2. Starting a Project

2.1.1. Identify and articulate your idea

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!"

2.1.2. Evaluate your idea

In evaluating your idea, you need to first ask yourself a few questions. This should happen before you move any further through this HOWTO. Ask yourself: Is the free software development model really 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 a second 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 who feels the same "itch." It is the fact that there are so many people with so many similar needs and desires that introduces the third major question: Has somebody already had your idea or a reasonably similar one?

2.3.1. 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 over the terms "Open Source Software" and "Free Software". However, because I've written the Free Software Project Management HOWTO and not the Open Source Software Project Management 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 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:

• The GNU General Public License

• The BSD License

• The Artistic License

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.

2.3.2. The mechanics of licensing

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.

2.3.3. 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 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.

2.5.1. Man pages

Your users will want to be able to type "man yourprojectname" end up with a nicely formatted man page highlighting the basic use of your application. 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" 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.

2.5.2. 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, as well as all the major options (also with explanations), plus 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 methods, be prepared for the flames and fallout that may result.

2.5.3. 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 the root directory of the source distribution or in a subdirectory of the root called "doc" or "Documentation." Common files in these places include:

2.5.4. Website

It's only indirectly an issue of documentation but a good website is quickly becoming an essential part of any free software project. Your website should provide access to your 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 make 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.

2.5.5. Other documentation hints

• 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. In my opinion, info falls into this category as well. There is plenty of great GNU documentation that people simply don't read because it only in info. And this does make people angry. It's not a question of superior formats; it is a question of accessability and the status quo plays a huge role in this determination.

• It doesn't hurt to distribute any documentation for your program from your website (FAQs etc) with your program. Don't hesitate to throw any of this in the program's 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.

• Unless your software is particular to a non-English language (a Japanese language editor for example), please distribute it with English language documentation. If you don't speak English or not not confident in your skills, ask a friend for help. Like it or not, fair or unfair, English is the language of free software. However, this does not mean you should limit your documentation to only English. If you speak another language, distribute translations of documentation with your software if you have the time and energy to do so. They will invariably be useful to someone.

• Finally, please spell-check your documentation. Misspellings in documentation are bugs. I'm very guilty of committing this error and it's extremely easy to do. If English is not your first language, have a native speaker look over or edit your documentation or web pages. Poor spelling or grammar goes a long way to making your code look unprofessional. In code comments, this type of thing is less important but in man pages and web pages these mistakes are not acceptable.

2.6.1. Package File Names

I agree with ESR when he says that: " It's helpful to everybody if your archive files all have GNU-like names -- all-lower-case alphanumeric stem prefix, followed by a dash, followed by a version number, extension, and other suffixes." There is more info (including lots of examples of what not to do in his Software Release Practices HOWTO which is included in this HOWTO's bibliography and can be found through the LDP.

2.6.2. 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-light as a more effective compression medium. I now make all my releases available in both gzip'ed and bzip2'ed tarballs.

Binary packages should always be distribution specific. If 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 distributions to develop a system for the consistent creation of binary packages. It's often a good idea to provide RedHat RPM's (.rpm), Debian deb's (.deb) and source RPM's SRPM's if possible. 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.

2.6.3. Version control systems

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.

2.6.4. 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 the web where the newest version can be quickly recognized. One effective technique is a provide a symlink called "yourprojectname-latest" that is always pointing to the most recent released or development version of your free software application. Keep in mind that this location will receive many requests for downloads around releases so make sure that the server you choose 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 yourprojectname@host or yourprojectname-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.