X-Git-Url: https://projects.mako.cc/source/fspm_howto/blobdiff_plain/febb7957a8feb7e38610ebf3f920c7090fca1e74..57bccb28ad9f1356de427fd1156afff43abddce6:/FreeSoftwareProjectManagementHOWTO.sgml
diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index 98e1607..19375fd 100644
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -1,1439 +1,3068 @@
-
-
-
-
-
-
-
- Free Software Development HOWTO
-
-
- Benjamin
- Mako
- Hill
-
-
- mako@debian.org
-
-
-
-
-
-
- v0.01
- 1 January 2001
- bch
-
- Initial Release
-
-
-
-
-
-
- fswd
-
-
-
- This HOWTO is designed for people with experience in programming
- and some skills in managing a software project but who are new to
- the world of Free Software. This document is meant to act as a
- guide to the non-technical aspects of programming and is meant as
- a crash course in the people skills that can make or break a free
- software project.
-
-
-
-
-
-
-
-
- Introduction
-
-
- fswd!introduction
-
-
-
- For various reasons this brand new release is codenamed the
- release release.
-
-
-
- New code names will appear as per industry standard
- guidelines to emphasize the state-of-the-art-ness of this
- document.
-
-
-
- This document was written when I read a feedback asking for a
- template to fill in to make new HOWTOs. This template was
- initially made by extracting the skeletal structure of the Multi
- Disk HOWTO which is a rather large HOWTO. It then went through
- extensive editing.
-
-
-
- Stating the background is a simple way to getting started
- writing the intro.
-
-
-
- First of all we need a bit of legalese. Recent development
- shows it is quite important.
-
-
-
-
-
- Copyright Information
-
-
- This document is copyrighted (c) 2000 Stein Gjoen and is
- distributed under the terms of the Linux Documentation Project
- (LDP) license, stated below. Replace with your name,
- or supply a new license, when you use this skeleton for a new
- HOWTO.
-
-
-
- Unless otherwise stated, Linux HOWTO documents are
- copyrighted by their respective authors. Linux HOWTO documents may
- be reproduced and distributed in whole or in part, in any medium
- physical or electronic, as long as this copyright notice is
- retained on all copies. Commercial redistribution is allowed and
- encouraged; however, the author would like to be notified of any
- such distributions.
-
-
-
- All translations, derivative works, or aggregate works
- incorporating any Linux HOWTO documents must be covered under this
- copyright notice. That is, you may not produce a derivative work
- from a HOWTO and impose additional restrictions on its
- distribution. Exceptions to these rules may be granted under
- certain conditions; please contact the Linux HOWTO coordinator at
- the address given below.
-
-
-
- In short, we wish to promote dissemination of this
- information through as many channels as possible. However, we do
- wish to retain copyright on the HOWTO documents, and would like to
- be notified of any plans to redistribute the HOWTOs.
-
-
-
- If you have any questions, please contact
- linux-howto@metalab.unc.edu
-
-
-
-
-
-
- Disclaimer
-
-
- No liability for the contents of this documents can be accepted.
- Use the concepts, examples and other content at your own risk.
- As this is a new edition of this document, there may be errors
- and inaccuracies, that may of course be damaging to your system.
- Proceed with caution, and although this is highly unlikely,
- the author(s) do not take any responsibility for that.
-
-
-
- All copyrights are held by their by their respective owners, unless
- specifically noted otherwise. Use of a term in this document
- should not be regarded as affecting the validity of any trademark
- or service mark.
-
-
-
- Naming of particular products or brands should not be seen
- as endorsements.
-
-
-
- You are strongly recommended to take a backup of your system
- before major installation and backups at regular intervals.
-
-
-
-
-
-
- New Versions
-
-
- (your index root)!news on
-
-
-
- This is where you make a summary of what is new. When a
- HOWTO exceeds 20 pages it takes more than a casual read to find
- the updates. This is where you help your readers with that,
- alerting them to specific and important updates to the document.
-
-
-
- This is the initial release.
-
-
-
- Tell people where the document home page is so the very
- newest release could be found in case of problems with the main
- Linux Documentation
- Project homepage.
-
-
-
- The following is a sample from the Multi Disk HOWTO:
-
-
-
- The latest version number of this document can be
- gleaned from my plan entry if you
-
- finger my Nyx account.
-
-
-
- If you have the capability, it would be nice to
- make the HOWTO available in a number of formats.
-
-
-
- The newest version of this HOWTO will always be made available on
- my website, in a variety of formats:
-
-
-
-
-
-
- HTML.
-
-
-
-
-
- plain text.
-
-
-
-
-
- compressed
- postscript (US letter format).
-
-
-
-
-
- SGML source.
-
-
-
-
-
-
- Note that paper sizes vary in the world, A4 and US letter differ
- significantly. You might also wish to consider using the
- universal format (8.27x11in; 210x279mm).
-
-
-
-
-
-
- Credits
-
-
- It is always nice to acknowledge people who help you
- with input; it is also regarded by many as important in the
- Linux world new economy.
-
-
-
- In this version I have the pleasure of acknowledging:
-
-
-
- name (at) site.org
-
-
-
- Please scramble the addresses so email harvesters
- cannot get addresses from your HOWTO and then spam people. That
- has happened in the past.
-
-
-
- Somecompany is acknowledged for sending me
- documentation on their gizmos as well as permission to quote from
- the material. These quotes have been approved before appearing
- here and will be clearly labeled.
-
-
-
-
-
-
- Feedback
-
-
- Feedback is most certainly welcome for this document. Without
- your submissions and input, this document wouldn't exist. Please
- send your additions, comments and criticisms to the following
- email address : sgjoen@nyx.net.
-
-
-
-
-
-
- Translations
-
-
- Not everyone speaks English, pointers to translations are nice.
- Also your translators tend to give very important inputs.
-
-
-
-
-
-
-
- German Translation
- by someone (at) somewhere.de
-
-
-
-
-
- French Translation
- by someone (at) somewhere.fr
-
-
-
-
-
- Italian Translation
- by someone (at) somewhere.it
-
-
-
-
-
-
-
-
-
-
-
-
-
- Starting a Project
-
-
-
-
- Choosing a Project
-
-
-
-
-
- Deciding on a License
-
-
-
-
-
- Choosing a Method of Version Numbering
-
-
-
-
-
- Documentation
-
-
-
-
-
- Other Presentation Issues
-
-
-
-
-
- Nuturing Future Development
-
-
-
-
-
-
-
-
-
- Maintaining a Project: Interacting with Developers
-
-
-
-
- Delegating Work
-
-
-
-
-
- Stable and Development Branches
-
-
-
-
-
- Freezing
-
-
-
-
-
- Avoiding the Code Cram Effect
-
-
-
-
-
- Accepting and Rejecting Patches
-
-
-
-
-
-
- Maintaining a Project: Interacting with Users
-
-
-
-
- Announcing Your Project
-
-
-
-
-
- Testing and Testers
-
-
-
-
-
-
- Samples
-
-
- This section gives some simple SGML examples you could
- use. Read the SGML source to see how it was done.
-
-
-
- Further information and examples can be obtained from the publication
- DocBook: The Definitive
- Guide. Written by Norman Walsh
- and Leonard Muellner; 1st Edition, October 1999.
-
-
-
-
-
- Lists
-
-
- Lists are used frequently, and are available in a number
- of formats shown below.
-
-
-
- A list in which each entry is marked with a bullet or other dingbat:
-
-
-
-
-
-
- Apples
-
-
-
- Oranges
-
-
-
- Bananas
-
-
-
-
-
-
- A list in which each entry is composed of a set of one or more
- terms and an associated description:
-
-
-
-
-
-
- Fruits
-
- such as apples, oranges, and more.
-
-
-
-
- Nuts
-
- Don't eat too many; you are what you eat.
-
-
-
-
- Vegetables
-
- Potatos are spelled with care.
-
-
-
-
-
-
-
- A list in which each entry is marked with a sequentially
- incremented label:
-
-
-
-
-
-
- Step one
-
-
-
- Step two
-
-
-
-
-
-
-
-
-
- Links
-
-
- Links can be used within your documents to refer to
- different sections and chapters or to refer to documents external
- to yours.
-
-
-
- Internal links
-
-
- Click on the link to jump to the top of
- this chapter. Note the anchor at the section tag.
-
-
-
-
- External links
-
-
- Click on this link
- to jump to the LDP site. Note you can use http, ftp, news and
- other protocols in the locator if required.
-
-
-
-
-
-
-
-
- Images
-
-
- Avoid diagrams if possible as this cannot be rendered
- in the ASCII outputs which are still needed by many around the
- world.
-
-
-
-
- Graphics Test Image
-
-
-
-
-
- Here is another variation which allows for ALT text:
-
-
-
-
-
-
-
-
-
-
-
- ALT text to be used: Green Ball
-
-
-
-
-
- Caption for the graphic goes here: This is a Green Ball.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Structure
-
-
- A quick overview on how all parts fit together in the overall
- structure. An example from the Multi Disk HOWTO is used.
-
-
-
- As this type of document is supposed to be as much for learning as
- a technical reference document I have rearranged the structure to
- this end. For the designer of a system it is more useful to have
- the information presented in terms of the goals of this exercise
- than from the point of view of the logical layer structure of the
- devices themselves. Nevertheless this document would not be
- complete without such a layer structure the computer field is so
- full of, so I will include it here as an introduction to how it
- works.
-
-
-
-
-
- Logical structure
-
-
- disk!structure, I/O subsystem
-
-
-
- This is based on how each layer access each other, traditionally
- with the application on top and the physical layer on the bottom.
- It is quite useful to show the interrelationship between each of
- the layers used in controlling drives.
-
-
- ___________________________________________________________
- |__ File structure ( /usr /tmp etc) __|
- |__ File system (ext2fs, vfat etc) __|
- |__ Volume management (AFS) __|
- |__ RAID, concatenation (md) __|
- |__ Device driver (SCSI, IDE etc) __|
- |__ Controller (chip, card) __|
- |__ Connection (cable, network) __|
- |__ Drive (magnetic, optical etc) __|
- -----------------------------------------------------------
-
-
-
-
- In the above diagram both volume management and RAID and
- concatenation are optional layers. The 3 lower layers are in
- hardware. All parts are discussed at length later on in this
- document.
-
-
-
-
-
-
- Document structure
-
-
- Most users start out with a given set of hardware and some plans
- on what they wish to achieve and how big the system should be.
- This is the point of view I will adopt in this document in
- presenting the material, starting out with hardware, continuing
- with design constraints before detailing the design strategy that
- I have found to work well. I have used this both for my own
- personal computer at home, a multi purpose server at work and
- found it worked quite well. In addition my Japanese co-worker in
- this project have applied the same strategy on a server in an
- academic setting with similar success.
-
-
-
- Finally at the end I have detailed some configuration tables for
- use in your own design. If you have any comments regarding this
- or notes from your own design work I would like to hear from you
- so this document can be upgraded.
-
-
-
-
-
-
- Reading plan
-
-
- As you go beyond 50 pages or so there will be a lot of
- text that experts and even the experienced do not need to read.
- Keeping in mind that we wish to care for all kinds of people in
- the Linux world we might have to make a reading plan. Again,
- an example follows from the Multi Disk HOWTO.
-
-
-
- Although not the biggest HOWTO it is nevertheless rather big
- already and I have been requested to make a reading plan to make
- it possible to cut down on the volume.
-
-
-
-
-
-
- Expert
-
-
- (aka the elite). If you are familiar with Linux as well as
- disk drive technologies you will find most of what you need in
- the appendices. Additionally you are recommended to read the
- FAQ and the chapter.
-
-
-
-
-
- Experienced
-
-
- (aka Competent). If you are familiar with computers in
- general you can go straight to the chapters on
- and continue from there on.
-
-
-
-
-
- Newbie
-
-
- (mostly harmless). You just have to read the whole thing.
- Sorry. In addition you are also recommended to read all the
- other disk related HOWTOs.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Technologies
-
-
- (your index root)!technologies
-
-
-
- Introduction of technology for the newbie with a few
- references to detailed works. Remember that not everyone has
- Internet access so you have to explain in sufficient details so
- even the newbie can get by.
-
-
-
-
-
-
-
-
-
-
- Implementation
-
-
- (your index root)!implementation
-
-
-
- Now your readers should have a sufficient knowledge of
- what this is about and now we come to the hands on of implementing
- your clever scheme.
-
-
-
-
-
-
-
-
-
-
- Maintenance
-
-
- (your index root)!maintenance
-
-
-
- Few systems and designs are maintenance free, here you
- explain how to keep the system running.
-
-
-
-
-
-
-
-
-
-
- Advanced Issues
-
-
- (your index root)!advanced topics
-
-
-
- You can get most things up and running in a quick and
- dirty fashion, useful for testing and getting used to how things
- work. For more serious use you would need to be a little more
- advanced. This is the place to explain it all, if applicable.
-
-
-
-
-
-
-
-
-
-
- Further Information
-
-
- (your index root)!information resources
-
-
-
- A HOWTO cannot describe everything, some times the user
- has to venture out on th enet to get more information or just
- updates. Here is the place to tell where and how. Again examples
- from the Multi Disk HOWTO, replace as needed. There is wealth
- of information one should go through when setting up a major system,
- for instance for a news or general Internet service provider. The
- FAQs in the following groups are useful:
-
-
-
-
-
- News groups
-
-
- disk!information resources!news groups
-
-
- Some of the most interesting news groups are:
-
-
-
-
-
- Storage.
-
-
-
-
-
- PC storage.
-
-
-
-
-
- AFS.
-
-
-
-
-
- SCSI.
-
-
-
-
-
- Linux setup.
-
-
-
-
-
-
-
- Most newsgroups have their own FAQ that are designed to answer most
- of your questions, as the name Frequently Asked Questions indicate.
- Fresh versions should be posted regularly to the relevant newsgroups.
- If you cannot find it in your news spool you could go directly to the
- FAQ main archive FTP site.
- The WWW versions can be browsed at the
- FAQ
- main archive WWW site.
-
-
-
- Some FAQs have their own home site, of particular interest:
-
-
-
-
-
- SCSI FAQ
- and
-
-
-
-
-
- comp.arch.storage FAQ.
-
-
-
-
-
-
-
-
-
-
- Mailing Lists
-
-
- disk!information resources!mailing lists
-
-
-
- These are low-noise channels mainly for developers. Think twice
- before asking questions there as noise delays the development.
- Some relevant lists are linux-raid,
- linux-scsi and linux-ext2fs. Many
- of the most useful mailing lists run on the vger.rutgers.edu server but this is
- notoriously overloaded, so try to find a mirror. There are some
- lists mirrored at The Redhat
- Home Page. Many lists are also accessible at linuxhq, and the
- rest of the web site contains useful information as well.
-
-
-
- If you want to find out more about the lists available you can send
- a message with the line lists to the list server
- at majordomo@vger.rutgers.edu.
- If you need help on how to use the mail server just send the line
- help to the same address. Due to the
- popularity of this server it is likely it takes a bit to time before
- you get a reply or even get messages after you send a
- subscribe command.
-
-
-
- There is also a number of other majordomo list servers that can
- be of interest such as the EATA driver list
- (linux-eata@mail.uni-mainz.de)
- and the Intelligent IO list linux-i2o@dpt.com.
-
-
-
- Mailing lists are in a state of flux but you can find links to a
- number of interesting lists from the
- Linux Documentation
- Homepage.
-
-
-
-
-
-
- HOWTO
-
-
- disk!information resources!HOWTOs
-
-
-
- These are intended as the primary starting points to get the
- background information as well as show you how to solve a
- specific problem. Some relevant HOWTOs are
- Bootdisk,
- Installation,
- SCSI and
- UMSDOS. The main site for these is the
- LDP archiveat
- Metalab (formerly known as Sunsite).
-
-
-
- There is a a new HOWTO out that deals with setting up a DPT RAID
- system, check out the
- DPT RAID
- HOWTO homepage.
-
-
-
-
-
-
- Local Resources
-
-
- disk!information resources!local
-
-
-
- In most distributions of Linux there is a document directory
- installed, have a look in the /usr/doc
- directory. where most packages store their main documentation and
- README files etc. Also you will here find the HOWTO archive
- (/usr/doc/HOWTO) of ready formatted HOWTOs
- and also the mini-HOWTO archive
- (/usr/doc/HOWTO/mini) of plain text
- documents.
-
-
-
- Many of the configuration files mentioned earlier can be found in
- the /etc directory. In particular you will
- want to work with the /etc/fstab file that
- sets up the mounting of partitions and possibly also
- /etc/raidtab file that is used for the
- md system to set up RAID.
-
-
-
- The kernel source in /usr/src/linux is, of
- course, the ultimate documentation. In other words, use
- the source, Luke. It should also be pointed out that the
- kernel comes not only with source code which is even commented
- (well, partially at least) but also an informative
- /usr/src/linux/Documentation. If you are
- about to ask any questions about the kernel you should read this
- first, it will save you and many others a lot of time and
- possibly embarrassment.
-
-
-
- Also have a look in your system log file
- (/var/log/messages) to see what is going on
- and in particular how the booting went if too much scrolled off
- your screen. Using tail -f /var/log/messages
- in a separate window or screen will give you a continuous update
- of what is going on in your system.
-
-
-
- You can also take advantage of the /proc
- file system that is a window into the inner workings of your
- system. Use cat rather than
- more to view the files as they are reported as
- being zero length. Reports are that less works
- well here.
-
-
-
-
-
-
- Web Sites
-
-
- disk!information resources!WWW
-
-
- disk!information resources!web pages
-
-
-
- There are a huge number of informative web sites available. By
- their very nature they change quickly so do not be surprised
- if these links become quickly outdated.
-
-
-
- A good starting point is of course the
- Linux Documentation
- Project home page, an information central for
- documentation, project pages and much more.
-
-
-
- Please let me know if you have any other leads that can be
- of interest.
-
-
-
-
-
-
-
-
-
-
-
- Getting Help
-
-
- (your index root)!assistance, obtaining
-
-
-
- In the end you might find yourself unable to solve your problems
- and need help from someone else. The most efficient way is either
- to ask someone local or in your nearest Linux user group, search
- the web for the nearest one.
-
-
-
- Another possibility is to ask on Usenet News in one of the many,
- many newsgroups available. The problem is that these have such a
- high volume and noise (called low signal-to-noise ratio) that your
- question can easily fall through unanswered.
-
-
-
- No matter where you ask it is important to ask well or you will
- not be taken seriously. Saying just my disk
- does not work is not going to help you and instead the
- noise level is increased even further and if you are lucky someone
- will ask you to clarify.
-
-
-
- Instead describe your problems in some detail that will enable
- people to help you. The problem could lie somewhere you did not
- expect. Therefore you are advised to list the following information
- about your system:
-
-
-
-
-
-
- Hardware
-
-
-
-
- Processor
-
-
-
- DMA
-
-
-
- IRQ
-
-
-
- Chip set (LX, BX etc)
-
-
-
- Bus (ISA, VESA, PCI etc)
-
-
-
-
- Expansion cards used (Disk controllers, video, IO
- etc.)
-
-
-
-
-
-
-
-
-
- Software
-
-
-
-
-
- BIOS (On motherboard and possibly SCSI host adapters)
-
-
-
- LILO, if used
-
-
-
-
- Linux kernel version as well as possible modifications
- and patches
-
-
-
-
- Kernel parameters, if any
-
-
-
-
- Software that shows the error (with version number
- or date)
-
-
-
-
-
-
-
-
-
-
- Peripherals
-
-
-
-
-
-
- Type of disk drives with manufacturer name, version and type
-
-
-
-
- Other relevant peripherals
-
-
-
-
-
-
-
-
-
-
-
- Remember that booting text is logged to
- /var/log/messages which can answer most of
- the questions above. Obviously if the drives fail you might not be
- able to get the log saved to disk but you can at least scroll
- back up the screen using the SHIFT and
- PAGE UP keys. It may also be useful to include
- part of this in your request for help but do not go overboard,
- keep it brief as a complete log file dumped
- to Usenet News is more than a little annoying.
-
-
-
-
-
-
-
-
-
-
- Concluding Remarks
-
-
- (your index root)!conclusion
-
-
-
- Just summing up... Also a place for general
- recommendations.
-
-
-
-
-
-
-
-
-
-
- Questions and Answers
-
-
- (your index root)!FAQ
-
-
- (your index root)!frequently asked questions
-
-
-
- Check the newsgroups and try to determine some frequent
- problems and cover them here. Again an example from the Multi Disk
- HOWTO.
-
-
-
- This is just a collection of what I believe are the most common
- questions people might have. Give me more feedback and I will turn
- this section into a proper FAQ.
-
-
-
-
-
-
- Q:How many physical disk drives (spindles) does a Linux system need?
-
-
-
- A: Linux can run just fine on one drive (spindle). Having
- enough RAM (around 32 MB, and up to 64 MB) to support swapping
- is a better price/performance choice than getting a second
- disk. (E)IDE disk is usually cheaper (but a little slower) than
- SCSI.
-
-
-
-
-
- Q: Are there any disadvantages in this scheme?
-
-
-
- A: There is only a minor snag: if even a single partition
- overflows the system might stop working properly. The severity
- depends of course on what partition is affected. Still this is
- not hard to monitor, the command df gives
- you a good overview of the situation. Also check the swap
- partition(s) using free to make sure you are
- not about to run out of virtual memory.
-
-
-
-
-
- Q: OK, so should I split the system into as many partitions as
- possible for a single drive?
-
-
-
- A: No, there are several disadvantages to that. First of all
- maintenance becomes needlessly complex and you gain very little
- in this. In fact if your partitions are too big you will seek
- across larger areas than needed. This is a balance and
- dependent on the number of physical drives you have.
-
-
-
-
-
-
- Greg Leblanc: Depending on how big this FAQ gets, perhaps it
- would be worthwhile to have, say, the 5 most FAQ, and put the
- rest into an external FAQ. Dunno. Comments?
-
-
- (rest deleted.)
-
-
-
-
-
-
-
-
-
-
- Bits and Pieces
-
-
- disk!miscellaneous
-
-
-
- This is basically a section where I stuff all the bits I have not
- yet decided where should go, yet that I feel is worth knowing
- about. It is a kind of transient area.
-
-
-
-
-
-
-
-
-
-
- Examples
-
-
- (your index root)!examples
-
-
-
- Example designs and sample configuration files and other
- relevant details is always handy
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ Free Software Development HOWTO
+
+
+ Benjamin
+ Mako
+ Hill
+
+
+ mako@debian.org
+
+
+
+
+
+
+ v0.2
+ 8 April 2001
+ bch
+
+
+
+ v0.01
+ 27 March 2001
+ bch
+ Initial Release
+
+
+
+
+
+ fswd
+
+
+
+ This HOWTO is designed for people with experience in programming
+ and some skills in managing a software project but who are new to
+ the world of free software. This document is meant to act as a
+ guide to the non-technical aspects of free software development
+ and was written to act as a crash course in the people skills that
+ aren't taught to commercial coders but that can make or break a
+ free software project.
+
+
+
+
+
+
+
+
+ Introduction
+
+
+ fswd!introduction
+
+
+
+ Skimming through freshmeat.net provides mountains of reasons for this
+ HOWTO's existence--the Internet is littered with excellently
+ written and useful programs that have faded away into the Universe
+ of Free Software Forgottenness. This dismal scene made me ask
+ myself, "Why?"
+
+
+
+ This HOWTO tries to do a lot of thing (probably too many), but it
+ can't answer that question and won't attempt it. What this HOWTO
+ will attempt to do is give your Free Software project a fighting
+ chance--an edge. If you write a piece of crap that no one is
+ interested in, you can read this HOWTO until you can recite it in
+ your sleep and your project will probably fail. Then again, you can
+ write a beautiful, relevant piece of software and follow every
+ instruction in this HOWTO and your software may still not make
+ it. Sometimes life is like that. However, I'll go out a limb and
+ say that if you write a great, relevant pieces of software and
+ ignore the advise in this HOWTO, you'll probably fail
+ more often.
+
+
+
+ A lot of the information in this HOWTO is best called common
+ sense. Of course, as any debate on interfaces will prove, what is
+ common sense to some programmers proves totally unintuitive to
+ others. After explaining bits and pieces of this HOWTO to Free
+ Software developers on several occasions, I realized that writing
+ this HOWTO might provide a useful resource and a forum for
+ programmers to share ideas about what has and has not worked for
+ them.
+
+
+
+ As anyone involved in any of what seems like an unending parade of
+ ridiculous intellectual property clashes will attest to, a little
+ bit of legalese proves important.
+
+
+
+
+
+ Copyright Information
+
+
+ This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is
+ distributed under the terms of the Linux Documentation Project
+ (LDP) license, stated below.
+
+
+
+ Unless otherwise stated, Linux HOWTO documents are copyrighted by
+ their respective authors. Linux HOWTO documents may be reproduced
+ and distributed in whole or in part, in any medium physical or
+ electronic, as long as this copyright notice is retained on all
+ copies. Commercial redistribution is allowed and encouraged;
+ however, the author would like to be notified of any such
+ distributions.
+
+
+
+ All translations, derivative works, or aggregate works
+ incorporating any Linux HOWTO documents must be covered under this
+ copyright notice. That is, you may not produce a derivative work
+ from a HOWTO and impose additional restrictions on its
+ distribution. Exceptions to these rules may be granted under
+ certain conditions; please contact the Linux HOWTO coordinator at
+ the address given below.
+
+
+
+ In short, we wish to promote dissemination of this information
+ through as many channels as possible. However, we do wish to
+ retain copyright on the HOWTO documents, and would like to be
+ notified of any plans to redistribute the HOWTOs.
+
+
+
+ If you have any questions, please contact
+ linux-howto@metalab.unc.edu
+
+
+
+
+
+
+ Disclaimer
+
+
+ No liability for the contents of this documents can be accepted.
+ Use the concepts, examples and other content at your own risk. As
+ this is a new edition of this document, there may be errors and
+ inaccuracies, that may of course be damaging to your system.
+ Proceed with caution, and although this is highly unlikely, the
+ author(s) do not take any responsibility for that.
+
+
+
+ All copyrights are held by their by their respective owners, unless
+ specifically noted otherwise. Use of a term in this document
+ should not be regarded as affecting the validity of any trademark
+ or service mark.
+
+
+
+ Naming of particular products or brands should not be seen
+ as endorsements.
+
+
+
+ You are strongly recommended to take a backup of your system
+ before major installation and backups at regular intervals.
+
+
+
+
+
+
+ New Versions
+
+
+ fswd!news on
+
+
+
+ This is the initial release. It is written to be released to
+ developers for critique and brainstorming and submitted to
+ Hampshire College for academic credit. Please keep in mind that
+ this version of the HOWTO is still in an infant stage and will be
+ revised extensively before it hits the LDP.
+
+
+
+ The latest version number of this document should always be listed
+ on my webpage at
+ Debian.
+
+
+
+ The newest version of this HOWTO will always be made available at
+ the same website, in a variety of formats:
+
+
+
+
+
+
+
+ HTML.
+
+
+
+
+
+
+ HTML (single page).
+
+
+
+
+
+ plain text.
+
+
+
+
+
+ compressed postscript.
+
+
+
+
+
+ Compressed SGML source.
+
+
+
+
+
+
+
+
+
+ Credits
+
+
+ In this version I have the pleasure of acknowledging:
+
+
+
+ Karl Fogel, the author of Open
+ Source Development with CVS published by the Coriolis
+ Open Press. Large parts of his book are available on the web. 225 pages of
+ the book are available under the GPL and constitute the best
+ tutorial on CVS I've ever seen. The rest of the book covers, "the
+ challenges and philosophical issues inherent in running an Open
+ Source project using CVS." The book does a good job of covering
+ some of the subjects brought up in this HOWTO and much
+ more. The book's
+ website has information on ordering the book and provides
+ several translations of the chapters on CVS. I you are seriously
+ interested in running a Free Software project, you want this
+ book. I tried to mention Fogel in sections of this HOWTO where I
+ knew I was borrowing directly from his ideas. If I missed any, I'm
+ sorry, and I'll try and have those fixed in future versions.
+
+
+
+ Karl Fogel can be reached at kfogel (at) red-bean (dot)
+ com
+
+
+
+ Also providing support material, and inspiration for this HOWTO is
+ Eric S. Raymond for his prolific, consistent, and carefully
+ crafted arguments, Lawrence Lessig for reminding me of the
+ importance of Free Software. Additionaly, I want to thank every
+ user and developer involved with the Debian Project. The project
+ has provided me with a home, a place to practice Free Software
+ advocacy, a place to make a difference, a place to learn from
+ those how have been involved with the movement much longer than I,
+ and proof of a Free Software project that definitely, definitely
+ works.
+
+
+
+ Above all, I want to thank Richard Stallman
+ for his work at the Free Software Foundation and for never giving
+ up. Stallman provides and articulates the philosophical basis that
+ attracts me to Free Software and that drives me towards writing a
+ document to make sure it succeeds. RMS can always be emailed at
+ rms (at) gnu (dot) org.
+
+
+
+
+
+
+
+ Feedback
+
+
+ Feedback is always and most certainly welcome for this
+ document. Without your submissions and input, this document
+ wouldn't exist. Do you feel that something is missing? Don't
+ hesitate to contact me to have me write a chapter, section, or
+ subsection or to write one yourself. I want this document to be a
+ product of the Free Software development process that it heralds
+ and I believe that its ultimate success will be rooted in this
+ fact. Please send your additions, comments and criticisms to the
+ following email address : mako@debian. org.
+
+
+
+
+
+
+ Translations
+
+
+ I know that not everyone speaks English. Translations are nice and
+ I'd love for this HOWTO to gain the kind of international reach
+ afforded by a translated version.
+
+
+
+ However, this HOWTO is still young and I have to yet to be
+ contacted about a translation so English is all that is currently
+ available. If you would like to help with or do a translation, you
+ will gain my utmost respect and admiration and you'll get to be
+ part of a cool process. If you are at all interested, please don't
+ hesitate to contact me at: mako@debian.org.
+
+
+
+
+
+
+
+
+
+ Starting a Project
+
+
+ fswd!starting
+
+
+ With very little argument, the beginning is most difficult part of
+ successful free software development. Laying a firm foundation will
+ determine whether your project flourishes or withers away and
+ dies. It is also the subject that is of most immediate interest to
+ anyone reading this document as a tutorial.
+
+
+
+ Starting a project involves a dilemma that you as a developer must
+ try and deal with: No potential user for your program is interested
+ in a program that doesn't work. Simultaneously, the development
+ process that you want to employ holds involvement of users as
+ prerequisit to working software.
+
+
+
+ It is in these dangerous initial moments that anyone working to
+ start a free software project must try and strike a balance along
+ these lines. One of the most important ways that someone trying to
+ start a project can work towards this balance is by establishing a
+ solid framework for the development process through some of the
+ suggestions mentioned in this section.
+
+
+
+
+
+
+ Choosing a Project
+
+
+ If you are reading this document, there's a good chance you
+ already have an idea for a project in mind. Chances are pretty
+ good, it fills in a percieved gap by doing something that no other
+ free software process does or by doing something in a way the is
+ unique enough to necessitate a separate project.
+
+
+
+ Identify and articulate your idea
+
+ Eric S. Raymond writes about how free software projects start in
+ his paper, The Cathedral and the Bazaar, which
+ comes as required reading for any free software development. It
+ is available online
+ .
+
+
+
+ In The Cathedral and the Bazaar, Raymond tells us
+ that: Every good work of software starts by scratching
+ a developers itch. Raymond's now widely accepted
+ hypothesis is that new free software programs are written, first
+ and foremost, to solve a specific problem facing the developer.
+
+
+
+ If you have an idea for a program in mind, chances are good that
+ it targets a specific problem or itch you want to
+ see scratched. This idea is the project. Articulate it
+ clearly. Write it out. Describe the problem you will attack in
+ detail. The success of your project in tackling a particular
+ problem will be tied to your ability to identify that problem
+ early on. Find out exactly what it is that you want your project
+ to do.
+
+
+
+ Monty Manley articles the importance of this initial step in an
+ essay, Managing
+ Projects the Open Source Way. As the next section will
+ show, there is a lot of work that needs to
+ be done before software is ready for release. Manley says,
+ Beginning an OSS project properly means that a developer
+ must, first and foremost, avoid writing code too soon!
+
+
+
+
+ Evaluate your idea
+
+
+ In evaluating your idea, you need to first ask yourself a few
+ questions. Before you move any further into this HOWTO, you need
+ to determine if the free software development model really is the
+ right one for your project. Obviously, since the program
+ scratches your itch, you are definitely interested in seeing it
+ implemented in code. But, because one hacker coding in solitude
+ fails to qualify as a free software development effort, you need
+ to ask yourself the question: Is anybody else
+ interested?
+
+
+
+ Sometimes the answer is a simple no. If you
+ want to write a set of scripts to sort your
+ MP3 collection on your machine, maybe the free
+ software development model is not the best one to
+ choose. However, if you want to write a set of scripts to sort
+ anyone's MP3s, a free
+ software project might fill a useful gap.
+
+
+
+ Luckily, The Internet is a place so big and so diverse that,
+ chances are, there is someone, somewhere, who shares your
+ interests and how feels the same itch. It is the
+ fact that there are so many people with so many similar needs and
+ desires that introduces the second major question: Has
+ somebody already had your idea or a reasonably similar
+ one?
+
+
+
+ Finding Similar Projects
+
+
+ There are places you can go on the web to try and answer the
+ question above. If you have experience with the free software
+ community, you are probably already familiar with all of these
+ sites. All of the resources listed bellow offer searching of
+ their databases:
+
+
+
+
+
+ freshmeat.net:
+
+ freshmeat.net
+ describes itself as, the Web's largest index of Linux
+ and Open Source software and its reputation along
+ these lines is totally unparalleled and unquestioned. If you
+ can't find it on freshmeat, its doubtful that you (or anyone
+ else) will find it anywhere.
+
+
+
+
+ Slashdot:
+
+ Slashdot
+ provides News for Nerds: Stuff that Matters,
+ which usually includes discussion of free software, open
+ source, technology, and geek culture new and events. It is
+ not unusual for an particularly sexy development effort to be
+ announced here so it definitely worth checking.
+
+
+
+
+ SourceForge:
+
+ SourceForge
+ houses and facilitates a growing number of open source and
+ free software projects. It is also quickly becoming a nexus
+ and an necessary stop for free software
+ developers. SourceForge's software
+ map and new
+ releases pages should be necessary stops before
+ embarking on a new free software project. SourceForge also
+ provides a at Code Snippet
+ Library which contains useful reusable chunks of code
+ in an array of languaqges which can come in useful in any
+ project.
+
+
+
+
+ Google and Google's Linux Search:
+
+ Google and
+ Google's Linux
+ Search, provide powerful web searches that may
+ reveal people working on similar projects. It is not a
+ catalog of software or news like freshmeat or Slashdot, but
+ it is worth checking before you begin pouring your effort
+ into a redundant project.
+
+
+
+
+
+
+
+
+ Deciding to Proceed
+
+ Once you have successful charted the terrain and have an idea
+ bout what kinds of similar free software projects exist, every
+ developer needs to decide whether to proceed with their own
+ project. It is rare that a new project seeks to accomplish a
+ goal that is not similar to or related to the goal of another
+ project. Anyone starting a new project needs to ask themselves:
+ Will the new project be duplicating work done by another
+ project? Will the new project be competing for developers with
+ an existing project? Can the goals of the new project be
+ accomplished by adding functionality to an existing
+ project?
+
+
+
+ If the answer to any of these questions is yes,
+ try to contact the developer of the existing project(s) in
+ question and see if he or she might be willing to collaborate
+ with you.
+
+
+
+ This may be the single most difficult aspect of free software
+ development for many developers but it is an essential one. It
+ is easy to become fired up by an idea and be caught up in the
+ momentum and excitement of a new project. It is often extremely
+ difficult to do but, it is important that any free software
+ developer remember that the best interests of the free software
+ community and the quickest way to accomplish ones own project's
+ goals and the goals of similar project can often be accomplished
+ by not starting a new project.
+
+
+
+
+
+
+
+
+
+ Naming your project
+
+
+ While there are plenty of projects that fail with descriptive
+ names and plenty that succeed without them, I think naming your
+ project is wroth giving a little bit of thought. Leslie Orchard
+ tackles this issue in a n advogato
+ article. The article is short and probably worth looking
+ over quickly.
+
+
+
+ The very short version is that Orchard recommends that you should
+ pick a name where, after hearing the name, many users or
+ developers will:
+
+
+
+
+
+ You will know what the project does.
+
+
+ You will remember it tomorrow.
+
+
+
+
+
+ Humorously, Orchard's project, Iajitsu, does neither (and
+ development is effectively frozen since the article was written).
+
+
+
+ There is a point though. There are companies who only job is to
+ make names for pieces of software. They make
+ ridiculous amount of money doing it and they
+ are supposedly worth it. While you probably can't aford a company
+ like this, you can afford to learn from their existance and think
+ a little bit about the name you are giving your project.
+
+
+
+ If there is a name you really want, go ahead. I though
+ gnubile was one of the best names ever and I still
+ talk about it, long after I've stopped using the program. If you
+ can flexible on the subject, listen to Orchard's advice. It might
+ even help you.
+
+
+
+
+
+
+ Licensing your Software
+
+
+ On one (somewhat simplistic) level, the difference between a piece
+ of free software and a piece of propriety software is the
+ license. A license helps you as the developer by protecting your
+ legal rights to have your software distributed under your terms
+ and helps demonstrate to those who wish to help you or your
+ project that they are encouraged to join.
+
+
+
+ Choosing a license
+
+
+ Any discussion of licenses is also sure to generate at least a
+ small flame war as there are strong feelings that some free
+ software licenses are better than others. This discussion also
+ brings up the question of Open Source Software and
+ the debate around Open Source Software and
+ Free Software. However, because I've written the
+ Free Software Development HOWTO and not the Open Source
+ Development HOWTO, my own allegiances in this argument are in the
+ open.
+
+
+
+ In attempting to reach a middle ground through diplomacy without
+ sacrificing my own philosophy, I recommend picking any license
+ that conforms to the Debian Free Software
+ Guidelines. Originally compiled by the Debian project
+ under Bruce Perens, the DFSG form the first
+ version of the Open Source definition. Examples of free licenses
+ given by the DFSG are the
+ GPL, the BSD, and the
+ Artistic License.
+
+
+
+ Conforming to the definition of Free Software offered by Richard
+ Stallman in The Free
+ Software Definition, any of these licenses will
+ uphold, users' freedom to run, copy, distribute, study,
+ change and improve the software. There are plenty of
+ other licenses that also conform to the DFSG
+ but sticking with a more common license will offer the advantage
+ of immediate recognition and understanding.
+
+
+
+ In attempting a more in-depth analysis, I agree with Karl Fogel's
+ description of licenses as falling into two groups: those that
+ are the GPL and those that are not the
+ GPL.
+
+
+
+ Personally, I license all my software under the
+ GPL. Created and protected by the Free
+ Software Foundation and the GNU Project, the
+ GPL is the license for the Linux kernel,
+ GNOME, Emacs, and the vast majority of GNU/Linux software. It's
+ the obvious choice but I believe it is a good one. Any BSD
+ fanatic will urge you to remember that there is a viral aspect to
+ the GPLthat prevents the mixture of
+ GPL'ed code with non-GPL'ed
+ code. To many people (myself included), this is a benefit, but to
+ some, it is a major drawback.
+
+
+
+ The three major license can be found at the following locations:
+
+
+
+
+
+ The GNU
+ General Public License
+
+
+ The
+ BSD License
+
+
+ The Artistic
+ License
+
+
+
+
+
+ In any case, please read through any license before
+ your release your software. As the primary developer, you can't
+ afford any license surprises.
+
+
+
+
+ The mechanics of licensing
+
+
+ The text of the GPL offers a good
+ description of mechanics of applying a license to a piece
+ of software. My quick checklist for applying a license includes:
+
+
+
+
+
+
+ If at all possible, attach and distribute a full copy of
+ the license with the source and binary in a separate
+ file.
+
+
+
+ At the top of each source file in your program, attach a
+ notice of copyright and information on where the full license
+ can be found. The GPL recommends that each
+ file begin with:
+
+
+one line to give the program's name and an idea of what it does.
+Copyright (C) yyyy name of author
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+
+
+ The GPL goes on to recommend attaching
+ information on contacting you (the author) via email or
+ physical mail.
+
+
+
+
+
+ The GPL continues and suggests that if your
+ program runs in an interactive mode, you should write the
+ program to output a notice each time it enters interactive
+ mode that includes a message like this one that points to more
+ information about the programs licensing:
+
+
+
+Gnomovision version 69, Copyright (C) year name of author
+Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
+type `show w'. This is free software, and you are welcome
+to redistribute it under certain conditions; type `show c'
+for details.
+
+
+
+
+ Finally, it might be helpful to include a
+ copyright disclaimer with the program from an
+ employer or a school if you work as a programmer or if it seems
+ like your employer or school might be able to make an argument
+ for ownership of your code later on. Its often needed but there
+ are plenty of free software developers who have gotten into
+ trouble and wish they had attained one.
+
+
+
+
+
+
+
+ Final license warning
+
+
+ Please, please, please, place your software under some
+ license. It may not seem important, and to you, it may not be,
+ but licenses are important. For a piece of
+ software to be included in the Debian GNU/Linux distribution, it
+ must have a license that fits the Debian Free Software
+ Guidelines. If you have no license, your program can not
+ be distributed as a package in Debian until you re-release it
+ under a free license. Please save yourself and others trouble by
+ releasing the first version of your software with a clear
+ license.
+
+
+
+
+
+
+
+
+
+ Choosing a Method of Version Numbering
+
+
+ The most important thing about a system of version
+ numbering is that there is one. It may seem pedantic to
+ emphasize this point but you'd be surprised at the number of
+ scripts and small programs that pop up without any version number
+ at all.
+
+
+
+ The second most important thing about a system of
+ numbering is that the numbers always go up. Automatic
+ version tracking systems and people's sense of order in the
+ universe will fall apart if version numbers don't rise. It doesn't
+ really matter if 2.1 is a big jump and
+ 2.0.005 is a small jump but it does matter that 2.1 is more recent
+ than 2.0.005.
+
+
+
+ Beyond this, the most common technique seems to be the
+ major level, minor level,
+ patch level version numbering scheme. Whether you
+ are familiar with it or not, you interact with it all the
+ time. The first number is the major number and it signifies major
+ changes or rewrites. The second number is the minor number and it
+ represents added or tweaked functionality on top of a largely
+ coherant structure. The third number is the patch number and it
+ usually will only refer to bug fixes.
+
+
+
+ The widespread use of this scheme is why I know the nature and
+ relative degree in the differences between a 2.4.12 release of the
+ Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowning
+ anything about any of the releases.
+
+
+
+ You can bend or break these rules, and people do. Beware, if you
+ choose to, someone will get annoyed, assume you don't know, and
+ try and educate you. I always follow this method and I implore you
+ to do so as well.
+
+
+
+ Follow these two simple rules and you will not go (too)
+ wrong. Still, there are several version numbering systems that are
+ well known, useful, and that might be worth looking into before
+ you release your first version.
+
+
+
+
+ Linux kernel version numbering:
+
+ The Linux kernel uses a versioning system where any odd
+ minor version number refers to an development or testing release
+ and any even minor version number refers to a stable
+ version. Think about it for a second. Under this system, 2.1 and
+ 2.3 kernels were and always will be development or testing
+ kernels and 2.0, 2.2. and 2.4 kernels are all production code
+ with a higher degree of stability and more testing.
+
+
+
+ Whether you plan on having a split development model (as
+ described in ) or only one version
+ released at a time, my experience with several free software
+ projects and with the Debian project has taught me that use of
+ Linux's version numbering system is worth taking into
+ consideration. In Debian, all minor versions are stable
+ distributions (2.0, 2.1, etc). However, many people assume that
+ 2.1 is an unstable or development version and continue to use
+ an older version until they get so frustrated with the lack of
+ progress development that they complain and figure the system
+ out. If you never release an odd minor version but only release
+ even ones, nobody is hurt, and less people are confused. It's
+ worth taking into consideration.
+
+
+
+
+
+ Wine version numbering:
+
+ Because of the unusual nature of wine's development where
+ the not-emulator is constantly improving but not working towards
+ any immediately achievable goal, wine is released every three
+ weeks. Wine does this by labeling their releases in Year Month
+ Day format where each release might be labeled
+ wine-XXXXXXXX where the version from January 04,
+ 2000 would be wine-20000104. For certain
+ projects, Year Month Day format can make a lot of sense.
+
+
+
+
+
+ Mozilla milestones:
+
+ When one considers Netscape 6 and vendor versions, the
+ mozilla's project development structure is one of the most
+ complex free software model available. Their version numbering
+ has reflected the unique situation in which it is
+ developed.
+
+
+
+ Mozilla's version numbering structure has historically been
+ made up of milestones. From the beginning of the mozilla
+ project, the goals of the project in the order and degree to
+ which they were to be achieved were charted out on a series of
+ road
+ maps. Major points and achievements along these
+ road-maps were marked as milestones. Therefore, mozilla was
+ built and distributed nightly as "nightly builds" but on a day
+ when the goals of a milestone on the road-map had been reached,
+ that particular build was marked as a milestone release.
+
+
+
+ While I haven't seen this method employed in any other projects
+ to date, I like the idea and think that it might have value in
+ any testing or development branch of a large free application
+ under heavy development.
+
+
+
+
+
+
+
+
+
+
+ Documentation
+
+
+ A huge number of otherwise fantastic free software applications
+ have withered and died because their author was the only person
+ who knew how to use them fully. Even if your program is written
+ primarily for a techno-savvy group of users, documentation is
+ helpful and even necessary for the survival of your project. You
+ will learn later in that you should
+ always release something that is usable. A piece of
+ software without documentation is not usable.
+
+
+
+ There are lots of different people for whom to document and
+ therefore there are lots of ways to document your
+ project. The importance of ocumentation in source code
+ to help facilitate development by a large community is vital but
+ it falls outside the scope of this HOWTO. This being
+ the case, this section deals mostly useful tactics for
+ user-directed documentation.
+
+
+
+ A combination of tradition and necessity has resulted in a
+ semi-regular system of documentation in most free software
+ projects that is worth following. Both users and developers expect
+ to be able to get documentation in several ways and it's essential
+ that you provide the information they are seeking in a form they
+ can read if your project is ever going to get off the
+ ground. People have come to expect:
+
+
+
+ Man pages
+
+ Your users will want to be able to type man
+ projectname end up with a nicely formatted man page
+ highlighting the basic use of yourapplication. Make sure that
+ before you release your program, you've planned for this.
+
+
+
+ Man pages are not difficult to write. There is excellent
+ documentation on the man page writing process available through the
+ The Linux Man-Page-HOWTO available through the
+ Linux Documentation project (LDP) written by
+ Jens Schweikhardt. It is available from
+ Schweikhardt's site or from the
+ LDP.
+
+
+
+ It is also possible to write man pages using DocBook SGML and
+ convert them into man pages. Because man pages are so simple and
+ the DocBook method relatively new, I have not been able to follow
+ this up but would love help from anyone who can give me more
+ information on how exactly this is done.
+
+
+
+
+ Command line accessible documentation
+
+
+ Most users will expect some basic amount of documentation to be
+ easily available from the command line. For few programs should
+ this type of documentation extend for more than one screen (24 or
+ 25 lines) but it should cover the basic usage, a brief (one or
+ two sentence) description of the program, a list of the commands
+ with explanations, all the major options (also with
+ explanations), and a pointer to more in-depth documentation for
+ those who need it. The command line documentation for Debian's
+ apt-get serves as an excellent example and a useful model:
+
+
+
+apt 0.3.19 for i386 compiled on May 12 2000 21:17:27
+Usage: apt-get [options] command
+ apt-get [options] install pkg1 [pkg2 ...]
+
+apt-get is a simple command line interface for downloading and
+installing packages. The most frequently used commands are update
+and install.
+
+Commands:
+ update - Retrieve new lists of packages
+ upgrade - Perform an upgrade
+ install - Install new packages (pkg is libc6 not libc6.deb)
+ remove - Remove packages
+ source - Download source archives
+ dist-upgrade - Distribution upgrade, see apt-get(8)
+ dselect-upgrade - Follow dselect selections
+ clean - Erase downloaded archive files
+ autoclean - Erase old downloaded archive files
+ check - Verify that there are no broken dependencies
+
+Options:
+ -h This help text.
+ -q Loggable output - no progress indicator
+ -qq No output except for errors
+ -d Download only - do NOT install or unpack archives
+ -s No-act. Perform ordering simulation
+ -y Assume Yes to all queries and do not prompt
+ -f Attempt to continue if the integrity check fails
+ -m Attempt to continue if archives are unlocatable
+ -u Show a list of upgraded packages as well
+ -b Build the source package after fetching it
+ -c=? Read this configuration file
+ -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
+See the apt-get(8), sources.list(5) and apt.conf(5) manual
+pages for more information and options.
+
+
+
+ It has become a GNU convention to make this type of information
+ accessible with the -h and the
+ --help options. Most GNU/Linux users will expect
+ to be able to retrieve basic documentation these ways so if you
+ choose to use different method, be prepared for the flames and
+ for the fallout that may result.
+
+
+
+
+ Files users will expect
+
+ In addition to man pages and command-line help, there are certain
+ files where people will look for documentation, especially in any
+ package containing source code. In a source distribution, most of
+ these files can be stored in a the root directory of the source
+ distribution or in a subdirectory of the root called
+ doc or Documentation. Common files
+ places in these places include:
+
+
+
+
+
+ README or Readme
+
+
+ A document containing all the basic installation,
+ compilation, and even basic use instructions that make up the
+ bare minimum information needed to get the program up and
+ running. A README is not your chance to be verbose but needs
+ to be concise and effective. An ideal README is at least 30
+ lines long and more no more than 250.
+
+
+
+
+ INSTALL or Install
+
+
+ The INSTALL file should be much shorter than the README
+ file and should quickly and concisely describe how to build
+ and install the program. Usually an INSTALL file simply
+ instructs the user to run ./configure; make; make
+ install and touches on any unusual options or actions
+ that may be necessary. More advanced users can usually avoid
+ INSTALL files but it's good practice to at least glance at one
+ to understand what can be expected. For most relatively
+ standard install procedures and for most programs, INSTALL
+ files are as short as possible are rarely over 100
+ lines.
+
+
+
+
+ Changelog, ChangeLog, CHANGELOG, or changelog
+
+
+ A changelog is a simple file that every well-managed
+ free software project should include. A changelog is simple
+ the file that, as its name implies, logs or documents the
+ changes to a program. The most simple way to do a changelog is
+ to simply keep a file with the source code for your program
+ and add a section to the top of the changelog with each
+ release describing what has been, changed, fixed, or added to
+ the program. It's a good idea to post the changelog onto the
+ website as well because it can help people decide whether they
+ want or need to upgrade to a newer version or wait for a more
+ significant upgrade.
+
+
+
+
+ NEWS
+
+
+ A NEWS file and a ChangeLog are similar. A news file is
+ not typically sorted by version but just whenever new features
+ are added, the developer responisble will make a note in the
+ NEWS file. NEWS files should not have to changed before a
+ release (they should be kept up to date all along) but it's
+ usually a good idea to check first anyway because often people
+ just forget to keep them as current as they should.
+
+
+
+
+ FAQ
+
+
+ For those of you that don't already
+ know. FAQ stands for Frequently Asked
+ Questions and a FAQ is a collection of exactly that. FAQs
+ are not difficult to make. Simply make a policy that if you
+ are asked a question or see a question on a mailing list two
+ or more times, add it the question (and its answer) to your
+ FAQ. FAQs are more optional than the files listed above but
+ they can save your time, increase usability, and decrease
+ headaches on all sides.
+
+
+
+
+
+
+
+
+ Website
+
+ It's only idirectly an issue of documentation but a good website
+ is quickly becoming an essential part of any free software
+ project's documentation. Your website should provide access to
+ documentation (in HTML if possible). It should
+ also include a section for news and events around your program
+ and a section that details the process of getting involved with
+ development or testing and creates an open invitation. It should
+ also supply links to any mailing lists, similar websites, and
+ provide a direct link to all the available ways of downloading
+ your software.
+
+
+
+
+ Other documentation hints
+
+
+ It doesn't hurt to distribute any documentation for your program
+ from your website or anywhere else (FAQs etc) with the
+ program. Make a FAQ by cutting and posting common questions and
+ answers from a mailing list or your own email. Then, don't
+ hesitate through this in the programs tarball. If people don't
+ need it, they will delete it. I can repeat it over and over:
+ Too much documentation is not a sin.
+
+
+
+ All your documentation should be in plaintext, or, in cases where
+ it is on your website primarily, in HTML. Everyone can cat a
+ file, everyone has a pager, (almost) everyone can render
+ HTML. You are welcome to distribute information in PDF,
+ PostScript, RTF, or any number of other widely used formats but
+ this information must also be available in plaintext or HTML or
+ people will be very angry at you.
+
+
+
+
+
+
+
+ Other Presentation Issues
+
+ Many of the remaining issues surrounding the creation of a new
+ free software program fall under what most people describe as
+ common sense issues. Still, they are worth noting briefly in
+ hopes that they may remind a developer of something they may have
+ forgotten.
+
+
+
+ Package formats
+
+ Package formats may differ depending on the system you are
+ developing for. For windows based software, Zip archives (.zip)
+ usually serve as the package format of choice. If you are
+ developing for GNU/Linux, *BSD, or any UN*X, make sure that your
+ source code is always available in tar'ed and gzip'ed format
+ (.tar.gz). UNIX compress (.Z) has gone out of style and
+ usefulness and faster computers have brought bzip2 (.bz2) into
+ the spot-lit as a more effective compression medium. I now make
+ all my releases available in both gzip'ed and bzip2'ed formats.
+
+
+
+ Binary packages are largely distribution specific. You can build
+ binary packages against a current version of a major
+ distribution, you will only make your users happy. Try to foster
+ relationships with users or developers of large distribution to
+ develop a system for consistent binary packages. It's often a
+ good idea to provide RedHat RPM's (.rpm),
+ Debian deb's (.deb) and source RPM's
+ SRPM's. Binary packages can also be compiled
+ against a specified system with specified libraries and
+ distributed in tar.gz format as well. Remember: While
+ these binaries packages are nice, getting the source packaged and
+ released should always be your priority. Your users or fellow
+ developers can and will do the the binary packages for
+ you.
+
+
+
+
+ Useful tidbits and presentation hints
+
+
+ Other useful hints include:
+
+
+
+
+
+
+
+ Make sure that your program can always be found in a
+ single location. Often this means that you have a
+ single directory accessible via FTP or
+ HTTP where the newest version will be
+ quickly recognized. One effective technique is a provide a
+ symlink called projectname-latest that is
+ always pointing to the most recent released or development
+ version of your free software project. Keep in mind that this
+ location will recieve many requests for downloads around
+ releases so make sure that the server you choose for this
+ purpose has adequate bandwidth.
+
+
+
+
+
+ Make sure that there is a consistent email address
+ for bug reports. It's usually a good idea to make
+ this something that is NOT your primary email address like
+ projectname@host or projectname-bugs@host. This way if you
+ ever decide to hand over maintainership or if your email
+ address changes, you simply need to change where this email
+ address forwards. It also will allow for more than one person
+ to deal with the influx of mail that is created if your
+ project becomes as huge as you hope it will.
+
+
+
+
+
+
+
+ A version control system can make a lot of these problems of
+ packaging (and a lot of other problems mentioned in this HOWTO)
+ much easier. If you are using *NIX, CVS is your best bet. I
+ recommend Karl Fogel's book on the subject (and the posted HTML version)
+ wholeheartedly.
+
+
+
+ CVS or not, you should probably invest some time into learning
+ about a version control system because it provides an automated
+ way of solving many of the problems introduced into this HOWTO.
+ I am not aware of any free version control systems for windows or
+ mac but I know that CVS clients exist for both
+ platforms. Websites like SourceForge do a great job
+ as well with a nice, easy to use interface to CVS.
+
+
+
+ I'd love to devote more space in this HOWTO to CVS because I love
+ it (I even use CVS to keep version straight on this HOWTO!) but I
+ think it falls outside the scope of this document and should/has
+ already have its own HOWTO written about it.
+
+
+
+
+
+
+
+
+
+
+ Maintaining a Project: Interacting with Developers
+
+ fswd!developers
+
+
+
+ Once you have gotten your project started, you have overcome the
+ most difficult hurdles in the development process of your
+ program. Laying a firm foundation is essential, but the development
+ process itself is equally important and provides quite a few
+ opportunities for failure. In the next two sections, I will cover
+ running a project by discussing how to maintain a project through
+ interactions with developers and with users.
+
+
+
+ In releasing your program, your program becomes free software. This
+ transition is more than just a larger user base. By releasing your
+ program as free software, your software
+ becomes the free software community's
+ software. The direction of your software's development will be
+ reshaped, redirected, and fully determined by your users and, to a
+ larger extent, by other developers in the community.
+
+
+
+ The major difference between free software development and
+ propriety software development is the developer base. As the leader
+ of a free software project, you need to attract and keep developers
+ in a way that leaders of proprietary software projects simply don't
+ have to worry about. As the person leading development of
+ a free software project, you must harness the work of fellow
+ developers by making responsible decisions and by responsibly
+ choosing not to make decisions. You have to direct developers
+ without being overbearing or bossy. You need to strive to earn
+ respect and never forget to give it out.
+
+
+
+
+
+ Delegating Work
+
+
+ By now, you've hypothetically followed me through the early
+ programming of a piece of software, the creation of a website and
+ system of documentation and and we've gone ahead and (as will be
+ discussed in ) released it to the rest
+ of the world. Times passes, and if things go well, people become
+ interested and want to help. The patches begin flowing in.
+
+
+
+ Like the parent of any child who grows up, it's now time
+ to wince and smile and do most difficult thing in any parents
+ life: It's time to let go.
+
+
+
+ Delegation is the political way of describing this process of
+ letting go. It is the process of handing some of
+ the responsibility and power over your project to other responsible
+ and involved developers. It is difficult for anyone who has
+ invested a large deal of time and energy into a project but it
+ essential for the growth of any free software project. One person
+ can only do so much. A free software project is nothing
+ without the involvement of a group of developers. A group of
+ developers can only be maintained through respectful and
+ responsible leadership and delegation.
+
+
+
+ As your project progresses, you will notice people who are putting
+ significant amounts of time and effort into your project. These
+ will be the people submitting the most patches, posting most on
+ the mailing lists, engaging in long email discussions. It is your
+ responsibility to contact these people and to try and shift some of
+ the power and responsibility of your position as the project's
+ maintainer onto them (if they want it). There are several easy
+ ways you can do this:
+
+
+
+ In a bit of a disclaimer, delegation need not mean rule by
+ comittee. In many cases it does and this has been proven to
+ work. In other cases this has been the death of a project. Managing
+ Projects the Open Source Way argues that OSS
+ projects do best when one person is the clear leader of a team and
+ makes the big decisions (design changes, release dates, and so
+ on). I think this often true but would urge developers to
+ consider the ideas that the project leader need not be the
+ projects founder and that these important powers need not all rest
+ in one person but that a release manager may be different than a
+ lead developer. These situations are tricky politically though so
+ be careful and make sure this is necessary before you go around
+ empowering people.
+
+
+
+ How to delegate
+
+
+ You may find that other developers seem even more experienced or
+ knowledgeable than you. Your job as a maintainer does not mean
+ you have to have to be the best or the brightest. It means you
+ need are responsible for showing good judgment and for
+ recognizing which solutions are maintainable and which are not.
+
+
+ Like anything, its easier to watch others delegate than to do it
+ yourself. In a sentence: Keep an eye out for other
+ qualified developers who show an interest and sustained
+ involvement with your project and try and shift responsibility
+ towards them. The following ideas might be good places
+ to start or good sources of inspiration:
+
+
+
+ Allow a larger group of people write access to your CVS
+ repository and make real efforts towards rule by a
+ committee
+
+
+ Apache is an
+ example of a project that is run by small group of developers
+ who vote on major technical issues and the admission of new
+ members and all have write access to the main source
+ repository. Their process is detailed online.
+
+
+
+ The Debian Project
+ is an extreme example of rule by committee. At current count,
+ more than 700 developers have full responsibility for certain
+ aspects of the projects. All these developers can upload into
+ the main FTP servers, and vote on major issues. Direction for
+ the project is determined by the project's social
+ contract and a constitution. To
+ facilitate this system, there are special teams (i.e. the
+ install team, the Japanese language team) as well as a technical
+ committee and a project leader. The leader's main responsibility
+ is to, Appoint Delegates or delegate decisions to the
+ Technical Committee.
+
+
+
+ While both of these projects operate on a scale that your
+ project will not (at least initially), their example is
+ helpful. Debian's idea of a project leader who can do
+ nothing but delegate serves as a
+ caricature of how a project can involve and empower a huge
+ number of developers and grow to a huge size.
+
+
+
+
+
+ Publicly appoint someone as the release manager for a
+ specific release.
+
+
+ A release manager is usually responsible for coordinating
+ testing, enforcing a code freeze, being responsible for
+ stability and quality control, packaging up the software, and
+ placing it in the appropriate places to be downloaded.
+
+
+
+ This use of the release manager is a good way to give yourself a
+ break and to shift the responsibility for accepting and
+ rejecting patches to someone else. It is a good way of very
+ clearly defining a chunk of work on the project as belonging to
+ a certain person and its a great way of giving yourself room to
+ breath.
+
+
+
+
+ Delegate control of an entire branch.
+
+ If your project chooses to have branches (as described in ), it might be a good idea to appoint someone
+ else to be the the head of a branch. If you like focusing your
+ energy on development releases and the implementation of new
+ features, hand total control over the stable releases to a
+ well-suited developer.
+
+
+
+ The author of Linux, Linus Torvalds, came out and crowned Alan
+ Cox as the man for stable kernels. All patches
+ for stable kernels go to Alan and, if Linus were to be taken
+ away from work on Linux for any reason, Alan Cox would be more
+ than suited to fill his role as the acknowledged heir to the
+ Linux maintainership.
+
+
+
+
+
+
+
+
+ Accepting and Rejecting Patches
+
+ This HOWTO has already touched on the fact that as the maintainer
+ of a free software project, one of primary and most important
+ responsibilities will be accepting and rejecting patches submitted
+ to you by other developers.
+
+
+
+ Technical judgment
+
+
+ In Open Source Development with CVS, Karl
+ Fogel makes a convincing argument that the most important things
+ to keep in mind when rejecting or accepting patches are:
+
+
+
+
+
+
+ A firm knowledge of the scope of your program (that's the
+ idea I talked about in );
+
+
+
+ The ability to recognize, facilitate, and direct
+ evolution of your program so that the program
+ can grow and change and incorporate functionality that was
+ originally unforeseen;
+
+
+
+ The necessity to avoid digressions that might expand the
+ scope of the program too much and result and push the project
+ towards an early death under its own weight and
+ unwieldiness.
+
+
+
+
+
+
+ These are the criteria that you as a project maintainer should
+ take into account each time you receive a patch.
+
+
+
+ Fogel elaborates on this again and states the the
+ questions to ask yourself when considering whether to implement
+ (or approve) a change are:
+
+
+
+
+
+
+ Will it benefit a significant percentage of the program's
+ user community?
+
+
+
+ Does it fit within the program's domain or within a
+ natural, intuitive extension of that domain?
+
+
+
+
+
+
+ The answers to these questions are never straightforward and its
+ very possible (and even likely) that the person who submitted the
+ patch may feel differently about the answer to those questions
+ than you do. However, if you feel that that the answer to either
+ of those questions is no, it is your responsibility
+ to reject the change. If you fail to do this, the project will
+ become unwieldy and unmaintainable and will ultimately fail.
+
+
+
+
+ Rejecting patches
+
+
+ Rejecting patches is probably the most difficult and the most
+ sensitive job that the maintainer of any free software project
+ has to face. But sometimes it has to be done. I mentioned earlier
+ (in and in ) that any developer needs to try and
+ balance your responsibility and power to make what you think are
+ the best technical decisions with the fact that you will lose
+ support from other developers if you seem like you are on a power
+ trip or being overly bossy or possessive of a community-based
+ project. I recommend that you keep three major facts in mind when
+ rejecting patches (or other changes):
+
+
+
+ Bring it to the community
+
+ One of the best ways of justifying a decision to reject a patch
+ and working to not seem like you keep an iron grip on your
+ project is by not making the decision alone at all. It might
+ make sense to turn over larger proposed changes or more
+ difficult decisions to a development mailing list where they can
+ be discussed. There will be some patches (bug fixes, etc.) which
+ will definitely be accepted and some that you feel are so off
+ base that they do not even merit further discussion. It is those
+ that fall into the grey area between these two groups that might
+ merit a quick forward to a mailing list.
+
+
+
+ I recommend this process wholeheartedly. As the project
+ maintainer you are worried about making the best decision for
+ the project, for the project's users and developers, and for
+ yourself as a responsible project leader. Turning things over to
+ an email list will demonstrate your own responsibility and
+ responsive leadership as it tests and serves the interests of
+ your software's community.
+
+
+
+
+ Technical issues are not always good justification
+
+ Especially towards the beginning, you will find that many
+ changes are difficult to implement, introduce new bugs, or have
+ other technical problems. Try to see past these. Especially with
+ added functionality, good ideas do not always come from good
+ coders. Technical merit is a valid reason to postpone an
+ application of a patch but it is not always a good reason to
+ reject a change outright. Even small changes are worth the
+ effort of working with the developer submitting the patch to
+ iron out bugs and incorporate the change if you thing you think
+ it seems like a good addition to your project. The effort on
+ your part will work to make your project a community project and
+ it will pull a new or less experienced developer onto your
+ project and even teach them something that might help them in
+ making their next patch.
+
+
+
+
+ Common courtesy
+
+ It should go without saying but, above all and in all
+ cases, just be nice. If someone has an idea and cares
+ about it enough to write some code and submit a patch, they
+ care, they are motivated, and they are already involved. Your
+ goal as the maintainer is make sure they submit again. They may
+ have thrown you a dud this time but next time may be the idea or
+ feature that revolutionizes your project.
+
+
+
+ It is your responsibility to first justify your choice to not
+ incorporate their change clearly and concisely. Then thank
+ them. Let them know that you a appreciate their help and feel
+ horrible that you can't incorporate their change. Let them know
+ that you look forward to their staying involved and you hope
+ that the next patch or idea meshes better with your project
+ because you appreciate their work and want to see it in the
+ project. If you have ever had a patch rejected after putting a
+ large deal of time, thought, and energy into it, you remember
+ how it feels and it feels bad. Keep this in mind when you have
+ to let someone down. It's never easy but you need to do
+ everything you can to make it as not-unpleasant as possible.
+
+
+
+
+
+
+
+
+ Stable and Development Branches
+
+
+ The idea of stable and development branches has already been
+ described briefly in and in
+ . These allusions attest to some of
+ the ways that multiple branches can affect your software. Branches
+ can let you avoid (to some extent) some of the problems around
+ rejecting patches (as described in ) by
+ allowing you to temporarily compromise the stability of your
+ project without affecting those users who need that stability.
+
+
+
+ The most common way of branching your project is to have one
+ branch that is stable and one that is for development. This is the
+ model followed by the Linux kernel that is described in . In this model, there is always one
+ branch that is stable and always one that is in
+ development. Before any new release, the development branch goes
+ into a feature freeze as described in where major changes and added features are
+ rejected or put on hold under the development kernel is released
+ as the new stable branch and major development resumes on the
+ development branch. Bug fixes and small changes that are unlikely
+ to have any large negative repercussions are incorporated into the
+ stable branch as well as the development branch.
+
+
+
+ Linux's model is an extreme one. On many projects, there is no
+ need to have two versions always available. It may make sense to
+ have two versions only near a release. The Debian project has
+ historically made both a stable and an unstable distribution
+ available but has expanded to this to include: stable, unstable,
+ testing, experimental, and (around release time) a frozen
+ distribution that only incorporates bug fixes during the
+ transition from unstable to stable. There are few projects whose
+ size would necessitate a system like Debian's but this use of
+ branches helps demonstrate how they can be used to balance
+ consistent and effective development with the need to make regular
+ and usable releases.
+
+
+
+ In trying to set up a development tree for yourself, there are
+ several things that might be useful to keep in mind:
+
+
+
+
+
+
+ Minimize the number of branches
+
+ Debian may be able to make good use of four or five
+ branches but it contains gigabytes of software in over 5000
+ packages compiled for a 5-6 different architectures. For you,
+ two is probably a good number. Too many branches will confuse
+ your users (I can't count how many times I had to describe
+ Debian's system when it only had 2 and sometimes 3 branches!),
+ potential developers and even yourself. Branches can help but
+ they come at a cost so use them very sparingly.
+
+
+
+
+ Make sure that all your different branches are explained
+
+ As I mentioned in the preceding paragraph, different
+ branches will confuse your users. Do
+ everything you can to avoid this by clearly explaining the
+ different branches in a prominent page on your website and in a
+ Readme file in the FTP or
+ HTTP directory.
+
+
+ I might also recommend against a mistake that I think Debian
+ has made. The terms unstable,
+ testing, and experimental are
+ vague and difficult to rank in order of stability (or
+ instability as the case may be). Try explaining to someone
+ that stable actually means ultra
+ stable and that unstable doesn't
+ actually include any unstable software but is really stable
+ software that is untested as a distribution.
+
+
+
+ If you are going to use branches, especially early on, keep in
+ mind that people are conditioned to understand the terms
+ stable and development and you
+ probably can't go wrong with this simple and common division of
+ branches.
+
+
+
+
+
+ Make sure all your branches are always available
+
+ Like a lot of this document, this should probably should
+ go without saying but experience has taught me that it's not
+ always obvious to people. It's a good idea to physically split
+ up different branches in different directories or directory
+ trees on your FTP or HTTP
+ site. Linux accomplishes this by having kernels in a v2.2 and a
+ v2.3 subdirectory where it is immediately obvious (after you
+ know their version numbering scheme) which directory is for the
+ most recent stable and the current development releases. Debian
+ accomplishes this by naming all their distribution with names
+ (i.e. woody, potato, etc.) and then changing symlinks named
+ stable,unstable and
+ frozen to point to which ever distribution (by
+ name) is in whatever stage. Both methods work and there are
+ others. In any case, it is important that different branches
+ are always available, are accessible from consistent locations,
+ and that different branches are clearly distinguished from each
+ other so your users know exactly what they want to be
+ downloading and where to get it.
+
+
+
+
+
+
+
+
+
+
+
+ Other Development issues
+
+ There are more issues surrounding interaction with developers in a
+ free software project that I can not touch on in great detail in a
+ HOWTO of this size. Please don't hesitate to contact me if you see
+ any major omissions.
+
+
+
+ Other smaller issues that are worth mentioning are:
+
+
+
+ Freezing
+
+ For those projects that choose to adopt a split development model
+ (), freezing is a concept that is worth
+ becoming familiar with.
+
+
+
+ Freezes come in two major forms. A feature freeze
+ is a period when no significant functionality is added to a
+ program. It is a period where established functionality (even
+ skeletons of barely working functionality) can be improved and
+ perfected. It is a period where bugs are fixed. This type of
+ freeze is usually applied some period (a month or two) before a
+ release. It is easy to push a release back as you wait for
+ one more feature and a freeze helps to avoid this
+ situation by drawing the much needed line in the sand. It gives
+ developers room they need to get a program ready for release.
+
+
+
+ The second type of freeze is a code freeze which
+ is much more like a released piece of software. Once a piece of
+ software has entered a code freeze, all changes to the code are
+ frowned upon and only changes that fix known bugs are
+ permitted. This type of freeze usually follows a feature
+ freeze and directly precedes a release. Most released
+ software is in what could be interpreted as a sort of high
+ levelcode freeze.
+
+
+
+ Even if you never choose to appoint a release manager (), you will have an easier time
+ justifying the rejection or postponement of patches ( before a release with a publicly stated
+ freeze in effect.
+
+
+
+
+ Forking
+
+ Forks are the most extreme version of a branch. A fork is
+ when a group of developers takes code from a free software
+ project and actually starts a brand new free software
+ project. The most famous example of a fork is Emacs and
+ XEmacs. Both emacsen are based on an almost identical code-base
+ but for technical, political, and philosophical reasons,
+ development was split into two projects which now compete with
+ each other.
+
+
+
+ The short version of the fork section is, don't do
+ them. Forks force developers to choose one project to
+ work with, cause nasty political divisions and redundancy of
+ work. Luckily, usually the threat of the fork is enough to scare
+ the maintainer or maintainers of a project into changing the way
+ they run their project to avoid it.
+
+
+
+ In his chapter on The Open Source Process, Karl
+ Fogel describes how to do a fork if you absolutely must. If you
+ have determined that is absolutely necessary and that the
+ differences between you and the people threatening to fork are
+ absolutely unresolvable, I recommend Fogel's book as a good place
+ to start.
+
+
+
+
+
+
+
+
+ Maintaining a Project: Interacting with Users
+
+ fswd!users
+
+
+
+ If you've worked your way up to here, congratulations, you are
+ nearing the end of this document. This final section describes some
+ of the situations in which you, in your capacity as project
+ maintainer, will be interacting with users. It gives some
+ suggestions on how these situations might be handled effectively.
+
+
+
+ Interacting with users is difficult. In our discussion of
+ interaction with developers, the underlying assumption is that in a
+ free software project, a project maintainer must constantly strive to
+ attract and keep developers who can easily leave at any time.
+
+
+
+ Users in the free software community are different than developers
+ and are also different than users in the world of proprietary
+ software and they should be treated differently than either
+ group. Some ways in which the groups differ significantly follow:
+
+
+
+
+
+
+ The lines between users and developers are blurred in ways
+ that is totally foreign to any proprietary development
+ model. Your users are often your developers and vice
+ versa.
+
+
+
+ In the free software world, you are often your users only
+ choice. Because there is such an emphasis on not replicating the
+ work of others in the free software community and because the
+ element of competition present in the propriety software model is
+ absent (or at least in an extremely different form) in the free
+ software development model, you will probably be the only project
+ that does what you do (or at least the only one that does what
+ you do in the way that you do it). This means your responsiveness
+ to your users is even more important than in the proprietary
+ software world.
+
+
+
+ In an almost paradoxical situation, free software projects
+ have less immediate or dire consequences for ignoring their users
+ altogether--it is also often easier to do. Because you don't
+ usually need to compete with another product in the free software
+ model, chances are good that you will not be scrambling to gain
+ the features of the competitor's newest program. This means that
+ your development process will have to be directed either
+ internally, by a commitment to your users or by both.
+
+
+
+
+
+ Trying to tackle this unique situation can only be done
+ indirectly. Developers and maintainers need to listen to users and
+ to try and be as responsive as possible. A solid knowledge of the
+ situation recounted above is any free software developer's best tool
+ for shifting his development or leadership style to fit the unique
+ process of free software development. This chapters will try and
+ introduce some of the more difficult or important points in any
+ projects interactions with users and give some hints on how to
+ tackle these.
+
+
+
+
+
+ Testing and Testers
+
+
+ In addition to your users being your developers, they are also
+ (and perhaps more commonly) your testers. Before I get flamed, I
+ should rephrase my sentence: some of your
+ users are your testers.
+
+
+
+ It is important that this distinction be made early on because not
+ all of your users want to be testers. Many users want to use
+ stable software and don't care if they don't have the newest
+ greatest software with the latest and greatest features. These
+ users except a stable, tested piece of software with major or
+ obvious bugs worked out or openly declared and will be angry if
+ they find themselves in a testing position. This is yet another
+ way in which a split development model (as mentioned in ) might come in handy.
+
+
+
+ Managing
+ Projects the Open Source Way describes what a good test
+ should look for in each module:
+
+
+
+
+ Boundary conditions
+
+
+
+ Maximum buffer lengths, data conversions, upper/lower boundary
+ limits, and so on.
+
+
+
+
+
+ Inappropriate behavior
+
+
+
+ Its a good idea to find out what a program will do if a user
+ hands it a value it isn't expecting, hits the wrong button,
+ etc. Ask yourself a bunch of what if questions and think of
+ anything that might fail or
+ might go wrong and find out what program
+ would do in that case.
+
+
+
+
+
+ Graceful failure
+
+
+
+ The answer to a number of the what if questions
+ above is probably failure which is often the
+ only answer. Now make sure that it happens nicely. Make sure
+ that when it crashes, there is some indication of why it
+ crashed or failed so that the user or developer understands
+ whats going on.
+
+
+
+
+
+
+ Standards conformance
+
+
+
+ If possible, make sure your programs conforms to
+ standards. Don't be too creative with interfaces. If it is
+ non-interactive, make sure it communicates over appropriate and
+ established channels with other programs and with the rest of
+ the system.
+
+
+
+
+
+
+
+ Automated testing
+
+ For many programs, many common mistakes can be caught by
+ automated means. Automated tests tend to be pretty good at
+ catching errors that you've run into several times before or
+ something you just forget. They are not very good at finding
+ errors, even major ones, that were totally unforeseen.
+
+
+
+ CVS comes with a bourne shell script called sanity.sh that is
+ worth looking at. Debian uses a program called lintian that
+ checks Debian packages for all of the most common errors. While
+ use of these scripts may not be possible, there is a host of
+ other sanity checking software on the net that may be applicable
+ (feel free to email any recommendations). None of these will
+ create a bug-free release but they will avoid at least some major
+ oversights. Finally, if your programs become a long term
+ endeavor, you will find that there are certain errors that you
+ tend to make over and over. Start a collection of scripts that
+ check for these errors to help prevent them in the future.
+
+
+
+
+ Testing by testers
+
+ For any program that depends on user interactivity, many bugs
+ will only be uncovered through testing by users actually clicking
+ the keys and pressing the mouse buttons. For this you need
+ testers and as many testers as possible.
+
+
+
+ The most difficult part of testing is finding testers. It's
+ usually a good tactic to post a message to a relevant mailing
+ list or news group announcing a specific proposed release date
+ and outline the functionality of the program. If you put some
+ time into the announcement, you are sure to get a few bites.
+
+
+
+ The second most difficult part of testing is keeping your testers
+ and keeping them actively involved in the testing
+ process. Fortunately, there are some tried and true tactics that
+ can applied towards this end:
+
+
+
+
+
+
+ Make things simple for your testers
+
+ Your testers are doing you a favor so make it as easy as
+ possible for them. This means that you should be careful to
+ package your software in a way that is easy to find, unpack,
+ install, and uninstall. This also means you should explain
+ what you are looking for to each tester and make the means for
+ reporting bugs simple and well established. The key is to
+ provide as much structure as possible to make your testers'
+ jobs easy and maintain as much flexibility as possible for
+ those that want to do things a little differently.
+
+
+
+
+ Be responsive to your testers
+
+ When your testers submit bugs, respond to them and
+ respond quickly. Even if you are only responding to tell them
+ that the bug has already been fixed, quick and consistent
+ responses make them feel like their work is heard, important,
+ and appreciated.
+
+
+
+
+ Thank your testers
+
+ Thank them personally each time they send you
+ patch. Thank them publicly in the documentation and the about
+ section of your program. You appreciate your testers and your
+ program would not be possible without their help. Make sure
+ they know it. Pat them on the back to make sure the rest of
+ the world knows it too. It will be appreciated more than you
+ expected.
+
+
+
+
+
+
+
+
+
+
+
+
+ Setting up Support Infrastructure
+
+
+ While testing is important, the large part of your interactions
+ and responsibility to your users falls under the category of
+ support. The best way to make sure your users are adequately
+ supported in using your program is to set up a good infrastructure
+ for this purpose so that your developers and users help each other
+ and less of the burden falls on you. This way, people will also
+ get quicker and better responses to their questions. This
+ infrastructure comes in several major forms:
+
+
+
+ Documentation
+
+ It should not come as any surprise that the key element to any
+ support infrastructure is good documentation. This topic was
+ large covered in and will not be
+ repeated here.
+
+
+
+
+ Mailing lists
+
+ Aside from documentation, effective mailing lists will be your
+ greatest tool in providing user support. Running a mailing list
+ well is more complicated than installing mailing list software
+ onto a machine.
+
+
+
+ Separate lists
+
+
+ A good idea is too separate your user and development mailing
+ lists (perhaps into project-user@host and project-devel@host)
+ and enforce the division. If people post a development question
+ onto -user, politely ask them to repost it onto -devel and vise
+ versa. Subscribe yourself to both groups and encourage all
+ primarily developers to do the same.
+
+
+
+ This system provides that no one person is stuck doing all of
+ the support work and works so that users learn more about the
+ program, they can help newer users with their questions.
+
+
+
+
+ Choose mailing list software well
+
+ Please don't make the selection of mailing list software
+ impulsively. Please consider easy accessibility by users without
+ a lot of technical experience so you want to be as easy as
+ possible. Web accessibility to an archive of the list is also
+ important.
+
+
+
+ The two biggest free software mailing list programs are majordomo
+ and GNU Mailman. A
+ long time advocate of majordomo, I would now recommend any
+ project choose GNU Mailman. It fulfills the criteria listed
+ above and makes it easier to do so. It provides a good mailing
+ list program for a free software project maintainer as opposed
+ to a good mailing list application for a mailing list
+ administrator.
+
+
+
+ There are other things you want to take in setting up your
+ list. If it is possible to gate your mailing lists to USENET and
+ provide them in digest form as well as making them accessible on
+ the web, you will please some users and work to make the support
+ infrastructure slightly more accessible.
+
+
+
+
+
+ Other support ideas
+
+
+ A mailing list and accessible documentation are far from all you
+ can do to set up good user support infrastructure. Be
+ creative. If you stumble across something works well, email me
+ and I'll include it here in the HOWTO.
+
+
+
+ Make your self accessible
+
+ You can not put to few methods to access you. If you hang out in
+ an IRC channel, don't hesitate to list in
+ your projects documentation. List email and snail mail
+ addresses, or ways to reach you via ICQ,
+ AIM, or Jabber.
+
+
+
+
+ Bug management software
+
+ For many large software projects, use of bug management software
+ is essential to keep track of which bugs have been fixed, which
+ bugs have not been fixed, and which bugs are being fixed by
+ which people. Debian uses the Debian Bug Tracking System
+ (BTS) although it may not be best choice for
+ every project (it seems to currently be buckling under its own
+ weight. As well as a damn good web browser, the mozilla project
+ has spawned a sub-project resulting in a bug tracking system
+ called bugzilla
+ which has become extremely possible and which I like quite a
+ bit.
+
+
+
+ These systems (and others like them) can be unwieldy so
+ developers should be careful to not spend more time on the bug
+ tracking system than on the bugs or the projects themselves. If
+ a project continues to grow, use of a bug tracking system can
+ provide an easy standard way for users and testers to report
+ bugs and for developers and maintainers to fix them and track
+ them in an orderly fashion.
+
+
+
+
+
+
+
+
+ Releasing Your Program
+
+
+ As mentioned earlier in the HOWTO, the first rule of releasing is,
+ release something useful. Non-working or
+ not-useful software will not attract anyone to your
+ project. People will be turned off of your project and be likely
+ to simply gloss over it next time they see a new version
+ announced. Half-working software, if useful, will intrigue people,
+ whet their appetites for versions to come, and encourage them to
+ join the development process.
+
+
+
+ When to release
+
+
+ Making the decision to release your software for the first time
+ is an incredibly important and incredibly stressful decision. But
+ it needs to be done. My advice is to try and make something that
+ is complete enough to be usable and incomplete enough to allow
+ for flexibility and room for imagination by your future
+ developers. It's not an easy decision. Ask for help on a local
+ Linux User Group mailing list or from a group of developer
+ friends.
+
+
+
+ One tactic is to first do an alpha or
+ beta release as described below in . However, most of the guidelines described
+ above still apply.
+
+
+
+ When you feel in your gut it is time and you feel
+ you've weighed the situation well several times, cross your
+ fingers and take the plunge.
+
+
+
+ After you've released for the first time, knowing when to release
+ becomes less stressful, but just as difficult to gauge. I like
+ the criteria offered by Robert Krawitz in his article, Free
+ Software Project Management for maintaining a
+ good release cycle. He recommends that you ask yourself,
+ does this release...
+
+
+
+
+
+ Contain sufficient new functionality or bug fixes to be
+ worth the effort.
+
+
+
+ Be spaced sufficiently far apart to allow the user time
+ to work with the latest release.
+
+
+
+ Be sufficiently functional so that the user can get work
+ done (quality).
+
+
+
+
+
+ If the answer is yes to all of these questions, its probably time
+ for a release. If in doubt, remember that asking for advice can't
+ hurt.
+
+
+
+
+ How to release
+
+
+ If you've followed the guidelines described in this HOWTO up
+ until this point, the mechanics of doing a release are going to
+ be the easy part of releasing. If you have set up consistent
+ distribution locations and the other infrastructure described in
+ the preceding sections, releasing should be as simple as building
+ the package, checking it once over, and uploading it into the
+ appropriate place and then reflecting the release on your
+ website.
+
+
+
+
+ Alpha, beta, and development releases
+
+
+ When contemplating releases, it worth considering the fact that
+ not every release needs to be a full numbered release. Software
+ users are accustomed to pre-releases but you must be careful to
+ label these releases accurately or they cause more problems then
+ they are worth.
+
+
+
+ The observation is often made that many free software developers
+ seem to be confused about the release cycle. Managing
+ Projects the Open Source Way suggests that you memorize
+ the phrase, Alpha is not Beta. Beta is not Release
+ and I'd agree that tis is a probably a good idea.
+
+
+
+
+
+
+ alpha releases
+
+ Alpha software is feature-complete but sometimes only
+ partially functional.
+
+ Alpha releases are expected to be unstable, perhaps a
+ little unsafe, but definitely usable. Alpha versions should
+ have full functionality and limited testing. They can have
+ known bugs and kinks that have yet to be worked out. Before
+ releasing an alpha, be sure to keep in mind that
+ alpha releases are still releases and
+ people are not going to be expecting a nightly build from the
+ CVS source. An alpha should work and have minimal testing and
+ bug fixing already finished.
+
+
+
+
+ beta releases
+
+ Beta software is feature-complete and functional, but is
+ in the testing cycle and still has a few bugs in it.
+
+ Beta releases are general expected to be usable and
+ slightly unstable, although definitely not
+ unsafe. Beta releases usually preclude a full
+ release by under a month. They can contain small known bugs
+ but no major ones. All major functionality should be fully
+ implemented although the exact mechanics can still be worked
+ out. Beta releases are great tool to whet the appetites of
+ potential users by giving them a very realistic view of where
+ your project is going in the very near future and can help
+ keep interest by giving people
+ something.
+
+
+
+
+ development releases
+
+ Development release is much more vague
+ term than alpha or beta. I
+ usually choose to reserve the term for discussion of a
+ development branch although there are other ways to use the
+ term. So many in fact, that I feel the term has been
+ cheapened. The popular window manager Enlightenment has
+ released nothing but development
+ releases. Most often, the term is used to describe releases
+ that are not even to alpha or beta stages though and if I were
+ to release a pre-alpha version of a piece of software in order
+ to keep interest in my project live, this is probably how I
+ would have to label it.
+
+
+
+
+
+
+
+
+
+
+
+
+ Announcing Your Project
+
+
+ Well, you've done it. You've (at least for the purposes of this
+ HOWTO) designed, built, and released your free software
+ project. All that is left is for you to tell the world so they
+ know to come and try it out and hopefully jump on board with
+ development. If everything is in order as described above, this
+ will be a quick and painless process. A quick announcement is all
+ that it takes to put yourself on the free software communities
+ radar screen.
+
+
+
+ Mailing lists and USENET
+
+ Email is still the way that most people on the Internet get their
+ information. Its a good idea to send a message announcing your
+ program to any relevant mailing list you know of and any relevant
+ USENET discussion group. Karl Fogel recommends that use you
+ simple subject describing the fact that the message is an
+ announcement, the name of the program, the version, and a
+ half-line long description of its functionality. This way, any
+ interested user or developer will be immediately attracted to
+ your announcement. Fogel's example looks like:
+
+
+ Subject: ANN: aub 1.0, a program to assemble USENET binaries
+
+
+ The rest of the email should describe the programs functionality
+ quickly and concisely in no more than two paragraphs and should
+ provide links to the projects webpage and direct links to
+ downloads for those that want to try it right away.
+
+
+
+ You should repeat this announcement process consistently in the
+ same locations for each subsequent release.
+
+
+
+
+ freshmeat.net
+
+ Mentioned earlier in , in today's free
+ software community, announcements of your project on freshmeat
+ are almost more important than announcements on mailing lists.
+
+
+
+ Visit the freshmeat.net
+ website or their submit project
+ page to post your project onto their site and into their
+ database. In addition to a large website, freshmeat provides a
+ daily newsletter that highlights all the days releases and
+ reaches a huge audience (I skim it every night for any
+ interesting new releases).
+
+
+
+
+
+
+
+
+ Printed Books
+
+
+
+
+ Fogel
+ Karl
+
+
+ Open Source Development with CVS
+
+
+ Coriolois Open Press
+
+ 1999
+
+ 1-57610-490-7
+
+
+
+ Fogel's Guide to using CVS in the free software
+ world is much more than its subitle. In the publishers
+ own words: Open Source Development with
+ CVS is one of the first books available that teaches
+ you development and implementation of Open Source
+ software. It includes the best reference and tutorial
+ to CVS I have ever seen. It is the book that was so
+ good that it prompted me to write this HOWTO because
+ I thought the information it helped distribute was so important
+ and useful. Please check it or by if you can and are seriously
+ interested in running a free software project.
+
+
+
+
+
+
+
+ Lessig
+ Lawrence
+
+
+ Code and Other Laws of Cyberspace
+
+
+ Basic Books
+
+ 2000
+
+ 0-465-03913-8
+
+
+
+ While it only briefly talks about free software (and does it by
+ tiptoeing around the free software/open source issue with the
+ term open code), Lessig book is
+ brilliant. Written by a lawyer, it talks about how regulation
+ on the Internet is not done with law, but with the code itself
+ and how the nature of the code will determine future
+ freedoms. In addition to being a quick and enjoyable read, it
+ gives some cool history describes how we
+ need free software in a way more
+ powerfully than anything I've read (outside of RMS's
+ Right to Read.
+
+
+
+
+
+
+
+
+ Raymond
+ Eric
+
+
+ The Cathedral and the Bazaar
+ Musings on Linux and Open Source by an Accidental Revolutionary
+
+
+ O'Reilly
+
+ 1999
+
+ 1-56592-724-9
+
+
+ Although I have to honestly say that I am not the ESR fan that
+ I used to be, this book proved invaluable in getting me where I
+ am today. The essay that gives the book its title does a good
+ job sketching the free software process and does an an amazing
+ of job of making an argument for free software/open source
+ development as making better software. The rest of the book has
+ other articles, for the most part posted on his website, but
+ it's nice thing to own in hard copy and something every free
+ software/open source hacker should read.
+
+
+
+
+
+
+
+ Web-Accessable Resources
+
+
+ This is a list of the resources pertaining to this HOWTO that I've
+ found most helpful in compiling this information. If you have
+ more, please don't hesitate to email me at
+ mako@debian.org and we can look into getting it
+ added on the list.
+
+
+
+ I'd recommend that any free software developer (or potential one)
+ skim through these sites becaue they have a lot to say.
+
+
+
+
+
+ Manley
+ Montey
+
+
+ <ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink>
+
+
+ Linux
+ Programming
+
+ Oct 31, 2000
+
+
+
+ In one of the better articles on the subject that I've read,
+ Monty sums up some of the major points I touch on including:
+ starting a project, testing, documenation, orgazing a team and
+ leadership, and several other topics. While more opiniated that
+ I try to be, I think its an important article that I found very
+ helpful in writing this HOWTO and that I've tried to cite it in
+ the places where I borrowed from it most. I have problems with
+ much of the things written in the piece and I recommend you
+ read at the same time you read Monty's
+ article.
+
+
+
+
+
+
+
+
+ Gabriel
+ Richard
+
+
+ <ulink
+ url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
+ <quote>Worse is Better</quote></ulink>
+
+
+
+ A well written article although I think the title may have
+ confused as many people as it helped. It offers a good
+ description of how to design programs that will succeed and
+ stay maintainable as they grow.
+
+
+
+
+
+
+
+ Advogato Articles
+
+
+ I've found that one of the best resources that any free software
+ developer has at his or her disposal is the advogato. If you
+ haven't yet had a chance to visit the website, do.
+
+
+
+ I have spent a lot of time on advogato and I've gone through and
+ provided links to the articles that I think are of particular
+ interest to anyone reading this HOWTO. I think that looking
+ through these is important. I promise that you'll learn a lot. You
+ will learn that my idea of how a free software project should be
+ run is not the only idea about how such a
+ project can be done. I think that's great.
+
+
+
+ If nothing else, there is way more
+ information on that website than I could ever fit into, or
+ reference from this HOWTO. I have listed what I think are the most
+ relavant articles here with short descriptions.
+
+
+
+
+
+
+ Hindle
+ Stephen
+
+
+ <ulink url="http://www.advogato.org/article/262.html">'Best Practices' for Open Source?</ulink>
+
+
+ Advogato
+
+ March 21, 2001
+
+
+
+ Touching mostly on programming practice (as most articles on
+ the subject usually do), the article talks a little about
+ project managment (Use it!) and a bit about
+ communication within a free software project.
+
+
+
+
+
+
+
+
+ Cohen
+ Bram
+
+
+ <ulink
+ url="http://www.advogato.org/article/258.html"></ulink>How to
+ Write Maintainable Code
+
+
+ Advogato
+
+ March 15, 2001
+
+
+
+ This article touches upon the "writing maintainable code"
+ discussion that I try hard to avoid in my discussion. It's one
+ of the better articles on the subject that I've found.
+
+
+
+
+
+
+
+ Krawitz
+ Robert
+
+
+ <ulink url="http://www.advogato.org/article/196.html">Free
+ Source Project Management</ulink>
+
+
+ Advogato
+
+ November 4, 2000
+
+
+
+ This article made me happy because it challenged many of the
+ problems that I had with Monty's article on LinuxProgramming. The
+ author argues that Monty argues simply for the application of
+ old project management techniques to free software projects
+ instead of working with something new. I found his article to
+ be extremely well thought out and I think its an essential read
+ for any project manager.
+
+
+
+
+
+
+
+
+ Martins
+ Lalo
+
+
+ <ulink url="http://www.advogato.org/article/128.html">Ask
+ the Advogatos: why do Free Software projects
+ fail?</ulink>
+
+
+ Advogato
+
+ July 20, 2000
+
+
+
+ While the article is little more than a question, reading the
+ answer to this question can help. In a lot of ways, this HOWTO
+ acts as my answer to the question posed in this article but
+ there are others, many of which might take issue with whats in
+ this HOWTO. It's worth checking out.
+
+
+
+
+
+
+
+
+ Burley
+ David
+
+
+ <ulink
+ url="http://www.advogato.org/article/107.html">In-Roads to Free
+ Software Development</ulink>
+
+
+ Advogato
+
+ June 14, 2000
+
+
+
+ This document was written as a response to another advogato
+ article. Although not about running a project, this
+ describes some of the ways that you can get started with free
+ software development. I think this is an important article. If
+ you are interested to become involved with free software, this
+ article showcases some of the ways that you can do this without
+ actually starting a project (something that I hope this HOWTO
+ has demonstrated is not to be taken lightly).
+
+
+
+
+
+
+
+
+ Moorman
+ Jacob
+
+
+ <ulink
+ url="http://www.advogato.org/article/72.html"></ulink>Importance
+ of Non-Developer Supporters in Free Software
+
+
+ Advogato
+
+ April 16, 2000
+
+
+
+ Moorman's is a short article but it brings up some good
+ points. The comment reminding developers to thank their testers
+ and end-users is invaluable and oft-forgotten.
+
+
+
+
+
+
+
+
+ Orchard
+ Leslie
+
+
+ <ulink url="http://www.advogato.org/article/67.html">On
+ Naming an Open Source Project</ulink>
+
+
+ Advogato
+
+ April 12, 2000
+
+
+
+ I didn't even have a section on naming in this HOWTO (See ) until Leslie Orchard's article reminded me
+ of it. Thanks to Leslie for writing this article!
+
+
+
+
+
+
+
+
+ Allen
+ David
+
+
+ <ulink url="http://www.advogato.org/article/40.html">Version Numbering Madness</ulink>
+
+
+ Advogato
+
+ Februrary 28, 2000
+
+
+
+ In this article, David Allen challengs the whole
+ Major.Minor.Patch versioning scheme. Its good to
+ read this as you read . I
+ liked the article and it describes some of the projects that I
+ bring up in my discussion of verion numbering.
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file