Re-Read up through Ch1. Three chapters to reread and edit before a 0.1

[fspm_howto] / FreeSoftwareProjectManagementHOWTO.sgml

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">

<article>

<!-- Header -->

 <artheader>
  <title>Free Software Development 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.01</revnumber>
         <date>25 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 development
     and was written to act as a crash course in the people skills
     that aren't taught to commercial coders but that can make or
     break a free software project.
    </para>
  </abstract>

 </artheader>

<!-- Section1: intro -->

 <sect1 id="intro">
   <title>Introduction</title>

   <indexterm>
    <primary>fswd!introduction</primary>
   </indexterm>

  <para>
   For various reasons, this release has been code-named the
   <emphasis>homemade yogurt</emphasis> release.
  </para>

  <para>
   New code names will appear as per industry standard
   guidelines to emphasize the state-of-the-art-ness of this
   document.
  </para>

  <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 thing (probably too many), but it
   can't answer that question and won't attempt it. What this HOWTO
   will attempt to do is give your Free Software project a fighting
   chance--an edge. If you write a piece of crap that no one is
   interested in, you can read this HOWTO until you can recite it in
   your sleep and your project will probably fail. Then again, you can
   write a beautiful, relevant piece of software and follow every
   instruction in this HOWTO and your software may still not make
   it. Sometimes life is like that. However, I'll go out a limb and
   say that if you write a great, relevant pieces of software and
   ignore the advise in this HOWTO, you'll probably fail <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 Linux Documentation Project
    (LDP) license, stated below.
   </para>

   <para>
    Unless otherwise stated, Linux HOWTO documents are copyrighted by
    their respective authors. Linux HOWTO documents may be reproduced
    and distributed in whole or in part, in any medium physical or
    electronic, as long as this copyright notice is retained on all
    copies. Commercial redistribution is allowed and encouraged;
    however, the author would like to be notified of any such
    distributions.
   </para>

   <para>
    All translations, derivative works, or aggregate works
    incorporating any Linux HOWTO documents must be covered under this
    copyright notice. That is, you may not produce a derivative work
    from a HOWTO and impose additional restrictions on its
    distribution. Exceptions to these rules may be granted under
    certain conditions; please contact the Linux HOWTO coordinator at
    the address given below.
   </para>

   <para>
    In short, we wish to promote dissemination of this information
    through as many channels as possible. However, we do wish to
    retain copyright on the HOWTO documents, and would like to be
    notified of any plans to redistribute the HOWTOs.
   </para>

   <para>
    If you have any questions, please contact
    <email>linux-howto@metalab.unc.edu</email>
   </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 system.
    Proceed with caution, and although this is highly unlikely, the
    author(s) do 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>

   <para>
    You are strongly recommended to take a backup of your system 
    before major installation and backups at regular intervals.
   </para>
  </sect2>

<!-- Section2: newversions-->

  <sect2 id="newversions">
   <title>New Versions</title>

    <indexterm>
     <primary>fswd!news on</primary>
    </indexterm>

   <para>
    This is the initial release. It is written to be released to
    developers for critique and brainstorming and submitted to
    Hampshire College for academic credit. Please keep in mind that
    this version of the HOWTO is still in an infant stage and will be
    revised extensively before it hits the LDP.
   </para>

   <para>
    The latest version number of this document should always be listed
    on <ulink url="http://people.debian.org/~mako/">my webpage at
    Debian</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://people.debian.org/~mako/howto/fswd-howto.html">HTML</ulink>.
     </para>
    </listitem>

    <listitem>
     <para>
       <ulink URL="http://people.debian.org/~mako/howto/fswd-howto.txt">plain text</ulink>.
     </para>
    </listitem>

    <listitem>
     <para>
      <ulink url="http://people.debian.org/~mako/howto/fswd-howto.US.ps.gz">compressed 
       postscript (US letter format)</ulink>.
     </para>
    </listitem>

    <listitem>
     <para>
      <ulink url="http://people.debian.org/~mako/howto/fswd-howto.UF.ps.gz">compressed 
       postscript (Universal format / 8.27x11in; 210x279mm)</ulink>.
     </para>
    </listitem>

    <listitem>
     <para>
      <ulink url="http://people.debian.org/~mako/howto/fswd-howto.sgml">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>
    <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
    Source Development with CVS</emphasis> published by the Coriolis
    Open Press. Large parts of the 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 have ever seen. The rest of the book covers,
    "the challenges and philosophical issues inherent in running an
    Open Source project using CVS." The book does a good job of
    covering some of the subjects brought up in this HOWTO and much
    more. <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. I you are seriously
    interested in running a Free Software project, you want this
    book. I tried to mention Fogel in sections of this HOWTO where I
    knew I was borrowing directly from his ideas. If I missed any, I'm
    sorry, and I'll try and have those fixed in future versions.
   </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, Lawrence Lessig for reminding me of the
    importance of Free Software and finally, 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 how 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 towards 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 most certainly welcome for this document. Without your
    submissions and input, this document wouldn't exist. Something
    missing? Don't hesitate to contact me and to write a chapter or
    section, or subsection. I want this document to be a product of
    the Free Software development process that it heralds and I think
    its ultimate success will be rooted in this fact. 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 a translated version.
   </para>
   <para>
    However, this HOWTO is still young and I have to yet to be
    contacted about a translation so English is all that is currently
    available. If you would like to help with or do a translation, you
    will gain my utmost respect and admiration and you'll get to be
    part of a cool process. If you are at all interested, please don't
    hesitate to contact me at: <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, starting a project is most difficult
   part of successful free software development. Laying a firm
   foundation for your project 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 also involves a dilemma that you as a developer
   must try and deal with. No potential user for your program will be
   interested by a program that doesn't work. Simultaneously, the
   development process that you want to employ holds involvement of
   users as essential to the process of the development that will
   realize this working software.
  </para>

  <para>
   It is in these dangerous initial moments that anyone working to
   start a free software project must strike a balance. One of the
   most important ways that someone trying to start a project can work
   towards this balance is by establishing a framework for the
   development process through some of the ways 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 pretty
    good, it fills a gap by doing something that no other free
    software process does or or does it in a way that is unique
    enough to necessitate a separate project.
   </para>

   <sect3 id=identifyidea>
    <title>Identify and articulate your idea</title>
    <para>
     Eric S. Raymond writes about how free software projects start in
     his paper, "The Cathedral and the Bazaar" which comes as required
     reading for any free software development. You can find it <ulink
     url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
     </ulink>.
    </para>

    <para>
     In "The Cathedral and Bazaar," Raymond tells us that:
     <emphasis>Every good work of software starts by scratching a
     developers itch.</emphasis> Raymond 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 it is targeting a specific problem or itch you want to see
     scratched. <emphasis>This idea is the project. Articulate it
     clearly. Write it out. Describe the problem you will attack in
     detail. The success of your project in tackling a particular
     problem will be tied to your ability to identify that problem
     early on. Find out exactly what it is that you want your project
     to do.</emphasis>
    </para>
   </sect3>

   <sect3 id=evalulateidea>
    <title>Evaluate your idea</title>

    <para>
     In evaluating your idea, you need to ask yourself questions.
     Before you move any further into this HOWTO, you need to
     determine if the free software development model really is the
     right one for your project. Obviously, since the program
     scratches your itch, you are definitely interested in seeing it
     implemented in code. But, because one hacker coding alone fails
     to qualify as a free software development effort, you need to ask
     yourself the question: <emphasis>Is anybody else
     interested?</emphasis>
    </para>

    <para>
     Sometimes the answer is <emphasis>no</emphasis>. If you want to
     write a set of scripts to sort <emphasis>your</emphasis>
     <acronym>MP3</acronym> collection on your machine, maybe the free
     software development model is not the best one to
     choose. However, if you want to write a set of scripts to sort
     <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 diverse that, chances
     are, there is someone, somewhere, who shares your interests and
     how feels the same itch. It is the fact that there are so many
     people with so many similar needs and desires that introduces the
     second major question: <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 this
      question. If you have experience with the free software
      community, you are probably already familiar with all of these
      sites. All of the resources listed bellow offer searching of
      their databases:
     </para>

     <para>
     <variablelist>
       <varlistentry>
        <term>freshmeat.net:</term>
        <listitem>
         <para><ulink url="http://freshmeat.net">freshmeat</ulink>
         describes itself as, <quote>the Web's largest index of Linux
         and Open Source software</quote> and its reputation along
         these lines remains unquestioned. If you can't find it on
         freshmeat, its doubtful that you'll find it indexed anywhere
         else.</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 new and events. It is
         not unusual for an particularly sexy development effort to be
         announced here so it 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, SourceForge is quickly becoming a
         nexus and an 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
         releases</ulink> pages. should be necessary stops before
         embarking on a new free software project. SourceForge also
         provides a at <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>, provide powerful web searches that may
         reveal people working on similar projects. It is not a
         catalog of software or news like freshmeat or Slashdot, but
         it is worth checking before you begin pouring your effort
         into a redundant project.</para>
        </listitem>
       </varlistentry>

      </variablelist>
     </para>
    </sect4>

    <sect4 id=evalhow>
     <title>Deciding to Proceed</title>
     <para>
      Once you have successful charted the terrain and have an idea
      bout what kinds of similar free software projects exist, every
      developer needs to decide whether to proceed with their own
      project. It is rare that a new project seeks to accomplish a
      goal that is not similar to related to the goal of another
      project. Anyone starting a new project needs to ask themselves:
      <emphasis>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?</emphasis>
     </para>

     <para>
      If the answer to any of these questions is yes, try to contact
      the developer of the existing project in question and see if he
      or she might be willing to collaborate with you.
     </para>

     <para>
      This may be the single most difficult aspect of free software
      development for many developers but it is essential. It is easy
      to become fired up by and idea and be caught up in the momentum
      and excitement of a new project. It is often extremely difficult
      but it is important that any free software developer remember
      that the best interests of the of the free software community
      and the quickest way to accomplish ones own project's goals and
      the goals of similar project can often be accomplished by
      <emphasis>not</emphasis> starting a new project.
     </para>

    </sect4>
   </sect3>
  </sect2>

<!-- Section2: licensing-->

  <sect2 id="licensing">
   <title>Licensing your Software</title>
   
   <para>
    On one level, the difference between a piece of free software and
    a piece of propriety software is the license. A license helps both
    you as the developer by protecting your legal rights to your
    software 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 other free software
     licenses. This discussion also brings up the question of
     <quote>Open Source Software</quote> and the debate around
     <quote>Open Source Software</quote> and <quote>Free
     Software</quote>. However, because I've written the Free Software
     Development HOWTO and not the Open Source Development HOWTO, my
     own allegiances in this argument are out in the open.
    </para>

    <para>
     In attempting to reach a middle ground, I recommend picking any
     license that conforms to the <ulink
     url="http://www.debian.org/social_contract">Debian Free Software
     Guidelines</ulink>. Examples of these licenses are the
     <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
     Artistic License. Conforming to the definition of Free Software
     offered by Richard Stallman in <ulink
     url="http://www.gnu.org/philosophy/free-sw.html">The Free
     Software Definition</ulink>, any of these licenses will
     uphold,<quote> users' freedom to run, copy, distribute, study,
     change and improve the software.</quote> There are other licenses
     as well but sticking with a more common license will offer the
     advantage of immediate recognition and understanding.
    </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 majority of Linux software. Its an easy
     choice but I believe it is a good one. <emphasis>However, 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.</emphasis>
    </para>

    <para>
     The three major license 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 all cases, please read through any license before
     your release your software. As the 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</ulink> of mechanics of applying a license to a piece
     of software. A checklist for applying a license would include:
    </para>

    <para>
    <orderedlist>
      <listitem>

       <para>If at all possible, attach and distribute a full copy of
       the license with the source and binary in a separate
       file.</para>

      </listitem>
      <listitem>

       <para>At the top of each source file in your program, attach a
       notice of copyright and information on where the full license
       can be found. The <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 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 have the
        program output a notice each time it enters interactive mode
        that includes a message like this one that points to more
        information about the programs licensing:
       </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> with the program from an
       employer or a school if you work as a programmer or if it seems
       like your employer or school might be able to make an argument
       for ownership of your code.</para>
      </listitem>

     </orderedlist>
     </para>    
   </sect3>

   <sect3 id="licensewarning">
    <title>Final license warning</title>

    <para>
     Please, please, please, place your software under some
     license. It may not seem important, and to you, it may not be,
     but licenses are important. For a piece of software to be
     included in the Debian GNU/Linux distribution, it must have a
     license that fits the <ulink
     url="http://www.debian.org/social_contract">Debian Free Software
     Guidelines</ulink>. If you have no license, your program can be
     distributed in part of 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 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. 
   </para>

   <para>
    <emphasis>The second most important thing about a system of
    numbering is that the numbers always go up.</emphasis> Automatic
    versioning 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 rules and you will not go wrong. Still there are
    several versioning system 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 the any
      minor odd minor version number refers to an development or
      testing release and any even minor version number refers to a
      stable version. Under this system, 2.1 and 2.3 kernels were and
      always will be development and testing kernels and 2.0, 2.2. and
      2.4 kernels are all production code with a higher degree of
      stability.
     </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, all minor versions are stable
       distributions (2.0, 2.1, etc). However, many people assume that
       2.1 is an unstable or development version and continue to use
       an older version until they get so frustrated with the lack of
       development and progress that they complain. If you never
       release an odd minor version but only release even ones, nobody
       is hurt, and less people are confused.
      </para>

     </listitem>
    </varlistentry>
    <varlistentry>
     <term>Wine version numbering:</term>
     <listitem>
      <para>Because of the unusual nature of wine's development where
      it constantly improving but not working towards any immediately
      achievable goal, wine is released every three weeks. Wine does
      this by versioning their releases in Year Month Day 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, Year Month
      Day 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 model available. Their version numbering
      has reflected the unique situation in which it is
      developed.
      </para>

      <para>
       Mozilla's development 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 this road-maps
       were marked as milestones. Therefore, mozilla was built and
       distributed nightly as "nightly builds" but on a day when the
       goals of a milestone on the road-map had been reached, that
       particular build was marked as a milestone release.
      </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 free 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 because their author was the only person who knew
    how to use them well. Even if your program is written primarily
    for a techno-savvy group of users, documentation is helpful and
    necessary for the survival of your project. You will learn later
    in <xref linkend="releasing"> that you must always release
    something that is usable. <emphasis>A piece of software without
    documentation is not usable.</emphasis>
   </para>

   <para>
    There are lots of ways to document your project and lots of
    different people to document for. The idea of documentation the
    code itself to help facilitate development by a large community is
    vital but is outside the scope of this HOWTO. This being the case,
    this section deals mostly useful tactics for user-directed
    documentation.
   </para>

   <para>
    A combination of tradition and necessity has resulted in a
    semi-regular system method 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 its 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
    foo</quote> end up with a nicely formatted man page highlighting
    the basic use of their 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 process available through the
     <quote>The Linux Man-Page-HOWTO</quote> available through the
     Linux Documentation project <acronym>(LDP)</acronym> 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 and
     convert them into man pages. Because man pages are so simple, I
     have not been able to follow this up but would love help from
     anyone who can give me more information on how exactly this is
     done.
    </para>
   </sect3>

   <sect3>
    <title>Command line accessible documentation</title>

    <para>
     Most users will expect the most basic amount of documentation to
     be easily available from the command line. For few programs should
     then 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 commands, all the
     major options, and a pointer to more in-depth documentation for
     those who need it. The command line documentation for Debian's
     apt-get serves as an excellent example and a useful model:
    </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 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 method, be prepared for the flames and
     for the fallout that may result.
    </para>
   </sect3>
   <sect3>
    <title>Files users will expect</title>
    <para>
     In addition to man pages and online help, there are certain files
     where people will look to documentation, especially in any
     package containing source code. In a source distribution, most of
     these files can be stored in a the root directory of the source
     distribution or in a subdirectory of the root called
     <quote>doc</quote> or <quote>Documentation</quote>. These files 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 needs
         to 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 INSTALL file
         and should quickly and concisely describe how to build and
         install the program. Usually an install simply instructs the
         user to run ./configure; make; make install and touches on
         any unusual options that may be necessary. More advanced
         users can usually avoid them but it's good practice to at
         least glance at the file to understand what can be
         expected. For most relatively standard install procedures and
         for most programs, INSTALL files are as short as possible are
         rarely over 100 lines.
        </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 would imply, logs or documents the
         changes to a program. The most simple way to do a changelog
         is to simply keep a file with the source code for your
         program and add a section to the top of the changelog with
         each release describing what has been, changed, fixed, or
         added to the program. It's a good idea to post the changelog
         onto the website as well because it can help people decide
         whether they want or need to upgrade to a newer version or
         wait for a more significant upgrade.
        </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 the file is a collection of exactly that. FAQs
         are not difficult to make. Simply make a policy that if you
         are asked a question or see a question on a mailing list two
         or more times, add it the question (and its answer) to your
         FAQs. 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 a sort of 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 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 creates an open invitation. It should also supply
     links to any mailing lists, similar websites, and directly to all
     the available ways of downloading your software.
    </para>
   </sect3>

   <sect3>
    <title>Other documentation hints</title>

    <para>
     It doesn't hurt to distribute any documentation for your program
     from your website or anywhere else (FAQs etc) with the
     program. Make a FAQ by cutting and posting common questions and
     answers from a mailing list or your own email. Then, don't
     hesitate through this in the programs tarball. If people don't
     need it, they will delete it. I can repeat it over and over:
     <emphasis>Too much documentation is not a sin.</emphasis>
    </para>

    <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>
    </para>
   </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 actions. Still, they are worth noting briefly in
    hopes that they may remind a developer of something they may have
    forgotten.
   </para>

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

    <para>
     Binary packages are largely distribution specific. You can build
     binary packages against a current version of a major
     distribution, you will only make your users happy. Try to foster
     relationships with users or developers of large distribution to
     develop a system for consistent binary packages. It's often a
     good idea to provide RedHat <acronym>RPM</acronym>'s (.rpm),
     Debian deb's (.deb) and source <acronym>RPM</acronym>'s
     <acronym>SRPM</acronym>'s. Binary packages can also be compiled
     against a specified system with specified libraries and
     distributed in tar.gz format as well. <emphasis>Remember: While
     these binaries packages are nice, getting the source packaged and
     released should always be your priority. Other can and will do
     the the binary packages for you.</emphasis>
    </para>
   </sect3>

   <sect3>
    <title>Useful tidbits and presentation hints</title>

    <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
        <acronym>HTTP</acronym> where the newest version will be
        quickly recognized. One effective technique is a provide a
        symlink called <quote>projectname-latest</quote> that is
        always pointing to the most recent released or development
        version of your free software project.
       </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
        projectname@host or projectname-bugs@host. This way if you
        ever decide to hand over maintainership or if your email
        address changes, you simply need to change where this email
        address forwards to. 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 the project started, you have gotten over 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 an equal number of
   opportunities for failure. In the next two sections, I will and
   cover running a project by discussing how to maintain a project
   rough 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 and by choosing not to make
   decisions responsibly. You have to direct developers without being
   overbearing or bossy. You need to strive to earn respect and never
   forget to give it.</emphasis>
  </para>

<!-- Section2: delegation  -->

  <sect2 id="delegation">
   <title>Delegating Work</title>

   <para>
    By now, you've hypothetically followed me through the early
    writing of a piece of software, the creation of a website and
    system of documentation and and we've gone ahead and (as will be
    discussed in <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 and 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. <emphasis>A free software project is nothing
    without the involvement of a group of developers. A group of
    developers can only be maintained through respectful and
    responsible leadership and delegation.</emphasis>
   </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, 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>

   <sect3>
    <title>How to delegate</title>
 
    <para>
     Like anything, its easier to see how others delegate than to do
     it yourself. You may find that other developers seem even more
     experienced or knowledgeable than you. Your job as a maintainer
     does not mean you have to have to be the best or the
     brightest. It means you need are responsible for showing good
     judgment and for recognizing solutions that are maintainable and
     are not. 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
     towards 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 write access to your CVS
     repository and make real efforts towards 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 certain
      aspects of the projects. All these developers can upload into
      the main FTP servers, and vote on major issues. Direction for
      the project is determined by the project <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) and a technical
      committee and a project lead. There is a project leader as well
      but 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 who lead who can do
      <emphasis>nothing</emphasis> but delegate can serve 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 to someone else. It is a good way of very
      clearly defining a chunk of work on the project as belonging to
      a certain person and its a great way of giving yourself a break.
     </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, had 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 primary and most important
    responsibilities will be accepting and rejecting patches submitted
    to you by other developers.
   </para>

   <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 are a firm knowledge of the scope of your program
     (that's the <quote>idea</quote> I talked about in <xref
     linkend="chooseproject">) and the ability to recognize,
     facilitate, and direct <quote>evolution</quote> of a free
     software program so that the program can grow and change and
     incorporate functionality that was originally unforeseen but avoid
     digressions that might expand the scope of the program too much
     and result and push the project towards an early death under its
     own weight and unwieldiness. These are the criteria that you as a
     project maintainer should take into account each time you receive
     a patch.
    </para>

    <para>
     Fogel elaborates on this again 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 those questions
     than you do. However, if you feel that 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 will ultimately fail.
    </para>
   </sect3>

   <sect3>
    <title>Rejecting patches</title>

    <para>
     Rejecting patches is probably the most difficult and the most
     sensitive job that the maintainer of any free software project
     has to face. But sometimes it has to be done. I mentioned earlier
     (in <xref linkend="developers"> and in <xref
     linkend="delegation">) that any developer needs to try and
     balance your responsibility and power to make what you think are
     the best technical decisions with the fact that you will lose
     support from other developers if you seem like you are on a
     power trip or being overly bossy or possessive of a community-based
     project. I recommend that you keep three major facts in mind when
     rejecting patches (or other changes):
    </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. There will be some patches (bug fixes, etc.) which
      will  definitely be accepted  and some that you  feel are so off
      base that they do not even merit further discussion. It is those
      that fall into the grey area between these two groups that might
      merit a quick forward to a mailing list.
     </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 responsible and
      responsive leadership as it tests and serves the interests of
      your software's community.
     </para>
    </sect4>

    <sect4>
     <title>Technical issues is not always good justification</title>
     <para>
      Especially towards the beginning, you will find that many
      changes are difficult to implement, introduce new bugs, or have
      other technical problems. Try to see past these. Especially with
      added functionality, good ideas do not always come from good
      coders. Technical merit is a valid reason to postpone the
      application of a patch but it is not always a good reason to
      reject a change outright. Even small changes are worth the
      effort of working with the developer submitting the patch to iron out bugs and
      incorporate the change if you thing you think it seems like a
      good addition to your project. The effort on your part will work
      to make your project a community project and it will pull a new
      or less experienced developer onto your project and even teach
      them something that might help them in 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 action to not
      incorporate their change clearly and concisely. Then thank
      them. Let them know that you a appreciate their help and feel
      horrible that you can't incorporate their change. Let them know
      that you look forward to their staying involved and you hope
      that the next patch or idea meshes better with your project
      because you appreciate their work and want to see it in the
      project. If you have ever had a patch rejected that put a large
      deal of time, thought, and energy into, 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
      have 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 alludes attest to the fact
    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 affected 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 development. This is the
    model followed by the Linux kernel that is described in <xref
    linkend="chooseversioning">. In this model, there is always one
    branch that is stable and always one that is in
    development. Before any new release, the development branch goes
    into a <quote>feature freeze</quote> 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 begins
    again on the development branch. Bug fixes and small changes that
    are unlikely to have any large negative repercussions are
    incorporated into the stable branch also to the development
    branch.
   </para>

   <para>
    Linux's model is an extreme one. On many projects, there is no
    need to have two versions always available. It may make sense to
    have two versions only near a release. The Debian project has
    historically made both a stable and an unstable distribution
    available but has expanded to this to include: stable, unstable,
    testing, experimental, and (around release time) a frozen
    distribution that only incorporates bug fixes during the
    transition from unstable to stable. There are few projects whose
    size would necessitate a system like Debian but their 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 a 5-6 different architectures. Two is a good
        number. Too many branches will confuse your users (I can't
        count how many times I had to describe Debian's system when it
        only had 2 and sometimes 3 branches!), potential developers
        and even yourself. Branches can help but they come at a cost
        so use them very sparingly.
       </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 <acronym>HTTP</acronym>
        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 do 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 document, this should probably should go without
        saying but experience has taught me that it's not always
        obvious to people. It's a good idea to physically split up
        different branches in different directories or directory trees
        on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
        site. Linux accomplishes this by having all the v2.2 and a
        v2.3 subdirectory where it is immediately obvious (after you
        know their version numbering scheme) which directory is the
        most recent stable and the current development
        releases. Debian accomplishes this by naming all their
        distribution by name 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 their are
        others. In any case, it is important that different branches
        are always available, are accessible from consistent
        locations, and that different branches are clearly
        distinguished from each other so your users know exactly what
        they want to be downloading and where to get it.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </para>

  </sect2>

<!-- Section2: otherdev -->

  <sect2 id="otherdev">
   <title>Other Development issues</title>
   <para>
    There are more issues around surrounding interaction with
    developers in a free software project that I can touch on in great
    detail in a HOWTO of this size. Please don't hesitate to contact
    me if you see any major omissions. Other smaller issues that are
    worth mentioning are:
   </para>

   <sect3>
    <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>
     Freeze 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 code freeze, all changes to the code are
     frowned upon and only changes that fix known bugs are
     permitted. This type of freeze usually follows a <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 you do not 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>

   <sect3>
    <title>Forking</title>
    <para>
     Forks are the most extreme interpretation of a branch. A fork is
     when a group of developers takes code from a free software
     project and actually starts a brand new free software
     project. The most famous example of a fork is Emacs and
     XEmacs. Both emacsen are based on an almost identical code-base
     but for technical, political, and philosophical reasons,
     development was split into two projects which now compete with
     each other.
    </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, redundancy of work.
     Luckily, usually the threat of the fork is enough to scare the
     maintainer or maintainers of a project into changing the way they
     run their project to avoid it.
    </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>
   </sect3>
  </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 and 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 users in
   the world of proprietary software and they should be treated
   differently. 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 your users 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 in that in
     the proprietary world.</para>
    </listitem>

    <listitem>
     <para>In an almost paradoxical situation, free software projects
     have less immediate or dire consequences for ignoring their
     users--it is often easier to do. Because you don't usually need
     to compete with another product in the free software model,
     chances are good that you will not be scrambling to gain the
     features of the competitor's newest program. This means that your
     development process will have to be directed either internally,
     by your users or 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 developers best tool
   for shifting his development or leadership style to fit the unique
   process of free software development. This chapters will try and
   introduce some of the more difficult or important points in any
   projects interactions with users and give some hints on how to
   tackle these.
  </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</emphasis> users are
    your testers.
   </para>

   <para>
    It is important that this distinction be made early on because not
    all of your users wants to be testers. Many users want to use
    stable software and don't care if they don't have the newest
    greatest software with the latest and greatest features. These
    users except a stable, tested piece of software with major or
    obvious bugs worked out or openly declared and will be angry if
    they find themselves in a testing position. This is yet another
    way in which a split development model (as mentioned in <xref
    linkend="branches">) might come in handy.
   </para>

   <sect3>
    <title>Automated testing</title>
    <para>
     For many programs, many common and mistakes can be caught by
     automated means. Automated tests tend to be pretty good at
     catching errors that you've run into several times before or
     something you just forget and not very good at finding errors,
     even major ones, that were 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
     using these scripts may not be possible, there is a host of other
     sanity checking software on the net that may be applicable (feel
     free to email any recommendations). None of these will create a
     bug-free release but they will avoid at least some major
     oversights. Finally, if your programs become a long term
     endeavor, you will find that there are certain errors that you
     tend to make over and over. Start a collection of scripts that
     check for these errors to help prevent them in the future.
    </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 testers 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 outline the functionality of the program. If you put some
     time into the announcement, you are sure to get a few bites.
    </para>

    <para>
     The second most difficult part of testing is keeping your testers
     and keeping them actively involved in the testing
     process. Fortunately, there are some tried and true tactics that
     can applied towards this end:
    </para>

    <para>
     <itemizedlist>

      <listitem>
       <para><emphasis>Make things simple for your testers.</emphasis>
       Your testers are doing you a favor so make it as easy as
       possible. 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 tester's job easy and
       maintain as much flexibility as possible for those that want to
       do things a little differently.</para>
      </listitem>

      <listitem>
       <para><emphasis>Be responsive to your testers.</emphasis> 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 response make
       them feel like their work is heard, important, and
       appreciated.</para>
      </listitem>

      <listitem>
       <para><emphasis>Thank your testers.</emphasis> 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 and pat them on the
       back by making sure the rest of the world knows it too. It will
       be appreciated more than you expected.</para>
      </listitem>

     </itemizedlist>
    </para>
   </sect3>
  </sect2>

<!-- Section2: support  -->

  <sect2 id="support">
   <title>Setting up a 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 while people get quicker and
    better responses to their questions. This infrastructure comes in
    several 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
     large covered in <xref linkend="documentation"> and will not be
     repeated here.
    </para>
   </sect3>

   <sect3>
    <title>Mailing lists</title>
    <para>
     Aside from documentation, effective mailing lists will be your
     greatest tool in supporting 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 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 new 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
      lightly. 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 to do. 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 in setting up your
      list. If it is possible to gate your mailing lists to USENET and
      provide them in digest form as well as making them accessible on
      the web, you will please some users and work to make the support
      infrastructure slightly more accessible.
     </para>
    </sect4>
   </sect3>

   <sect3>
    <title>Other support ideas</title>

    <para>
     A mailing list and accessible documentation all you can do to set
     up good user support infrastructure. Be creative. If you stumble
     across something works well, email me and I'll include it here in
     the HOWTO.
    </para>
    <sect4>
     <title>Make your self accessible</title>
     <para>
      You can not put to few methods to access you. If you hang out in
      an <acronym>IRC</acronym> channel, don't hesitate to list in
      your projects documentation. List email and snail mail
      addresses, or ways to reach you via <acronym>ICQ</acronym>,
      <acronym>AIM</acronym>, or Jabber.
    </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>.
     </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 way for users and testers to report
      bugs and for developers and maintainers to fix 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 or 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 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 the version 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 be done. My advice is to try and make something that
     is complete enough to be usable and incomplete enough to allow
     for flexibility and 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 it is time and you feel
     you've weighed the situation well several times, cross your
     fingers and take the plunge.</emphasis>
   </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 a consistent
     distribution locations and the other infrastructure described in
     the preceding sections, releasing should be as simple as
     building the package, checking it once over, and uploading it
     into the appropriate place and then reflecting the release on
     your website.
    </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 cause more problems then
     they are worth.
    </para>

    <para>
     <variablelist>

      <varlistentry>
       <term>alpha releases</term>
       <listitem>
        <para>
         Alpha releases are expected to be unstable, perhaps a little
         unsafe, but definitely usable. Alpha versions should have
         full functionality and limited testing. They can have known
         bugs and kinks that have yet to be worked out. Before 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 releases are general expected to be usable and
         slightly unstable, although definitely
         <emphasis>not</emphasis> unsafe. Beta releases usually
         preclude a full release by under a month. They can contain
         small known bugs but no major ones. All major functionality
         should be fully implemented although the exact mechanics can
         still be worked out. Beta releases are great tool to whet the
         appetites of potential users by giving them a very
         realistic view of where your project is going in the very
         near future and can help keep interest by giving people
         <emphasis>something.</emphasis>
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term>development releases</term>
       <listitem>
        <para>
         Development release is much more vague term than
         <quote>alpha</quote> or <quote>beta</quote>. I usually choose
         to reserve the term for discussion of a development
         branch. 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 to alpha or beta stages though and if I
         were to release a pre-alpha release in order to keep interest
         in my project live, 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 communities
    radar screen.
   </para>

   <sect3>
    <title>Mailing lists and USENET</title>
    <para>
     Email is still the way that most people on the Internet get their
     information. Its a good idea to send a message announcing your
     program to any relevant mailing list you know of and any relevant
     USENET discussion group. Karl Fogel recommends that use you
     simple subject describing the fact that the message is an
     announcement, the name of the program, the version, and a
     half-line long description of its functionality. This way, any
     interested user or developer will be immediately attracted to
     your announcement. Fogel's example looks like:
    </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 it right away.
    </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 list
     announcements.
    </para>

    <para>
     Visit the <ulink url="http://freshmeat.net">freshmeat
     website</ulink> or their <ulink
     url="http://freshmeat.net/add-project/">submit project
     page</ulink> to post your project on their site and in their
     database. In addition to a large website, freshmeat provides a
     daily newsletter that highlights all the days releases and
     reaches a huge audience (I skim it every night for any
     interesting new releases).
    </para>

    <para>
     Once you've finished this...
    </para>

    <para>
     Congratulations. You've now the maintainer of an active free
     software project. Good luck and feel free to stay in touch with
     me about your experiences. I'd love to incorporate them into this
     HOWTO.
    </para>
   </sect3>
  </sect2>
</sect1>

</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:
-->