fix typo in makefile
[fspm_howto] / FreeSoftwareProjectManagementHOWTO.sgml
1
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
3
4 <article>
5
6 <!-- Header -->
7
8  <artheader>
9   <title>Free Software Project Management HOWTO</title>
10   
11   <author>
12    <firstname>Benjamin</firstname>
13    <othername>Mako</othername>
14    <surname>Hill</surname>
15    <affiliation>
16     <address>
17       <email>mako@atdot.cc</email>
18     </address>
19    </affiliation>
20   </author>
21
22   <revhistory>
23    <revision>
24     <revnumber>v0.3.4</revnumber>
25     <date>22 December 2009</date>
26    <authorinitials>bmh</authorinitials>
27    </revision>
28    
29    <revision>
30     <revnumber>v0.3.3</revnumber>
31     <date>22 August 2008</date>
32    <authorinitials>bmh</authorinitials>
33    </revision>
34   
35   <revision>
36     <revnumber>v0.3.2</revnumber>
37     <date>15 April 2002</date>
38    <authorinitials>bmh</authorinitials>
39    </revision>
40
41    <revision>
42     <revnumber>v0.3.1</revnumber>
43     <date>18 June 2001</date>
44     <authorinitials>bmh</authorinitials>
45    </revision>
46
47    <revision>
48     <revnumber>v0.3</revnumber>
49     <date>5 May 2001</date>
50     <authorinitials>bmh</authorinitials>
51    </revision>
52
53    <revision>
54     <revnumber>v0.2.1</revnumber>
55     <date>10 April 2001</date>
56     <authorinitials>bmh</authorinitials>
57    </revision>
58
59    <revision>
60     <revnumber>v0.2</revnumber>
61     <date>8 April 2001</date>
62     <authorinitials>bmh</authorinitials>
63    </revision>
64
65    <revision>
66     <revnumber>v0.01</revnumber>
67     <date>27 March 2001</date>
68     <authorinitials>bmh</authorinitials>
69     <revremark>Initial Release</revremark>
70    </revision>
71   </revhistory>
72
73   <abstract>
74    <indexterm>
75     <primary>fswd</primary>
76    </indexterm>
77    
78    <para>
79     This HOWTO is designed for people with experience in programming
80     and some skills in managing a software project but who are new to
81     the world of free software. This document is meant to act as a
82     guide to the non-technical aspects of free software project
83     management and was written to be a crash course in the people
84     skills that aren't taught to commercial coders but that can make
85     or break a free software project.
86    </para>
87   </abstract>
88   
89  </artheader>
90
91 <!-- Section1: intro -->
92
93  <sect1 id="intro">
94   <title>Introduction</title>
95   
96   <indexterm>
97    <primary>fswd!introduction</primary>
98   </indexterm>
99   
100   <para>
101    Skimming through freshmeat.net provides mountains of reasons for this
102    HOWTO's existence--the Internet is littered with excellently
103    written and useful programs that have faded away into the universe
104    of free software forgottenness. This dismal scene made me ask
105    myself, "Why?"
106   </para>
107
108   <para>
109    This HOWTO tries to do a lot of things (probably too many), but it
110    can't answer that question and won't attempt it. What this HOWTO
111    will attempt to do is give your Free Software project a fighting
112    chance--an edge. If you write a piece of crap that no one is
113    interested in, you can read this HOWTO until you can recite it in
114    your sleep and your project will probably fail. Then again, you can
115    write a beautiful, relevant piece of software and follow every
116    instruction in this HOWTO and your software may still not make
117    it. Sometimes life is like that. However, I'll go out a limb and
118    say that if you write a great, relevant pieces of software and
119    ignore the advise in this HOWTO, you'll probably fail <emphasis>
120    more often</emphasis>.
121   </para>
122
123   <para>
124    A lot of the information in this HOWTO is best called common
125    sense. Of course, as any debate on interfaces will prove, what is
126    common sense to some programmers proves totally unintuitive to
127    others. After explaining bits and pieces of this HOWTO to Free
128    Software developers on several occasions, I realized that writing
129    this HOWTO might provide a useful resource and a forum for
130    programmers to share ideas about what has and has not worked for
131    them.
132   </para>
133
134   <para>
135    As anyone involved in any of what seems like an unending parade of
136    ridiculous intellectual property clashes will attest to, a little
137    bit of legalese proves important.
138   </para>
139
140 <!-- Section2: copyright -->
141
142   <sect2 id="copyright">
143    <title>Copyright Information</title>
144
145    <para>
146     This document is copyrighted (c) 2000-2008 Benjamin Mako Hill and is
147     distributed under the terms of the <citetitle>GNU Free
148     Documentation License</citetitle>.
149    </para>
150
151     <para>
152      Permission is granted to copy, distribute and/or modify this
153      document under the terms of the <link
154      linkend="fdl"><citetitle>GNU Free Documentation
155      License</citetitle></link>, Version 1.2 or any later version
156      published by the Free Software Foundation with no Invariant
157      Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy
158      of the license can be found in <xref linkend="fdl">.
159     </para>
160   </sect2>
161
162 <!-- Section2: disclaimer -->
163
164   <sect2 id="disclaimer">
165    <title>Disclaimer</title>
166
167    <para>
168     No liability for the contents of this documents can be accepted.
169     Use the concepts, examples and other content at your own risk.  As
170     this is a new edition of this document, there may be errors and
171     inaccuracies, that may of course be damaging to your project (and
172     potentially your system).  Proceed with caution, and although this
173     is highly unlikely, the author(s) does not take any responsibility
174     for that.
175    </para>
176
177    <para>
178     All copyrights are held by their by their respective owners, unless
179     specifically noted otherwise.  Use of a term in this document
180     should not be regarded as affecting the validity of any trademark
181     or service mark.
182    </para>
183
184    <para>
185     Naming of particular products or brands should not be seen 
186     as endorsements.
187    </para>
188
189   </sect2>
190
191 <!-- Section2: newversions-->
192
193   <sect2 id="newversions">
194    <title>New Versions</title>
195
196    <para>
197     This version is the part of the third pre-release cycle of this
198     HOWTO. It is written to be released to developers for critique and
199     brainstorming. While the HOWTO is now several years old, please keep
200     in mind that this version of the HOWTO is still in an "early" stage
201     and will continue to be revised extensively.
202    </para>
203
204    <para>
205     The latest version number of this document should always be listed
206     on <ulink url="http://mako.cc/projects/howto">the projects
207     homepage</ulink>.
208    </para>
209
210    <para>
211     The newest version of this HOWTO will always be made available at
212     the same website, in a variety of formats:
213    </para>
214
215    <para>
216    <itemizedlist>
217
218     <listitem>
219      <para>
220       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO/t1.html">HTML</ulink>.
221      </para>
222     </listitem>
223
224
225     <listitem>
226      <para>
227       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.
228      </para>
229     </listitem>
230
231     <listitem>
232      <para>
233       <ulink URL="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.
234      </para>
235     </listitem>
236
237     <listitem>
238      <para>
239       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.
240      </para>
241     </listitem>
242
243     <listitem>
244      <para>
245       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.
246      </para>
247     </listitem>
248    </itemizedlist>
249    </para>
250   </sect2>
251
252 <!-- Section2: credits -->
253
254   <sect2 id="credits">
255    <title>Credits</title>
256
257    <para>
258     In this version I have the pleasure of acknowledging:
259    </para>
260
261    <para>Fellow Debian developers Martin Michlmayr and Vivek
262    Venugopalan who sent me information and links to extremely
263    interesting articles. I've added both to the bibliography and I've
264    added information from each into the HOWTO. Thanks to Andrew Shugg
265    who pointed out several errors in the document. Also, a big thanks
266    to Sung Wook Her (AKA RedBaron) who is doing the first translation
267    of the HOWTO into Korean. I've been happy to see that people have
268    enjoyed and benefited from the HOWTO so far.</para>
269
270    <para>
271     Older thanks that I don't want to take out yet include: Josh
272     Crawford, Andy King, and Jaime Davila who all read through this in
273     entirety and gave me feedback that has helped me make changes and
274     improvements to this document. I can't thank you guys enough for
275     your help. An extra <quote>Thank You</quote> goes to Andy King who
276     who read through this several times and submitted patches to make
277     life easier for me.
278    </para>
279
280    <para>
281     Karl Fogel, the author of <citetitle>Open Source Development with
282     CVS</citetitle> published by the Coriolis Open Press. Large parts
283     of his book are available <ulink
284     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
285     the book are available under the GPL and constitute the best
286     tutorial on CVS I've ever seen. The rest of the book covers,
287     <quote>the challenges and philosophical issues inherent in running
288     an Open Source project using CVS.</quote> The book does a good job
289     of covering some of the subjects brought up in this HOWTO and much
290     more. <ulink url="http://cvsbook.red-bean.com">The book's
291     website</ulink> has information on ordering the book and provides
292     several translations of the chapters on CVS. If you are seriously
293     interested in running a Free Software project, you want this
294     book. I tried to mention Fogel in sections of this HOWTO where I
295     knew I was borrowing directly from his ideas. If I missed any, I'm
296     sorry. I'll try and have those fixed in future versions.
297    </para>
298    
299    <para>
300     Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
301     com</email>
302    </para>
303
304    <para>
305     Also providing support material, and inspiration for this HOWTO is
306     Eric S. Raymond for his prolific, consistent, and carefully
307     crafted arguments and Lawrence Lessig for reminding me of the
308     importance of Free Software. Additionally, I want to thank every
309     user and developer involved with the <ulink
310     url="http://www.debian.org">Debian Project</ulink>. The project
311     has provided me with a home, a place to practice free software
312     advocacy, a place to make a difference, a place to learn from
313     those who have been involved with the movement much longer than I,
314     and proof of a free software project that definitely, definitely
315     works.
316    </para>
317
318    <para>
319     Above all, I want to thank <emphasis>Richard Stallman</emphasis>
320     for his work at the Free Software Foundation and for never giving
321     up. Stallman provides and articulates the philosophical basis that
322     attracts me to free software and that drives me toward writing a
323     document to make sure it succeeds. RMS can always be emailed at
324     <email>rms (at) gnu (dot) org</email>.
325    </para>
326
327   </sect2>
328
329 <!-- Section2: feedback -->
330
331   <sect2 id="feedback">
332    <title>Feedback</title>
333
334    <para>
335     Feedback is always and most certainly welcome for this
336     document. Without your submissions and input, this document
337     wouldn't exist. Do you feel that something is missing? Don't
338     hesitate to contact me to have me write a chapter, section, or
339     subsection or to write one yourself. I want this document to be a
340     product of the Free Software development process that it heralds
341     and I believe that its ultimate success will be rooted in its
342     ability to do this. Please send your additions, comments, and
343     criticisms to the following email address:
344     <email>mako@atdot.cc</email>.
345    </para>
346    </sect2>
347
348 <!-- Section2: translations -->
349
350   <sect2 id="translations">
351    <title>Translations</title>
352
353    <para>
354     I know that not everyone speaks English. Translations are nice and
355     I'd love for this HOWTO to gain the kind of international reach
356     afforded by translated versions.
357    </para>
358
359    <para>
360     This HOWTO has graciously been translated into German by Robert F.
361     Schmitt.  That copy is accessible in the following formats:
362    </para>
363
364    <itemizedlist>
365     <listitem>
366      <para>
367       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.DE.html">HTML (single page)</ulink>.
368      </para>
369     </listitem>
370
371     <listitem>
372      <para>
373       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.DE.rst">Restructured Text Source</ulink>.
374      </para>
375     </listitem>
376    </itemizedlist>
377
378    <para>
379     It has also been translated into Spanish (Castilian) by Isidro
380     Fuentes Hermoso. That copy is accessible in the following formats:
381    </para>
382
383    <itemizedlist>
384     <listitem>
385      <para>
386       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.ES.pdf">PDF</ulink>.
387      </para>
388     </listitem>
389
390     <listitem>
391      <para>
392       <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.ES.odt">Open Document Format</ulink>.
393      </para>
394     </listitem>
395    </itemizedlist>
396
397    <para>
398     If you would like to help with or do a translation, you will gain my
399     utmost respect and admiration and you'll get to be part of a cool
400     process. If you are at all interested, please don't hesitate to
401     contact me at: <email>mako@atdot.cc</email>.
402    </para>
403    </sect2>
404  </sect1>
405
406 <!-- Section1: intro: END -->
407
408 <!-- Section1: starting -->
409
410  <sect1 id="starting">
411   <title>Starting a Project</title>
412
413    <indexterm>
414     <primary>fswd!starting</primary>
415    </indexterm>
416   <para>
417    With very little argument, the beginning is the most difficult
418    period in a project's life to do successful free software project
419    management. Laying a firm foundation will determine whether your
420    project flourishes or withers away and dies. It is also the subject
421    that is of most immediate interest to anyone reading this document
422    as a tutorial.
423   </para>
424
425   <para>
426    Starting a project involves a dilemma that you as a developer must
427    try and deal with: no potential user for your program is interested
428    in a program that doesn't work, while the development process that
429    you want to employ holds involvement of users as imperative.
430   </para>
431
432   <para>
433    It is in these dangerous initial moments that anyone working to
434    start a free software project must try and strike a balance along
435    these lines. One of the most important ways that someone trying to
436    start a project can work toward this balance is by establishing a
437    solid framework for the development process through some of the
438    suggestions mentioned in this section.
439   </para>
440
441
442 <!-- Section2: chooseproject-->
443
444   <sect2 id="chooseproject">
445    <title>Choosing a Project</title>
446
447    <para>
448     If you are reading this document, there's a good chance you
449     already have an idea for a project in mind. Chances are also
450     pretty good that it fills a perceived gap by doing something that
451     no other free software project does or by doing something in a way
452     that is unique enough to necessitate a brand new piece of
453     software.
454    </para>
455
456    <sect3 id=identifyidea>
457     <title>Identify and articulate your idea</title>
458     <para>
459      Eric S. Raymond writes about how free software projects start in
460      his essay, <ulink
461      url="http://catb.org/~esr/writings/cathedral-bazaar/"><quote>The
462      Cathedral and the Bazaar,</quote></ulink> which comes as required
463      reading for any free software developer. It is available online .
464     </para>
465
466     <para>
467      In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
468      that: <quote>every good work of software starts by scratching
469      a developers itch.</quote> Raymond's now widely accepted
470      hypothesis is that new free software programs are written, first
471      and foremost, to solve a specific problem facing the developer.
472     </para>
473
474     <para>
475      If you have an idea for a program in mind, chances are good that
476      it targets a specific problem or <quote>itch</quote> you want to
477      see scratched. <emphasis>This idea is the project.</emphasis>
478      Articulate it clearly. Write it out. Describe the problem you
479      will attack in detail. The success of your project in tackling a
480      particular problem will be tied to your ability to identify that
481      problem clearly early on. Find out exactly what it is that you
482      want your project to do.
483     </para>
484
485     <para>
486      Monty Manley articulates the importance of this initial step in
487      an essay, <quote><ulink
488      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
489      Projects the Open Source Way.</ulink></quote> As the next section
490      will show, there is <emphasis>a lot</emphasis> of work that needs
491      to be done before software is even ready to be coded. Manley
492      says, <quote>Beginning an OSS project properly means that a
493      developer must, first and foremost, avoid writing code too
494      soon!</quote>
495     </para>
496    </sect3>
497
498    <sect3 id=evalulateidea>
499     <title>Evaluate your idea</title>
500
501     <para>
502      In evaluating your idea, you need to first ask yourself a few
503      questions.  This should happen before you move any further
504      through this HOWTO. Ask yourself: <emphasis>Is the free software
505      development model really the right one for your
506      project?</emphasis>
507     </para>
508
509     <para>
510      Obviously, since the program scratches your itch, you are
511      definitely interested in seeing it implemented in code. But,
512      because one hacker coding in solitude fails to qualify as a free
513      software development effort, you need to ask yourself a second
514      question: <emphasis>Is anybody else interested?</emphasis>
515     </para>
516
517     <para>
518      Sometimes the answer is a simple <quote>no.</quote> If you want
519      to write a set of scripts to sort <emphasis>your</emphasis>
520      <acronym>MP3</acronym> collection on <emphasis>your</emphasis>
521      machine, <emphasis>maybe</emphasis> the free software development
522      model is not the best one to choose. However, if you want to
523      write a set of scripts to sort <emphasis>anyone's</emphasis>
524      <acronym>MP3</acronym>s, a free software project might fill a
525      useful gap.
526     </para>
527
528     <para>
529      Luckily, the Internet is a place so big and so diverse that,
530      chances are, there is someone, somewhere, who shares your
531      interests and who feels the same <quote>itch.</quote> It is the
532      fact that there are so many people with so many similar needs and
533      desires that introduces the third major question: <emphasis>Has
534      somebody already had your idea or a reasonably similar
535      one?</emphasis>
536     </para>
537
538      <sect4 id=evalwhere>
539       <title>Finding Similar Projects</title>
540
541      <para>
542       There are places you can go on the web to try and answer the
543       question above. If you have experience with the free software
544       community, you are probably already familiar with many of these
545       sites. All of the resources listed below offer searching of
546       their databases:
547      </para>
548
549      <para>
550      <variablelist>
551        <varlistentry>
552         <term>freshmeat.net</term>
553         <listitem>
554          <para><ulink url="http://freshmeat.net">freshmeat.net</ulink>
555          describes itself as, <quote>the Web's largest index of Linux
556          and Open Source software</quote> and its reputation along
557          these lines is totally unparalleled and unquestioned. If you
558          can't find it on freshmeat, its doubtful that you (or anyone
559          else) will find it at all.</para>
560         </listitem>
561        </varlistentry>
562
563        <varlistentry>
564         <term>Slashdot</term>
565         <listitem>
566          <para><ulink url="http://slashdot.org">Slashdot</ulink>
567          provides <quote>News for Nerds. Stuff that matters,</quote>
568          which usually includes discussion of free software, open
569          source, technology, and geek culture news and events. It is
570          not unusual for a particularly sexy development effort to be
571          announced here, so it is definitely worth checking.</para>
572         </listitem>
573        </varlistentry>
574
575        <varlistentry>
576         <term>SourceForge</term>
577         <listitem>
578          <para><ulink url="http://sourceforge.net">SourceForge</ulink>
579          houses and facilitates a growing number of open source and
580          free software projects. It is also quickly becoming a nexus
581          and a necessary stop for free software
582          developers. SourceForge's <ulink
583          url="http://sourceforge.net/softwaremap/trove_list.php">software
584          map</ulink> and <ulink url="http://sourceforge.net/new/"> new
585          release</ulink> pages should be necessary stops before
586          embarking on a new free software project. SourceForge also
587          provides a <ulink
588          url="http://sourceforge.net/snippet/">Code Snippet
589          Library</ulink> which contains useful reusable chunks of code
590          in an array of languages which can come in useful in any
591          project.</para>
592         </listitem>
593        </varlistentry>
594
595        <varlistentry>
596         <term>Google and Google's Linux Search</term>
597         <listitem>
598          <para><ulink url="http://www.google.com">Google</ulink> and
599          <ulink url="http://www.google.com/linux"> Google's Linux
600          Search</ulink>, provides powerful web searches that may reveal
601          people working on similar projects. It is not a catalog of
602          software or news like freshmeat or Slashdot, but it is worth
603          checking to make sure you aren't pouring your effort into a
604          redundant project.</para>
605         </listitem>
606        </varlistentry>
607
608       </variablelist>
609      </para>
610     </sect4>
611
612     <sect4 id=evalhow>
613      <title>Deciding to Proceed</title>
614      <para>
615       Once you have successfully charted the terrain and have an idea
616       about what kinds of similar free software projects exist, every
617       developer needs to decide whether to proceed with their own
618       project. It is rare that a new project seeks to accomplish a
619       goal that is not at all similar or related to the goal of
620       another project. Anyone starting a new project needs to ask
621       themselves: <quote>Will the new project be duplicating work done
622       by another project? Will the new project be competing for
623       developers with an existing project? Can the goals of the new
624       project be accomplished by adding functionality to an existing
625       project?</quote>
626      </para>
627
628      <para>
629       If the answer to any of these questions is <quote>yes,</quote>
630       try to contact the developer of the existing project(s) in
631       question and see if he or she might be willing to collaborate
632       with you.
633      </para>
634
635      <para>
636       For many developers this may be the single most difficult aspect
637       of free software project management, but it is an essential one. It is
638       easy to become fired up by an idea and get caught up in the
639       momentum and excitement of a new project. It is often extremely
640       difficult to do, but it is important that any free software
641       developer remembers that the best interests of the free software
642       community and the quickest way to accomplish your own project's
643       goals and the goals of similar projects can often be
644       accomplished by <emphasis>not</emphasis> starting a new
645       development effort.
646      </para>
647
648     </sect4>
649    </sect3>
650   </sect2>
651
652 <!-- Section2: naming-->
653
654   <sect2 id="naming">
655    <title>Naming your project</title>
656
657    <para>
658     While there are plenty of projects that fail with descriptive
659     names and plenty that succeed without them, I think naming your
660     project is worth giving a bit of thought. Leslie Orchard tackles
661     this issue in an <ulink
662     url="http://www.advogato.org/article/67.html">Advogato
663     article</ulink>. His article is short and definitely worth looking
664     over quickly.
665    </para>
666
667    <para>
668     The synopsis is that Orchard recommends you pick a name where,
669     after hearing the name, many users or developers will both:
670    </para>
671
672    <para>
673     <itemizedlist>
674      <listitem>
675       <para>Know what the project does.</para>
676      </listitem>
677      <listitem>
678       <para>Remember it tomorrow.</para>
679      </listitem>
680     </itemizedlist>
681    </para>
682
683    <para>
684     Humorously, Orchard's project, <quote>Iajitsu,</quote> does
685     neither. It is probably unrelated that development has effectively
686     frozen since the article was written.
687    </para>
688
689    <para>
690     He makes a good point though. There are companies whose only job
691     is to make names for pieces of software. They make
692     <emphasis>ridiculous</emphasis> amount of money doing it and are
693     supposedly worth it. While you probably can't afford a company like
694     this, you can afford to learn from their existence and think a
695     little bit about the name you are giving your project because it
696     <emphasis>does</emphasis> matter.
697    </para>
698
699    <para>
700     If there is a name you really want but it doesn't fit Orchard's
701     criteria, you can still go ahead. I thought <quote>gnubile</quote>
702     was one of the best I'd heard for a free software project ever and
703     I still talk about it long after I've stopped using the
704     program. However, if you can be flexible on the subject, listen to
705     Orchard's advice. It might help you.
706    </para>
707   </sect2>
708
709 <!-- Section2: licensing-->
710
711   <sect2 id="licensing">
712    <title>Licensing your Software</title>
713    
714    <para>
715     On one (somewhat simplistic) level, the difference between a piece
716     of free software and a piece of propriety software is the
717     license. A license helps you as the developer by protecting your
718     legal rights to have your software distributed under your terms
719     and helps demonstrate to those who wish to help you or your
720     project that they are encouraged to join.
721    </para>
722    
723    <sect3 id="chooselicense">
724     <title>Choosing a license</title>
725
726     <para>
727      Any discussion of licenses is also sure to generate at least a
728      small flame war as there are strong feelings that some free
729      software licenses are better than others. This discussion also
730      brings up the question of <quote>Open Source Software</quote> and
731      the debate over the terms <quote>Open Source Software</quote> and
732      <quote>Free Software</quote>. However, because I've written the
733      Free Software Project Management HOWTO and not the Open Source
734      Software Project Management HOWTO, my own allegiances in this
735      argument are in the open.
736     </para>
737
738     <para>
739      In attempting to reach a middle ground through diplomacy without
740      sacrificing my own philosophy, I will recommend picking any
741      license that conforms to the <ulink
742      url="http://www.debian.org/social_contract">Debian Free Software
743      Guidelines</ulink>. Originally compiled by the Debian project
744      under Bruce Perens, the <acronym>DFSG</acronym> forms the first
745      version of the <ulink
746      url="http://www.opensource.org/docs/definition_plain.html">Open
747      Source Definition.</ulink> Examples of free licenses given by the
748      <acronym>DFSG</acronym> are the <acronym>GPL</acronym>, the
749      <acronym>BSD</acronym>, and the Artistic License. As ESR mentions
750      in his his HOWTO<xref linkend="esrhowto">, don't write your own
751      license if at all possible. The three licenses I mention all have
752      long interpretive traditions. They are also definitely free
753      software (and can therefore be distributed as part of Debian and
754      in other places that permit the transfer of free software).
755     </para>
756
757     <para>
758      Conforming to the definition of free software offered by Richard
759      Stallman in <ulink
760      url="http://www.gnu.org/philosophy/free-sw.html"><quote>The Free
761      Software Definition</quote></ulink>, any of these licenses will
762      uphold, <quote>users' freedom to run, copy, distribute, study,
763      change and improve the software.</quote> There are plenty of
764      other licenses that also conform to the <acronym>DFSG</acronym>
765      but sticking with a more well-known license will offer the
766      advantage of immediate recognition and understanding.</para>
767
768     <para>
769      In attempting a more in-depth analysis, I agree with Karl Fogel's
770      description of licenses as falling into two groups: those that
771      are the <acronym>GPL</acronym> and those that are not the
772      <acronym>GPL</acronym>.
773     </para>
774
775     <para>
776      Personally, I license all my software under the
777      <acronym>GPL</acronym>. Created and protected by the Free
778      Software Foundation and the GNU Project, the
779      <acronym>GPL</acronym> is the license for the Linux kernel,
780      GNOME, Emacs, and the vast majority of GNU/Linux software. It's
781      the obvious choice but I also believe it is a good one. Any BSD
782      fanatic will urge you to remember that there is a viral aspect to
783      the <acronym>GPL</acronym> that prevents the mixture of
784      <acronym>GPL</acronym>'ed code with non-<acronym>GPL</acronym>'ed
785      code. To many people (myself included), this is a benefit, but to
786      some, it is a major drawback.
787     </para>
788
789     <para>
790      Many people write three or four sentences in a COPYING file and
791      assume that they have written a free software license--as my long
792      experience with the debian-legal mailing professes, this is very
793      often not the case. It may not protect you, it may not protect
794      your software, and it may make things very difficult for people
795      that want to use your software but who pay a lot of attention to
796      the subtle legal points of licenses. If you are passionate about
797      a home-brewed license, run it by either people at <ulink
798      url="http://www.opensource.org">OSI</ulink> or the <ulink
799      url="mailto:debian-devel@lists.debian.org">debian-legal mailing
800      list</ulink> first protect yourself from unanticipated
801      side-effects of your license.
802     </para>
803
804     <para>
805      The three major licenses can be found at the following locations:
806     </para>
807
808     <para>
809      <itemizedlist>
810       <listitem>
811        <para><ulink url="http://www.gnu.org/copyleft/gpl.html">The GNU
812        General Public License</ulink></para>
813       </listitem>
814       <listitem>
815        <para><ulink url="http://www.debian.org/misc/bsd.license">The
816        BSD License</ulink></para>
817       </listitem>
818       <listitem>
819        <para><ulink
820        url="http://language.perl.com/misc/Artistic.html">The Artistic
821        License</ulink></para>
822       </listitem>
823      </itemizedlist>
824     </para>
825
826     <para>
827      <emphasis>In any case, please read through any license before
828      your release your software under it. As the primary developer,
829      you can't afford any license surprises.</emphasis>
830     </para>
831    </sect3>
832
833    <sect3 id="licensechoose">
834     <title>The mechanics of licensing</title>
835
836     <para>
837      The text of the <acronym>GPL</acronym> offers <ulink
838      url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
839      description of the mechanics of applying a license</ulink> to a
840      piece of software. My quick checklist for applying a license
841      includes:
842     </para>
843
844     <para>
845      <itemizedlist>
846      
847       <listitem>
848        <para>Make yourself or the FSF the copyright holder for the
849        work. In a few rare cases, you might want to make a sponsoring
850        organization (if it's big and powerful enough) the copyright
851        holder instead. Doing this is as simple as putting the name in
852        the blank when you modify the notice of copyright
853        below. Contrary to popular belief, you don't need to file with
854        any organization. The notice alone is enough to copyright your
855        work.</para>
856       </listitem>
857
858       <listitem>
859        <para>If at all possible, attach and distribute a full copy of
860        the license with the source and binary by including a separate
861        file.</para>
862       </listitem>
863
864       <listitem>
865        <para>At the top of each source file in your program, attach a
866        notice of copyright and include information on where the full
867        license can be found. The <acronym>GPL</acronym> recommends
868        that each file begin with:</para>
869
870        <screen>
871 <emphasis>one line to give the program's name and an idea of what it does.</emphasis>
872 Copyright (C) yyyy  name of author
873
874 This program is free software; you can redistribute it and/or
875 modify it under the terms of the GNU General Public License
876 as published by the Free Software Foundation; either version 2
877 of the License, or (at your option) any later version.
878
879 This program is distributed in the hope that it will be useful,
880 but WITHOUT ANY WARRANTY; without even the implied warranty of
881 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
882 GNU General Public License for more details.
883
884 You should have received a copy of the GNU General Public License
885 along with this program; if not, write to the Free Software
886 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
887        </screen>
888
889        <para>
890         The <acronym>GPL</acronym> goes on to recommend attaching
891         information on methods for contacting you (the author) via
892         email or physical mail.
893       </para>
894       </listitem>
895
896       <listitem>
897        <para>
898         The <acronym>GPL</acronym> continues and suggests that if your
899         program runs in an interactive mode, you should write the
900         program to output a notice each time it enters interactive
901         mode that includes a message like this one that points to full
902         information about the programs license:
903        </para>
904
905        <screen>
906 Gnomovision version 69, Copyright (C) year name of author
907 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
908 type `show w'.  This is free software, and you are welcome
909 to redistribute it under certain conditions; type `show c' 
910 for details.
911        </screen>
912       </listitem>
913
914       <listitem>
915        <para>Finally, it might be helpful to include a
916        <quote>copyright disclaimer</quote> from an employer or a
917        school if you work as a programmer or if it seems like your
918        employer or school might be able to make an argument for
919        ownership of your code later on. These aren't often needed but
920        there are plenty of free software developers who have gotten
921        into trouble and wish they'd asked for one.</para>
922       </listitem>
923
924      </itemizedlist>
925     </para>    
926    </sect3>
927
928    <sect3 id="licensewarning">
929     <title>Final license warning</title>
930
931     <para>
932      Please, please, please, place your software under
933      <emphasis>some</emphasis> license. It may not seem important, and
934      to you it may not be, but licenses <emphasis>are</emphasis>
935      important. For a piece of software to be included in the Debian
936      GNU/Linux distribution, it must have a license that fits the
937      <ulink url="http://www.debian.org/social_contract">Debian Free
938      Software Guidelines</ulink>. If your software has no license, it
939      can not be distributed as a package in Debian until you
940      re-release it under a free license. Please save yourself and
941      others trouble by releasing the first version of your software
942      with a clear license.
943     </para>
944
945    </sect3>
946
947  </sect2>
948
949 <!-- Section2: chooseversioning-->
950
951   <sect2 id="chooseversioning">
952    <title>Choosing a Method of Version Numbering</title>
953
954    <para>
955     <emphasis>The most important thing about a system of version
956     numbering is that there is one.</emphasis> It may seem pedantic to
957     emphasize this point but you'd be surprised at the number of
958     scripts and small programs that pop up without any version number
959     at all.
960    </para>
961
962    <para>
963     <emphasis>The second most important thing about a system of
964     numbering is that the numbers always go up.</emphasis> Automatic
965     version tracking systems and people's sense of order in the
966     universe will fall apart if version numbers don't rise. It doesn't
967     <emphasis>really</emphasis> matter if 2.1 is a big jump and
968     2.0.005 is a small jump but it does matter that 2.1 is more recent
969     than 2.0.005.
970    </para>
971
972    <para>
973     Follow these two simple rules and you will not go (too)
974     wrong. Beyond this, the most common technique seems to be the
975     <quote>major level,</quote> <quote>minor level,</quote>
976     <quote>patch level</quote> version numbering scheme. Whether you
977     are familiar with the name or not, you interact with it all the
978     time. The first number is the major number and it signifies major
979     changes or rewrites. The second number is the minor number and it
980     represents added or tweaked functionality on top of a largely
981     coherent structure. The third number is the patch number and it
982     usually will only refer to releases fixing bugs.
983    </para>
984
985    <para>
986     The widespread use of this scheme is why I know the nature and
987     relative degree in the differences between a 2.4.12 release of the
988     Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowing
989     anything about any of the releases.
990    </para>
991
992    <para>
993     You can bend or break these rules, and people do. But beware, if
994     you choose to, someone will get annoyed, assume you don't know,
995     and try and educate you, probably not nicely. I always follow this
996     method and I implore you to do so as well.
997    </para>
998    
999    <para>
1000     There are several version numbering systems that are well known,
1001     useful, and that might be worth looking into before you release
1002     your first version.
1003    </para>
1004
1005    <variablelist>
1006     <varlistentry>
1007      <term>Linux kernel version numbering:</term>
1008      <listitem>
1009       <para>The Linux kernel uses a versioning system where any odd
1010       minor version number refers to an development or testing release
1011       and any even minor version number refers to a stable
1012       version. Think about it for a second. Under this system, 2.1 and
1013       2.3 kernels were and always will be development or testing
1014       kernels and 2.0, 2.2. and 2.4 kernels are all production code
1015       with a higher degree of stability and more testing.
1016      </para>
1017
1018       <para>
1019        Whether you plan on having a split development model (as
1020        described in <xref linkend="branches">) or only one version
1021        released at a time, my experience with several free software
1022        projects and with the Debian project has taught me that use of
1023        Linux's version numbering system is worth taking into
1024        consideration. In Debian, <emphasis>all</emphasis> minor
1025        versions are stable distributions (2.0, 2.1, etc). However,
1026        many people assume that 2.1 is an unstable or development
1027        version and continue to use an older version until they get so
1028        frustrated with the lack of development progress that they
1029        complain and figure the system out. If you never release an odd
1030        minor version but only release even ones, nobody is hurt, and
1031        less people are confused. It's an idea worth taking into
1032        consideration.
1033       </para>
1034      </listitem>
1035     </varlistentry>
1036
1037     <varlistentry>
1038      <term>Wine version numbering:</term>
1039      <listitem>
1040       <para>Because of the unusual nature of wine's development where
1041       the not-emulator is constantly improving but not working toward
1042       any immediately achievable goal, wine is released every three
1043       weeks. Wine does this by labeling their releases in <quote>Year
1044       Month Day</quote> format where each release might be labeled
1045       <quote>wine-XXXXXXXX</quote> where the version from January 04,
1046       2000 would be <quote>wine-20000104</quote>. For certain
1047       projects, <quote>Year Month Day</quote> format can make a lot of
1048       sense.
1049       </para>
1050      </listitem>
1051     </varlistentry>
1052
1053     <varlistentry>
1054      <term>Mozilla milestones:</term>
1055      <listitem>
1056       <para>When one considers Netscape 6 and vendor versions, the
1057       mozilla's project development structure is one of the most
1058       complex free software models available. The project's version
1059       numbering has reflected the unique situation in which it is
1060       developed.
1061       </para>
1062
1063       <para>
1064        Mozilla's version numbering structure has historically been
1065        made up of milestones. From the beginning of the mozilla
1066        project, the goals of the project in the order and degree to
1067        which they were to be achieved were charted out on a series of
1068        <ulink url="http://www.mozilla.org/roadmap.html">road
1069        maps</ulink>. Major points and achievements along these
1070        road-maps were marked as milestones. Therefore, although
1071        Mozilla was built and distributed nightly as <quote>nightly
1072        builds,</quote> on a day when the goals of a milestone on the
1073        road-map had been reached, that particular build was marked as
1074        a <quote>milestone release.</quote>
1075       </para>
1076
1077       <para>
1078        While I haven't seen this method employed in any other projects
1079        to date, I like the idea and think that it might have value in
1080        any testing or development branch of a large application under
1081        heavy development.
1082       </para>
1083      </listitem>
1084     </varlistentry>
1085
1086    </variablelist>
1087   </sect2>
1088
1089 <!-- Section2: documentation-->
1090
1091   <sect2 id="documentation">
1092    <title>Documentation</title>
1093
1094    <para>
1095     A huge number of otherwise fantastic free software applications
1096     have withered and died because their author was the only person
1097     who knew how to use them fully. Even if your program is written
1098     primarily for a techno-savvy group of users, documentation is
1099     helpful and even necessary for the survival of your project. You
1100     will learn later in <xref linkend="releasing"> that you should
1101     always release something that is usable. <emphasis>A piece of
1102     software without documentation is not usable.</emphasis>
1103    </para>
1104
1105    <para>
1106     There are lots of different people you should document for and
1107     there are lots of ways to document your project. <emphasis>The
1108     importance of documentation in source code to help facilitate
1109     development by a large community is vital</emphasis> but it falls
1110     outside the scope of this HOWTO. This being the case, this section
1111     deals with useful tactics for user-directed documentation.
1112    </para>
1113
1114    <para>
1115     A combination of tradition and necessity has resulted in a
1116     semi-regular system of documentation in most free software
1117     projects that is worth following. Both users and developers expect
1118     to be able to get documentation in several ways and it's essential
1119     that you provide the information they are seeking in a form they
1120     can read if your project is ever going to get off the
1121     ground. People have come to expect:
1122    </para>
1123
1124    <sect3>
1125     <title>Man pages</title> 
1126
1127     <para>Your users will want to be able to type <quote>man
1128     yourprojectname</quote> end up with a nicely formatted man page
1129     highlighting the basic use of your application. Make sure that
1130     before you release your program, you've planned for this.
1131     </para>
1132
1133     <para>
1134      Man pages are not difficult to write. There is excellent
1135      documentation on the man page writing process available through
1136      the <quote>The Linux Man-Page-HOWTO</quote> which is available
1137      through the Linux Documentation project <acronym>(LDP)</acronym>
1138      and is written by Jens Schweikhardt. It is available <ulink
1139      url="http://www.schweikhardt.net/man_page_howto.html">from
1140      Schweikhardt's site</ulink>.
1141     </para>
1142
1143     <para>
1144      It is also possible to write man pages using DocBook
1145      SGML. Because man pages are so simple and the DocBook method
1146      relatively new, I have not been able to follow this up but would
1147      love help from anyone who can give me more information on how
1148      exactly how this is done.
1149     </para>
1150    </sect3>
1151
1152    <sect3>
1153     <title>Command line accessible documentation</title>
1154
1155     <para>
1156      Most users will expect some basic amount of documentation to be
1157      easily available from the command line. For few programs should
1158      this type of documentation extend for more than one screen (24 or
1159      25 lines) but it should cover the basic usage, a brief (one or
1160      two sentence) description of the program, a list of the commands
1161      with explanations, as well as all the major options (also with
1162      explanations), plus a pointer to more in-depth documentation for
1163      those who need it. The command line documentation for Debian's
1164      apt-get serves as an excellent example and a useful model:
1165     </para>
1166
1167     <screen>
1168 apt 0.3.19 for i386 compiled on May 12 2000  21:17:27
1169 Usage: apt-get [options] command
1170        apt-get [options] install pkg1 [pkg2 ...]
1171
1172 apt-get is a simple command line interface for downloading and
1173 installing packages. The most frequently used commands are update
1174 and install.
1175
1176 Commands:
1177    update - Retrieve new lists of packages
1178    upgrade - Perform an upgrade
1179    install - Install new packages (pkg is libc6 not libc6.deb)
1180    remove - Remove packages
1181    source - Download source archives
1182    dist-upgrade - Distribution upgrade, see apt-get(8)
1183    dselect-upgrade - Follow dselect selections
1184    clean - Erase downloaded archive files
1185    autoclean - Erase old downloaded archive files
1186    check - Verify that there are no broken dependencies
1187
1188 Options:
1189   -h  This help text.
1190   -q  Loggable output - no progress indicator
1191   -qq No output except for errors
1192   -d  Download only - do NOT install or unpack archives
1193   -s  No-act. Perform ordering simulation
1194   -y  Assume Yes to all queries and do not prompt
1195   -f  Attempt to continue if the integrity check fails
1196   -m  Attempt to continue if archives are unlocatable
1197   -u  Show a list of upgraded packages as well
1198   -b  Build the source package after fetching it
1199   -c=? Read this configuration file
1200   -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
1201 See the apt-get(8), sources.list(5) and apt.conf(5) manual
1202 pages for more information and options.
1203     </screen>
1204
1205     <para>
1206      It has become a GNU convention to make this type of information
1207      accessible with the <quote>-h</quote> and the
1208      <quote>--help</quote> options. Most GNU/Linux users will expect
1209      to be able to retrieve basic documentation these ways so if you
1210      choose to use different methods, be prepared for the flames and
1211      fallout that may result.
1212     </para>
1213    </sect3>
1214
1215    <sect3>
1216     <title>Files users will expect</title>
1217     <para>
1218      In addition to man pages and command-line help, there are certain
1219      files where people will look for documentation, especially in any
1220      package containing source code. In a source distribution, most of
1221      these files can be stored in the root directory of the source
1222      distribution or in a subdirectory of the root called
1223      <quote>doc</quote> or <quote>Documentation.</quote> Common files
1224      in these places include:
1225     </para>
1226
1227     <para>
1228      <variablelist>
1229       <varlistentry>
1230        <term>README or Readme</term>
1231
1232        <listitem>
1233         <para>A document containing all the basic installation,
1234         compilation, and even basic use instructions that make up the
1235         bare minimum information needed to get the program up and
1236         running. A README is not your chance to be verbose but should
1237         be concise and effective. An ideal README is at least 30 lines
1238         long and more no more than 250.</para>
1239        </listitem>
1240
1241       </varlistentry>
1242       <varlistentry>
1243        <term>INSTALL or Install</term>
1244
1245        <listitem>
1246         <para>The INSTALL file should be much shorter than the README
1247         file and should quickly and concisely describe how to build
1248         and install the program. Usually an INSTALL file simply
1249         instructs the user to run <quote>./configure; make; make
1250         install</quote> and touches on any unusual options or actions
1251         that may be necessary. For most relatively standard install
1252         procedures and for most programs, INSTALL files are as short
1253         as possible and are rarely over 100 lines.</para>
1254        </listitem>
1255
1256       </varlistentry>
1257       <varlistentry>
1258        <term>CHANGELOG, Changelog, ChangeLog, or changelog</term>
1259
1260        <listitem>
1261         <para>A CHANGELOG is a simple file that every well-managed
1262         free software project should include. A CHANGELOG is simple
1263         the file that, as its name implies, logs or documents the
1264         changes you make to your program. The most simple way to
1265         maintain a CHANGELOG is to simply keep a file with the source
1266         code for your program and add a section to the top of the
1267         CHANGELOG with each release describing what has been changed,
1268         fixed, or added to the program. It's a good idea to post the
1269         CHANGELOG onto the website as well because it can help people
1270         decide whether they want or need to upgrade to a newer version
1271         or wait for a more significant improvement.</para>
1272        </listitem>
1273
1274       </varlistentry>
1275       <varlistentry>
1276        <term>NEWS</term>
1277
1278        <listitem>
1279         <para>A NEWS file and a ChangeLog are similar. Unlike a
1280         CHANGELOG, a NEWS file is not typically updated with new
1281         versions. Whenever new features are added, the developer
1282         responsible will make a note in the NEWS file. NEWS files
1283         should not have to be changed before a release (they should be
1284         kept up to date all along) but it's usually a good idea to
1285         check first anyway because often developers just forget to
1286         keep them as current as they should.</para>
1287        </listitem>
1288
1289       </varlistentry>
1290       <varlistentry>
1291        <term><acronym>FAQ</acronym></term>
1292
1293        <listitem>
1294         <para>For those of you that don't already know,
1295         <acronym>FAQ</acronym> stands for Frequently Asked Questions
1296         and a FAQ is a collection of exactly that. FAQs are not
1297         difficult to make. Simply make a policy that if you are asked
1298         a question or see a question on a mailing list two or more
1299         times, add the question (and its answer) to your FAQ. FAQs are
1300         more optional than the files listed above but they can save
1301         your time, increase usability, and decrease headaches on all
1302         sides.</para>
1303        </listitem>
1304
1305       </varlistentry>
1306      </variablelist>
1307     </para>
1308    </sect3>
1309
1310    <sect3>
1311     <title>Website</title> 
1312     <para>
1313      It's only indirectly an issue of documentation but a good website
1314      is quickly becoming an essential part of any free software
1315      project. Your website should provide access to your documentation
1316      (in <acronym>HTML</acronym> if possible). It should also include
1317      a section for news and events around your program and a section
1318      that details the process of getting involved with development or
1319      testing and make an open invitation. It should also supply links
1320      to any mailing lists, similar websites, and provide a direct link
1321      to all the available ways of downloading your software.
1322     </para>
1323    </sect3>
1324
1325    <sect3>
1326     <title>Other documentation hints</title>
1327
1328     <itemizedlist>
1329      <listitem>
1330       <para>
1331         All your documentation should be in plaintext, or, in cases
1332         where it is on your website primarily, in HTML. Everyone can
1333         cat a file, everyone has a pager, (almost) everyone can render
1334         HTML. <emphasis>You are welcome to distribute information in
1335         PDF, PostScript, RTF, or any number of other widely used
1336         formats but this information must also be available in
1337         plaintext or HTML or people will be very angry at
1338         you.</emphasis> In my opinion, info falls into this category
1339         as well. There is plenty of great GNU documentation that
1340         people simply don't read because it only in info. And this
1341         <emphasis>does</emphasis> make people angry. It's not a
1342         question of superior formats; it is a question of
1343         accessability and the status quo plays a huge role in this
1344         determination.
1345       </para>
1346      </listitem>
1347
1348      <listitem>
1349       <para>
1350        It doesn't hurt to distribute any documentation for your
1351        program from your website (FAQs etc) with your program. Don't
1352        hesitate to throw any of this in the program's tarball. If
1353        people don't need it, they will delete it. I can repeat it over
1354        and over: <emphasis>Too much documentation is not a
1355        sin.</emphasis>
1356       </para>
1357      </listitem>
1358
1359      <listitem>
1360       <para>Unless your software is particular to a non-English
1361       language (a Japanese language editor for example), please
1362       distribute it with English language documentation. If you don't
1363       speak English or not not confident in your skills, ask a friend
1364       for help. Like it or not, fair or unfair, <emphasis>English is
1365       the language of free software</emphasis>. However, this does not
1366       mean you should limit your documentation to only English. If you
1367       speak another language, distribute translations of documentation
1368       with your software if you have the time and energy to do
1369       so. They will invariably be useful to someone.</para>
1370      </listitem>
1371
1372      <listitem>
1373       <para>
1374        Finally, <emphasis>please spell-check your
1375        documentation.</emphasis> Misspellings in documentation are
1376        bugs. I'm very guilty of committing this error and it's
1377        extremely easy to do. If English is not your first language,
1378        have a native speaker look over or edit your documentation or
1379        web pages. Poor spelling or grammar goes a long way to making
1380        your code look unprofessional. In code comments, this type of
1381        thing is less important but in man pages and web pages these
1382        mistakes are not acceptable.
1383       </para>
1384      </listitem>
1385
1386     </itemizedlist>
1387
1388
1389    </sect3>
1390   </sect2>
1391
1392 <!-- Section2: presentation -->
1393
1394   <sect2 id="presentation">
1395    <title>Other Presentation Issues</title>
1396    <para>
1397     Many of the remaining issues surrounding the creation of a new
1398     free software program fall under what most people describe as
1399     common sense issues. Its often said that software engineering is
1400     90 percent common sense combined with 10 percent specialized
1401     knowledge. Still, they are worth noting briefly in hopes that they
1402     may remind a developer of something they may have forgotten.
1403    </para>
1404
1405    <sect3>
1406     <title>Package File Names</title> 
1407     <para>
1408      I agree with ESR when he says that: <quote> It's helpful to
1409      everybody if your archive files all have GNU-like names --
1410      all-lower-case alphanumeric stem prefix, followed by a dash,
1411      followed by a version number, extension, and other
1412      suffixes.</quote> There is more info (including lots of examples
1413      of what <emphasis>not</emphasis> to do in his <citetitle>Software
1414      Release Practices HOWTO</citetitle> which is included in this
1415      HOWTO's bibliography and can be found through the LDP.
1416     </para>
1417    </sect3>
1418
1419    <sect3>
1420     <title>Package formats</title>
1421     <para>
1422      Package formats may differ depending on the system you are
1423      developing for. For windows based software, Zip archives (.zip)
1424      usually serve as the package format of choice. If you are
1425      developing for GNU/Linux, *BSD, or any UN*X, make sure that your
1426      source code is always available in tar'ed and gzip'ed format
1427      (.tar.gz). UNIX compress (.Z) has gone out of style and
1428      usefulness and faster computers have brought bzip2 (.bz2) into
1429      the spot-light as a more effective compression medium. I now make
1430      all my releases available in both gzip'ed and bzip2'ed tarballs.
1431     </para>
1432
1433     <para>
1434      Binary packages should always be distribution specific. If you
1435      can build binary packages against a current version of a major
1436      distribution, you will only make your users happy. Try to foster
1437      relationships with users or developers of large distributions to
1438      develop a system for the consistent creation of binary
1439      packages. It's often a good idea to provide RedHat
1440      <acronym>RPM</acronym>'s (.rpm), Debian deb's (.deb) and source
1441      <acronym>RPM</acronym>'s <acronym>SRPM</acronym>'s if
1442      possible. Remember: <emphasis>While these binaries packages are
1443      nice, getting the source packaged and released should always be
1444      your priority. Your users or fellow developers can and will do
1445      the the binary packages for you.</emphasis>
1446     </para>
1447    </sect3>
1448
1449    <sect3>
1450     <title>Version control systems</title>
1451
1452     <para>
1453      A version control system can make a lot of these problems of
1454      packaging (and a lot of other problems mentioned in this HOWTO)
1455      less problematic. If you are using *NIX, CVS is your best bet. I
1456      recommend Karl Fogel's book on the subject (and the <ulink
1457      url="http://cvsbook.red-bean.com/">posted HTML version</ulink>)
1458      wholeheartedly.
1459     </para>
1460
1461     <para>
1462      CVS or not, you should probably invest some time into learning
1463      about a version control system because it provides an automated
1464      way of solving many of the problems described by this HOWTO.  I
1465      am not aware of any free version control systems for Windows or
1466      Mac OS but I know that CVS clients exist for both
1467      platforms. Websites like <ulink
1468      url="http://sourceforge.net">SourceForge</ulink> do a great job
1469      as well with a nice, easy-to-use web interface to CVS.
1470     </para>
1471
1472     <para>
1473      I'd love to devote more space in this HOWTO to CVS because I love
1474      it (I even use CVS to keep versions straight on this HOWTO!) but
1475      I think it falls outside the scope of this document and already
1476      has its own HOWTOs. Most notably is the <citetitle>CVS Best
1477      Practices HOWTO</citetitle><xref linkend="cvsbestpractices">
1478      which I've included in the attached bibliography.
1479     </para>
1480
1481    </sect3>
1482
1483    <sect3>
1484     <title>Useful tidbits and presentation hints</title>
1485
1486     <para>
1487      Other useful hints include:
1488     </para>
1489
1490     <para>
1491      <itemizedlist>
1492
1493       <listitem>
1494        <para>
1495         <emphasis>Make sure that your program can always be found in a
1496         single location.</emphasis> Often this means that you have a
1497         single directory accessible via <acronym>FTP</acronym> or the
1498         web where the newest version can be quickly recognized. One
1499         effective technique is a provide a symlink called
1500         <quote>yourprojectname-latest</quote> that is always pointing
1501         to the most recent released or development version of your
1502         free software application. Keep in mind that this location
1503         will receive many requests for downloads around releases so
1504         make sure that the server you choose has adequate bandwidth.
1505        </para>
1506       </listitem>
1507
1508       <listitem>
1509        <para>
1510         <emphasis>Make sure that there is a consistent email address
1511         for bug reports.</emphasis> It's usually a good idea to make
1512         this something that is NOT your primary email address like
1513         yourprojectname@host or yourprojectname-bugs@host. This way,
1514         if you ever decide to hand over maintainership or if your
1515         email address changes, you simply need to change where this
1516         email address forwards. It also will allow for more than one
1517         person to deal with the influx of mail that is created if your
1518         project becomes as huge as you hope it will.
1519        </para>
1520       </listitem>
1521
1522      </itemizedlist>
1523     </para>
1524    </sect3>
1525   </sect2>
1526  </sect1>
1527
1528 <!-- Section1: starting: END -->
1529
1530 <!-- Section1: developers -->
1531
1532  <sect1 id="developers">
1533   <title>Maintaining a Project: Interacting with Developers</title>
1534   <indexterm>
1535    <primary>fswd!developers</primary>
1536   </indexterm>
1537
1538   <para>
1539    Once you have gotten your project started, you have overcome the
1540    most difficult hurdles in the development process of your
1541    program. Laying a firm foundation is essential, but the development
1542    process itself is equally important and provides just as many
1543    opportunities for failure. In the next two sections, I will
1544    describe running a project by discussing how to maintain a
1545    development effort through interactions with developers and with
1546    users.
1547   </para>
1548
1549   <para>
1550    In releasing your program, your program becomes free software. This
1551    transition is more than just a larger user base. By releasing your
1552    program as free software, <emphasis>your</emphasis> software
1553    becomes the <emphasis>free software community's</emphasis>
1554    software. The direction of your software's development will be
1555    reshaped, redirected, and fully determined by your users and, to a
1556    larger extent, by other developers in the community.
1557   </para>
1558
1559   <para>
1560    The major difference between free software development and
1561    propriety software development is the developer base. As the leader
1562    of a free software project, you need to attract and keep developers
1563    in a way that leaders of proprietary software projects simply don't
1564    have to worry about. <emphasis>As the person leading development of
1565    a free software project, you must harness the work of fellow
1566    developers by making responsible decisions and by responsibly
1567    choosing not to make decisions. You have to direct developers
1568    without being overbearing or bossy. You need to strive to earn
1569    respect and never forget to give it out.</emphasis>
1570   </para>
1571
1572 <!-- Section2: delegation  -->
1573
1574   <sect2 id="delegation">
1575    <title>Delegating Work</title>
1576
1577    <para>
1578     By now, you've hypothetically followed me through the early
1579     programming of a piece of software, the creation of a website and
1580     system of documentation, and we've gone ahead and (as will be
1581     discussed in <xref linkend="releasing">) released it to the rest
1582     of the world. Times passes, and if things go well, people become
1583     interested and want to help. The patches begin flowing in.
1584    </para>
1585
1586    <para>
1587     <emphasis>Like the parent of any child who grows up, it's now time
1588     to wince, smile and do most difficult thing in any parents
1589     life: It's time to let go.</emphasis>
1590    </para>
1591
1592    <para>
1593     Delegation is the political way of describing this process of
1594     <quote>letting go.</quote> It is the process of handing some of
1595     the responsibility and power over your project to other
1596     responsible and involved developers. It is difficult for anyone
1597     who has invested a large deal of time and energy into a project
1598     but it essential for the growth of any free software project. One
1599     person can only do so much. A free software project is nothing
1600     without the involvement of <emphasis>a group</emphasis> of
1601     developers. A group of developers can only be maintained through
1602     respectful and responsible leadership and delegation.
1603    </para>
1604
1605    <para>
1606     As your project progresses, you will notice people who are putting
1607     significant amounts of time and effort into your project. These
1608     will be the people submitting the most patches, posting most on
1609     the mailing lists, and engaging in long email discussions. It is
1610     your responsibility to contact these people and to try and shift
1611     some of the power and responsibility of your position as the
1612     project's maintainer onto them (if they want it). There are
1613     several easy ways you can do this:
1614    </para>
1615
1616    <para>
1617     In a bit of a disclaimer, delegation need not mean rule by
1618     committee. In many cases it does and this has been proven to
1619     work. In other cases this has created problems. <ulink
1620     url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
1621     Projects the Open Source Way</ulink> argues that <quote>OSS
1622     projects do best when one person is the clear leader of a team and
1623     makes the big decisions (design changes, release dates, and so
1624     on).</quote> I think this often true but would urge developers to
1625     consider the ideas that the project leader need not be the
1626     project's founder and that these important powers need not all rest
1627     with one person but that a release manager may be different than a
1628     lead developer. These situations are tricky politically so
1629     be careful and make sure it's necessary before you go around
1630     empowering people.
1631    </para>
1632
1633    <sect3>
1634     <title>How to delegate</title>
1635  
1636     <para>
1637      You may find that other developers seem even more experienced or
1638      knowledgeable than you. Your job as a maintainer does not mean
1639      you have to be the best or the brightest. It means you
1640      are responsible for showing good judgment and for
1641      recognizing which solutions are maintainable and which are not. 
1642     </para>
1643     <para>
1644      Like anything, its easier to watch others delegate than to do it
1645      yourself. In a sentence: <emphasis>Keep an eye out for other
1646      qualified developers who show an interest and sustained
1647      involvement with your project and try and shift responsibility
1648      toward them.</emphasis> The following ideas might be good places
1649      to start or good sources of inspiration:
1650     </para>
1651  
1652     <sect4>
1653      <title>Allow a larger group of people to have write access to your CVS
1654      repository and make real efforts toward rule by a
1655      committee</title>
1656
1657      <para>
1658       <ulink url="http://httpd.apache.org/">Apache</ulink> is an
1659       example of a project that is run by small group of developers
1660       who vote on major technical issues and the admission of new
1661       members and all have write access to the main source
1662       repository. Their process is detailed <ulink
1663       url="http://httpd.apache.org/ABOUT_APACHE.html">online.</ulink>
1664      </para>
1665
1666      <para>
1667       The <ulink url="http://www.debian.org/"> Debian Project</ulink>
1668       is an extreme example of rule by committee. At current count,
1669       more than 700 developers have full responsibility for
1670       aspects of the project. All these developers can upload into
1671       the main FTP server, and vote on major issues. Direction for
1672       the project is determined by the project's <ulink
1673       url="http://www.debian.org/social_contract">social
1674       contract</ulink> and a <ulink
1675       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
1676       facilitate this system, there are special teams (i.e. the
1677       install team, the Japanese language team) as well as a technical
1678       committee and a project leader. The leader's main responsibility
1679       is to, <quote>appoint delegates or delegate decisions to the
1680       Technical Committee.</quote>
1681      </para>
1682
1683      <para>
1684       While both of these projects operate on a scale that your
1685       project will not (at least initially), their example is
1686       helpful. Debian's idea of a project leader who can do
1687       <emphasis>nothing</emphasis> but delegate serves as a
1688       caricature of how a project can involve and empower a huge
1689       number of developers and grow to a huge size.
1690      </para>
1691
1692     </sect4>
1693
1694     <sect4 id="releasemanager">
1695      <title>Publicly appoint someone as the release manager for a
1696        specific release</title>
1697
1698      <para>
1699       A release manager is usually responsible for coordinating
1700       testing, enforcing a code freeze, being responsible for
1701       stability and quality control, packaging up the software, and
1702       placing it in the appropriate places to be downloaded.
1703      </para>
1704
1705      <para>
1706       This use of the release manager is a good way to give yourself a
1707       break and to shift the responsibility for accepting and
1708       rejecting patches onto someone else. It is a good way of very
1709       clearly defining a chunk of work on the project as belonging to
1710       a certain person and its a great way of giving yourself room to
1711       breath.
1712      </para>
1713     </sect4>
1714
1715     <sect4 id="delegatebranch">
1716      <title>Delegate control of an entire branch</title>
1717      <para>
1718       If your project chooses to have branches (as described in <xref
1719       linkend="branches">), it might be a good idea to appoint someone
1720       else to be the the head of a branch. If you like focusing your
1721       energy on development releases and the implementation of new
1722       features, hand total control over the stable releases to a
1723       well-suited developer.
1724      </para>
1725
1726      <para>
1727       The author of Linux, Linus Torvalds, came out and crowned Alan
1728       Cox as <quote>the man for stable kernels.</quote> All patches
1729       for stable kernels go to Alan and, if Linus were to be taken
1730       away from work on Linux for any reason, Alan Cox would be more
1731       than suited to fill his role as the acknowledged heir to the
1732       Linux maintainership.
1733      </para>
1734     </sect4>
1735    </sect3> 
1736   </sect2>
1737
1738 <!-- Section2: patching -->
1739
1740   <sect2 id="patching">
1741    <title>Accepting and Rejecting Patches</title>
1742    <para>
1743     This HOWTO has already touched on the fact that as the maintainer
1744     of a free software project, one of your primary and most important
1745     responsibilities will be accepting and rejecting patches submitted
1746     to you by other developers.
1747    </para>
1748
1749    <sect3>
1750     <title>Encouraging Good Patching</title>
1751
1752     <para>As the person managing or maintaining the project, you
1753     aren't the person who is going to be making a lot of
1754     patches. However, it's worth knowing about ESR's section on
1755     <citetitle>Good Patching Practice</citetitle> in the
1756     <citetitle>Software Release Practices HOWTO</citetitle><xref
1757     linkend="esrhowto">. I don't agree with ESR's claim that most ugly
1758     or undocumented patches are probably worth throwing out at first
1759     sight--this just hasn't been my experience, especially when
1760     dealing with bug fixes that often don't come in the form of
1761     patches at all. Of course, this doesn't mean that I
1762     <emphasis>like</emphasis> getting poorly done patches. If you get
1763     ugly -e patches, if you get totally undocumented patches, and
1764     especially if they are anything more than trivial bug-fixes, it
1765     might be worth judging the patch by some of the criteria in ESR's
1766     HOWTO and then throwing people the link to the document so they
1767     can do it the <quote>right way.</quote>
1768     </para>
1769
1770    </sect3>
1771
1772    <sect3>
1773     <title>Technical judgment</title>
1774
1775     <para>
1776      In <emphasis>Open Source Development with CVS</emphasis>, Karl
1777      Fogel makes a convincing argument that the most important things
1778      to keep in mind when rejecting or accepting patches are:
1779     </para>
1780
1781     <para>
1782      <itemizedlist>
1783
1784       <listitem>
1785        <para>A firm knowledge of the scope of your program (that's the
1786        <quote>idea</quote> I talked about in <xref linkend="chooseproject">);</para>
1787       </listitem>
1788       
1789       <listitem>
1790        <para>The ability to recognize, facilitate, and direct
1791        <quote>evolution</quote> of your program so that the program
1792        can grow and change and incorporate functionality that was
1793        originally unforeseen;</para>
1794       </listitem>
1795
1796       <listitem>
1797        <para>The necessity to avoid digressions that might expand the
1798        scope of the program too much and result and push the project
1799        toward an early death under its own weight and
1800        unwieldiness.</para>
1801       </listitem>
1802
1803      </itemizedlist>
1804     </para>
1805
1806     <para>
1807      These are the criteria that you as a project maintainer should
1808      take into account each time you receive a patch.
1809     </para>
1810
1811     <para>
1812      Fogel elaborates on this and states the <quote>the
1813      questions to ask yourself when considering whether to implement
1814      (or approve) a change are:</quote>
1815     </para>
1816
1817     <para>
1818      <itemizedlist>
1819
1820       <listitem>
1821        <para>Will it benefit a significant percentage of the program's
1822        user community?</para>
1823       </listitem>
1824
1825       <listitem>
1826        <para>Does it fit within the program's domain or within a
1827        natural, intuitive extension of that domain?</para>
1828       </listitem>
1829
1830      </itemizedlist>
1831     </para>
1832
1833     <para>
1834      The answers to these questions are never straightforward and its
1835      very possible (and even likely) that the person who submitted the
1836      patch may feel differently about the answer to these questions
1837      than you do. However, if you feel that that the answer to either
1838      of those questions is <quote>no,</quote> it is your responsibility
1839      to reject the change. If you fail to do this, the project will
1840      become unwieldy and unmaintainable and many ultimately fail.
1841     </para>
1842    </sect3>
1843
1844    <sect3>
1845     <title>Rejecting patches</title>
1846
1847     <para>
1848      Rejecting patches is probably the most difficult and sensitive
1849      job that the maintainer of any free software project has to
1850      face. But sometimes it has to be done. I mentioned earlier (in
1851      <xref linkend="developers"> and in <xref linkend="delegation">)
1852      that you need to try and balance your responsibility and power to
1853      make what you think are the best technical decisions with the
1854      fact that you will lose support from other developers if you seem
1855      like you are on a power trip or being overly bossy or possessive
1856      of the community's project. I recommend that you keep these three
1857      major concepts in mind when rejecting patches (or other changes):
1858     </para>
1859
1860     <sect4>
1861      <title>Bring it to the community</title>
1862      <para>
1863       One of the best ways of justifying a decision to reject a patch
1864       and working to not seem like you keep an iron grip on your
1865       project is by not making the decision alone at all. It might
1866       make sense to turn over larger proposed changes or more
1867       difficult decisions to a development mailing list where they can
1868       be discussed and debated. There will be some patches (bug fixes,
1869       etc.) which will definitely be accepted and some that you feel
1870       are so off base that they do not even merit further
1871       discussion. It is those that fall into the gray area between
1872       these two groups that might merit a quick forward to a mailing
1873       list.
1874      </para>
1875
1876      <para>
1877       I recommend this process wholeheartedly. As the project
1878       maintainer you are worried about making the best decision for
1879       the project, for the project's users and developers, and for
1880       yourself as a responsible project leader. Turning things over to
1881       an email list will demonstrate your own responsibility and
1882       responsive leadership as it tests and serves the interests of
1883       your software's community.
1884      </para>
1885     </sect4>
1886
1887     <sect4>
1888      <title>Technical issues are not always good justification</title>
1889      <para>
1890       Especially toward the beginning of your project's life, you
1891       will find that many changes are difficult to implement,
1892       introduce new bugs, or have other technical problems. Try to see
1893       past these. Especially with added functionality, good ideas do
1894       not always come from good programmers. Technical merit is a
1895       valid reason to postpone an application of a patch but it is not
1896       always a good reason to reject a change outright. Even small
1897       changes are worth the effort of working with the developer
1898       submitting the patch to iron out bugs and incorporate the change
1899       if you think it seems like a good addition to your project. The
1900       effort on your part will work to make your project a community
1901       project and it will pull a new or less experienced developer
1902       into your project and even teach them something that might help
1903       them in making their next patch.
1904      </para>
1905     </sect4>
1906
1907     <sect4>
1908      <title>Common courtesy</title>
1909      <para>
1910       It should go without saying but, <emphasis>above all and in all
1911       cases, just be nice.</emphasis> If someone has an idea and cares
1912       about it enough to write some code and submit a patch, they
1913       care, they are motivated, and they are already involved. Your
1914       goal as the maintainer is make sure they submit again. They may
1915       have thrown you a dud this time but next time may be the idea or
1916       feature that revolutionizes your project. 
1917      </para>
1918
1919      <para>
1920       It is your responsibility to first justify your choice to not
1921       incorporate their change clearly and concisely. Then thank
1922       them. Let them know that you a appreciate their help and feel
1923       horrible that you can't incorporate their change. Let them know
1924       that you look forward to their staying involved and you hope
1925       that the next patch or idea meshes better with your project
1926       because you appreciate their work and want to see it in your
1927       application. If you have ever had a patch rejected after putting
1928       a large deal of time, thought, and energy into it, you remember
1929       how it feels and it feels bad. Keep this in mind when you have
1930       to let someone down. It's never easy but you need to do
1931       everything you can to make it as not-unpleasant as possible.
1932      </para>
1933     </sect4>
1934    </sect3>
1935   </sect2>
1936
1937 <!-- Section2: branches  -->
1938
1939   <sect2 id="branches">
1940    <title>Stable and Development Branches</title>
1941
1942    <para>
1943     The idea of stable and development branches has already been
1944     described briefly in <xref linkend="chooseversioning"> and in
1945     <xref linkend="delegatebranch">. These allusions attest to some of
1946     the ways that multiple branches can affect your software. Branches
1947     can let you avoid (to some extent) some of the problems around
1948     rejecting patches (as described in <xref linkend="patching">) by
1949     allowing you to temporarily compromise the stability of your
1950     project without affecting those users who need that stability.
1951    </para>
1952
1953    <para>
1954     The most common way of branching your project is to have one
1955     branch that is stable and one that is for development. This is the
1956     model followed by the Linux kernel that is described in <xref
1957     linkend="chooseversioning">. In this model, there is
1958     <emphasis>always</emphasis> one branch that is stable and always
1959     one that is in development. Before any new release, the
1960     development branch goes into a <quote>feature freeze</quote> as
1961     described in <xref linkend="freezing"> where major changes and
1962     added features are rejected or put on hold under the development
1963     kernel is released as the new stable branch and major development
1964     resumes on the development branch. Bug fixes and small changes
1965     that are unlikely to have any large negative repercussions are
1966     incorporated into the stable branch as well as the development
1967     branch.
1968    </para>
1969
1970    <para>
1971     Linux's model provides an extreme example. On many projects, there is no
1972     need to have two versions constantly available. It may make sense to
1973     have two versions only near a release. The Debian project has
1974     historically made both a stable and an unstable distribution
1975     available but has expanded to this to include: stable, unstable,
1976     testing, experimental, and (around release time) a frozen
1977     distribution that only incorporates bug fixes during the
1978     transition from unstable to stable. There are few projects whose
1979     size would necessitate a system like Debian's but this use of
1980     branches helps demonstrate how they can be used to balance
1981     consistent and effective development with the need to make regular
1982     and usable releases.
1983    </para>
1984
1985    <para>
1986     In trying to set up a development tree for yourself, there are
1987     several things that might be useful to keep in mind:
1988    </para>
1989
1990    <para>
1991     <variablelist>
1992
1993      <varlistentry>
1994       <term>Minimize the number of branches</term>
1995       <listitem>
1996        <para>Debian may be able to make good use of four or five
1997        branches but it contains gigabytes of software in over 5000
1998        packages compiled for 5-6 different architectures. For you,
1999        two is probably a good ceiling. Too many branches will confuse
2000        your users (I can't count how many times I had to describe
2001        Debian's system when it only had 2 and sometimes 3 branches!),
2002        potential developers and even yourself. Branches can help but
2003        they come at a cost so use them very sparingly.</para>
2004       </listitem>
2005      </varlistentry>
2006
2007      <varlistentry>
2008       <term>Make sure that all your different branches are explained</term>
2009       <listitem>
2010        <para>As I mentioned in the preceding paragraph, different
2011        branches <emphasis>will</emphasis> confuse your users. Do
2012        everything you can to avoid this by clearly explaining the
2013        different branches in a prominent page on your website and in a
2014        README file in the <acronym>FTP</acronym> or
2015        web directory.</para>
2016
2017        <para>
2018         I might also recommend against a mistake that I think Debian
2019         has made. The terms <quote>unstable,</quote>
2020         <quote>testing,</quote> and <quote>experimental</quote> are
2021         vague and difficult to rank in order of stability (or
2022         instability as the case may be). Try explaining to someone
2023         that <quote>stable</quote> actually means <quote>ultra
2024         stable</quote> and that <quote>unstable</quote> doesn't
2025         actually include any unstable software but is really stable
2026         software that is untested as a distribution.
2027        </para>
2028
2029        <para>
2030         If you are going to use branches, especially early on, keep in
2031         mind that people are conditioned to understand the terms
2032         <quote>stable</quote> and <quote>development</quote> and you
2033         probably can't go wrong with this simple and common division of
2034         branches.
2035        </para>
2036       </listitem>
2037      </varlistentry>
2038
2039      <varlistentry>
2040       <term>Make sure all your branches are always available</term>
2041       <listitem>
2042        <para>Like a lot of this document, this should probably should
2043        go without saying but experience has taught me that it's not
2044        always obvious to people. It's a good idea to physically split
2045        up different branches into different directories or directory
2046        trees on your <acronym>FTP</acronym> or web site. Linux
2047        accomplishes this by having kernels in a v2.2 and a v2.3
2048        subdirectory where it is immediately obvious (after you know
2049        their version numbering scheme) which directory is for the most
2050        recent stable and the current development releases. Debian
2051        accomplishes this by naming all their distribution with names
2052        (i.e. woody, potato, etc.) and then changing symlinks named
2053        <quote>stable,</quote> <quote>unstable</quote> and
2054        <quote>frozen</quote> to point to which ever distribution (by
2055        name) is in whatever stage. Both methods work and there are
2056        others. In any case, it is important that different branches
2057        are always available, are accessible from consistent locations,
2058        and that different branches are clearly distinguished from each
2059        other so your users know exactly what they want and where to
2060        get it.</para>
2061       </listitem>
2062      </varlistentry>
2063
2064     </variablelist>
2065    </para>
2066
2067   </sect2>
2068
2069 <!-- Section2: otherdev -->
2070
2071   <sect2 id="otherdev">
2072    <title>Other Project Management issues</title>
2073    <para>
2074     There are more issues surrounding interaction with developers in a
2075     free software project that I can not touch on in great detail in a
2076     HOWTO of this size and scope. Please don't hesitate to contact me if you see
2077     any major omissions.
2078    </para>
2079
2080    <para>
2081      Other smaller issues that are worth mentioning are:
2082    </para>
2083
2084    <sect3 id="freezing">
2085     <title>Freezing</title>
2086     <para>
2087      For those projects that choose to adopt a split development model
2088      (<xref linkend="branches">), freezing is a concept that is worth
2089      becoming familiar with. 
2090     </para>
2091
2092     <para>
2093      Freezes come in two major forms. A <quote>feature freeze</quote>
2094      is a period when no significant functionality is added to a
2095      program. It is a period where established functionality (even
2096      skeletons of barely working functionality) can be improved and
2097      perfected. It is a period where bugs are fixed. This type of
2098      freeze is usually applied some period (a month or two) before a
2099      release. It is easy to push a release back as you wait for
2100      <quote>one more feature</quote> and a freeze helps to avoid this
2101      situation by drawing the much needed line in the sand. It gives
2102      developers room they need to get a program ready for release.
2103     </para>
2104
2105     <para>
2106      The second type of freeze is a <quote>code freeze</quote> which
2107      is much more like a released piece of software. Once a piece of
2108      software has entered a <quote>code freeze,</quote> all changes to
2109      the code are discouraged and only changes that fix known bugs
2110      are permitted. This type of freeze usually follows a
2111      <quote>feature freeze</quote> and directly precedes a
2112      release. Most released software is in what could be interpreted
2113      as a sort of high level <quote>code freeze.</quote>
2114     </para>
2115
2116     <para>
2117      Even if you never choose to appoint a release manager (<xref
2118      linkend="releasemanager">), you will have an easier time
2119      justifying the rejection or postponement of patches (<xref
2120      linkend="patching">) before a release with a publicly stated
2121      freeze in effect.
2122     </para>
2123    </sect3>
2124   </sect2>
2125
2126    <sect2>
2127     <title>Forks</title>
2128     <para>
2129      I wasn't sure about how I would deal with forking in this
2130      document (or if I would deal with forking at all). A fork is when
2131      a group of developers takes code from a free software project and
2132      actually starts a brand new free software project with it. The
2133      most famous example of a fork was between Emacs and XEmacs. Both
2134      emacsen are based on an identical code-base but for technical,
2135      political, and philosophical reasons, development was split into
2136      two projects which now compete with each other.
2137     </para>
2138
2139     <para>
2140      The short version of the fork section is, <emphasis>don't do
2141      them.</emphasis> Forks force developers to choose one project to
2142      work with, cause nasty political divisions, and redundancy of
2143      work.  Luckily, usually the threat of the fork is enough to scare
2144      the maintainer or maintainers of a project into changing the way
2145      they run their project.
2146     </para>
2147
2148     <para>
2149      In his chapter on <quote>The Open Source Process,</quote> Karl
2150      Fogel describes how to do a fork if you absolutely must. If you
2151      have determined that is absolutely necessary and that the
2152      differences between you and the people threatening to fork are
2153      absolutely unresolvable, I recommend Fogel's book as a good place
2154      to start.
2155     </para>
2156   </sect2>
2157  </sect1>
2158
2159 <!-- Section1: users -->
2160
2161  <sect1 id="users">
2162   <title>Maintaining a Project: Interacting with Users</title>
2163   <indexterm>
2164    <primary>fswd!users</primary>
2165   </indexterm>
2166
2167   <para>
2168    If you've worked your way up to here, congratulations, you are
2169    nearing the end of this document. This final section describes some
2170    of the situations in which you, in your capacity as project
2171    maintainer, will be interacting with users. It gives some
2172    suggestions on how these situations might be handled effectively.
2173   </para>
2174
2175   <para>
2176    Interacting with users is difficult. In our discussion of
2177    interaction with developers, the underlying assumption is that in a
2178    free software project, a project maintainer must constantly strive to
2179    attract and keep developers who can easily leave at any time.
2180   </para>
2181
2182   <para>
2183    Users in the free software community are different than developers
2184    and are also different than users in the world of proprietary
2185    software and they should be treated differently than either
2186    group. Some ways in which the groups differ significantly follow:
2187   </para>
2188
2189   <para>
2190    <itemizedlist>
2191
2192     <listitem>
2193      <para>The lines between users and developers are blurred in ways
2194      that is totally foreign to any proprietary development
2195      model. Your users are often your developers and vice
2196      versa.</para>
2197     </listitem>
2198
2199     <listitem>
2200      <para>In the free software world, you are often your users' only
2201      choice. Because there is such an emphasis on not replicating the
2202      work of others in the free software community and because the
2203      element of competition present in the propriety software model is
2204      absent (or at least in an extremely different form) in the free
2205      software development model, you will probably be the only project
2206      that does what you do (or at least the only one that does what
2207      you do in the way that you do it). This means your responsiveness
2208      to your users is even more important than in the proprietary
2209      software world.</para>
2210     </listitem>
2211
2212     <listitem>
2213      <para>In an almost paradoxical situation, free software projects
2214      have less immediate or dire consequences for ignoring their users
2215      altogether. It is also often easier to do. Because you don't
2216      usually need to compete with another product, chances are good
2217      that you will not be scrambling to gain the features of your
2218      competitor's newest program. This means that your development
2219      process will have to be directed either internally, by a
2220      commitment to your users, or through both.</para>
2221     </listitem>
2222    </itemizedlist>
2223   </para>
2224
2225   <para>
2226    Trying to tackle this unique situation can only be done
2227    indirectly. Developers and maintainers need to listen to users and
2228    to try and be as responsive as possible. A solid knowledge of the
2229    situation recounted above is any free software developer's best tool
2230    for shifting his development or leadership style to fit the unique
2231    process of free software project management. This chapters will try and
2232    introduce some of the more difficult or important points in any
2233    projects interactions with users and give some hints on how to
2234    tackle these.
2235   </para>
2236
2237 <!-- Section2: testing -->
2238
2239   <sect2 id="testing">
2240    <title>Testing and Testers</title>
2241
2242    <para>
2243     In addition to your users being your developers, they are also
2244     (and perhaps more commonly) your testers. Before I get flamed, I
2245     should rephrase my sentence: <emphasis>some of your
2246     users</emphasis> (those who explicitly volunteer) are your
2247     testers.
2248    </para>
2249
2250    <para>
2251     It is important that this distinction be made early on because not
2252     all of your users want to be testers. Many users want to use
2253     stable software and don't care if they don't have the newest,
2254     greatest software with the latest, greatest features. These users
2255     except a stable, tested piece of software without major or obvious
2256     bugs and will be angry if they find themselves testing. This is
2257     yet another way in which a split development model (as mentioned
2258     in <xref linkend="branches">) might come in handy.
2259    </para>
2260
2261    <para>
2262      <quote><ulink
2263      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
2264      Projects the Open Source Way</ulink></quote> describes what a
2265      good test should look for:
2266    </para>
2267
2268    <variablelist>
2269     <varlistentry>
2270      <term>Boundary conditions</term>
2271
2272      <listitem>
2273       <para>Maximum buffer lengths, data conversions, upper/lower
2274       boundary limits, and so on.</para>
2275      </listitem>
2276
2277     </varlistentry>
2278     <varlistentry>
2279      <term>Inappropriate behavior</term>
2280
2281      <listitem>
2282       <para>Its a good idea to find out what a program will do if a
2283       user hands it a value it isn't expecting, hits the wrong button,
2284       etc. Ask yourself a bunch of <quote>what if</quote> questions
2285       and think of anything that <emphasis>might</emphasis> fail or
2286       <emphasis>might</emphasis> go wrong and find out what your
2287       program would do in those cases.</para>
2288      </listitem>
2289
2290     </varlistentry>
2291     <varlistentry>
2292      <term>Graceful failure</term>
2293
2294      <listitem>
2295       <para>The answer to a number of the <quote>what if</quote>
2296       questions above is probably <quote>failure</quote> which is
2297       often the only answer. Now make sure that it happens
2298       nicely. Make sure that when it crashes, there is some indication
2299       of why it crashed or failed so that the user or developer
2300       understands whats going on.</para>
2301      </listitem>
2302
2303     </varlistentry>
2304
2305     <varlistentry>
2306      <term>Standards conformance</term>
2307
2308      <listitem>
2309       <para>If possible, make sure your programs conforms to
2310       standards. If it's interactive, don't be too creative with
2311       interfaces. If it is non-interactive, make sure it communicates
2312       over appropriate and established channels with other programs
2313       and with the rest of the system.</para>
2314      </listitem>
2315
2316     </varlistentry>
2317    </variablelist>
2318
2319    <sect3>
2320     <title>Automated testing</title>
2321     <para>
2322      For many programs, many common mistakes can be caught by
2323      automated means. Automated tests tend to be pretty good at
2324      catching errors that you've run into several times before or
2325      the things you just forget. They are not very good at finding
2326      errors, even major ones, that are totally unforeseen.
2327     </para>
2328
2329     <para>
2330      CVS comes with a Bourne shell script called sanity.sh that is
2331      worth looking at. Debian uses a program called lintian that
2332      checks Debian packages for all of the most common errors. While
2333      use of these scripts may not be helpful, there is a host of other
2334      sanity checking software on the net that may be applicable (feel
2335      free to email me any recommendations). None of these will create
2336      a bug-free release but they will avoid at least some major
2337      oversights. Finally, if your programs become a long term
2338      endeavor, you will find that there are certain errors that you
2339      tend to make over and over. Start a collection of scripts that
2340      check for these errors to help keep them out of future releases.
2341     </para>
2342    </sect3>
2343
2344    <sect3>
2345     <title>Testing by testers</title>
2346     <para>
2347      For any program that depends on user interactivity, many bugs
2348      will only be uncovered through testing by users actually clicking
2349      the keys and pressing the mouse buttons. For this you need
2350      testers and as many as possible.
2351     </para>
2352
2353     <para>
2354      The most difficult part of testing is finding testers. It's
2355      usually a good tactic to post a message to a relevant mailing
2356      list or news group announcing a specific proposed release date
2357      and outlining the functionality of your program. If you put some
2358      time into the announcement, you are sure to get a few responses.
2359     </para>
2360
2361     <para>
2362      The second most difficult part of testing is
2363      <emphasis>keeping</emphasis> your testers and keeping them
2364      actively involved in the testing process. Fortunately, there are
2365      some tried and true tactics that can applied toward this end:
2366     </para>
2367
2368     <para>
2369      <variablelist>
2370
2371       <varlistentry>
2372        <term>Make things simple for your testers</term>
2373        <listitem>
2374         <para>Your testers are doing you a favor so make it as easy as
2375         possible for them. This means that you should be careful to
2376         package your software in a way that is easy to find, unpack,
2377         install, and uninstall. This also means you should explain
2378         what you are looking for to each tester and make the means for
2379         reporting bugs simple and well established. The key is to
2380         provide as much structure as possible to make your testers'
2381         jobs easy and to maintain as much flexibility as possible for
2382         those that want to do things a little differently.</para>
2383        </listitem>
2384       </varlistentry>
2385
2386       <varlistentry>
2387        <term>Be responsive to your testers</term>
2388        <listitem>
2389         <para>When your testers submit bugs, respond to them and
2390         respond quickly. Even if you are only responding to tell them
2391         that the bug has already been fixed, quick and consistent
2392         responses make them feel like their work is heard, important,
2393         and appreciated.</para>
2394        </listitem>
2395       </varlistentry>
2396
2397       <varlistentry>
2398        <term>Thank your testers</term>
2399        <listitem>
2400         <para>Thank them personally each time they send you
2401         patch. Thank them publicly in the documentation and the about
2402         section of your program. You appreciate your testers and your
2403         program would not be possible without their help. Make sure
2404         they know it. Publicly, pat them on the back to make sure the rest of
2405         the world knows it too. It will be appreciated more than you
2406         expected.</para>
2407        </listitem>
2408
2409       </varlistentry>
2410      </variablelist>
2411     </para>
2412
2413    </sect3>
2414   </sect2>
2415
2416 <!-- Section2: support  -->
2417
2418   <sect2 id="support">
2419    <title>Setting up Support Infrastructure</title>
2420
2421    <para>
2422     While testing is important, the large part of your interactions
2423     and responsibility to your users falls under the category of
2424     support. The best way to make sure your users are adequately
2425     supported in using your program is to set up a good infrastructure
2426     for this purpose so that your developers and users help each other
2427     and less of the burden falls on you. This way, people will also
2428     get quicker and better responses to their questions. This
2429     infrastructure comes in several major forms:
2430    </para>
2431
2432    <sect3>
2433     <title>Documentation</title>
2434     <para>
2435      It should not come as any surprise that the key element to any
2436      support infrastructure is good documentation. This topic was
2437      largely covered in <xref linkend="documentation"> and will not be
2438      repeated here.
2439     </para>
2440    </sect3>
2441
2442    <sect3 id="mailinglists">
2443     <title>Mailing lists</title>
2444     <para>
2445      Aside from documentation, effective mailing lists will be your
2446      greatest tool in providing user support. Running a mailing list
2447      well is more complicated than installing mailing list software
2448      onto a machine.
2449     </para>
2450
2451     <sect4>
2452      <title>Separate lists</title>
2453      
2454      <para>
2455       A good idea is too separate your user and development mailing
2456       lists (perhaps into project-user@host and project-devel@host)
2457       and enforce the division. If people post a development question
2458       onto -user, politely ask them to repost it onto -devel and vise
2459       versa. Subscribe yourself to both groups and encourage all
2460       primarily developers to do the same.
2461      </para>
2462
2463      <para>
2464       This system provides so that no one person is stuck doing all of
2465       the support work and works so that users learn more about the
2466       program, they can help newer users with their questions.
2467      </para>
2468     </sect4>
2469
2470     <sect4>
2471      <title>Choose mailing list software well</title>
2472      <para>
2473       Please don't make the selection of mailing list software
2474       impulsively. Please consider easy accessibility by users without
2475       a lot of technical experience so you want to be as easy as
2476       possible. Web accessibility to an archive of the list is also
2477       important.
2478      </para>
2479
2480      <para>
2481       The two biggest free software mailing list programs are <ulink
2482       url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
2483       and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
2484       long time advocate of majordomo, I would now recommend any
2485       project choose GNU Mailman. It fulfills the criteria listed
2486       above and makes it easier. It provides a good mailing
2487       list program for a free software project maintainer as opposed
2488       to a good mailing list application for a mailing list
2489       administrator.
2490      </para>
2491
2492      <para>
2493       There are other things you want to take into consideration in
2494       setting up your list. If it is possible to gate your mailing
2495       lists to Usenet and provide it in digest form as well as
2496       making them accessible on the web, you will please some users
2497       and work to make the support infrastructure slightly more
2498       accessible.
2499      </para>
2500     </sect4>
2501    </sect3>
2502
2503    <sect3>
2504     <title>Other support ideas</title>
2505
2506     <para>
2507      A mailing list and accessible documentation are far from all you
2508      can do to set up good user support infrastructure. Be
2509      creative. If you stumble across something that works well, email me
2510      and I'll include it here.
2511     </para>
2512
2513     <sect4>
2514      <title>Make your self accessible</title>
2515      <para>
2516       You can not list too few methods to reach you. If you hang out
2517       in an <acronym>IRC</acronym> channel, don't hesitate to list it
2518       in your projects documentation. List email and snailmail
2519       addresses, and ways to reach you via <acronym>ICQ</acronym>,
2520       <acronym>AIM</acronym>, or Jabber if they apply.
2521     </para>
2522     </sect4>
2523
2524     <sect4>
2525      <title>Bug management software</title>
2526      <para>
2527       For many large software projects, use of bug management software
2528       is essential to keep track of which bugs have been fixed, which
2529       bugs have not been fixed, and which bugs are being fixed by
2530       which people. Debian uses the <ulink
2531       url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
2532       (<acronym>BTS</acronym>) although it may not be best choice for
2533       every project (it seems to currently be buckling under its own
2534       weight) As well as a damn good web browser, the Mozilla project
2535       has spawned a sub-project resulting in a bug tracking system
2536       called <ulink
2537       url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
2538       which has become extremely possible and which I like a lot.
2539      </para>
2540
2541      <para>
2542       These systems (and others like them) can be unwieldy so
2543       developers should be careful to not spend more time on the bug
2544       tracking system than on the bugs or the projects themselves. If
2545       a project continues to grow, use of a bug tracking system can
2546       provide an easy standard avenue for users and testers to report
2547       bugs and for developers and maintainers to fix them and track
2548       them in an orderly fashion.
2549      </para>
2550     </sect4>
2551    </sect3>
2552   </sect2>
2553
2554 <!-- Section2: releasing -->
2555
2556   <sect2 id="releasing">
2557    <title>Releasing Your Program</title>
2558
2559    <para>
2560     As mentioned earlier in the HOWTO, the first rule of releasing is,
2561     <emphasis>release something useful.</emphasis> Non-working or
2562     not-useful software will not attract anyone to your
2563     project. People will be turned off of your project and will be likely
2564     to simply gloss over it next time they see a new version
2565     announced. Half-working software, if useful, will intrigue people,
2566     whet their appetites for versions to come, and encourage them to
2567     join the development process.
2568    </para>
2569
2570    <sect3>
2571     <title>When to release</title>
2572
2573     <para>
2574      Making the decision to release your software for the first time
2575      is an incredibly important and incredibly stressful decision. But
2576      it needs to  done. My advice is to try and make something that
2577      is complete enough to be usable and incomplete enough to allow
2578      for flexibility and room for imagination by your future
2579      developers. It's not an easy decision. Ask for help on a local
2580      Linux User Group mailing list or from a group of developer
2581      friends.
2582     </para>
2583
2584     <para>
2585      One tactic is to first do an <quote>alpha</quote> or
2586      <quote>beta</quote> release as described below in <xref
2587      linkend="alphabeta">. However, most of the guidelines described
2588      above still apply.
2589     </para>
2590
2591     <para>
2592      <emphasis>When you feel in your gut that it is time and you feel
2593      you've weighed the situation well several times, cross your
2594      fingers and take the plunge.</emphasis>
2595    </para>
2596
2597     <para>
2598      After you've released for the first time, knowing when to release
2599      becomes less stressful, but just as difficult to gauge. I like
2600      the criteria offered by Robert Krawitz in his article, <ulink
2601      url="http://www.advogato.org/article/196.html"><quote>Free
2602      Software Project Management</quote></ulink> for maintaining a
2603      good release cycle. He recommends that you ask yourself,
2604      <quote>does this release...</quote>
2605     </para>
2606
2607     <para>
2608      <itemizedlist>
2609       <listitem>
2610        <para>Contain sufficient new functionality or bug fixes to be
2611        worth the effort.</para>
2612       </listitem>
2613
2614       <listitem>
2615        <para>Be spaced sufficiently far apart to allow the user time
2616        to work with the latest release.</para>
2617       </listitem>
2618
2619       <listitem>
2620        <para>Be sufficiently functional so that the user can get work
2621        done (quality).</para>
2622       </listitem>
2623      </itemizedlist>
2624     </para>
2625
2626     <para>
2627      If the answer is yes to all of these questions, its probably time
2628      for a release. If in doubt, remember that asking for advice can't
2629      hurt.
2630     </para>
2631    </sect3>
2632
2633    <sect3>
2634     <title>How to release</title>
2635
2636     <para>
2637      If you've followed the guidelines described in this HOWTO up
2638      until this point, the mechanics of doing a release are going to
2639      be the easy part of releasing. If you have set up consistent
2640      distribution locations and the other infrastructure described in
2641      the preceding sections, releasing should be as simple as building
2642      the package, checking it once over, and uploading it into the
2643      appropriate place and then making your website reflect the
2644      change.
2645     </para>
2646    </sect3>
2647
2648    <sect3 id="alphabeta">
2649     <title>Alpha, beta, and development releases</title>
2650
2651     <para>
2652      When contemplating releases, it worth considering the fact that
2653      not every release needs to be a full numbered release. Software
2654      users are accustomed to pre-releases but you must be careful to
2655      label these releases accurately or they will cause more problems then
2656      they are worth.
2657     </para>
2658
2659     <para>
2660      The observation is often made that many free software developers
2661      seem to be confused about the release cycle. <quote><ulink
2662      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
2663      Projects the Open Source Way</ulink></quote> suggests that you memorize
2664      the phrase, <quote>Alpha is not Beta. Beta is not Release</quote>
2665      and I'd agree that tis is a probably a good idea.
2666     </para>
2667
2668     <para>
2669      <variablelist>
2670
2671       <varlistentry>
2672        <term>alpha releases</term>
2673        <listitem>
2674         <para>Alpha software is feature-complete but sometimes only
2675         partially functional.</para>
2676
2677         <para>Alpha releases are expected to be unstable, perhaps a
2678         little unsafe, but definitely usable. They
2679         <emphasis>can</emphasis> have known bugs and kinks that have
2680         yet to be worked out. Before releasing an alpha, be sure to
2681         keep in mind that <emphasis>alpha releases are still
2682         releases</emphasis> and people are not going to be expecting a
2683         nightly build from the CVS source. An alpha should work and
2684         have minimal testing and bug fixing already finished.</para>
2685        </listitem>
2686       </varlistentry>
2687
2688       <varlistentry>
2689        <term>beta releases</term>
2690        <listitem>
2691         <para>Beta software is feature-complete and functional, but is
2692         in the testing cycle and still has a few bugs left to be
2693         ironed out.</para>
2694
2695         <para>Beta releases are general expected to be usable and
2696         slightly unstable, although definitely <emphasis>not
2697         unsafe.</emphasis> Beta releases usually preclude a full
2698         release by under a month. They can contain small known bugs
2699         but no major ones. All major functionality should be fully
2700         implemented although the exact mechanics can still be worked
2701         out. Beta releases are great tool to whet the appetites of
2702         potential users by giving them a very realistic view of where
2703         your project is going to be in the very near future and can
2704         help keep interest by giving people
2705         <emphasis>something.</emphasis></para>
2706        </listitem>
2707       </varlistentry>
2708
2709       <varlistentry>
2710        <term>development releases</term>
2711        <listitem>
2712         <para><quote>Development release</quote> is much a more vague
2713         term than <quote>alpha</quote> or <quote>beta</quote>. I
2714         usually choose to reserve the term for discussion of a
2715         development branch although there are other ways to use the
2716         term. So many in fact, that I feel the term has been
2717         cheapened. The popular window manager <ulink
2718         url="http://www.enlightenment.org">Enlightenment</ulink> has
2719         released <emphasis>nothing but</emphasis> development
2720         releases. Most often, the term is used to describe releases
2721         that are not even alpha or beta and if I were to release a
2722         pre-alpha version of a piece of software in order to keep
2723         interest in my project alive, this is probably how I would
2724         have to label it.</para>
2725        </listitem>
2726       </varlistentry>
2727
2728      </variablelist>
2729
2730     </para>
2731    </sect3>
2732   </sect2>
2733
2734 <!-- Section2: announcing  -->
2735
2736   <sect2 id="announcing">
2737    <title>Announcing Your Project</title>
2738
2739    <para>
2740     Well, you've done it. You've (at least for the purposes of this
2741     HOWTO) designed, built, and released your free software
2742     project. All that is left is for you to tell the world so they
2743     know to come and try it out and hopefully jump on board with
2744     development. If everything is in order as described above, this
2745     will be a quick and painless process. A quick announcement is all
2746     that it takes to put yourself on the free software community's
2747     radar screen.
2748    </para>
2749
2750    <sect3>
2751     <title>Mailing lists and Usenet</title>
2752
2753     <para>Announce your software on Usenet's <ulink
2754     url="news:comp.os.linux.announce">comp.os.linux.announce</ulink>. If
2755     you only announce your software in two places, have it be c.o.l.a
2756     and freshmeat.</para>
2757
2758     <para>
2759      However, email is still the way that most people on the Internet
2760      get their information. Its a good idea to send a message
2761      announcing your program to any relevant mailing list you know of
2762      and any other relevant Usenet discussion groups.</para>
2763
2764     <para>Karl Fogel recommends that use you simple subject
2765      describing the fact that the message is an announcement, the name
2766      of the program, the version, and a half-line long description of
2767      its functionality. This way, any interested user or developer
2768      will be immediately attracted to your announcement. Fogel's
2769      example looks like:
2770     </para>
2771
2772     <screen>Subject: ANN: aub 1.0, a program to assemble Usenet binaries</screen>
2773
2774     <para>
2775      The rest of the email should describe the programs functionality
2776      quickly and concisely in no more than two paragraphs and should
2777      provide links to the projects webpage and direct links to
2778      downloads for those that want to try it right away. This form
2779      will work for both Usenet and mailing list posts.
2780     </para>
2781
2782     <para>
2783      You should repeat this announcement process consistently in the
2784      same locations for each subsequent release.
2785     </para>
2786    </sect3>
2787
2788    <sect3>
2789     <title>freshmeat.net</title>
2790     <para>
2791      Mentioned earlier in <xref linkend="evalwhere">, in today's free
2792      software community, announcements of your project on freshmeat
2793      are almost more important than announcements on mailing lists.
2794     </para>
2795
2796     <para>
2797      Visit the <ulink url="http://freshmeat.net">freshmeat.net
2798      website</ulink> or their <ulink
2799      url="http://freshmeat.net/add-project/">submit project
2800      page</ulink> to post your project onto their site and into their
2801      database. In addition to a large website, freshmeat provides a
2802      daily newsletter that highlights all the days releases and
2803      reaches a huge audience (I personally skim it every night for any
2804      interesting new releases).
2805     </para>
2806    </sect3>
2807
2808    <sect3>
2809     <title>Project Mailing List</title>
2810
2811     <para>If you've gone ahead and created mailing lists for your
2812     project, you should always announce new versions on these
2813     lists. I've found that for many projects, users request a very
2814     low-volume announce only mailing list to be notified when new
2815     versions are released. freshmeat.net now allows users to subscribe
2816     to a particular project so they receive emails every time a new
2817     version is announced through their system. It's free and it can
2818     stand in for an announce-only mailing list. In my opinion, it
2819     can't hurt.</para>
2820    </sect3>
2821   </sect2>
2822 </sect1>
2823
2824  <bibliography>
2825
2826   <bibliodiv>
2827    <title>Printed Books</title>
2828
2829    <biblioentry>
2830     <biblioset>
2831      <author>
2832       <surname>Fogel</surname>
2833       <firstname>Karl</firstname>
2834      </author>
2835      
2836      <title>Open Source Development with CVS</title>
2837      
2838      <publisher>
2839       <publishername>Coriolois Open Press</publishername>
2840      </publisher>
2841      <pubdate>1999</pubdate>
2842
2843      <isbn>1-57610-490-7</isbn>
2844
2845      <abstract>
2846       <para>
2847        Fogel's <quote>guide to using CVS in the free software
2848        world</quote> is much more than its subtitle. In the publisher's
2849        own words: <quote><emphasis>Open Source Development with
2850        CVS</emphasis> is one of the first books available that teaches
2851        you development and implementation of Open Source
2852        software.</quote> It also includes the best reference and
2853        tutorial to CVS I have ever seen. It is the book that was
2854        <emphasis>so good</emphasis> that it prompted me to write this
2855        HOWTO because I thought the role it tried to serve was so
2856        important and useful. Please check it or buy it if you can and
2857        are seriously interested in running a free software project.
2858       </para>
2859
2860       <para>In May of 2003, the entire book under the GPL. You can
2861       find the full text of the book <ulink
2862       url="http://cvsbook.red-bean.com/">here</ulink>.</para>
2863      </abstract>
2864     </biblioset>
2865    </biblioentry>
2866
2867    <biblioentry
2868     <biblioset>
2869      <author>
2870       <surname>Lessig</surname>
2871       <firstname>Lawrence</firstname>
2872      </author>
2873
2874      <title>Code and Other Laws of Cyberspace</title>
2875      
2876      <publisher>
2877       <publishername>Basic Books</publishername>
2878      </publisher>
2879      <pubdate>2000</pubdate>
2880      
2881      <isbn>0-465-03913-8</isbn>
2882
2883      <abstract>
2884       <para>
2885        While it only briefly talks about free software (and does it by
2886        tiptoeing around the free software/open source issue with the
2887        spineless use of the term <quote>open code</quote> that only a
2888        lawyer could coin), Lessig's book is brilliant. Written by a
2889        lawyer, it talks about how regulation on the Internet is not
2890        done with law, but with the code itself and how the nature of
2891        the code will determine the nature of future freedoms. In
2892        addition to being a quick and enjoyable read, it gives some
2893        cool history and describes how we <emphasis>need</emphasis>
2894        free software in a way more powerfully than anything I've read
2895        outside of <ulink
2896        url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
2897        <quote>Right to Read.</quote></ulink>
2898       </para>
2899      </abstract>
2900     </biblioset>
2901    </biblioentry>
2902    
2903    <biblioentry>
2904     <biblioset>
2905      <author>
2906       <surname>Raymond</surname>
2907       <firstname>Eric</firstname>
2908      </author>
2909      
2910      <title>The Cathedral and the Bazaar</title>
2911      <subtitle>Musings on Linux and Open Source by an Accidental Revolutionary</subtitle>
2912      
2913      <publisher>
2914       <publishername>O'Reilly</publishername>
2915      </publisher>
2916      <pubdate>1999</pubdate>
2917     
2918      <isbn>1-56592-724-9</isbn>
2919      <abstract>
2920       <para>
2921        Although I have to honestly say that I am not the ESR fan that
2922        I used to be, this book proved invaluable in getting me where I
2923        am today. The essay that gives the book its title does a good
2924        job of sketching the free software process and does an an
2925        amazing job of making an argument for free software/open source
2926        development as a road to better software. The rest of the book
2927        has other of ESR's articles, which for the most part are posted
2928        on his website. Still, it's nice thing to own in hard copy and
2929        something that every free software/open source hacker should
2930        read.
2931       </para>
2932      </abstract>
2933     </biblioset>
2934    </biblioentry>
2935   </bibliodiv>
2936
2937   <bibliodiv>
2938    <title>Web-Accessible Resources</title>
2939
2940    <para>
2941     This is a list of the web resources pertaining to this HOWTO that
2942     I've found most helpful in compiling this information. If you know
2943     of others that would help, please don't hesitate to email me at
2944     <email>mako@atdot.cc</email> and we can look into getting it
2945     added to the list and represented in the HOWTO.
2946    </para>
2947
2948    <para>
2949     I'd recommend that any free software developer (or potential one)
2950     skim through these sites because they have each have a lot to say.
2951    </para>
2952
2953
2954    <biblioentry>
2955     <biblioset>
2956      <author>
2957       <surname>Dafermos</surname>
2958       <firstname>George</firstname>
2959       <othername>N</othername>
2960      </author>
2961
2962      <title><ulink url="http://firstmonday.org/issues/issue6_11/dafermos/">Management and Virtual Decentralized Networks: The Linux Project</ulink></title>
2963
2964      <abstract>
2965       <para>Since the paper includes its own abstract, I thought I
2966       would include it here verbatim:</para>
2967
2968       <para><blockquote><para>This paper examines the latest of
2969         paradigms - the Virtual Network(ed) Organisation - and whether
2970         geographically dispersed knowledge workers can virtually
2971         collaborate for a project under no central
2972         planning. Co-ordination, management and the role of knowledge
2973         arise as the central areas of focus. The Linux Project and its
2974         development model are selected as a case of analysis and the
2975         critical success factors of this organisational design are
2976         identified. The study proceeds to the formulation of a
2977         framework that can be applied to all kinds of virtual
2978         decentralised work and concludes that value creation is
2979         maximized when there is intense interaction and uninhibited
2980         sharing of information between the organisation and the
2981         surrounding community. Therefore, the potential success or
2982         failure of this organisational paradigm depends on the degree
2983         of dedication and involvement by the surrounding
2984         community.</para></blockquote></para>
2985
2986       <para>This paper was referred to me in my capacity as author of
2987       this HOWTO and I was very impressed. It's written by a graduate
2988       student in management and I think it succeeds at evaluating the
2989       Linux project as an example of a new paradigm in management--one
2990       that <emphasis>you</emphasis> will be be placing yourself at the
2991       center of in your capacity as maintainer of a free software
2992       project.</para>
2993
2994       <para>As a developer trying to control an application and guide
2995       it to success in the free software world, I'm not sure how
2996       useful Dafermos's argument is. It does however, provide a
2997       theoretical justification for my HOWTO--free software project
2998       management <emphasis>is</emphasis> a different creature than
2999       proprietary software project management. If you are interested
3000       in the conceptual and theoretical ways that free software
3001       project management differs from other types of management, this
3002       is a great paper to read. If this paper answers questions of
3003       <quote>how?</quote>, Dafermos answers the (more difficult to
3004       defend) questions of <quote>why?</quote> and does a very good
3005       job.</para>
3006
3007
3008      </abstract>
3009     </biblioset>
3010    </biblioentry>
3011
3012    <biblioentry>
3013     <biblioset>
3014      <author>
3015       <surname>Gabriel</surname>
3016       <firstname>Richard</firstname>
3017      </author>
3018      
3019      <title><ulink
3020      url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
3021      <quote>Worse is Better</quote></ulink></title>
3022
3023      <abstract>
3024       <para>
3025        A well written article although I think the title may have
3026        confused as many people as the rest of the essay helped. It
3027        offers a good description of how to design programs that will
3028        succeed and stay maintainable as they grow.
3029       </para>
3030      </abstract>
3031     </biblioset>
3032    </biblioentry>
3033
3034    <biblioentry>
3035     <biblioset>
3036      <author>
3037       <surname>Manley</surname>
3038       <firstname>Montey</firstname>
3039      </author>
3040      
3041      <title><ulink
3042      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
3043      Projects the Open Source Way</ulink></title>
3044      
3045      <publisher>
3046       <publishername><ulink
3047       url="http://www.linuxprogramming.com">Linux
3048       Programming</ulink></publishername>
3049      </publisher>
3050      <pubdate>Oct 31, 2000</pubdate>
3051
3052      <abstract>
3053       <para>
3054        In one of the better articles on the subject that I've read,
3055        Monty sums up some of the major points I touch on including:
3056        starting a project, testing, documentation, organizing a team and
3057        leadership, and several other topics. While more opinionated that
3058        I try to be, I think its an important article that I found very
3059        helpful in writing this HOWTO. I've tried to cite him in
3060        the places where I borrowed from him most.
3061       </para>
3062
3063       <para>
3064        I have problems much of this piece and I recommend you read
3065        <xref linkend="krawitz"> at the same time you read Monty's
3066        article for a good critique.
3067       </para>
3068      </abstract>
3069     </biblioset>
3070    </biblioentry>
3071
3072    <biblioentry id="esrhowto">
3073     <biblioset>
3074      <author>
3075       <surname>Raymond</surname>
3076       <firstname>Eric</firstname>
3077       <othername>Steven</othername>
3078      </author>
3079
3080      <title><ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">Software Release Practice HOWTO</ulink></title>
3081
3082      <abstract>
3083
3084       <para>At first glance, ESR's release practice HOWTO seems to
3085       share a lot of terrain with this document. Upon closer
3086       examination, the differences become apparent but they are
3087       closely related. His document, read in conjunction with mine,
3088       will give a reader a good picture of how to go about managing a
3089       project. ESR's HOWTO goes into a bit more detail on how to write
3090       and what languages to write in. He tends to give more specific
3091       instructions and checklists (<quote>name this file this, not
3092       this</quote>) while this HOWTO speaks more conceptually. There
3093       are several sections that are extremely similar. It's also
3094       <emphasis>much</emphasis> shorter.</para>
3095
3096       <para>My favorite quote from his HOWTO is: <quote>"Managing a
3097       project well when all the participants are volunteers presents
3098       some unique challenges. This is too large a topic to cover in a
3099       HOWTO.</quote> Oh really? Perhaps I just do a poor job.</para>
3100      </abstract>
3101
3102     </biblioset>
3103    </biblioentry>
3104
3105
3106    <biblioentry id="cvsbestpractices">
3107     <biblioset>
3108      <author>
3109       <surname>Venugopalan</surname>
3110       <firstname>Vivek</firstname>
3111      </author>
3112
3113      <title><ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html">CVS Best Practices</ulink></title>
3114
3115      <abstract>
3116
3117       <para>Venugopalan provides one of the best essays on
3118       effective use of CVS that I've come across. It is written for
3119       people who already have a good knowledge of CVS. In the chapter
3120       on branching, he describes when and how to branch but gives no
3121       information on what CVS commands you should use to do this. This
3122       is fine (technical CVS HOWTO have been written) but CVS newbies
3123       will want to spend some time with Fogel's reference before they
3124       will find this one very useful.</para>
3125
3126       <para>Venugopalan creates checklists of things to do before,
3127       after, and around releases. It's definitely worth a read through
3128       as most of his ideas will save tons of developer head aches over
3129       any longer period of time.</para>
3130
3131      </abstract>
3132     </biblioset>
3133    </biblioentry>
3134
3135   </bibliodiv>
3136
3137   <bibliodiv>
3138    <title>Advogato Articles</title>
3139
3140    <para>
3141     I've found that one of the best resources that any free software
3142     developer has at his or her disposal is Advogato.org. If you haven't
3143     yet had a chance to visit <ulink url="http://www.advogato.org">the
3144     website</ulink>, do.
3145    </para>
3146
3147    <para>
3148     I have spent a huge amount of time on Advogato and I've gone
3149     through and provided links to the articles that I think might be
3150     of particular interest to anyone reading this HOWTO. I think that
3151     skimming through these links can be helpful and I promise that if
3152     you do, you'll learn a lot. You will learn that my idea of how a
3153     free software project should be run is not the
3154     <emphasis>only</emphasis> idea. I think that's important.
3155    </para>
3156
3157    <para>
3158     If nothing else, there is <emphasis>way</emphasis> more
3159     information on that website than I could ever fit into, or
3160     reference from this HOWTO. I have listed what I think are the most
3161     relevant articles here with short descriptions that I've written.
3162    </para>
3163
3164
3165    <biblioentry>
3166     <biblioset>
3167      <author>
3168       <surname>Hindle</surname>
3169       <firstname>Stephen</firstname>
3170      </author>
3171      
3172      <title><ulink url="http://www.advogato.org/article/262.html">'Best Practices' for Open Source?</ulink></title>
3173      
3174      <publisher>
3175       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3176      </publisher>
3177      <pubdate>March 21, 2001</pubdate>
3178
3179      <abstract>
3180       <para>
3181        Touching mostly on programming practice (as most articles on
3182        the subject usually do), the article talks a little about
3183        project management (<quote>Use it!</quote>) and a bit about
3184        communication within a free software project.
3185       </para>
3186      </abstract>
3187     </biblioset>
3188    </biblioentry>
3189
3190    <biblioentry>
3191     <biblioset>
3192      <author>
3193       <surname>Cohen</surname>
3194       <firstname>Bram</firstname>
3195      </author>
3196      
3197      <title><ulink
3198      url="http://www.advogato.org/article/258.html"></ulink>How to
3199      Write Maintainable Code</title>
3200      
3201      <publisher>
3202       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3203      </publisher>
3204      <pubdate>March 15, 2001</pubdate>
3205      
3206      <abstract>
3207       <para>
3208        This article touches upon the "writing maintainable code"
3209        discussion that I try hard to avoid in my HOWTO. It's one of
3210        the better (and most diplomatic) articles on the subject that
3211        I've found.
3212       </para>
3213      </abstract>
3214     </biblioset>
3215    </biblioentry>
3216    <biblioentry id="krawitz">
3217     <biblioset>
3218      <author>
3219       <surname>Krawitz</surname>
3220       <firstname>Robert</firstname>
3221      </author>
3222      
3223      <title><ulink url="http://www.advogato.org/article/196.html">Free
3224      Source Project Management</ulink></title>
3225      
3226      <publisher>
3227       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3228      </publisher>
3229      <pubdate>November 4, 2000</pubdate>
3230     
3231      <abstract>
3232       <para>
3233        This article made me happy because it challenged many of the
3234        problems that I had with Monty's article on <ulink
3235        url="http://www.linuxprogramming.com">LinuxProgramming</ulink>. The
3236        author argues that Monty calls simply for the application of
3237        old (proprietary software) project management techniques in
3238        free software projects instead of working to come up with
3239        something new. I found his article to be extremely well thought
3240        out and I think it's an essential read for any free software
3241        project manager.
3242       </para>
3243      </abstract>
3244     </biblioset>
3245    </biblioentry>
3246
3247    <biblioentry>
3248     <biblioset>
3249      <author>
3250       <surname>Martins</surname>
3251       <firstname>Lalo</firstname>
3252      </author>
3253      
3254      <title><ulink url="http://www.advogato.org/article/128.html">Ask
3255      the Advogatos: why do Free Software projects
3256      fail?</ulink></title>
3257      
3258      <publisher>
3259       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3260      </publisher>
3261      <pubdate>July 20, 2000</pubdate>
3262
3263      <abstract>
3264       <para>
3265        While the article is little more than a question, reading the
3266        answers to this question offered by Advogato's readers can
3267        help. In a lot of ways, this HOWTO acts as my answer to the
3268        questions posed in this article but there are others, many of
3269        which might take issue with whats is in this HOWTO. It's worth
3270        checking out.
3271       </para>
3272      </abstract>
3273     </biblioset>
3274    </biblioentry>
3275
3276    <biblioentry>
3277     <biblioset>
3278      <author>
3279       <surname>Burley</surname>
3280       <firstname>David</firstname>
3281      </author>
3282      
3283      <title><ulink
3284      url="http://www.advogato.org/article/107.html">In-Roads to Free
3285      Software Development</ulink></title>
3286      
3287      <publisher>
3288       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3289      </publisher>
3290      <pubdate>June 14, 2000</pubdate>
3291     
3292      <abstract>
3293       <para>
3294        This document was written as a response to <ulink
3295        url="http://www.advogato.org/article/72.html">another Advogato
3296        article</ulink>. Although not about running a project, this
3297        describes some of the ways that you can get started with free
3298        software development without starting a project. I think this
3299        is an important article. If you are interested in becoming
3300        involved with free software, this article showcases some of the
3301        ways that you can do this without actually starting a project
3302        (something that I hope this HOWTO has demonstrated is not to be
3303        taken lightly).
3304       </para>
3305      </abstract>
3306     </biblioset>
3307    </biblioentry>
3308
3309    <biblioentry>
3310     <biblioset>
3311      <author>
3312       <surname>Moorman</surname>
3313       <firstname>Jacob</firstname>
3314      </author>
3315
3316      <title><ulink url="http://www.advogato.org/article/72.html">Importance of
3317      Non-Developer Supporters in Free Software</ulink><title></title>
3318
3319      <publisher>
3320       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3321      </publisher>
3322      <pubdate>April 16, 2000</pubdate>
3323     
3324      <abstract>
3325       <para>
3326        Moorman's is a short article but it brings up some good
3327        points. The comment reminding developers to thank their testers
3328        and end-users is invaluable and oft-forgotten.
3329       </para>
3330      </abstract>
3331     </biblioset>
3332    </biblioentry>
3333
3334    <biblioentry>
3335     <biblioset>
3336      <author>
3337       <surname>Orchard</surname>
3338       <firstname>Leslie</firstname>
3339      </author>
3340      
3341      <title><ulink url="http://www.advogato.org/article/67.html">On
3342      Naming an Open Source Project</ulink></title>
3343      
3344      <publisher>
3345       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3346      </publisher>
3347      <pubdate>April 12, 2000</pubdate>
3348     
3349      <abstract>
3350       <para>
3351        I didn't even have a section on project naming in this HOWTO
3352        (See <xref linkend="naming">) until Leslie Orchard's article
3353        reminded me of it. Thanks to Leslie for writing this article!
3354       </para>
3355      </abstract>
3356     </biblioset>
3357    </biblioentry>
3358
3359    <biblioentry>
3360     <biblioset>
3361      <author>
3362       <surname>Allen</surname>
3363       <firstname>David</firstname>
3364      </author>
3365      
3366      <title><ulink url="http://www.advogato.org/article/40.html">Version Numbering Madness</ulink></title>
3367      
3368      <publisher>
3369       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
3370      </publisher>
3371      <pubdate>February 28, 2000</pubdate>
3372     
3373      <abstract>
3374       <para>
3375        In this article, David Allen challenges the whole
3376        <quote>Major.Minor.Patch</quote> version numbering scheme. Its
3377        good to read this as you read <xref
3378        linkend="chooseversioning">. I liked the article and it
3379        describes some of the projects that I bring up in my discussion
3380        of version numbering.
3381       </para>
3382      </abstract>
3383     </biblioset>
3384    </biblioentry>
3385
3386   </bibliodiv>
3387  </bibliography>
3388
3389   <appendix id="fdl">
3390   <title>GNU Free Documentation License</title>
3391   <para>
3392     Copyright (C) 2000, 2001, 2002 Free Software Foundation,
3393     <abbrev>Inc.</abbrev> 51 Franklin <abbrev>St</abbrev>, Fifth Floor,
3394     Boston, <abbrev>MA</abbrev> 02110-1301 <abbrev
3395     role="initialism">USA</abbrev>.  Everyone is permitted to copy and
3396     distribute verbatim copies of this license document, but changing it is
3397     not allowed.
3398   </para>
3399   <bridgehead id="Preamble" renderas="sect1">
3400     0. PREAMBLE
3401   </bridgehead>
3402   <para>
3403     The purpose of this License is to make a manual, textbook, or other
3404     functional and useful document "free" in the sense of freedom: to assure
3405     everyone the effective freedom to copy and redistribute it, with or
3406     without modifying it, either commercially or noncommercially.
3407     Secondarily, this License preserves for the author and publisher a way to
3408     get credit for their work, while not being considered responsible for
3409     modifications made by others.
3410   </para>
3411   <para>
3412     This License is a kind of "copyleft", which means that derivative works of
3413     the document must themselves be free in the same sense.  It complements
3414     the GNU General Public License, which is a copyleft license designed for
3415     free software.
3416   </para>
3417   <para>
3418     We have designed this License in order to use it for manuals for free
3419     software, because free software needs free documentation: a free program
3420     should come with manuals providing the same freedoms that the software
3421     does.  But this License is not limited to software manuals; it can be used
3422     for any textual work, regardless of subject matter or whether it is
3423     published as a printed book.  We recommend this License principally for
3424     works whose purpose is instruction or reference.</para>
3425   <bridgehead id="Definitions" renderas="sect1">
3426     1. APPLICABILITY AND DEFINITIONS
3427   </bridgehead>
3428   <para>
3429     This License applies to any manual or other work, in any medium, that
3430     contains a notice placed by the copyright holder saying it can be
3431     distributed under the terms of this License.  Such a notice grants a
3432     world-wide, royalty-free license, unlimited in duration, to use that work
3433     under the conditions stated herein.  The "Document", below, refers to any
3434     such manual or work.  Any member of the public is a licensee, and is
3435     addressed as "you".  You accept the license if you copy, modify or
3436     distribute the work in a way requiring permission under copyright
3437     law.
3438   </para>
3439   <para>
3440     A "Modified Version" of the Document means any work containing the
3441     Document or a portion of it, either copied verbatim, or with modifications
3442     and/or translated into another language.
3443   </para>
3444   <para>
3445     A "Secondary Section" is a named appendix or a front-matter section of the
3446     Document that deals exclusively with the relationship of the publishers or
3447     authors of the Document to the Document's overall subject (or to related
3448     matters) and contains nothing that could fall directly within that overall
3449     subject.  (Thus, if the Document is in part a textbook of mathematics, a
3450     Secondary Section may not explain any mathematics.)  The relationship
3451     could be a matter of historical connection with the subject or with
3452     related matters, or of legal, commercial, philosophical, ethical or
3453     political position regarding them.
3454   </para>
3455   <para>
3456     The "Invariant Sections" are certain Secondary Sections whose titles are
3457     designated, as being those of Invariant Sections, in the notice that says
3458     that the Document is released under this License.  If a section does not
3459     fit the above definition of Secondary then it is not allowed to be
3460     designated as Invariant.  The Document may contain zero Invariant
3461     Sections.  If the Document does not identify any Invariant Sections then
3462     there are none.
3463   </para>
3464   <para>
3465     The "Cover Texts" are certain short passages of text that are listed, as
3466     Front-Cover Texts or Back-Cover Texts, in the notice that says that the
3467     Document is released under this License.  A Front-Cover Text may be at
3468     most 5 words, and a Back-Cover Text may be at most 25 words.
3469   </para>
3470   <para>
3471     A "Transparent" copy of the Document means a machine-readable copy,
3472     represented in a format whose specification is available to the general
3473     public, that is suitable for revising the document straightforwardly with
3474     generic text editors or (for images composed of pixels) generic paint
3475     programs or (for drawings) some widely available drawing editor, and that
3476     is suitable for input to text formatters or for automatic translation to a
3477     variety of formats suitable for input to text formatters.  A copy made in
3478     an otherwise Transparent file format whose markup, or absence of markup,
3479     has been arranged to thwart or discourage subsequent modification by
3480     readers is not Transparent.  An image format is not Transparent if used
3481     for any substantial amount of text.  A copy that is not "Transparent" is
3482     called "Opaque".
3483   </para>
3484   <para>
3485     Examples of suitable formats for Transparent copies include plain ASCII
3486     without markup, Texinfo input format, LaTeX input format, SGML or XML
3487     using a publicly available DTD, and standard-conforming simple HTML,
3488     PostScript or PDF designed for human modification.  Examples of
3489     transparent image formats include PNG, XCF and JPG.  Opaque formats
3490     include proprietary formats that can be read and edited only by
3491     proprietary word processors, SGML or XML for which the DTD and/or
3492     processing tools are not generally available, and the machine-generated
3493     HTML, PostScript or PDF produced by some word processors for output
3494     purposes only.
3495   </para>
3496   <para>
3497     The "Title Page" means, for a printed book, the title page itself, plus
3498     such following pages as are needed to hold, legibly, the material this
3499     License requires to appear in the title page.  For works in formats which
3500     do not have any title page as such, "Title Page" means the text near the
3501     most prominent appearance of the work's title, preceding the beginning of
3502     the body of the text.
3503   </para>
3504   <para>
3505     A section "Entitled XYZ" means a named subunit of the Document whose title
3506     either is precisely XYZ or contains XYZ in parentheses following text that
3507     translates XYZ in another language.  (Here XYZ stands for a specific
3508     section name mentioned below, such as "Acknowledgements", "Dedications",
3509     "Endorsements", or "History".)  To "Preserve the Title" of such a section
3510     when you modify the Document means that it remains a section "Entitled
3511     XYZ" according to this definition.
3512   </para>
3513   <para>
3514     The Document may include Warranty Disclaimers next to the notice which
3515     states that this License applies to the Document.  These Warranty
3516     Disclaimers are considered to be included by reference in this License,
3517     but only as regards disclaiming warranties: any other implication that
3518     these Warranty Disclaimers may have is void and has no effect on the
3519     meaning of this License.
3520   </para>
3521   <bridgehead id="VerbatimCopying" renderas="sect1">
3522     2. VERBATIM COPYING
3523   </bridgehead>
3524   <para>
3525     You may copy and distribute the Document in any medium, either
3526     commercially or noncommercially, provided that this License, the copyright
3527     notices, and the license notice saying this License applies to the
3528     Document are reproduced in all copies, and that you add no other
3529     conditions whatsoever to those of this License.  You may not use technical
3530     measures to obstruct or control the reading or further copying of the
3531     copies you make or distribute.  However, you may accept compensation in
3532     exchange for copies.  If you distribute a large enough number of copies
3533     you must also follow the conditions in section 3.
3534   </para>
3535   <para>
3536     You may also lend copies, under the same conditions stated above, and you
3537     may publicly display copies.
3538   </para>
3539   <bridgehead id="QuantityCopying" renderas="sect1">
3540     3. COPYING IN QUANTITY
3541   </bridgehead>
3542   <para>
3543     If you publish printed copies (or copies in media that commonly have
3544     printed covers) of the Document, numbering more than 100, and the
3545     Document's license notice requires Cover Texts, you must enclose the
3546     copies in covers that carry, clearly and legibly, all these Cover Texts:
3547     Front-Cover Texts on the front cover, and Back-Cover Texts on the back
3548     cover.  Both covers must also clearly and legibly identify you as the
3549     publisher of these copies.  The front cover must present the full title
3550     with all words of the title equally prominent and visible.  You may add
3551     other material on the covers in addition.  Copying with changes limited to
3552     the covers, as long as they preserve the title of the Document and satisfy
3553     these conditions, can be treated as verbatim copying in other
3554     respects.
3555   </para>
3556   <para>
3557     If the required texts for either cover are too voluminous to fit legibly,
3558     you should put the first ones listed (as many as fit reasonably) on the
3559     actual cover, and continue the rest onto adjacent pages.
3560   </para>
3561   <para>
3562     If you publish or distribute Opaque copies of the Document numbering more
3563     than 100, you must either include a machine-readable Transparent copy
3564     along with each Opaque copy, or state in or with each Opaque copy a
3565     computer-network location from which the general network-using public has
3566     access to download using public-standard network protocols a complete
3567     Transparent copy of the Document, free of added material.  If you use the
3568     latter option, you must take reasonably prudent steps, when you begin
3569     distribution of Opaque copies in quantity, to ensure that this Transparent
3570     copy will remain thus accessible at the stated location until at least one
3571     year after the last time you distribute an Opaque copy (directly or
3572     through your agents or retailers) of that edition to the public.
3573   </para>
3574   <para>
3575     It is requested, but not required, that you contact the authors of the
3576     Document well before redistributing any large number of copies, to give
3577     them a chance to provide you with an updated version of the
3578     Document.
3579   </para>
3580   <bridgehead id="Modifications" renderas="sect1">
3581     4. MODIFICATIONS
3582   </bridgehead>
3583   <para>
3584     You may copy and distribute a Modified Version of the Document under the
3585     conditions of sections 2 and 3 above, provided that you release the
3586     Modified Version under precisely this License, with the Modified Version
3587     filling the role of the Document, thus licensing distribution and
3588     modification of the Modified Version to whoever possesses a copy of it.
3589     In addition, you must do these things in the Modified Version:
3590   </para>
3591   <orderedlist numeration="upperalpha">
3592     <listitem>
3593       <simpara>
3594         Use in the Title Page (and on the covers, if any) a title distinct
3595         from that of the Document, and from those of previous versions (which
3596         should, if there were any, be listed in the History section of the
3597         Document).  You may use the same title as a previous version if the
3598         original publisher of that version gives permission.
3599         </simpara>
3600     </listitem>
3601     <listitem>
3602       <simpara>
3603         List on the Title Page, as authors, one or more persons or entities
3604         responsible for authorship of the modifications in the Modified
3605         Version, together with at least five of the principal authors of the
3606         Document (all of its principal authors, if it has fewer than five),
3607         unless they release you from this requirement.
3608       </simpara>
3609     </listitem>
3610     <listitem>
3611       <simpara>
3612         State on the Title page the name of the publisher of the Modified
3613         Version, as the publisher.
3614       </simpara>
3615     </listitem>
3616     <listitem>
3617       <simpara>
3618         Preserve all the copyright notices of the Document.
3619       </simpara>
3620     </listitem>
3621     <listitem>
3622       <simpara>
3623         Add an appropriate copyright notice for your modifications adjacent to
3624         the other copyright notices.
3625       </simpara>
3626     </listitem>
3627     <listitem>
3628       <simpara>
3629         Include, immediately after the copyright notices, a license notice
3630         giving the public permission to use the Modified Version under the
3631         terms of this License, in the form shown in the Addendum below.
3632       </simpara>
3633     </listitem>
3634     <listitem>
3635       <simpara>
3636         Preserve in that license notice the full lists of Invariant Sections
3637         and required Cover Texts given in the Document's license notice.
3638       </simpara>
3639     </listitem>
3640     <listitem>
3641       <simpara>
3642         Include an unaltered copy of this License.
3643       </simpara>
3644     </listitem>
3645     <listitem>
3646       <simpara>
3647         Preserve the section Entitled "History", Preserve its Title, and add
3648         to it an item stating at least the title, year, new authors, and
3649         publisher of the Modified Version as given on the Title Page.  If
3650         there is no section Entitled "History" in the Document, create one
3651         stating the title, year, authors, and publisher of the Document as
3652         given on its Title Page, then add an item describing the Modified
3653         Version as stated in the previous sentence.
3654       </simpara>
3655     </listitem>
3656     <listitem>
3657       <simpara>
3658         Preserve the network location, if any, given in the Document for
3659         public access to a Transparent copy of the Document, and likewise the
3660         network locations given in the Document for previous versions it was
3661         based on.  These may be placed in the "History" section.  You may omit
3662         a network location for a work that was published at least four years
3663         before the Document itself, or if the original publisher of the
3664         version it refers to gives permission.
3665       </simpara>
3666     </listitem>
3667     <listitem>
3668       <simpara>
3669         For any section Entitled "Acknowledgements" or "Dedications", Preserve
3670         the Title of the section, and preserve in the section all the
3671         substance and tone of each of the contributor acknowledgements and/or
3672         dedications given therein.
3673       </simpara>
3674     </listitem>
3675     <listitem>
3676       <simpara>
3677         Preserve all the Invariant Sections of the Document, unaltered in
3678         their text and in their titles.  Section numbers or the equivalent are
3679         not considered part of the section titles.
3680       </simpara>
3681     </listitem>
3682     <listitem>
3683       <simpara>
3684         Delete any section Entitled "Endorsements".  Such a section may not be
3685         included in the Modified Version.
3686       </simpara>
3687     </listitem>
3688     <listitem>
3689       <simpara>
3690         Do not retitle any existing section to be Entitled "Endorsements" or
3691         to conflict in title with any Invariant Section.
3692       </simpara>
3693     </listitem>
3694     <listitem>
3695       <simpara>
3696         Preserve any Warranty Disclaimers.
3697       </simpara>
3698     </listitem>
3699   </orderedlist>
3700   <para>
3701     If the Modified Version includes new front-matter sections or appendices
3702     that qualify as Secondary Sections and contain no material copied from the
3703     Document, you may at your option designate some or all of these sections
3704     as invariant.  To do this, add their titles to the list of Invariant
3705     Sections in the Modified Version's license notice.  These titles must be
3706     distinct from any other section titles.
3707   </para>
3708   <para>
3709     You may add a section Entitled "Endorsements", provided it contains
3710     nothing but endorsements of your Modified Version by various parties--for
3711     example, statements of peer review or that the text has been approved by
3712     an organization as the authoritative definition of a standard.
3713   </para>
3714   <para>
3715     You may add a passage of up to five words as a Front-Cover Text, and a
3716     passage of up to 25 words as a Back-Cover Text, to the end of the list of
3717     Cover Texts in the Modified Version.  Only one passage of Front-Cover Text
3718     and one of Back-Cover Text may be added by (or through arrangements made
3719     by) any one entity.  If the Document already includes a cover text for the
3720     same cover, previously added by you or by arrangement made by the same
3721     entity you are acting on behalf of, you may not add another; but you may
3722     replace the old one, on explicit permission from the previous publisher
3723     that added the old one.
3724   </para>
3725   <para>
3726     The author(s) and publisher(s) of the Document do not by this License give
3727     permission to use their names for publicity for or to assert or imply
3728     endorsement of any Modified Version.
3729   </para>
3730   <bridgehead id="Combining" renderas="sect1">
3731     5. COMBINING DOCUMENTS
3732   </bridgehead>
3733   <para>
3734     You may combine the Document with other documents released under this
3735     License, under the terms defined in section 4 above for modified versions,
3736     provided that you include in the combination all of the Invariant Sections
3737     of all of the original documents, unmodified, and list them all as
3738     Invariant Sections of your combined work in its license notice, and that
3739     you preserve all their Warranty Disclaimers.
3740   </para>
3741   <para>
3742     The combined work need only contain one copy of this License, and multiple
3743     identical Invariant Sections may be replaced with a single copy.  If there
3744     are multiple Invariant Sections with the same name but different contents,
3745     make the title of each such section unique by adding at the end of it, in
3746     parentheses, the name of the original author or publisher of that section
3747     if known, or else a unique number.  Make the same adjustment to the
3748     section titles in the list of Invariant Sections in the license notice of
3749     the combined work.
3750   </para>
3751   <para>
3752     In the combination, you must combine any sections Entitled "History" in
3753     the various original documents, forming one section Entitled "History";
3754     likewise combine any sections Entitled "Acknowledgements", and any
3755     sections Entitled "Dedications".  You must delete all sections Entitled
3756     "Endorsements".
3757   </para>
3758   <bridgehead id="Collections" renderas="sect1">
3759     6. COLLECTIONS OF DOCUMENTS
3760   </bridgehead>
3761   <para>
3762     You may make a collection consisting of the Document and other documents
3763     released under this License, and replace the individual copies of this
3764     License in the various documents with a single copy that is included in
3765     the collection, provided that you follow the rules of this License for
3766     verbatim copying of each of the documents in all other respects.
3767   </para>
3768   <para>
3769     You may extract a single document from such a collection, and distribute
3770     it individually under this License, provided you insert a copy of this
3771     License into the extracted document, and follow this License in all other
3772     respects regarding verbatim copying of that document.
3773   </para>
3774   <bridgehead id="Aggregation" renderas="sect1">
3775     7. AGGREGATION WITH INDEPENDENT WORKS
3776   </bridgehead>
3777   <para>
3778     A compilation of the Document or its derivatives with other separate and
3779     independent documents or works, in or on a volume of a storage or
3780     distribution medium, is called an "aggregate" if the copyright resulting
3781     from the compilation is not used to limit the legal rights of the
3782     compilation's users beyond what the individual works permit.  When the
3783     Document is included in an aggregate, this License does not apply to the
3784     other works in the aggregate which are not themselves derivative works of
3785     the Document.
3786   </para>
3787   <para>
3788     If the Cover Text requirement of section 3 is applicable to these copies
3789     of the Document, then if the Document is less than one half of the entire
3790     aggregate, the Document's Cover Texts may be placed on covers that bracket
3791     the Document within the aggregate, or the electronic equivalent of covers
3792     if the Document is in electronic form.  Otherwise they must appear on
3793     printed covers that bracket the whole aggregate.
3794   </para>
3795   <bridgehead id="Translation" renderas="sect1">
3796     8. TRANSLATION
3797   </bridgehead>
3798   <para>
3799     Translation is considered a kind of modification, so you may distribute
3800     translations of the Document under the terms of section 4.  Replacing
3801     Invariant Sections with translations requires special permission from
3802     their copyright holders, but you may include translations of some or all
3803     Invariant Sections in addition to the original versions of these Invariant
3804     Sections.  You may include a translation of this License, and all the
3805     license notices in the Document, and any Warranty Disclaimers, provided
3806     that you also include the original English version of this License and the
3807     original versions of those notices and disclaimers.  In case of a
3808     disagreement between the translation and the original version of this
3809     License or a notice or disclaimer, the original version will prevail.
3810   </para>
3811   <para>
3812     If a section in the Document is Entitled "Acknowledgements",
3813     "Dedications", or "History", the requirement (section 4) to Preserve its
3814     Title (section 1) will typically require changing the actual title.
3815   </para>
3816   <bridgehead id="Termination" renderas="sect1">
3817     9. TERMINATION
3818   </bridgehead>
3819   <para>
3820     You may not copy, modify, sublicense, or distribute the Document except as
3821     expressly provided for under this License.  Any other attempt to copy,
3822     modify, sublicense or distribute the Document is void, and will
3823     automatically terminate your rights under this License.  However, parties
3824     who have received copies, or rights, from you under this License will not
3825     have their licenses terminated so long as such parties remain in full
3826     compliance.
3827   </para>
3828   <bridgehead id="FutureRevisions" renderas="sect1">
3829     10. FUTURE REVISIONS OF THIS LICENSE
3830   </bridgehead>
3831   <para>
3832     The Free Software Foundation may publish new, revised versions of the GNU
3833     Free Documentation License from time to time.  Such new versions will be
3834     similar in spirit to the present version, but may differ in detail to
3835     address new problems or concerns.  See <ulink
3836     url="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</ulink>.
3837   </para>
3838   <para>
3839     Each version of the License is given a distinguishing version number.  If
3840     the Document specifies that a particular numbered version of this License
3841     "or any later version" applies to it, you have the option of following the
3842     terms and conditions either of that specified version or of any later
3843     version that has been published (not as a draft) by the Free Software
3844     Foundation.  If the Document does not specify a version number of this
3845     License, you may choose any version ever published (not as a draft) by the
3846     Free Software Foundation.
3847   </para>
3848   <bridgehead id="HowToUse" renderas="sect1">
3849     ADDENDUM: How to use this License for your documents
3850   </bridgehead>
3851   <para>
3852     To use this License in a document you have written, include a copy of the
3853     License in the document and put the following copyright and license
3854     notices just after the title page:
3855   </para>
3856   <blockquote>
3857     <para>
3858       Copyright (C) YEAR YOUR NAME.
3859     </para>
3860     <para>
3861       Permission is granted to copy, distribute and/or modify this document
3862       under the terms of the GNU Free Documentation License, Version 1.2 or
3863       any later version published by the Free Software Foundation; with no
3864       Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A
3865       copy of the license is included in the section entitled "GNU Free
3866       Documentation License".
3867     </para>
3868   </blockquote>
3869   <para>
3870     If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
3871     replace the "with...Texts." line with this:
3872   </para>
3873   <blockquote>
3874     <para>
3875       with the Invariant Sections being LIST THEIR TITLES, with the
3876       Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
3877     </para>
3878   </blockquote>
3879   <para>
3880     If you have Invariant Sections without Cover Texts, or some other
3881     combination of the three, merge those two alternatives to suit the
3882     situation.
3883   </para>
3884   <para>
3885     If your document contains nontrivial examples of program code, we
3886     recommend releasing these examples in parallel under your choice of free
3887     software license, such as the GNU General Public License, to permit their
3888     use in free software.
3889   </para>
3890 </appendix>
3891
3892 </article>
3893
3894 <!-- Keep this comment at the end of the file
3895 Local variables:
3896 mode: sgml