I fixed lots of little bugs, the subsections on choosing a license and

[fspm_howto] / FreeSoftwareDevelopmentHOWTO.sgml

diff --git a/FreeSoftwareDevelopmentHOWTO.sgml b/FreeSoftwareDevelopmentHOWTO.sgml
index 32091e727c2c5c6d96478118c8d9e73ff7baa8f3..4499e578b318aaa0b0c4ae8cdcbfa384c6c848b9 100644 (file)
--- a/FreeSoftwareDevelopmentHOWTO.sgml
+++ b/FreeSoftwareDevelopmentHOWTO.sgml
@@ -392,23 +392,487 @@
     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
     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 something unique
+    software process does or or does it in a way that is unique
+    enought to necessitate a seperate project.

    </para>
 
    </para>
 

-  </sect2>
+   <sect3 id=identifyidea>
+    <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 <ulink
+     url="http://www.tuxedo.org/!esr/writings/cathedral-bazaar/">online
+     </ulink>.
+    </para>

 
 

-<!-- Section2: chooselicense-->
+    <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>

 
 

-  <sect2 id="chooselicense">
-   <title>Deciding on a License</title>
-   <para></para>
+    <para>
+     If you have an idea for a program in mind, chances are good that
+     it it is targetting 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 definately 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> MP3
+     collection on your machine, maybe the free software development
+     model is not the best one to choose. However, if you want to
+     write a set of scripts to sort <emphasis>anyone's</emphasis>
+     MP3s, 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 develpment effort to be
+        announced here so it definately worth checking.</para>
+        </listitem>
+       </varlistentry>
+
+       <varlistentry>
+        <term>SourceForge</term>
+        <listitem>
+        <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>
+        <listitem>
+        <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>
+
+      </variablelist>
+     </para>
+    </sect4>
+
+    <sect4 id=evalhow>
+     <title>Deciding to Proceed</title>
+     <para>
+      Once you have successfull 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 rememeber
+      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>
 
   </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 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>
 <!-- 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<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>
 
 <!-- Section2: documentation-->


@@ -425,13 +889,6 @@
    <para></para>
   </sect2>
 
    <para></para>
   </sect2>
 

-<!-- Section2: futuredev -->
-
-  <sect2 id="futuredev">
-   <title>Nuturing Future Development</title>
-   <para></para>
-  </sect2>
-

  </sect1>
 
 <!-- Section1: starting: END -->
  </sect1>
 
 <!-- Section1: starting: END -->


@@ -440,7 +897,6 @@
 
  <sect1 id="developers">
   <title>Maintaining a Project: Interacting with Developers</title>
 
  <sect1 id="developers">
   <title>Maintaining a Project: Interacting with Developers</title>

-

    <indexterm>
     <primary>fswd!developers</primary>
    </indexterm>
    <indexterm>
     <primary>fswd!developers</primary>
    </indexterm>


@@ -524,4 +980,4 @@ sgml-exposed-tags:nil
 sgml-local-catalogs:nil
 sgml-local-ecat-files:nil
 End:
 sgml-local-catalogs:nil
 sgml-local-ecat-files:nil
 End:

--->
+-->
\ No newline at end of file