LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/Software-Proj-Mgmt-HOWTO.sgml

3984 lines
152 KiB
Plaintext
Raw Permalink Blame History

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<article>
<!-- Header -->
<artheader>
<title>Free Software Project Management HOWTO</title>
<author>
<firstname>Benjamin</firstname>
<othername>"Mako"</othername>
<surname>Hill</surname>
<affiliation>
<address>
<email>mako@debian.org</email>
</address>
</affiliation>
</author>
<revhistory>
<revision>
<revnumber>v0.3.2</revnumber>
<date>15 April 2002</date>
<authorinitials>bch</authorinitials>
</revision>
<revision>
<revnumber>v0.3.1</revnumber>
<date>18 June 2001</date>
<authorinitials>bch</authorinitials>
</revision>
<revision>
<revnumber>v0.3</revnumber>
<date>5 May 2001</date>
<authorinitials>bch</authorinitials>
</revision>
<revision>
<revnumber>v0.2.1</revnumber>
<date>10 April 2001</date>
<authorinitials>bch</authorinitials>
</revision>
<revision>
<revnumber>v0.2</revnumber>
<date>8 April 2001</date>
<authorinitials>bch</authorinitials>
</revision>
<revision>
<revnumber>v0.01</revnumber>
<date>27 March 2001</date>
<authorinitials>bch</authorinitials>
<revremark>Initial Release</revremark>
</revision>
</revhistory>
<abstract>
<indexterm>
<primary>fswd</primary>
</indexterm>
<para>
This HOWTO is designed for people with experience in programming
and some skills in managing a software project but who are new to
the world of free software. This document is meant to act as a
guide to the non-technical aspects of free software project
management and was written to be a crash course in the people
skills that aren't taught to commercial coders but that can make
or break a free software project.
</para>
</abstract>
</artheader>
<!-- Section1: intro -->
<sect1 id="intro">
<title>Introduction</title>
<indexterm>
<primary>fswd!introduction</primary>
</indexterm>
<para>
Skimming through freshmeat.net provides mountains of reasons for this
HOWTO's existence--the Internet is littered with excellently
written and useful programs that have faded away into the universe
of free software forgottenness. This dismal scene made me ask
myself, "Why?"
</para>
<para>
This HOWTO tries to do a lot of things (probably too many), but it
can't answer that question and won't attempt it. What this HOWTO
will attempt to do is give your Free Software project a fighting
chance--an edge. If you write a piece of crap that no one is
interested in, you can read this HOWTO until you can recite it in
your sleep and your project will probably fail. Then again, you can
write a beautiful, relevant piece of software and follow every
instruction in this HOWTO and your software may still not make
it. Sometimes life is like that. However, I'll go out a limb and
say that if you write a great, relevant pieces of software and
ignore the advise in this HOWTO, you'll probably fail <emphasis>
more often</emphasis>.
</para>
<para>
A lot of the information in this HOWTO is best called common
sense. Of course, as any debate on interfaces will prove, what is
common sense to some programmers proves totally unintuitive to
others. After explaining bits and pieces of this HOWTO to Free
Software developers on several occasions, I realized that writing
this HOWTO might provide a useful resource and a forum for
programmers to share ideas about what has and has not worked for
them.
</para>
<para>
As anyone involved in any of what seems like an unending parade of
ridiculous intellectual property clashes will attest to, a little
bit of legalese proves important.
</para>
<!-- Section2: copyright -->
<sect2 id="copyright">
<title>Copyright Information</title>
<para>
This document is copyrighted (c) 2000 Benjamin "Mako" Hill and is
distributed under the terms of the <citetitle>GNU Free
Documentation License</citetitle>.
</para>
<para>
Permission is granted to copy, distribute and/or modify this
document under the terms of the <link
linkend="fdl"><citetitle>GNU Free Documentation
License</citetitle></link>, 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 <xref linkend="fdl">.
</para>
</sect2>
<!-- Section2: disclaimer -->
<sect2 id="disclaimer">
<title>Disclaimer</title>
<para>
No liability for the contents of this documents can be accepted.
Use the concepts, examples and other content at your own risk. As
this is a new edition of this document, there may be errors and
inaccuracies, that may of course be damaging to your project (and
potentially your system). Proceed with caution, and although this
is highly unlikely, the author(s) does not take any responsibility
for that.
</para>
<para>
All copyrights are held by their by their respective owners, unless
specifically noted otherwise. Use of a term in this document
should not be regarded as affecting the validity of any trademark
or service mark.
</para>
<para>
Naming of particular products or brands should not be seen
as endorsements.
</para>
</sect2>
<!-- Section2: newversions-->
<sect2 id="newversions">
<title>New Versions</title>
<para>
This version is the part of the third pre-release cycle of this
HOWTO. It is written to be released to developers for critique and
brainstorming. Please keep in mind that this version of the HOWTO
is still in an infant stage and will continue to be revised
extensively.
</para>
<para>
The latest version number of this document should always be listed
on <ulink url="http://yukidoke.org/~mako/projects/howto">the projects
homepage </ulink> hosted by <ulink url="http://yukidoke.org">yukidoke.org.</ulink>
</para>
<para>
The newest version of this HOWTO will always be made available at
the same website, in a variety of formats:
</para>
<para>
<itemizedlist>
<listitem>
<para>
<ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO/t1.html">HTML</ulink>.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.
</para>
</listitem>
<listitem>
<para>
<ulink URL="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<!-- Section2: credits -->
<sect2 id="credits">
<title>Credits</title>
<para>
In this version I have the pleasure of acknowledging:
</para>
<para>Fellow Debian developer Martin Michlmayr and Vivek
Venugopalan who sent me information and links to extremely
interesting articles. I've added both to the bibliography and I've
added information from each into the HOWTO. Thanks to Andrew Shugg
who pointed out several errors in the document. Also, a big thanks
to Sung Wook Her (AKA RedBaron) who is doing the first translation
of the HOWTO into Korean. I've been happy to see that people have
enjoyed and benefited from the HOWTO so far.</para>
<para>
Older thanks that I don't want to take out yet include: Josh
Crawford, Andy King, and Jaime Davila who all read through this in
entirety and gave me feedback that has helped me make changes and
improvements to this document. I can't thank you guys enough for
your help. An extra <quote>Thank You</quote> goes to Andy King who
who read through this several times and submitted patches to make
life easier for me.
</para>
<para>
Karl Fogel, the author of <citetitle>Open Source Development with
CVS</citetitle> published by the Coriolis Open Press. Large parts
of his book are available <ulink
url="http://cvsbook.red-bean.com">on the web</ulink>. 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,
<quote>the challenges and philosophical issues inherent in running
an Open Source project using CVS.</quote> The book does a good job
of covering some of the subjects brought up in this HOWTO and much
more. <ulink url="http://cvsbook.red-bean.com">The book's
website</ulink> 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.
</para>
<para>
Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
com</email>
</para>
<para>
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 <ulink
url="http://www.debian.org">Debian Project</ulink>. 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.
</para>
<para>
Above all, I want to thank <emphasis>Richard Stallman</emphasis>
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
<email>rms (at) gnu (dot) org</email>.
</para>
</sect2>
<!-- Section2: feedback -->
<sect2 id="feedback">
<title>Feedback</title>
<para>
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:
<email>mako@debian.org</email>.
</para>
</sect2>
<!-- Section2: translations -->
<sect2 id="translations">
<title>Translations</title>
<para>
I know that not everyone speaks English. Translations are nice and
I'd love for this HOWTO to gain the kind of international reach
afforded by translated versions.
</para>
<para>
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: <email>mako@debian.org</email>.
</para>
</sect2>
</sect1>
<!-- Section1: intro: END -->
<!-- Section1: starting -->
<sect1 id="starting">
<title>Starting a Project</title>
<indexterm>
<primary>fswd!starting</primary>
</indexterm>
<para>
With very little argument, the beginning is the most difficult
period in a project's life to do successful free software project
management. Laying a firm foundation will determine whether your
project flourishes or withers away and dies. It is also the subject
that is of most immediate interest to anyone reading this document
as a tutorial.
</para>
<para>
Starting a project involves a dilemma that you as a developer must
try and deal with: no potential user for your program is interested
in a program that doesn't work, while the development process that
you want to employ holds involvement of users as imperative.
</para>
<para>
It is in these dangerous initial moments that anyone working to
start a free software project must try and strike a balance along
these lines. One of the most important ways that someone trying to
start a project can work toward this balance is by establishing a
solid framework for the development process through some of the
suggestions mentioned in this section.
</para>
<!-- Section2: chooseproject-->
<sect2 id="chooseproject">
<title>Choosing a Project</title>
<para>
If you are reading this document, there's a good chance you
already have an idea for a project in mind. Chances are also
pretty good that it fills a perceived gap by doing something that
no other free software project does or by doing something in a way
that is unique enough to necessitate a brand new piece of
software.
</para>
<sect3 id=identifyidea>
<title>Identify and articulate your idea</title>
<para>
Eric S. Raymond writes about how free software projects start in
his essay, <ulink
url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/"><quote>The
Cathedral and the Bazaar,</quote></ulink> which comes as required
reading for any free software developer. It is available online .
</para>
<para>
In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
that: <quote>every good work of software starts by scratching
a developers itch.</quote> 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.
</para>
<para>
If you have an idea for a program in mind, chances are good that
it targets a specific problem or <quote>itch</quote> you want to
see scratched. <emphasis>This idea is the project.</emphasis>
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.
</para>
<para>
Monty Manley articulates the importance of this initial step in
an essay, <quote><ulink
url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
Projects the Open Source Way.</ulink></quote> As the next section
will show, there is <emphasis>a lot</emphasis> of work that needs
to be done before software is even ready to be coded. Manley
says, <quote>Beginning an OSS project properly means that a
developer must, first and foremost, avoid writing code too
soon!</quote>
</para>
</sect3>
<sect3 id=evalulateidea>
<title>Evaluate your idea</title>
<para>
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: <emphasis>Is the free software
development model really the right one for your
project?</emphasis>
</para>
<para>
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: <emphasis>Is anybody else interested?</emphasis>
</para>
<para>
Sometimes the answer is a simple <quote>no.</quote> If you want
to write a set of scripts to sort <emphasis>your</emphasis>
<acronym>MP3</acronym> collection on <emphasis>your</emphasis>
machine, <emphasis>maybe</emphasis> the free software development
model is not the best one to choose. However, if you want to
write a set of scripts to sort <emphasis>anyone's</emphasis>
<acronym>MP3</acronym>s, a free software project might fill a
useful gap.
</para>
<para>
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 <quote>itch.</quote> It is the
fact that there are so many people with so many similar needs and
desires that introduces the third major question: <emphasis>Has
somebody already had your idea or a reasonably similar
one?</emphasis>
</para>
<sect4 id=evalwhere>
<title>Finding Similar Projects</title>
<para>
There are places you can go on the web to try and answer the
question above. If you have experience with the free software
community, you are probably already familiar with many of these
sites. All of the resources listed below offer searching of
their databases:
</para>
<para>
<variablelist>
<varlistentry>
<term>freshmeat.net</term>
<listitem>
<para><ulink url="http://freshmeat.net">freshmeat.net</ulink>
describes itself as, <quote>the Web's largest index of Linux
and Open Source software</quote> 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Slashdot</term>
<listitem>
<para><ulink url="http://slashdot.org">Slashdot</ulink>
provides <quote>News for Nerds. Stuff that matters,</quote>
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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SourceForge</term>
<listitem>
<para><ulink url="http://sourceforge.net">SourceForge</ulink>
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 <ulink
url="http://sourceforge.net/softwaremap/trove_list.php">software
map</ulink> and <ulink url="http://sourceforge.net/new/"> new
release</ulink> pages should be necessary stops before
embarking on a new free software project. SourceForge also
provides a <ulink
url="http://sourceforge.net/snippet/">Code Snippet
Library</ulink> which contains useful reusable chunks of code
in an array of languages which can come in useful in any
project.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Google and Google's Linux Search</term>
<listitem>
<para><ulink url="http://www.google.com">Google</ulink> and
<ulink url="http://www.google.com/linux"> Google's Linux
Search</ulink>, 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.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect4>
<sect4 id=evalhow>
<title>Deciding to Proceed</title>
<para>
Once you have successfully charted the terrain and have an idea
about what kinds of similar free software projects exist, every
developer needs to decide whether to proceed with their own
project. It is rare that a new project seeks to accomplish a
goal that is not at all similar or related to the goal of
another project. Anyone starting a new project needs to ask
themselves: <quote>Will the new project be duplicating work done
by another project? Will the new project be competing for
developers with an existing project? Can the goals of the new
project be accomplished by adding functionality to an existing
project?</quote>
</para>
<para>
If the answer to any of these questions is <quote>yes,</quote>
try to contact the developer of the existing project(s) in
question and see if he or she might be willing to collaborate
with you.
</para>
<para>
For many developers this may be the single most difficult aspect
of free software project management, but it is an essential one. It is
easy to become fired up by an idea and get caught up in the
momentum and excitement of a new project. It is often extremely
difficult to do, but it is important that any free software
developer remembers that the best interests of the free software
community and the quickest way to accomplish your own project's
goals and the goals of similar projects can often be
accomplished by <emphasis>not</emphasis> starting a new
development effort.
</para>
</sect4>
</sect3>
</sect2>
<!-- Section2: naming-->
<sect2 id="naming">
<title>Naming your project</title>
<para>
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 <ulink
url="http://www.advogato.org/article/67.html">Advogato
article</ulink>. His article is short and definitely worth looking
over quickly.
</para>
<para>
The synopsis is that Orchard recommends you pick a name where,
after hearing the name, many users or developers will both:
</para>
<para>
<itemizedlist>
<listitem>
<para>Know what the project does.</para>
</listitem>
<listitem>
<para>Remember it tomorrow.</para>
</listitem>
</itemizedlist>
</para>
<para>
Humorously, Orchard's project, <quote>Iajitsu,</quote> does
neither. It is probably unrelated that development has effectively
frozen since the article was written.
</para>
<para>
He makes a good point though. There are companies whose only job
is to make names for pieces of software. They make
<emphasis>ridiculous</emphasis> 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
<emphasis>does</emphasis> matter.
</para>
<para>
If there is a name you really want but it doesn't fit Orchard's
criteria, you can still go ahead. I thought <quote>gnubile</quote>
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.
</para>
</sect2>
<!-- Section2: licensing-->
<sect2 id="licensing">
<title>Licensing your Software</title>
<para>
On one (somewhat simplistic) level, the difference between a piece
of free software and a piece of propriety software is the
license. A license helps you as the developer by protecting your
legal rights to have your software distributed under your terms
and helps demonstrate to those who wish to help you or your
project that they are encouraged to join.
</para>
<sect3 id="chooselicense">
<title>Choosing a license</title>
<para>
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 <quote>Open Source Software</quote> and
the debate over the terms <quote>Open Source Software</quote> and
<quote>Free Software</quote>. 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.
</para>
<para>
In attempting to reach a middle ground through diplomacy without
sacrificing my own philosophy, I will recommend picking any
license that conforms to the <ulink
url="http://www.debian.org/social_contract">Debian Free Software
Guidelines</ulink>. Originally compiled by the Debian project
under Bruce Perens, the <acronym>DFSG</acronym> forms the first
version of the <ulink
url="http://www.opensource.org/docs/definition_plain.html">Open
Source Definition.</ulink> Examples of free licenses given by the
<acronym>DFSG</acronym> are the <acronym>GPL</acronym>, the
<acronym>BSD</acronym>, and the Artistic License. As ESR mentions
in his HOWTO<xref linkend="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).
</para>
<para>
Conforming to the definition of free software offered by Richard
Stallman in <ulink
url="http://www.gnu.org/philosophy/free-sw.html"><quote>The Free
Software Definition</quote></ulink>, any of these licenses will
uphold, <quote>users' freedom to run, copy, distribute, study,
change and improve the software.</quote> There are plenty of
other licenses that also conform to the <acronym>DFSG</acronym>
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.
</para>
<para>
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 <acronym>GPL</acronym> and those that are not the
<acronym>GPL</acronym>.
</para>
<para>
Personally, I license all my software under the
<acronym>GPL</acronym>. Created and protected by the Free
Software Foundation and the GNU Project, the
<acronym>GPL</acronym> 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 <acronym>GPL</acronym> that prevents the mixture of
<acronym>GPL</acronym>'ed code with non-<acronym>GPL</acronym>'ed
code. To many people (myself included), this is a benefit, but to
some, it is a major drawback.
</para>
<para>
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 <ulink
url="http://www.opensource.org">OSI</ulink> or the <ulink
url="mailto:debian-devel@lists.debian.org">debian-legal mailing
list</ulink> first protect yourself from unanticipated
side-effects of your license.
</para>
<para>
The three major licenses can be found at the following locations:
</para>
<para>
<itemizedlist>
<listitem>
<para><ulink url="http://www.gnu.org/copyleft/gpl.html">The GNU
General Public License</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.debian.org/misc/bsd.license">The
BSD License</ulink></para>
</listitem>
<listitem>
<para><ulink
url="http://language.perl.com/misc/Artistic.html">The Artistic
License</ulink></para>
</listitem>
</itemizedlist>
</para>
<para>
<emphasis>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.</emphasis>
</para>
</sect3>
<sect3 id="licensechoose">
<title>The mechanics of licensing</title>
<para>
The text of the <acronym>GPL</acronym> offers <ulink
url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
description of the mechanics of applying a license</ulink> to a
piece of software. My quick checklist for applying a license
includes:
</para>
<para>
<itemizedlist>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>If at all possible, attach and distribute a full copy of
the license with the source and binary by including a separate
file.</para>
</listitem>
<listitem>
<para>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 <acronym>GPL</acronym> recommends
that each file begin with:</para>
<screen>
<emphasis>one line to give the program's name and an idea of what it does.</emphasis>
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.
</screen>
<para>
The <acronym>GPL</acronym> goes on to recommend attaching
information on methods for contacting you (the author) via
email or physical mail.
</para>
</listitem>
<listitem>
<para>
The <acronym>GPL</acronym> 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:
</para>
<screen>
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.
</screen>
</listitem>
<listitem>
<para>Finally, it might be helpful to include a
<quote>copyright disclaimer</quote> 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.</para>
</listitem>
</itemizedlist>
</para>
</sect3>
<sect3 id="licensewarning">
<title>Final license warning</title>
<para>
Please, please, please, place your software under
<emphasis>some</emphasis> license. It may not seem important, and
to you it may not be, but licenses <emphasis>are</emphasis>
important. For a piece of software to be included in the Debian
GNU/Linux distribution, it must have a license that fits the
<ulink url="http://www.debian.org/social_contract">Debian Free
Software Guidelines</ulink>. 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.
</para>
</sect3>
</sect2>
<!-- Section2: chooseversioning-->
<sect2 id="chooseversioning">
<title>Choosing a Method of Version Numbering</title>
<para>
<emphasis>The most important thing about a system of version
numbering is that there is one.</emphasis> It may seem pedantic to
emphasize this point but you'd be surprised at the number of
scripts and small programs that pop up without any version number
at all.
</para>
<para>
<emphasis>The second most important thing about a system of
numbering is that the numbers always go up.</emphasis> Automatic
version tracking systems and people's sense of order in the
universe will fall apart if version numbers don't rise. It doesn't
<emphasis>really</emphasis> matter if 2.1 is a big jump and
2.0.005 is a small jump but it does matter that 2.1 is more recent
than 2.0.005.
</para>
<para>
Follow these two simple rules and you will not go (too)
wrong. Beyond this, the most common technique seems to be the
<quote>major level,</quote> <quote>minor level,</quote>
<quote>patch level</quote> version numbering scheme. Whether you
are familiar with the name or not, you interact with it all the
time. The first number is the major number and it signifies major
changes or rewrites. The second number is the minor number and it
represents added or tweaked functionality on top of a largely
coherent structure. The third number is the patch number and it
usually will only refer to releases fixing bugs.
</para>
<para>
The widespread use of this scheme is why I know the nature and
relative degree in the differences between a 2.4.12 release of the
Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowing
anything about any of the releases.
</para>
<para>
You can bend or break these rules, and people do. But beware, if
you choose to, someone will get annoyed, assume you don't know,
and try and educate you, probably not nicely. I always follow this
method and I implore you to do so as well.
</para>
<para>
There are several version numbering systems that are well known,
useful, and that might be worth looking into before you release
your first version.
</para>
<variablelist>
<varlistentry>
<term>Linux kernel version numbering:</term>
<listitem>
<para>The Linux kernel uses a versioning system where any odd
minor version number refers to an development or testing release
and any even minor version number refers to a stable
version. Think about it for a second. Under this system, 2.1 and
2.3 kernels were and always will be development or testing
kernels and 2.0, 2.2. and 2.4 kernels are all production code
with a higher degree of stability and more testing.
</para>
<para>
Whether you plan on having a split development model (as
described in <xref linkend="branches">) 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, <emphasis>all</emphasis> 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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Wine version numbering:</term>
<listitem>
<para>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 <quote>Year
Month Day</quote> format where each release might be labeled
<quote>wine-XXXXXXXX</quote> where the version from January 04,
2000 would be <quote>wine-20000104</quote>. For certain
projects, <quote>Year Month Day</quote> format can make a lot of
sense.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mozilla milestones:</term>
<listitem>
<para>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.
</para>
<para>
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
<ulink url="http://www.mozilla.org/roadmap.html">road
maps</ulink>. Major points and achievements along these
road-maps were marked as milestones. Therefore, although
Mozilla was built and distributed nightly as <quote>nightly
builds,</quote> on a day when the goals of a milestone on the
road-map had been reached, that particular build was marked as
a <quote>milestone release.</quote>
</para>
<para>
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.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<!-- Section2: documentation-->
<sect2 id="documentation">
<title>Documentation</title>
<para>
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 <xref linkend="releasing"> that you should
always release something that is usable. <emphasis>A piece of
software without documentation is not usable.</emphasis>
</para>
<para>
There are lots of different people you should document for and
there are lots of ways to document your project. <emphasis>The
importance of documentation in source code to help facilitate
development by a large community is vital</emphasis> but it falls
outside the scope of this HOWTO. This being the case, this section
deals with useful tactics for user-directed documentation.
</para>
<para>
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:
</para>
<sect3>
<title>Man pages</title>
<para>Your users will want to be able to type <quote>man
yourprojectname</quote> 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.
</para>
<para>
Man pages are not difficult to write. There is excellent
documentation on the man page writing process available through
the <quote>The Linux Man-Page-HOWTO</quote> which is available
through the Linux Documentation project <acronym>(LDP)</acronym>
and is written by Jens Schweikhardt. It is available <ulink
url="http://www.schweikhardt.net/man_page_howto.html">from
Schweikhardt's site</ulink> or <ulink
url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the
<acronym>LDP</acronym></ulink>.
</para>
<para>
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.
</para>
</sect3>
<sect3>
<title>Command line accessible documentation</title>
<para>
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:
</para>
<screen>
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.
</screen>
<para>
It has become a GNU convention to make this type of information
accessible with the <quote>-h</quote> and the
<quote>--help</quote> 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.
</para>
</sect3>
<sect3>
<title>Files users will expect</title>
<para>
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
<quote>doc</quote> or <quote>Documentation.</quote> Common files
in these places include:
</para>
<para>
<variablelist>
<varlistentry>
<term>README or Readme</term>
<listitem>
<para>A document containing all the basic installation,
compilation, and even basic use instructions that make up the
bare minimum information needed to get the program up and
running. A README is not your chance to be verbose but should
be concise and effective. An ideal README is at least 30 lines
long and more no more than 250.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>INSTALL or Install</term>
<listitem>
<para>The INSTALL file should be much shorter than the README
file and should quickly and concisely describe how to build
and install the program. Usually an INSTALL file simply
instructs the user to run <quote>./configure; make; make
install</quote> and touches on any unusual options or actions
that may be necessary. For most relatively standard install
procedures and for most programs, INSTALL files are as short
as possible and are rarely over 100 lines.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>CHANGELOG, Changelog, ChangeLog, or changelog</term>
<listitem>
<para>A CHANGELOG is a simple file that every well-managed
free software project should include. A CHANGELOG is simple
the file that, as its name implies, logs or documents the
changes you make to your program. The most simple way to
maintain a CHANGELOG is to simply keep a file with the source
code for your program and add a section to the top of the
CHANGELOG with each release describing what has been changed,
fixed, or added to the program. It's a good idea to post the
CHANGELOG onto the website as well because it can help people
decide whether they want or need to upgrade to a newer version
or wait for a more significant improvement.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NEWS</term>
<listitem>
<para>A NEWS file and a ChangeLog are similar. Unlike a
CHANGELOG, a NEWS file is not typically updated with new
versions. Whenever new features are added, the developer
responsible will make a note in the NEWS file. NEWS files
should not have to be changed before a release (they should be
kept up to date all along) but it's usually a good idea to
check first anyway because often developers just forget to
keep them as current as they should.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><acronym>FAQ</acronym></term>
<listitem>
<para>For those of you that don't already know,
<acronym>FAQ</acronym> stands for Frequently Asked Questions
and a FAQ is a collection of exactly that. FAQs are not
difficult to make. Simply make a policy that if you are asked
a question or see a question on a mailing list two or more
times, add the question (and its answer) to your FAQ. FAQs are
more optional than the files listed above but they can save
your time, increase usability, and decrease headaches on all
sides.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect3>
<sect3>
<title>Website</title>
<para>
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 <acronym>HTML</acronym> 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.
</para>
</sect3>
<sect3>
<title>Other documentation hints</title>
<itemizedlist>
<listitem>
<para>
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. <emphasis>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.</emphasis> 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
<emphasis>does</emphasis> 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.
</para>
</listitem>
<listitem>
<para>
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: <emphasis>Too much documentation is not a
sin.</emphasis>
</para>
</listitem>
<listitem>
<para>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 confident in your skills, ask a friend
for help. Like it or not, fair or unfair, <emphasis>English is
the language of free software</emphasis>. 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.</para>
</listitem>
<listitem>
<para>
Finally, <emphasis>please spell-check your
documentation.</emphasis> 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.
</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
<!-- Section2: presentation -->
<sect2 id="presentation">
<title>Other Presentation Issues</title>
<para>
Many of the remaining issues surrounding the creation of a new
free software program fall under what most people describe as
common sense issues. Its often said that software engineering is
90 percent common sense combined with 10 percent specialized
knowledge. Still, they are worth noting briefly in hopes that they
may remind a developer of something they may have forgotten.
</para>
<sect3>
<title>Package File Names</title>
<para>
I agree with ESR when he says that: <quote> 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.</quote> There is more info (including lots of examples
of what <emphasis>not</emphasis> to do in his <citetitle>Software
Release Practices HOWTO</citetitle> which is included in this
HOWTO's bibliography and can be found through the LDP.
</para>
</sect3>
<sect3>
<title>Package formats</title>
<para>
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.
</para>
<para>
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
<acronym>RPM</acronym>'s (.rpm), Debian deb's (.deb) and source
<acronym>RPM</acronym>'s <acronym>SRPM</acronym>'s if
possible. Remember: <emphasis>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 binary packages for you.</emphasis>
</para>
</sect3>
<sect3>
<title>Version control systems</title>
<para>
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 <ulink
url="http://cvsbook.red-bean.com/">posted HTML version</ulink>)
wholeheartedly.
</para>
<para>
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 <ulink
url="http://sourceforge.net">SourceForge</ulink> do a great job
as well with a nice, easy-to-use web interface to CVS.
</para>
<para>
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 <citetitle>CVS Best
Practices HOWTO</citetitle><xref linkend="cvsbestpractices">
which I've included in the attached bibliography.
</para>
</sect3>
<sect3>
<title>Useful tidbits and presentation hints</title>
<para>
Other useful hints include:
</para>
<para>
<itemizedlist>
<listitem>
<para>
<emphasis>Make sure that your program can always be found in a
single location.</emphasis> Often this means that you have a
single directory accessible via <acronym>FTP</acronym> or the
web where the newest version can be quickly recognized. One
effective technique is a provide a symlink called
<quote>yourprojectname-latest</quote> 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.
</para>
</listitem>
<listitem>
<para>
<emphasis>Make sure that there is a consistent email address
for bug reports.</emphasis> 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.
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
</sect2>
</sect1>
<!-- Section1: starting: END -->
<!-- Section1: developers -->
<sect1 id="developers">
<title>Maintaining a Project: Interacting with Developers</title>
<indexterm>
<primary>fswd!developers</primary>
</indexterm>
<para>
Once you have gotten your project started, you have overcome the
most difficult hurdles in the development process of your
program. Laying a firm foundation is essential, but the development
process itself is equally important and provides just as many
opportunities for failure. In the next two sections, I will
describe running a project by discussing how to maintain a
development effort through interactions with developers and with
users.
</para>
<para>
In releasing your program, your program becomes free software. This
transition is more than just a larger user base. By releasing your
program as free software, <emphasis>your</emphasis> software
becomes the <emphasis>free software community's</emphasis>
software. The direction of your software's development will be
reshaped, redirected, and fully determined by your users and, to a
larger extent, by other developers in the community.
</para>
<para>
The major difference between free software development and
propriety software development is the developer base. As the leader
of a free software project, you need to attract and keep developers
in a way that leaders of proprietary software projects simply don't
have to worry about. <emphasis>As the person leading development of
a free software project, you must harness the work of fellow
developers by making responsible decisions and by responsibly
choosing not to make decisions. You have to direct developers
without being overbearing or bossy. You need to strive to earn
respect and never forget to give it out.</emphasis>
</para>
<!-- Section2: delegation -->
<sect2 id="delegation">
<title>Delegating Work</title>
<para>
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 <xref linkend="releasing">) 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.
</para>
<para>
<emphasis>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.</emphasis>
</para>
<para>
Delegation is the political way of describing this process of
<quote>letting go.</quote> 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 <emphasis>a group</emphasis> of
developers. A group of developers can only be maintained through
respectful and responsible leadership and delegation.
</para>
<para>
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:
</para>
<para>
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. <ulink
url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
Projects the Open Source Way</ulink> argues that <quote>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).</quote> 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.
</para>
<sect3>
<title>How to delegate</title>
<para>
You may find that other developers seem even more experienced or
knowledgeable than you. Your job as a maintainer does not mean
you have to be the best or the brightest. It means you
are responsible for showing good judgment and for
recognizing which solutions are maintainable and which are not.
</para>
<para>
Like anything, its easier to watch others delegate than to do it
yourself. In a sentence: <emphasis>Keep an eye out for other
qualified developers who show an interest and sustained
involvement with your project and try and shift responsibility
toward them.</emphasis> The following ideas might be good places
to start or good sources of inspiration:
</para>
<sect4>
<title>Allow a larger group of people to have write access to your CVS
repository and make real efforts toward rule by a
committee</title>
<para>
<ulink url="http://httpd.apache.org/">Apache</ulink> 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 <ulink
url="http://httpd.apache.org/ABOUT_APACHE.html">online.</ulink>
</para>
<para>
The <ulink url="http://www.debian.org/"> Debian Project</ulink>
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 <ulink
url="http://www.debian.org/social_contract">social
contract</ulink> and a <ulink
url="http://www.debian.org/devel/constitution">constitution</ulink>. 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, <quote>appoint delegates or delegate decisions to the
Technical Committee.</quote>
</para>
<para>
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
<emphasis>nothing</emphasis> 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.
</para>
</sect4>
<sect4 id="releasemanager">
<title>Publicly appoint someone as the release manager for a
specific release</title>
<para>
A release manager is usually responsible for coordinating
testing, enforcing a code freeze, being responsible for
stability and quality control, packaging up the software, and
placing it in the appropriate places to be downloaded.
</para>
<para>
This use of the release manager is a good way to give yourself a
break and to shift the responsibility for accepting and
rejecting patches onto someone else. It is a good way of very
clearly defining a chunk of work on the project as belonging to
a certain person and its a great way of giving yourself room to
breath.
</para>
</sect4>
<sect4 id="delegatebranch">
<title>Delegate control of an entire branch</title>
<para>
If your project chooses to have branches (as described in <xref
linkend="branches">), 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.
</para>
<para>
The author of Linux, Linus Torvalds, came out and crowned Alan
Cox as <quote>the man for stable kernels.</quote> 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.
</para>
</sect4>
</sect3>
</sect2>
<!-- Section2: patching -->
<sect2 id="patching">
<title>Accepting and Rejecting Patches</title>
<para>
This HOWTO has already touched on the fact that as the maintainer
of a free software project, one of your primary and most important
responsibilities will be accepting and rejecting patches submitted
to you by other developers.
</para>
<sect3>
<title>Encouraging Good Patching</title>
<para>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
<citetitle>Good Patching Practice</citetitle> in the
<citetitle>Software Release Practices HOWTO</citetitle><xref
linkend="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
<emphasis>like</emphasis> 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 <quote>right way.</quote>
</para>
</sect3>
<sect3>
<title>Technical judgment</title>
<para>
In <emphasis>Open Source Development with CVS</emphasis>, Karl
Fogel makes a convincing argument that the most important things
to keep in mind when rejecting or accepting patches are:
</para>
<para>
<itemizedlist>
<listitem>
<para>A firm knowledge of the scope of your program (that's the
<quote>idea</quote> I talked about in <xref linkend="chooseproject">);</para>
</listitem>
<listitem>
<para>The ability to recognize, facilitate, and direct
<quote>evolution</quote> of your program so that the program
can grow and change and incorporate functionality that was
originally unforeseen;</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</itemizedlist>
</para>
<para>
These are the criteria that you as a project maintainer should
take into account each time you receive a patch.
</para>
<para>
Fogel elaborates on this and states the <quote>the
questions to ask yourself when considering whether to implement
(or approve) a change are:</quote>
</para>
<para>
<itemizedlist>
<listitem>
<para>Will it benefit a significant percentage of the program's
user community?</para>
</listitem>
<listitem>
<para>Does it fit within the program's domain or within a
natural, intuitive extension of that domain?</para>
</listitem>
</itemizedlist>
</para>
<para>
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 the answer to either
of those questions is <quote>no,</quote> 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.
</para>
</sect3>
<sect3>
<title>Rejecting patches</title>
<para>
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
<xref linkend="developers"> and in <xref linkend="delegation">)
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):
</para>
<sect4>
<title>Bring it to the community</title>
<para>
One of the best ways of justifying a decision to reject a patch
and working to not seem like you keep an iron grip on your
project is by not making the decision alone at all. It might
make sense to turn over larger proposed changes or more
difficult decisions to a development mailing list where they can
be discussed and debated. There will be some patches (bug fixes,
etc.) which will definitely be accepted and some that you feel
are so off base that they do not even merit further
discussion. It is those that fall into the gray area between
these two groups that might merit a quick forward to a mailing
list.
</para>
<para>
I recommend this process wholeheartedly. As the project
maintainer you are worried about making the best decision for
the project, for the project's users and developers, and for
yourself as a responsible project leader. Turning things over to
an email list will demonstrate your own responsibility and
responsive leadership as it tests and serves the interests of
your software's community.
</para>
</sect4>
<sect4>
<title>Technical issues are not always good justification</title>
<para>
Especially toward the beginning of your project's life, you
will find that many changes are difficult to implement,
introduce new bugs, or have other technical problems. Try to see
past these. Especially with added functionality, good ideas do
not always come from good programmers. Technical merit is a
valid reason to postpone an application of a patch but it is not
always a good reason to reject a change outright. Even small
changes are worth the effort of working with the developer
submitting the patch to iron out bugs and incorporate the change
if you think it seems like a good addition to your project. The
effort on your part will work to make your project a community
project and it will pull a new or less experienced developer
into your project and even teach them something that might help
them in making their next patch.
</para>
</sect4>
<sect4>
<title>Common courtesy</title>
<para>
It should go without saying but, <emphasis>above all and in all
cases, just be nice.</emphasis> If someone has an idea and cares
about it enough to write some code and submit a patch, they
care, they are motivated, and they are already involved. Your
goal as the maintainer is make sure they submit again. They may
have thrown you a dud this time but next time may be the idea or
feature that revolutionizes your project.
</para>
<para>
It is your responsibility to first justify your choice to not
incorporate their change clearly and concisely. Then thank
them. Let them know that you a appreciate their help and feel
horrible that you can't incorporate their change. Let them know
that you look forward to their staying involved and you hope
that the next patch or idea meshes better with your project
because you appreciate their work and want to see it in your
application. If you have ever had a patch rejected after putting
a large deal of time, thought, and energy into it, you remember
how it feels and it feels bad. Keep this in mind when you have
to let someone down. It's never easy but you need to do
everything you can to make it as not-unpleasant as possible.
</para>
</sect4>
</sect3>
</sect2>
<!-- Section2: branches -->
<sect2 id="branches">
<title>Stable and Development Branches</title>
<para>
The idea of stable and development branches has already been
described briefly in <xref linkend="chooseversioning"> and in
<xref linkend="delegatebranch">. 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 <xref linkend="patching">) by
allowing you to temporarily compromise the stability of your
project without affecting those users who need that stability.
</para>
<para>
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 <xref
linkend="chooseversioning">. In this model, there is
<emphasis>always</emphasis> one branch that is stable and always
one that is in development. Before any new release, the
development branch goes into a <quote>feature freeze</quote> as
described in <xref linkend="freezing"> 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.
</para>
<para>
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.
</para>
<para>
In trying to set up a development tree for yourself, there are
several things that might be useful to keep in mind:
</para>
<para>
<variablelist>
<varlistentry>
<term>Minimize the number of branches</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Make sure that all your different branches are explained</term>
<listitem>
<para>As I mentioned in the preceding paragraph, different
branches <emphasis>will</emphasis> 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 <acronym>FTP</acronym> or
web directory.</para>
<para>
I might also recommend against a mistake that I think Debian
has made. The terms <quote>unstable,</quote>
<quote>testing,</quote> and <quote>experimental</quote> are
vague and difficult to rank in order of stability (or
instability as the case may be). Try explaining to someone
that <quote>stable</quote> actually means <quote>ultra
stable</quote> and that <quote>unstable</quote> doesn't
actually include any unstable software but is really stable
software that is untested as a distribution.
</para>
<para>
If you are going to use branches, especially early on, keep in
mind that people are conditioned to understand the terms
<quote>stable</quote> and <quote>development</quote> and you
probably can't go wrong with this simple and common division of
branches.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Make sure all your branches are always available</term>
<listitem>
<para>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 <acronym>FTP</acronym> 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
<quote>stable,</quote> <quote>unstable</quote> and
<quote>frozen</quote> 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.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect2>
<!-- Section2: otherdev -->
<sect2 id="otherdev">
<title>Other Project Management issues</title>
<para>
There are more issues surrounding interaction with developers in a
free software project that I can not touch on in great detail in a
HOWTO of this size and scope. Please don't hesitate to contact me if you see
any major omissions.
</para>
<para>
Other smaller issues that are worth mentioning are:
</para>
<sect3 id="freezing">
<title>Freezing</title>
<para>
For those projects that choose to adopt a split development model
(<xref linkend="branches">), freezing is a concept that is worth
becoming familiar with.
</para>
<para>
Freezes come in two major forms. A <quote>feature freeze</quote>
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
<quote>one more feature</quote> 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.
</para>
<para>
The second type of freeze is a <quote>code freeze</quote> which
is much more like a released piece of software. Once a piece of
software has entered a <quote>code freeze,</quote> all changes to
the code are discouraged and only changes that fix known bugs
are permitted. This type of freeze usually follows a
<quote>feature freeze</quote> and directly precedes a
release. Most released software is in what could be interpreted
as a sort of high level <quote>code freeze.</quote>
</para>
<para>
Even if you never choose to appoint a release manager (<xref
linkend="releasemanager">), you will have an easier time
justifying the rejection or postponement of patches (<xref
linkend="patching">) before a release with a publicly stated
freeze in effect.
</para>
</sect3>
</sect2>
<sect2>
<title>Forks</title>
<para>
I wasn't sure about how I would deal with forking in this
document (or if I would deal with forking at all). A fork is when
a group of developers takes code from a free software project and
actually starts a brand new free software project with it. The
most famous example of a fork was between Emacs and XEmacs. Both
emacsen are based on an identical code-base but for technical,
political, and philosophical reasons, development was split into
two projects which now compete with each other.
</para>
<para>
The short version of the fork section is, <emphasis>don't do
them.</emphasis> Forks force developers to choose one project to
work with, cause nasty political divisions, and redundancy of
work. Luckily, usually the threat of the fork is enough to scare
the maintainer or maintainers of a project into changing the way
they run their project.
</para>
<para>
In his chapter on <quote>The Open Source Process,</quote> Karl
Fogel describes how to do a fork if you absolutely must. If you
have determined that is absolutely necessary and that the
differences between you and the people threatening to fork are
absolutely unresolvable, I recommend Fogel's book as a good place
to start.
</para>
</sect2>
</sect1>
<!-- Section1: users -->
<sect1 id="users">
<title>Maintaining a Project: Interacting with Users</title>
<indexterm>
<primary>fswd!users</primary>
</indexterm>
<para>
If you've worked your way up to here, congratulations, you are
nearing the end of this document. This final section describes some
of the situations in which you, in your capacity as project
maintainer, will be interacting with users. It gives some
suggestions on how these situations might be handled effectively.
</para>
<para>
Interacting with users is difficult. In our discussion of
interaction with developers, the underlying assumption is that in a
free software project, a project maintainer must constantly strive to
attract and keep developers who can easily leave at any time.
</para>
<para>
Users in the free software community are different than developers
and are also different than users in the world of proprietary
software and they should be treated differently than either
group. Some ways in which the groups differ significantly follow:
</para>
<para>
<itemizedlist>
<listitem>
<para>The lines between users and developers are blurred in ways
that is totally foreign to any proprietary development
model. Your users are often your developers and vice
versa.</para>
</listitem>
<listitem>
<para>In the free software world, you are often your users' only
choice. Because there is such an emphasis on not replicating the
work of others in the free software community and because the
element of competition present in the propriety software model is
absent (or at least in an extremely different form) in the free
software development model, you will probably be the only project
that does what you do (or at least the only one that does what
you do in the way that you do it). This means your responsiveness
to your users is even more important than in the proprietary
software world.</para>
</listitem>
<listitem>
<para>In an almost paradoxical situation, free software projects
have less immediate or dire consequences for ignoring their users
altogether. It is also often easier to do. Because you don't
usually need to compete with another product, chances are good
that you will not be scrambling to gain the features of your
competitor's newest program. This means that your development
process will have to be directed either internally, by a
commitment to your users, or through both.</para>
</listitem>
</itemizedlist>
</para>
<para>
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.
</para>
<!-- Section2: testing -->
<sect2 id="testing">
<title>Testing and Testers</title>
<para>
In addition to your users being your developers, they are also
(and perhaps more commonly) your testers. Before I get flamed, I
should rephrase my sentence: <emphasis>some of your
users</emphasis> (those who explicitly volunteer) are your
testers.
</para>
<para>
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 <xref linkend="branches">) might come in handy.
</para>
<para>
<quote><ulink
url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
Projects the Open Source Way</ulink></quote> describes what a
good test should look for:
</para>
<variablelist>
<varlistentry>
<term>Boundary conditions</term>
<listitem>
<para>Maximum buffer lengths, data conversions, upper/lower
boundary limits, and so on.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Inappropriate behavior</term>
<listitem>
<para>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 <quote>what if</quote> questions
and think of anything that <emphasis>might</emphasis> fail or
<emphasis>might</emphasis> go wrong and find out what your
program would do in those cases.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Graceful failure</term>
<listitem>
<para>The answer to a number of the <quote>what if</quote>
questions above is probably <quote>failure</quote> 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Standards conformance</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
</variablelist>
<sect3>
<title>Automated testing</title>
<para>
For many programs, many common mistakes can be caught by
automated means. Automated tests tend to be pretty good at
catching errors that you've run into several times before or
the things you just forget. They are not very good at finding
errors, even major ones, that are totally unforeseen.
</para>
<para>
CVS comes with a Bourne shell script called sanity.sh that is
worth looking at. Debian uses a program called lintian that
checks Debian packages for all of the most common errors. While
use of these scripts may not be helpful, there is a host of other
sanity checking software on the net that may be applicable (feel
free to email me any recommendations). None of these will create
a bug-free release but they will avoid at least some major
oversights. Finally, if your programs become a long term
endeavor, you will find that there are certain errors that you
tend to make over and over. Start a collection of scripts that
check for these errors to help keep them out of future releases.
</para>
</sect3>
<sect3>
<title>Testing by testers</title>
<para>
For any program that depends on user interactivity, many bugs
will only be uncovered through testing by users actually clicking
the keys and pressing the mouse buttons. For this you need
testers and as many as possible.
</para>
<para>
The most difficult part of testing is finding testers. It's
usually a good tactic to post a message to a relevant mailing
list or news group announcing a specific proposed release date
and outlining the functionality of your program. If you put some
time into the announcement, you are sure to get a few responses.
</para>
<para>
The second most difficult part of testing is
<emphasis>keeping</emphasis> your testers and keeping them
actively involved in the testing process. Fortunately, there are
some tried and true tactics that can applied toward this end:
</para>
<para>
<variablelist>
<varlistentry>
<term>Make things simple for your testers</term>
<listitem>
<para>Your testers are doing you a favor so make it as easy as
possible for them. This means that you should be careful to
package your software in a way that is easy to find, unpack,
install, and uninstall. This also means you should explain
what you are looking for to each tester and make the means for
reporting bugs simple and well established. The key is to
provide as much structure as possible to make your testers'
jobs easy and to maintain as much flexibility as possible for
those that want to do things a little differently.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Be responsive to your testers</term>
<listitem>
<para>When your testers submit bugs, respond to them and
respond quickly. Even if you are only responding to tell them
that the bug has already been fixed, quick and consistent
responses make them feel like their work is heard, important,
and appreciated.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Thank your testers</term>
<listitem>
<para>Thank them personally each time they send you
patch. Thank them publicly in the documentation and the about
section of your program. You appreciate your testers and your
program would not be possible without their help. Make sure
they know it. Publicly, pat them on the back to make sure the rest of
the world knows it too. It will be appreciated more than you
expected.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect3>
</sect2>
<!-- Section2: support -->
<sect2 id="support">
<title>Setting up Support Infrastructure</title>
<para>
While testing is important, the large part of your interactions
and responsibility to your users falls under the category of
support. The best way to make sure your users are adequately
supported in using your program is to set up a good infrastructure
for this purpose so that your developers and users help each other
and less of the burden falls on you. This way, people will also
get quicker and better responses to their questions. This
infrastructure comes in several major forms:
</para>
<sect3>
<title>Documentation</title>
<para>
It should not come as any surprise that the key element to any
support infrastructure is good documentation. This topic was
largely covered in <xref linkend="documentation"> and will not be
repeated here.
</para>
</sect3>
<sect3 id="mailinglists">
<title>Mailing lists</title>
<para>
Aside from documentation, effective mailing lists will be your
greatest tool in providing user support. Running a mailing list
well is more complicated than installing mailing list software
onto a machine.
</para>
<sect4>
<title>Separate lists</title>
<para>
A good idea is too separate your user and development mailing
lists (perhaps into project-user@host and project-devel@host)
and enforce the division. If people post a development question
onto -user, politely ask them to repost it onto -devel and vise
versa. Subscribe yourself to both groups and encourage all
primarily developers to do the same.
</para>
<para>
This system provides so that no one person is stuck doing all of
the support work and works so that users learn more about the
program, they can help newer users with their questions.
</para>
</sect4>
<sect4>
<title>Choose mailing list software well</title>
<para>
Please don't make the selection of mailing list software
impulsively. Please consider easy accessibility by users without
a lot of technical experience so you want to be as easy as
possible. Web accessibility to an archive of the list is also
important.
</para>
<para>
The two biggest free software mailing list programs are <ulink
url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
and <ulink url="http://www.list.org/">GNU Mailman</ulink>. 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.
</para>
<para>
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.
</para>
</sect4>
</sect3>
<sect3>
<title>Other support ideas</title>
<para>
A mailing list and accessible documentation are far from all you
can do to set up good user support infrastructure. Be
creative. If you stumble across something that works well, email me
and I'll include it here.
</para>
<sect4>
<title>Make your self accessible</title>
<para>
You can not list too few methods to reach you. If you hang out
in an <acronym>IRC</acronym> channel, don't hesitate to list it
in your projects documentation. List email and snailmail
addresses, and ways to reach you via <acronym>ICQ</acronym>,
<acronym>AIM</acronym>, or Jabber if they apply.
</para>
</sect4>
<sect4>
<title>Bug management software</title>
<para>
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 <ulink
url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
(<acronym>BTS</acronym>) 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 <ulink
url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
which has become extremely possible and which I like a lot.
</para>
<para>
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.
</para>
</sect4>
</sect3>
</sect2>
<!-- Section2: releasing -->
<sect2 id="releasing">
<title>Releasing Your Program</title>
<para>
As mentioned earlier in the HOWTO, the first rule of releasing is,
<emphasis>release something useful.</emphasis> Non-working or
not-useful software will not attract anyone to your
project. People will be turned off of your project and will be likely
to simply gloss over it next time they see a new version
announced. Half-working software, if useful, will intrigue people,
whet their appetites for versions to come, and encourage them to
join the development process.
</para>
<sect3>
<title>When to release</title>
<para>
Making the decision to release your software for the first time
is an incredibly important and incredibly stressful decision. But
it needs to done. My advice is to try and make something that
is complete enough to be usable and incomplete enough to allow
for flexibility and room for imagination by your future
developers. It's not an easy decision. Ask for help on a local
Linux User Group mailing list or from a group of developer
friends.
</para>
<para>
One tactic is to first do an <quote>alpha</quote> or
<quote>beta</quote> release as described below in <xref
linkend="alphabeta">. However, most of the guidelines described
above still apply.
</para>
<para>
<emphasis>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.</emphasis>
</para>
<para>
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, <ulink
url="http://www.advogato.org/article/196.html"><quote>Free
Software Project Management</quote></ulink> for maintaining a
good release cycle. He recommends that you ask yourself,
<quote>does this release...</quote>
</para>
<para>
<itemizedlist>
<listitem>
<para>Contain sufficient new functionality or bug fixes to be
worth the effort.</para>
</listitem>
<listitem>
<para>Be spaced sufficiently far apart to allow the user time
to work with the latest release.</para>
</listitem>
<listitem>
<para>Be sufficiently functional so that the user can get work
done (quality).</para>
</listitem>
</itemizedlist>
</para>
<para>
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.
</para>
</sect3>
<sect3>
<title>How to release</title>
<para>
If you've followed the guidelines described in this HOWTO up
until this point, the mechanics of doing a release are going to
be the easy part of releasing. If you have set up consistent
distribution locations and the other infrastructure described in
the preceding sections, releasing should be as simple as building
the package, checking it once over, and uploading it into the
appropriate place and then making your website reflect the
change.
</para>
</sect3>
<sect3 id="alphabeta">
<title>Alpha, beta, and development releases</title>
<para>
When contemplating releases, it worth considering the fact that
not every release needs to be a full numbered release. Software
users are accustomed to pre-releases but you must be careful to
label these releases accurately or they will cause more problems then
they are worth.
</para>
<para>
The observation is often made that many free software developers
seem to be confused about the release cycle. <quote><ulink
url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
Projects the Open Source Way</ulink></quote> suggests that you memorize
the phrase, <quote>Alpha is not Beta. Beta is not Release</quote>
and I'd agree that tis is a probably a good idea.
</para>
<para>
<variablelist>
<varlistentry>
<term>alpha releases</term>
<listitem>
<para>Alpha software is feature-complete but sometimes only
partially functional.</para>
<para>Alpha releases are expected to be unstable, perhaps a
little unsafe, but definitely usable. They
<emphasis>can</emphasis> have known bugs and kinks that have
yet to be worked out. Before releasing an alpha, be sure to
keep in mind that <emphasis>alpha releases are still
releases</emphasis> 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>beta releases</term>
<listitem>
<para>Beta software is feature-complete and functional, but is
in the testing cycle and still has a few bugs left to be
ironed out.</para>
<para>Beta releases are general expected to be usable and
slightly unstable, although definitely <emphasis>not
unsafe.</emphasis> 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
<emphasis>something.</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term>development releases</term>
<listitem>
<para><quote>Development release</quote> is much a more vague
term than <quote>alpha</quote> or <quote>beta</quote>. 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 <ulink
url="http://www.enlightenment.org">Enlightenment</ulink> has
released <emphasis>nothing but</emphasis> 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.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect3>
</sect2>
<!-- Section2: announcing -->
<sect2 id="announcing">
<title>Announcing Your Project</title>
<para>
Well, you've done it. You've (at least for the purposes of this
HOWTO) designed, built, and released your free software
project. All that is left is for you to tell the world so they
know to come and try it out and hopefully jump on board with
development. If everything is in order as described above, this
will be a quick and painless process. A quick announcement is all
that it takes to put yourself on the free software community's
radar screen.
</para>
<sect3>
<title>Mailing lists and Usenet</title>
<para>Announce your software on Usenet's <ulink
url="news:comp.os.linux.announce">comp.os.linux.announce</ulink>. If
you only announce your software in two places, have it be c.o.l.a
and freshmeat.</para>
<para>
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.</para>
<para>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:
</para>
<screen>Subject: ANN: aub 1.0, a program to assemble Usenet binaries</screen>
<para>
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.
</para>
<para>
You should repeat this announcement process consistently in the
same locations for each subsequent release.
</para>
</sect3>
<sect3>
<title>freshmeat.net</title>
<para>
Mentioned earlier in <xref linkend="evalwhere">, in today's free
software community, announcements of your project on freshmeat
are almost more important than announcements on mailing lists.
</para>
<para>
Visit the <ulink url="http://freshmeat.net">freshmeat.net
website</ulink> or their <ulink
url="http://freshmeat.net/add-project/">submit project
page</ulink> 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).
</para>
</sect3>
<sect3>
<title>Project Mailing List</title>
<para>If you've gone ahead and created mailing lists for your
project, you should always announce new versions on these
lists. I've found that for many projects, users request a very
low-volume announce only mailing list to be notified when new
versions are released. freshmeat.net now allows users to subscribe
to a particular project so they receive emails every time a new
version is announced through their system. It's free and it can
stand in for an announce-only mailing list. In my opinion, it
can't hurt.</para>
</sect3>
</sect2>
</sect1>
<bibliography>
<bibliodiv>
<title>Printed Books</title>
<biblioentry>
<biblioset>
<author>
<surname>Fogel</surname>
<firstname>Karl</firstname>
</author>
<title>Open Source Development with CVS</title>
<publisher>
<publishername>Coriolois Open Press</publishername>
</publisher>
<pubdate>1999</pubdate>
<isbn>1-57610-490-7</isbn>
<abstract>
<para>
Fogel's <quote>guide to using CVS in the free software
world</quote> is much more than its subtitle. In the publisher's
own words: <quote><emphasis>Open Source Development with
CVS</emphasis> is one of the first books available that teaches
you development and implementation of Open Source
software.</quote> It also includes the best reference and
tutorial to CVS I have ever seen. It is the book that was
<emphasis>so good</emphasis> 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.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry
<biblioset>
<author>
<surname>Lessig</surname>
<firstname>Lawrence</firstname>
</author>
<title>Code and Other Laws of Cyberspace</title>
<publisher>
<publishername>Basic Books</publishername>
</publisher>
<pubdate>2000</pubdate>
<isbn>0-465-03913-8</isbn>
<abstract>
<para>
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 <quote>open code</quote> 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 <emphasis>need</emphasis>
free software in a way more powerfully than anything I've read
outside of <ulink
url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
<quote>Right to Read.</quote></ulink>
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Raymond</surname>
<firstname>Eric</firstname>
</author>
<title>The Cathedral and the Bazaar</title>
<subtitle>Musings on Linux and Open Source by an Accidental Revolutionary</subtitle>
<publisher>
<publishername>O'Reilly</publishername>
</publisher>
<pubdate>1999</pubdate>
<isbn>1-56592-724-9</isbn>
<abstract>
<para>
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
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.
</para>
</abstract>
</biblioset>
</biblioentry>
</bibliodiv>
<bibliodiv>
<title>Web-Accessible Resources</title>
<para>
This is a list of the web resources pertaining to this HOWTO that
I've found most helpful in compiling this information. If you know
of others that would help, please don't hesitate to email me at
<email>mako@debian.org</email> and we can look into getting it
added to the list and represented in the HOWTO.
</para>
<para>
I'd recommend that any free software developer (or potential one)
skim through these sites because they have each have a lot to say.
</para>
<biblioentry>
<biblioset>
<author>
<surname>Dafermos</surname>
<firstname>George</firstname>
<othername>N</othername>
</author>
<title><ulink url="http://firstmonday.org/issues/issue6_11/dafermos/">Management and Virtual Decentralized Networks: The Linux Project</ulink></title>
<abstract>
<para>Since the paper includes its own abstract, I thought I
would include it here verbatim:</para>
<para><blockquote><para>This paper examines the latest of
paradigms - the Virtual Network(ed) Organisation - and whether
geographically dispersed knowledge workers can virtually
collaborate for a project under no central
planning. Co-ordination, management and the role of knowledge
arise as the central areas of focus. The Linux Project and its
development model are selected as a case of analysis and the
critical success factors of this organisational design are
identified. The study proceeds to the formulation of a
framework that can be applied to all kinds of virtual
decentralised work and concludes that value creation is
maximized when there is intense interaction and uninhibited
sharing of information between the organisation and the
surrounding community. Therefore, the potential success or
failure of this organisational paradigm depends on the degree
of dedication and involvement by the surrounding
community.</para></blockquote></para>
<para>This paper was referred to me in my capacity as author of
this HOWTO and I was very impressed. It's written by a graduate
student in management and I think it succeeds at evaluating the
Linux project as an example of a new paradigm in management--one
that <emphasis>you</emphasis> will be placing yourself at the
center of in your capacity as maintainer of a free software
project.</para>
<para>As a developer trying to control an application and guide
it to success in the free software world, I'm not sure how
useful Dafermos's argument is. It does however, provide a
theoretical justification for my HOWTO--free software project
management <emphasis>is</emphasis> a different creature than
proprietary software project management. If you are interested
in the conceptual and theoretical ways that free software
project management differs from other types of management, this
is a great paper to read. If this paper answers questions of
<quote>how?</quote>, Dafermos answers the (more difficult to
defend) questions of <quote>why?</quote> and does a very good
job.</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Gabriel</surname>
<firstname>Richard</firstname>
</author>
<title><ulink
url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
<quote>Worse is Better</quote></ulink></title>
<abstract>
<para>
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.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Manley</surname>
<firstname>Montey</firstname>
</author>
<title><ulink
url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
Projects the Open Source Way</ulink></title>
<publisher>
<publishername><ulink
url="http://www.linuxprogramming.com">Linux
Programming</ulink></publishername>
</publisher>
<pubdate>Oct 31, 2000</pubdate>
<abstract>
<para>
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.
</para>
<para>
I have problems much of this piece and I recommend you read
<xref linkend="krawitz"> at the same time you read Monty's
article for a good critique.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry id="esrhowto">
<biblioset>
<author>
<surname>Raymond</surname>
<firstname>Eric</firstname>
<othername>Steven</othername>
</author>
<title><ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">Software Release Practice HOWTO</ulink></title>
<abstract>
<para>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 (<quote>name this file this, not
this</quote>) while this HOWTO speaks more conceptually. There
are several sections that are extremely similar. It's also
<emphasis>much</emphasis> shorter.</para>
<para>My favorite quote from his HOWTO is: <quote>"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.</quote> Oh really? Perhaps I just do a poor job.</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry id="cvsbestpractices">
<biblioset>
<author>
<surname>Venugopalan</surname>
<firstname>Vivek</firstname>
</author>
<title><ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html">CVS Best Practices</ulink></title>
<abstract>
<para>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.</para>
<para>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.</para>
</abstract>
</biblioset>
</biblioentry>
</bibliodiv>
<bibliodiv>
<title>Advogato Articles</title>
<para>
I've found that one of the best resources that any free software
developer has at his or her disposal is Advogato.org. If you haven't
yet had a chance to visit <ulink url="http://www.advogato.org">the
website</ulink>, do.
</para>
<para>
I have spent a huge amount of time on Advogato and I've gone
through and provided links to the articles that I think might be
of particular interest to anyone reading this HOWTO. I think that
skimming through these links can be helpful and I promise that if
you do, you'll learn a lot. You will learn that my idea of how a
free software project should be run is not the
<emphasis>only</emphasis> idea. I think that's important.
</para>
<para>
If nothing else, there is <emphasis>way</emphasis> more
information on that website than I could ever fit into, or
reference from this HOWTO. I have listed what I think are the most
relevant articles here with short descriptions that I've written.
</para>
<biblioentry>
<biblioset>
<author>
<surname>Hindle</surname>
<firstname>Stephen</firstname>
</author>
<title><ulink url="http://www.advogato.org/article/262.html">'Best Practices' for Open Source?</ulink></title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>March 21, 2001</pubdate>
<abstract>
<para>
Touching mostly on programming practice (as most articles on
the subject usually do), the article talks a little about
project management (<quote>Use it!</quote>) and a bit about
communication within a free software project.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Cohen</surname>
<firstname>Bram</firstname>
</author>
<title><ulink
url="http://www.advogato.org/article/258.html"></ulink>How to
Write Maintainable Code</title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>March 15, 2001</pubdate>
<abstract>
<para>
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.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry id="krawitz">
<biblioset>
<author>
<surname>Krawitz</surname>
<firstname>Robert</firstname>
</author>
<title><ulink url="http://www.advogato.org/article/196.html">Free
Source Project Management</ulink></title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>November 4, 2000</pubdate>
<abstract>
<para>
This article made me happy because it challenged many of the
problems that I had with Monty's article on <ulink
url="http://www.linuxprogramming.com">LinuxProgramming</ulink>. 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.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Martins</surname>
<firstname>Lalo</firstname>
</author>
<title><ulink url="http://www.advogato.org/article/128.html">Ask
the Advogatos: why do Free Software projects
fail?</ulink></title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>July 20, 2000</pubdate>
<abstract>
<para>
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.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Burley</surname>
<firstname>David</firstname>
</author>
<title><ulink
url="http://www.advogato.org/article/107.html">In-Roads to Free
Software Development</ulink></title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>June 14, 2000</pubdate>
<abstract>
<para>
This document was written as a response to <ulink
url="http://www.advogato.org/article/72.html">another Advogato
article</ulink>. 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).
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Moorman</surname>
<firstname>Jacob</firstname>
</author>
<title><ulink url="http://www.advogato.org/article/72.html">Importance of
Non-Developer Supporters in Free Software</ulink></title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>April 16, 2000</pubdate>
<abstract>
<para>
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.
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Orchard</surname>
<firstname>Leslie</firstname>
</author>
<title><ulink url="http://www.advogato.org/article/67.html">On
Naming an Open Source Project</ulink></title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>April 12, 2000</pubdate>
<abstract>
<para>
I didn't even have a section on project naming in this HOWTO
(See <xref linkend="naming">) until Leslie Orchard's article
reminded me of it. Thanks to Leslie for writing this article!
</para>
</abstract>
</biblioset>
</biblioentry>
<biblioentry>
<biblioset>
<author>
<surname>Allen</surname>
<firstname>David</firstname>
</author>
<title><ulink url="http://www.advogato.org/article/40.html">Version Numbering Madness</ulink></title>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<pubdate>February 28, 2000</pubdate>
<abstract>
<para>
In this article, David Allen challenges the whole
<quote>Major.Minor.Patch</quote> version numbering scheme. Its
good to read this as you read <xref
linkend="chooseversioning">. I liked the article and it
describes some of the projects that I bring up in my discussion
of version numbering.
</para>
</abstract>
</biblioset>
</biblioentry>
</bibliodiv>
</bibliography>
<!--
The GNU Free Documentation License 1.1 in DocBook
Markup by Eric Baudais <baudais@okstate.edu>
Maintained by the GNOME Documentation Project
http://developer.gnome.org/projects/gdp
Version: 1.0.1
Last Modified: Nov 16, 2000
-->
<appendix id="fdl">
<docinfo>
<releaseinfo>
Version 1.1, March 2000
</releaseinfo>
<copyright>
<year>2000</year><holder>Free Software Foundation, Inc.</holder>
</copyright>
<legalnotice id="fdl-legalnotice">
<para>
<address>Free Software Foundation, Inc. <street>59 Temple Place,
Suite 330</street>, <city>Boston</city>, <state>MA</state>
<postcode>02111-1307</postcode> <country>USA</country></address>
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
</para>
</legalnotice>
</docinfo>
<title>GNU Free Documentation License</title>
<simplesect id="fdl-preamble">
<title>0. PREAMBLE</title>
<para>
The purpose of this License is to make a manual, textbook, or
other written document <quote>free</quote> in the sense of
freedom: to assure everyone the effective freedom to copy and
redistribute it, with or without modifying it, either
commercially or non-commercially. Secondarily, this License
preserves for the author and publisher a way to get credit for
their work, while not being considered responsible for
modifications made by others.
</para>
<para>
This License is a kind of <quote>copyleft</quote>, which means
that derivative works of the document must themselves be free in
the same sense. It complements the GNU General Public License,
which is a copyleft license designed for free software.
</para>
<para>
We have designed this License in order to use it for manuals for
free software, because free software needs free documentation: a
free program should come with manuals providing the same
freedoms that the software does. But this License is not limited
to software manuals; it can be used for any textual work,
regardless of subject matter or whether it is published as a
printed book. We recommend this License principally for works
whose purpose is instruction or reference.
</para>
</simplesect>
<simplesect id="fdl-simplesect1">
<title>1. APPLICABILITY AND DEFINITIONS</title>
<para id="fdl-document">
This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be
distributed under the terms of this License. The
<quote>Document</quote>, below, refers to any such manual or
work. Any member of the public is a licensee, and is addressed
as <quote>you</quote>.
</para>
<para id="fdl-modified">
A <quote>Modified Version</quote> of the Document means any work
containing the Document or a portion of it, either copied
verbatim, or with modifications and/or translated into another
language.
</para>
<para id="fdl-secondary">
A <quote>Secondary Section</quote> is a named appendix or a
front-matter section of the <link
linkend="fdl-document">Document</link> 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.
</para>
<para id="fdl-invariant">
The <quote>Invariant Sections</quote> are certain <link
linkend="fdl-secondary"> Secondary Sections</link> whose titles
are designated, as being those of Invariant Sections, in the
notice that says that the <link
linkend="fdl-document">Document</link> is released under this
License.
</para>
<para id="fdl-cover-texts">
The <quote>Cover Texts</quote> are certain short passages of
text that are listed, as Front-Cover Texts or Back-Cover Texts,
in the notice that says that the <link
linkend="fdl-document">Document</link> is released under this
License.
</para>
<para id="fdl-transparent">
A <quote>Transparent</quote> copy of the <link
linkend="fdl-document"> Document</link> 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 <quote>Transparent</quote> is called
<quote>Opaque</quote>.
</para>
<para>
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.
</para>
<para id="fdl-title-page">
The <quote>Title Page</quote> 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, <quote>Title Page</quote> means the text near the
most prominent appearance of the work's title, preceding the
beginning of the body of the text.
</para>
</simplesect>
<simplesect id="fdl-section2">
<title>2. VERBATIM COPYING</title>
<para>
You may copy and distribute the <link
linkend="fdl-document">Document</link> 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 <link
linkend="fdl-section3">section 3</link>.
</para>
<para>
You may also lend copies, under the same conditions stated
above, and you may publicly display copies.
</para>
</simplesect>
<simplesect id="fdl-section3">
<title>3. COPYING IN QUANTITY</title>
<para>
If you publish printed copies of the <link
linkend="fdl-document">Document</link> numbering more than 100,
and the Document's license notice requires <link
linkend="fdl-cover-texts">Cover Texts</link>, 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
<link linkend="fdl-document">Document</link> and satisfy these
conditions, can be treated as verbatim copying in other
respects.
</para>
<para>
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.
</para>
<para>
If you publish or distribute <link
linkend="fdl-transparent">Opaque</link> copies of the <link
linkend="fdl-document">Document</link> numbering more than 100,
you must either include a machine-readable <link
linkend="fdl-transparent">Transparent</link> 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.
</para>
<para>
It is requested, but not required, that you contact the authors
of the <link linkend="fdl-document">Document</link> well before
redistributing any large number of copies, to give them a chance
to provide you with an updated version of the Document.
</para>
</simplesect>
<simplesect id="fdl-section4">
<title>4. MODIFICATIONS</title>
<para>
You may copy and distribute a <link
linkend="fdl-modified">Modified Version</link> of the <link
linkend="fdl-document">Document</link> under the conditions of
sections <link linkend="fdl-section2">2</link> and <link
linkend="fdl-section3">3</link> 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:
</para>
<itemizedlist mark="opencircle">
<listitem>
<formalpara>
<title>A</title>
<para>
Use in the <link linkend="fdl-title-page">Title
Page</link> (and on the covers, if any) a title distinct
from that of the <link
linkend="fdl-document">Document</link>, 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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>B</title>
<para>
List on the <link linkend="fdl-title-page">Title
Page</link>, as authors, one or more persons or entities
responsible for authorship of the modifications in the
<link linkend="fdl-modified">Modified Version</link>,
together with at least five of the principal authors of
the <link linkend="fdl-document">Document</link> (all of
its principal authors, if it has less than five).
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>C</title>
<para>
State on the <link linkend="fdl-title-page">Title
Page</link> the name of the publisher of the <link
linkend="fdl-modified">Modified Version</link>, as the
publisher.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>D</title>
<para>
Preserve all the copyright notices of the <link
linkend="fdl-document">Document</link>.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>E</title>
<para>
Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>F</title>
<para>
Include, immediately after the copyright notices, a
license notice giving the public permission to use the
<link linkend="fdl-modified">Modified Version</link> under
the terms of this License, in the form shown in the
Addendum below.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>G</title>
<para>
Preserve in that license notice the full lists of <link
linkend="fdl-invariant"> Invariant Sections</link> and
required <link linkend="fdl-cover-texts">Cover
Texts</link> given in the <link
linkend="fdl-document">Document's</link> license notice.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>H</title>
<para>
Include an unaltered copy of this License.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>I</title>
<para>
Preserve the section entitled <quote>History</quote>, and
its title, and add to it an item stating at least the
title, year, new authors, and publisher of the <link
linkend="fdl-modified">Modified Version </link>as given on
the <link linkend="fdl-title-page">Title Page</link>. If
there is no section entitled <quote>History</quote> in the
<link linkend="fdl-document">Document</link>, 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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>J</title>
<para>
Preserve the network location, if any, given in the <link
linkend="fdl-document">Document</link> for public access
to a <link linkend="fdl-transparent">Transparent</link>
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 <quote>History</quote>
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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>K</title>
<para>
In any section entitled <quote>Acknowledgements</quote> or
<quote>Dedications</quote>, 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.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>L</title>
<para>
Preserve all the <link linkend="fdl-invariant">Invariant
Sections</link> of the <link
linkend="fdl-document">Document</link>, unaltered in their
text and in their titles. Section numbers or the
equivalent are not considered part of the section titles.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>M</title>
<para>
Delete any section entitled
<quote>Endorsements</quote>. Such a section may not be
included in the <link linkend="fdl-modified">Modified
Version</link>.
</para>
</formalpara>
</listitem>
<listitem>
<formalpara>
<title>N</title>
<para>
Do not retitle any existing section as
<quote>Endorsements</quote> or to conflict in title with
any <link linkend="fdl-invariant">Invariant
Section</link>.
</para>
</formalpara>
</listitem>
</itemizedlist>
<para>
If the <link linkend="fdl-modified">Modified Version</link>
includes new front-matter sections or appendices that qualify as
<link linkend="fdl-secondary">Secondary Sections</link> 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 <link
linkend="fdl-invariant">Invariant Sections</link> in the
Modified Version's license notice. These titles must be
distinct from any other section titles.
</para>
<para>
You may add a section entitled <quote>Endorsements</quote>,
provided it contains nothing but endorsements of your <link
linkend="fdl-modified">Modified Version</link> 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.
</para>
<para>
You may add a passage of up to five words as a <link
linkend="fdl-cover-texts">Front-Cover Text</link>, and a passage
of up to 25 words as a <link
linkend="fdl-cover-texts">Back-Cover Text</link>, to the end of
the list of <link linkend="fdl-cover-texts">Cover Texts</link>
in the <link linkend="fdl-modified">Modified Version</link>.
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 <link linkend="fdl-document">Document</link>
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.
</para>
<para>
The author(s) and publisher(s) of the <link
linkend="fdl-document">Document</link> do not by this License
give permission to use their names for publicity for or to
assert or imply endorsement of any <link
linkend="fdl-modified">Modified Version </link>.
</para>
</simplesect>
<simplesect id="fdl-section5">
<title>5. COMBINING DOCUMENTS</title>
<para>
You may combine the <link linkend="fdl-document">Document</link>
with other documents released under this License, under the
terms defined in <link linkend="fdl-section4">section 4</link>
above for modified versions, provided that you include in the
combination all of the <link linkend="fdl-invariant">Invariant
Sections</link> of all of the original documents, unmodified,
and list them all as Invariant Sections of your combined work in
its license notice.
</para>
<para>
The combined work need only contain one copy of this License,
and multiple identical <link linkend="fdl-invariant">Invariant
Sections</link> 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.
</para>
<para>
In the combination, you must combine any sections entitled
<quote>History</quote> in the various original documents,
forming one section entitled <quote>History</quote>; likewise
combine any sections entitled <quote>Acknowledgements</quote>,
and any sections entitled <quote>Dedications</quote>. You must
delete all sections entitled <quote>Endorsements.</quote>
</para>
</simplesect>
<simplesect id="fdl-section6">
<title>6. COLLECTIONS OF DOCUMENTS</title>
<para>
You may make a collection consisting of the <link
linkend="fdl-document">Document</link> 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.
</para>
<para>
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.
</para>
</simplesect>
<simplesect id="fdl-section7">
<title>7. AGGREGATION WITH INDEPENDENT WORKS</title>
<para>
A compilation of the <link
linkend="fdl-document">Document</link> 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 <link linkend="fdl-modified">Modified Version</link>
of the Document, provided no compilation copyright is claimed
for the compilation. Such a compilation is called an
<quote>aggregate</quote>, 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 <link
linkend="fdl-cover-texts">Cover Text</link> requirement of <link
linkend="fdl-section3">section 3</link> 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.
</para>
</simplesect>
<simplesect id="fdl-section8">
<title>8. TRANSLATION</title>
<para>
Translation is considered a kind of modification, so you may
distribute translations of the <link
linkend="fdl-document">Document</link> under the terms of <link
linkend="fdl-section4">section 4</link>. Replacing <link
linkend="fdl-invariant"> Invariant Sections</link> 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.
</para>
</simplesect>
<simplesect id="fdl-section9">
<title>9. TERMINATION</title>
<para>
You may not copy, modify, sublicense, or distribute the <link
linkend="fdl-document">Document</link> 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.
</para>
</simplesect>
<simplesect id="fdl-section10">
<title>10. FUTURE REVISIONS OF THIS LICENSE</title>
<para>
The <ulink type="http"
url="http://www.gnu.org/fsf/fsf.html">Free Software
Foundation</ulink> 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 <ulink
type="http"
url="http://www.gnu.org/copyleft">http://www.gnu.org/copyleft/</ulink>.
</para>
<para>
Each version of the License is given a distinguishing version
number. If the <link linkend="fdl-document">Document</link>
specifies that a particular numbered version of this License
<quote>or any later version</quote> 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.
</para>
</simplesect>
</appendix>
</article>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:nil
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
View Git Blame Copy Permalink