]> projects.mako.cc - fspm_howto/blobdiff - FreeSoftwareDevelopmentHOWTO.sgml
Section 2 on completely a project is complete. The whole thing
[fspm_howto] / FreeSoftwareDevelopmentHOWTO.sgml
index 8c83f39357851277b0acc5ddf0f583c74fe234e4..d41ae2b3b08491e4c4b0cc25141a13e52a4f9483 100644 (file)
    </para>
 
    <para>
-    The latest version number of this document should always be listed 
-    at my webpage at<ulink url="http://people.debian.org/~mako/">
-    http://people.debian.org/~mako/</ulink> Debian.
+    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>
     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 (at) debian (dot) org</email>.
+    <email>mako@debian. org</email>.
    </para>
    </sect2>
 
     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 (at) debian (dot)
-    org</email>.
+    hesitate to contact me at: <email>mako@debian.org</email>.
    </para>
    </sect2>
  </sect1>
    </para>
 
    <sect3 id=identifyidea>
-    <title>Indentify and Articulate Your Idea</title>
+    <title>Indentify 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 softare development. You can find it online
-     at <ulink url="http://www.tuxedo.org/!esr/writings/cathedral-bazaar/">
-     http://www.tuxedo.org/!esr/writings/cathedral-bazaar/</ulink>.
+     reading for any free softare development. You can find it <ulink
+     url="http://www.tuxedo.org/!esr/writings/cathedral-bazaar/">online
+     </ulink>.
     </para>
 
     <para>
    </sect3>
 
    <sect3 id=evalulateidea>
-    <title>Evaluate Your Idea</title>
+    <title>Evaluate your idea</title>
 
     <para>
      In evaluating your idea, you need to ask yourself questions.
      <para>
      <variablelist>
        <varlistentry>
-        <term>freshmeat.net</term>
+        <term>freshmeat.net:</term>
         <listitem>
-        <para>
-          Located at at <ulink url="http://freshmeat.net">
-          http://freshmeat.net</ulink>, freshmeat 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>
+        <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>
+        <term>Slashdot:</term>
         <listitem>
-        <para>
-          Located at <ulink url="http://slashdot.org">
-          http://slashdot.org</ulink>, Slashdot 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 develpment effort to be announced here so
-          it definately worth checking.
-         </para>
+        <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 develpment effort to be
+        announced here so it definately worth checking.</para>
         </listitem>
        </varlistentry>
 
        <varlistentry>
-        <term>SourceForge</term>
+        <term>SourceForge:</term>
         <listitem>
-        <para>
-          Located at <ulink url="http://sourceforge.net">
-          http://sourceforge.net</ulink>, SourceForge houses and
-          facilitates a growning 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
-          <emphasis>Code Snippet Library</emphasis> at <ulink
-          url="http://sourceforge.net/snippet/">http://sourceforge.net/snippet/</ulink>
-          which contains useful reusuable chunks of code in an array
-          of langauges which can come in useful in any project.
-         </para>
+        <para><ulink url="http://sourceforge.net">SourceForge</ulink>
+        houses and facilitates a growning 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 reusuable chunks of
+        code in an array of langauges which can come in useful in any
+        project.</para>
         </listitem>
        </varlistentry>
 
        <varlistentry>
-        <term>Google and Google's Linux Search</term>
+        <term>Google and Google's Linux Search:</term>
         <listitem>
-        <para>
-          Located at <ulink url="http://www.google.com">
-          http://www.google.com</ulink> and
-          <ulink url="http://www.google.com/linux">
-          http://www.google.com/linux</ulink>, provide prowerful 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>
+        <para><ulink url="http://www.google.com">Google</ulink> and
+        <ulink url="http://www.google.com/linux"> Google's Linux
+        Search</ulink>, provide powwerful 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>
 
    </sect3>
   </sect2>
 
-<!-- Section2: chooselicense-->
+<!-- Section2: licensing-->
 
-  <sect2 id="chooselicense">
-   <title>Deciding on a License</title>
-   <para></para>
-  </sect2>
+  <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 flamewar 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 allegiences 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
+     Guidlines</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 undestanding.
+    </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 seperate
+       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 distrobution, 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 rerelease 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></para>
+   <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 taht 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 frusterated 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 Janurary 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 verdor 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 teh 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 roadmaps
+       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 roadmap had been reached, that
+       particular build was marked as a milstone 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></para>
+
+   <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 usuable.</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 manpages 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 accessable documentation</title>
+
+    <para>
+     Most users will expect the most basic amount of documentation to
+     be easily availabe 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
+     sentance) 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
+     accessable 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 directery 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,
+         compiliation, 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 quicly 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 teh 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 signifigant 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 useability, 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></para>
-  </sect2>
+   <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>
 
-<!-- Section2: futuredev -->
+   <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 spotlit as a more effective compression medium. I now make
+     all my releases available in both gzip'ed and bzip2'ed formats.
+    </para>
 
-  <sect2 id="futuredev">
-   <title>Nuturing Future Development</title>
-   <para></para>
-  </sect2>
+    <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 specificed libraries and
+     distributed in tar.gz format as well. <emphasis>Remember: While
+     these binaries packages are nice, geting 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 accessable 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 -->
 
  <sect1 id="developers">
   <title>Maintaining a Project: Interacting with Developers</title>
-></ulink>which
    <indexterm>
     <primary>fswd!developers</primary>
    </indexterm>
     <primary>fswd!users</primary>
    </indexterm>
 
+<!-- Section2: testing -->
+
+  <sect2 id="testing">
+   <title>Testing and Testers</title>
+   <para></para>
+  </sect2>
+
+<!-- Section2: support  -->
+
+  <sect2 id="support">
+   <title>Setting up a Support Infrastructure</title>
+   <para></para>
+  </sect2>
+
+<!-- Section2: releasing  -->
+
+  <sect2 id="releasing">
+   <title>Releasing Your Program</title>
+   <para></para>
+  </sect2>
 
 <!-- Section2: announcing  -->
 
    <para></para>
   </sect2>
 
-<!-- Section2: testing -->
 
-  <sect2 id="testing">
-   <title>Testing and Testers</title>
-   <para></para>
-  </sect2>
 </sect1>
 
 </article>

Benjamin Mako Hill || Want to submit a patch?