<artheader>
<title>Free Software Development HOWTO</title>
-
+
<author>
- <firstname>Benjamin</firstname>
- <othername>Mako</othername>
- <surnamen>Hill</surname>
- <affiliation>
- <address>
- <email>mako@debian.org</email>
-
- </address>
- </affiliation>
+ <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>1 January 2001</date>
- <authorinitials>bch</authorinitials>
- <revremark>
- Initial Release
- </revremark>
- </revision>
- </revhistory>
+
+ <revhistory>
+ <revision>
+ <revnumber>v0.2</revnumber>
+ <date>8 April 2001</date>
+ <authorinitials>bch</authorinitials>
+ </revision>
+
+ <revision>
+ <revnumber>v0.01</revnumber>
+ <date>27 March 2001</date>
+ <authorinitials>bch</authorinitials>
+ <revremark>Initial Release</revremark>
+ </revision>
+ </revhistory>
<abstract>
- <indexterm>
-
<primary>fswd</primary>
- </indexterm>
-
- 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 programming 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>
+ <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 realease has been codenamed the
- <emphasis>homade 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>
-
+ <title>Introduction</title>
+
+ <indexterm>
+ <primary>fswd!introduction</primary>
+ </indexterm>
+
<para>
- Skimming through Freshmeat provides mountains of reasons for this
+ 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
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 recite it in your
- sleep and your project will probably fail. Then again, you can
- write a beautiful, relevent piece of software and follow every
+ 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
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 bites and pieces of this HOWTO to Free
- Software developers on several occasions, I realized that that
- writing this HOWTO might provide a useful resource and a forum for
+ 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>
-
+ them.
</para>
<para>
<title>Copyright Information</title>
<para>
- This document is copyrighted (c) 2000 Stein Gjoen and is
+ This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is
distributed under the terms of the Linux Documentation Project
- (LDP) license, stated below. <emphasis>Replace with your name,
- or supply a new license, when you use this skeleton for a new
- HOWTO.</emphasis>
+ (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.
+ 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>
</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.
+ 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
+ If you have any questions, please contact
<email>linux-howto@metalab.unc.edu</email>
</para>
</sect2>
<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.
+ 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>
<title>New Versions</title>
<indexterm>
- <primary>(your index root)!news on</primary>
+ <primary>fswd!news on</primary>
</indexterm>
<para>
</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/</unlink> 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>
<para>
<itemizedlist>
+
<listitem>
<para>
- <ulink url="http://people.debian.org/~mako/howto/fswd-howto.html">HTML</ulink>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO/t1.html">HTML</ulink>.
</para>
</listitem>
+
<listitem>
<para>
- <ulink URL="http://people.debian.org/~mako/howto/fswd-howto.txt">plain text</ulink>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.html">HTML (single page)</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://people.debian.org/~mako/howto/fswd-howto.US.ps.gz">compressed
- postscript (US letter format)</ulink>.
+ <ulink URL="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.txt">plain text</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>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.ps.gz">compressed postscript</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://people.debian.org/~mako/howto/fswd-howto.sgml">SGML source</ulink>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.sgml.gz">Compressed SGML source</ulink>.
</para>
</listitem>
</itemizedlist>
</para>
+ </sect2>
<!-- Section2: credits -->
<para>
<emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
Source Development with CVS</emphasis> published by the Coriolis
- Open Press. Large
s parts of the book are available <ulink
+ Open Press. Large
parts of his book are available <ulink
url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
the book are available under the GPL and constitute the best
- tutorial on CVS I 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
+ tutorial on CVS I've 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.
+ 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 and material, and inspiration for this
- HOWTO is Eric S. Raymond for his prolific, consitent, and
- carefully crafted arguments, to Lawrence Lessig for reminding me
- of the importance of Free Software and to 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 and to make a difference, a
- place to learn from those how have been involved with the movement
- much longer than I, and an proof of a Free Software project that
- <emphasis>definately, definately works</emphasis>.
+ 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. Additionaly, I want to thank every
+ user and developer involved with the <ulink
+ url="http://www.debian.org">Debian Project</ulink>. The project
+ has provided me with a home, a place to practice Free Software
+ advocacy, a place to make a difference, a place to learn from
+ those 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 provided the philosphical 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>.
+ 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>
<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. I
- want this document to be as much 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 (at) debian (dot) org</email>.
+ Feedback is always and most certainly welcome for this
+ document. Without your submissions and input, this document
+ wouldn't exist. Do you feel that something is missing? Don't
+ hesitate to contact me to have me write a chapter, section, or
+ subsection or to write one yourself. I want this document to be a
+ product of the Free Software development process that it heralds
+ and I believe that its ultimate success will be rooted in this
+ fact. Please send your additions, comments and criticisms to the
+ following email address : <email>mako@debian. org</email>.
</para>
</sect2>
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
+ 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 (at) debian (dot)
- org</email>.
+ hesitate to contact me at: <email>mako@debian.org</email>.
</para>
</sect2>
</sect1>
<indexterm>
<primary>fswd!starting</primary>
</indexterm>
+ <para>
+ With very little argument, the beginning is most difficult part of
+ successful free software development. Laying a firm foundation will
+ determine whether your project flourishes or withers away and
+ dies. It is also the subject that is of most immediate interest to
+ anyone reading this document as a tutorial.
+ </para>
+
+ <para>
+ Starting a project involves a dilemma that you as a developer must
+ try and deal with: No potential user for your program is interested
+ in a program that doesn't work. Simultaneously, the development
+ process that you want to employ holds involvement of users as
+ prerequisit to working software.
+ </para>
+
+ <para>
+ It is in these dangerous initial moments that anyone working to
+ start a free software project must try and strike a balance along
+ these lines. One of the most important ways that someone trying to
+ start a project can work towards this balance is by establishing a
+ solid framework for the development process through some of the
+ suggestions mentioned in this section.
+ </para>
<!-- Section2: chooseproject-->
<sect2 id="chooseproject">
<title>Choosing a Project</title>
- </sect2>
-
-<!-- Section2: chooselicense-->
-
- <sect2 id="chooselicense">
- <title>Deciding on a License</title>
- </sect2>
-
-<!-- Section2: chooseversioning-->
-
- <sect2 id="chooseversioning">
- <title>Choosing a Method of Version Numbering</title>
- </sect2>
-
-<!-- Section2: documentation-->
-
- <sect2 id="documentation">
- <title>Documentation</title>
- </sect2>
-
-<!-- Section2: presentation -->
-
- <sect2 id="presentation">
- <title>Other Presentation Issues</title>
- </sect2>
-
-<!-- Section2: futuredev -->
-
- <sect2 id="futuredev">
- <title>Nuturing Future Development</title>
- </sect2>
-
- </sect1>
-
-<!-- Section1: starting: END -->
-
-<!-- Section1: developers -->
-
- <sect1 id="developers">
- <title>Maintaining a Project: Interacting with Developers</title>
-
- <indexterm>
- <primary>fswd!developers</primary>
- </indexterm>
-
-<!-- Section2: delegation -->
-
- <sect2 id="delegation">
- <title>Delegating Work</title>
- </sect2>
-<!-- Section2: branches -->
+ <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 in a percieved gap by doing something that no other
+ free software process does or by doing something in a way the is
+ unique enough to necessitate a separate project.
+ </para>
- <sect2 id="branches">
- <title>Stable and Development Branches</title>
- </sect2>
+ <sect3 id=identifyidea>
+ <title>Identify and articulate your idea</title>
+ <para>
+ Eric S. Raymond writes about how free software projects start in
+ his paper, <quote>The Cathedral and the Bazaar,</quote> which
+ comes as required reading for any free software development. It
+ is available <ulink
+ url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
+ </ulink>.
+ </para>
-<!-- Section2: freezing -->
+ <para>
+ In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
+ that: <emphasis>Every good work of software starts by scratching
+ a developers itch.</emphasis> Raymond's now widely accepted
+ hypothesis is that new free software programs are written, first
+ and foremost, to solve a specific problem facing the developer.
+ </para>
- <sect2 id="freezing">
- <title>Freezing</title>
- </sect2>
+ <para>
+ If you have an idea for a program in mind, chances are good that
+ it targets a specific problem or <quote>itch</quote> you want to
+ see scratched. 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.
+ </para>
-<!-- Section2: codecram -->
+ <para>
+ Monty Manley articles the importance of this initial step in an
+ essay, <ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way.</ulink> As the next section will
+ show, there is <emphasis>a lot</emphasis> of work that needs to
+ be done before software is ready for release. Manley says,
+ <quote>Beginning an OSS project properly means that a developer
+ must, first and foremost, avoid writing code too soon!</quote>
+ </para>
+ </sect3>
- <sect2 id="codecram">
- <title>Avoiding the Code Cram Effect</title>
- </sect2>
+ <sect3 id=evalulateidea>
+ <title>Evaluate your idea</title>
-<!-- Section2: patching -->
+ <para>
+ In evaluating your idea, you need to first ask yourself a few
+ 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 in solitude
+ fails to qualify as a free software development effort, you need
+ to ask yourself the question: <emphasis>Is anybody else
+ interested?</emphasis>
+ </para>
- <sect2 id="patching">
- <title>Accepting and Rejecting Patches</title>
- </sect2>
- </sect1>
+ <para>
+ Sometimes the answer is a simple <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>
-<!-- Section1: users -->
+ <para>
+ Luckily, The Internet is a place so big and so diverse that,
+ chances are, there is someone, somewhere, who shares your
+ interests and how feels the same <quote>itch.</quote> It is the
+ fact that there are so many people with so many similar needs and
+ desires that introduces the second major question: <emphasis>Has
+ somebody already had your idea or a reasonably similar
+ one?</emphasis>
+ </para>
- <sect1 id="users">
- <title>Maintaining a Project: Interacting with Users</title>
+ <sect4 id=evalwhere>
+ <title>Finding Similar Projects</title>
- <indexterm>
- <primary>fswd!users</primary>
- </indexterm>
+ <para>
+ There are places you can go on the web to try and answer the
+ question above. If you have experience with the free software
+ community, you are probably already familiar with 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.net</ulink>
+ describes itself as, <quote>the Web's largest index of Linux
+ and Open Source software</quote> and its reputation along
+ these lines is totally unparalleled and unquestioned. If you
+ can't find it on freshmeat, its doubtful that you (or anyone
+ else) will find it anywhere.</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. It is also 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 languaqges 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>
-<!-- Section2: announcing -->
+ <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 or related to the goal of another
+ project. Anyone starting a new project needs to ask themselves:
+ <quote>Will the new project be duplicating work done by another
+ project? Will the new project be competing for developers with
+ an existing project? Can the goals of the new project be
+ accomplished by adding functionality to an existing
+ project?</quote>
+ </para>
- <sect2 id="announcing">
- <title>Announcing Your Project</title>
- </sect2>
+ <para>
+ If the answer to any of these questions is <quote>yes,</quote>
+ try to contact the developer of the existing project(s) in
+ question and see if he or she might be willing to collaborate
+ with you.
+ </para>
-<!-- Section2: testing -->
+ <para>
+ This may be the single most difficult aspect of free software
+ development for many developers but it is an essential one. It
+ is easy to become fired up by an idea and be caught up in the
+ momentum and excitement of a new project. It is often extremely
+ difficult to do but, it is important that any free software
+ developer remember that the best interests 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>
- <sect2 id="testing">
- <title>Testing and Testers</title>
+ </sect4>
+ </sect3>
</sect2>
-</sect1>
-
-<!-- Section1: samples -->
-
- <sect1 id="samples">
- <title>Samples</title>
-
- <para>
- <emphasis>This section gives some simple SGML examples you could
- use. Read the SGML source to see how it was done.</emphasis>
- </para>
- <para>
- Further information and examples can be obtained from the publication
- <ulink url="http://docbook.org/tdg/html/">DocBook: The Definitive
- Guide</ulink>. Written by <emphasis>Norman Walsh</emphasis>
- and <emphasis>Leonard Muellner</emphasis>; 1st Edition, October 1999.
- </para>
-
-<!-- Section2: lists -->
+<!-- Section2: naming-->
- <sect2 id="lists">
- <title>Lists</title>
+ <sect2 id="naming">
+ <title>Naming your project</title>
<para>
- <emphasis>Lists are used frequently, and are available in a number
- of formats shown below.</emphasis>
+ While there are plenty of projects that fail with descriptive
+ names and plenty that succeed without them, I think naming your
+ project is wroth giving a little bit of thought. Leslie Orchard
+ tackles this issue in a n <ulink
+ url="http://www.advogato.org/article/67.html">advogato
+ article</ulink>. The article is short and probably worth looking
+ over quickly.
</para>
<para>
- A list in which each entry is marked with a bullet or other dingbat:
+ The very short version is that Orchard recommends that you should
+ pick a name where, after hearing the name, many users or
+ developers will:
</para>
<para>
<itemizedlist>
-
- <listitem>
- <para>Apples</para>
- </listitem>
-
<listitem>
- <para>Oranges</para>
+ <para>You will know what the project does.</para>
</listitem>
-
<listitem>
- <para>Bananas</para>
+ <para>You will remember it tomorrow.</para>
</listitem>
-
</itemizedlist>
</para>
<para>
- A list in which each entry is composed of a set of one or more
- terms and an associated description:
- </para>
-
- <para>
- <variablelist>
-
- <varlistentry>
- <term>Fruits</term>
- <listitem>
- <para>such as apples, oranges, and more.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Nuts</term>
- <listitem>
- <para>Don't eat too many; you are what you eat.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Vegetables</term>
- <listitem>
- <para>Potatos are spelled with care.</para>
- </listitem>
- </varlistentry>
-
- </variablelist>
+ Humorously, Orchard's project, Iajitsu, does neither (and
+ development is effectively frozen since the article was written).
</para>
<para>
- A list in which each entry is marked with a sequentially
- incremented label:
+ There is a point though. There are companies who only job is to
+ make names for pieces of software. They make
+ <emphasis>ridiculous</emphasis> amount of money doing it and they
+ are supposedly worth it. While you probably can't aford a company
+ like this, you can afford to learn from their existance and think
+ a little bit about the name you are giving your project.
</para>
<para>
- <orderedlist>
-
- <listitem>
- <para>Step one</para>
- </listitem>
-
- <listitem>
- <para>Step two</para>
- </listitem>
-
- </orderedlist>
+ If there is a name you really want, go ahead. I though
+ <quote>gnubile</quote> was one of the best names ever and I still
+ talk about it, long after I've stopped using the program. If you
+ can flexible on the subject, listen to Orchard's advice. It might
+ even help you.
</para>
</sect2>
-<!-- Section2: links -->
-
- <sect2 id="links">
- <title>Links</title>
+<!-- Section2: licensing-->
+ <sect2 id="licensing">
+ <title>Licensing your Software</title>
+
<para>
- <emphasis>Links can be used within your documents to refer to
- different sections and chapters or to refer to documents external
- to yours.</emphasis>
+ On one (somewhat simplistic) level, the difference between a piece
+ of free software and a piece of propriety software is the
+ license. A license helps you as the developer by protecting your
+ legal rights to have your software distributed under your terms
+ and helps demonstrate to those who wish to help you or your
+ project that they are encouraged to join.
</para>
+
+ <sect3 id="chooselicense">
+ <title>Choosing a license</title>
- <sect3 id="int-links">
- <title>Internal links</title>
+ <para>
+ Any discussion of licenses is also sure to generate at least a
+ small flame war as there are strong feelings that some free
+ software licenses are better than others. This discussion also
+ brings up the question of <quote>Open Source Software</quote> and
+ the debate 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 in the
+ open.
+ </para>
<para>
- Click on the <xref LinkEnd="samples"> link to jump to the top of
- this chapter. Note the anchor at the section tag.
+ In attempting to reach a middle ground through diplomacy without
+ sacrificing my own philosophy, I recommend picking any license
+ that conforms to the <ulink
+ url="http://www.debian.org/social_contract">Debian Free Software
+ Guidelines</ulink>. Originally compiled by the Debian project
+ under Bruce Perens, the <acronym>DFSG</acronym> form the first
+ version of the Open Source definition. Examples of free licenses
+ given by the <acronym>DFSG</acronym> are the
+ <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
+ Artistic License.
</para>
- </sect3>
- <sect3 id="ext-links">
- <title>External links</title>
+ <para>
+ Conforming to the definition of Free Software offered by Richard
+ Stallman in <ulink
+ url="http://www.gnu.org/philosophy/free-sw.html"><quote>The Free
+ Software Definition</quote></ulink>, any of these licenses will
+ uphold,<quote> users' freedom to run, copy, distribute, study,
+ change and improve the software.</quote> There are plenty of
+ other licenses that also conform to the <acronym>DFSG</acronym>
+ but sticking with a more common license will offer the advantage
+ of immediate recognition and understanding.
+ </para>
<para>
- Click on <ulink url="http://www.linuxdoc.org/">this</ulink> link
- to jump to the LDP site. Note you can use http, ftp, news and
- other protocols in the locator if required.
+ 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>
- </sect3>
- </sect2>
+ <para>
+ Personally, I license all my software under the
+ <acronym>GPL</acronym>. Created and protected by the Free
+ Software Foundation and the GNU Project, the
+ <acronym>GPL</acronym> is the license for the Linux kernel,
+ GNOME, Emacs, and the vast majority of GNU/Linux software. It's
+ the obvious choice but I believe it is a good one. Any BSD
+ fanatic will urge you to remember that there is a viral aspect to
+ the <acronym>GPL</acronym>that prevents the mixture of
+ <acronym>GPL</acronym>'ed code with non-<acronym>GPL</acronym>'ed
+ code. To many people (myself included), this is a benefit, but to
+ some, it is a major drawback.
+ </para>
-<!-- Section2: images -->
+ <para>
+ The three major license can be found at the following locations:
+ </para>
- <sect2 id="images">
- <title>Images</title>
+ <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>Avoid diagrams if possible as this cannot be rendered
- in the ASCII outputs which are still needed by many around the
- world.</emphasis>
- </para>
+ <para>
+ <emphasis>In any case, please read through any license before
+ your release your software. As the primary developer, you can't
+ afford any license surprises.</emphasis>
+ </para>
+ </sect3>
- <para>
- <figure>
- <title>Graphics Test Image</title>
- <graphic FileRef="red.gif"></graphic>
- </figure>
- </para>
+ <sect3 id="licensechoose">
+ <title>The mechanics of licensing</title>
- <para>
- Here is another variation which allows for ALT text:
- </para>
+ <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. My quick checklist for applying a license includes:
+ </para>
- <para>
- <mediaobject>
+ <para>
+ <itemizedlist>
+
+ <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>
- <imageobject>
- <imagedata fileref="green.gif" format="gif">
- </imageobject>
+ <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>
- <textobject>
- <phrase>
- ALT text to be used: Green Ball
- </phrase>
- </textobject>
+ <para>
+ The <acronym>GPL</acronym> goes on to recommend attaching
+ information on contacting you (the author) via email or
+ physical mail.
+ </para>
+ </listitem>
- <caption>
+ <listitem>
<para>
- Caption for the graphic goes here: This is a Green Ball.
+ The <acronym>GPL</acronym> continues and suggests that if your
+ program runs in an interactive mode, you should write the
+ program to output a notice each time it enters interactive
+ mode that includes a message like this one that points to more
+ information about the programs licensing:
</para>
- </caption>
- </mediaobject>
- </para>
- </sect2>
-
- </sect1>
-<!-- Section1: samples: END -->
+ <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 later on. Its often needed but there
+ are plenty of free software developers who have gotten into
+ trouble and wish they had attained one.</para>
+ </listitem>
-<!-- Section1: structure -->
+ </itemizedlist>
+ </para>
+ </sect3>
- <sect1 id="structure">
- <title>Structure</title>
+ <sect3 id="licensewarning">
+ <title>Final license warning</title>
- <para>
- <emphasis>A quick overview on how all parts fit together in the overall
- structure. An example from the Multi Disk HOWTO is used.</emphasis>
- </para>
+ <para>
+ Please, please, please, place your software under some
+ license. It may not seem important, and to you, it may not be,
+ but licenses <emphasis>are</emphasis> important. For a piece of
+ software to be included in the Debian GNU/Linux distribution, it
+ must have a license that fits the <ulink
+ url="http://www.debian.org/social_contract">Debian Free Software
+ Guidelines</ulink>. If you have no license, your program can not
+ be distributed as a package in Debian until you re-release it
+ under a free license. Please save yourself and others trouble by
+ releasing the first version of your software with a clear
+ license.
+ </para>
- <para>
- As this type of document is supposed to be as much for learning as
- a technical reference document I have rearranged the structure to
- this end. For the designer of a system it is more useful to have
- the information presented in terms of the goals of this exercise
- than from the point of view of the logical layer structure of the
- devices themselves. Nevertheless this document would not be
- complete without such a layer structure the computer field is so
- full of, so I will include it here as an introduction to how it
- works.
- </para>
+ </sect3>
-<!-- Section2: logical-struct -->
+ </sect2>
- <sect2 id="logical-struct">
- <title>Logical structure</title>
+<!-- Section2: chooseversioning-->
- <indexterm>
- <primary>disk!structure, I/O subsystem</primary>
- </indexterm>
+ <sect2 id="chooseversioning">
+ <title>Choosing a Method of Version Numbering</title>
<para>
- This is based on how each layer access each other, traditionally
- with the application on top and the physical layer on the bottom.
- It is quite useful to show the interrelationship between each of
- the layers used in controlling drives.
-
- <screen>
- ___________________________________________________________
- |__ File structure ( /usr /tmp etc) __|
- |__ File system (ext2fs, vfat etc) __|
- |__ Volume management (AFS) __|
- |__ RAID, concatenation (md) __|
- |__ Device driver (SCSI, IDE etc) __|
- |__ Controller (chip, card) __|
- |__ Connection (cable, network) __|
- |__ Drive (magnetic, optical etc) __|
- -----------------------------------------------------------
- </screen>
+ <emphasis>The most important thing about a system of version
+ numbering is that there is one.</emphasis> It may seem pedantic to
+ emphasize this point but you'd be surprised at the number of
+ scripts and small programs that pop up without any version number
+ at all.
</para>
<para>
- In the above diagram both volume management and RAID and
- concatenation are optional layers. The 3 lower layers are in
- hardware. All parts are discussed at length later on in this
- document.
+ <emphasis>The second most important thing about a system of
+ numbering is that the numbers always go up.</emphasis> Automatic
+ version tracking systems and people's sense of order in the
+ universe will fall apart if version numbers don't rise. It doesn't
+ <emphasis>really</emphasis> matter if 2.1 is a big jump and
+ 2.0.005 is a small jump but it does matter that 2.1 is more recent
+ than 2.0.005.
</para>
- </sect2>
-
-<!-- Section2: doc-struct -->
-
- <sect2 id="doc-struct">
- <title>Document structure</title>
<para>
- Most users start out with a given set of hardware and some plans
- on what they wish to achieve and how big the system should be.
- This is the point of view I will adopt in this document in
- presenting the material, starting out with hardware, continuing
- with design constraints before detailing the design strategy that
- I have found to work well. I have used this both for my own
- personal computer at home, a multi purpose server at work and
- found it worked quite well. In addition my Japanese co-worker in
- this project have applied the same strategy on a server in an
- academic setting with similar success.
+ Beyond this, the most common technique seems to be the
+ <quote>major level</quote>, <quote>minor level</quote>,
+ <quote>patch level</quote> version numbering scheme. Whether you
+ are familiar with it or not, you interact with it all the
+ time. The first number is the major number and it signifies major
+ changes or rewrites. The second number is the minor number and it
+ represents added or tweaked functionality on top of a largely
+ coherant structure. The third number is the patch number and it
+ usually will only refer to bug fixes.
</para>
<para>
- Finally at the end I have detailed some configuration tables for
- use in your own design. If you have any comments regarding this
- or notes from your own design work I would like to hear from you
- so this document can be upgraded.
+ The widespread use of this scheme is why I know the nature and
+ relative degree in the differences between a 2.4.12 release of the
+ Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowning
+ anything about any of the releases.
</para>
- </sect2>
-
-<!-- Section2: reading-plan -->
-
- <sect2 id="reading-plan">
- <title>Reading plan</title>
<para>
- <emphasis>As you go beyond 50 pages or so there will be a lot of
- text that experts and even the experienced do not need to read.
- Keeping in mind that we wish to care for all kinds of people in
- the Linux world we might have to make a reading plan. Again,
- an example follows from the Multi Disk HOWTO.</emphasis>
+ You can bend or break these rules, and people do. Beware, if you
+ choose to, someone will get annoyed, assume you don't know, and
+ try and educate you. I always follow this method and I implore you
+ to do so as well.
</para>
-
+
<para>
- Although not the biggest HOWTO it is nevertheless rather big
- already and I have been requested to make a reading plan to make
- it possible to cut down on the volume.
+ Follow these two simple rules and you will not go (too)
+ wrong. Still, there are several version numbering systems that are
+ well known, useful, and that might be worth looking into before
+ you release your first version.
</para>
- <para>
- <variablelist>
-
- <varlistentry>
- <term>Expert</term>
- <listitem>
- <para>
- (aka the elite). If you are familiar with Linux as well as
- disk drive technologies you will find most of what you need in
- the appendices. Additionally you are recommended to read the
- FAQ and the <XRef LinkEnd="bits-n-pieces">chapter.
- </para>
- </listitem>
- </varlistentry>
+ <variablelist>
+ <varlistentry>
+ <term>Linux kernel version numbering:</term>
+ <listitem>
+ <para>The Linux kernel uses a versioning system where any odd
+ minor version number refers to an development or testing release
+ and any even minor version number refers to a stable
+ version. Think about it for a second. Under this system, 2.1 and
+ 2.3 kernels were and always will be development or testing
+ kernels and 2.0, 2.2. and 2.4 kernels are all production code
+ with a higher degree of stability and more testing.
+ </para>
- <varlistentry>
- <term>Experienced</term>
- <listitem>
- <para>
- (aka Competent). If you are familiar with computers in
- general you can go straight to the chapters on
- <XRef LinkEnd="technologies"> and continue from there on.
- </para>
- </listitem>
- </varlistentry>
+ <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
+ progress development that they complain and figure the system
+ out. If you never release an odd minor version but only release
+ even ones, nobody is hurt, and less people are confused. It's
+ worth taking into consideration.
+ </para>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>Newbie</term>
- <listitem>
- <para>
- (mostly harmless). You just have to read the whole thing.
- Sorry. In addition you are also recommended to read all the
- other disk related HOWTOs.
- </para>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>Wine version numbering:</term>
+ <listitem>
+ <para>Because of the unusual nature of wine's development where
+ the not-emulator is constantly improving but not working towards
+ any immediately achievable goal, wine is released every three
+ weeks. Wine does this by labeling 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>
- </variablelist>
- </para>
- </sect2>
+ <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>
- </sect1>
+ <para>
+ Mozilla's version numbering structure has historically been
+ made up of milestones. From the beginning of the mozilla
+ project, the goals of the project in the order and degree to
+ which they were to be achieved were charted out on a series of
+ <ulink url="http://www.mozilla.org/roadmap.html">road
+ maps</ulink>. Major points and achievements along these
+ road-maps were marked as milestones. Therefore, 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>
-<!-- Section1: structure: END -->
+ <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>
-<!-- Section1: technologies -->
+<!-- Section2: documentation-->
- <sect1 id="technologies">
- <title>Technologies</title>
+ <sect2 id="documentation">
+ <title>Documentation</title>
- <indexterm>
- <primary>(your index root)!technologies</primary>
- </indexterm>
+ <para>
+ A huge number of otherwise fantastic free software applications
+ have withered and died because their author was the only person
+ who knew how to use them fully. Even if your program is written
+ primarily for a techno-savvy group of users, documentation is
+ helpful and even necessary for the survival of your project. You
+ will learn later in <xref linkend="releasing"> that you should
+ always release something that is usable. <emphasis>A piece of
+ software without documentation is not usable.</emphasis>
+ </para>
- <para>
- <emphasis>Introduction of technology for the newbie with a few
- references to detailed works. Remember that not everyone has
- Internet access so you have to explain in sufficient details so
- even the newbie can get by.</emphasis>
- </para>
+ <para>
+ There are lots of different people for whom to document and
+ therefore there are lots of ways to document your
+ project. <emphasis>The importance of ocumentation in source code
+ to help facilitate development by a large community is vital but
+ it falls outside the scope of this HOWTO.</emphasis> This being
+ the case, this section deals mostly useful tactics for
+ user-directed documentation.
+ </para>
- </sect1>
+ <para>
+ A combination of tradition and necessity has resulted in a
+ semi-regular system of documentation in most free software
+ projects that is worth following. Both users and developers expect
+ to be able to get documentation in several ways and it's essential
+ that you provide the information they are seeking in a form they
+ can read if your project is ever going to get off the
+ ground. People have come to expect:
+ </para>
-<!-- Section1: technologies: END -->
+ <sect3>
+ <title>Man pages</title>
+ <para>Your users will want to be able to type <quote>man
+ projectname</quote> end up with a nicely formatted man page
+ highlighting the basic use of yourapplication. Make sure that
+ before you release your program, you've planned for this.
+ </para>
-<!-- Section1: implement -->
+ <para>
+ Man pages are not difficult to write. There is excellent
+ documentation on the man page writing process available through the
+ <quote>The Linux Man-Page-HOWTO</quote> 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>
- <sect1 id="implement">
- <title>Implementation</title>
+ <para>
+ It is also possible to write man pages using DocBook SGML and
+ convert them into man pages. Because man pages are so simple and
+ the DocBook method relatively new, I have not been able to follow
+ this up but would love help from anyone who can give me more
+ information on how exactly this is done.
+ </para>
+ </sect3>
- <indexterm>
- <primary>(your index root)!implementation</primary>
- </indexterm>
+ <sect3>
+ <title>Command line accessible documentation</title>
- <para>
- <emphasis>Now your readers should have a sufficient knowledge of
- what this is about and now we come to the hands on of implementing
- your clever scheme.</emphasis>
- </para>
+ <para>
+ Most users will expect some basic amount of documentation to be
+ easily available from the command line. For few programs should
+ this type of documentation extend for more than one screen (24 or
+ 25 lines) but it should cover the basic usage, a brief (one or
+ two sentence) description of the program, a list of the commands
+ with explanations, all the major options (also with
+ explanations), 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>
- </sect1>
+ <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>
-<!-- Section1: implement: END -->
+ <para>
+ It has become a GNU convention to make this type of information
+ accessible with the <quote>-h</quote> and the
+ <quote>--help</quote> options. Most GNU/Linux users will expect
+ to be able to retrieve basic documentation these ways so if you
+ choose to use different 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 command-line help, there are certain
+ files where people will look for documentation, especially in any
+ package containing source code. In a source distribution, most of
+ these files can be stored in a the root directory of the source
+ distribution or in a subdirectory of the root called
+ <quote>doc</quote> or <quote>Documentation</quote>. Common files
+ places in these places include:
+ </para>
-<!-- Section1: maint -->
+ <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 README
+ file and should quickly and concisely describe how to build
+ and install the program. Usually an INSTALL file simply
+ instructs the user to run <quote>./configure; make; make
+ install</quote> and touches on any unusual options or actions
+ that may be necessary. More advanced users can usually avoid
+ INSTALL files but it's good practice to at least glance at one
+ 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 implies, 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>NEWS</term>
+
+ <listitem>
+ <para>A NEWS file and a ChangeLog are similar. A news file is
+ not typically sorted by version but just whenever new features
+ are added, the developer responisble will make a note in the
+ NEWS file. NEWS files should not have to changed before a
+ release (they should be kept up to date all along) but it's
+ usually a good idea to check first anyway because often people
+ just forget to keep them as current as they should.</para>
+ </listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term><acronym>FAQ</acronym></term>
+
+ <listitem>
+ <para>For those of you that don't already
+ know. <acronym>FAQ</acronym> stands for Frequently Asked
+ Questions and a FAQ is a collection of exactly that. FAQs
+ are not difficult to make. Simply make a policy that if you
+ are asked a question or see a question on a mailing list two
+ or more times, add it the question (and its answer) to your
+ FAQ. FAQs are more optional than the files listed above but
+ they can save your time, increase usability, and decrease
+ headaches on all sides.</para>
+ </listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ </sect3>
- <sect1 id="maint">
- <title>Maintenance</title>
+ <sect3>
+ <title>Website</title>
+ <para>
+ It's only idirectly an issue of documentation but a good website
+ is quickly becoming an essential part of any free software
+ project's documentation. 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
+ provide a direct link to all the available ways of downloading
+ your software.
+ </para>
+ </sect3>
- <indexterm>
- <primary>(your index root)!maintenance</primary>
- </indexterm>
+ <sect3>
+ <title>Other documentation hints</title>
- <para>
- <emphasis>Few systems and designs are maintenance free, here you
- explain how to keep the system running.</emphasis>
- </para>
+ <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>
- </sect1>
+ <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>
-<!-- Section1: maint: END -->
+<!-- Section2: presentation -->
+ <sect2 id="presentation">
+ <title>Other Presentation Issues</title>
+ <para>
+ Many of the remaining issues surrounding the creation of a new
+ free software program fall under what most people describe as
+ common sense issues. Still, they are worth noting briefly in
+ hopes that they may remind a developer of something they may have
+ forgotten.
+ </para>
-<!-- Section1: adv-issues -->
+ <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>
- <sect1 id="adv-issues">
- <title>Advanced Issues</title>
+ <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. Your users or fellow
+ developers can and will do the the binary packages for
+ you.</emphasis>
+ </para>
+ </sect3>
- <indexterm>
- <primary>(your index root)!advanced topics</primary>
- </indexterm>
+ <sect3>
+ <title>Useful tidbits and presentation hints</title>
- <para>
- <emphasis>You can get most things up and running in a quick and
- dirty fashion, useful for testing and getting used to how things
- work. For more serious use you would need to be a little more
- advanced. This is the place to explain it all, if applicable.</emphasis>
- </para>
+ <para>
+ Other useful hints include:
+ </para>
- </sect1>
+ <para>
+ <itemizedlist>
-<!-- Section1: adv-issues: END -->
+ <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. Keep in mind that this
+ location will recieve many requests for downloads around
+ releases so make sure that the server you choose for this
+ purpose has adequate bandwidth.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis>Make sure that there is a consistent email address
+ for bug reports.</emphasis> It's usually a good idea to make
+ this something that is NOT your primary email address like
+ 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. 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>
-<!-- Section1: moreinfo -->
+ </itemizedlist>
+ </para>
- <sect1 id="moreinfo">
- <title>Further Information</title>
+ <para>
+ A version control system can make a lot of these problems of
+ packaging (and a lot of other problems mentioned in this HOWTO)
+ much easier. If you are using *NIX, CVS is your best bet. I
+ recommend Karl Fogel's book on the subject (and the <ulink
+ url="http://cvsbook.red-bean.com/">posted HTML version</ulink>)
+ wholeheartedly.
+ </para>
- <indexterm>
- <primary>(your index root)!information resources</primary>
- </indexterm>
+ <para>
+ CVS or not, you should probably invest some time into learning
+ about a version control system because it provides an automated
+ way of solving many of the problems introduced into this HOWTO.
+ I am not aware of any free version control systems for windows or
+ mac but I know that CVS clients exist for both
+ platforms. Websites like <ulink
+ url="http://sourceforge.net">SourceForge</ulink> do a great job
+ as well with a nice, easy to use interface to CVS.
+ </para>
- <para>
- <emphasis>A HOWTO cannot describe everything, some times the user
- has to venture out on th enet to get more information or just
- updates. Here is the place to tell where and how. Again examples
- from the Multi Disk HOWTO, replace as needed.</emphasis> There is wealth
- of information one should go through when setting up a major system,
- for instance for a news or general Internet service provider. The
- FAQs in the following groups are useful:
- </para>
+ I'd love to devote more space in this HOWTO to CVS because I love
+ it (I even use CVS to keep version straight on this HOWTO!) but I
+ think it falls outside the scope of this document and should/has
+ already have its own HOWTO written about it.
+ </para>
+ </sect3>
+ </sect2>
+ </sect1>
-<!-- Section2: newsgroups -->
+<!-- Section1: starting: END -->
- <sect2 id="newsgroups">
- <title>News groups</title>
+<!-- Section1: developers -->
- <indexterm>
- <primary>disk!information resources!news groups</primary>
- </indexterm>
+ <sect1 id="developers">
+ <title>Maintaining a Project: Interacting with Developers</title>
+ <indexterm>
+ <primary>fswd!developers</primary>
+ </indexterm>
- <para>Some of the most interesting news groups are:
+ <para>
+ Once you have gotten your project started, you have overcome the
+ most difficult hurdles in the development process of your
+ program. Laying a firm foundation is essential, but the development
+ process itself is equally important and provides quite a few
+ opportunities for failure. In the next two sections, I will cover
+ running a project by discussing how to maintain a project through
+ interactions with developers and with users.
+ </para>
- <itemizedlist>
+ <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>
- <listitem>
- <para>
- <ulink url="news:comp.arch.storage">Storage</ulink>.
- </para>
- </listitem>
+ <para>
+ The major difference between free software development and
+ propriety software development is the developer base. As the leader
+ of a free software project, you need to attract and keep developers
+ in a way that leaders of proprietary software projects simply don't
+ have to worry about. <emphasis>As the person leading development of
+ a free software project, you must harness the work of fellow
+ developers by making responsible decisions and by responsibly
+ choosing not to make decisions. You have to direct developers
+ without being overbearing or bossy. You need to strive to earn
+ respect and never forget to give it out.</emphasis>
+ </para>
- <listitem>
- <para>
- <ulink url="news:comp.sys.ibm.pc.hardware.storage">PC storage</ulink>.
- </para>
- </listitem>
+<!-- Section2: delegation -->
- <listitem>
- <para>
- <ulink url="news:alt.filesystems.afs">AFS</ulink>.
- </para>
- </listitem>
+ <sect2 id="delegation">
+ <title>Delegating Work</title>
- <listitem>
- <para>
- <ulink url="news:comp.periphs.scsi">SCSI</ulink>.
- </para>
- </listitem>
+ <para>
+ By now, you've hypothetically followed me through the early
+ programming of a piece of software, the creation of a website and
+ system of documentation and 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>
- <listitem>
- <para>
- <ulink url="news:comp.os.linux.setup">Linux setup</ulink>.
- </para>
- </listitem>
+ <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>
- </itemizedlist>
+ <para>
+ Delegation is the political way of describing this process of
+ <quote>letting go.</quote> It is the process of handing some of
+ the responsibility and power over your project to other responsible
+ and involved developers. It is difficult for anyone who has
+ invested a large deal of time and energy into a project but it
+ essential for the growth of any free software project. One person
+ can only do so much. A free software project is nothing
+ without the involvement of a group of developers. A group of
+ developers can only be maintained through respectful and
+ responsible leadership and delegation.
</para>
<para>
- Most newsgroups have their own FAQ that are designed to answer most
- of your questions, as the name Frequently Asked Questions indicate.
- Fresh versions should be posted regularly to the relevant newsgroups.
- If you cannot find it in your news spool you could go directly to the
- <ulink url="ftp://rtfm.mit.edu/">FAQ main archive FTP site</ulink>.
- The WWW versions can be browsed at the
- <ulink url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html">FAQ
- main archive WWW site</ulink>.
+ 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>
<para>
- Some FAQs have their own home site, of particular interest:
+ In a bit of a disclaimer, delegation need not mean rule by
+ comittee. In many cases it does and this has been proven to
+ work. In other cases this has been the death of a project. <ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink> argues that <quote>OSS
+ projects do best when one person is the clear leader of a team and
+ makes the big decisions (design changes, release dates, and so
+ on).</quote> I think this often true but would urge developers to
+ consider the ideas that the project leader need not be the
+ projects founder and that these important powers need not all rest
+ in one person but that a release manager may be different than a
+ lead developer. These situations are tricky politically though so
+ be careful and make sure this is necessary before you go around
+ empowering people.
+ </para>
- <itemizedlist>
+ <sect3>
+ <title>How to delegate</title>
+
+ <para>
+ You may find that other developers seem even more experienced or
+ knowledgeable than you. Your job as a maintainer does not mean
+ you have to have to be the best or the brightest. It means you
+ need are responsible for showing good judgment and for
+ recognizing which solutions are maintainable and which are not.
+ </para>
+ <para>
+ Like anything, its easier to watch others delegate than to do it
+ yourself. In a sentence: <emphasis>Keep an eye out for other
+ qualified developers who show an interest and sustained
+ involvement with your project and try and shift responsibility
+ 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>
- <listitem>
- <para>
- <ulink url="http://www.paranoia.com/~filipg/HTML/LINK/F_SCSI.html">SCSI FAQ</ulink>
- and
- </para>
- </listitem>
+ <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>
- <listitem>
- <para>
- <ulink url="http://alumni.caltech.edu/~rdv/comp_arch_storage/FAQ-1.html">comp.arch.storage FAQ</ulink>.
- </para>
- </listitem>
+ <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's <ulink
+ url="http://www.debian.org/social_contract">social
+ contract</ulink> and a <ulink
+ url="http://www.debian.org/devel/constitution">constitution</ulink>. To
+ facilitate this system, there are special teams (i.e. the
+ install team, the Japanese language team) as well as a technical
+ committee and a project leader. The leader's main responsibility
+ is to, <quote>Appoint Delegates or delegate decisions to the
+ Technical Committee.</quote>
+ </para>
- </itemizedlist>
- </para>
- </sect2>
+ <para>
+ While both of these projects operate on a scale that your
+ project will not (at least initially), their example is
+ helpful. Debian's idea of a project leader who can do
+ <emphasis>nothing</emphasis> but delegate serves as a
+ caricature of how a project can involve and empower a huge
+ number of developers and grow to a huge size.
+ </para>
-<!-- Section2: maillists -->
+ </sect4>
- <sect2 id="maillists">
- <title>Mailing Lists</title>
+ <sect4 id="releasemanager">
+ <title>Publicly appoint someone as the release manager for a
+ specific release.</title>
- <indexterm>
- <primary>disk!information resources!mailing lists</primary>
- </indexterm>
+ <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>
- These are low-noise channels mainly for developers. Think twice
- before asking questions there as noise delays the development.
- Some relevant lists are <email>linux-raid</email>,
- <email>linux-scsi</email> and <email>linux-ext2fs</email>. Many
- of the most useful mailing lists run on the <Literal
- remap="tt">vger.rutgers.edu</Literal> server but this is
- notoriously overloaded, so try to find a mirror. There are some
- lists mirrored at <ulink url="http://www.redhat.com">The Redhat
- Home Page</ulink>. Many lists are also accessible at <ulink
- url="http://www.linuxhq.com/lnxlists">linuxhq</ulink>, and the
- rest of the web site contains useful information as well.
- </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 room to
+ breath.
+ </para>
+ </sect4>
- <para>
- If you want to find out more about the lists available you can send
- a message with the line <command>lists</command> to the list server
- at <email>majordomo@vger.rutgers.edu</email>.
- If you need help on how to use the mail server just send the line
- <command>help</command> to the same address. Due to the
- popularity of this server it is likely it takes a bit to time before
- you get a reply or even get messages after you send a
- <command>subscribe</command> command.
- </para>
+ <sect4 id="delegatebranch">
+ <title>Delegate control of an entire branch.</title>
+ <para>
+ If your project chooses to have branches (as described in <xref
+ linkend="branches">), it might be a good idea to appoint someone
+ else to be the the head of a branch. If you like focusing your
+ energy on development releases and the implementation of new
+ features, hand total control over the stable releases to a
+ well-suited developer.
+ </para>
- <para>
- There is also a number of other majordomo list servers that can
- be of interest such as the EATA driver list
- (<email>linux-eata@mail.uni-mainz.de</email>)
- and the Intelligent IO list <email>linux-i2o@dpt.com</email>.
- </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>
- Mailing lists are in a state of flux but you can find links to a
- number of interesting lists from the
- <ulink url="http://www.linuxdoc.org/">Linux Documentation
- Homepage</ulink>.
+ 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>
- </sect2>
-<!-- Section2: howto -->
+ <sect3>
+ <title>Technical judgment</title>
- <sect2 id="howto">
- <title>HOWTO</title>
+ <para>
+ In <emphasis>Open Source Development with CVS</emphasis>, Karl
+ Fogel makes a convincing argument that the most important things
+ to keep in mind when rejecting or accepting patches are:
+ </para>
- <indexterm>
- <primary>disk!information resources!HOWTOs</primary>
- </indexterm>
+ <para>
+ <itemizedlist>
- <para>
- These are intended as the primary starting points to get the
- background information as well as show you how to solve a
- specific problem. Some relevant HOWTOs are
- <Literal remap="tt">Bootdisk</Literal>,
- <Literal remap="tt">Installation</Literal>,
- <Literal remap="tt">SCSI</Literal> and
- <Literal remap="tt">UMSDOS</Literal>. The main site for these is the
- <ulink url="http://www.linuxdoc.org/">LDP archive</ulink>at
- Metalab (formerly known as Sunsite).
- </para>
+ <listitem>
+ <para>A firm knowledge of the scope of your program (that's the
+ <quote>idea</quote> I talked about in <xref linkend="chooseproject">);</para>
+ </listitem>
+
+ <listitem>
+ <para>The ability to recognize, facilitate, and direct
+ <quote>evolution</quote> of your program so that the program
+ can grow and change and incorporate functionality that was
+ originally unforeseen;</para>
+ </listitem>
- <para>
- There is a a new HOWTO out that deals with setting up a DPT RAID
- system, check out the
- <ulink url="http://www.ram.org/computing/linux/dpt_raid.html">DPT RAID
- HOWTO homepage</ulink>.
- </para>
- </sect2>
+ <listitem>
+ <para>The necessity to 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.</para>
+ </listitem>
-<!-- Section2: local-res -->
+ </itemizedlist>
+ </para>
- <sect2 id="local-res">
- <title>Local Resources</title>
+ <para>
+ These are the criteria that you as a project maintainer should
+ take into account each time you receive a patch.
+ </para>
- <indexterm>
- <primary>disk!information resources!local</primary>
- </indexterm>
+ <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 responsibility and
+ responsive leadership as it tests and serves the interests of
+ your software's community.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Technical issues are not always good justification</title>
+ <para>
+ Especially 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 an
+ application of a patch but it is not always a good reason to
+ reject a change outright. Even small changes are worth the
+ effort of working with the developer submitting the patch to
+ iron out bugs and incorporate the change if you 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
+ making their next patch.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Common courtesy</title>
+ <para>
+ It should go without saying but, <emphasis>above all and in all
+ cases, just be nice.</emphasis> If someone has an idea and cares
+ about it enough to write some code and submit a patch, they
+ care, they are motivated, and they are already involved. Your
+ goal as the maintainer is make sure they submit again. They may
+ have thrown you a dud this time but next time may be the idea or
+ feature that revolutionizes your project.
+ </para>
+
+ <para>
+ It is your responsibility to first justify your choice to not
+ incorporate their change clearly and concisely. Then thank
+ them. Let them know that you a appreciate their help and feel
+ horrible that you can't incorporate their change. Let them know
+ that you look forward to their staying involved and you hope
+ that the next patch or idea meshes better with your project
+ because you appreciate their work and want to see it in the
+ project. If you have ever had a patch rejected after putting a
+ large deal of time, thought, and energy into it, you remember
+ how it feels and it feels bad. Keep this in mind when you have
+ to let someone down. It's never easy but you need to do
+ everything you can to make it as not-unpleasant as possible.
+ </para>
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: branches -->
+
+ <sect2 id="branches">
+ <title>Stable and Development Branches</title>
<para>
- In most distributions of Linux there is a document directory
- installed, have a look in the <filename>/usr/doc</filename>
- directory. where most packages store their main documentation and
- README files etc. Also you will here find the HOWTO archive
- (<filename>/usr/doc/HOWTO</filename>) of ready formatted HOWTOs
- and also the mini-HOWTO archive
- (<filename>/usr/doc/HOWTO/mini</filename>) of plain text
- documents.
+ The idea of stable and development branches has already been
+ described briefly in <xref linkend="chooseversioning"> and in
+ <xref linkend="delegatebranch">. These allusions attest to some of
+ the ways that multiple branches can affect your software. Branches
+ can let you avoid (to some extent) some of the problems around
+ rejecting patches (as described in <xref linkend="patching">) by
+ allowing you to temporarily compromise the stability of your
+ project without affecting those users who need that stability.
</para>
<para>
- Many of the configuration files mentioned earlier can be found in
- the <filename>/etc</filename> directory. In particular you will
- want to work with the <filename>/etc/fstab</filename> file that
- sets up the mounting of partitions and possibly also
- <filename>/etc/raidtab</filename> file that is used for the
- <Literal remap="tt">md</Literal> system to set up RAID.
+ The most common way of branching your project is to have one
+ branch that is stable and one that is for development. This is the
+ model followed by the Linux kernel that is described in <xref
+ linkend="chooseversioning">. In this model, there is 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> as described in <xref
+ linkend="freezing"> where major changes and added features are
+ rejected or put on hold under the development kernel is released
+ as the new stable branch and major development resumes on the
+ development branch. Bug fixes and small changes that are unlikely
+ to have any large negative repercussions are incorporated into the
+ stable branch as well as the development branch.
</para>
<para>
- The kernel source in <filename>/usr/src/linux</filename> is, of
- course, the ultimate documentation. In other words, <quote>use
- the source, Luke</quote>. It should also be pointed out that the
- kernel comes not only with source code which is even commented
- (well, partially at least) but also an informative
- <filename>/usr/src/linux/Documentation</filename>. If you are
- about to ask any questions about the kernel you should read this
- first, it will save you and many others a lot of time and
- possibly embarrassment.
+ 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's but this use of
+ branches helps demonstrate how they can be used to balance
+ consistent and effective development with the need to make regular
+ and usable releases.
</para>
<para>
- Also have a look in your system log file
- (<filename>/var/log/messages</filename>) to see what is going on
- and in particular how the booting went if too much scrolled off
- your screen. Using <command>tail -f /var/log/messages</command>
- in a separate window or screen will give you a continuous update
- of what is going on in your system.
+ In trying to set up a development tree for yourself, there are
+ several things that might be useful to keep in mind:
</para>
<para>
- You can also take advantage of the <filename>/proc</filename>
- file system that is a window into the inner workings of your
- system. Use <command>cat</command> rather than
- <command>more</command> to view the files as they are reported as
- being zero length. Reports are that <command>less</command> works
- well here.
- </para>
- </sect2>
+ <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. For you,
+ two is probably 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>
-<!-- Section2: web -->
+ <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>
- <sect2 id="web">
- <title>Web Sites</title>
+ <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>
- <indexterm>
- <primary>disk!information resources!WWW</primary>
- </indexterm>
- <indexterm>
- <primary>disk!information resources!web pages</primary>
- </indexterm>
+ <para>
+ If you are going to use branches, especially early on, keep in
+ mind that people are conditioned to understand the terms
+ <quote>stable</quote> and <quote>development</quote> and you
+ probably can't go wrong with this simple and common division of
+ branches.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Make sure all your branches are always available</term>
+ <listitem>
+ <para>Like a lot of this document, this should probably should
+ go without saying but experience has taught me that it's not
+ always obvious to people. It's a good idea to physically split
+ up different branches in different directories or directory
+ trees on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
+ site. Linux accomplishes this by having kernels in a v2.2 and a
+ v2.3 subdirectory where it is immediately obvious (after you
+ know their version numbering scheme) which directory is for the
+ most recent stable and the current development releases. Debian
+ accomplishes this by naming all their distribution with names
+ (i.e. woody, potato, etc.) and then changing symlinks named
+ <quote>stable,</quote> <quote>unstable</quote> and
+ <quote>frozen</quote> to point to which ever distribution (by
+ name) is in whatever stage. Both methods work and there are
+ others. In any case, it is important that different branches
+ are always available, are accessible from consistent locations,
+ and that different branches are clearly distinguished from each
+ other so your users know exactly what they want 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 a huge number of informative web sites available. By
- their very nature they change quickly so do not be surprised
- if these links become quickly outdated.
+ There are more issues surrounding interaction with developers in a
+ free software project that I can not touch on in great detail in a
+ HOWTO of this size. Please don't hesitate to contact me if you see
+ any major omissions.
</para>
<para>
- A good starting point is of course the
- <ulink url="http://www.linuxdoc.org/">Linux Documentation
- Project</ulink> home page, an information central for
- documentation, project pages and much more.
+ Other smaller issues that are worth mentioning are:
</para>
- <para>
- Please let me know if you have any other leads that can be
- of interest.
- </para>
- </sect2>
+ <sect3 id="freezing">
+ <title>Freezing</title>
+ <para>
+ For those projects that choose to adopt a split development model
+ (<xref linkend="branches">), freezing is a concept that is worth
+ becoming familiar with.
+ </para>
+
+ <para>
+ Freezes come in two major forms. A <quote>feature freeze</quote>
+ is a period when no significant functionality is added to a
+ program. It is a period where established functionality (even
+ skeletons of barely working functionality) can be improved and
+ perfected. It is a period where bugs are fixed. This type of
+ freeze is usually applied some period (a month or two) before a
+ release. It is easy to push a release back as you wait for
+ <quote>one more feature</quote> and a freeze helps to avoid this
+ situation by drawing the much needed line in the sand. It gives
+ developers room they need to get a program ready for release.
+ </para>
+
+ <para>
+ The second type of freeze is a <quote>code freeze</quote> which
+ is much more like a released piece of software. Once a piece of
+ software has entered a 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>
- </sect1>
+ <para>
+ Even if you never choose to appoint a release manager (<xref
+ linkend="releasemanager">), you will have an easier time
+ justifying the rejection or postponement of patches (<xref
+ linkend="patching"> before a release with a publicly stated
+ freeze in effect.
+ </para>
+ </sect3>
-<!-- Section1: moreinfo: END -->
+ <sect3>
+ <title>Forking</title>
+ <para>
+ Forks are the most extreme version 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 and redundancy of
+ work. Luckily, usually the threat of the fork is enough to scare
+ the maintainer or maintainers of a project into changing the way
+ they run their project to avoid it.
+ </para>
-<!-- Section1: help -->
+ <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>
- <sect1 id="help">
- <title>Getting Help</title>
+<!-- Section1: users -->
- <indexterm>
- <primary>(your index root)!assistance, obtaining</primary>
- </indexterm>
+ <sect1 id="users">
+ <title>Maintaining a Project: Interacting with Users</title>
+ <indexterm>
+ <primary>fswd!users</primary>
+ </indexterm>
<para>
- In the end you might find yourself unable to solve your problems
- and need help from someone else. The most efficient way is either
- to ask someone local or in your nearest Linux user group, search
- the web for the nearest one.
+ If you've worked your way up to here, congratulations, you are
+ nearing the end of this document. This final section describes some
+ of the situations in which you, in your capacity as project
+ maintainer, will be interacting with users. It gives some
+ suggestions on how these situations might be handled effectively.
</para>
<para>
- Another possibility is to ask on Usenet News in one of the many,
- many newsgroups available. The problem is that these have such a
- high volume and noise (called low signal-to-noise ratio) that your
- question can easily fall through unanswered.
+ 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>
- No matter where you ask it is important to ask well or you will
- not be taken seriously. Saying just <emphasis remap="it">my disk
- does not work</emphasis> is not going to help you and instead the
- noise level is increased even further and if you are lucky someone
- will ask you to clarify.
+ Users in the free software community are different than developers
+ and are also different than users in the world of proprietary
+ software and they should be treated differently than either
+ group. Some ways in which the groups differ significantly follow:
</para>
<para>
- Instead describe your problems in some detail that will enable
- people to help you. The problem could lie somewhere you did not
- expect. Therefore you are advised to list the following information
- about your system:
+ <itemizedlist>
+
+ <listitem>
+ <para>The lines between users and developers are blurred in ways
+ that is totally foreign to any proprietary development
+ model. Your users are often your developers and vice
+ versa.</para>
+ </listitem>
+
+ <listitem>
+ <para>In the free software world, you are often your users only
+ choice. Because there is such an emphasis on not replicating the
+ work of others in the free software community and because the
+ element of competition present in the propriety software model is
+ absent (or at least in an extremely different form) in the free
+ software development model, you will probably be the only project
+ that does what you do (or at least the only one that does what
+ you do in the way that you do it). This means your responsiveness
+ to your users is even more important than in the proprietary
+ software world.</para>
+ </listitem>
+
+ <listitem>
+ <para>In an almost paradoxical situation, free software projects
+ have less immediate or dire consequences for ignoring their users
+ altogether--it is also often easier to do. Because you don't
+ usually need to compete with another product 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 a commitment to your users or by both.</para>
+ </listitem>
+ </itemizedlist>
</para>
<para>
- <variablelist>
+ Trying to tackle this unique situation can only be done
+ indirectly. Developers and maintainers need to listen to users and
+ to try and be as responsive as possible. A solid knowledge of the
+ situation recounted above is any free software developer's best tool
+ for shifting his development or leadership style to fit the unique
+ process of free software 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> of your
+ users are your testers.
+ </para>
+
+ <para>
+ It is important that this distinction be made early on because not
+ all of your users want to be testers. Many users want to use
+ stable software and don't care if they don't have the newest
+ greatest software with the latest 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>
+ <para>
+ <ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink> describes what a good test
+ should look for in each module:
+ </para>
+
+ <variablelist>
<varlistentry>
- <term>Hardware</Term>
+ <term>Boundary conditions</term>
+
<listitem>
<para>
- <itemizedlist>
- <listitem>
- <para>Processor</para>
- </listitem>
-
- <listitem>
- <para>DMA</para>
- </listitem>
-
- <listitem>
- <para>IRQ</para>
- </listitem>
-
- <listitem>
- <para>Chip set (LX, BX etc)</para>
- </listitem>
-
- <listitem>
- <para>Bus (ISA, VESA, PCI etc)</para>
- </listitem>
-
- <listitem>
- <para>
- Expansion cards used (Disk controllers, video, IO
- etc.)
- </para>
- </listitem>
-
- </itemizedlist>
+ Maximum buffer lengths, data conversions, upper/lower boundary
+ limits, and so on.
</para>
</listitem>
- </varlistentry>
+ </varlistentry>
<varlistentry>
- <term>Software</term>
+ <term>Inappropriate behavior</term>
+
<listitem>
<para>
- <itemizedlist>
-
- <listitem>
- <para>BIOS (On motherboard and possibly SCSI host adapters)</para>
- </listitem>
-
- <listitem>
- <para>LILO, if used</para>
- </listitem>
-
- <listitem>
- <para>
- Linux kernel version as well as possible modifications
- and patches
- </para>
- </listitem>
-
- <listitem>
- <para>Kernel parameters, if any</para>
- </listitem>
-
- <listitem>
- <para>
- Software that shows the error (with version number
- or date)
- </para>
- </listitem>
-
- </itemizedlist>
+ Its a good idea to find out what a program will do if a user
+ hands it a value it isn't expecting, hits the wrong button,
+ etc. Ask yourself a bunch of what if questions and think of
+ anything that <emphasis>might</emphasis> fail or
+ <emphasis>might</emphasis> go wrong and find out what program
+ would do in that case.
</para>
-
</listitem>
- </varlistentry>
+ </varlistentry>
<varlistentry>
- <term>Peripherals</term>
+ <term>Graceful failure</term>
+
<listitem>
<para>
- <itemizedlist>
+ The answer to a number of the <quote>what if</quote> questions
+ above is probably <quote>failure</quote> which is often the
+ only answer. Now make sure that it happens nicely. Make sure
+ that when it crashes, there is some indication of why it
+ crashed or failed so that the user or developer understands
+ whats going on.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Type of disk drives with manufacturer name, version and type
- </para>
- </listitem>
+ </varlistentry>
- <listitem>
- <para>Other relevant peripherals</para>
- </listitem>
+ <varlistentry>
+ <term>Standards conformance</term>
- </itemizedlist>
+ <listitem>
+ <para>
+ If possible, make sure your programs conforms to
+ standards. Don't be too creative with interfaces. If it is
+ non-interactive, make sure it communicates over appropriate and
+ established channels with other programs and with the rest of
+ the system.
</para>
</listitem>
- </varlistentry>
+ </varlistentry>
</variablelist>
- </para>
-
- <para>
- Remember that booting text is logged to
- <filename>/var/log/messages</filename> which can answer most of
- the questions above. Obviously if the drives fail you might not be
- able to get the log saved to disk but you can at least scroll
- back up the screen using the <keycap>SHIFT</keycap> and
- <keycap>PAGE UP</keycap> keys. It may also be useful to include
- part of this in your request for help but do not go overboard,
- keep it <emphasis>brief</emphasis> as a complete log file dumped
- to Usenet News is more than a little annoying.
- </para>
-
- </sect1>
-
-<!-- Section1: help: END -->
+ <sect3>
+ <title>Automated testing</title>
+ <para>
+ For many programs, many common mistakes can be caught by
+ automated means. Automated tests tend to be pretty good at
+ catching errors that you've run into several times before or
+ something you just forget. They are not very good at finding
+ errors, even major ones, that were totally unforeseen.
+ </para>
-<!-- Section1: remarks -->
+ <para>
+ CVS comes with a bourne shell script called sanity.sh that is
+ worth looking at. Debian uses a program called lintian that
+ checks Debian packages for all of the most common errors. While
+ use of these scripts may not be 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>
- <sect1 id="remarks">
- <title>Concluding Remarks</title>
+ <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>
- <indexterm>
- <primary>(your index root)!conclusion</primary>
- </indexterm>
+ <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>
- <emphasis>Just summing up... Also a place for general
- recommendations.</emphasis>
- </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>
- </sect1>
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>Make things simple for your testers</term>
+ <listitem>
+ <para>Your testers are doing you a favor so make it as easy as
+ possible for them. This means that you should be careful to
+ package your software in a way that is easy to find, unpack,
+ install, and uninstall. This also means you should explain
+ what you are looking for to each tester and make the means for
+ reporting bugs simple and well established. The key is to
+ provide as much structure as possible to make your testers'
+ jobs easy and maintain as much flexibility as possible for
+ those that want to do things a little differently.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Be responsive to your testers</term>
+ <listitem>
+ <para>When your testers submit bugs, respond to them and
+ respond quickly. Even if you are only responding to tell them
+ that the bug has already been fixed, quick and consistent
+ responses make them feel like their work is heard, important,
+ and appreciated.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Thank your testers</term>
+ <listitem>
+ <para>Thank them personally each time they send you
+ patch. Thank them publicly in the documentation and the about
+ section of your program. You appreciate your testers and your
+ program would not be possible without their help. Make sure
+ they know it. Pat them on the back to make sure the rest of
+ the world knows it too. It will be appreciated more than you
+ expected.</para>
+ </listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
-<!-- Section1: remarks: END -->
+ </sect3>
+ </sect2>
+<!-- Section2: support -->
-<!-- Section1: faq -->
+ <sect2 id="support">
+ <title>Setting up Support Infrastructure</title>
- <sect1 id="faq">
- <title>Questions and Answers</title>
+ <para>
+ While testing is important, the large part of your interactions
+ and responsibility to your users falls under the category of
+ support. The best way to make sure your users are adequately
+ supported in using your program is to set up a good infrastructure
+ for this purpose so that your developers and users help each other
+ and less of the burden falls on you. This way, people will also
+ get quicker and better responses to their questions. This
+ infrastructure comes in several major forms:
+ </para>
- <indexterm>
- <primary>(your index root)!FAQ</primary>
- </indexterm>
- <indexterm>
- <primary>(your index root)!frequently asked questions</primary>
- </indexterm>
+ <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>
- <para>
- <emphasis>Check the newsgroups and try to determine some frequent
- problems and cover them here. Again an example from the Multi Disk
- HOWTO.</emphasis>
- </para>
+ <sect3>
+ <title>Mailing lists</title>
+ <para>
+ Aside from documentation, effective mailing lists will be your
+ greatest tool in providing user support. Running a mailing list
+ well is more complicated than installing mailing list software
+ onto a machine.
+ </para>
- <para>
- This is just a collection of what I believe are the most common
- questions people might have. Give me more feedback and I will turn
- this section into a proper FAQ.
- </para>
+ <sect4>
+ <title>Separate lists</title>
+
+ <para>
+ A good idea is too separate your user and development mailing
+ lists (perhaps into project-user@host and project-devel@host)
+ and enforce the division. If people post a development question
+ onto -user, politely ask them to repost it onto -devel and vise
+ versa. Subscribe yourself to both groups and encourage all
+ primarily developers to do the same.
+ </para>
- <para>
- <itemizedlist>
- <listitem>
<para>
- Q:How many physical disk drives (spindles) does a Linux system need?
+ This system provides that no one person is stuck doing all of
+ the support work and works so that users learn more about the
+ program, they can help newer users with their questions.
</para>
+ </sect4>
+ <sect4>
+ <title>Choose mailing list software well</title>
<para>
- A: Linux can run just fine on one drive (spindle). Having
- enough RAM (around 32 MB, and up to 64 MB) to support swapping
- is a better price/performance choice than getting a second
- disk. (E)IDE disk is usually cheaper (but a little slower) than
- SCSI.
+ Please don't make the selection of mailing list software
+ impulsively. Please consider easy accessibility by users without
+ a lot of technical experience so you want to be as easy as
+ possible. Web accessibility to an archive of the list is also
+ important.
</para>
- </listitem>
- <listitem>
<para>
- Q: Are there any disadvantages in this scheme?
+ 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 so. 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>
- A: There is only a minor snag: if even a single partition
- overflows the system might stop working properly. The severity
- depends of course on what partition is affected. Still this is
- not hard to monitor, the command <command>df</command> gives
- you a good overview of the situation. Also check the swap
- partition(s) using <command>free</command> to make sure you are
- not about to run out of virtual memory.
+ 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>
- </listitem>
+ </sect4>
+ </sect3>
- <listitem>
+ <sect3>
+ <title>Other support ideas</title>
+
+ <para>
+ A mailing list and accessible documentation are far from all you
+ can do to set up good user support infrastructure. Be
+ creative. If you stumble across something works well, email me
+ and I'll include it here in the HOWTO.
+ </para>
+
+ <sect4>
+ <title>Make your self accessible</title>
<para>
- Q: OK, so should I split the system into as many partitions as
- possible for a single drive?
+ 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>
+ which has become extremely possible and which I like quite a
+ bit.
</para>
<para>
- A: No, there are several disadvantages to that. First of all
- maintenance becomes needlessly complex and you gain very little
- in this. In fact if your partitions are too big you will seek
- across larger areas than needed. This is a balance and
- dependent on the number of physical drives you have.
+ 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 and track
+ them in an orderly fashion.
</para>
- </listitem>
+ </sect4>
+ </sect3>
+ </sect2>
- </itemizedlist>
+<!-- Section2: releasing -->
- <comment>
- Greg Leblanc: Depending on how big this FAQ gets, perhaps it
- would be worthwhile to have, say, the 5 most FAQ, and put the
- rest into an external FAQ. Dunno. Comments?
- </comment>
+ <sect2 id="releasing">
+ <title>Releasing Your Program</title>
- <emphasis>(rest deleted.)</emphasis>
- </para>
+ <para>
+ As mentioned earlier in the HOWTO, the first rule of releasing is,
+ <emphasis>release something useful.</emphasis> Non-working or
+ not-useful software will not attract anyone to your
+ project. People will be turned off of your project and be likely
+ to simply gloss over it next time they see a new version
+ announced. Half-working software, if useful, will intrigue people,
+ whet their appetites for versions to come, and encourage them to
+ join the development process.
+ </para>
- </sect1>
+ <sect3>
+ <title>When to release</title>
-<!-- Section1: faq: END -->
+ <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 room for imagination by your future
+ developers. It's not an easy decision. Ask for help on a local
+ Linux User Group mailing list or from a group of developer
+ friends.
+ </para>
+ <para>
+ One tactic is to first do an <quote>alpha</quote> or
+ <quote>beta</quote> release as described below in <xref
+ linkend="alphabeta">. However, most of the guidelines described
+ above still apply.
+ </para>
-<!-- Section1: bits-n-pieces -->
+ <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>
- <sect1 id="bits-n-pieces">
- <title>Bits and Pieces </title>
+ <para>
+ After you've released for the first time, knowing when to release
+ becomes less stressful, but just as difficult to gauge. I like
+ the criteria offered by Robert Krawitz in his article, <ulink
+ url="http://www.advogato.org/article/196.html"><quote>Free
+ Software Project Management</quote></ulink> for maintaining a
+ good release cycle. He recommends that you ask yourself,
+ <quote>does this release...</quote>
+ </para>
- <indexterm>
- <primary>disk!miscellaneous</primary>
- </indexterm>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>Contain sufficient new functionality or bug fixes to be
+ worth the effort.</para>
+ </listitem>
- <para>
- This is basically a section where I stuff all the bits I have not
- yet decided where should go, yet that I feel is worth knowing
- about. It is a kind of transient area.
- </para>
+ <listitem>
+ <para>Be spaced sufficiently far apart to allow the user time
+ to work with the latest release.</para>
+ </listitem>
- </sect1>
+ <listitem>
+ <para>Be sufficiently functional so that the user can get work
+ done (quality).</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ If the answer is yes to all of these questions, its probably time
+ for a release. If in doubt, remember that asking for advice can't
+ hurt.
+ </para>
+ </sect3>
-<!-- Section1: bits-n-pieces: END -->
+ <sect3>
+ <title>How to release</title>
+ <para>
+ If you've followed the guidelines described in this HOWTO up
+ until this point, the mechanics of doing a release are going to
+ be the easy part of releasing. If you have set up consistent
+ distribution locations and the other infrastructure described in
+ the preceding sections, releasing should be as simple as building
+ the package, checking it once over, and uploading it into the
+ appropriate place and then reflecting the release on your
+ website.
+ </para>
+ </sect3>
-<!-- Section1: examples -->
+ <sect3 id="alphabeta">
+ <title>Alpha, beta, and development releases</title>
- <sect1 id="examples">
- <title>Examples</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>
- <indexterm>
- <primary>(your index root)!examples</primary>
- </indexterm>
+ <para>
+ The observation is often made that many free software developers
+ seem to be confused about the release cycle. <ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink> suggests that you memorize
+ the phrase, <quote>Alpha is not Beta. Beta is not Release</quote>
+ and I'd agree that tis is a probably a good idea.
+ </para>
- <para>
- <emphasis>Example designs and sample configuration files and other
- relevant details is always handy</emphasis>
- </para>
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>alpha releases</term>
+ <listitem>
+ <para>Alpha software is feature-complete but sometimes only
+ partially functional.</para>
+
+ <para>Alpha releases are expected to be unstable, perhaps a
+ little unsafe, but definitely usable. Alpha versions should
+ have full functionality and limited testing. They can have
+ known bugs and kinks that have yet to be worked out. Before
+ releasing an alpha, be sure to keep in mind that
+ <emphasis>alpha releases are still releases</emphasis> and
+ people are not going to be expecting a nightly build from the
+ CVS source. An alpha should work and have minimal testing and
+ bug fixing already finished.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>beta releases</term>
+ <listitem>
+ <para>Beta software is feature-complete and functional, but is
+ in the testing cycle and still has a few bugs in it.</para>
+
+ <para>Beta releases are general expected to be usable and
+ slightly unstable, although definitely <emphasis>not
+ unsafe.</emphasis> Beta releases usually preclude a full
+ release by under a month. They can contain small known bugs
+ but no major ones. All major functionality should be fully
+ implemented although the exact mechanics can still be worked
+ out. Beta releases are great tool to whet the appetites of
+ potential users by giving them a very realistic view of where
+ your project is going in the very near future and can help
+ keep interest by giving people
+ <emphasis>something.</emphasis></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>development releases</term>
+ <listitem>
+ <para><quote>Development release</quote> is much more vague
+ term than <quote>alpha</quote> or <quote>beta</quote>. I
+ usually choose to reserve the term for discussion of a
+ development branch although there are other ways to use the
+ term. So many in fact, that I feel the term has been
+ cheapened. The popular window manager <ulink
+ url="http://www.enlightenment.org">Enlightenment</ulink> has
+ released <emphasis>nothing but</emphasis> development
+ releases. Most often, the term is used to describe releases
+ that are not even to alpha or beta stages though and if I were
+ to release a pre-alpha version of a piece of software in order
+ to keep interest in my project live, this is probably how I
+ would have to label it.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
- </sect1>
+ </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 to try 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 lists.
+ </para>
+
+ <para>
+ Visit the <ulink url="http://freshmeat.net">freshmeat.net
+ website</ulink> or their <ulink
+ url="http://freshmeat.net/add-project/">submit project
+ page</ulink> to post your project onto their site and into their
+ database. In addition to a large website, freshmeat provides a
+ daily newsletter that highlights all the days releases and
+ reaches a huge audience (I skim it every night for any
+ interesting new releases).
+ </para>
+ </sect3>
+ </sect2>
+</sect1>
+
+ <bibliography>
+
+ <bibliodiv>
+ <title>Printed Books</title>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Fogel</surname>
+ <firstname>Karl</firstname>
+ </author>
+
+ <title>Open Source Development with CVS</title>
+
+ <publisher>
+ <publishername>Coriolois Open Press</publishername>
+ </publisher>
+ <pubdate>1999</pubdate>
+
+ <isbn>1-57610-490-7</isbn>
+
+ <abstract>
+ <para>
+ Fogel's <quote>Guide to using CVS in the free software
+ world</quote> is much more than its subitle. In the publishers
+ own words: <quote><emphasis>Open Source Development with
+ CVS</emphasis> is one of the first books available that teaches
+ you development and implementation of Open Source
+ software.</quote> It includes the best reference and tutorial
+ to CVS I have ever seen. It is the book that was <emphasis>so
+ good</emphasis> that it prompted me to write this HOWTO because
+ I thought the information it helped distribute was so important
+ and useful. Please check it or by if you can and are seriously
+ interested in running a free software project.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry
+ <biblioset>
+ <author>
+ <surname>Lessig</surname>
+ <firstname>Lawrence</firstname>
+ </author>
+
+ <title>Code and Other Laws of Cyberspace</title>
+
+ <publisher>
+ <publishername>Basic Books</publishername>
+ </publisher>
+ <pubdate>2000</pubdate>
+
+ <isbn>0-465-03913-8</isbn>
+
+ <abstract>
+ <para>
+ While it only briefly talks about free software (and does it by
+ tiptoeing around the free software/open source issue with the
+ term <quote>open code</quote>), Lessig book is
+ brilliant. Written by a lawyer, it talks about how regulation
+ on the Internet is not done with law, but with the code itself
+ and how the nature of the code will determine future
+ freedoms. In addition to being a quick and enjoyable read, it
+ gives some cool history describes how we
+ <emphasis>need</emphasis> free software in a way more
+ powerfully than anything I've read (outside of <ulink
+ url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
+ <quote>Right to Read.</quote></ulink>
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Raymond</surname>
+ <firstname>Eric</firstname>
+ </author>
+
+ <title>The Cathedral and the Bazaar</title>
+ <subtitle>Musings on Linux and Open Source by an Accidental Revolutionary</subtitle>
+
+ <publisher>
+ <publishername>O'Reilly</publishername>
+ </publisher>
+ <pubdate>1999</pubdate>
+
+ <isbn>1-56592-724-9</isbn>
+ <abstract>
+ <para>
+ Although I have to honestly say that I am not the ESR fan that
+ I used to be, this book proved invaluable in getting me where I
+ am today. The essay that gives the book its title does a good
+ job sketching the free software process and does an an amazing
+ of job of making an argument for free software/open source
+ development as making better software. The rest of the book has
+ other articles, for the most part posted on his website, but
+ it's nice thing to own in hard copy and something every free
+ software/open source hacker should read.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ </bibliodiv>
+
+ <bibliodiv>
+ <title>Web-Accessable Resources</title>
+
+ <para>
+ This is a list of the resources pertaining to this HOWTO that I've
+ found most helpful in compiling this information. If you have
+ more, please don't hesitate to email me at
+ <email>mako@debian.org</email> and we can look into getting it
+ added on the list.
+ </para>
+
+ <para>
+ I'd recommend that any free software developer (or potential one)
+ skim through these sites becaue they have a lot to say.
+ </para>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Manley</surname>
+ <firstname>Montey</firstname>
+ </author>
+
+ <title><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink></title>
+
+ <publisher>
+ <publishername><ulink
+ url="http://www.linuxprogramming.com">Linux
+ Programming</ulink></publishername>
+ </publisher>
+ <pubdate>Oct 31, 2000</pubdate>
+
+ <abstract>
+ <para>
+ In one of the better articles on the subject that I've read,
+ Monty sums up some of the major points I touch on including:
+ starting a project, testing, documenation, orgazing a team and
+ leadership, and several other topics. While more opiniated that
+ I try to be, I think its an important article that I found very
+ helpful in writing this HOWTO and that I've tried to cite it in
+ the places where I borrowed from it most. I have problems with
+ much of the things written in the piece and I recommend you
+ read <xref linkend="krawitz"> at the same time you read Monty's
+ article.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Gabriel</surname>
+ <firstname>Richard</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
+ <quote>Worse is Better</quote></ulink></title>
+
+ <abstract>
+ <para>
+ A well written article although I think the title may have
+ confused as many people as it helped. It offers a good
+ description of how to design programs that will succeed and
+ stay maintainable as they grow.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ </bibliodiv>
+
+ <bibliodiv>
+ <title>Advogato Articles</title>
+
+ <para>
+ I've found that one of the best resources that any free software
+ developer has at his or her disposal is the advogato. If you
+ haven't yet had a chance to visit <ulink
+ url="http://www.advogato.org">the website</ulink>, do.
+ </para>
+
+ <para>
+ I have spent a lot of time on advogato and I've gone through and
+ provided links to the articles that I think are of particular
+ interest to anyone reading this HOWTO. I think that looking
+ through these is important. I promise that you'll learn a lot. You
+ will learn that my idea of how a free software project should be
+ run is not the <emphasis>only</emphasis> idea about how such a
+ project can be done. I think that's great.
+ </para>
+
+ <para>
+ If nothing else, there is <emphasis>way</emphasis> more
+ information on that website than I could ever fit into, or
+ reference from this HOWTO. I have listed what I think are the most
+ relavant articles here with short descriptions.
+ </para>
+
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Hindle</surname>
+ <firstname>Stephen</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/262.html">'Best Practices' for Open Source?</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>March 21, 2001</pubdate>
+
+ <abstract>
+ <para>
+ Touching mostly on programming practice (as most articles on
+ the subject usually do), the article talks a little about
+ project managment (<quote>Use it!</quote>) and a bit about
+ communication within a free software project.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Cohen</surname>
+ <firstname>Bram</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/258.html"></ulink>How to
+ Write Maintainable Code</title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>March 15, 2001</pubdate>
+
+ <abstract>
+ <para>
+ This article touches upon the "writing maintainable code"
+ discussion that I try hard to avoid in my discussion. It's one
+ of the better articles on the subject that I've found.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ <biblioentry id="krawitz">
+ <biblioset>
+ <author>
+ <surname>Krawitz</surname>
+ <firstname>Robert</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/196.html">Free
+ Source Project Management</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>November 4, 2000</pubdate>
+
+ <abstract>
+ <para>
+ This article made me happy because it challenged many of the
+ problems that I had with Monty's article on <ulink
+ url="http://www.linuxprogramming.com">LinuxProgramming</ulink>. The
+ author argues that Monty argues simply for the application of
+ old project management techniques to free software projects
+ instead of working with something new. I found his article to
+ be extremely well thought out and I think its an essential read
+ for any project manager.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Martins</surname>
+ <firstname>Lalo</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/128.html">Ask
+ the Advogatos: why do Free Software projects
+ fail?</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>July 20, 2000</pubdate>
+
+ <abstract>
+ <para>
+ While the article is little more than a question, reading the
+ answer to this question can help. In a lot of ways, this HOWTO
+ acts as my answer to the question posed in this article but
+ there are others, many of which might take issue with whats in
+ this HOWTO. It's worth checking out.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Burley</surname>
+ <firstname>David</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/107.html">In-Roads to Free
+ Software Development</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>June 14, 2000</pubdate>
+
+ <abstract>
+ <para>
+ This document was written as a response to <ulink
+ url="http://www.advogato.org/article/72.html">another advogato
+ article</ulink>. Although not about running a project, this
+ describes some of the ways that you can get started with free
+ software development. I think this is an important article. If
+ you are interested to become involved with free software, this
+ article showcases some of the ways that you can do this without
+ actually starting a project (something that I hope this HOWTO
+ has demonstrated is not to be taken lightly).
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Moorman</surname>
+ <firstname>Jacob</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/72.html"></ulink>Importance
+ of Non-Developer Supporters in Free Software</title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>April 16, 2000</pubdate>
+
+ <abstract>
+ <para>
+ Moorman's is a short article but it brings up some good
+ points. The comment reminding developers to thank their testers
+ and end-users is invaluable and oft-forgotten.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Orchard</surname>
+ <firstname>Leslie</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/67.html">On
+ Naming an Open Source Project</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>April 12, 2000</pubdate>
+
+ <abstract>
+ <para>
+ I didn't even have a section on naming in this HOWTO (See <xref
+ linkend="naming">) until Leslie Orchard's article reminded me
+ of it. Thanks to Leslie for writing this article!
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Allen</surname>
+ <firstname>David</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/40.html">Version Numbering Madness</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>Februrary 28, 2000</pubdate>
+
+ <abstract>
+ <para>
+ In this article, David Allen challengs the whole
+ <quote>Major.Minor.Patch</quote> versioning scheme. Its good to
+ read this as you read <xref linkend="chooseversioning">. I
+ liked the article and it describes some of the projects that I
+ bring up in my discussion of verion numbering.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
-<!-- Section1: examples: END -->
+ </bibliodiv>
+ </bibliography>
</article>
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
--->
+-->
\ No newline at end of file
projects / fspm_howto / blobdiff