<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>
<varlistentry>
<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>
<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>
<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>
<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<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-->
<para></para>
</sect2>
-<!-- Section2: futuredev -->
-
- <sect2 id="futuredev">
- <title>Nuturing Future Development</title>
- <para></para>
- </sect2>
-
</sect1>
<!-- Section1: starting: END -->
<sect1 id="developers">
<title>Maintaining a Project: Interacting with Developers</title>
-></ulink>which
<indexterm>
<primary>fswd!developers</primary>
</indexterm>
projects / fspm_howto / blobdiff