I've removed the section on code cram because it doesn't seem
[fspm_howto] / FreeSoftwareProjectManagementHOWTO.sgml
1 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
2
3 <article>
4
5 <!-- Header -->
6
7  <artheader>
8   <title>Free Software Development HOWTO</title>
9
10   <author>
11      <firstname>Benjamin</firstname>
12      <othername>Mako</othername>
13      <surname>Hill</surname>
14      <affiliation>
15         <address>
16            <email>mako@debian.org</email>
17
18         </address>
19      </affiliation>
20   </author>
21
22    <revhistory>
23       <revision>
24          <revnumber>v0.01</revnumber>
25          <date>25 March 2001</date>
26          <authorinitials>bch</authorinitials>
27           <revremark>
28           Initial Release
29          </revremark>
30       </revision>
31    </revhistory>
32
33   <abstract>
34     <indexterm>
35       <primary>fswd</primary>
36     </indexterm>
37
38     <para>
39      This HOWTO is designed for people with experience in programming
40      and some skills in managing a software project but who are new to
41      the world of Free Software. This document is meant to act as a
42      guide to the non-technical aspects of programming and was written
43      to act as a crash course in the people skills that aren't taught
44      to commercial coders but that can make or break a free software
45      project.
46     </para>
47   </abstract>
48
49  </artheader>
50
51 <!-- Section1: intro -->
52
53  <sect1 id="intro">
54    <title>Introduction</title>
55
56    <indexterm>
57     <primary>fswd!introduction</primary>
58    </indexterm>
59
60   <para>
61    For various reasons, this realease has been codenamed the
62    <emphasis>homade yogurt</emphasis> release.
63   </para>
64
65   <para>
66    New code names will appear as per industry standard
67    guidelines to emphasize the state-of-the-art-ness of this
68    document.
69   </para>
70
71   <para>
72    Skimming through Freshmeat provides mountains of reasons for this
73    HOWTO's existence--the Internet is littered with excellently
74    written and useful programs that have faded away into the Universe
75    of Free Software Forgottenness. This dismal scene made me ask
76    myself, "Why?"
77   </para>
78
79   <para>
80    This HOWTO tries to do a lot of thing (probably too many), but it
81    can't answer that question and won't attempt it. What this HOWTO
82    will attempt to do is give your Free Software project a fighting
83    chance-an edge. If you write a piece of crap that no one is
84    interested in, you can read this HOWTO until you recite it in your
85    sleep and your project will probably fail. Then again, you can
86    write a beautiful, relevent piece of software and follow every
87    instruction in this HOWTO and your software may still not make
88    it. Sometimes life is like that. However, I'll go out a limb and
89    say that if you write a great, relevant pieces of software and
90    ignore the advise in this HOWTO, you'll probably fail <emphasis>
91    more often</emphasis>.
92   </para>
93
94   <para>
95    A lot of the information in this HOWTO is best called common
96    sense. Of course, as any debate on interfaces will prove, what is
97    common sense to some programmers proves totally unintuitive to
98    others. After explaining bites and pieces of this HOWTO to Free
99    Software developers on several occasions, I realized that that
100    writing this HOWTO might provide a useful resource and a forum for
101    programmers to share ideas about what has and has not worked for
102    them. 
103   </para>
104
105   <para>
106
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
128     copyrighted by their respective authors. Linux HOWTO documents may
129     be reproduced and distributed in whole or in part, in any medium
130     physical or electronic, as long as this copyright notice is
131     retained on all copies. Commercial redistribution is allowed and
132     encouraged; however, the author would like to be notified of any
133     such 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
148     information through as many channels as possible. However, we do
149     wish to retain copyright on the HOWTO documents, and would like to
150     be 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.
167     As this is a new edition of this document, there may be errors
168     and inaccuracies, that may of course be damaging to your system.
169     Proceed with caution, and although this is highly unlikely,
170     the author(s) do 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 take 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     <indexterm>
197      <primary>(your index root)!news on</primary>
198     </indexterm>
199
200    <para>
201     This is the initial release. It is written to be released to
202     developers for critique and brainstorming and submitted to
203     Hampshire College for academic credit. Please keep in mind that
204     this version of the HOWTO is still in an infant stage and will be
205     revised extensively before it hits the LDP.
206    </para>
207
208    <para>
209     The latest version number of this document should always be listed
210     on <ulink url="http://people.debian.org/~mako/">my webpage at
211     Debian</ulink>.
212    </para>
213
214    <para>
215     The newest version of this HOWTO will always be made available at
216     the same website, in a variety of formats:
217    </para>
218
219    <para>
220    <itemizedlist>
221     <listitem>
222      <para>
223       <ulink url="http://people.debian.org/~mako/howto/fswd-howto.html">HTML</ulink>.
224      </para>
225     </listitem>
226
227     <listitem>
228      <para>
229        <ulink URL="http://people.debian.org/~mako/howto/fswd-howto.txt">plain text</ulink>.
230      </para>
231     </listitem>
232
233     <listitem>
234      <para>
235       <ulink url="http://people.debian.org/~mako/howto/fswd-howto.US.ps.gz">compressed 
236        postscript (US letter format)</ulink>.
237      </para>
238     </listitem>
239
240     <listitem>
241      <para>
242       <ulink url="http://people.debian.org/~mako/howto/fswd-howto.UF.ps.gz">compressed 
243        postscript (Universal format / 8.27x11in; 210x279mm)</ulink>.
244      </para>
245     </listitem>
246
247     <listitem>
248      <para>
249       <ulink url="http://people.debian.org/~mako/howto/fswd-howto.sgml">SGML source</ulink>.
250      </para>
251     </listitem>
252    </itemizedlist>
253    </para>
254   </sect2>
255
256 <!-- Section2: credits -->
257
258   <sect2 id="credits">
259    <title>Credits</title>
260
261    <para>
262     In this version I have the pleasure of acknowledging:
263    </para>
264
265    <para>
266     <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
267     Source Development with CVS</emphasis> published by the Coriolis
268     Open Press. Larges parts of the book are available <ulink
269     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
270     the book are available under the GPL and constitute the best
271     tutorial on CVS I have ever seen. The rest of the book covers,
272     "the challenges and philosophical issues inherent in running an
273     Open Source project using CVS." The book does a good job of
274     covering some of the subjects brought up in this HOWTO and much
275     more. <ulink url="http://cvsbook.red-bean.com">The book's
276     website</ulink> has information on ordering the book and provides
277     several translations of the chapters on CVS. I you are seriously
278     interested in running a Free Software project, you want this book.
279    </para>
280    
281    <para>
282     Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
283     com</email>
284    </para>
285    <para>
286     Also providing support and material, and inspiration for this
287     HOWTO is Eric S. Raymond for his prolific, consitent, and
288     carefully crafted arguments, to Lawrence Lessig for reminding me
289     of the importance of Free Software and to every user and developer
290     involved with the <ulink url="http://www.debian.org">Debian
291     Project</ulink>. The project has provided me with a home, a place
292     to practice Free Software advocacy and to make a difference, a
293     place to learn from those how have been involved with the movement
294     much longer than I, and an proof of a Free Software project that
295     <emphasis>definately, definately works</emphasis>.
296    </para>
297
298    <para>
299     Above all, I want to thank <emphasis>Richard Stallman</emphasis>
300     for his work at the Free Software Foundation and for never giving
301     up. Stallman provided the philosphical basis that attracts me to
302     Free Software and that drives me towards writing a document to
303     make sure it succeeds. RMS can always be emailed at <email>rms
304     (at) gnu (dot) org</email>.
305    </para>
306
307   </sect2>
308
309 <!-- Section2: feedback -->
310
311   <sect2 id="feedback">
312    <title>Feedback</title>
313
314    <para>
315     Feedback is most certainly welcome for this document. Without your
316     submissions and input, this document wouldn't exist. Something
317     missing? Don't hesitate to contact me and to write a chapter. I
318     want this document to be as much a product of the Free Software
319     development process that it heralds and I think its ultimate
320     success will be rooted in this fact. Please send your additions,
321     comments and criticisms to the following email address :
322     <email>mako@debian. org</email>.
323    </para>
324    </sect2>
325
326 <!-- Section2: translations -->
327
328   <sect2 id="translations">
329    <title>Translations</title>
330
331    <para>
332     I know that not everyone speaks English. Translations are nice and
333     I'd love for this HOWTO to gain the kind of international reach
334     afforded by a translated version.
335    </para>
336    <para>
337     However, this HOWTO is still young and I have to yet to be
338     contacted about a translation so English is all that is
339     available. If you would like to help with or do a translation, you
340     will gain my utmost respect and admiration and you'll get to be
341     part of a cool process. If you are at all interested, please don't
342     hesitate to contact me at: <email>mako@debian.org</email>.
343    </para>
344    </sect2>
345  </sect1>
346
347 <!-- Section1: intro: END -->
348
349 <!-- Section1: starting -->
350
351  <sect1 id="starting">
352   <title>Starting a Project</title>
353
354    <indexterm>
355     <primary>fswd!starting</primary>
356    </indexterm>
357   <para>
358    With very little argument, starting a project is most difficult
359    part of successful free software development. Laying a firm
360    foundation for your project will determine whether your project
361    flourishes or withers away and dies. It is also the subject that is
362    of most immediate interest to anyone reading this document as a
363    tutorial.
364   </para>
365
366   <para>
367    Starting a project also involves a dilemna that you as a developer
368    must try and deal with. No potential user for your program will be
369    interested by a program that doesn't work. Simultaneously, the
370    development process that you want to employ holds involvement of
371    users as essential to the process of the development that will
372    realize this working software.
373   </para>
374
375   <para>
376    It is in these dangerous initial moments that anyone working to
377    start a free software project must strike a balance. One of the
378    most important ways that omeone trying to start a project can work
379    towards this balance is by establishing a framework for the
380    development process through some of the ways mentioned in this
381    section.
382   </para>
383
384
385 <!-- Section2: chooseproject-->
386
387   <sect2 id="chooseproject">
388    <title>Choosing a Project</title>
389
390    <para>
391     If you are reading this document, there's a good chance you
392     already have an idea for a project in mind. Chances are pretty
393     good, it fills a gap by doing something that no other free
394     software process does or or does it in a way that is unique
395     enought to necessitate a seperate project.
396    </para>
397
398    <sect3 id=identifyidea>
399     <title>Indentify and articulate your idea</title>
400     <para>
401      Eric S. Raymond writes about how free software projects start in
402      his paper, "The Cathedral and the Bazaar" which comes as required
403      reading for any free softare development. You can find it <ulink
404      url="http://www.tuxedo.org/!esr/writings/cathedral-bazaar/">online
405      </ulink>.
406     </para>
407
408     <para>
409      In "The Cathedral and Bazaar," Raymond tells us that:
410      <emphasis>Every good work of software starts by scratching a
411      developers itch.</emphasis> Raymond now widely accepted
412      hypothesis is that new free software programs are written, first
413      and foremost, to solve a specific problem facing the developer.
414     </para>
415
416     <para>
417      If you have an idea for a program in mind, chances are good that
418      it it is targetting a specific problem or itch you want to see
419      scratched. <emphasis>This idea is the project. Articulate it
420      clearly. Write it out. Describe the problem you will attack in
421      detail. The success of your project in tackling a particular
422      problem will be tied to your ability to identify that problem
423      early on. Find out exactly what it is that you want your project
424      to do.</emphasis>
425     </para>
426    </sect3>
427
428    <sect3 id=evalulateidea>
429     <title>Evaluate your idea</title>
430
431     <para>
432      In evaluating your idea, you need to ask yourself questions.
433      Before you move any further into this HOWTO, you need to
434      determine if the free software development model really is the
435      right one for your project. Obviously, since the program
436      scratches your itch, you are definately interested in seeing it
437      implemented in code. But, because one hacker coding alone fails
438      to qualify as a free software development effort, you need to ask
439      yourself the question: <emphasis>Is anybody else
440      interested?</emphasis>
441     </para>
442
443     <para>
444      Sometimes the answer is <emphasis>no</emphasis>. If you want to
445      write a set of scripts to sort <emphasis>your</emphasis> MP3
446      collection on your machine, maybe the free software development
447      model is not the best one to choose. However, if you want to
448      write a set of scripts to sort <emphasis>anyone's</emphasis>
449      MP3s, a free software project might fill a useful gap.
450     </para>
451
452     <para>
453      Luckily, The Internet is a place so big and diverse that, chances
454      are, there is someone, somewhere, who shares your interests and
455      how feels the same itch. It is the fact that there are so many
456      people with so many similar needs and desires that introduces the
457      second major question: <emphasis>Has somebody already had your
458      idea or a reasonably similar one?</emphasis>
459     </para>
460
461      <sect4 id=evalwhere>
462       <title>Finding Similar Projects</title>
463
464      <para>
465       There are places you can go on the web to try and answer this
466       question. If you have experience with the free software
467       community, you are probably already familiar with all of these
468       sites. All of the resources listed bellow offer searching of
469       their databases:
470      </para>
471
472      <para>
473      <variablelist>
474        <varlistentry>
475         <term>freshmeat.net:</term>
476         <listitem>
477          <para><ulink url="http://freshmeat.net">freshmeat</ulink>
478          describes itself as, <quote>the Web's largest index of Linux
479          and Open Source software</quote> and its reputation along
480          these lines remains unquestioned. If you can't find it on
481          freshmeat, its doubtful that you'll find it indexed anywhere
482          else.</para>
483         </listitem>
484        </varlistentry>
485
486        <varlistentry>
487         <term>Slashdot:</term>
488         <listitem>
489          <para><ulink url="http://slashdot.org">Slashdot</ulink>
490          provides <quote>News for Nerds: Stuff that Matters,</quote>
491          which usually includes discussion of free software, open
492          source, technology, and geek culture new and events. It is
493          not unusual for an particularly sexy develpment effort to be
494          announced here so it definately worth checking.</para>
495         </listitem>
496        </varlistentry>
497
498        <varlistentry>
499         <term>SourceForge:</term>
500         <listitem>
501          <para><ulink url="http://sourceforge.net">SourceForge</ulink>
502          houses and facilitates a growning number of open source and
503          free software projects, SourceForge is quickly becoming a
504          nexus and an necessary stop for free software
505          developers. SourceForge's <ulink
506          url="http://sourceforge.net/softwaremap/trove_list.php">software
507          map</ulink> and <ulink url="http://sourceforge.net/new/"> new
508          releases</ulink> pages. should be necessary stops before
509          embarking on a new free software project. SourceForge also
510          provides a at <ulink
511          url="http://sourceforge.net/snippet/">Code Snippet
512          Library</ulink> which contains useful reusuable chunks of
513          code in an array of langauges which can come in useful in any
514          project.</para>
515         </listitem>
516        </varlistentry>
517
518        <varlistentry>
519         <term>Google and Google's Linux Search:</term>
520         <listitem>
521          <para><ulink url="http://www.google.com">Google</ulink> and
522          <ulink url="http://www.google.com/linux"> Google's Linux
523          Search</ulink>, provide powwerful web searches that may
524          reveal people working on similar projects. It is not a
525          catalog of software or news like freshmeat or Slashdot, but
526          it is worth checking before you begin pouring your effort
527          into a redundant project.</para>
528         </listitem>
529        </varlistentry>
530
531       </variablelist>
532      </para>
533     </sect4>
534
535     <sect4 id=evalhow>
536      <title>Deciding to Proceed</title>
537      <para>
538       Once you have successfull charted the terrain and have an idea
539       bout what kinds of similar free software projects exist, every
540       developer needs to decide whether to proceed with their own
541       project. It is rare that a new project seeks to accomplish a
542       goal that is not similar to related to the goal of another
543       project. Anyone starting a new project needs to ask themselves:
544       <emphasis>Will the new project be duplicating work done by
545       another project? Will the new project be competing for
546       developers with an existing project? Can the goals of the new
547       project be accomplished by adding functionality to an existing
548       project?</emphasis>
549      </para>
550
551      <para>
552       If the answer to any of these questions is yes, try to contact
553       the developer of the existing project in question and see if he
554       or she might be willing to collaborate with you.
555      </para>
556
557      <para>
558       This may be the single most difficult aspect of free software
559       development for many developers but it is essential. It is easy
560       to become fired up by and idea and be caught up in the momentum
561       and excitement of a new project. It is often extremely difficult
562       but it is important that any free software developer rememeber
563       that the best interests of the of the free software community
564       and the quickest way to accomplish ones own project's goals and
565       the goals of similar project can often be accomplished by
566       <emphasis>not</emphasis> starting a new project.
567      </para>
568
569     </sect4>
570    </sect3>
571   </sect2>
572
573 <!-- Section2: licensing-->
574
575   <sect2 id="licensing">
576    <title>Licensing your Software</title>
577    
578    <para>
579     On one level, the difference between a piece of free software and
580     a piece of propriety software is the license. A license helps both
581     you as the developer by protecting your legal rights to your
582     software and helps demonstrate to those who wish to help you or
583     your project that they are encouraged to join.
584    </para>
585    
586    <sect3 id="chooselicense">
587     <title>Choosing a license</title>
588
589     <para>
590      Any discussion of licenses is also sure to generate at least a
591      small flamewar as there are strong feelings that some free
592      software licenses are better than other free software
593      licenses. This discussion also brings up the question of
594      <quote>Open Source Software</quote> and the debate around
595      <quote>Open Source Software</quote> and <quote>Free
596      Software</quote>. However, because I've written the Free Software
597      Development HOWTO and not the Open Source Development HOWTO, my
598      own allegiences in this argument are out in the open.
599     </para>
600
601     <para>
602      In attempting to reach a middle ground, I recommend picking any
603      license that conforms to the <ulink
604      url="http://www.debian.org/social_contract">Debian Free Software
605      Guidlines</ulink>. Examples of these licenses are the
606      <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
607      Artistic License. Conforming to the definition of Free Software
608      offered by Richard Stallman in <ulink
609      url="http://www.gnu.org/philosophy/free-sw.html">The Free
610      Software Definition</ulink>, any of these licenses will
611      uphold,<quote> users' freedom to run, copy, distribute, study,
612      change and improve the software.</quote> There are other licenses
613      as well but sticking with a more common license will offer the
614      advantage of immediate recognition and undestanding.
615     </para>
616
617     <para>
618      In attempting a more in-depth analysis, I agree with Karl Fogel's
619      description of licenses as falling into two groups: those that
620      are the <acronym>GPL</acronym> and those that are not the
621      <acronym>GPL</acronym>.
622     </para>
623
624     <para>
625      Personally, I license all my software under the
626      <acronym>GPL</acronym>. Created and protected by the Free
627      Software Foundation and the GNU Project, the
628      <acronym>GPL</acronym> is the license for the Linux kernel,
629      GNOME, Emacs, and the majority of Linux software. Its an easy
630      choice but I believe it is a good one. <emphasis>However, there
631      is a viral aspect to the <acronym>GPL</acronym>that prevents the
632      mixture of <acronym>GPL</acronym>'ed code with
633      non-<acronym>GPL</acronym>'ed code. To many people (myself
634      included), this is a benefit, but to some, it is a major
635      drawback.</emphasis>
636     </para>
637
638     <para>
639      The three major license can be found at the following locations:
640     </para>
641
642     <para>
643      <itemizedlist>
644       <listitem>
645        <para><ulink url="http://www.gnu.org/copyleft/gpl.html">The GNU
646        General Public License</ulink></para>
647       </listitem>
648       <listitem>
649        <para><ulink url="http://www.debian.org/misc/bsd.license">The
650        BSD License</ulink></para>
651       </listitem>
652       <listitem>
653        <para><ulink
654        url="http://language.perl.com/misc/Artistic.html">The Artistic
655        License</ulink></para>
656       </listitem>
657      </itemizedlist>
658     </para>
659
660     <para>
661      <emphasis>In all cases, please read through any license before
662      your release your software. As the developer, you can't afford
663      any license surprises.</emphasis>
664     </para>
665    </sect3>
666
667    <sect3 id="licensechoose">
668     <title>The mechanics of licensing</title>
669
670     <para>
671      The text of the <acronym>GPL</acronym> offers <ulink
672      url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
673      description</ulink> of mechanics of applying a license to a piece
674      of software. A checklist for applying a license would include:
675     </para>
676
677     <para>
678     <orderedlist>
679       <listitem>
680
681        <para>If at all possible, attach and distribute a full copy of
682        the license with the source and binary in a seperate
683        file.</para>
684
685       </listitem>
686       <listitem>
687
688        <para>At the top of each source file in your program, attach a
689        notice of copyright and information on where the full license
690        can be found. The <acronym>GPL</acronym> recommends that each
691        file begin with:</para>
692
693        <screen>
694 <emphasis>one line to give the program's name and an idea of what it does.</emphasis>
695 Copyright (C) yyyy  name of author
696
697 This program is free software; you can redistribute it and/or
698 modify it under the terms of the GNU General Public License
699 as published by the Free Software Foundation; either version 2
700 of the License, or (at your option) any later version.
701
702 This program is distributed in the hope that it will be useful,
703 but WITHOUT ANY WARRANTY; without even the implied warranty of
704 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
705 GNU General Public License for more details.
706
707 You should have received a copy of the GNU General Public License
708 along with this program; if not, write to the Free Software
709 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
710        </screen>
711
712        <para>
713         The <acronym>GPL</acronym> goes on to recommend attaching
714         information on contacting you (the author) via email or
715         physical mail.
716       </para>
717
718       </listitem>
719       <listitem>
720
721        <para>
722         The <acronym>GPL</acronym> continues and suggests that if your
723         program runs in an interactive mode, you should have the
724         program output a notice each time it enters interactive mode
725         that includes a message like this one that points to more
726         information about the programs licensing:
727        </para>
728
729        <screen>
730 Gnomovision version 69, Copyright (C) year name of author
731 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
732 type `show w'.  This is free software, and you are welcome
733 to redistribute it under certain conditions; type `show c' 
734 for details.
735        </screen>
736
737       </listitem>
738       <listitem>
739        <para>Finally, it might be helpful to include a
740        <quote>copyright disclaimer</quote> with the program from an
741        employer or a school if you work as a programmer or if it seems
742        like your employer or school might be able to make an argument
743        for ownership of your code.</para>
744       </listitem>
745
746      </orderedlist>
747      </para>    
748    </sect3>
749
750    <sect3 id="licensewarning">
751     <title>Final license warning</title>
752
753     <para>
754      Please, please, please, place your software under some
755      license. It may not seem important, and to you, it may not be,
756      but licenses are important. For a piece of software to be
757      included in the Debian GNU/Linux distrobution, it must have a
758      license that fits the <ulink
759      url="http://www.debian.org/social_contract">Debian Free Software
760      Guidelines</ulink>. If you have no license, your program can be
761      distributed in part of Debian until you rerelease it under a free
762      license. Please save yourself and others trouble by releasing the
763      first version of your software with a clear license.
764     </para>
765
766    </sect3>
767
768  </sect2>
769
770 <!-- Section2: chooseversioning-->
771
772   <sect2 id="chooseversioning">
773    <title>Choosing a Method of Version Numbering</title>
774    <para>
775     <emphasis>The most important thing about a system of numbering is
776     that there is one.</emphasis> It may seem pedantic to emphasize
777     this point but you'd be surprised at the number of scripts and
778     small programs that pop up without any version number. 
779    </para>
780
781    <para>
782     <emphasis>The second most important thing about a system of
783     numbering is that the numbers always go up.</emphasis> Automatic
784     versioning systems and people's sense of order in the universe
785     will fall apart if version numbers don't rise. It doesn't
786     <emphasis>really</emphasis> matter if 2.1 is a big jump and
787     2.0.005 is a small jump but it does matter that 2.1 is more recent
788     than 2.0.005.
789    </para>
790
791    <para>
792     Follow these two rules and you will not go wrong. Still there are
793     several versioning system that are well known, useful, and that
794     might be worth looking into before you release your first version.
795    </para>
796
797    <variablelist>
798     <varlistentry>
799      <term>Linux kernel version numbering:</term>
800      <listitem>
801       <para>The Linux kernel uses a versioning system where the any
802       minor odd minor version number refers to an development or
803       testing release and any even minor version number refers to a
804       stable version. Under this system, 2.1 and 2.3 kernels were and
805       always will be development and testing kernels and 2.0, 2.2. and
806       2.4 kernels are all production code with a higher degree of
807       stability.
808      </para>
809
810       <para>
811        Whether you plan on having a split development model (as
812        described in <xref linkend="branches">) or only one version
813        released at a time, my experience with several free software
814        projects and with the Debian project has taught me taht use of
815        Linux's version numbering system is worth taking into
816        consideration. In Debian, all minor versions are stable
817        distributions (2.0, 2.1, etc). However, many people assume that
818        2.1 is an unstable or development version and continue to use
819        an older version until they get so frusterated with the lack of
820        development and progress that they complain. If you never
821        release an odd minor version but only release even ones, nobody
822        is hurt, and less people are confused.
823       </para>
824
825      </listitem>
826     </varlistentry>
827     <varlistentry>
828      <term>Wine version numbering:</term>
829      <listitem>
830       <para>Because of the unusual nature of wine's development where
831       it constantly improving but not working towards any immediately
832       achievable goal, wine is released every three weeks. Wine does
833       this by versioning their releases in Year Month Day format where
834       each release might be labeled <quote>wine-XXXXXXXX</quote> where
835       the version from Janurary 04, 2000 would be
836       <quote>wine-20000104</quote>. For certain projects, Year Month
837       Day format can make a lot of sense.
838       </para>
839
840      </listitem>
841     </varlistentry>
842     <varlistentry>
843      <term>Mozilla milestones:</term>
844      <listitem>
845       <para>When one considers Netscape 6 and verdor versions, the
846       mozilla's project development structure is one of the most
847       complex free software model available. Their version numbering
848       has reflected the unique situation in which it is
849       developed.
850       </para>
851
852       <para>
853        Mozilla's development structure has historically been made up
854        of milestones. From teh beginning of the mozilla project, the
855        goals of the project in the order and degree to which they were
856        to be achieved were charted out on a series of <ulink
857        url="http://www.mozilla.org/roadmap.html">road
858        maps</ulink>. Major points and achievements along this roadmaps
859        were marked as milestones. Therefore, mozilla was built and
860        distributed nightly as "nightly builds" but on a day when the
861        goals of a milestone on the roadmap had been reached, that
862        particular build was marked as a milstone release.
863       </para>
864
865       <para>
866        While I haven't seen this method employed in any other projects
867        to date, I like the idea and think that it might have value in
868        any testing or development branch of a large free application
869        under heavy development.
870       </para>
871
872      </listitem>
873     </varlistentry>
874    </variablelist>
875   </sect2>
876
877 <!-- Section2: documentation-->
878
879   <sect2 id="documentation">
880    <title>Documentation</title>
881
882    <para>
883     A huge number of otherwise fantastic free software applications
884     have withered because their author was the only person who knew
885     how to use them well. Even if your program is written primarily
886     for a techno-savvy group of users, documentation is helpful and
887     necessary for the survival of your project. You will learn later
888     in <xref linkend="releasing"> that you must always release
889     something that is usable. <emphasis>A piece of software without
890     documentation is not usuable.</emphasis>
891    </para>
892
893    <para>
894     There are lots of ways to document your project and lots of
895     different people to document for. The idea of documentation the
896     code itself to help facilitate development by a large community is
897     vital but is outside the scope of this HOWTO. This being the case,
898     this section deals mostly useful tactics for user-directed
899     documentation.
900    </para>
901
902    <para>
903     A combination of tradition and necessity has resulted in a
904     semi-regular system method of documentation in most free software
905     projects that is worth following. Both users and developers expect
906     to be able to get documentation in several ways and its essential
907     that you provide the information they are seeking in a form they
908     can read if your project is ever going to get off the
909     ground. People have come to expect:
910    </para>
911
912    <sect3>
913     <title>Man pages</title> 
914
915     <para>Your users will want to be able to type <quote>man
916     foo</quote> end up with a nicely formatted man page highlighting
917     the basic use of their application. Make sure that before you
918     release your program, you've planned for this.
919     </para>
920
921     <para>
922      Man pages are not difficult to write. There is excellent
923      documentation on the man page process available through the
924      <quote>The Linux Man-Page-HOWTO</quote> available through the
925      Linux Documentation project <acronym>(LDP)</acronym> written by
926      Jens Schweikhardt. It is available <ulink
927      url="http://www.schweikhardt.net/man_page_howto.html">from
928      Schweikhardt's site</ulink> or <ulink
929      url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the
930      <acronym>LDP</acronym></ulink>.
931     </para>
932
933     <para>
934      It is also possible to write man pages using DocBook SGML and
935      convert them into man pages. Because manpages are so simple, I
936      have not been able to follow this up but would love help from
937      anyone who can give me more information on how exactly this is
938      done.
939     </para>
940    </sect3>
941
942    <sect3>
943     <title>Command line accessable documentation</title>
944
945     <para>
946      Most users will expect the most basic amount of documentation to
947      be easily availabe from the command line. For few programs should
948      then documentation extend for more than one screen (24 or 25
949      lines) but it should cover the basic usage, a brief (one or two
950      sentance) description of the program, a list of commands, all the
951      major options, and a pointer to more in-depth documentation for
952      those who need it. The command line documentation for Debian's
953      apt-get serves as an excellent example and a useful model:
954     </para>
955
956     <screen>
957 apt 0.3.19 for i386 compiled on May 12 2000  21:17:27
958 Usage: apt-get [options] command
959        apt-get [options] install pkg1 [pkg2 ...]
960
961 apt-get is a simple command line interface for downloading and
962 installing packages. The most frequently used commands are update
963 and install.
964
965 Commands:
966    update - Retrieve new lists of packages
967    upgrade - Perform an upgrade
968    install - Install new packages (pkg is libc6 not libc6.deb)
969    remove - Remove packages
970    source - Download source archives
971    dist-upgrade - Distribution upgrade, see apt-get(8)
972    dselect-upgrade - Follow dselect selections
973    clean - Erase downloaded archive files
974    autoclean - Erase old downloaded archive files
975    check - Verify that there are no broken dependencies
976
977 Options:
978   -h  This help text.
979   -q  Loggable output - no progress indicator
980   -qq No output except for errors
981   -d  Download only - do NOT install or unpack archives
982   -s  No-act. Perform ordering simulation
983   -y  Assume Yes to all queries and do not prompt
984   -f  Attempt to continue if the integrity check fails
985   -m  Attempt to continue if archives are unlocatable
986   -u  Show a list of upgraded packages as well
987   -b  Build the source package after fetching it
988   -c=? Read this configuration file
989   -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
990 See the apt-get(8), sources.list(5) and apt.conf(5) manual
991 pages for more information and options.
992     </screen>
993
994     <para>
995      It has become a GNU convention to make this information
996      accessable with the <quote>-h</quote> and the
997      <quote>--help</quote> options. Most GNU/Linux users will expect
998      to be able to retrieve basic documentation these ways so if you
999      choose to use different method, be prepared for the flames and
1000      for the fallout that may result.
1001     </para>
1002    </sect3>
1003    <sect3>
1004     <title>Files users will expect</title>
1005     <para>
1006      In addition to man pages and online help, there are certain files
1007      where people will look to documentation, especially in any
1008      package containing source code. In a source distribution, most of
1009      these files can be stored in a the root directery of the source
1010      distribution or in a subdirectory of the root called
1011      <quote>doc</quote> or <quote>Documentation</quote>. These files include:
1012     </para>
1013     <para>
1014      <variablelist>
1015       <varlistentry>
1016        <term>README or Readme</term>
1017
1018        <listitem>
1019         <para>
1020          A document containing all the basic installation,
1021          compiliation, and even basic use instructions that make up
1022          the bare minimum information needed to get the program up and
1023          running. A README is not your chance to be verbose but needs
1024          to be concise and effective. An ideal README is at least 30
1025          lines long and more no more than 250.
1026         </para>
1027        </listitem>
1028
1029       </varlistentry>
1030       <varlistentry>
1031        <term>INSTALL or Install</term>
1032
1033        <listitem>
1034         <para>
1035          The INSTALL file should be much shorter than the INSTALL file
1036          and should quicly and concisely describe how to build and
1037          install the program. Usually an install simply instructs the
1038          user to run ./configure; make; make install and touches on
1039          any unusual options that may be necessary. More advanced
1040          users can usually avoid them but it's good practice to at
1041          least glance at the file to understand what can be
1042          expected. For most relatively standard install procedures and
1043          for most programs, INSTALL files are as short as possible are
1044          rarely over 100 lines.
1045         </para>
1046        </listitem>
1047
1048       </varlistentry>
1049       <varlistentry>
1050        <term>Changelog, ChangeLog, CHANGELOG, or changelog</term>
1051
1052        <listitem>
1053         <para>
1054          A changelog is a simple file that every well-managed free
1055          software project should include. A changelog is simple the
1056          file that, as its name would imply, logs or documents the
1057          changes to a program. The most simple way to do a changelog
1058          is to simply keep a file with teh source code for your
1059          program and add a section to the top of the changelog with
1060          each release describing what has been, changed, fixed, or
1061          added to the program. It's a good idea to post the changelog
1062          onto the website as well because it can help people decide
1063          whether they want or need to upgrade to a newer version or
1064          wait for a more signifigant upgrade.
1065         </para>
1066        </listitem>
1067
1068       </varlistentry>
1069       <varlistentry>
1070        <term><acronym>FAQ</acronym></term>
1071
1072        <listitem>
1073         <para>
1074          For those of you that don't already
1075          know. <acronym>FAQ</acronym> stands for Frequently Asked
1076          Questions and the file is a collection of exactly that. FAQs
1077          are not difficult to make. Simply make a policy that if you
1078          are asked a question or see a question on a mailing list two
1079          or more times, add it the question (and its answer) to your
1080          FAQs. FAQs are more optional than the files listed above but
1081          they can save your time, increase useability, and decrease
1082          headaches on all sides.
1083         </para>
1084        </listitem>
1085
1086       </varlistentry>
1087      </variablelist>
1088     </para>
1089    </sect3>
1090
1091    <sect3>
1092     <title>Website</title>
1093     <para>
1094      It's only a sort of an issue of documentation but a good website
1095      is quickly becoming an essential part of any free software
1096      project. Your website should provide access to documentation (in
1097      <acronym>HTML</acronym> if possible). It should also include a
1098      section for news and events around your program and a section
1099      that details the process of getting involved with development or
1100      testing and creates an open invitation. It should also supply
1101      links to any mailing lists, similar websites, and directly to all
1102      the available ways of downloading your software.
1103     </para>
1104    </sect3>
1105
1106    <sect3>
1107     <title>Other documentation hints</title>
1108
1109     <para>
1110      It doesn't hurt to distribute any documentation for your program
1111      from your website or anywhere else (FAQs etc) with the
1112      program. Make a FAQ by cutting and posting common questions and
1113      answers from a mailing list or your own email. Then, don't
1114      hesitate through this in the programs tarball. If people don't
1115      need it, they will delete it. I can repeat it over and over:
1116      <emphasis>Too much documentation is not a sin.</emphasis>
1117     </para>
1118
1119     <para>
1120      All your documentation should be in plaintext, or, in cases where
1121      it is on your website primarily, in HTML. Everyone can cat a
1122      file, everyone has a pager, (almost) everyone can render
1123      HTML. <emphasis>You are welcome to distribute information in PDF,
1124      PostScript, RTF, or any number of other widely used formats but
1125      this information must also be available in plaintext or HTML or
1126      people will be very angry at you.</emphasis>
1127     </para>
1128    </sect3>
1129   </sect2>
1130
1131 <!-- Section2: presentation -->
1132
1133   <sect2 id="presentation">
1134    <title>Other Presentation Issues</title>
1135    <para>
1136     Many of the remaining issues surrounding the creation of a new
1137     free software program fall under what most people describe as
1138     common sense actions. Still, they are worth noting briefly in
1139     hopes that they may remind a developer of something they may have
1140     forgotten.
1141    </para>
1142
1143    <sect3>
1144     <title>Package formats</title>
1145     <para>
1146      Package formats may differ depending on the system you are
1147      developing for. For windows based software, Zip archives (.zip)
1148      usually serve as the package format of choice. If you are
1149      developing for GNU/Linux, *BSD, or any UN*X, make sure that your
1150      source code is always available in tar'ed and gzip'ed format
1151      (.tar.gz). UNIX compress (.Z) has gone out of style and
1152      usefulness and faster computers have brought bzip2 (.bz2) into
1153      the spotlit as a more effective compression medium. I now make
1154      all my releases available in both gzip'ed and bzip2'ed formats.
1155     </para>
1156
1157     <para>
1158      Binary packages are largely distribution specific. You can build
1159      binary packages against a current version of a major
1160      distribution, you will only make your users happy. Try to foster
1161      relationships with users or developers of large distribution to
1162      develop a system for consistent binary packages. It's often a
1163      good idea to provide RedHat <acronym>RPM</acronym>'s (.rpm),
1164      Debian deb's (.deb) and source <acronym>RPM</acronym>'s
1165      <acronym>SRPM</acronym>'s. Binary packages can also be compiled
1166      against a specified system with specificed libraries and
1167      distributed in tar.gz format as well. <emphasis>Remember: While
1168      these binaries packages are nice, geting the source packaged and
1169      released should always be your priority. Other can and will do
1170      the the binary packages for you.</emphasis>
1171     </para>
1172    </sect3>
1173
1174    <sect3>
1175     <title>Useful tidbits and presentation hints</title>
1176
1177     <para>
1178      <itemizedlist>
1179
1180       <listitem>
1181        <para>
1182         <emphasis>Make sure that your program can always be found in a
1183         single location.</emphasis> Often this means that you have a
1184         single directory accessable via <acronym>FTP</acronym> or
1185         <acronym>HTTP</acronym> where the newest version will be
1186         quickly recognized. One effective technique is a provide a
1187         symlink called <quote>projectname-latest</quote> that is
1188         always pointing to the most recent released or development
1189         version of your free software project.
1190        </para>
1191       </listitem>
1192
1193       <listitem>
1194        <para>
1195         <emphasis>Make sure that there is a consistent email address
1196         for bug reports.</emphasis> It's usually a good idea to make
1197         this something that is NOT your primary email address like
1198         projectname@host or projectname-bugs@host. This way if you
1199         ever decide to hand over maintainership or if your email
1200         address changes, you simply need to change where this email
1201         address forwards to. It also will allow for more than one
1202         person to deal with the influx of mail that is created if your
1203         project becomes as huge as you hope it will.
1204        </para>
1205       </listitem>
1206
1207      </itemizedlist>
1208     </para>
1209
1210    </sect3>
1211   </sect2>
1212  </sect1>
1213
1214 <!-- Section1: starting: END -->
1215
1216 <!-- Section1: developers -->
1217
1218  <sect1 id="developers">
1219   <title>Maintaining a Project: Interacting with Developers</title>
1220    <indexterm>
1221     <primary>fswd!developers</primary>
1222    </indexterm>
1223
1224   <para>
1225    Once you have gotten the project started, you have gotten over the
1226    most difficult hurdles in the development process of your
1227    program. Laying a firm foundation is essential, but the development
1228    process itself is equally important and provides an equal number of
1229    opportunities for failure. In the next two sections, I will and
1230    cover running a project by discussing how to maintain a project
1231    rhough interactions with developers and with users.
1232   </para>
1233
1234   <para>
1235    The difference between free software development and propriety
1236    software development is th developer base. As the leader of a free
1237    software project, you need to attract and keep developers in a way
1238    that leaders of proprietary software projects sipmly don't have to
1239    worry about. <emphasis>As the person leading development of a free
1240    software project, you must harness the work of fellow developers by
1241    making responsible decisions and by and by choosing not to make
1242    decisions responsibly. You have to direct developers without being
1243    overbearing or bossy. You need to strive to earn respect and never
1244    forget to give it.</emphasis>
1245   </para>
1246
1247 <!-- Section2: delegation  -->
1248
1249   <sect2 id="delegation">
1250    <title>Delegating Work</title>
1251
1252    <para>
1253     By now, you've hypothetically followed me through the early
1254     writing of a piece of software, the creation of a website and
1255     system of documentation and and we've gone ahead and (as will be
1256     discussed in <xref linkend="releasing">) released it to the rest
1257     of the world. Times passes, and if things go well, people become
1258     interested and want to help. The patches begin flowing in.
1259    </para>
1260
1261    <para>
1262     <emphasis>Like the parent of any child who grows up, it's now time
1263     to wince and smile and do most difficult thing in any parents
1264     life: It's time to let go.</emphasis>
1265    </para>
1266
1267    <para>
1268     Delegation is the politcal way of describing this process of
1269     <quote>letting go.</quote> It is the process of handing some of
1270     the responsibility and power over your project to other reponsible
1271     and involved developers. It is difficult for anyone who has
1272     invested a large deal of time and energy into a project but it
1273     essential for the growth of any free software project. One person
1274     can only do so much. <emphasis>A free software project is nothing
1275     without the involvement of a group of developers. A group of
1276     developers can only be maintained through respectful and
1277     responsible leadership and delegation.</emphasis>
1278    </para>
1279
1280    <para>
1281     As your project progresses, you will notice people who are putting
1282     signfigant amounts of time and effort into your project. These
1283     will be the people submitting the most patches, posting most on
1284     the mailing lists, engaging in long email discussions. It is your
1285     responsiblity to contact these people and to try and shift some of
1286     the power and responsiblity of your position as the project's
1287     maintainer onto them (if they want it). There are several easy
1288     weays you can do this:
1289    </para>
1290
1291    <sect3>
1292     <title>How to delegate</title>
1293  
1294     <para>
1295      Like anything, its easier to see how others delegate than to do
1296      it yourself. In a sentance: <emphasis>Keep an eye out for other
1297      qualified developers who show an interest and sustained
1298      involvement with your project and try and shift responsibility
1299      towards them.</emphasis> The following ideas might be good places
1300      to start or good sources of inspiriation:
1301     </para>
1302  
1303     <sect4>
1304      <title>Allow a larger group of people write access to your CVS
1305      reponsitory and make real efforts towards rule by a
1306      committee</title>
1307
1308      <para>
1309       <ulink url="http://httpd.apache.org/">Apache</ulink> is an
1310       example of a project that is run by small group of developers
1311       who vote on major technical issues and the admission of new
1312       members and all have write access to the main source
1313       repository. Their process is detailed <ulink
1314       url="http://httpd.apache.org/ABOUT_APACHE.html">online.</ulink>
1315      </para>
1316
1317      <para>
1318       The <ulink url="http://www.debian.org/"> Debian Project</ulink>
1319       is an extreme example of rule by committee. At current count,
1320       more than 700 developers have full responsibility for certain
1321       aspects of the projects. All these developers can upload into
1322       the main ftp servers, and vote on major issues. Direction for
1323       the project is determined by the project <ulink
1324       url="http://www.debian.org/social_contract">social
1325       contract</ulink> and a <ulink
1326       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
1327       facilitate this system, there are special teams (i.e. the
1328       install team, the Japanese language team) and a technical
1329       committee and a project lead. There is a project lead as well
1330       but the lead's main responsiblity is to, <quote>Appoint
1331       Delegates or delegate decisions to the Technical
1332       Committee.</quote>
1333      </para>
1334
1335      <para>
1336       While both of these projects operate on a scale that your
1337       project will not (at least initially), their example is
1338       helpful. Debian's idea of a project who lead who can do
1339       <emphasis>nothing</emphasis> but delegate can serve as a
1340       charicature of how a project can involve and empower a huge
1341       number of developers and grow to a huge size.
1342      </para>
1343
1344     </sect4>
1345
1346     <sect4>
1347      <title>Publicly appoint someone as the release manager for a
1348        specific release.</title>
1349
1350      <para>
1351       A relase manager is usually responsible for coordinating
1352       testing, encforcing a code freeze, being responsible for
1353       stability and quality control, packaging up the software, and
1354       placing it in the approrpriate places to be downloaded.
1355      </para>
1356
1357      <para>
1358       This use of the release manager is a good way to give yourself a
1359       break and to shift the responsibility for accepting and
1360       rejecting patches to somenoe else. It is a good way of very
1361       clearly defining a chunk of work on the project as belonging to
1362       a certain person and its a great way of giving yourself a break.
1363      </para>
1364     </sect4>
1365
1366     <sect4>
1367      <title>Delegate control of an entire branch.</title>
1368      <para>
1369       If your project chooses to have branches (as described in <xref
1370       linkend="branches">), it might be a good idea to appoint someone
1371       else to be the the head of a branch. If you like focusing your
1372       energy on development releases and the implementation of new
1373       features, had total control over the stable releases to a
1374       well-suiteded developer.
1375      </para>
1376
1377      <para>
1378       The author of linux, Linus Torvalds, came out and crowned Alan
1379       Cox as <quote>the man for stable kernels.</quote> All patches
1380       for stable kernels go to Alan and, if Linus were to be taken
1381       away from work on linux for any reason, Alan Cox would be more
1382       than suited to fill his role as the acknowledged heir to the
1383       linux maintainership.
1384      </para>
1385     </sect4>
1386    </sect3> 
1387   </sect2>
1388
1389 <!-- Section2: patching -->
1390
1391   <sect2 id="patching">
1392    <title>Accepting and Rejecting Patches</title>
1393    <para></para>
1394   </sect2>
1395
1396
1397 <!-- Section2: branches  -->
1398
1399   <sect2 id="branches">
1400    <title>Stable and Development Branches</title>
1401    <para></para>
1402   </sect2>
1403
1404 <!-- Section2: otherdev -->
1405
1406   <sect2 id="otherdev">
1407    <title>Other Development issues</title>
1408    <para></para>
1409   </sect2>
1410
1411
1412  </sect1>
1413
1414 <!-- Section1: users -->
1415
1416  <sect1 id="users">
1417   <title>Maintaining a Project: Interacting with Users</title>
1418
1419    <indexterm>
1420     <primary>fswd!users</primary>
1421    </indexterm>
1422
1423 <!-- Section2: testing -->
1424
1425   <sect2 id="testing">
1426    <title>Testing and Testers</title>
1427    <para></para>
1428   </sect2>
1429
1430 <!-- Section2: support  -->
1431
1432   <sect2 id="support">
1433    <title>Setting up a Support Infrastructure</title>
1434    <para></para>
1435   </sect2>
1436
1437 <!-- Section2: releasing  -->
1438
1439   <sect2 id="releasing">
1440    <title>Releasing Your Program</title>
1441    <para></para>
1442   </sect2>
1443
1444 <!-- Section2: announcing  -->
1445
1446   <sect2 id="announcing">
1447    <title>Announcing Your Project</title>
1448    <para></para>
1449   </sect2>
1450
1451
1452 </sect1>
1453
1454 </article>
1455
1456 <!-- Keep this comment at the end of the file
1457 Local variables:
1458 mode: sgml
1459 sgml-omittag:t
1460 sgml-shorttag:t
1461 sgml-namecase-general:t
1462 sgml-general-insert-case:lower
1463 sgml-minimize-attributes:nil
1464 sgml-always-quote-attributes:t
1465 sgml-indent-step:1
1466 sgml-indent-data:nil
1467 sgml-parent-document:nil
1468 sgml-exposed-tags:nil
1469 sgml-local-catalogs:nil
1470 sgml-local-ecat-files:nil
1471 End:
1472 -->

Benjamin Mako Hill || Want to submit a patch?