-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">\r
-\r
-<article>\r
-\r
-<!-- Header -->\r
-\r
- <artheader>\r
- <title>Free Software Development HOWTO</title>\r
-\r
- <author>\r
- <firstname>Benjamin</firstname>\r
- <othername>Mako</othername>\r
- <surnamen>Hill</surname>\r
- <affiliation>\r
- <address>\r
- <email>mako@debian.org</email>\r
- </address>\r
- </affiliation>\r
- </author>\r
-\r
- <revhistory>\r
- <revision>\r
- <revnumber>v0.01</revnumber>\r
- <date>1 January 2001</date>\r
- <authorinitials>bch</authorinitials>\r
- <revremark>\r
- Initial Release\r
- </revremark>\r
- </revision>\r
- </revhistory>\r
-\r
- <abstract>\r
- <indexterm>\r
- <primary>fswd</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This HOWTO is designed for people with experience in programming\r
- and some skills in managing a software project but who are new to\r
- the world of Free Software. This document is meant to act as a\r
- guide to the non-technical aspects of programming and is meant as\r
- a crash course in the people skills that can make or break a free\r
- software project.\r
- </para>\r
- </abstract>\r
-\r
- </artheader>\r
-\r
-<!-- Section1: intro -->\r
-\r
- <sect1 id="intro">\r
- <title>Introduction</title>\r
-\r
- <indexterm>\r
- <primary>fswd!introduction</primary>\r
- </indexterm>\r
-\r
- <para>\r
- For various reasons this brand new release is codenamed the\r
- <emphasis>release</emphasis> release.\r
- </para>\r
-\r
- <para>\r
- New code names will appear as per industry standard\r
- guidelines to emphasize the state-of-the-art-ness of this\r
- document.\r
- </para>\r
-\r
- <para>\r
- This document was written when I read a feedback asking for a\r
- template to fill in to make new HOWTOs. This template was\r
- initially made by extracting the skeletal structure of the Multi\r
- Disk HOWTO which is a rather large HOWTO. It then went through\r
- extensive editing.\r
- </para>\r
-\r
- <para>\r
- Stating the background is a simple way to getting started\r
- writing the intro.\r
- </para>\r
-\r
- <para>\r
- First of all we need a bit of legalese. Recent development\r
- shows it is quite important.\r
- </para>\r
-\r
-<!-- Section2: copyright -->\r
-\r
- <sect2 id="copyright">\r
- <title>Copyright Information</title>\r
-\r
- <para>\r
- This document is copyrighted (c) 2000 Stein Gjoen and is\r
- distributed under the terms of the Linux Documentation Project\r
- (LDP) license, stated below. <emphasis>Replace with your name,\r
- or supply a new license, when you use this skeleton for a new\r
- HOWTO.</emphasis>\r
- </para>\r
-\r
- <para>\r
- Unless otherwise stated, Linux HOWTO documents are\r
- copyrighted by their respective authors. Linux HOWTO documents may\r
- be reproduced and distributed in whole or in part, in any medium\r
- physical or electronic, as long as this copyright notice is\r
- retained on all copies. Commercial redistribution is allowed and\r
- encouraged; however, the author would like to be notified of any\r
- such distributions.\r
- </para>\r
-\r
- <para>\r
- All translations, derivative works, or aggregate works\r
- incorporating any Linux HOWTO documents must be covered under this\r
- copyright notice. That is, you may not produce a derivative work\r
- from a HOWTO and impose additional restrictions on its\r
- distribution. Exceptions to these rules may be granted under\r
- certain conditions; please contact the Linux HOWTO coordinator at\r
- the address given below.\r
- </para>\r
-\r
- <para>\r
- In short, we wish to promote dissemination of this\r
- information through as many channels as possible. However, we do\r
- wish to retain copyright on the HOWTO documents, and would like to\r
- be notified of any plans to redistribute the HOWTOs.\r
- </para>\r
-\r
- <para>\r
- If you have any questions, please contact \r
- <email>linux-howto@metalab.unc.edu</email>\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: disclaimer -->\r
-\r
- <sect2 id="disclaimer">\r
- <title>Disclaimer</title>\r
-\r
- <para>\r
- No liability for the contents of this documents can be accepted.\r
- Use the concepts, examples and other content at your own risk.\r
- As this is a new edition of this document, there may be errors\r
- and inaccuracies, that may of course be damaging to your system.\r
- Proceed with caution, and although this is highly unlikely,\r
- the author(s) do not take any responsibility for that.\r
- </para>\r
-\r
- <para>\r
- All copyrights are held by their by their respective owners, unless\r
- specifically noted otherwise. Use of a term in this document\r
- should not be regarded as affecting the validity of any trademark\r
- or service mark.\r
- </para>\r
-\r
- <para>\r
- Naming of particular products or brands should not be seen \r
- as endorsements.\r
- </para>\r
-\r
- <para>\r
- You are strongly recommended to take a backup of your system \r
- before major installation and backups at regular intervals.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: newversions-->\r
-\r
- <sect2 id="newversions">\r
- <title>New Versions</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!news on</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This is where you make a summary of what is new. When a\r
- HOWTO exceeds 20 pages it takes more than a casual read to find\r
- the updates. This is where you help your readers with that,\r
- alerting them to specific and important updates to the document.\r
- </para>\r
-\r
- <para>\r
- This is the initial release.\r
- </para>\r
-\r
- <para>\r
- Tell people where the document home page is so the very\r
- newest release could be found in case of problems with the main\r
- <ulink url="http://www.linuxdoc.org/">Linux Documentation\r
- Project</ulink> homepage.\r
- </para>\r
-\r
- <para>\r
- The following is a sample from the Multi Disk HOWTO:\r
- </para>\r
-\r
- <para>\r
- The latest version number of this document can be \r
- gleaned from my plan entry if you \r
- <ulink url="http://www.cs.indiana.edu/finger/nox.nyx.net/sgjoen">\r
- finger</ulink> my Nyx account.\r
- </para>\r
-\r
- <para>\r
- <emphasis>If you have the capability, it would be nice to \r
- make the HOWTO available in a number of formats.</emphasis>\r
- </para>\r
-\r
- <para>\r
- The newest version of this HOWTO will always be made available on\r
- my website, in a variety of formats:\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.nyx.net/~sgjoen/disk.html">HTML</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink URL="http://www.nyx.net/~sgjoen/disk.txt">plain text</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.nyx.net/~sgjoen/disk-US.ps.gz">compressed \r
- postscript (US letter format)</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.nyx.net/~sgjoen/disk.sgml">SGML source</ulink>.\r
- </para>\r
- </listitem>\r
- </itemizedlist>\r
- </para>\r
-\r
- <para>\r
- Note that paper sizes vary in the world, A4 and US letter differ \r
- significantly. You might also wish to consider using the \r
- <emphasis>universal format</emphasis> (8.27x11in; 210x279mm). \r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: credits -->\r
-\r
- <sect2 id="credits">\r
- <title>Credits</title>\r
-\r
- <para>\r
- <emphasis>It is always nice to acknowledge people who help you\r
- with input; it is also regarded by many as important in the\r
- Linux world new economy.</emphasis>\r
- </para>\r
-\r
- <para>\r
- In this version I have the pleasure of acknowledging:\r
- </para>\r
-\r
- <para>\r
- <email>name (at) site.org</email>\r
- </para>\r
-\r
- <para>\r
- <emphasis>Please scramble the addresses so email harvesters\r
- cannot get addresses from your HOWTO and then spam people. That\r
- has happened in the past.</emphasis>\r
- </para>\r
-\r
- <para>\r
- <emphasis>Somecompany</emphasis> is acknowledged for sending me\r
- documentation on their gizmos as well as permission to quote from\r
- the material. These quotes have been approved before appearing\r
- here and will be clearly labeled.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: feedback -->\r
-\r
- <sect2 id="feedback">\r
- <title>Feedback</title>\r
-\r
- <para>\r
- Feedback is most certainly welcome for this document. Without\r
- your submissions and input, this document wouldn't exist. Please\r
- send your additions, comments and criticisms to the following\r
- email address : <email>sgjoen@nyx.net</email>.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: translations -->\r
-\r
- <sect2 id="translations">\r
- <title>Translations</title>\r
-\r
- <para>\r
- Not everyone speaks English, pointers to translations are nice.\r
- Also your translators tend to give very important inputs.\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://linuxdoc.org/">German Translation</ulink>\r
- by <email>someone (at) somewhere.de</email>\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://linuxdoc.org/">French Translation</ulink>\r
- by <email>someone (at) somewhere.fr</email>\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://linuxdoc.org/">Italian Translation</ulink>\r
- by <email>someone (at) somewhere.it</email>\r
- </para>\r
- </listitem>\r
- </itemizedlist>\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: intro: END -->\r
-\r
-<!-- Section1: starting -->\r
-\r
- <sect1 id="starting">\r
- <title>Starting a Project</title>\r
-\r
-<!-- Section2: chooseproject-->\r
-\r
- <sect2 id="chooseproject">\r
- <title>Choosing a Project</title>\r
- </sect2>\r
-\r
-<!-- Section2: chooselicense-->\r
-\r
- <sect2 id="chooselicense">\r
- <title>Deciding on a License</title>\r
- </sect2>\r
-\r
-<!-- Section2: chooseversioning-->\r
-\r
- <sect2 id="chooseversioning">\r
- <title>Choosing a Method of Version Numbering</title>\r
- </sect2>\r
-\r
-<!-- Section2: documentation-->\r
-\r
- <sect2 id="documentation">\r
- <title>Documentation</title>\r
- </sect2>\r
-\r
-<!-- Section2: presentation -->\r
-\r
- <sect2 id="presentation">\r
- <title>Other Presentation Issues</title>\r
- </sect2>\r
-\r
-<!-- Section2: futuredev -->\r
-\r
- <sect2 id="futuredev">\r
- <title>Nuturing Future Development</title>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: starting: END -->\r
-\r
-<!-- Section1: developers -->\r
-\r
- <sect1 id="developers">\r
- <title>Maintaining a Project: Interacting with Developers</title>\r
-\r
-<!-- Section2: delegation -->\r
-\r
- <sect2 id="delegation">\r
- <title>Delegating Work</title>\r
- </sect2>\r
-\r
-<!-- Section2: branches -->\r
-\r
- <sect2 id="branches">\r
- <title>Stable and Development Branches</title>\r
- </sect2>\r
-\r
-<!-- Section2: freezing -->\r
-\r
- <sect2 id="freezing">\r
- <title>Freezing</title>\r
- </sect2>\r
-\r
-<!-- Section2: codecram -->\r
-\r
- <sect2 id="codecram">\r
- <title>Avoiding the Code Cram Effect</title>\r
- </sect2>\r
-\r
-<!-- Section2: patching -->\r
-\r
- <sect2 id="patching">\r
- <title>Accepting and Rejecting Patches</title>\r
- </sect2>\r
- </sect1>\r
-\r
-<!-- Section1: users -->\r
-\r
- <sect1 id="users">\r
- <title>Maintaining a Project: Interacting with Users</title>\r
-\r
-<!-- Section2: announcing -->\r
-\r
- <sect2 id="announcing">\r
- <title>Announcing Your Project</title>\r
- </sect2>\r
-\r
-<!-- Section2: testing -->\r
-\r
- <sect2 id="testing">\r
- <title>Testing and Testers</title>\r
- </sect2>\r
-</sect1>\r
-\r
-<!-- Section1: samples -->\r
-\r
- <sect1 id="samples">\r
- <title>Samples</title>\r
-\r
- <para>\r
- <emphasis>This section gives some simple SGML examples you could\r
- use. Read the SGML source to see how it was done.</emphasis>\r
- </para>\r
-\r
- <para>\r
- Further information and examples can be obtained from the publication\r
- <ulink url="http://docbook.org/tdg/html/">DocBook: The Definitive \r
- Guide</ulink>. Written by <emphasis>Norman Walsh</emphasis>\r
- and <emphasis>Leonard Muellner</emphasis>; 1st Edition, October 1999.\r
- </para>\r
- \r
-<!-- Section2: lists -->\r
-\r
- <sect2 id="lists">\r
- <title>Lists</title>\r
-\r
- <para>\r
- <emphasis>Lists are used frequently, and are available in a number\r
- of formats shown below.</emphasis>\r
- </para>\r
-\r
- <para>\r
- A list in which each entry is marked with a bullet or other dingbat:\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>Apples</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Oranges</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Bananas</para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
-\r
- <para>\r
- A list in which each entry is composed of a set of one or more\r
- terms and an associated description:\r
- </para>\r
-\r
- <para>\r
- <variablelist>\r
-\r
- <varlistentry>\r
- <term>Fruits</term>\r
- <listitem>\r
- <para>such as apples, oranges, and more.</para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Nuts</term>\r
- <listitem>\r
- <para>Don't eat too many; you are what you eat.</para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Vegetables</term>\r
- <listitem>\r
- <para>Potatos are spelled with care.</para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- </variablelist>\r
- </para>\r
-\r
- <para>\r
- A list in which each entry is marked with a sequentially \r
- incremented label:\r
- </para>\r
-\r
- <para>\r
- <orderedlist>\r
-\r
- <listitem>\r
- <para>Step one</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Step two</para>\r
- </listitem>\r
-\r
- </orderedlist>\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: links -->\r
-\r
- <sect2 id="links">\r
- <title>Links</title>\r
-\r
- <para>\r
- <emphasis>Links can be used within your documents to refer to\r
- different sections and chapters or to refer to documents external\r
- to yours.</emphasis>\r
- </para>\r
-\r
- <sect3 id="int-links">\r
- <title>Internal links</title>\r
-\r
- <para>\r
- Click on the <xref LinkEnd="samples"> link to jump to the top of\r
- this chapter. Note the anchor at the section tag.\r
- </para>\r
- </sect3>\r
-\r
- <sect3 id="ext-links">\r
- <title>External links</title>\r
-\r
- <para>\r
- Click on <ulink url="http://www.linuxdoc.org/">this</ulink> link\r
- to jump to the LDP site. Note you can use http, ftp, news and\r
- other protocols in the locator if required.\r
- </para>\r
- </sect3>\r
-\r
- </sect2>\r
-\r
-<!-- Section2: images -->\r
-\r
- <sect2 id="images">\r
- <title>Images</title>\r
-\r
- <para>\r
- <emphasis>Avoid diagrams if possible as this cannot be rendered\r
- in the ASCII outputs which are still needed by many around the\r
- world.</emphasis>\r
- </para>\r
-\r
- <para>\r
- <figure>\r
- <title>Graphics Test Image</title>\r
- <graphic FileRef="red.gif"></graphic>\r
- </figure>\r
- </para>\r
-\r
- <para>\r
- Here is another variation which allows for ALT text:\r
- </para>\r
-\r
- <para>\r
- <mediaobject>\r
-\r
- <imageobject>\r
- <imagedata fileref="green.gif" format="gif">\r
- </imageobject>\r
-\r
- <textobject>\r
- <phrase>\r
- ALT text to be used: Green Ball\r
- </phrase>\r
- </textobject>\r
-\r
- <caption>\r
- <para>\r
- Caption for the graphic goes here: This is a Green Ball.\r
- </para>\r
- </caption>\r
- </mediaobject>\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: samples: END -->\r
-\r
-\r
-<!-- Section1: structure -->\r
-\r
- <sect1 id="structure">\r
- <title>Structure</title>\r
-\r
- <para>\r
- <emphasis>A quick overview on how all parts fit together in the overall\r
- structure. An example from the Multi Disk HOWTO is used.</emphasis>\r
- </para>\r
-\r
- <para>\r
- As this type of document is supposed to be as much for learning as\r
- a technical reference document I have rearranged the structure to\r
- this end. For the designer of a system it is more useful to have\r
- the information presented in terms of the goals of this exercise\r
- than from the point of view of the logical layer structure of the\r
- devices themselves. Nevertheless this document would not be\r
- complete without such a layer structure the computer field is so\r
- full of, so I will include it here as an introduction to how it\r
- works.\r
- </para>\r
-\r
-<!-- Section2: logical-struct -->\r
-\r
- <sect2 id="logical-struct">\r
- <title>Logical structure</title>\r
-\r
- <indexterm>\r
- <primary>disk!structure, I/O subsystem</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This is based on how each layer access each other, traditionally\r
- with the application on top and the physical layer on the bottom.\r
- It is quite useful to show the interrelationship between each of\r
- the layers used in controlling drives.\r
-\r
- <screen>\r
- ___________________________________________________________\r
- |__ File structure ( /usr /tmp etc) __|\r
- |__ File system (ext2fs, vfat etc) __|\r
- |__ Volume management (AFS) __|\r
- |__ RAID, concatenation (md) __|\r
- |__ Device driver (SCSI, IDE etc) __|\r
- |__ Controller (chip, card) __|\r
- |__ Connection (cable, network) __|\r
- |__ Drive (magnetic, optical etc) __|\r
- -----------------------------------------------------------\r
- </screen>\r
- </para>\r
-\r
- <para>\r
- In the above diagram both volume management and RAID and\r
- concatenation are optional layers. The 3 lower layers are in\r
- hardware. All parts are discussed at length later on in this\r
- document.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: doc-struct -->\r
-\r
- <sect2 id="doc-struct">\r
- <title>Document structure</title>\r
-\r
- <para>\r
- Most users start out with a given set of hardware and some plans\r
- on what they wish to achieve and how big the system should be.\r
- This is the point of view I will adopt in this document in\r
- presenting the material, starting out with hardware, continuing\r
- with design constraints before detailing the design strategy that\r
- I have found to work well. I have used this both for my own\r
- personal computer at home, a multi purpose server at work and\r
- found it worked quite well. In addition my Japanese co-worker in\r
- this project have applied the same strategy on a server in an\r
- academic setting with similar success.\r
- </para>\r
-\r
- <para>\r
- Finally at the end I have detailed some configuration tables for\r
- use in your own design. If you have any comments regarding this\r
- or notes from your own design work I would like to hear from you\r
- so this document can be upgraded.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: reading-plan -->\r
-\r
- <sect2 id="reading-plan">\r
- <title>Reading plan</title>\r
-\r
- <para>\r
- <emphasis>As you go beyond 50 pages or so there will be a lot of\r
- text that experts and even the experienced do not need to read.\r
- Keeping in mind that we wish to care for all kinds of people in\r
- the Linux world we might have to make a reading plan. Again,\r
- an example follows from the Multi Disk HOWTO.</emphasis>\r
- </para>\r
-\r
- <para>\r
- Although not the biggest HOWTO it is nevertheless rather big\r
- already and I have been requested to make a reading plan to make\r
- it possible to cut down on the volume.\r
- </para>\r
-\r
- <para>\r
- <variablelist>\r
-\r
- <varlistentry>\r
- <term>Expert</term>\r
- <listitem>\r
- <para>\r
- (aka the elite). If you are familiar with Linux as well as\r
- disk drive technologies you will find most of what you need in\r
- the appendices. Additionally you are recommended to read the\r
- FAQ and the <XRef LinkEnd="bits-n-pieces">chapter.\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Experienced</term>\r
- <listitem>\r
- <para>\r
- (aka Competent). If you are familiar with computers in\r
- general you can go straight to the chapters on \r
- <XRef LinkEnd="technologies"> and continue from there on.\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Newbie</term>\r
- <listitem>\r
- <para>\r
- (mostly harmless). You just have to read the whole thing.\r
- Sorry. In addition you are also recommended to read all the\r
- other disk related HOWTOs.\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- </variablelist>\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: structure: END -->\r
-\r
-\r
-<!-- Section1: technologies -->\r
-\r
- <sect1 id="technologies">\r
- <title>Technologies</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!technologies</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Introduction of technology for the newbie with a few\r
- references to detailed works. Remember that not everyone has\r
- Internet access so you have to explain in sufficient details so\r
- even the newbie can get by.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: technologies: END -->\r
-\r
-\r
-<!-- Section1: implement -->\r
-\r
- <sect1 id="implement">\r
- <title>Implementation</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!implementation</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Now your readers should have a sufficient knowledge of\r
- what this is about and now we come to the hands on of implementing\r
- your clever scheme.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: implement: END -->\r
-\r
-\r
-<!-- Section1: maint -->\r
-\r
- <sect1 id="maint">\r
- <title>Maintenance</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!maintenance</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Few systems and designs are maintenance free, here you\r
- explain how to keep the system running.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: maint: END -->\r
-\r
-\r
-<!-- Section1: adv-issues -->\r
-\r
- <sect1 id="adv-issues">\r
- <title>Advanced Issues</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!advanced topics</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>You can get most things up and running in a quick and\r
- dirty fashion, useful for testing and getting used to how things\r
- work. For more serious use you would need to be a little more\r
- advanced. This is the place to explain it all, if applicable.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: adv-issues: END -->\r
-\r
-\r
-<!-- Section1: moreinfo -->\r
-\r
- <sect1 id="moreinfo">\r
- <title>Further Information</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!information resources</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>A HOWTO cannot describe everything, some times the user\r
- has to venture out on th enet to get more information or just\r
- updates. Here is the place to tell where and how. Again examples\r
- from the Multi Disk HOWTO, replace as needed.</emphasis> There is wealth\r
- of information one should go through when setting up a major system,\r
- for instance for a news or general Internet service provider. The\r
- FAQs in the following groups are useful:\r
- </para>\r
-\r
-<!-- Section2: newsgroups -->\r
-\r
- <sect2 id="newsgroups">\r
- <title>News groups</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!news groups</primary>\r
- </indexterm>\r
-\r
- <para>Some of the most interesting news groups are:\r
-\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.arch.storage">Storage</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.sys.ibm.pc.hardware.storage">PC storage</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:alt.filesystems.afs">AFS</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.periphs.scsi">SCSI</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.os.linux.setup">Linux setup</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
-\r
- <para>\r
- Most newsgroups have their own FAQ that are designed to answer most\r
- of your questions, as the name Frequently Asked Questions indicate.\r
- Fresh versions should be posted regularly to the relevant newsgroups.\r
- If you cannot find it in your news spool you could go directly to the\r
- <ulink url="ftp://rtfm.mit.edu/">FAQ main archive FTP site</ulink>.\r
- The WWW versions can be browsed at the \r
- <ulink url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html">FAQ\r
- main archive WWW site</ulink>.\r
- </para>\r
-\r
- <para>\r
- Some FAQs have their own home site, of particular interest:\r
-\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.paranoia.com/~filipg/HTML/LINK/F_SCSI.html">SCSI FAQ</ulink> \r
- and\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://alumni.caltech.edu/~rdv/comp_arch_storage/FAQ-1.html">comp.arch.storage FAQ</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: maillists -->\r
-\r
- <sect2 id="maillists">\r
- <title>Mailing Lists</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!mailing lists</primary>\r
- </indexterm>\r
-\r
- <para>\r
- These are low-noise channels mainly for developers. Think twice\r
- before asking questions there as noise delays the development.\r
- Some relevant lists are <email>linux-raid</email>,\r
- <email>linux-scsi</email> and <email>linux-ext2fs</email>. Many\r
- of the most useful mailing lists run on the <Literal\r
- remap="tt">vger.rutgers.edu</Literal> server but this is\r
- notoriously overloaded, so try to find a mirror. There are some\r
- lists mirrored at <ulink url="http://www.redhat.com">The Redhat\r
- Home Page</ulink>. Many lists are also accessible at <ulink\r
- url="http://www.linuxhq.com/lnxlists">linuxhq</ulink>, and the\r
- rest of the web site contains useful information as well.\r
- </para>\r
-\r
- <para>\r
- If you want to find out more about the lists available you can send\r
- a message with the line <command>lists</command> to the list server\r
- at <email>majordomo@vger.rutgers.edu</email>.\r
- If you need help on how to use the mail server just send the line\r
- <command>help</command> to the same address. Due to the\r
- popularity of this server it is likely it takes a bit to time before\r
- you get a reply or even get messages after you send a\r
- <command>subscribe</command> command.\r
- </para>\r
-\r
- <para>\r
- There is also a number of other majordomo list servers that can\r
- be of interest such as the EATA driver list\r
- (<email>linux-eata@mail.uni-mainz.de</email>)\r
- and the Intelligent IO list <email>linux-i2o@dpt.com</email>.\r
- </para>\r
-\r
- <para>\r
- Mailing lists are in a state of flux but you can find links to a\r
- number of interesting lists from the \r
- <ulink url="http://www.linuxdoc.org/">Linux Documentation\r
- Homepage</ulink>.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: howto -->\r
-\r
- <sect2 id="howto">\r
- <title>HOWTO</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!HOWTOs</primary>\r
- </indexterm>\r
-\r
- <para>\r
- These are intended as the primary starting points to get the\r
- background information as well as show you how to solve a\r
- specific problem. Some relevant HOWTOs are\r
- <Literal remap="tt">Bootdisk</Literal>, \r
- <Literal remap="tt">Installation</Literal>,\r
- <Literal remap="tt">SCSI</Literal> and \r
- <Literal remap="tt">UMSDOS</Literal>. The main site for these is the\r
- <ulink url="http://www.linuxdoc.org/">LDP archive</ulink>at\r
- Metalab (formerly known as Sunsite).\r
- </para>\r
-\r
- <para>\r
- There is a a new HOWTO out that deals with setting up a DPT RAID\r
- system, check out the\r
- <ulink url="http://www.ram.org/computing/linux/dpt_raid.html">DPT RAID\r
- HOWTO homepage</ulink>.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: local-res -->\r
-\r
- <sect2 id="local-res">\r
- <title>Local Resources</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!local</primary>\r
- </indexterm>\r
-\r
- <para>\r
- In most distributions of Linux there is a document directory\r
- installed, have a look in the <filename>/usr/doc</filename>\r
- directory. where most packages store their main documentation and\r
- README files etc. Also you will here find the HOWTO archive \r
- (<filename>/usr/doc/HOWTO</filename>) of ready formatted HOWTOs\r
- and also the mini-HOWTO archive \r
- (<filename>/usr/doc/HOWTO/mini</filename>) of plain text\r
- documents.\r
- </para>\r
-\r
- <para>\r
- Many of the configuration files mentioned earlier can be found in\r
- the <filename>/etc</filename> directory. In particular you will\r
- want to work with the <filename>/etc/fstab</filename> file that\r
- sets up the mounting of partitions and possibly also\r
- <filename>/etc/raidtab</filename> file that is used for the\r
- <Literal remap="tt">md</Literal> system to set up RAID.\r
- </para>\r
-\r
- <para>\r
- The kernel source in <filename>/usr/src/linux</filename> is, of\r
- course, the ultimate documentation. In other words, <quote>use\r
- the source, Luke</quote>. It should also be pointed out that the\r
- kernel comes not only with source code which is even commented\r
- (well, partially at least) but also an informative\r
- <filename>/usr/src/linux/Documentation</filename>. If you are\r
- about to ask any questions about the kernel you should read this\r
- first, it will save you and many others a lot of time and\r
- possibly embarrassment.\r
- </para>\r
-\r
- <para>\r
- Also have a look in your system log file\r
- (<filename>/var/log/messages</filename>) to see what is going on\r
- and in particular how the booting went if too much scrolled off\r
- your screen. Using <command>tail -f /var/log/messages</command>\r
- in a separate window or screen will give you a continuous update\r
- of what is going on in your system.\r
- </para>\r
-\r
- <para>\r
- You can also take advantage of the <filename>/proc</filename>\r
- file system that is a window into the inner workings of your\r
- system. Use <command>cat</command> rather than\r
- <command>more</command> to view the files as they are reported as\r
- being zero length. Reports are that <command>less</command> works\r
- well here.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: web -->\r
-\r
- <sect2 id="web">\r
- <title>Web Sites</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!WWW</primary>\r
- </indexterm>\r
- <indexterm>\r
- <primary>disk!information resources!web pages</primary>\r
- </indexterm>\r
-\r
- <para>\r
- There are a huge number of informative web sites available. By\r
- their very nature they change quickly so do not be surprised\r
- if these links become quickly outdated.\r
- </para>\r
-\r
- <para>\r
- A good starting point is of course the \r
- <ulink url="http://www.linuxdoc.org/">Linux Documentation\r
- Project</ulink> home page, an information central for\r
- documentation, project pages and much more.\r
- </para>\r
-\r
- <para>\r
- Please let me know if you have any other leads that can be \r
- of interest.\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: moreinfo: END -->\r
-\r
-\r
-<!-- Section1: help -->\r
-\r
- <sect1 id="help">\r
- <title>Getting Help</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!assistance, obtaining</primary>\r
- </indexterm>\r
-\r
- <para>\r
- In the end you might find yourself unable to solve your problems\r
- and need help from someone else. The most efficient way is either\r
- to ask someone local or in your nearest Linux user group, search\r
- the web for the nearest one.\r
- </para>\r
-\r
- <para>\r
- Another possibility is to ask on Usenet News in one of the many,\r
- many newsgroups available. The problem is that these have such a\r
- high volume and noise (called low signal-to-noise ratio) that your\r
- question can easily fall through unanswered.\r
- </para>\r
-\r
- <para>\r
- No matter where you ask it is important to ask well or you will\r
- not be taken seriously. Saying just <emphasis remap="it">my disk\r
- does not work</emphasis> is not going to help you and instead the\r
- noise level is increased even further and if you are lucky someone\r
- will ask you to clarify.\r
- </para>\r
-\r
- <para>\r
- Instead describe your problems in some detail that will enable\r
- people to help you. The problem could lie somewhere you did not\r
- expect. Therefore you are advised to list the following information\r
- about your system:\r
- </para>\r
-\r
- <para>\r
- <variablelist>\r
-\r
- <varlistentry>\r
- <term>Hardware</Term>\r
- <listitem>\r
- <para>\r
- <itemizedlist>\r
- <listitem>\r
- <para>Processor</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>DMA</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>IRQ</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Chip set (LX, BX etc)</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Bus (ISA, VESA, PCI etc)</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Expansion cards used (Disk controllers, video, IO \r
- etc.)\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Software</term>\r
- <listitem>\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>BIOS (On motherboard and possibly SCSI host adapters)</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>LILO, if used</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Linux kernel version as well as possible modifications \r
- and patches\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Kernel parameters, if any</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Software that shows the error (with version number \r
- or date)\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
-\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Peripherals</term>\r
- <listitem>\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- Type of disk drives with manufacturer name, version and type\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Other relevant peripherals</para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- </variablelist>\r
- </para>\r
-\r
- <para>\r
- Remember that booting text is logged to\r
- <filename>/var/log/messages</filename> which can answer most of\r
- the questions above. Obviously if the drives fail you might not be\r
- able to get the log saved to disk but you can at least scroll\r
- back up the screen using the <keycap>SHIFT</keycap> and\r
- <keycap>PAGE UP</keycap> keys. It may also be useful to include\r
- part of this in your request for help but do not go overboard,\r
- keep it <emphasis>brief</emphasis> as a complete log file dumped\r
- to Usenet News is more than a little annoying.\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: help: END -->\r
-\r
-\r
-<!-- Section1: remarks -->\r
-\r
- <sect1 id="remarks">\r
- <title>Concluding Remarks</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!conclusion</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Just summing up... Also a place for general\r
- recommendations.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: remarks: END -->\r
-\r
-\r
-<!-- Section1: faq -->\r
-\r
- <sect1 id="faq">\r
- <title>Questions and Answers</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!FAQ</primary>\r
- </indexterm>\r
- <indexterm>\r
- <primary>(your index root)!frequently asked questions</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Check the newsgroups and try to determine some frequent\r
- problems and cover them here. Again an example from the Multi Disk\r
- HOWTO.</emphasis>\r
- </para>\r
-\r
- <para>\r
- This is just a collection of what I believe are the most common\r
- questions people might have. Give me more feedback and I will turn\r
- this section into a proper FAQ.\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
- <listitem>\r
- <para>\r
- Q:How many physical disk drives (spindles) does a Linux system need?\r
- </para>\r
-\r
- <para>\r
- A: Linux can run just fine on one drive (spindle). Having\r
- enough RAM (around 32 MB, and up to 64 MB) to support swapping\r
- is a better price/performance choice than getting a second\r
- disk. (E)IDE disk is usually cheaper (but a little slower) than\r
- SCSI.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Q: Are there any disadvantages in this scheme?\r
- </para>\r
-\r
- <para>\r
- A: There is only a minor snag: if even a single partition\r
- overflows the system might stop working properly. The severity\r
- depends of course on what partition is affected. Still this is\r
- not hard to monitor, the command <command>df</command> gives\r
- you a good overview of the situation. Also check the swap\r
- partition(s) using <command>free</command> to make sure you are\r
- not about to run out of virtual memory.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Q: OK, so should I split the system into as many partitions as \r
- possible for a single drive?\r
- </para>\r
-\r
- <para>\r
- A: No, there are several disadvantages to that. First of all\r
- maintenance becomes needlessly complex and you gain very little\r
- in this. In fact if your partitions are too big you will seek\r
- across larger areas than needed. This is a balance and\r
- dependent on the number of physical drives you have.\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
-\r
- <comment>\r
- Greg Leblanc: Depending on how big this FAQ gets, perhaps it\r
- would be worthwhile to have, say, the 5 most FAQ, and put the\r
- rest into an external FAQ. Dunno. Comments?\r
- </comment>\r
-\r
- <emphasis>(rest deleted.)</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: faq: END -->\r
-\r
-\r
-<!-- Section1: bits-n-pieces -->\r
-\r
- <sect1 id="bits-n-pieces">\r
- <title>Bits and Pieces </title>\r
-\r
- <indexterm>\r
- <primary>disk!miscellaneous</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This is basically a section where I stuff all the bits I have not\r
- yet decided where should go, yet that I feel is worth knowing\r
- about. It is a kind of transient area.\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: bits-n-pieces: END -->\r
-\r
-\r
-<!-- Section1: examples -->\r
-\r
- <sect1 id="examples">\r
- <title>Examples</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!examples</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Example designs and sample configuration files and other\r
- relevant details is always handy</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: examples: END -->\r
-\r
-</article>\r
-\r
-<!-- Keep this comment at the end of the file\r
-Local variables:\r
-mode: sgml\r
-sgml-omittag:t\r
-sgml-shorttag:t\r
-sgml-namecase-general:t\r
-sgml-general-insert-case:lower\r
-sgml-minimize-attributes:nil\r
-sgml-always-quote-attributes:t\r
-sgml-indent-step:1\r
-sgml-indent-data:nil\r
-sgml-parent-document:nil\r
-sgml-exposed-tags:nil\r
-sgml-local-catalogs:nil\r
-sgml-local-ecat-files:nil\r
-End:\r
--->\r
+
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
+
+<article>
+
+<!-- Header -->
+
+ <artheader>
+ <title>Free Software Project Management HOWTO</title>
+
+ <author>
+ <firstname>Benjamin</firstname>
+ <othername>Mako</othername>
+ <surname>Hill</surname>
+ <affiliation>
+ <address>
+ <email>mako@atdot.cc</email>
+ </address>
+ </affiliation>
+ </author>
+
+ <revhistory>
+ <revision>
+ <revnumber>v0.3.3</revnumber>
+ <date>22 August 2008</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+ <revision>
+
+ <revnumber>v0.3.2</revnumber>
+ <date>15 April 2002</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+
+ <revision>
+ <revnumber>v0.3.1</revnumber>
+ <date>18 June 2001</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+
+ <revision>
+ <revnumber>v0.3</revnumber>
+ <date>5 May 2001</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+
+ <revision>
+ <revnumber>v0.2.1</revnumber>
+ <date>10 April 2001</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+
+ <revision>
+ <revnumber>v0.2</revnumber>
+ <date>8 April 2001</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+
+ <revision>
+ <revnumber>v0.01</revnumber>
+ <date>27 March 2001</date>
+ <authorinitials>bmh</authorinitials>
+ <revremark>Initial Release</revremark>
+ </revision>
+ </revhistory>
+
+ <abstract>
+ <indexterm>
+ <primary>fswd</primary>
+ </indexterm>
+
+ <para>
+ This HOWTO is designed for people with experience in programming
+ and some skills in managing a software project but who are new to
+ the world of free software. This document is meant to act as a
+ guide to the non-technical aspects of free software project
+ management and was written to be 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>
+ Skimming through freshmeat.net provides mountains of reasons for this
+ HOWTO's existence--the Internet is littered with excellently
+ written and useful programs that have faded away into the universe
+ of free software forgottenness. This dismal scene made me ask
+ myself, "Why?"
+ </para>
+
+ <para>
+ This HOWTO tries to do a lot of things (probably too many), but it
+ can't answer that question and won't attempt it. What this HOWTO
+ will attempt to do is give your Free Software project a fighting
+ chance--an edge. If you write a piece of crap that no one is
+ interested in, you can read this HOWTO until you can recite it in
+ your sleep and your project will probably fail. Then again, you can
+ write a beautiful, relevant piece of software and follow every
+ instruction in this HOWTO and your software may still not make
+ it. Sometimes life is like that. However, I'll go out a limb and
+ say that if you write a great, relevant pieces of software and
+ ignore the advise in this HOWTO, you'll probably fail <emphasis>
+ more often</emphasis>.
+ </para>
+
+ <para>
+ A lot of the information in this HOWTO is best called common
+ sense. Of course, as any debate on interfaces will prove, what is
+ common sense to some programmers proves totally unintuitive to
+ others. After explaining bits and pieces of this HOWTO to Free
+ Software developers on several occasions, I realized that writing
+ this HOWTO might provide a useful resource and a forum for
+ programmers to share ideas about what has and has not worked for
+ them.
+ </para>
+
+ <para>
+ As anyone involved in any of what seems like an unending parade of
+ ridiculous intellectual property clashes will attest to, a little
+ bit of legalese proves important.
+ </para>
+
+<!-- Section2: copyright -->
+
+ <sect2 id="copyright">
+ <title>Copyright Information</title>
+
+ <para>
+ This document is copyrighted (c) 2000-2008 Benjamin Mako Hill and is
+ distributed under the terms of the <citetitle>GNU Free
+ Documentation License</citetitle>.
+ </para>
+
+ <para>
+ Permission is granted to copy, distribute and/or modify this
+ document under the terms of the <link
+ linkend="fdl"><citetitle>GNU Free Documentation
+ License</citetitle></link>, Version 1.2 or any later version
+ published by the Free Software Foundation with no Invariant
+ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
+ of the license can be found in <xref linkend="fdl">.
+ </para>
+ </sect2>
+
+<!-- Section2: disclaimer -->
+
+ <sect2 id="disclaimer">
+ <title>Disclaimer</title>
+
+ <para>
+ No liability for the contents of this documents can be accepted.
+ Use the concepts, examples and other content at your own risk. As
+ this is a new edition of this document, there may be errors and
+ inaccuracies, that may of course be damaging to your project (and
+ potentially your system). Proceed with caution, and although this
+ is highly unlikely, the author(s) does not take any responsibility
+ for that.
+ </para>
+
+ <para>
+ All copyrights are held by their by their respective owners, unless
+ specifically noted otherwise. Use of a term in this document
+ should not be regarded as affecting the validity of any trademark
+ or service mark.
+ </para>
+
+ <para>
+ Naming of particular products or brands should not be seen
+ as endorsements.
+ </para>
+
+ </sect2>
+
+<!-- Section2: newversions-->
+
+ <sect2 id="newversions">
+ <title>New Versions</title>
+
+ <para>
+ This version is the part of the third pre-release cycle of this
+ HOWTO. It is written to be released to developers for critique and
+ brainstorming. While the HOWTO is now several years old, please keep
+ in mind that this version of the HOWTO is still in an "early" stage
+ and will continue to be revised extensively.
+ </para>
+
+ <para>
+ The latest version number of this document should always be listed
+ on <ulink url="http://mako.cc/projects/howto">the projects
+ homepage</ulink>.
+ </para>
+
+ <para>
+ The newest version of this HOWTO will always be made available at
+ the same website, in a variety of formats:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO/t1.html">HTML</ulink>.
+ </para>
+ </listitem>
+
+
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink URL="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect2>
+
+<!-- Section2: credits -->
+
+ <sect2 id="credits">
+ <title>Credits</title>
+
+ <para>
+ In this version I have the pleasure of acknowledging:
+ </para>
+
+ <para>Fellow Debian developers Martin Michlmayr and Vivek
+ Venugopalan who sent me information and links to extremely
+ interesting articles. I've added both to the bibliography and I've
+ added information from each into the HOWTO. Thanks to Andrew Shugg
+ who pointed out several errors in the document. Also, a big thanks
+ to Sung Wook Her (AKA RedBaron) who is doing the first translation
+ of the HOWTO into Korean. I've been happy to see that people have
+ enjoyed and benefited from the HOWTO so far.</para>
+
+ <para>
+ Older thanks that I don't want to take out yet include: Josh
+ Crawford, Andy King, and Jaime Davila who all read through this in
+ entirety and gave me feedback that has helped me make changes and
+ improvements to this document. I can't thank you guys enough for
+ your help. An extra <quote>Thank You</quote> goes to Andy King who
+ who read through this several times and submitted patches to make
+ life easier for me.
+ </para>
+
+ <para>
+ Karl Fogel, the author of <citetitle>Open Source Development with
+ CVS</citetitle> published by the Coriolis 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've ever seen. The rest of the book covers,
+ <quote>the challenges and philosophical issues inherent in running
+ an Open Source project using CVS.</quote> 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. If you are seriously
+ interested in running a Free Software project, you want this
+ book. I tried to mention Fogel in sections of this HOWTO where I
+ knew I was borrowing directly from his ideas. If I missed any, I'm
+ sorry. I'll try and have those fixed in future versions.
+ </para>
+
+ <para>
+ Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
+ com</email>
+ </para>
+
+ <para>
+ Also providing support material, and inspiration for this HOWTO is
+ Eric S. Raymond for his prolific, consistent, and carefully
+ crafted arguments and Lawrence Lessig for reminding me of the
+ importance of Free Software. Additionally, 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 who have been involved with the movement much longer than I,
+ and proof of a free software project that definitely, definitely
+ works.
+ </para>
+
+ <para>
+ Above all, I want to thank <emphasis>Richard Stallman</emphasis>
+ for his work at the Free Software Foundation and for never giving
+ up. Stallman provides and articulates the philosophical basis that
+ attracts me to free software and that drives me toward writing a
+ document to make sure it succeeds. RMS can always be emailed at
+ <email>rms (at) gnu (dot) org</email>.
+ </para>
+
+ </sect2>
+
+<!-- Section2: feedback -->
+
+ <sect2 id="feedback">
+ <title>Feedback</title>
+
+ <para>
+ Feedback is 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 its
+ ability to do this. Please send your additions, comments, and
+ criticisms to the following email address:
+ <email>mako@atdot.cc</email>.
+ </para>
+ </sect2>
+
+<!-- Section2: translations -->
+
+ <sect2 id="translations">
+ <title>Translations</title>
+
+ <para>
+ I know that not everyone speaks English. Translations are nice and
+ I'd love for this HOWTO to gain the kind of international reach
+ afforded by translated versions.
+ </para>
+
+ <para>
+ This HOWTO has graciously translated into German by Robert F.
+ Schmitt. That copy is accessible in the following formats:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.DE.html">HTML (single page)</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.DE.rstl">Restructured Text Source</ulink>.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ 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@atdot.cc</email>.
+ </para>
+ </sect2>
+ </sect1>
+
+<!-- Section1: intro: END -->
+
+<!-- Section1: starting -->
+
+ <sect1 id="starting">
+ <title>Starting a Project</title>
+
+ <indexterm>
+ <primary>fswd!starting</primary>
+ </indexterm>
+ <para>
+ With very little argument, the beginning is the most difficult
+ period in a project's life to do successful free software project
+ management. 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, while the development process that
+ you want to employ holds involvement of users as imperative.
+ </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 toward 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>
+
+ <para>
+ If you are reading this document, there's a good chance you
+ already have an idea for a project in mind. Chances are also
+ pretty good that it fills a perceived gap by doing something that
+ no other free software project does or by doing something in a way
+ that is unique enough to necessitate a brand new piece of
+ software.
+ </para>
+
+ <sect3 id=identifyidea>
+ <title>Identify and articulate your idea</title>
+ <para>
+ Eric S. Raymond writes about how free software projects start in
+ his essay, <ulink
+ url="http://catb.org/~esr/writings/cathedral-bazaar/"><quote>The
+ Cathedral and the Bazaar,</quote></ulink> which comes as required
+ reading for any free software developer. It is available online .
+ </para>
+
+ <para>
+ In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
+ that: <quote>every good work of software starts by scratching
+ a developers itch.</quote> 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>
+
+ <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. <emphasis>This idea is the project.</emphasis>
+ 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 clearly early on. Find out exactly what it is that you
+ want your project to do.
+ </para>
+
+ <para>
+ Monty Manley articulates the importance of this initial step in
+ an essay, <quote><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way.</ulink></quote> As the next section
+ will show, there is <emphasis>a lot</emphasis> of work that needs
+ to be done before software is even ready to be coded. Manley
+ says, <quote>Beginning an OSS project properly means that a
+ developer must, first and foremost, avoid writing code too
+ soon!</quote>
+ </para>
+ </sect3>
+
+ <sect3 id=evalulateidea>
+ <title>Evaluate your idea</title>
+
+ <para>
+ In evaluating your idea, you need to first ask yourself a few
+ questions. This should happen before you move any further
+ through this HOWTO. Ask yourself: <emphasis>Is the free software
+ development model really the right one for your
+ project?</emphasis>
+ </para>
+
+ <para>
+ 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 a second
+ question: <emphasis>Is anybody else interested?</emphasis>
+ </para>
+
+ <para>
+ Sometimes the answer is a simple <quote>no.</quote> If you want
+ to write a set of scripts to sort <emphasis>your</emphasis>
+ <acronym>MP3</acronym> collection on <emphasis>your</emphasis>
+ machine, <emphasis>maybe</emphasis> the free software development
+ model is not the best one to choose. However, if you want to
+ write a set of scripts to sort <emphasis>anyone's</emphasis>
+ <acronym>MP3</acronym>s, a free software project might fill a
+ useful gap.
+ </para>
+
+ <para>
+ Luckily, the Internet is a place so big and so diverse that,
+ chances are, there is someone, somewhere, who shares your
+ interests and who 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 third major question: <emphasis>Has
+ somebody already had your idea or a reasonably similar
+ one?</emphasis>
+ </para>
+
+ <sect4 id=evalwhere>
+ <title>Finding Similar Projects</title>
+
+ <para>
+ There are places you can go on the web to try and answer the
+ question above. If you have experience with the free software
+ community, you are probably already familiar with many of these
+ sites. All of the resources listed below 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 at all.</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 news and events. It is
+ not unusual for a particularly sexy development effort to be
+ announced here, so it is 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 a 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
+ release</ulink> pages should be necessary stops before
+ embarking on a new free software project. SourceForge also
+ provides a <ulink
+ url="http://sourceforge.net/snippet/">Code Snippet
+ Library</ulink> which contains useful reusable chunks of code
+ in an array of languages which can come in useful in any
+ project.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Google and Google's Linux Search</term>
+ <listitem>
+ <para><ulink url="http://www.google.com">Google</ulink> and
+ <ulink url="http://www.google.com/linux"> Google's Linux
+ Search</ulink>, provides 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 to make sure you aren't pouring your effort into a
+ redundant project.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </para>
+ </sect4>
+
+ <sect4 id=evalhow>
+ <title>Deciding to Proceed</title>
+ <para>
+ Once you have successfully charted the terrain and have an idea
+ about 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 at all similar 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>
+
+ <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>
+
+ <para>
+ For many developers this may be the single most difficult aspect
+ of free software project management, but it is an essential one. It is
+ easy to become fired up by an idea and get 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 remembers that the best interests of the free software
+ community and the quickest way to accomplish your own project's
+ goals and the goals of similar projects can often be
+ accomplished by <emphasis>not</emphasis> starting a new
+ development effort.
+ </para>
+
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: naming-->
+
+ <sect2 id="naming">
+ <title>Naming your project</title>
+
+ <para>
+ While there are plenty of projects that fail with descriptive
+ names and plenty that succeed without them, I think naming your
+ project is worth giving a bit of thought. Leslie Orchard tackles
+ this issue in an <ulink
+ url="http://www.advogato.org/article/67.html">Advogato
+ article</ulink>. His article is short and definitely worth looking
+ over quickly.
+ </para>
+
+ <para>
+ The synopsis is that Orchard recommends you pick a name where,
+ after hearing the name, many users or developers will both:
+ </para>
+
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>Know what the project does.</para>
+ </listitem>
+ <listitem>
+ <para>Remember it tomorrow.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Humorously, Orchard's project, <quote>Iajitsu,</quote> does
+ neither. It is probably unrelated that development has effectively
+ frozen since the article was written.
+ </para>
+
+ <para>
+ He makes a good point though. There are companies whose only job
+ is to make names for pieces of software. They make
+ <emphasis>ridiculous</emphasis> amount of money doing it and are
+ supposedly worth it. While you probably can't afford a company like
+ this, you can afford to learn from their existence and think a
+ little bit about the name you are giving your project because it
+ <emphasis>does</emphasis> matter.
+ </para>
+
+ <para>
+ If there is a name you really want but it doesn't fit Orchard's
+ criteria, you can still go ahead. I thought <quote>gnubile</quote>
+ was one of the best I'd heard for a free software project ever and
+ I still talk about it long after I've stopped using the
+ program. However, if you can be flexible on the subject, listen to
+ Orchard's advice. It might help you.
+ </para>
+ </sect2>
+
+<!-- Section2: licensing-->
+
+ <sect2 id="licensing">
+ <title>Licensing your Software</title>
+
+ <para>
+ 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>
+
+ <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 over the terms <quote>Open Source Software</quote> and
+ <quote>Free Software</quote>. However, because I've written the
+ Free Software Project Management HOWTO and not the Open Source
+ Software Project Management HOWTO, my own allegiances in this
+ argument are in the open.
+ </para>
+
+ <para>
+ In attempting to reach a middle ground through diplomacy without
+ sacrificing my own philosophy, I will 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> forms the first
+ version of the <ulink
+ url="http://www.opensource.org/docs/definition_plain.html">Open
+ Source Definition.</ulink> Examples of free licenses given by the
+ <acronym>DFSG</acronym> are the <acronym>GPL</acronym>, the
+ <acronym>BSD</acronym>, and the Artistic License. As ESR mentions
+ in his his HOWTO<xref linkend="esrhowto">, don't write your own
+ license if at all possible. The three licenses I mention all have
+ long interpretive traditions. They are also definitely free
+ software (and can therefore be distributed as part of Debian and
+ in other places that permit the transfer of free software).
+ </para>
+
+ <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 well-known license will offer the
+ advantage of immediate recognition and understanding.</para>
+
+ <para>
+ In attempting a more in-depth analysis, I agree with Karl Fogel's
+ description of licenses as falling into two groups: those that
+ are the <acronym>GPL</acronym> and those that are not the
+ <acronym>GPL</acronym>.
+ </para>
+
+ <para>
+ Personally, I license all my software under the
+ <acronym>GPL</acronym>. Created and protected by the Free
+ Software Foundation and the GNU Project, the
+ <acronym>GPL</acronym> is the license for the Linux kernel,
+ GNOME, Emacs, and the vast majority of GNU/Linux software. It's
+ the obvious choice but I also 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>
+
+ <para>
+ Many people write three or four sentences in a COPYING file and
+ assume that they have written a free software license--as my long
+ experience with the debian-legal mailing professes, this is very
+ often not the case. It may not protect you, it may not protect
+ your software, and it may make things very difficult for people
+ that want to use your software but who pay a lot of attention to
+ the subtle legal points of licenses. If you are passionate about
+ a home-brewed license, run it by either people at <ulink
+ url="http://www.opensource.org">OSI</ulink> or the <ulink
+ url="mailto:debian-devel@lists.debian.org">debian-legal mailing
+ list</ulink> first protect yourself from unanticipated
+ side-effects of your license.
+ </para>
+
+ <para>
+ The three major licenses can be found at the following locations:
+ </para>
+
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para><ulink url="http://www.gnu.org/copyleft/gpl.html">The GNU
+ General Public License</ulink></para>
+ </listitem>
+ <listitem>
+ <para><ulink url="http://www.debian.org/misc/bsd.license">The
+ BSD License</ulink></para>
+ </listitem>
+ <listitem>
+ <para><ulink
+ url="http://language.perl.com/misc/Artistic.html">The Artistic
+ License</ulink></para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ <emphasis>In any case, please read through any license before
+ your release your software under it. As the primary developer,
+ you can't afford any license surprises.</emphasis>
+ </para>
+ </sect3>
+
+ <sect3 id="licensechoose">
+ <title>The mechanics of licensing</title>
+
+ <para>
+ The text of the <acronym>GPL</acronym> offers <ulink
+ url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
+ description of the mechanics of applying a license</ulink> to a
+ piece of software. My quick checklist for applying a license
+ includes:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>Make yourself or the FSF the copyright holder for the
+ work. In a few rare cases, you might want to make a sponsoring
+ organization (if it's big and powerful enough) the copyright
+ holder instead. Doing this is as simple as putting the name in
+ the blank when you modify the notice of copyright
+ below. Contrary to popular belief, you don't need to file with
+ any organization. The notice alone is enough to copyright your
+ work.</para>
+ </listitem>
+
+ <listitem>
+ <para>If at all possible, attach and distribute a full copy of
+ the license with the source and binary by including a separate
+ file.</para>
+ </listitem>
+
+ <listitem>
+ <para>At the top of each source file in your program, attach a
+ notice of copyright and include information on where the full
+ license can be found. The <acronym>GPL</acronym> recommends
+ that each file begin with:</para>
+
+ <screen>
+<emphasis>one line to give the program's name and an idea of what it does.</emphasis>
+Copyright (C) yyyy name of author
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ </screen>
+
+ <para>
+ The <acronym>GPL</acronym> goes on to recommend attaching
+ information on methods for contacting you (the author) via
+ email or physical mail.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <acronym>GPL</acronym> continues and suggests that if your
+ program runs in an interactive mode, you should write the
+ program to output a notice each time it enters interactive
+ mode that includes a message like this one that points to full
+ information about the programs license:
+ </para>
+
+ <screen>
+Gnomovision version 69, Copyright (C) year name of author
+Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
+type `show w'. This is free software, and you are welcome
+to redistribute it under certain conditions; type `show c'
+for details.
+ </screen>
+ </listitem>
+
+ <listitem>
+ <para>Finally, it might be helpful to include a
+ <quote>copyright disclaimer</quote> 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. These aren't often needed but
+ there are plenty of free software developers who have gotten
+ into trouble and wish they'd asked for one.</para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </sect3>
+
+ <sect3 id="licensewarning">
+ <title>Final license warning</title>
+
+ <para>
+ Please, please, please, place your software under
+ <emphasis>some</emphasis> 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 your software has no license, it
+ 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>
+
+ </sect3>
+
+ </sect2>
+
+<!-- Section2: chooseversioning-->
+
+ <sect2 id="chooseversioning">
+ <title>Choosing a Method of Version Numbering</title>
+
+ <para>
+ <emphasis>The most important thing about a system of 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>
+ <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>
+
+ <para>
+ Follow these two simple rules and you will not go (too)
+ wrong. 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 the name 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
+ coherent structure. The third number is the patch number and it
+ usually will only refer to releases fixing bugs.
+ </para>
+
+ <para>
+ 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 knowing
+ anything about any of the releases.
+ </para>
+
+ <para>
+ You can bend or break these rules, and people do. But beware, if
+ you choose to, someone will get annoyed, assume you don't know,
+ and try and educate you, probably not nicely. I always follow this
+ method and I implore you to do so as well.
+ </para>
+
+ <para>
+ 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>
+
+ <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>
+
+ <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, <emphasis>all</emphasis> minor
+ versions are stable distributions (2.0, 2.1, etc). However,
+ many people assume that 2.1 is an unstable or development
+ version and continue to use an older version until they get so
+ frustrated with the lack of development progress 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 an idea worth taking into
+ consideration.
+ </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 toward
+ any immediately achievable goal, wine is released every three
+ weeks. Wine does this by labeling their releases in <quote>Year
+ Month Day</quote> 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, <quote>Year Month Day</quote> format can make a lot of
+ sense.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Mozilla milestones:</term>
+ <listitem>
+ <para>When one considers Netscape 6 and vendor versions, the
+ mozilla's project development structure is one of the most
+ complex free software models available. The project's version
+ numbering has reflected the unique situation in which it is
+ developed.
+ </para>
+
+ <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, although
+ Mozilla was built and distributed nightly as <quote>nightly
+ builds,</quote> on a day when the goals of a milestone on the
+ road-map had been reached, that particular build was marked as
+ a <quote>milestone release.</quote>
+ </para>
+
+ <para>
+ While I haven't seen this method employed in any other projects
+ to date, I like the idea and think that it might have value in
+ any testing or development branch of a large application under
+ heavy development.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </sect2>
+
+<!-- Section2: documentation-->
+
+ <sect2 id="documentation">
+ <title>Documentation</title>
+
+ <para>
+ A huge number of otherwise fantastic free software applications
+ have withered 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>
+ There are lots of different people you should document for and
+ there are lots of ways to document your project. <emphasis>The
+ importance of documentation in source code to help facilitate
+ development by a large community is vital</emphasis> but it falls
+ outside the scope of this HOWTO. This being the case, this section
+ deals with useful tactics for user-directed documentation.
+ </para>
+
+ <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>
+
+ <sect3>
+ <title>Man pages</title>
+
+ <para>Your users will want to be able to type <quote>man
+ yourprojectname</quote> end up with a nicely formatted man page
+ highlighting the basic use of your application. Make sure that
+ before you release your program, you've planned for this.
+ </para>
+
+ <para>
+ Man pages are not difficult to write. There is excellent
+ documentation on the man page writing process available through
+ the <quote>The Linux Man-Page-HOWTO</quote> which is available
+ through the Linux Documentation project <acronym>(LDP)</acronym>
+ and is written by Jens Schweikhardt. It is available <ulink
+ url="http://www.schweikhardt.net/man_page_howto.html">from
+ Schweikhardt's site</ulink>.
+ </para>
+
+ <para>
+ It is also possible to write man pages using DocBook
+ SGML. 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 how this is done.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Command line accessible documentation</title>
+
+ <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, as well as all the major options (also with
+ explanations), plus a pointer to more in-depth documentation for
+ those who need it. The command line documentation for Debian's
+ apt-get serves as an excellent example and a useful model:
+ </para>
+
+ <screen>
+apt 0.3.19 for i386 compiled on May 12 2000 21:17:27
+Usage: apt-get [options] command
+ apt-get [options] install pkg1 [pkg2 ...]
+
+apt-get is a simple command line interface for downloading and
+installing packages. The most frequently used commands are update
+and install.
+
+Commands:
+ update - Retrieve new lists of packages
+ upgrade - Perform an upgrade
+ install - Install new packages (pkg is libc6 not libc6.deb)
+ remove - Remove packages
+ source - Download source archives
+ dist-upgrade - Distribution upgrade, see apt-get(8)
+ dselect-upgrade - Follow dselect selections
+ clean - Erase downloaded archive files
+ autoclean - Erase old downloaded archive files
+ check - Verify that there are no broken dependencies
+
+Options:
+ -h This help text.
+ -q Loggable output - no progress indicator
+ -qq No output except for errors
+ -d Download only - do NOT install or unpack archives
+ -s No-act. Perform ordering simulation
+ -y Assume Yes to all queries and do not prompt
+ -f Attempt to continue if the integrity check fails
+ -m Attempt to continue if archives are unlocatable
+ -u Show a list of upgraded packages as well
+ -b Build the source package after fetching it
+ -c=? Read this configuration file
+ -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
+See the apt-get(8), sources.list(5) and apt.conf(5) manual
+pages for more information and options.
+ </screen>
+
+ <para>
+ It has become a GNU convention to make this 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 methods, be prepared for the flames and
+ 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 the root directory of the source
+ distribution or in a subdirectory of the root called
+ <quote>doc</quote> or <quote>Documentation.</quote> Common files
+ in these places include:
+ </para>
+
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>README or Readme</term>
+
+ <listitem>
+ <para>A document containing all the basic installation,
+ compilation, and even basic use instructions that make up the
+ bare minimum information needed to get the program up and
+ running. A README is not your chance to be verbose but should
+ 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. For most relatively standard install
+ procedures and for most programs, INSTALL files are as short
+ as possible and 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 you make to your program. The most simple way to
+ maintain 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 improvement.</para>
+ </listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term>NEWS</term>
+
+ <listitem>
+ <para>A NEWS file and a ChangeLog are similar. Unlike a
+ CHANGELOG, a NEWS file is not typically updated with new
+ versions. Whenever new features are added, the developer
+ responsible will make a note in the NEWS file. NEWS files
+ should not have to be 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 developers 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 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>
+
+ <sect3>
+ <title>Website</title>
+ <para>
+ It's only indirectly an issue of documentation but a good website
+ is quickly becoming an essential part of any free software
+ project. Your website should provide access to your 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 make 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>
+
+ <sect3>
+ <title>Other documentation hints</title>
+
+ <itemizedlist>
+ <listitem>
+ <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> In my opinion, info falls into this category
+ as well. There is plenty of great GNU documentation that
+ people simply don't read because it only in info. And this
+ <emphasis>does</emphasis> make people angry. It's not a
+ question of superior formats; it is a question of
+ accessability and the status quo plays a huge role in this
+ determination.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ It doesn't hurt to distribute any documentation for your
+ program from your website (FAQs etc) with your program. Don't
+ hesitate to throw any of this in the program's 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>
+ </listitem>
+
+ <listitem>
+ <para>Unless your software is particular to a non-English
+ language (a Japanese language editor for example), please
+ distribute it with English language documentation. If you don't
+ speak English or not not confident in your skills, ask a friend
+ for help. Like it or not, fair or unfair, <emphasis>English is
+ the language of free software</emphasis>. However, this does not
+ mean you should limit your documentation to only English. If you
+ speak another language, distribute translations of documentation
+ with your software if you have the time and energy to do
+ so. They will invariably be useful to someone.</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Finally, <emphasis>please spell-check your
+ documentation.</emphasis> Misspellings in documentation are
+ bugs. I'm very guilty of committing this error and it's
+ extremely easy to do. If English is not your first language,
+ have a native speaker look over or edit your documentation or
+ web pages. Poor spelling or grammar goes a long way to making
+ your code look unprofessional. In code comments, this type of
+ thing is less important but in man pages and web pages these
+ mistakes are not acceptable.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+
+ </sect3>
+ </sect2>
+
+<!-- Section2: presentation -->
+
+ <sect2 id="presentation">
+ <title>Other Presentation Issues</title>
+ <para>
+ Many of the remaining issues surrounding the creation of a new
+ free software program fall under what most people describe as
+ common sense issues. Its often said that software engineering is
+ 90 percent common sense combined with 10 percent specialized
+ knowledge. Still, they are worth noting briefly in hopes that they
+ may remind a developer of something they may have forgotten.
+ </para>
+
+ <sect3>
+ <title>Package File Names</title>
+ <para>
+ I agree with ESR when he says that: <quote> It's helpful to
+ everybody if your archive files all have GNU-like names --
+ all-lower-case alphanumeric stem prefix, followed by a dash,
+ followed by a version number, extension, and other
+ suffixes.</quote> There is more info (including lots of examples
+ of what <emphasis>not</emphasis> to do in his <citetitle>Software
+ Release Practices HOWTO</citetitle> which is included in this
+ HOWTO's bibliography and can be found through the LDP.
+ </para>
+ </sect3>
+
+ <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-light as a more effective compression medium. I now make
+ all my releases available in both gzip'ed and bzip2'ed tarballs.
+ </para>
+
+ <para>
+ Binary packages should always be distribution specific. If 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 distributions to
+ develop a system for the consistent creation of 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 if
+ possible. Remember: <emphasis>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>
+
+ <sect3>
+ <title>Version control systems</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)
+ less problematic. 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>
+
+ <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 described by this HOWTO. I
+ am not aware of any free version control systems for Windows or
+ Mac OS 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 web interface to CVS.
+ </para>
+
+ <para>
+ I'd love to devote more space in this HOWTO to CVS because I love
+ it (I even use CVS to keep versions straight on this HOWTO!) but
+ I think it falls outside the scope of this document and already
+ has its own HOWTOs. Most notably is the <citetitle>CVS Best
+ Practices HOWTO</citetitle><xref linkend="cvsbestpractices">
+ which I've included in the attached bibliography.
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Useful tidbits and presentation hints</title>
+
+ <para>
+ Other useful hints include:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <emphasis>Make sure that your program can always be found in a
+ single location.</emphasis> Often this means that you have a
+ single directory accessible via <acronym>FTP</acronym> or the
+ web where the newest version can be quickly recognized. One
+ effective technique is a provide a symlink called
+ <quote>yourprojectname-latest</quote> that is always pointing
+ to the most recent released or development version of your
+ free software application. Keep in mind that this location
+ will receive many requests for downloads around releases so
+ make sure that the server you choose 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
+ yourprojectname@host or yourprojectname-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>
+
+ </itemizedlist>
+ </para>
+ </sect3>
+ </sect2>
+ </sect1>
+
+<!-- Section1: starting: END -->
+
+<!-- Section1: developers -->
+
+ <sect1 id="developers">
+ <title>Maintaining a Project: Interacting with Developers</title>
+ <indexterm>
+ <primary>fswd!developers</primary>
+ </indexterm>
+
+ <para>
+ Once you have gotten 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 just as many
+ opportunities for failure. In the next two sections, I will
+ describe running a project by discussing how to maintain a
+ development effort through interactions with developers and with
+ users.
+ </para>
+
+ <para>
+ In releasing your program, your program becomes free software. This
+ transition is more than just a larger user base. By releasing your
+ program as free software, <emphasis>your</emphasis> software
+ becomes the <emphasis>free software community's</emphasis>
+ software. The direction of your software's development will be
+ reshaped, redirected, and fully determined by your users and, to a
+ larger extent, by other developers in the community.
+ </para>
+
+ <para>
+ The major difference between free software development and
+ propriety software development is the developer base. As the leader
+ of a free software project, you need to attract and keep developers
+ in a way that leaders of proprietary software projects simply don't
+ have to worry about. <emphasis>As the person leading development of
+ a free software project, you must harness the work of fellow
+ developers by making responsible decisions and by 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>
+
+<!-- Section2: delegation -->
+
+ <sect2 id="delegation">
+ <title>Delegating Work</title>
+
+ <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 we've gone ahead and (as will be
+ discussed in <xref linkend="releasing">) released it to the rest
+ of the world. Times passes, and if things go well, people become
+ interested and want to help. The patches begin flowing in.
+ </para>
+
+ <para>
+ <emphasis>Like the parent of any child who grows up, it's now time
+ to wince, smile and do most difficult thing in any parents
+ life: It's time to let go.</emphasis>
+ </para>
+
+ <para>
+ Delegation is the political way of describing this process of
+ <quote>letting go.</quote> It is the process of handing some of
+ the responsibility and power over your project to other
+ responsible and involved developers. It is difficult for anyone
+ who has invested a large deal of time and energy into a project
+ but it essential for the growth of any free software project. One
+ person can only do so much. A free software project is nothing
+ without the involvement of <emphasis>a group</emphasis> of
+ developers. A group of developers can only be maintained through
+ respectful and responsible leadership and delegation.
+ </para>
+
+ <para>
+ As your project progresses, you will notice people who are putting
+ significant amounts of time and effort into your project. These
+ will be the people submitting the most patches, posting most on
+ the mailing lists, and 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>
+ In a bit of a disclaimer, delegation need not mean rule by
+ committee. In many cases it does and this has been proven to
+ work. In other cases this has created problems. <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
+ project's founder and that these important powers need not all rest
+ with one person but that a release manager may be different than a
+ lead developer. These situations are tricky politically so
+ be careful and make sure it's necessary before you go around
+ empowering people.
+ </para>
+
+ <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 be the best or the brightest. It means you
+ 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
+ toward 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 to have write access to your CVS
+ repository and make real efforts toward rule by a
+ committee</title>
+
+ <para>
+ <ulink url="http://httpd.apache.org/">Apache</ulink> is an
+ example of a project that is run by small group of developers
+ who vote on major technical issues and the admission of new
+ members and all have write access to the main source
+ repository. Their process is detailed <ulink
+ url="http://httpd.apache.org/ABOUT_APACHE.html">online.</ulink>
+ </para>
+
+ <para>
+ The <ulink url="http://www.debian.org/"> Debian Project</ulink>
+ is an extreme example of rule by committee. At current count,
+ more than 700 developers have full responsibility for
+ aspects of the project. All these developers can upload into
+ the main FTP server, 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>
+
+ <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>
+
+ </sect4>
+
+ <sect4 id="releasemanager">
+ <title>Publicly appoint someone as the release manager for a
+ specific release</title>
+
+ <para>
+ A release manager is usually responsible for coordinating
+ testing, enforcing a code freeze, being responsible for
+ stability and quality control, packaging up the software, and
+ placing it in the appropriate places to be downloaded.
+ </para>
+
+ <para>
+ This use of the release manager is a good way to give yourself a
+ break and to shift the responsibility for accepting and
+ rejecting patches onto 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>
+
+ <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>
+ The author of Linux, Linus Torvalds, came out and crowned Alan
+ Cox as <quote>the man for stable kernels.</quote> All patches
+ for stable kernels go to Alan and, if Linus were to be taken
+ away from work on Linux for any reason, Alan Cox would be more
+ than suited to fill his role as the acknowledged heir to the
+ Linux maintainership.
+ </para>
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: patching -->
+
+ <sect2 id="patching">
+ <title>Accepting and Rejecting Patches</title>
+ <para>
+ This HOWTO has already touched on the fact that as the maintainer
+ of a free software project, one of your primary and most important
+ responsibilities will be accepting and rejecting patches submitted
+ to you by other developers.
+ </para>
+
+ <sect3>
+ <title>Encouraging Good Patching</title>
+
+ <para>As the person managing or maintaining the project, you
+ aren't the person who is going to be making a lot of
+ patches. However, it's worth knowing about ESR's section on
+ <citetitle>Good Patching Practice</citetitle> in the
+ <citetitle>Software Release Practices HOWTO</citetitle><xref
+ linkend="esrhowto">. I don't agree with ESR's claim that most ugly
+ or undocumented patches are probably worth throwing out at first
+ sight--this just hasn't been my experience, especially when
+ dealing with bug fixes that often don't come in the form of
+ patches at all. Of course, this doesn't mean that I
+ <emphasis>like</emphasis> getting poorly done patches. If you get
+ ugly -e patches, if you get totally undocumented patches, and
+ especially if they are anything more than trivial bug-fixes, it
+ might be worth judging the patch by some of the criteria in ESR's
+ HOWTO and then throwing people the link to the document so they
+ can do it the <quote>right way.</quote>
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Technical judgment</title>
+
+ <para>
+ In <emphasis>Open Source Development with CVS</emphasis>, Karl
+ Fogel makes a convincing argument that the most important things
+ to keep in mind when rejecting or accepting patches are:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <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>
+
+ <listitem>
+ <para>The necessity to avoid digressions that might expand the
+ scope of the program too much and result and push the project
+ toward an early death under its own weight and
+ unwieldiness.</para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ These are the criteria that you as a project maintainer should
+ take into account each time you receive a patch.
+ </para>
+
+ <para>
+ Fogel elaborates on this 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 these 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 many ultimately fail.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Rejecting patches</title>
+
+ <para>
+ Rejecting patches is probably the most difficult and 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 you need 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 the community's project. I recommend that you keep these three
+ major concepts 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 and debated. 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 gray 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 toward the beginning of your project's life, 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 programmers. 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 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
+ into 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 your
+ application. 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>
+ 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>
+ 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
+ <emphasis>always</emphasis> 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>
+ Linux's model provides an extreme example. On many projects, there is no
+ need to have two versions constantly 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>
+ In trying to set up a development tree for yourself, there are
+ several things that might be useful to keep in mind:
+ </para>
+
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>Minimize the number of branches</term>
+ <listitem>
+ <para>Debian may be able to make good use of four or five
+ branches but it contains gigabytes of software in over 5000
+ packages compiled for 5-6 different architectures. For you,
+ two is probably a good ceiling. Too many branches will confuse
+ your users (I can't count how many times I had to describe
+ Debian's system when it only had 2 and sometimes 3 branches!),
+ potential developers and even yourself. Branches can help but
+ they come at a cost so use them very sparingly.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Make sure that all your different branches are explained</term>
+ <listitem>
+ <para>As I mentioned in the preceding paragraph, different
+ branches <emphasis>will</emphasis> confuse your users. Do
+ everything you can to avoid this by clearly explaining the
+ different branches in a prominent page on your website and in a
+ README file in the <acronym>FTP</acronym> or
+ web directory.</para>
+
+ <para>
+ I might also recommend against a mistake that I think Debian
+ has made. The terms <quote>unstable,</quote>
+ <quote>testing,</quote> and <quote>experimental</quote> are
+ vague and difficult to rank in order of stability (or
+ instability as the case may be). Try explaining to someone
+ that <quote>stable</quote> actually means <quote>ultra
+ stable</quote> and that <quote>unstable</quote> doesn't
+ actually include any unstable software but is really stable
+ software that is untested as a distribution.
+ </para>
+
+ <para>
+ If you are going to 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 into different directories or directory
+ trees on your <acronym>FTP</acronym> or web 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 and where to
+ get it.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </para>
+
+ </sect2>
+
+<!-- Section2: otherdev -->
+
+ <sect2 id="otherdev">
+ <title>Other Project Management issues</title>
+ <para>
+ 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 and scope. Please don't hesitate to contact me if you see
+ any major omissions.
+ </para>
+
+ <para>
+ Other smaller issues that are worth mentioning are:
+ </para>
+
+ <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 <quote>code freeze,</quote> all changes to
+ the code are discouraged and only changes that fix known bugs
+ are permitted. This type of freeze usually follows a
+ <quote>feature freeze</quote> and directly precedes a
+ release. Most released software is in what could be interpreted
+ as a sort of high level <quote>code freeze.</quote>
+ </para>
+
+ <para>
+ Even 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>
+ </sect2>
+
+ <sect2>
+ <title>Forks</title>
+ <para>
+ I wasn't sure about how I would deal with forking in this
+ document (or if I would deal with forking at all). A fork is when
+ a group of developers takes code from a free software project and
+ actually starts a brand new free software project with it. The
+ most famous example of a fork was between Emacs and XEmacs. Both
+ emacsen are based on an 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.
+ </para>
+
+ <para>
+ In his chapter on <quote>The Open Source Process,</quote> Karl
+ Fogel describes how to do a fork if you absolutely must. If you
+ have determined that is absolutely necessary and that the
+ differences between you and the people threatening to fork are
+ absolutely unresolvable, I recommend Fogel's book as a good place
+ to start.
+ </para>
+ </sect2>
+ </sect1>
+
+<!-- Section1: users -->
+
+ <sect1 id="users">
+ <title>Maintaining a Project: Interacting with Users</title>
+ <indexterm>
+ <primary>fswd!users</primary>
+ </indexterm>
+
+ <para>
+ If you've worked your way up to here, congratulations, you are
+ nearing the end of this document. This final section describes some
+ of the situations in which you, in your capacity as project
+ maintainer, will be interacting with users. It gives some
+ suggestions on how these situations might be handled effectively.
+ </para>
+
+ <para>
+ Interacting with users is difficult. In our discussion of
+ interaction with developers, the underlying assumption is that in a
+ free software project, a project maintainer must constantly strive to
+ attract and keep developers who can easily leave at any time.
+ </para>
+
+ <para>
+ Users in the free software community are different than 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>
+ <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, chances are good
+ that you will not be scrambling to gain the features of your
+ competitor's newest program. This means that your development
+ process will have to be directed either internally, by a
+ commitment to your users, or through both.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Trying to tackle this unique situation can only be done
+ indirectly. Developers and maintainers need to listen to users and
+ to try and be as responsive as possible. A solid knowledge of the
+ situation recounted above is any free software developer's best tool
+ for shifting his development or leadership style to fit the unique
+ process of free software project management. 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 of your
+ users</emphasis> (those who explicitly volunteer) 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, greatest features. These users
+ except a stable, tested piece of software without major or obvious
+ bugs and will be angry if they find themselves testing. This is
+ yet another way in which a split development model (as mentioned
+ in <xref linkend="branches">) might come in handy.
+ </para>
+
+ <para>
+ <quote><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink></quote> describes what a
+ good test should look for:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Boundary conditions</term>
+
+ <listitem>
+ <para>Maximum buffer lengths, data conversions, upper/lower
+ boundary limits, and so on.</para>
+ </listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term>Inappropriate behavior</term>
+
+ <listitem>
+ <para>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 <quote>what if</quote> questions
+ and think of anything that <emphasis>might</emphasis> fail or
+ <emphasis>might</emphasis> go wrong and find out what your
+ program would do in those cases.</para>
+ </listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term>Graceful failure</term>
+
+ <listitem>
+ <para>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>
+
+ </varlistentry>
+
+ <varlistentry>
+ <term>Standards conformance</term>
+
+ <listitem>
+ <para>If possible, make sure your programs conforms to
+ standards. If it's interactive, 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>
+ </variablelist>
+
+ <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
+ the things you just forget. They are not very good at finding
+ errors, even major ones, that are totally unforeseen.
+ </para>
+
+ <para>
+ CVS comes with a Bourne shell script called sanity.sh that is
+ worth looking at. Debian uses a program called lintian that
+ checks Debian packages for all of the most common errors. While
+ use of these scripts may not be helpful, there is a host of other
+ sanity checking software on the net that may be applicable (feel
+ free to email me 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 keep them out of future releases.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Testing by testers</title>
+ <para>
+ For any program that depends on user interactivity, many bugs
+ will only be uncovered through testing by users actually clicking
+ the keys and pressing the mouse buttons. For this you need
+ testers and as many as possible.
+ </para>
+
+ <para>
+ The most difficult part of testing is finding testers. It's
+ usually a good tactic to post a message to a relevant mailing
+ list or news group announcing a specific proposed release date
+ and outlining the functionality of your program. If you put some
+ time into the announcement, you are sure to get a few responses.
+ </para>
+
+ <para>
+ The second most difficult part of testing is
+ <emphasis>keeping</emphasis> your testers and keeping them
+ actively involved in the testing process. Fortunately, there are
+ some tried and true tactics that can applied toward this end:
+ </para>
+
+ <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 to 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. Publicly, 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>
+
+ </sect3>
+ </sect2>
+
+<!-- Section2: support -->
+
+ <sect2 id="support">
+ <title>Setting up Support Infrastructure</title>
+
+ <para>
+ While testing is important, the large part of your interactions
+ and responsibility to your users falls under the category of
+ support. The best way to make sure your users are adequately
+ supported in using your program is to set up a good infrastructure
+ for this purpose so that your developers and users help each other
+ and less of the burden falls on you. This way, people will also
+ get quicker and better responses to their questions. This
+ infrastructure comes in several major forms:
+ </para>
+
+ <sect3>
+ <title>Documentation</title>
+ <para>
+ It should not come as any surprise that the key element to any
+ support infrastructure is good documentation. This topic was
+ largely covered in <xref linkend="documentation"> and will not be
+ repeated here.
+ </para>
+ </sect3>
+
+ <sect3 id="mailinglists">
+ <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>
+
+ <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>
+ This system provides so that no one person is stuck doing all of
+ the support work and works so that users learn more about the
+ program, they can help newer users with their questions.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Choose mailing list software well</title>
+ <para>
+ Please don't make the selection of mailing list software
+ 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>
+
+ <para>
+ The two biggest free software mailing list programs are <ulink
+ url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
+ and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
+ long time advocate of majordomo, I would now recommend any
+ project choose GNU Mailman. It fulfills the criteria listed
+ above and makes it easier. It provides a good mailing
+ list program for a free software project maintainer as opposed
+ to a good mailing list application for a mailing list
+ administrator.
+ </para>
+
+ <para>
+ There are other things you want to take into consideration in
+ setting up your list. If it is possible to gate your mailing
+ lists to Usenet and provide it in digest form as well as
+ making them accessible on the web, you will please some users
+ and work to make the support infrastructure slightly more
+ accessible.
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3>
+ <title>Other support ideas</title>
+
+ <para>
+ A mailing list and accessible documentation are far from all you
+ can do to set up good user support infrastructure. Be
+ creative. If you stumble across something that works well, email me
+ and I'll include it here.
+ </para>
+
+ <sect4>
+ <title>Make your self accessible</title>
+ <para>
+ You can not list too few methods to reach you. If you hang out
+ in an <acronym>IRC</acronym> channel, don't hesitate to list it
+ in your projects documentation. List email and snailmail
+ addresses, and ways to reach you via <acronym>ICQ</acronym>,
+ <acronym>AIM</acronym>, or Jabber if they apply.
+ </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 a lot.
+ </para>
+
+ <para>
+ These systems (and others like them) can be unwieldy so
+ developers should be careful to not spend more time on the bug
+ tracking system than on the bugs or the projects themselves. If
+ a project continues to grow, use of a bug tracking system can
+ provide an easy standard avenue for users and testers to report
+ bugs and for developers and maintainers to fix them and track
+ them in an orderly fashion.
+ </para>
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: releasing -->
+
+ <sect2 id="releasing">
+ <title>Releasing Your Program</title>
+
+ <para>
+ As mentioned earlier in the HOWTO, the first rule 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 will 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>
+
+ <sect3>
+ <title>When to release</title>
+
+ <para>
+ Making the decision to release your software for the first time
+ is an incredibly important and incredibly stressful decision. But
+ it needs to 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>
+
+ <para>
+ <emphasis>When you feel in your gut that it is time and you feel
+ you've weighed the situation well several times, cross your
+ fingers and take the plunge.</emphasis>
+ </para>
+
+ <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>
+
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>Contain sufficient new functionality or bug fixes to be
+ worth the effort.</para>
+ </listitem>
+
+ <listitem>
+ <para>Be spaced sufficiently far apart to allow the user time
+ to work with the latest release.</para>
+ </listitem>
+
+ <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>
+
+ <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 making your website reflect the
+ change.
+ </para>
+ </sect3>
+
+ <sect3 id="alphabeta">
+ <title>Alpha, beta, and development releases</title>
+
+ <para>
+ When contemplating releases, it worth considering the fact that
+ not every release needs to be a full numbered release. Software
+ users are accustomed to pre-releases but you must be careful to
+ label these releases accurately or they will cause more problems then
+ they are worth.
+ </para>
+
+ <para>
+ The observation is often made that many free software developers
+ seem to be confused about the release cycle. <quote><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink></quote> 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>
+ <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. They
+ <emphasis>can</emphasis> 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 left to be
+ ironed out.</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 to be 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 a 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 alpha or beta and if I were to release a
+ pre-alpha version of a piece of software in order to keep
+ interest in my project alive, this is probably how I would
+ have to label it.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </para>
+ </sect3>
+ </sect2>
+
+<!-- Section2: announcing -->
+
+ <sect2 id="announcing">
+ <title>Announcing Your Project</title>
+
+ <para>
+ Well, you've done it. You've (at least for the purposes of this
+ HOWTO) designed, built, and released your free software
+ project. All that is left is for you to tell the world so they
+ know to come and try it out and hopefully jump on board with
+ development. If everything is in order as described above, this
+ will be a quick and painless process. A quick announcement is all
+ that it takes to put yourself on the free software community's
+ radar screen.
+ </para>
+
+ <sect3>
+ <title>Mailing lists and Usenet</title>
+
+ <para>Announce your software on Usenet's <ulink
+ url="news:comp.os.linux.announce">comp.os.linux.announce</ulink>. If
+ you only announce your software in two places, have it be c.o.l.a
+ and freshmeat.</para>
+
+ <para>
+ However, 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 other relevant Usenet discussion groups.</para>
+
+ <para>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. This form
+ will work for both Usenet and mailing list posts.
+ </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 personally skim it every night for any
+ interesting new releases).
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Project Mailing List</title>
+
+ <para>If you've gone ahead and created mailing lists for your
+ project, you should always announce new versions on these
+ lists. I've found that for many projects, users request a very
+ low-volume announce only mailing list to be notified when new
+ versions are released. freshmeat.net now allows users to subscribe
+ to a particular project so they receive emails every time a new
+ version is announced through their system. It's free and it can
+ stand in for an announce-only mailing list. In my opinion, it
+ can't hurt.</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 subtitle. In the publisher's
+ 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 also 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 role it tried to serve was so
+ important and useful. Please check it or buy it if you can and
+ are seriously interested in running a free software project.
+ </para>
+
+ <para>In May of 2003, the entire book under the GPL. You can
+ find the full text of the book <ulink
+ url="http://cvsbook.red-bean.com/">here</ulink>.</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
+ spineless use of the term <quote>open code</quote> that only a
+ lawyer could coin), Lessig's 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 the nature of future freedoms. In
+ addition to being a quick and enjoyable read, it gives some
+ cool history and 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 of sketching the free software process and does an an
+ amazing job of making an argument for free software/open source
+ development as a road to better software. The rest of the book
+ has other of ESR's articles, which for the most part are posted
+ on his website. Still, it's nice thing to own in hard copy and
+ something that every free software/open source hacker should
+ read.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ </bibliodiv>
+
+ <bibliodiv>
+ <title>Web-Accessible Resources</title>
+
+ <para>
+ This is a list of the web resources pertaining to this HOWTO that
+ I've found most helpful in compiling this information. If you know
+ of others that would help, please don't hesitate to email me at
+ <email>mako@atdot.cc</email> and we can look into getting it
+ added to the list and represented in the HOWTO.
+ </para>
+
+ <para>
+ I'd recommend that any free software developer (or potential one)
+ skim through these sites because they have each have a lot to say.
+ </para>
+
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Dafermos</surname>
+ <firstname>George</firstname>
+ <othername>N</othername>
+ </author>
+
+ <title><ulink url="http://firstmonday.org/issues/issue6_11/dafermos/">Management and Virtual Decentralized Networks: The Linux Project</ulink></title>
+
+ <abstract>
+ <para>Since the paper includes its own abstract, I thought I
+ would include it here verbatim:</para>
+
+ <para><blockquote><para>This paper examines the latest of
+ paradigms - the Virtual Network(ed) Organisation - and whether
+ geographically dispersed knowledge workers can virtually
+ collaborate for a project under no central
+ planning. Co-ordination, management and the role of knowledge
+ arise as the central areas of focus. The Linux Project and its
+ development model are selected as a case of analysis and the
+ critical success factors of this organisational design are
+ identified. The study proceeds to the formulation of a
+ framework that can be applied to all kinds of virtual
+ decentralised work and concludes that value creation is
+ maximized when there is intense interaction and uninhibited
+ sharing of information between the organisation and the
+ surrounding community. Therefore, the potential success or
+ failure of this organisational paradigm depends on the degree
+ of dedication and involvement by the surrounding
+ community.</para></blockquote></para>
+
+ <para>This paper was referred to me in my capacity as author of
+ this HOWTO and I was very impressed. It's written by a graduate
+ student in management and I think it succeeds at evaluating the
+ Linux project as an example of a new paradigm in management--one
+ that <emphasis>you</emphasis> will be be placing yourself at the
+ center of in your capacity as maintainer of a free software
+ project.</para>
+
+ <para>As a developer trying to control an application and guide
+ it to success in the free software world, I'm not sure how
+ useful Dafermos's argument is. It does however, provide a
+ theoretical justification for my HOWTO--free software project
+ management <emphasis>is</emphasis> a different creature than
+ proprietary software project management. If you are interested
+ in the conceptual and theoretical ways that free software
+ project management differs from other types of management, this
+ is a great paper to read. If this paper answers questions of
+ <quote>how?</quote>, Dafermos answers the (more difficult to
+ defend) questions of <quote>why?</quote> and does a very good
+ job.</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 the rest of the essay helped. It
+ offers a good description of how to design programs that will
+ succeed and stay maintainable as they grow.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <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, documentation, organizing a team and
+ leadership, and several other topics. While more opinionated that
+ I try to be, I think its an important article that I found very
+ helpful in writing this HOWTO. I've tried to cite him in
+ the places where I borrowed from him most.
+ </para>
+
+ <para>
+ I have problems much of this piece and I recommend you read
+ <xref linkend="krawitz"> at the same time you read Monty's
+ article for a good critique.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry id="esrhowto">
+ <biblioset>
+ <author>
+ <surname>Raymond</surname>
+ <firstname>Eric</firstname>
+ <othername>Steven</othername>
+ </author>
+
+ <title><ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">Software Release Practice HOWTO</ulink></title>
+
+ <abstract>
+
+ <para>At first glance, ESR's release practice HOWTO seems to
+ share a lot of terrain with this document. Upon closer
+ examination, the differences become apparent but they are
+ closely related. His document, read in conjunction with mine,
+ will give a reader a good picture of how to go about managing a
+ project. ESR's HOWTO goes into a bit more detail on how to write
+ and what languages to write in. He tends to give more specific
+ instructions and checklists (<quote>name this file this, not
+ this</quote>) while this HOWTO speaks more conceptually. There
+ are several sections that are extremely similar. It's also
+ <emphasis>much</emphasis> shorter.</para>
+
+ <para>My favorite quote from his HOWTO is: <quote>"Managing a
+ project well when all the participants are volunteers presents
+ some unique challenges. This is too large a topic to cover in a
+ HOWTO.</quote> Oh really? Perhaps I just do a poor job.</para>
+ </abstract>
+
+ </biblioset>
+ </biblioentry>
+
+
+ <biblioentry id="cvsbestpractices">
+ <biblioset>
+ <author>
+ <surname>Venugopalan</surname>
+ <firstname>Vivek</firstname>
+ </author>
+
+ <title><ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html">CVS Best Practices</ulink></title>
+
+ <abstract>
+
+ <para>Venugopalan provides one of the best essays on
+ effective use of CVS that I've come across. It is written for
+ people who already have a good knowledge of CVS. In the chapter
+ on branching, he describes when and how to branch but gives no
+ information on what CVS commands you should use to do this. This
+ is fine (technical CVS HOWTO have been written) but CVS newbies
+ will want to spend some time with Fogel's reference before they
+ will find this one very useful.</para>
+
+ <para>Venugopalan creates checklists of things to do before,
+ after, and around releases. It's definitely worth a read through
+ as most of his ideas will save tons of developer head aches over
+ any longer period of time.</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 Advogato.org. 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 huge amount of time on Advogato and I've gone
+ through and provided links to the articles that I think might be
+ of particular interest to anyone reading this HOWTO. I think that
+ skimming through these links can be helpful and I promise that if
+ you do, 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. I think that's important.
+ </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
+ relevant articles here with short descriptions that I've written.
+ </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 management (<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 HOWTO. It's one of
+ the better (and most diplomatic) 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 calls simply for the application of
+ old (proprietary software) project management techniques in
+ free software projects instead of working to come up with
+ something new. I found his article to be extremely well thought
+ out and I think it's an essential read for any free software
+ 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
+ answers to this question offered by Advogato's readers can
+ help. In a lot of ways, this HOWTO acts as my answer to the
+ questions posed in this article but there are others, many of
+ which might take issue with whats is 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 without starting a project. I think this
+ is an important article. If you are interested in becoming
+ 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">Importance of
+ Non-Developer Supporters in Free Software</ulink><title></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 project 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>February 28, 2000</pubdate>
+
+ <abstract>
+ <para>
+ In this article, David Allen challenges the whole
+ <quote>Major.Minor.Patch</quote> version numbering 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 version numbering.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ </bibliodiv>
+ </bibliography>
+
+ <appendix id="fdl">
+ <title>GNU Free Documentation License</title>
+ <para>
+ Copyright (C) 2000, 2001, 2002 Free Software Foundation,
+ <abbrev>Inc.</abbrev> 51 Franklin <abbrev>St</abbrev>, Fifth Floor,
+ Boston, <abbrev>MA</abbrev> 02110-1301 <abbrev
+ role="initialism">USA</abbrev>. Everyone is permitted to copy and
+ distribute verbatim copies of this license document, but changing it is
+ not allowed.
+ </para>
+ <bridgehead id="Preamble" renderas="sect1">
+ 0. PREAMBLE
+ </bridgehead>
+ <para>
+ The purpose of this License is to make a manual, textbook, or other
+ functional and useful document "free" in the sense of freedom: to assure
+ everyone the effective freedom to copy and redistribute it, with or
+ without modifying it, either commercially or noncommercially.
+ Secondarily, this License preserves for the author and publisher a way to
+ get credit for their work, while not being considered responsible for
+ modifications made by others.
+ </para>
+ <para>
+ This License is a kind of "copyleft", which means that derivative works of
+ the document must themselves be free in the same sense. It complements
+ the GNU General Public License, which is a copyleft license designed for
+ free software.
+ </para>
+ <para>
+ We have designed this License in order to use it for manuals for free
+ software, because free software needs free documentation: a free program
+ should come with manuals providing the same freedoms that the software
+ does. But this License is not limited to software manuals; it can be used
+ for any textual work, regardless of subject matter or whether it is
+ published as a printed book. We recommend this License principally for
+ works whose purpose is instruction or reference.</para>
+ <bridgehead id="Definitions" renderas="sect1">
+ 1. APPLICABILITY AND DEFINITIONS
+ </bridgehead>
+ <para>
+ This License applies to any manual or other work, in any medium, that
+ contains a notice placed by the copyright holder saying it can be
+ distributed under the terms of this License. Such a notice grants a
+ world-wide, royalty-free license, unlimited in duration, to use that work
+ under the conditions stated herein. The "Document", below, refers to any
+ such manual or work. Any member of the public is a licensee, and is
+ addressed as "you". You accept the license if you copy, modify or
+ distribute the work in a way requiring permission under copyright
+ law.
+ </para>
+ <para>
+ A "Modified Version" of the Document means any work containing the
+ Document or a portion of it, either copied verbatim, or with modifications
+ and/or translated into another language.
+ </para>
+ <para>
+ A "Secondary Section" is a named appendix or a front-matter section of the
+ Document that deals exclusively with the relationship of the publishers or
+ authors of the Document to the Document's overall subject (or to related
+ matters) and contains nothing that could fall directly within that overall
+ subject. (Thus, if the Document is in part a textbook of mathematics, a
+ Secondary Section may not explain any mathematics.) The relationship
+ could be a matter of historical connection with the subject or with
+ related matters, or of legal, commercial, philosophical, ethical or
+ political position regarding them.
+ </para>
+ <para>
+ The "Invariant Sections" are certain Secondary Sections whose titles are
+ designated, as being those of Invariant Sections, in the notice that says
+ that the Document is released under this License. If a section does not
+ fit the above definition of Secondary then it is not allowed to be
+ designated as Invariant. The Document may contain zero Invariant
+ Sections. If the Document does not identify any Invariant Sections then
+ there are none.
+ </para>
+ <para>
+ The "Cover Texts" are certain short passages of text that are listed, as
+ Front-Cover Texts or Back-Cover Texts, in the notice that says that the
+ Document is released under this License. A Front-Cover Text may be at
+ most 5 words, and a Back-Cover Text may be at most 25 words.
+ </para>
+ <para>
+ A "Transparent" copy of the Document means a machine-readable copy,
+ represented in a format whose specification is available to the general
+ public, that is suitable for revising the document straightforwardly with
+ generic text editors or (for images composed of pixels) generic paint
+ programs or (for drawings) some widely available drawing editor, and that
+ is suitable for input to text formatters or for automatic translation to a
+ variety of formats suitable for input to text formatters. A copy made in
+ an otherwise Transparent file format whose markup, or absence of markup,
+ has been arranged to thwart or discourage subsequent modification by
+ readers is not Transparent. An image format is not Transparent if used
+ for any substantial amount of text. A copy that is not "Transparent" is
+ called "Opaque".
+ </para>
+ <para>
+ Examples of suitable formats for Transparent copies include plain ASCII
+ without markup, Texinfo input format, LaTeX input format, SGML or XML
+ using a publicly available DTD, and standard-conforming simple HTML,
+ PostScript or PDF designed for human modification. Examples of
+ transparent image formats include PNG, XCF and JPG. Opaque formats
+ include proprietary formats that can be read and edited only by
+ proprietary word processors, SGML or XML for which the DTD and/or
+ processing tools are not generally available, and the machine-generated
+ HTML, PostScript or PDF produced by some word processors for output
+ purposes only.
+ </para>
+ <para>
+ The "Title Page" means, for a printed book, the title page itself, plus
+ such following pages as are needed to hold, legibly, the material this
+ License requires to appear in the title page. For works in formats which
+ do not have any title page as such, "Title Page" means the text near the
+ most prominent appearance of the work's title, preceding the beginning of
+ the body of the text.
+ </para>
+ <para>
+ A section "Entitled XYZ" means a named subunit of the Document whose title
+ either is precisely XYZ or contains XYZ in parentheses following text that
+ translates XYZ in another language. (Here XYZ stands for a specific
+ section name mentioned below, such as "Acknowledgements", "Dedications",
+ "Endorsements", or "History".) To "Preserve the Title" of such a section
+ when you modify the Document means that it remains a section "Entitled
+ XYZ" according to this definition.
+ </para>
+ <para>
+ The Document may include Warranty Disclaimers next to the notice which
+ states that this License applies to the Document. These Warranty
+ Disclaimers are considered to be included by reference in this License,
+ but only as regards disclaiming warranties: any other implication that
+ these Warranty Disclaimers may have is void and has no effect on the
+ meaning of this License.
+ </para>
+ <bridgehead id="VerbatimCopying" renderas="sect1">
+ 2. VERBATIM COPYING
+ </bridgehead>
+ <para>
+ You may copy and distribute the Document in any medium, either
+ commercially or noncommercially, provided that this License, the copyright
+ notices, and the license notice saying this License applies to the
+ Document are reproduced in all copies, and that you add no other
+ conditions whatsoever to those of this License. You may not use technical
+ measures to obstruct or control the reading or further copying of the
+ copies you make or distribute. However, you may accept compensation in
+ exchange for copies. If you distribute a large enough number of copies
+ you must also follow the conditions in section 3.
+ </para>
+ <para>
+ You may also lend copies, under the same conditions stated above, and you
+ may publicly display copies.
+ </para>
+ <bridgehead id="QuantityCopying" renderas="sect1">
+ 3. COPYING IN QUANTITY
+ </bridgehead>
+ <para>
+ If you publish printed copies (or copies in media that commonly have
+ printed covers) of the Document, numbering more than 100, and the
+ Document's license notice requires Cover Texts, you must enclose the
+ copies in covers that carry, clearly and legibly, all these Cover Texts:
+ Front-Cover Texts on the front cover, and Back-Cover Texts on the back
+ cover. Both covers must also clearly and legibly identify you as the
+ publisher of these copies. The front cover must present the full title
+ with all words of the title equally prominent and visible. You may add
+ other material on the covers in addition. Copying with changes limited to
+ the covers, as long as they preserve the title of the Document and satisfy
+ these conditions, can be treated as verbatim copying in other
+ respects.
+ </para>
+ <para>
+ If the required texts for either cover are too voluminous to fit legibly,
+ you should put the first ones listed (as many as fit reasonably) on the
+ actual cover, and continue the rest onto adjacent pages.
+ </para>
+ <para>
+ If you publish or distribute Opaque copies of the Document numbering more
+ than 100, you must either include a machine-readable Transparent copy
+ along with each Opaque copy, or state in or with each Opaque copy a
+ computer-network location from which the general network-using public has
+ access to download using public-standard network protocols a complete
+ Transparent copy of the Document, free of added material. If you use the
+ latter option, you must take reasonably prudent steps, when you begin
+ distribution of Opaque copies in quantity, to ensure that this Transparent
+ copy will remain thus accessible at the stated location until at least one
+ year after the last time you distribute an Opaque copy (directly or
+ through your agents or retailers) of that edition to the public.
+ </para>
+ <para>
+ It is requested, but not required, that you contact the authors of the
+ Document well before redistributing any large number of copies, to give
+ them a chance to provide you with an updated version of the
+ Document.
+ </para>
+ <bridgehead id="Modifications" renderas="sect1">
+ 4. MODIFICATIONS
+ </bridgehead>
+ <para>
+ You may copy and distribute a Modified Version of the Document under the
+ conditions of sections 2 and 3 above, provided that you release the
+ Modified Version under precisely this License, with the Modified Version
+ filling the role of the Document, thus licensing distribution and
+ modification of the Modified Version to whoever possesses a copy of it.
+ In addition, you must do these things in the Modified Version:
+ </para>
+ <orderedlist numeration="upperalpha">
+ <listitem>
+ <simpara>
+ Use in the Title Page (and on the covers, if any) a title distinct
+ from that of the Document, and from those of previous versions (which
+ should, if there were any, be listed in the History section of the
+ Document). You may use the same title as a previous version if the
+ original publisher of that version gives permission.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ List on the Title Page, as authors, one or more persons or entities
+ responsible for authorship of the modifications in the Modified
+ Version, together with at least five of the principal authors of the
+ Document (all of its principal authors, if it has fewer than five),
+ unless they release you from this requirement.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ State on the Title page the name of the publisher of the Modified
+ Version, as the publisher.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve all the copyright notices of the Document.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Add an appropriate copyright notice for your modifications adjacent to
+ the other copyright notices.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Include, immediately after the copyright notices, a license notice
+ giving the public permission to use the Modified Version under the
+ terms of this License, in the form shown in the Addendum below.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve in that license notice the full lists of Invariant Sections
+ and required Cover Texts given in the Document's license notice.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Include an unaltered copy of this License.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve the section Entitled "History", Preserve its Title, and add
+ to it an item stating at least the title, year, new authors, and
+ publisher of the Modified Version as given on the Title Page. If
+ there is no section Entitled "History" in the Document, create one
+ stating the title, year, authors, and publisher of the Document as
+ given on its Title Page, then add an item describing the Modified
+ Version as stated in the previous sentence.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve the network location, if any, given in the Document for
+ public access to a Transparent copy of the Document, and likewise the
+ network locations given in the Document for previous versions it was
+ based on. These may be placed in the "History" section. You may omit
+ a network location for a work that was published at least four years
+ before the Document itself, or if the original publisher of the
+ version it refers to gives permission.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ For any section Entitled "Acknowledgements" or "Dedications", Preserve
+ the Title of the section, and preserve in the section all the
+ substance and tone of each of the contributor acknowledgements and/or
+ dedications given therein.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve all the Invariant Sections of the Document, unaltered in
+ their text and in their titles. Section numbers or the equivalent are
+ not considered part of the section titles.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Delete any section Entitled "Endorsements". Such a section may not be
+ included in the Modified Version.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Do not retitle any existing section to be Entitled "Endorsements" or
+ to conflict in title with any Invariant Section.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve any Warranty Disclaimers.
+ </simpara>
+ </listitem>
+ </orderedlist>
+ <para>
+ If the Modified Version includes new front-matter sections or appendices
+ that qualify as Secondary Sections and contain no material copied from the
+ Document, you may at your option designate some or all of these sections
+ as invariant. To do this, add their titles to the list of Invariant
+ Sections in the Modified Version's license notice. These titles must be
+ distinct from any other section titles.
+ </para>
+ <para>
+ You may add a section Entitled "Endorsements", provided it contains
+ nothing but endorsements of your Modified Version by various parties--for
+ example, statements of peer review or that the text has been approved by
+ an organization as the authoritative definition of a standard.
+ </para>
+ <para>
+ You may add a passage of up to five words as a Front-Cover Text, and a
+ passage of up to 25 words as a Back-Cover Text, to the end of the list of
+ Cover Texts in the Modified Version. Only one passage of Front-Cover Text
+ and one of Back-Cover Text may be added by (or through arrangements made
+ by) any one entity. If the Document already includes a cover text for the
+ same cover, previously added by you or by arrangement made by the same
+ entity you are acting on behalf of, you may not add another; but you may
+ replace the old one, on explicit permission from the previous publisher
+ that added the old one.
+ </para>
+ <para>
+ The author(s) and publisher(s) of the Document do not by this License give
+ permission to use their names for publicity for or to assert or imply
+ endorsement of any Modified Version.
+ </para>
+ <bridgehead id="Combining" renderas="sect1">
+ 5. COMBINING DOCUMENTS
+ </bridgehead>
+ <para>
+ You may combine the Document with other documents released under this
+ License, under the terms defined in section 4 above for modified versions,
+ provided that you include in the combination all of the Invariant Sections
+ of all of the original documents, unmodified, and list them all as
+ Invariant Sections of your combined work in its license notice, and that
+ you preserve all their Warranty Disclaimers.
+ </para>
+ <para>
+ The combined work need only contain one copy of this License, and multiple
+ identical Invariant Sections may be replaced with a single copy. If there
+ are multiple Invariant Sections with the same name but different contents,
+ make the title of each such section unique by adding at the end of it, in
+ parentheses, the name of the original author or publisher of that section
+ if known, or else a unique number. Make the same adjustment to the
+ section titles in the list of Invariant Sections in the license notice of
+ the combined work.
+ </para>
+ <para>
+ In the combination, you must combine any sections Entitled "History" in
+ the various original documents, forming one section Entitled "History";
+ likewise combine any sections Entitled "Acknowledgements", and any
+ sections Entitled "Dedications". You must delete all sections Entitled
+ "Endorsements".
+ </para>
+ <bridgehead id="Collections" renderas="sect1">
+ 6. COLLECTIONS OF DOCUMENTS
+ </bridgehead>
+ <para>
+ You may make a collection consisting of the Document and other documents
+ released under this License, and replace the individual copies of this
+ License in the various documents with a single copy that is included in
+ the collection, provided that you follow the rules of this License for
+ verbatim copying of each of the documents in all other respects.
+ </para>
+ <para>
+ You may extract a single document from such a collection, and distribute
+ it individually under this License, provided you insert a copy of this
+ License into the extracted document, and follow this License in all other
+ respects regarding verbatim copying of that document.
+ </para>
+ <bridgehead id="Aggregation" renderas="sect1">
+ 7. AGGREGATION WITH INDEPENDENT WORKS
+ </bridgehead>
+ <para>
+ A compilation of the Document or its derivatives with other separate and
+ independent documents or works, in or on a volume of a storage or
+ distribution medium, is called an "aggregate" if the copyright resulting
+ from the compilation is not used to limit the legal rights of the
+ compilation's users beyond what the individual works permit. When the
+ Document is included in an aggregate, this License does not apply to the
+ other works in the aggregate which are not themselves derivative works of
+ the Document.
+ </para>
+ <para>
+ If the Cover Text requirement of section 3 is applicable to these copies
+ of the Document, then if the Document is less than one half of the entire
+ aggregate, the Document's Cover Texts may be placed on covers that bracket
+ the Document within the aggregate, or the electronic equivalent of covers
+ if the Document is in electronic form. Otherwise they must appear on
+ printed covers that bracket the whole aggregate.
+ </para>
+ <bridgehead id="Translation" renderas="sect1">
+ 8. TRANSLATION
+ </bridgehead>
+ <para>
+ Translation is considered a kind of modification, so you may distribute
+ translations of the Document under the terms of section 4. Replacing
+ Invariant Sections with translations requires special permission from
+ their copyright holders, but you may include translations of some or all
+ Invariant Sections in addition to the original versions of these Invariant
+ Sections. You may include a translation of this License, and all the
+ license notices in the Document, and any Warranty Disclaimers, provided
+ that you also include the original English version of this License and the
+ original versions of those notices and disclaimers. In case of a
+ disagreement between the translation and the original version of this
+ License or a notice or disclaimer, the original version will prevail.
+ </para>
+ <para>
+ If a section in the Document is Entitled "Acknowledgements",
+ "Dedications", or "History", the requirement (section 4) to Preserve its
+ Title (section 1) will typically require changing the actual title.
+ </para>
+ <bridgehead id="Termination" renderas="sect1">
+ 9. TERMINATION
+ </bridgehead>
+ <para>
+ You may not copy, modify, sublicense, or distribute the Document except as
+ expressly provided for under this License. Any other attempt to copy,
+ modify, sublicense or distribute the Document is void, and will
+ automatically terminate your rights under this License. However, parties
+ who have received copies, or rights, from you under this License will not
+ have their licenses terminated so long as such parties remain in full
+ compliance.
+ </para>
+ <bridgehead id="FutureRevisions" renderas="sect1">
+ 10. FUTURE REVISIONS OF THIS LICENSE
+ </bridgehead>
+ <para>
+ The Free Software Foundation may publish new, revised versions of the GNU
+ Free Documentation License from time to time. Such new versions will be
+ similar in spirit to the present version, but may differ in detail to
+ address new problems or concerns. See <ulink
+ url="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</ulink>.
+ </para>
+ <para>
+ Each version of the License is given a distinguishing version number. If
+ the Document specifies that a particular numbered version of this License
+ "or any later version" applies to it, you have the option of following the
+ terms and conditions either of that specified version or of any later
+ version that has been published (not as a draft) by the Free Software
+ Foundation. If the Document does not specify a version number of this
+ License, you may choose any version ever published (not as a draft) by the
+ Free Software Foundation.
+ </para>
+ <bridgehead id="HowToUse" renderas="sect1">
+ ADDENDUM: How to use this License for your documents
+ </bridgehead>
+ <para>
+ To use this License in a document you have written, include a copy of the
+ License in the document and put the following copyright and license
+ notices just after the title page:
+ </para>
+ <blockquote>
+ <para>
+ Copyright (C) YEAR YOUR NAME.
+ </para>
+ <para>
+ Permission is granted to copy, distribute and/or modify this document
+ under the terms of the GNU Free Documentation License, Version 1.2 or
+ any later version published by the Free Software Foundation; with no
+ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
+ copy of the license is included in the section entitled "GNU Free
+ Documentation License".
+ </para>
+ </blockquote>
+ <para>
+ If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+ replace the "with...Texts." line with this:
+ </para>
+ <blockquote>
+ <para>
+ with the Invariant Sections being LIST THEIR TITLES, with the
+ Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
+ </para>
+ </blockquote>
+ <para>
+ If you have Invariant Sections without Cover Texts, or some other
+ combination of the three, merge those two alternatives to suit the
+ situation.
+ </para>
+ <para>
+ If your document contains nontrivial examples of program code, we
+ recommend releasing these examples in parallel under your choice of free
+ software license, such as the GNU General Public License, to permit their
+ use in free software.
+ </para>
+</appendix>
+
+</article>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:t
+sgml-shorttag:t
+sgml-namecase-general:t
+sgml-general-insert-case:lower
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:nil
+sgml-parent-document:nil
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+-->
projects / fspm_howto / blobdiff