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

Benjamin Mako Hill || Want to submit a patch?