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