mako@debian.org
| Revision History | ||
|---|---|---|
| Revision v0.3.2 | 15 April 2002 | Revised by: bch |
| Revision v0.3.1 | 18 June 2001 | Revised by: bch |
| Revision v0.3 | 5 May 2001 | Revised by: bch |
| Revision v0.2.1 | 10 April 2001 | Revised by: bch |
| Revision v0.2 | 8 April 2001 | Revised by: bch |
| Revision v0.01 | 27 March 2001 | Revised by: bch |
| Initial Release | ||
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found in Appendix A.
The latest version number of this document should always be listed on the projects homepage hosted by yukidoke.org.
The newest version of this HOWTO will always be made available at the same website, in a variety of formats:
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. If 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. 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 and Lawrence Lessig for reminding me of the importance of Free Software. Additionally, 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 who 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 toward writing a document to make sure it succeeds. RMS can always be emailed at <rms (at) gnu (dot) org>.
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 its ability to do this. Please send your additions, comments, and criticisms to the following email address: <mako@debian.org>.
I've been contacted by a reader who promises a translation into Korean. However, this HOWTO is still young and other than the promise of Korean, 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>.
Eric S. Raymond writes about how free software projects start in his essay, "The Cathedral and the Bazaar," which comes as required reading for any free software developer. 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 clearly early on. Find out exactly what it is that you want your project to do.
Monty Manley articulates 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 even ready to be coded. Manley says, "Beginning an OSS project properly means that a developer must, first and foremost, avoid writing code too soon!"
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 at all.
Slashdot provides "News for Nerds. Stuff that matters," which usually includes discussion of free software, open source, technology, and geek culture news and events. It is not unusual for a particularly sexy development effort to be announced here, so it is definitely worth checking.
SourceForge houses and facilitates a growing number of open source and free software projects. It is also quickly becoming a nexus and a necessary stop for free software developers. SourceForge's software map and new release pages should be necessary stops before embarking on a new free software project. SourceForge also provides a Code Snippet Library which contains useful reusable chunks of code in an array of languages which can come in useful in any project.
Google and Google's Linux Search, provides 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 to make sure you aren't pouring your effort into a redundant project.
While there are plenty of projects that fail with descriptive names and plenty that succeed without them, I think naming your project is worth giving a bit of thought. Leslie Orchard tackles this issue in an Advogato article. His article is short and definitely worth looking over quickly.
The synopsis is that Orchard recommends you pick a name where, after hearing the name, many users or developers will both:
Know what the project does.
Remember it tomorrow.
Humorously, Orchard's project, "Iajitsu," does neither. It is probably unrelated that development has effectively frozen since the article was written.
He makes a good point though. There are companies whose only job is to make names for pieces of software. They make ridiculous amount of money doing it and are supposedly worth it. While you probably can't afford a company like this, you can afford to learn from their existence and think a little bit about the name you are giving your project because it does matter.
If there is a name you really want but it doesn't fit Orchard's criteria, you can still go ahead. I thought "gnubile" was one of the best I'd heard for a free software project ever and I still talk about it long after I've stopped using the program. However, if you can be flexible on the subject, listen to Orchard's advice. It might help you.
In attempting to reach a middle ground through diplomacy without sacrificing my own philosophy, I will recommend picking any license that conforms to the Debian Free Software Guidelines. Originally compiled by the Debian project under Bruce Perens, the DFSG forms 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. As ESR mentions in his his HOWTO[ESRHOWTO], don't write your own license if at all possible. The three licenses I mention all have long interpretive traditions. They are also definitely free software (and can therefore be distributed as part of Debian and in other places that permit the transfer of free software).
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 well-known license will offer the advantage of immediate recognition and understanding. Many people write three or four sentences in a COPYING file and assume that they have written a free software license--as my long experience with the debian-legal mailing professes, this is very often not the case.
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 also believe it is a good one. Any BSD fanatic will urge you to remember that there is a viral aspect to the GPL that 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.
Many people write three or four sentences in a COPYING file and assume that they have written a free software license--as my long experience with the debian-legal mailing professes, this is very often not the case. It may not protect you, it may not protect your software, and it may make things very difficult for people that want to use your software but who pay a lot of attention to the subtle legal points of licenses. If you are passionate about a home-brewed license, run it by either people at OSI or the debian-legal mailing list first protect yourself from unanticipated side-effects of your license.
The three major licenses can be found at the following locations:
In any case, please read through any license before your release your software under it. As the primary developer, you can't afford any license surprises.
The text of the GPL offers a good description of the mechanics of applying a license to a piece of software. My quick checklist for applying a license includes:
Make yourself or the FSF the copyright holder for the work. In a few rare cases, you might want to make a sponsoring organization (if it's big and powerful enough) the copyright holder instead. Doing this is as simple as putting the name in the blank when you modify the notice of copyright below. Contrary to popular belief, you don't need to file with any organization. The notice alone is enough to copyright your work.
If at all possible, attach and distribute a full copy of the license with the source and binary by including a separate file.
At the top of each source file in your program, attach a notice of copyright and include 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 methods for 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 full information about the programs license:
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" 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. These aren't often needed but there are plenty of free software developers who have gotten into trouble and wish they'd asked for one.
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 your software has no license, it 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.
Whether you plan on having a split development model (as described in Section 3.3) 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 development progress 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 an idea worth taking into consideration.
Because of the unusual nature of wine's development where the not-emulator is constantly improving but not working toward 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.
When one considers Netscape 6 and vendor versions, the mozilla's project development structure is one of the most complex free software models available. The project's 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, although Mozilla was built and distributed nightly as "nightly builds," 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 application under heavy development.
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 Section 4.3 that you should always release something that is usable. A piece of software without documentation is not usable.
There are lots of different people you should document for and there are lots of ways to document your project. The importance of documentation 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 with 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 are not difficult to write. There is excellent documentation on the man page writing process available through the "The Linux Man-Page-HOWTO" which is available through the Linux Documentation project (LDP) and is 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. 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 how this is done.
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.
|
A version control system can make a lot of these problems of packaging (and a lot of other problems mentioned in this HOWTO) less problematic. 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 described by this HOWTO. I am not aware of any free version control systems for Windows or Mac OS 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 web 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 versions straight on this HOWTO!) but I think it falls outside the scope of this document and already has its own HOWTOs. Most notably is the CVS Best Practices HOWTO[CVSBESTPRACTICES] which I've included in the attached bibliography.
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 we've gone ahead and (as will be discussed in Section 4.3) 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, 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, and 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 committee. In many cases it does and this has been proven to work. In other cases this has created problems. 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 project's founder and that these important powers need not all rest with one person but that a release manager may be different than a lead developer. These situations are tricky politically so be careful and make sure it's necessary before you go around empowering people.
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 aspects of the project. All these developers can upload into the main FTP server, 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.
If your project chooses to have branches (as described in Section 3.3), 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.
As the person managing or maintaining the project, you aren't the person who is going to be making a lot of patches. However, it's worth knowing about ESR's section on Good Patching Practice in the Software Release Practices HOWTO[ESRHOWTO]. I don't agree with ESR's claim that most ugly or undocumented patches are probably worth throwing out at first sight--this just hasn't been my experience, especially when dealing with bug fixes that often don't come in the form of patches at all. Of course, this doesn't mean that I like getting poorly done patches. If you get ugly -e patches, if you get totally undocumented patches, and especially if they are anything more than trivial bug-fixes, it might be worth judging the patch by some of the criteria in ESR's HOWTO and then throwing people the link to the document so they can do it the "right way."
A firm knowledge of the scope of your program (that's the "idea" I talked about in Section 2.1);
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 toward 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 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 these 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 many ultimately fail.
Rejecting patches is probably the most difficult and sensitive job that the maintainer of any free software project has to face. But sometimes it has to be done. I mentioned earlier (in Section 3 and in Section 3.1) that you need 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 the community's project. I recommend that you keep these three major concepts in mind when rejecting patches (or other changes):
The idea of stable and development branches has already been described briefly in Section 2.4 and in Section 3.1.1.3. 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 Section 3.2) 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 Section 2.4. 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 Section 3.4.1 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 provides an extreme example. On many projects, there is no need to have two versions constantly 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:
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 5-6 different architectures. For you, two is probably a good ceiling. 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.
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 web 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.
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 into different directories or directory trees on your FTP or web 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 and where to get it.
Other smaller issues that are worth mentioning are:
For those projects that choose to adopt a split development model (Section 3.3), 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 discouraged 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 level "code freeze."
Even if you never choose to appoint a release manager (Section 3.1.1.2), you will have an easier time justifying the rejection or postponement of patches (Section 3.2) before a release with a publicly stated freeze in effect.
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 project management. 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.
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, greatest features. These users except a stable, tested piece of software without major or obvious bugs and will be angry if they find themselves testing. This is yet another way in which a split development model (as mentioned in Section 3.3) might come in handy.
"Managing Projects the Open Source Way" describes what a good test should look for:
Maximum buffer lengths, data conversions, upper/lower boundary limits, and so on.
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 your program would do in those cases.
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.
If possible, make sure your programs conforms to standards. If it's interactive, 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.
It should not come as any surprise that the key element to any support infrastructure is good documentation. This topic was largely covered in Section 2.5 and will not be repeated here.
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. 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 into consideration in setting up your list. If it is possible to gate your mailing lists to Usenet and provide it 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.
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 a lot.
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 avenue for users and testers to report bugs and for developers and maintainers to fix them and track them in an orderly fashion.
One tactic is to first do an "alpha" or "beta" release as described below in Section 4.3.3. However, most of the guidelines described above still apply.
When you feel in your gut that 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.
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 software is feature-complete but sometimes only partially functional.
Alpha releases are expected to be unstable, perhaps a little unsafe, but definitely usable. 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 software is feature-complete and functional, but is in the testing cycle and still has a few bugs left to be ironed out.
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 to be in the very near future and can help keep interest by giving people something.
"Development release" is much a 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 alpha or beta and if I were to release a pre-alpha version of a piece of software in order to keep interest in my project alive, this is probably how I would have to label it.
Announce your software on Usenet's comp.os.linux.announce. If you only announce your software in two places, have it be c.o.l.a and freshmeat.
However, 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 other relevant Usenet discussion groups.
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. This form will work for both Usenet and mailing list posts.
You should repeat this announcement process consistently in the same locations for each subsequent release.
Mentioned earlier in Section 2.1.2.1, 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 personally skim it every night for any interesting new releases).
Karl Fogel, 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 subtitle. In the publisher's 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 also 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 role it tried to serve was so important and useful. Please check it or buy it if you can and are seriously interested in running a free software project.
Lawrence Lessig, 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 spineless use of the term "open code" that only a lawyer could coin), Lessig's 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 the nature of future freedoms. In addition to being a quick and enjoyable read, it gives some cool history and describes how we need free software in a way more powerfully than anything I've read outside of RMS's "Right to Read."
Eric Raymond, 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 of sketching the free software process and does an an amazing job of making an argument for free software/open source development as a road to better software. The rest of the book has other of ESR's articles, which for the most part are posted on his website. Still, it's nice thing to own in hard copy and something that every free software/open source hacker should read.
George N Dafermos, Management and Virtual Decentralized Networks: The Linux Project.
Since the paper includes its own abstract, I thought I would include it here verbatim:
Richard Gabriel, The Rise of "Worse is Better".
A well written article although I think the title may have confused as many people as the rest of the essay helped. It offers a good description of how to design programs that will succeed and stay maintainable as they grow.
Montey Manley, Managing Projects the Open Source Way, 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, documentation, organizing a team and leadership, and several other topics. While more opinionated that I try to be, I think its an important article that I found very helpful in writing this HOWTO. I've tried to cite him in the places where I borrowed from him most.
I have problems much of this piece and I recommend you read [KRAWITZ] at the same time you read Monty's article for a good critique.
Eric Steven Raymond, Software Release Practice HOWTO.
At first glance, ESR's release practice HOWTO seems to share a lot of terrain with this document. Upon closer examination, the differences become apparent but they are closely related. His document, read in conjunction with mine, will give a reader a good picture of how to go about managing a project. ESR's HOWTO goes into a bit more detail on how to write and what languages to write in. He tends to give more specific instructions and checklists ("name this file this, not this") while this HOWTO speaks more conceptually. There are several sections that are extremely similar. It's also much shorter.
My favorite quote from his HOWTO is: ""Managing a project well when all the participants are volunteers presents some unique challenges. This is too large a topic to cover in a HOWTO." Oh really? Perhaps I just do a poor job.
Vivek Venugopalan, CVS Best Practices.
Venugopalan provides one of the best essays on effective use of CVS that I've come across. It is written for people who already have a good knowledge of CVS. In the chapter on branching, he describes when and how to branch but gives no information on what CVS commands you should use to do this. This is fine (technical CVS HOWTO have been written) but CVS newbies will want to spend some time with Fogel's reference before they will find this one very useful.
Venugopalan creates checklists of things to do before, after, and around releases. It's definitely worth a read through as most of his ideas will save tons of developer head aches over any longer period of time.
Stephen Hindle, 'Best Practices' for Open Source?, Advogato, March 21, 2001.
Touching mostly on programming practice (as most articles on the subject usually do), the article talks a little about project management ("Use it!") and a bit about communication within a free software project.
Bram Cohen, http://www.advogato.org/article/258.htmlHow 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 HOWTO. It's one of the better (and most diplomatic) articles on the subject that I've found.
Robert Krawitz, Free Source Project Management, 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 calls simply for the application of old (proprietary software) project management techniques in free software projects instead of working to come up with something new. I found his article to be extremely well thought out and I think it's an essential read for any free software project manager.
Lalo Martins, Ask the Advogatos: why do Free Software projects fail?, Advogato, July 20, 2000.
While the article is little more than a question, reading the answers to this question offered by Advogato's readers can help. In a lot of ways, this HOWTO acts as my answer to the questions posed in this article but there are others, many of which might take issue with whats is in this HOWTO. It's worth checking out.
David Burley, In-Roads to Free Software Development, 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 without starting a project. I think this is an important article. If you are interested in becoming 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).
Jacob Moorman, 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.
Leslie Orchard, On Naming an Open Source Project, Advogato, April 12, 2000.
I didn't even have a section on project naming in this HOWTO (See Section 2.2) until Leslie Orchard's article reminded me of it. Thanks to Leslie for writing this article!
David Allen, Version Numbering Madness, Advogato, February 28, 2000.
In this article, David Allen challenges the whole "Major.Minor.Patch" version numbering scheme. Its good to read this as you read Section 2.4. I liked the article and it describes some of the projects that I bring up in my discussion of version numbering.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
You may copy and distribute the Document in any medium, either commercially or non-commercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).
C. State on the Title Page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version .
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and dispbibute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document , on account of their being thus compiled, if they are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.