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.