Bugs fixed.
[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 Development 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
18         </address>
19      </affiliation>
20   </author>
21
22    <revhistory>
23       <revision>
24          <revnumber>v0.01</revnumber>
25          <date>27 March 2001</date>
26          <authorinitials>bch</authorinitials>
27           <revremark>
28           Initial Release
29          </revremark>
30       </revision>
31    </revhistory>
32
33   <abstract>
34     <indexterm>
35       <primary>fswd</primary>
36     </indexterm>
37
38     <para>
39      This HOWTO is designed for people with experience in programming
40      and some skills in managing a software project but who are new to
41      the world of Free Software. This document is meant to act as a
42      guide to the non-technical aspects of free software development
43      and was written to act as a crash course in the people skills
44      that aren't taught to commercial coders but that can make or
45      break a free software project.
46     </para>
47   </abstract>
48
49  </artheader>
50
51 <!-- Section1: intro -->
52
53  <sect1 id="intro">
54    <title>Introduction</title>
55
56    <indexterm>
57     <primary>fswd!introduction</primary>
58    </indexterm>
59
60   <para>
61    Skimming through freshmeat.net provides mountains of reasons for this
62    HOWTO's existence--the Internet is littered with excellently
63    written and useful programs that have faded away into the Universe
64    of Free Software Forgottenness. This dismal scene made me ask
65    myself, "Why?"
66   </para>
67
68   <para>
69    This HOWTO tries to do a lot of thing (probably too many), but it
70    can't answer that question and won't attempt it. What this HOWTO
71    will attempt to do is give your Free Software project a fighting
72    chance--an edge. If you write a piece of crap that no one is
73    interested in, you can read this HOWTO until you can recite it in
74    your sleep and your project will probably fail. Then again, you can
75    write a beautiful, relevant piece of software and follow every
76    instruction in this HOWTO and your software may still not make
77    it. Sometimes life is like that. However, I'll go out a limb and
78    say that if you write a great, relevant pieces of software and
79    ignore the advise in this HOWTO, you'll probably fail <emphasis>
80    more often</emphasis>.
81   </para>
82
83   <para>
84    A lot of the information in this HOWTO is best called common
85    sense. Of course, as any debate on interfaces will prove, what is
86    common sense to some programmers proves totally unintuitive to
87    others. After explaining bits and pieces of this HOWTO to Free
88    Software developers on several occasions, I realized that writing
89    this HOWTO might provide a useful resource and a forum for
90    programmers to share ideas about what has and has not worked for
91    them.
92   </para>
93
94   <para>
95    As anyone involved in any of what seems like an unending parade of
96    ridiculous intellectual property clashes will attest to, a little
97    bit of legalese proves important.
98   </para>
99
100 <!-- Section2: copyright -->
101
102   <sect2 id="copyright">
103    <title>Copyright Information</title>
104
105    <para>
106     This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is
107     distributed under the terms of the Linux Documentation Project
108     (LDP) license, stated below.
109    </para>
110
111    <para>
112     Unless otherwise stated, Linux HOWTO documents are copyrighted by
113     their respective authors. Linux HOWTO documents may be reproduced
114     and distributed in whole or in part, in any medium physical or
115     electronic, as long as this copyright notice is retained on all
116     copies. Commercial redistribution is allowed and encouraged;
117     however, the author would like to be notified of any such
118     distributions.
119    </para>
120
121    <para>
122     All translations, derivative works, or aggregate works
123     incorporating any Linux HOWTO documents must be covered under this
124     copyright notice. That is, you may not produce a derivative work
125     from a HOWTO and impose additional restrictions on its
126     distribution. Exceptions to these rules may be granted under
127     certain conditions; please contact the Linux HOWTO coordinator at
128     the address given below.
129    </para>
130
131    <para>
132     In short, we wish to promote dissemination of this information
133     through as many channels as possible. However, we do wish to
134     retain copyright on the HOWTO documents, and would like to be
135     notified of any plans to redistribute the HOWTOs.
136    </para>
137
138    <para>
139     If you have any questions, please contact
140     <email>linux-howto@metalab.unc.edu</email>
141    </para>
142   </sect2>
143
144 <!-- Section2: disclaimer -->
145
146   <sect2 id="disclaimer">
147    <title>Disclaimer</title>
148
149    <para>
150     No liability for the contents of this documents can be accepted.
151     Use the concepts, examples and other content at your own risk.  As
152     this is a new edition of this document, there may be errors and
153     inaccuracies, that may of course be damaging to your system.
154     Proceed with caution, and although this is highly unlikely, the
155     author(s) do not take any responsibility for that.
156    </para>
157
158    <para>
159     All copyrights are held by their by their respective owners, unless
160     specifically noted otherwise.  Use of a term in this document
161     should not be regarded as affecting the validity of any trademark
162     or service mark.
163    </para>
164
165    <para>
166     Naming of particular products or brands should not be seen 
167     as endorsements.
168    </para>
169
170    <para>
171     You are strongly recommended to take a backup of your system 
172     before major installation and backups at regular intervals.
173    </para>
174   </sect2>
175
176 <!-- Section2: newversions-->
177
178   <sect2 id="newversions">
179    <title>New Versions</title>
180
181     <indexterm>
182      <primary>fswd!news on</primary>
183     </indexterm>
184
185    <para>
186     This is the initial release. It is written to be released to
187     developers for critique and brainstorming and submitted to
188     Hampshire College for academic credit. Please keep in mind that
189     this version of the HOWTO is still in an infant stage and will be
190     revised extensively before it hits the LDP.
191    </para>
192
193    <para>
194     The latest version number of this document should always be listed
195     on <ulink url="http://people.debian.org/~mako/">my webpage at
196     Debian</ulink>.
197    </para>
198
199    <para>
200     The newest version of this HOWTO will always be made available at
201     the same website, in a variety of formats:
202    </para>
203
204    <para>
205    <itemizedlist>
206
207     <listitem>
208      <para>
209       <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO/t1.html">HTML</ulink>.
210      </para>
211     </listitem>
212
213
214     <listitem>
215      <para>
216       <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.html">HTML (single page)</ulink>.
217      </para>
218     </listitem>
219
220     <listitem>
221      <para>
222        <ulink URL="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.txt">plain text</ulink>.
223      </para>
224     </listitem>
225
226     <listitem>
227      <para>
228       <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.ps.gz">compressed postscript</ulink>.
229      </para>
230     </listitem>
231
232     <listitem>
233      <para>
234       <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.sgml.gz">Compressed SGML source</ulink>.
235      </para>
236     </listitem>
237    </itemizedlist>
238    </para>
239   </sect2>
240
241 <!-- Section2: credits -->
242
243   <sect2 id="credits">
244    <title>Credits</title>
245
246    <para>
247     In this version I have the pleasure of acknowledging:
248    </para>
249
250    <para>
251     <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
252     Source Development with CVS</emphasis> published by the Coriolis
253     Open Press. Large parts of his book are available <ulink
254     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
255     the book are available under the GPL and constitute the best
256     tutorial on CVS I've ever seen. The rest of the book covers, "the
257     challenges and philosophical issues inherent in running an Open
258     Source project using CVS." The book does a good job of covering
259     some of the subjects brought up in this HOWTO and much
260     more. <ulink url="http://cvsbook.red-bean.com">The book's
261     website</ulink> has information on ordering the book and provides
262     several translations of the chapters on CVS. I you are seriously
263     interested in running a Free Software project, you want this
264     book. I tried to mention Fogel in sections of this HOWTO where I
265     knew I was borrowing directly from his ideas. If I missed any, I'm
266     sorry, and I'll try and have those fixed in future versions.
267    </para>
268    
269    <para>
270     Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
271     com</email>
272    </para>
273
274    <para>
275     Also providing support material, and inspiration for this HOWTO is
276     Eric S. Raymond for his prolific, consistent, and carefully
277     crafted arguments, Lawrence Lessig for reminding me of the
278     importance of Free Software. Additionaly, I want to thank every
279     user and developer involved with the <ulink
280     url="http://www.debian.org">Debian Project</ulink>. The project
281     has provided me with a home, a place to practice Free Software
282     advocacy, a place to make a difference, a place to learn from
283     those how have been involved with the movement much longer than I,
284     and proof of a Free Software project that definitely, definitely
285     works.
286    </para>
287
288    <para>
289     Above all, I want to thank <emphasis>Richard Stallman</emphasis>
290     for his work at the Free Software Foundation and for never giving
291     up. Stallman provides and articulates the philosophical basis that
292     attracts me to Free Software and that drives me towards writing a
293     document to make sure it succeeds. RMS can always be emailed at
294     <email>rms (at) gnu (dot) org</email>.
295    </para>
296
297   </sect2>
298
299 <!-- Section2: feedback -->
300
301   <sect2 id="feedback">
302    <title>Feedback</title>
303
304    <para>
305     Feedback is always and most certainly welcome for this
306     document. Without your submissions and input, this document
307     wouldn't exist. Do you feel that something is missing? Don't
308     hesitate to contact me to have me write a chapter, section, or
309     subsection or to write one yourself. I want this document to be a
310     product of the Free Software development process that it heralds
311     and I believe that its ultimate success will be rooted in this
312     fact. Please send your additions, comments and criticisms to the
313     following email address : <email>mako@debian. org</email>.
314    </para>
315    </sect2>
316
317 <!-- Section2: translations -->
318
319   <sect2 id="translations">
320    <title>Translations</title>
321
322    <para>
323     I know that not everyone speaks English. Translations are nice and
324     I'd love for this HOWTO to gain the kind of international reach
325     afforded by a translated version.
326    </para>
327
328    <para>
329     However, this HOWTO is still young and I have to yet to be
330     contacted about a translation so English is all that is currently
331     available. If you would like to help with or do a translation, you
332     will gain my utmost respect and admiration and you'll get to be
333     part of a cool process. If you are at all interested, please don't
334     hesitate to contact me at: <email>mako@debian.org</email>.
335    </para>
336    </sect2>
337  </sect1>
338
339 <!-- Section1: intro: END -->
340
341 <!-- Section1: starting -->
342
343  <sect1 id="starting">
344   <title>Starting a Project</title>
345
346    <indexterm>
347     <primary>fswd!starting</primary>
348    </indexterm>
349   <para>
350    With very little argument, the beginning is most difficult part of
351    successful free software development. Laying a firm foundation will
352    determine whether your project flourishes or withers away and
353    dies. It is also the subject that is of most immediate interest to
354    anyone reading this document as a tutorial.
355   </para>
356
357   <para>
358    Starting a project involves a dilemma that you as a developer must
359    try and deal with: No potential user for your program is interested
360    in a program that doesn't work. Simultaneously, the development
361    process that you want to employ holds involvement of users as
362    prerequisit to working software.
363   </para>
364
365   <para>
366    It is in these dangerous initial moments that anyone working to
367    start a free software project must try and strike a balance along
368    these lines. One of the most important ways that someone trying to
369    start a project can work towards this balance is by establishing a
370    solid framework for the development process through some of the
371    suggestions mentioned in this section.
372   </para>
373
374
375 <!-- Section2: chooseproject-->
376
377   <sect2 id="chooseproject">
378    <title>Choosing a Project</title>
379
380    <para>
381     If you are reading this document, there's a good chance you
382     already have an idea for a project in mind. Chances are pretty
383     good, it fills in a percieved gap by doing something that no other
384     free software process does or by doing something in a way the is
385     unique enough to necessitate a separate project.
386    </para>
387
388    <sect3 id=identifyidea>
389     <title>Identify and articulate your idea</title>
390     <para>
391      Eric S. Raymond writes about how free software projects start in
392      his paper, <quote>The Cathedral and the Bazaar,</quote> which
393      comes as required reading for any free software development. It
394      is available <ulink
395      url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
396      </ulink>.
397     </para>
398
399     <para>
400      In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
401      that: <emphasis>Every good work of software starts by scratching
402      a developers itch.</emphasis> Raymond's now widely accepted
403      hypothesis is that new free software programs are written, first
404      and foremost, to solve a specific problem facing the developer.
405     </para>
406
407     <para>
408      If you have an idea for a program in mind, chances are good that
409      it targets a specific problem or <quote>itch</quote> you want to
410      see scratched. This idea is the project. Articulate it
411      clearly. Write it out. Describe the problem you will attack in
412      detail. The success of your project in tackling a particular
413      problem will be tied to your ability to identify that problem
414      early on. Find out exactly what it is that you want your project
415      to do.
416     </para>
417    </sect3>
418
419    <sect3 id=evalulateidea>
420     <title>Evaluate your idea</title>
421
422     <para>
423      In evaluating your idea, you need to first ask yourself a few
424      questions.  Before you move any further into this HOWTO, you need
425      to determine if the free software development model really is the
426      right one for your project. Obviously, since the program
427      scratches your itch, you are definitely interested in seeing it
428      implemented in code. But, because one hacker coding in solitude
429      fails to qualify as a free software development effort, you need
430      to ask yourself the question: <emphasis>Is anybody else
431      interested?</emphasis>
432     </para>
433
434     <para>
435      Sometimes the answer is a simple <emphasis>no</emphasis>. If you
436      want to write a set of scripts to sort <emphasis>your</emphasis>
437      <acronym>MP3</acronym> collection on your machine, maybe the free
438      software development model is not the best one to
439      choose. However, if you want to write a set of scripts to sort
440      <emphasis>anyone's</emphasis> <acronym>MP3</acronym>s, a free
441      software project might fill a useful gap.
442     </para>
443
444     <para>
445      Luckily, The Internet is a place so big and so diverse that,
446      chances are, there is someone, somewhere, who shares your
447      interests and how feels the same <quote>itch.</quote> It is the
448      fact that there are so many people with so many similar needs and
449      desires that introduces the second major question: <emphasis>Has
450      somebody already had your idea or a reasonably similar
451      one?</emphasis>
452     </para>
453
454      <sect4 id=evalwhere>
455       <title>Finding Similar Projects</title>
456
457      <para>
458       There are places you can go on the web to try and answer the
459       question above. If you have experience with the free software
460       community, you are probably already familiar with all of these
461       sites. All of the resources listed bellow offer searching of
462       their databases:
463      </para>
464
465      <para>
466      <variablelist>
467        <varlistentry>
468         <term>freshmeat.net:</term>
469         <listitem>
470          <para><ulink url="http://freshmeat.net">freshmeat.net</ulink>
471          describes itself as, <quote>the Web's largest index of Linux
472          and Open Source software</quote> and its reputation along
473          these lines is totally unparalleled and unquestioned. If you
474          can't find it on freshmeat, its doubtful that you (or anyone
475          else) will find it anywhere.</para>
476         </listitem>
477        </varlistentry>
478
479        <varlistentry>
480         <term>Slashdot:</term>
481         <listitem>
482          <para><ulink url="http://slashdot.org">Slashdot</ulink>
483          provides <quote>News for Nerds: Stuff that Matters,</quote>
484          which usually includes discussion of free software, open
485          source, technology, and geek culture new and events. It is
486          not unusual for an particularly sexy development effort to be
487          announced here so it definitely worth checking.</para>
488         </listitem>
489        </varlistentry>
490
491        <varlistentry>
492         <term>SourceForge:</term>
493         <listitem>
494          <para><ulink url="http://sourceforge.net">SourceForge</ulink>
495          houses and facilitates a growing number of open source and
496          free software projects. It is also quickly becoming a nexus
497          and an necessary stop for free software
498          developers. SourceForge's <ulink
499          url="http://sourceforge.net/softwaremap/trove_list.php">software
500          map</ulink> and <ulink url="http://sourceforge.net/new/"> new
501          releases</ulink> pages should be necessary stops before
502          embarking on a new free software project. SourceForge also
503          provides a at <ulink
504          url="http://sourceforge.net/snippet/">Code Snippet
505          Library</ulink> which contains useful reusable chunks of code
506          in an array of languaqges which can come in useful in any
507          project.</para>
508         </listitem>
509        </varlistentry>
510
511        <varlistentry>
512         <term>Google and Google's Linux Search:</term>
513         <listitem>
514          <para><ulink url="http://www.google.com">Google</ulink> and
515          <ulink url="http://www.google.com/linux"> Google's Linux
516          Search</ulink>, provide powerful web searches that may
517          reveal people working on similar projects. It is not a
518          catalog of software or news like freshmeat or Slashdot, but
519          it is worth checking before you begin pouring your effort
520          into a redundant project.</para>
521         </listitem>
522        </varlistentry>
523
524       </variablelist>
525      </para>
526     </sect4>
527
528     <sect4 id=evalhow>
529      <title>Deciding to Proceed</title>
530      <para>
531       Once you have successful charted the terrain and have an idea
532       bout what kinds of similar free software projects exist, every
533       developer needs to decide whether to proceed with their own
534       project. It is rare that a new project seeks to accomplish a
535       goal that is not similar to or related to the goal of another
536       project. Anyone starting a new project needs to ask themselves:
537       <quote>Will the new project be duplicating work done by another
538       project? Will the new project be competing for developers with
539       an existing project? Can the goals of the new project be
540       accomplished by adding functionality to an existing
541       project?</quote>
542      </para>
543
544      <para>
545       If the answer to any of these questions is <quote>yes,</quote>
546       try to contact the developer of the existing project(s) in
547       question and see if he or she might be willing to collaborate
548       with you.
549      </para>
550
551      <para>
552       This may be the single most difficult aspect of free software
553       development for many developers but it is an essential one. It
554       is easy to become fired up by an idea and be caught up in the
555       momentum and excitement of a new project. It is often extremely
556       difficult to do but, it is important that any free software
557       developer remember that the best interests of the free software
558       community and the quickest way to accomplish ones own project's
559       goals and the goals of similar project can often be accomplished
560       by <emphasis>not</emphasis> starting a new project.
561      </para>
562
563     </sect4>
564    </sect3>
565   </sect2>
566
567 <!-- Section2: licensing-->
568
569   <sect2 id="licensing">
570    <title>Licensing your Software</title>
571    
572    <para>
573     On one (somewhat simplistic) level, the difference between a piece
574     of free software and a piece of propriety software is the
575     license. A license helps you as the developer by protecting your
576     legal rights to have your software distributed under your terms
577     and helps demonstrate to those who wish to help you or your
578     project that they are encouraged to join.
579    </para>
580    
581    <sect3 id="chooselicense">
582     <title>Choosing a license</title>
583
584     <para>
585      Any discussion of licenses is also sure to generate at least a
586      small flame war as there are strong feelings that some free
587      software licenses are better than others. This discussion also
588      brings up the question of <quote>Open Source Software</quote> and
589      the debate around <quote>Open Source Software</quote> and
590      <quote>Free Software</quote>. However, because I've written the
591      Free Software Development HOWTO and not the Open Source
592      Development HOWTO, my own allegiances in this argument are in the
593      open.
594     </para>
595
596     <para>
597      In attempting to reach a middle ground through diplomacy without
598      sacrificing my own philosophy, I recommend picking any license
599      that conforms to the <ulink
600      url="http://www.debian.org/social_contract">Debian Free Software
601      Guidelines</ulink>. Originally compiled by the Debian project
602      under Bruce Perens, the <acronym>DFSG</acronym> form the first
603      version of the Open Source definition. Examples of free licenses
604      given by the <acronym>DFSG</acronym> are the
605      <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
606      Artistic License. 
607     </para>
608
609     <para>
610      Conforming to the definition of Free Software offered by Richard
611      Stallman in <ulink
612      url="http://www.gnu.org/philosophy/free-sw.html"><quote>The Free
613      Software Definition</quote></ulink>, any of these licenses will
614      uphold,<quote> users' freedom to run, copy, distribute, study,
615      change and improve the software.</quote> There are plenty of
616      other licenses that also conform to the <acronym>DFSG</acronym>
617      but sticking with a more common license will offer the advantage
618      of immediate recognition and understanding.
619     </para>
620
621     <para>
622      In attempting a more in-depth analysis, I agree with Karl Fogel's
623      description of licenses as falling into two groups: those that
624      are the <acronym>GPL</acronym> and those that are not the
625      <acronym>GPL</acronym>.
626     </para>
627
628     <para>
629      Personally, I license all my software under the
630      <acronym>GPL</acronym>. Created and protected by the Free
631      Software Foundation and the GNU Project, the
632      <acronym>GPL</acronym> is the license for the Linux kernel,
633      GNOME, Emacs, and the vast majority of GNU/Linux software. It's
634      the obvious choice but I believe it is a good one. Any BSD
635      fanatic will urge you to remember that there is a viral aspect to
636      the <acronym>GPL</acronym>that prevents the mixture of
637      <acronym>GPL</acronym>'ed code with non-<acronym>GPL</acronym>'ed
638      code. To many people (myself included), this is a benefit, but to
639      some, it is a major drawback.
640     </para>
641
642     <para>
643      The three major license can be found at the following locations:
644     </para>
645
646     <para>
647      <itemizedlist>
648       <listitem>
649        <para><ulink url="http://www.gnu.org/copyleft/gpl.html">The GNU
650        General Public License</ulink></para>
651       </listitem>
652       <listitem>
653        <para><ulink url="http://www.debian.org/misc/bsd.license">The
654        BSD License</ulink></para>
655       </listitem>
656       <listitem>
657        <para><ulink
658        url="http://language.perl.com/misc/Artistic.html">The Artistic
659        License</ulink></para>
660       </listitem>
661      </itemizedlist>
662     </para>
663
664     <para>
665      <emphasis>In any case, please read through any license before
666      your release your software. As the primary developer, you can't
667      afford any license surprises.</emphasis>
668     </para>
669    </sect3>
670
671    <sect3 id="licensechoose">
672     <title>The mechanics of licensing</title>
673
674     <para>
675      The text of the <acronym>GPL</acronym> offers <ulink
676      url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
677      description</ulink> of mechanics of applying a license to a piece
678      of software. My quick checklist for applying a license includes:
679     </para>
680
681     <para>
682      <itemizedlist>
683      
684       <listitem>
685        <para>If at all possible, attach and distribute a full copy of
686        the license with the source and binary in a separate
687        file.</para>
688       </listitem>
689
690       <listitem>
691        <para>At the top of each source file in your program, attach a
692        notice of copyright and information on where the full license
693        can be found. The <acronym>GPL</acronym> recommends that each
694        file begin with:</para>
695
696        <screen>
697 <emphasis>one line to give the program's name and an idea of what it does.</emphasis>
698 Copyright (C) yyyy  name of author
699
700 This program is free software; you can redistribute it and/or
701 modify it under the terms of the GNU General Public License
702 as published by the Free Software Foundation; either version 2
703 of the License, or (at your option) any later version.
704
705 This program is distributed in the hope that it will be useful,
706 but WITHOUT ANY WARRANTY; without even the implied warranty of
707 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
708 GNU General Public License for more details.
709
710 You should have received a copy of the GNU General Public License
711 along with this program; if not, write to the Free Software
712 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
713        </screen>
714
715        <para>
716         The <acronym>GPL</acronym> goes on to recommend attaching
717         information on contacting you (the author) via email or
718         physical mail.
719       </para>
720       </listitem>
721
722       <listitem>
723        <para>
724         The <acronym>GPL</acronym> continues and suggests that if your
725         program runs in an interactive mode, you should write the
726         program to output a notice each time it enters interactive
727         mode that includes a message like this one that points to more
728         information about the programs licensing:
729        </para>
730
731        <screen>
732 Gnomovision version 69, Copyright (C) year name of author
733 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
734 type `show w'.  This is free software, and you are welcome
735 to redistribute it under certain conditions; type `show c' 
736 for details.
737        </screen>
738       </listitem>
739
740       <listitem>
741        <para>Finally, it might be helpful to include a
742        <quote>copyright disclaimer</quote> with the program from an
743        employer or a school if you work as a programmer or if it seems
744        like your employer or school might be able to make an argument
745        for ownership of your code later on. Its often needed but there
746        are plenty of free software developers who have gotten into
747        trouble and wish they had attained one.</para>
748       </listitem>
749
750      </itemizedlist>
751     </para>    
752    </sect3>
753
754    <sect3 id="licensewarning">
755     <title>Final license warning</title>
756
757     <para>
758      Please, please, please, place your software under some
759      license. It may not seem important, and to you, it may not be,
760      but licenses <emphasis>are</emphasis> important. For a piece of
761      software to be included in the Debian GNU/Linux distribution, it
762      must have a license that fits the <ulink
763      url="http://www.debian.org/social_contract">Debian Free Software
764      Guidelines</ulink>. If you have no license, your program can not
765      be distributed as a package in Debian until you re-release it
766      under a free license. Please save yourself and others trouble by
767      releasing the first version of your software with a clear
768      license.
769     </para>
770
771    </sect3>
772
773  </sect2>
774
775 <!-- Section2: chooseversioning-->
776
777   <sect2 id="chooseversioning">
778    <title>Choosing a Method of Version Numbering</title>
779
780    <para>
781     <emphasis>The most important thing about a system of version
782     numbering is that there is one.</emphasis> It may seem pedantic to
783     emphasize this point but you'd be surprised at the number of
784     scripts and small programs that pop up without any version number
785     at all.
786    </para>
787
788    <para>
789     <emphasis>The second most important thing about a system of
790     numbering is that the numbers always go up.</emphasis> Automatic
791     version tracking systems and people's sense of order in the
792     universe will fall apart if version numbers don't rise. It doesn't
793     <emphasis>really</emphasis> matter if 2.1 is a big jump and
794     2.0.005 is a small jump but it does matter that 2.1 is more recent
795     than 2.0.005.
796    </para>
797
798    <para>
799     Follow these two simple rules and you will not go (too)
800     wrong. Still, there are several version numbering systems that are
801     well known, useful, and that might be worth looking into before
802     you release your first version.
803    </para>
804
805    <variablelist>
806     <varlistentry>
807      <term>Linux kernel version numbering:</term>
808      <listitem>
809       <para>The Linux kernel uses a versioning system where any odd
810       minor version number refers to an development or testing release
811       and any even minor version number refers to a stable
812       version. Think about it for a second. Under this system, 2.1 and
813       2.3 kernels were and always will be development or testing
814       kernels and 2.0, 2.2. and 2.4 kernels are all production code
815       with a higher degree of stability and more testing.
816      </para>
817
818       <para>
819        Whether you plan on having a split development model (as
820        described in <xref linkend="branches">) or only one version
821        released at a time, my experience with several free software
822        projects and with the Debian project has taught me that use of
823        Linux's version numbering system is worth taking into
824        consideration. In Debian, all minor versions are stable
825        distributions (2.0, 2.1, etc). However, many people assume that
826        2.1 is an unstable or development version and continue to use
827        an older version until they get so frustrated with the lack of
828        progress development that they complain and figure the system
829        out. If you never release an odd minor version but only release
830        even ones, nobody is hurt, and less people are confused. It's
831        worth taking into consideration.
832       </para>
833      </listitem>
834     </varlistentry>
835
836     <varlistentry>
837      <term>Wine version numbering:</term>
838      <listitem>
839       <para>Because of the unusual nature of wine's development where
840       the not-emulator is constantly improving but not working towards
841       any immediately achievable goal, wine is released every three
842       weeks. Wine does this by labeling their releases in Year Month
843       Day format where each release might be labeled
844       <quote>wine-XXXXXXXX</quote> where the version from January 04,
845       2000 would be <quote>wine-20000104</quote>. For certain
846       projects, Year Month Day format can make a lot of sense.
847       </para>
848      </listitem>
849     </varlistentry>
850
851     <varlistentry>
852      <term>Mozilla milestones:</term>
853      <listitem>
854       <para>When one considers Netscape 6 and vendor versions, the
855       mozilla's project development structure is one of the most
856       complex free software model available. Their version numbering
857       has reflected the unique situation in which it is
858       developed.
859       </para>
860
861       <para>
862        Mozilla's version numbering structure has historically been
863        made up of milestones. From the beginning of the mozilla
864        project, the goals of the project in the order and degree to
865        which they were to be achieved were charted out on a series of
866        <ulink url="http://www.mozilla.org/roadmap.html">road
867        maps</ulink>. Major points and achievements along these
868        road-maps were marked as milestones. Therefore, mozilla was
869        built and distributed nightly as "nightly builds" but on a day
870        when the goals of a milestone on the road-map had been reached,
871        that particular build was marked as a milestone release.
872       </para>
873
874       <para>
875        While I haven't seen this method employed in any other projects
876        to date, I like the idea and think that it might have value in
877        any testing or development branch of a large free application
878        under heavy development.
879       </para>
880      </listitem>
881     </varlistentry>
882
883    </variablelist>
884   </sect2>
885
886 <!-- Section2: documentation-->
887
888   <sect2 id="documentation">
889    <title>Documentation</title>
890
891    <para>
892     A huge number of otherwise fantastic free software applications
893     have withered and died because their author was the only person
894     who knew how to use them fully. Even if your program is written
895     primarily for a techno-savvy group of users, documentation is
896     helpful and even necessary for the survival of your project. You
897     will learn later in <xref linkend="releasing"> that you should
898     always release something that is usable. <emphasis>A piece of
899     software without documentation is not usable.</emphasis>
900    </para>
901
902    <para>
903     There are lots of different people for whom to document and
904     therefore there are lots of ways to document your project. The
905     idea of documentation in source code to help facilitate
906     development by a large community is vital but it falls outside the scope
907     of this HOWTO. This being the case, this section deals mostly
908     useful tactics for user-directed documentation.
909    </para>
910
911    <para>
912     A combination of tradition and necessity has resulted in a
913     semi-regular system of documentation in most free software
914     projects that is worth following. Both users and developers expect
915     to be able to get documentation in several ways and it's essential
916     that you provide the information they are seeking in a form they
917     can read if your project is ever going to get off the
918     ground. People have come to expect:
919    </para>
920
921    <sect3>
922     <title>Man pages</title> 
923
924     <para>Your users will want to be able to type <quote>man
925     projectname</quote> end up with a nicely formatted man page
926     highlighting the basic use of yourapplication. Make sure that
927     before you release your program, you've planned for this.
928     </para>
929
930     <para>
931      Man pages are not difficult to write. There is excellent
932      documentation on the man page writing process available through the
933      <quote>The Linux Man-Page-HOWTO</quote> available through the
934      Linux Documentation project <acronym>(LDP)</acronym> written by
935      Jens Schweikhardt. It is available <ulink
936      url="http://www.schweikhardt.net/man_page_howto.html">from
937      Schweikhardt's site</ulink> or <ulink
938      url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the
939      <acronym>LDP</acronym></ulink>.
940     </para>
941
942     <para>
943      It is also possible to write man pages using DocBook SGML and
944      convert them into man pages. Because man pages are so simple and
945      the DocBook method relatively new, I have not been able to follow
946      this up but would love help from anyone who can give me more
947      information on how exactly this is done.
948     </para>
949    </sect3>
950
951    <sect3>
952     <title>Command line accessible documentation</title>
953
954     <para>
955      Most users will expect some basic amount of documentation to be
956      easily available from the command line. For few programs should
957      this type of documentation extend for more than one screen (24 or
958      25 lines) but it should cover the basic usage, a brief (one or
959      two sentence) description of the program, a list of the commands
960      with explanations, all the major options (also with
961      explanations), and a pointer to more in-depth documentation for
962      those who need it. The command line documentation for Debian's
963      apt-get serves as an excellent example and a useful model:
964     </para>
965
966     <screen>
967 apt 0.3.19 for i386 compiled on May 12 2000  21:17:27
968 Usage: apt-get [options] command
969        apt-get [options] install pkg1 [pkg2 ...]
970
971 apt-get is a simple command line interface for downloading and
972 installing packages. The most frequently used commands are update
973 and install.
974
975 Commands:
976    update - Retrieve new lists of packages
977    upgrade - Perform an upgrade
978    install - Install new packages (pkg is libc6 not libc6.deb)
979    remove - Remove packages
980    source - Download source archives
981    dist-upgrade - Distribution upgrade, see apt-get(8)
982    dselect-upgrade - Follow dselect selections
983    clean - Erase downloaded archive files
984    autoclean - Erase old downloaded archive files
985    check - Verify that there are no broken dependencies
986
987 Options:
988   -h  This help text.
989   -q  Loggable output - no progress indicator
990   -qq No output except for errors
991   -d  Download only - do NOT install or unpack archives
992   -s  No-act. Perform ordering simulation
993   -y  Assume Yes to all queries and do not prompt
994   -f  Attempt to continue if the integrity check fails
995   -m  Attempt to continue if archives are unlocatable
996   -u  Show a list of upgraded packages as well
997   -b  Build the source package after fetching it
998   -c=? Read this configuration file
999   -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
1000 See the apt-get(8), sources.list(5) and apt.conf(5) manual
1001 pages for more information and options.
1002     </screen>
1003
1004     <para>
1005      It has become a GNU convention to make this type of information
1006      accessible with the <quote>-h</quote> and the
1007      <quote>--help</quote> options. Most GNU/Linux users will expect
1008      to be able to retrieve basic documentation these ways so if you
1009      choose to use different method, be prepared for the flames and
1010      for the fallout that may result.
1011     </para>
1012    </sect3>
1013
1014    <sect3>
1015     <title>Files users will expect</title>
1016     <para>
1017      In addition to man pages and command-line help, there are certain
1018      files where people will look for documentation, especially in any
1019      package containing source code. In a source distribution, most of
1020      these files can be stored in a the root directory of the source
1021      distribution or in a subdirectory of the root called
1022      <quote>doc</quote> or <quote>Documentation</quote>. Common files
1023      places in these places include:
1024     </para>
1025
1026     <para>
1027      <variablelist>
1028       <varlistentry>
1029        <term>README or Readme</term>
1030
1031        <listitem>
1032         <para>A document containing all the basic installation,
1033         compilation, and even basic use instructions that make up the
1034         bare minimum information needed to get the program up and
1035         running. A README is not your chance to be verbose but needs
1036         to be concise and effective. An ideal README is at least 30
1037         lines long and more no more than 250.</para>
1038        </listitem>
1039
1040       </varlistentry>
1041       <varlistentry>
1042        <term>INSTALL or Install</term>
1043
1044        <listitem>
1045         <para>The INSTALL file should be much shorter than the README
1046         file and should quickly and concisely describe how to build
1047         and install the program. Usually an INSTALL file simply
1048         instructs the user to run <quote>./configure; make; make
1049         install</quote> and touches on any unusual options or actions
1050         that may be necessary. More advanced users can usually avoid
1051         INSTALL files but it's good practice to at least glance at one
1052         to understand what can be expected. For most relatively
1053         standard install procedures and for most programs, INSTALL
1054         files are as short as possible are rarely over 100
1055         lines.</para>
1056        </listitem>
1057
1058       </varlistentry>
1059       <varlistentry>
1060        <term>Changelog, ChangeLog, CHANGELOG, or changelog</term>
1061
1062        <listitem>
1063         <para>A changelog is a simple file that every well-managed
1064         free software project should include. A changelog is simple
1065         the file that, as its name implies, logs or documents the
1066         changes to a program. The most simple way to do a changelog is
1067         to simply keep a file with the source code for your program
1068         and add a section to the top of the changelog with each
1069         release describing what has been, changed, fixed, or added to
1070         the program. It's a good idea to post the changelog onto the
1071         website as well because it can help people decide whether they
1072         want or need to upgrade to a newer version or wait for a more
1073         significant upgrade.</para>
1074        </listitem>
1075
1076       </varlistentry>
1077       <varlistentry>
1078        <term>NEWS</term>
1079
1080        <listitem>
1081         <para>A NEWS file and a ChangeLog are similar. A news file is
1082         not typically sorted by version but just whenever new features
1083         are added, the developer responisble will make a note in the
1084         NEWS file. NEWS files should not have to changed before a
1085         release (they should be kept up to date all along) but it's
1086         usually a good idea to check first anyway because often people
1087         just forget to keep them as current as they should.</para>
1088        </listitem>
1089
1090       </varlistentry>
1091       <varlistentry>
1092        <term><acronym>FAQ</acronym></term>
1093
1094        <listitem>
1095         <para>For those of you that don't already
1096         know. <acronym>FAQ</acronym> stands for Frequently Asked
1097         Questions and a FAQ is a collection of exactly that. FAQs
1098         are not difficult to make. Simply make a policy that if you
1099         are asked a question or see a question on a mailing list two
1100         or more times, add it the question (and its answer) to your
1101         FAQ. FAQs are more optional than the files listed above but
1102         they can save your time, increase usability, and decrease
1103         headaches on all sides.</para>
1104        </listitem>
1105
1106       </varlistentry>
1107      </variablelist>
1108     </para>
1109    </sect3>
1110
1111    <sect3>
1112     <title>Website</title> 
1113     <para>
1114      It's only idirectly an issue of documentation but a good website
1115      is quickly becoming an essential part of any free software
1116      project's documentation. Your website should provide access to
1117      documentation (in <acronym>HTML</acronym> if possible). It should
1118      also include a section for news and events around your program
1119      and a section that details the process of getting involved with
1120      development or testing and creates an open invitation. It should
1121      also supply links to any mailing lists, similar websites, and
1122      provide a direct link to all the available ways of downloading
1123      your software.
1124     </para>
1125    </sect3>
1126
1127    <sect3>
1128     <title>Other documentation hints</title>
1129
1130     <para>
1131      It doesn't hurt to distribute any documentation for your program
1132      from your website or anywhere else (FAQs etc) with the
1133      program. Make a FAQ by cutting and posting common questions and
1134      answers from a mailing list or your own email. Then, don't
1135      hesitate through this in the programs tarball. If people don't
1136      need it, they will delete it. I can repeat it over and over:
1137      <emphasis>Too much documentation is not a sin.</emphasis>
1138     </para>
1139
1140     <para>
1141      All your documentation should be in plaintext, or, in cases where
1142      it is on your website primarily, in HTML. Everyone can cat a
1143      file, everyone has a pager, (almost) everyone can render
1144      HTML. <emphasis>You are welcome to distribute information in PDF,
1145      PostScript, RTF, or any number of other widely used formats but
1146      this information must also be available in plaintext or HTML or
1147      people will be very angry at you.</emphasis>
1148     </para>
1149    </sect3>
1150   </sect2>
1151
1152 <!-- Section2: presentation -->
1153
1154   <sect2 id="presentation">
1155    <title>Other Presentation Issues</title>
1156    <para>
1157     Many of the remaining issues surrounding the creation of a new
1158     free software program fall under what most people describe as
1159     common sense issues. Still, they are worth noting briefly in
1160     hopes that they may remind a developer of something they may have
1161     forgotten.
1162    </para>
1163
1164    <sect3>
1165     <title>Package formats</title>
1166     <para>
1167      Package formats may differ depending on the system you are
1168      developing for. For windows based software, Zip archives (.zip)
1169      usually serve as the package format of choice. If you are
1170      developing for GNU/Linux, *BSD, or any UN*X, make sure that your
1171      source code is always available in tar'ed and gzip'ed format
1172      (.tar.gz). UNIX compress (.Z) has gone out of style and
1173      usefulness and faster computers have brought bzip2 (.bz2) into
1174      the spot-lit as a more effective compression medium. I now make
1175      all my releases available in both gzip'ed and bzip2'ed formats.
1176     </para>
1177
1178     <para>
1179      Binary packages are largely distribution specific. You can build
1180      binary packages against a current version of a major
1181      distribution, you will only make your users happy. Try to foster
1182      relationships with users or developers of large distribution to
1183      develop a system for consistent binary packages. It's often a
1184      good idea to provide RedHat <acronym>RPM</acronym>'s (.rpm),
1185      Debian deb's (.deb) and source <acronym>RPM</acronym>'s
1186      <acronym>SRPM</acronym>'s. Binary packages can also be compiled
1187      against a specified system with specified libraries and
1188      distributed in tar.gz format as well. <emphasis>Remember: While
1189      these binaries packages are nice, getting the source packaged and
1190      released should always be your priority. Your users or fellow
1191      developers can and will do the the binary packages for
1192      you.</emphasis>
1193     </para>
1194    </sect3>
1195
1196    <sect3>
1197     <title>Useful tidbits and presentation hints</title>
1198
1199     <para>
1200      Other useful hints include:
1201     </para>
1202
1203     <para>
1204      <itemizedlist>
1205
1206       <listitem>
1207        <para>
1208         <emphasis>Make sure that your program can always be found in a
1209         single location.</emphasis> Often this means that you have a
1210         single directory accessible via <acronym>FTP</acronym> or
1211         <acronym>HTTP</acronym> where the newest version will be
1212         quickly recognized. One effective technique is a provide a
1213         symlink called <quote>projectname-latest</quote> that is
1214         always pointing to the most recent released or development
1215         version of your free software project. Keep in mind that this
1216         location will recieve many requests for downloads around
1217         releases so make sure that the server you choose for this
1218         purpose has adequate bandwidth.
1219        </para>
1220       </listitem>
1221
1222       <listitem>
1223        <para>
1224         <emphasis>Make sure that there is a consistent email address
1225         for bug reports.</emphasis> It's usually a good idea to make
1226         this something that is NOT your primary email address like
1227         projectname@host or projectname-bugs@host. This way if you
1228         ever decide to hand over maintainership or if your email
1229         address changes, you simply need to change where this email
1230         address forwards. It also will allow for more than one person
1231         to deal with the influx of mail that is created if your
1232         project becomes as huge as you hope it will.
1233        </para>
1234       </listitem>
1235
1236      </itemizedlist>
1237     </para>
1238
1239    </sect3>
1240   </sect2>
1241  </sect1>
1242
1243 <!-- Section1: starting: END -->
1244
1245 <!-- Section1: developers -->
1246
1247  <sect1 id="developers">
1248   <title>Maintaining a Project: Interacting with Developers</title>
1249   <indexterm>
1250    <primary>fswd!developers</primary>
1251   </indexterm>
1252
1253   <para>
1254    Once you have gotten your project started, you have overcome the
1255    most difficult hurdles in the development process of your
1256    program. Laying a firm foundation is essential, but the development
1257    process itself is equally important and provides quite a few
1258    opportunities for failure. In the next two sections, I will cover
1259    running a project by discussing how to maintain a project through
1260    interactions with developers and with users.
1261   </para>
1262
1263   <para>
1264    In releasing your program, your program becomes free software. This
1265    transition is more than just a larger user base. By releasing your
1266    program as free software, <emphasis>your</emphasis> software
1267    becomes the <emphasis>free software community's</emphasis>
1268    software. The direction of your software's development will be
1269    reshaped, redirected, and fully determined by your users and, to a
1270    larger extent, by other developers in the community.
1271   </para>
1272
1273   <para>
1274    The major difference between free software development and
1275    propriety software development is the developer base. As the leader
1276    of a free software project, you need to attract and keep developers
1277    in a way that leaders of proprietary software projects simply don't
1278    have to worry about. <emphasis>As the person leading development of
1279    a free software project, you must harness the work of fellow
1280    developers by making responsible decisions and by responsibly
1281    choosing not to make decisions. You have to direct developers
1282    without being overbearing or bossy. You need to strive to earn
1283    respect and never forget to give it out.</emphasis>
1284   </para>
1285
1286 <!-- Section2: delegation  -->
1287
1288   <sect2 id="delegation">
1289    <title>Delegating Work</title>
1290
1291    <para>
1292     By now, you've hypothetically followed me through the early
1293     programming of a piece of software, the creation of a website and
1294     system of documentation and and we've gone ahead and (as will be
1295     discussed in <xref linkend="releasing">) released it to the rest
1296     of the world. Times passes, and if things go well, people become
1297     interested and want to help. The patches begin flowing in.
1298    </para>
1299
1300    <para>
1301     <emphasis>Like the parent of any child who grows up, it's now time
1302     to wince and smile and do most difficult thing in any parents
1303     life: It's time to let go.</emphasis>
1304    </para>
1305
1306    <para>
1307     Delegation is the political way of describing this process of
1308     <quote>letting go.</quote> It is the process of handing some of
1309     the responsibility and power over your project to other responsible
1310     and involved developers. It is difficult for anyone who has
1311     invested a large deal of time and energy into a project but it
1312     essential for the growth of any free software project. One person
1313     can only do so much. A free software project is nothing
1314     without the involvement of a group of developers. A group of
1315     developers can only be maintained through respectful and
1316     responsible leadership and delegation.
1317    </para>
1318
1319    <para>
1320     As your project progresses, you will notice people who are putting
1321     significant amounts of time and effort into your project. These
1322     will be the people submitting the most patches, posting most on
1323     the mailing lists, engaging in long email discussions. It is your
1324     responsibility to contact these people and to try and shift some of
1325     the power and responsibility of your position as the project's
1326     maintainer onto them (if they want it). There are several easy
1327     ways you can do this:
1328    </para>
1329
1330    <sect3>
1331     <title>How to delegate</title>
1332  
1333     <para>
1334      You may find that other developers seem even more experienced or
1335      knowledgeable than you. Your job as a maintainer does not mean
1336      you have to have to be the best or the brightest. It means you
1337      need are responsible for showing good judgment and for
1338      recognizing which solutions are maintainable and which are not. 
1339     </para>
1340     <para>
1341      Like anything, its easier to watch others delegate than to do it
1342      yourself. In a sentence: <emphasis>Keep an eye out for other
1343      qualified developers who show an interest and sustained
1344      involvement with your project and try and shift responsibility
1345      towards them.</emphasis> The following ideas might be good places
1346      to start or good sources of inspiration:
1347     </para>
1348  
1349     <sect4>
1350      <title>Allow a larger group of people write access to your CVS
1351      repository and make real efforts towards rule by a
1352      committee</title>
1353
1354      <para>
1355       <ulink url="http://httpd.apache.org/">Apache</ulink> is an
1356       example of a project that is run by small group of developers
1357       who vote on major technical issues and the admission of new
1358       members and all have write access to the main source
1359       repository. Their process is detailed <ulink
1360       url="http://httpd.apache.org/ABOUT_APACHE.html">online.</ulink>
1361      </para>
1362
1363      <para>
1364       The <ulink url="http://www.debian.org/"> Debian Project</ulink>
1365       is an extreme example of rule by committee. At current count,
1366       more than 700 developers have full responsibility for certain
1367       aspects of the projects. All these developers can upload into
1368       the main FTP servers, and vote on major issues. Direction for
1369       the project is determined by the project's <ulink
1370       url="http://www.debian.org/social_contract">social
1371       contract</ulink> and a <ulink
1372       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
1373       facilitate this system, there are special teams (i.e. the
1374       install team, the Japanese language team) as well as a technical
1375       committee and a project leader. The leader's main responsibility
1376       is to, <quote>Appoint Delegates or delegate decisions to the
1377       Technical Committee.</quote>
1378      </para>
1379
1380      <para>
1381       While both of these projects operate on a scale that your
1382       project will not (at least initially), their example is
1383       helpful. Debian's idea of a project who lead who can do
1384       <emphasis>nothing</emphasis> but delegate can serve as a
1385       caricature of how a project can involve and empower a huge
1386       number of developers and grow to a huge size.
1387      </para>
1388
1389     </sect4>
1390
1391     <sect4 id="releasemanager">
1392      <title>Publicly appoint someone as the release manager for a
1393        specific release.</title>
1394
1395      <para>
1396       A release manager is usually responsible for coordinating
1397       testing, enforcing a code freeze, being responsible for
1398       stability and quality control, packaging up the software, and
1399       placing it in the appropriate places to be downloaded.
1400      </para>
1401
1402      <para>
1403       This use of the release manager is a good way to give yourself a
1404       break and to shift the responsibility for accepting and
1405       rejecting patches to someone else. It is a good way of very
1406       clearly defining a chunk of work on the project as belonging to
1407       a certain person and its a great way of giving yourself room to
1408       breath.
1409      </para>
1410     </sect4>
1411
1412     <sect4 id="delegatebranch">
1413      <title>Delegate control of an entire branch.</title>
1414      <para>
1415       If your project chooses to have branches (as described in <xref
1416       linkend="branches">), it might be a good idea to appoint someone
1417       else to be the the head of a branch. If you like focusing your
1418       energy on development releases and the implementation of new
1419       features, hand total control over the stable releases to a
1420       well-suited developer.
1421      </para>
1422
1423      <para>
1424       The author of Linux, Linus Torvalds, came out and crowned Alan
1425       Cox as <quote>the man for stable kernels.</quote> All patches
1426       for stable kernels go to Alan and, if Linus were to be taken
1427       away from work on Linux for any reason, Alan Cox would be more
1428       than suited to fill his role as the acknowledged heir to the
1429       Linux maintainership.
1430      </para>
1431     </sect4>
1432    </sect3> 
1433   </sect2>
1434
1435 <!-- Section2: patching -->
1436
1437   <sect2 id="patching">
1438    <title>Accepting and Rejecting Patches</title>
1439    <para>
1440     This HOWTO has already touched on the fact that as the maintainer
1441     of a free software project, one of primary and most important
1442     responsibilities will be accepting and rejecting patches submitted
1443     to you by other developers.
1444    </para>
1445
1446    <sect3>
1447     <title>Technical judgment</title>
1448
1449     <para>
1450      In <emphasis>Open Source Development with CVS</emphasis>, Karl
1451      Fogel makes a convincing argument that the most important things
1452      to keep in mind when rejecting or accepting patches are:
1453     </para>
1454
1455     <para>
1456      <itemizedlist>
1457
1458       <listitem>
1459        <para>A firm knowledge of the scope of your program (that's the
1460        <quote>idea</quote> I talked about in <xref linkend="chooseproject">);</para>
1461       </listitem>
1462       
1463       <listitem>
1464        <para>The ability to recognize, facilitate, and direct
1465        <quote>evolution</quote> of your program so that the program
1466        can grow and change and incorporate functionality that was
1467        originally unforeseen;</para>
1468       </listitem>
1469
1470       <listitem>
1471        <para>The necessity to avoid digressions that might expand the
1472        scope of the program too much and result and push the project
1473        towards an early death under its own weight and
1474        unwieldiness.</para>
1475       </listitem>
1476
1477      </itemizedlist>
1478     </para>
1479
1480     <para>
1481      These are the criteria that you as a project maintainer should
1482      take into account each time you receive a patch.
1483     </para>
1484
1485     <para>
1486      Fogel elaborates on this again and states the <quote>the
1487      questions to ask yourself when considering whether to implement
1488      (or approve) a change are:</quote>
1489     </para>
1490
1491     <para>
1492      <itemizedlist>
1493
1494       <listitem>
1495        <para>Will it benefit a significant percentage of the program's
1496        user community?</para>
1497       </listitem>
1498
1499       <listitem>
1500        <para>Does it fit within the program's domain or within a
1501        natural, intuitive extension of that domain?</para>
1502       </listitem>
1503
1504      </itemizedlist>
1505     </para>
1506
1507     <para>
1508      The answers to these questions are never straightforward and its
1509      very possible (and even likely) that the person who submitted the
1510      patch may feel differently about the answer to those questions
1511      than you do. However, if you feel that that the answer to either
1512      of those questions is <quote>no,</quote> it is your responsibility
1513      to reject the change. If you fail to do this, the project will
1514      become unwieldy and unmaintainable and will ultimately fail.
1515     </para>
1516    </sect3>
1517
1518    <sect3>
1519     <title>Rejecting patches</title>
1520
1521     <para>
1522      Rejecting patches is probably the most difficult and the most
1523      sensitive job that the maintainer of any free software project
1524      has to face. But sometimes it has to be done. I mentioned earlier
1525      (in <xref linkend="developers"> and in <xref
1526      linkend="delegation">) that any developer needs to try and
1527      balance your responsibility and power to make what you think are
1528      the best technical decisions with the fact that you will lose
1529      support from other developers if you seem like you are on a power
1530      trip or being overly bossy or possessive of a community-based
1531      project. I recommend that you keep three major facts in mind when
1532      rejecting patches (or other changes):
1533     </para>
1534
1535     <sect4>
1536      <title>Bring it to the community</title>
1537      <para>
1538       One of the best ways of justifying a decision to reject a patch
1539       and working to not seem like you keep an iron grip on your
1540       project is by not making the decision alone at all. It might
1541       make sense to turn over larger proposed changes or more
1542       difficult decisions to a development mailing list where they can
1543       be discussed. There will be some patches (bug fixes, etc.) which
1544       will definitely be accepted and some that you feel are so off
1545       base that they do not even merit further discussion. It is those
1546       that fall into the grey area between these two groups that might
1547       merit a quick forward to a mailing list.
1548      </para>
1549
1550      <para>
1551       I recommend this process wholeheartedly. As the project
1552       maintainer you are worried about making the best decision for
1553       the project, for the project's users and developers, and for
1554       yourself as a responsible project leader. Turning things over to
1555       an email list will demonstrate your own responsibility and
1556       responsive leadership as it tests and serves the interests of
1557       your software's community.
1558      </para>
1559     </sect4>
1560
1561     <sect4>
1562      <title>Technical issues are not always good justification</title>
1563      <para>
1564       Especially towards the beginning, you will find that many
1565       changes are difficult to implement, introduce new bugs, or have
1566       other technical problems. Try to see past these. Especially with
1567       added functionality, good ideas do not always come from good
1568       coders. Technical merit is a valid reason to postpone an
1569       application of a patch but it is not always a good reason to
1570       reject a change outright. Even small changes are worth the
1571       effort of working with the developer submitting the patch to
1572       iron out bugs and incorporate the change if you thing you think
1573       it seems like a good addition to your project. The effort on
1574       your part will work to make your project a community project and
1575       it will pull a new or less experienced developer onto your
1576       project and even teach them something that might help them in
1577       making their next patch.
1578      </para>
1579     </sect4>
1580
1581     <sect4>
1582      <title>Common courtesy</title>
1583      <para>
1584       It should go without saying but, <emphasis>above all and in all
1585       cases, just be nice.</emphasis> If someone has an idea and cares
1586       about it enough to write some code and submit a patch, they
1587       care, they are motivated, and they are already involved. Your
1588       goal as the maintainer is make sure they submit again. They may
1589       have thrown you a dud this time but next time may be the idea or
1590       feature that revolutionizes your project. 
1591      </para>
1592
1593      <para>
1594       It is your responsibility to first justify your choice to not
1595       incorporate their change clearly and concisely. Then thank
1596       them. Let them know that you a appreciate their help and feel
1597       horrible that you can't incorporate their change. Let them know
1598       that you look forward to their staying involved and you hope
1599       that the next patch or idea meshes better with your project
1600       because you appreciate their work and want to see it in the
1601       project. If you have ever had a patch rejected after putting a
1602       large deal of time, thought, and energy into it, you remember
1603       how it feels and it feels bad. Keep this in mind when you have
1604       to let someone down. It's never easy but you need to do
1605       everything you can to make it as not-unpleasant as possible.
1606      </para>
1607     </sect4>
1608    </sect3>
1609   </sect2>
1610
1611 <!-- Section2: branches  -->
1612
1613   <sect2 id="branches">
1614    <title>Stable and Development Branches</title>
1615
1616    <para>
1617     The idea of stable and development branches has already been
1618     described briefly in <xref linkend="chooseversioning"> and in
1619     <xref linkend="delegatebranch">. These allusions attest to some of
1620     the ways that multiple branches can affect your software. Branches
1621     can let you avoid (to some extent) some of the problems around
1622     rejecting patches (as described in <xref linkend="patching">) by
1623     allowing you to temporarily compromise the stability of your
1624     project without affecting those users who need that stability.
1625    </para>
1626
1627    <para>
1628     The most common way of branching your project is to have one
1629     branch that is stable and one that is for development. This is the
1630     model followed by the Linux kernel that is described in <xref
1631     linkend="chooseversioning">. In this model, there is always one
1632     branch that is stable and always one that is in
1633     development. Before any new release, the development branch goes
1634     into a <quote>feature freeze</quote> as described in <xref
1635     linkend="freezing"> where major changes and added features are
1636     rejected or put on hold under the development kernel is released
1637     as the new stable branch and major development resumes on the
1638     development branch. Bug fixes and small changes that are unlikely
1639     to have any large negative repercussions are incorporated into the
1640     stable branch as well as the development branch.
1641    </para>
1642
1643    <para>
1644     Linux's model is an extreme one. On many projects, there is no
1645     need to have two versions always available. It may make sense to
1646     have two versions only near a release. The Debian project has
1647     historically made both a stable and an unstable distribution
1648     available but has expanded to this to include: stable, unstable,
1649     testing, experimental, and (around release time) a frozen
1650     distribution that only incorporates bug fixes during the
1651     transition from unstable to stable. There are few projects whose
1652     size would necessitate a system like Debian's but this use of
1653     branches helps demonstrate how they can be used to balance
1654     consistent and effective development with the need to make regular
1655     and usable releases.
1656    </para>
1657
1658    <para>
1659     In trying to set up a development tree for yourself, there are
1660     several things that might be useful to keep in mind:
1661    </para>
1662
1663    <para>
1664     <variablelist>
1665
1666      <varlistentry>
1667       <term>Minimize the number of branches</term>
1668       <listitem>
1669        <para>Debian may be able to make good use of four or five
1670        branches but it contains gigabytes of software in over 5000
1671        packages compiled for a 5-6 different architectures. For you,
1672        two is probably a good number. Too many branches will confuse
1673        your users (I can't count how many times I had to describe
1674        Debian's system when it only had 2 and sometimes 3 branches!),
1675        potential developers and even yourself. Branches can help but
1676        they come at a cost so use them very sparingly.</para>
1677       </listitem>
1678      </varlistentry>
1679
1680      <varlistentry>
1681       <term>Make sure that all your different branches are explained</term>
1682       <listitem>
1683        <para>As I mentioned in the preceding paragraph, different
1684        branches <emphasis>will</emphasis> confuse your users. Do
1685        everything you can to avoid this by clearly explaining the
1686        different branches in a prominent page on your website and in a
1687        Readme file in the <acronym>FTP</acronym> or
1688        <acronym>HTTP</acronym> directory.</para>
1689
1690        <para>
1691         I might also recommend against a mistake that I think Debian
1692         has made. The terms <quote>unstable,</quote>
1693         <quote>testing,</quote> and <quote>experimental</quote> are
1694         vague and difficult to rank in order of stability (or
1695         instability as the case may be). Try explaining to someone
1696         that <quote>stable</quote> actually means <quote>ultra
1697         stable</quote> and that <quote>unstable</quote> doesn't
1698         actually include any unstable software but is really stable
1699         software that is untested as a distribution.
1700        </para>
1701
1702        <para>
1703         If you are going to use branches, especially early on, keep in
1704         mind that people are conditioned to understand the terms
1705         <quote>stable</quote> and <quote>development</quote> and you
1706         probably can't go wrong with this simple and common division of
1707         branches.
1708        </para>
1709       </listitem>
1710      </varlistentry>
1711
1712      <varlistentry>
1713       <term>Make sure all your branches are always available</term>
1714       <listitem>
1715        <para>Like a lot of this document, this should probably should
1716        go without saying but experience has taught me that it's not
1717        always obvious to people. It's a good idea to physically split
1718        up different branches in different directories or directory
1719        trees on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
1720        site. Linux accomplishes this by having kernels in a v2.2 and a
1721        v2.3 subdirectory where it is immediately obvious (after you
1722        know their version numbering scheme) which directory is for the
1723        most recent stable and the current development releases. Debian
1724        accomplishes this by naming all their distribution with names
1725        (i.e. woody, potato, etc.) and then changing symlinks named
1726        <quote>stable,</quote> <quote>unstable</quote> and
1727        <quote>frozen</quote> to point to which ever distribution (by
1728        name) is in whatever stage. Both methods work and there are
1729        others. In any case, it is important that different branches
1730        are always available, are accessible from consistent locations,
1731        and that different branches are clearly distinguished from each
1732        other so your users know exactly what they want to be
1733        downloading and where to get it.</para>
1734       </listitem>
1735      </varlistentry>
1736
1737     </variablelist>
1738    </para>
1739
1740   </sect2>
1741
1742 <!-- Section2: otherdev -->
1743
1744   <sect2 id="otherdev">
1745    <title>Other Development issues</title>
1746    <para>
1747     There are more issues surrounding interaction with developers in a
1748     free software project that I can not touch on in great detail in a
1749     HOWTO of this size. Please don't hesitate to contact me if you see
1750     any major omissions.
1751    </para>
1752
1753    <para>
1754      Other smaller issues that are worth mentioning are:
1755    </para>
1756
1757    <sect3 id="freezing">
1758     <title>Freezing</title>
1759     <para>
1760      For those projects that choose to adopt a split development model
1761      (<xref linkend="branches">), freezing is a concept that is worth
1762      becoming familiar with. 
1763     </para>
1764
1765     <para>
1766      Freezes come in two major forms. A <quote>feature freeze</quote>
1767      is a period when no significant functionality is added to a
1768      program. It is a period where established functionality (even
1769      skeletons of barely working functionality) can be improved and
1770      perfected. It is a period where bugs are fixed. This type of
1771      freeze is usually applied some period (a month or two) before a
1772      release. It is easy to push a release back as you wait for
1773      <quote>one more feature</quote> and a freeze helps to avoid this
1774      situation by drawing the much needed line in the sand. It gives
1775      developers room they need to get a program ready for release.
1776     </para>
1777
1778     <para>
1779      The second type of freeze is a <quote>code freeze</quote> which
1780      is much more like a released piece of software. Once a piece of
1781      software has entered a code freeze, all changes to the code are
1782      frowned upon and only changes that fix known bugs are
1783      permitted. This type of freeze usually follows a <quote>feature
1784      freeze</quote> and directly precedes a release. Most released
1785      software is in what could be interpreted as a sort of high
1786      level<quote>code freeze.</quote>
1787     </para>
1788
1789     <para>
1790      Even if you never choose to appoint a release manager (<xref
1791      linkend="releasemanager">), you will have an easier time
1792      justifying the rejection or postponement of patches (<xref
1793      linkend="patching"> before a release with a publicly stated
1794      freeze in effect.
1795     </para>
1796    </sect3>
1797
1798    <sect3>
1799     <title>Forking</title>
1800     <para>
1801      Forks are the most extreme version of a branch. A fork is
1802      when a group of developers takes code from a free software
1803      project and actually starts a brand new free software
1804      project. The most famous example of a fork is Emacs and
1805      XEmacs. Both emacsen are based on an almost identical code-base
1806      but for technical, political, and philosophical reasons,
1807      development was split into two projects which now compete with
1808      each other.
1809     </para>
1810
1811     <para>
1812      The short version of the fork section is, <emphasis>don't do
1813      them.</emphasis> Forks force developers to choose one project to
1814      work with, cause nasty political divisions and redundancy of
1815      work.  Luckily, usually the threat of the fork is enough to scare
1816      the maintainer or maintainers of a project into changing the way
1817      they run their project to avoid it.
1818     </para>
1819
1820     <para>
1821      In his chapter on <quote>The Open Source Process,</quote> Karl
1822      Fogel describes how to do a fork if you absolutely must. If you
1823      have determined that is absolutely necessary and that the
1824      differences between you and the people threatening to fork are
1825      absolutely unresolvable, I recommend Fogel's book as a good place
1826      to start.
1827     </para>
1828    </sect3>
1829   </sect2>
1830  </sect1>
1831
1832 <!-- Section1: users -->
1833
1834  <sect1 id="users">
1835   <title>Maintaining a Project: Interacting with Users</title>
1836   <indexterm>
1837    <primary>fswd!users</primary>
1838   </indexterm>
1839
1840   <para>
1841    If you've worked your way up to here, congratulations, you are
1842    nearing the end of this document. This final section describes some
1843    of the situations in which you, in your capacity as project
1844    maintainer, will be interacting with users. It gives some
1845    suggestions on how these situations might be handled effectively.
1846   </para>
1847
1848   <para>
1849    Interacting with users is difficult. In our discussion of
1850    interaction with developers, the underlying assumption is that in a
1851    free software project, a project maintainer must constantly strive to
1852    attract and keep developers who can easily leave at any time.
1853   </para>
1854
1855   <para>
1856    Users in the free software community are different than developers
1857    and are also different than users in the world of proprietary
1858    software and they should be treated differently than either
1859    group. Some ways in which the groups differ significantly follow:
1860   </para>
1861
1862   <para>
1863    <itemizedlist>
1864
1865     <listitem>
1866      <para>The lines between users and developers are blurred in ways
1867      that is totally foreign to any proprietary development
1868      model. Your users are often your developers and vice
1869      versa.</para>
1870     </listitem>
1871
1872     <listitem>
1873      <para>In the free software world, you are often your users only
1874      choice. Because there is such an emphasis on not replicating the
1875      work of others in the free software community and because the
1876      element of competition present in the propriety software model is
1877      absent (or at least in an extremely different form) in the free
1878      software development model, you will probably be the only project
1879      that does what you do (or at least the only one that does what
1880      you do in the way that you do it). This means your responsiveness
1881      to your users is even more important than in the proprietary
1882      software world.</para>
1883     </listitem>
1884
1885     <listitem>
1886      <para>In an almost paradoxical situation, free software projects
1887      have less immediate or dire consequences for ignoring their users
1888      altogether--it is also often easier to do. Because you don't
1889      usually need to compete with another product in the free software
1890      model, chances are good that you will not be scrambling to gain
1891      the features of the competitor's newest program. This means that
1892      your development process will have to be directed either
1893      internally, by a commitment to your users or by both.</para>
1894     </listitem>
1895    </itemizedlist>
1896   </para>
1897
1898   <para>
1899    Trying to tackle this unique situation can only be done
1900    indirectly. Developers and maintainers need to listen to users and
1901    to try and be as responsive as possible. A solid knowledge of the
1902    situation recounted above is any free software developer's best tool
1903    for shifting his development or leadership style to fit the unique
1904    process of free software development. This chapters will try and
1905    introduce some of the more difficult or important points in any
1906    projects interactions with users and give some hints on how to
1907    tackle these.
1908   </para>
1909
1910 <!-- Section2: testing -->
1911
1912   <sect2 id="testing">
1913    <title>Testing and Testers</title>
1914
1915    <para>
1916     In addition to your users being your developers, they are also
1917     (and perhaps more commonly) your testers. Before I get flamed, I
1918     should rephrase my sentence: <emphasis>some</emphasis> of your
1919     users are your testers.
1920    </para>
1921
1922    <para>
1923     It is important that this distinction be made early on because not
1924     all of your users want to be testers. Many users want to use
1925     stable software and don't care if they don't have the newest
1926     greatest software with the latest and greatest features. These
1927     users except a stable, tested piece of software with major or
1928     obvious bugs worked out or openly declared and will be angry if
1929     they find themselves in a testing position. This is yet another
1930     way in which a split development model (as mentioned in <xref
1931     linkend="branches">) might come in handy.
1932    </para>
1933
1934    <sect3>
1935     <title>Automated testing</title>
1936     <para>
1937      For many programs, many common mistakes can be caught by
1938      automated means. Automated tests tend to be pretty good at
1939      catching errors that you've run into several times before or
1940      something you just forget. They are not very good at finding
1941      errors, even major ones, that were totally unforeseen.
1942     </para>
1943
1944     <para>
1945      CVS comes with a bourne shell script called sanity.sh that is
1946      worth looking at. Debian uses a program called lintian that
1947      checks Debian packages for all of the most common errors. While
1948      use of these scripts may not be possible, there is a host of
1949      other sanity checking software on the net that may be applicable
1950      (feel free to email any recommendations). None of these will
1951      create a bug-free release but they will avoid at least some major
1952      oversights. Finally, if your programs become a long term
1953      endeavor, you will find that there are certain errors that you
1954      tend to make over and over. Start a collection of scripts that
1955      check for these errors to help prevent them in the future.
1956     </para>
1957    </sect3>
1958
1959    <sect3>
1960     <title>Testing by testers</title>
1961     <para>
1962      For any program that depends on user interactivity, many bugs
1963      will only be uncovered through testing by users actually clicking
1964      the keys and pressing the mouse buttons. For this you need
1965      testers and as many testers as possible.
1966     </para>
1967
1968     <para>
1969      The most difficult part of testing is finding testers. It's
1970      usually a good tactic to post a message to a relevant mailing
1971      list or news group announcing a specific proposed release date
1972      and outline the functionality of the program. If you put some
1973      time into the announcement, you are sure to get a few bites.
1974     </para>
1975
1976     <para>
1977      The second most difficult part of testing is keeping your testers
1978      and keeping them actively involved in the testing
1979      process. Fortunately, there are some tried and true tactics that
1980      can applied towards this end:
1981     </para>
1982
1983     <para>
1984      <variablelist>
1985
1986       <varlistentry>
1987        <term>Make things simple for your testers</term>
1988        <listitem>
1989         <para>Your testers are doing you a favor so make it as easy as
1990         possible for them. This means that you should be careful to
1991         package your software in a way that is easy to find, unpack,
1992         install, and uninstall. This also means you should explain
1993         what you are looking for to each tester and make the means for
1994         reporting bugs simple and well established. The key is to
1995         provide as much structure as possible to make your testers'
1996         jobs easy and maintain as much flexibility as possible for
1997         those that want to do things a little differently.</para>
1998        </listitem>
1999       </varlistentry>
2000
2001       <varlistentry>
2002        <term>Be responsive to your testers</term>
2003        <listitem>
2004         <para>When your testers submit bugs, respond to them and
2005         respond quickly. Even if you are only responding to tell them
2006         that the bug has already been fixed, quick and consistent
2007         responses make them feel like their work is heard, important,
2008         and appreciated.</para>
2009        </listitem>
2010       </varlistentry>
2011
2012       <varlistentry>
2013        <term>Thank your testers</term>
2014        <listitem>
2015         <para>Thank them personally each time they send you
2016         patch. Thank them publicly in the documentation and the about
2017         section of your program. You appreciate your testers and your
2018         program would not be possible without their help. Make sure
2019         they know it. Pat them on the back to make sure the rest of
2020         the world knows it too. It will be appreciated more than you
2021         expected.</para>
2022        </listitem>
2023
2024       </varlistentry>
2025      </variablelist>
2026     </para>
2027
2028    </sect3>
2029   </sect2>
2030
2031 <!-- Section2: support  -->
2032
2033   <sect2 id="support">
2034    <title>Setting up Support Infrastructure</title>
2035
2036    <para>
2037     While testing is important, the large part of your interactions
2038     and responsibility to your users falls under the category of
2039     support. The best way to make sure your users are adequately
2040     supported in using your program is to set up a good infrastructure
2041     for this purpose so that your developers and users help each other
2042     and less of the burden falls on you. This way, people will also
2043     get quicker and better responses to their questions. This
2044     infrastructure comes in several major forms:
2045    </para>
2046
2047    <sect3>
2048     <title>Documentation</title>
2049     <para>
2050      It should not come as any surprise that the key element to any
2051      support infrastructure is good documentation. This topic was
2052      large covered in <xref linkend="documentation"> and will not be
2053      repeated here.
2054     </para>
2055    </sect3>
2056
2057    <sect3>
2058     <title>Mailing lists</title>
2059     <para>
2060      Aside from documentation, effective mailing lists will be your
2061      greatest tool in providing user support. Running a mailing list
2062      well is more complicated than installing mailing list software
2063      onto a machine.
2064     </para>
2065
2066     <sect4>
2067      <title>Separate lists</title>
2068      
2069      <para>
2070       A good idea is too separate your user and development mailing
2071       lists (perhaps into project-user@host and project-devel@host)
2072       and enforce the division. If people post a development question
2073       onto -user, politely ask them to repost it onto -devel and vise
2074       versa. Subscribe yourself to both groups and encourage all
2075       primarily developers to do the same.
2076      </para>
2077
2078      <para>
2079       This system provides that no one person is stuck doing all of
2080       the support work and works so that users learn more about the
2081       program, they can help newer users with their questions.
2082      </para>
2083     </sect4>
2084
2085     <sect4>
2086      <title>Choose mailing list software well</title>
2087      <para>
2088       Please don't make the selection of mailing list software
2089       impulsively. Please consider easy accessibility by users without
2090       a lot of technical experience so you want to be as easy as
2091       possible. Web accessibility to an archive of the list is also
2092       important.
2093      </para>
2094
2095      <para>
2096       The two biggest free software mailing list programs are <ulink
2097       url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
2098       and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
2099       long time advocate of majordomo, I would now recommend any
2100       project choose GNU Mailman. It fulfills the criteria listed
2101       above and makes it easier to do so. It provides a good mailing
2102       list program for a free software project maintainer as opposed
2103       to a good mailing list application for a mailing list
2104       administrator.
2105      </para>
2106
2107      <para>
2108       There are other things you want to take in setting up your
2109       list. If it is possible to gate your mailing lists to USENET and
2110       provide them in digest form as well as making them accessible on
2111       the web, you will please some users and work to make the support
2112       infrastructure slightly more accessible.
2113      </para>
2114     </sect4>
2115    </sect3>
2116
2117    <sect3>
2118     <title>Other support ideas</title>
2119
2120     <para>
2121      A mailing list and accessible documentation are far from all you
2122      can do to set up good user support infrastructure. Be
2123      creative. If you stumble across something works well, email me
2124      and I'll include it here in the HOWTO.
2125     </para>
2126
2127     <sect4>
2128      <title>Make your self accessible</title>
2129      <para>
2130       You can not put to few methods to access you. If you hang out in
2131       an <acronym>IRC</acronym> channel, don't hesitate to list in
2132       your projects documentation. List email and snail mail
2133       addresses, or ways to reach you via <acronym>ICQ</acronym>,
2134       <acronym>AIM</acronym>, or Jabber.
2135     </para>
2136     </sect4>
2137
2138     <sect4>
2139      <title>Bug management software</title>
2140      <para>
2141       For many large software projects, use of bug management software
2142       is essential to keep track of which bugs have been fixed, which
2143       bugs have not been fixed, and which bugs are being fixed by
2144       which people. Debian uses the <ulink
2145       url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
2146       (<acronym>BTS</acronym>) although it may not be best choice for
2147       every project (it seems to currently be buckling under its own
2148       weight. As well as a damn good web browser, the mozilla project
2149       has spawned a sub-project resulting in a bug tracking system
2150       called <ulink
2151       url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
2152       which has become extremely possible and which I like quite a
2153       bit.
2154      </para>
2155
2156      <para>
2157       These systems (and others like them) can be unwieldy so
2158       developers should be careful to not spend more time on the bug
2159       tracking system than on the bugs or the projects themselves. If
2160       a project continues to grow, use of a bug tracking system can
2161       provide an easy standard way for users and testers to report
2162       bugs and for developers and maintainers to fix them and track
2163       them in an orderly fashion.
2164      </para>
2165     </sect4>
2166    </sect3>
2167   </sect2>
2168
2169 <!-- Section2: releasing -->
2170
2171   <sect2 id="releasing">
2172    <title>Releasing Your Program</title>
2173
2174    <para>
2175     As mentioned earlier in the HOWTO, the first rule of releasing is,
2176     <emphasis>release something useful.</emphasis> Non-working or
2177     not-useful software will not attract anyone to your
2178     project. People will be turned off of your project and be likely
2179     to simply gloss over it next time they see a new version
2180     announced. Half-working software, if useful, will intrigue people,
2181     whet their appetites for versions to come, and encourage them to
2182     join the development process.
2183    </para>
2184
2185    <sect3>
2186     <title>When to release</title>
2187
2188     <para>
2189      Making the decision to release your software for the first time
2190      is an incredibly important and incredibly stressful decision. But
2191      it needs to be done. My advice is to try and make something that
2192      is complete enough to be usable and incomplete enough to allow
2193      for flexibility and room for imagination by your future
2194      developers. It's not an easy decision. Ask for help on a local
2195      Linux User Group mailing list or from a group of developer
2196      friends.
2197     </para>
2198
2199     <para>
2200      One tactic is to first do an <quote>alpha</quote> or
2201      <quote>beta</quote> release as described below in <xref
2202      linkend="alphabeta">. However, most of the guidelines described
2203      above still apply.
2204     </para>
2205
2206     <para>
2207      <emphasis>When you feel in your gut it is time and you feel
2208      you've weighed the situation well several times, cross your
2209      fingers and take the plunge.</emphasis>
2210    </para>
2211    </sect3>
2212
2213    <sect3>
2214     <title>How to release</title>
2215
2216     <para>
2217      If you've followed the guidelines described in this HOWTO up
2218      until this point, the mechanics of doing a release are going to
2219      be the easy part of releasing. If you have set up consistent
2220      distribution locations and the other infrastructure described in
2221      the preceding sections, releasing should be as simple as building
2222      the package, checking it once over, and uploading it into the
2223      appropriate place and then reflecting the release on your
2224      website.
2225     </para>
2226    </sect3>
2227
2228    <sect3 id="alphabeta">
2229     <title>Alpha, beta, and development releases</title>
2230
2231     <para>
2232      When contemplating releases, it worth considering the fact that
2233      not every release needs to be a full numbered release. Software
2234      users are accustomed to pre-releases but you must be careful to
2235      label these releases accurately or they cause more problems then
2236      they are worth.
2237     </para>
2238
2239     <para>
2240      <variablelist>
2241
2242       <varlistentry>
2243        <term>alpha releases</term>
2244        <listitem>
2245         <para>Alpha releases are expected to be unstable, perhaps a
2246         little unsafe, but definitely usable. Alpha versions should
2247         have full functionality and limited testing. They can have
2248         known bugs and kinks that have yet to be worked out. Before
2249         releasing an alpha, be sure to keep in mind that
2250         <emphasis>alpha releases are still releases</emphasis> and
2251         people are not going to be expecting a nightly build from the
2252         CVS source. An alpha should work and have minimal testing and
2253         bug fixing already finished.</para>
2254        </listitem>
2255       </varlistentry>
2256
2257       <varlistentry>
2258        <term>beta releases</term>
2259        <listitem>
2260         <para>Beta releases are general expected to be usable and
2261         slightly unstable, although definitely <emphasis>not
2262         unsafe.</emphasis> Beta releases usually preclude a full
2263         release by under a month. They can contain small known bugs
2264         but no major ones. All major functionality should be fully
2265         implemented although the exact mechanics can still be worked
2266         out. Beta releases are great tool to whet the appetites of
2267         potential users by giving them a very realistic view of where
2268         your project is going in the very near future and can help
2269         keep interest by giving people
2270         <emphasis>something.</emphasis></para>
2271        </listitem>
2272       </varlistentry>
2273
2274       <varlistentry>
2275        <term>development releases</term>
2276        <listitem>
2277         <para><quote>Development release</quote> is much more vague
2278         term than <quote>alpha</quote> or <quote>beta</quote>. I
2279         usually choose to reserve the term for discussion of a
2280         development branch although there are other ways to use the
2281         term. So many in fact, that I feel the term has been
2282         cheapened. The popular window manager <ulink
2283         url="http://www.enlightenment.org">Enlightenment</ulink> has
2284         released <emphasis>nothing but</emphasis> development
2285         releases. Most often, the term is used to describe releases
2286         that are not even to alpha or beta stages though and if I were
2287         to release a pre-alpha version of a piece of software in order
2288         to keep interest in my project live, this is probably how I
2289         would have to label it.</para>
2290        </listitem>
2291       </varlistentry>
2292
2293      </variablelist>
2294
2295     </para>
2296    </sect3>
2297   </sect2>
2298
2299 <!-- Section2: announcing  -->
2300
2301   <sect2 id="announcing">
2302    <title>Announcing Your Project</title>
2303
2304    <para>
2305     Well, you've done it. You've (at least for the purposes of this
2306     HOWTO) designed, built, and released your free software
2307     project. All that is left is for you to tell the world so they
2308     know to come and try it out and hopefully jump on board with
2309     development. If everything is in order as described above, this
2310     will be a quick and painless process. A quick announcement is all
2311     that it takes to put yourself on the free software communities
2312     radar screen.
2313    </para>
2314
2315    <sect3>
2316     <title>Mailing lists and USENET</title>
2317     <para>
2318      Email is still the way that most people on the Internet get their
2319      information. Its a good idea to send a message announcing your
2320      program to any relevant mailing list you know of and any relevant
2321      USENET discussion group. Karl Fogel recommends that use you
2322      simple subject describing the fact that the message is an
2323      announcement, the name of the program, the version, and a
2324      half-line long description of its functionality. This way, any
2325      interested user or developer will be immediately attracted to
2326      your announcement. Fogel's example looks like:
2327     </para>
2328
2329     <screen>Subject: ANN: aub 1.0, a program to assemble USENET binaries</screen>
2330
2331     <para>
2332      The rest of the email should describe the programs functionality
2333      quickly and concisely in no more than two paragraphs and should
2334      provide links to the projects webpage and direct links to
2335      downloads for those that want to try it right away.
2336     </para>
2337
2338     <para>
2339      You should repeat this announcement process consistently in the
2340      same locations for each subsequent release.
2341     </para>
2342    </sect3>
2343
2344    <sect3>
2345     <title>freshmeat.net</title>
2346     <para>
2347      Mentioned earlier in <xref linkend="evalwhere">, in today's free
2348      software community, announcements of your project on freshmeat
2349      are almost more important than announcements on mailing lists.
2350     </para>
2351
2352     <para>
2353      Visit the <ulink url="http://freshmeat.net">freshmeat.net
2354      website</ulink> or their <ulink
2355      url="http://freshmeat.net/add-project/">submit project
2356      page</ulink> to post your project onto their site and into their
2357      database. In addition to a large website, freshmeat provides a
2358      daily newsletter that highlights all the days releases and
2359      reaches a huge audience (I skim it every night for any
2360      interesting new releases).
2361     </para>
2362    </sect3>
2363   </sect2>
2364 </sect1>
2365
2366 </article>
2367
2368 <!-- Keep this comment at the end of the file
2369 Local variables:
2370 mode: sgml
2371 sgml-omittag:t
2372 sgml-shorttag:t
2373 sgml-namecase-general:t
2374 sgml-general-insert-case:lower
2375 sgml-minimize-attributes:nil
2376 sgml-always-quote-attributes:t
2377 sgml-indent-step:1
2378 sgml-indent-data:nil
2379 sgml-parent-document:nil
2380 sgml-exposed-tags:nil
2381 sgml-local-catalogs:nil
2382 sgml-local-ecat-files:nil
2383 End:
2384 -->

Benjamin Mako Hill || Want to submit a patch?