+ <sect2 id="delegation">
+ <title>Delegating Work</title>
+
+ <para>
+ By now, you've hypothetically followed me through the early
+ programming of a piece of software, the creation of a website and
+ system of documentation, and we've gone ahead and (as will be
+ discussed in <xref linkend="releasing">) released it to the rest
+ of the world. Times passes, and if things go well, people become
+ interested and want to help. The patches begin flowing in.
+ </para>
+
+ <para>
+ <emphasis>Like the parent of any child who grows up, it's now time
+ to wince, smile and do most difficult thing in any parents
+ life: It's time to let go.</emphasis>
+ </para>
+
+ <para>
+ Delegation is the political way of describing this process of
+ <quote>letting go.</quote> It is the process of handing some of
+ the responsibility and power over your project to other
+ responsible and involved developers. It is difficult for anyone
+ who has invested a large deal of time and energy into a project
+ but it essential for the growth of any free software project. One
+ person can only do so much. A free software project is nothing
+ without the involvement of <emphasis>a group</emphasis> of
+ developers. A group of developers can only be maintained through
+ respectful and responsible leadership and delegation.
+ </para>
+
+ <para>
+ As your project progresses, you will notice people who are putting
+ significant amounts of time and effort into your project. These
+ will be the people submitting the most patches, posting most on
+ the mailing lists, and engaging in long email discussions. It is
+ your responsibility to contact these people and to try and shift
+ some of the power and responsibility of your position as the
+ project's maintainer onto them (if they want it). There are
+ several easy ways you can do this:
+ </para>
+
+ <para>
+ In a bit of a disclaimer, delegation need not mean rule by
+ committee. In many cases it does and this has been proven to
+ work. In other cases this has created problems. <ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink> argues that <quote>OSS
+ projects do best when one person is the clear leader of a team and
+ makes the big decisions (design changes, release dates, and so
+ on).</quote> I think this often true but would urge developers to
+ consider the ideas that the project leader need not be the
+ project's founder and that these important powers need not all rest
+ with one person but that a release manager may be different than a
+ lead developer. These situations are tricky politically so
+ be careful and make sure it's necessary before you go around
+ empowering people.
+ </para>
+
+ <sect3>
+ <title>How to delegate</title>
+
+ <para>
+ You may find that other developers seem even more experienced or
+ knowledgeable than you. Your job as a maintainer does not mean
+ you have to be the best or the brightest. It means you
+ are responsible for showing good judgment and for
+ recognizing which solutions are maintainable and which are not.
+ </para>
+ <para>
+ Like anything, its easier to watch others delegate than to do it
+ yourself. In a sentence: <emphasis>Keep an eye out for other
+ qualified developers who show an interest and sustained
+ involvement with your project and try and shift responsibility
+ toward them.</emphasis> The following ideas might be good places
+ to start or good sources of inspiration:
+ </para>
+
+ <sect4>
+ <title>Allow a larger group of people to have write access to your CVS
+ repository and make real efforts toward rule by a
+ committee</title>
+
+ <para>
+ <ulink url="http://httpd.apache.org/">Apache</ulink> is an
+ example of a project that is run by small group of developers
+ who vote on major technical issues and the admission of new
+ members and all have write access to the main source
+ repository. Their process is detailed <ulink
+ url="http://httpd.apache.org/ABOUT_APACHE.html">online.</ulink>
+ </para>
+
+ <para>
+ The <ulink url="http://www.debian.org/"> Debian Project</ulink>
+ is an extreme example of rule by committee. At current count,
+ more than 700 developers have full responsibility for
+ aspects of the project. All these developers can upload into
+ the main FTP server, and vote on major issues. Direction for
+ the project is determined by the project's <ulink
+ url="http://www.debian.org/social_contract">social
+ contract</ulink> and a <ulink
+ url="http://www.debian.org/devel/constitution">constitution</ulink>. To
+ facilitate this system, there are special teams (i.e. the
+ install team, the Japanese language team) as well as a technical
+ committee and a project leader. The leader's main responsibility
+ is to, <quote>appoint delegates or delegate decisions to the
+ Technical Committee.</quote>
+ </para>
+
+ <para>
+ While both of these projects operate on a scale that your
+ project will not (at least initially), their example is
+ helpful. Debian's idea of a project leader who can do
+ <emphasis>nothing</emphasis> but delegate serves as a
+ caricature of how a project can involve and empower a huge
+ number of developers and grow to a huge size.
+ </para>
+
+ </sect4>
+
+ <sect4 id="releasemanager">
+ <title>Publicly appoint someone as the release manager for a
+ specific release</title>
+
+ <para>
+ A release manager is usually responsible for coordinating
+ testing, enforcing a code freeze, being responsible for
+ stability and quality control, packaging up the software, and
+ placing it in the appropriate places to be downloaded.
+ </para>
+
+ <para>
+ This use of the release manager is a good way to give yourself a
+ break and to shift the responsibility for accepting and
+ rejecting patches onto someone else. It is a good way of very
+ clearly defining a chunk of work on the project as belonging to
+ a certain person and its a great way of giving yourself room to
+ breath.
+ </para>
+ </sect4>
+
+ <sect4 id="delegatebranch">
+ <title>Delegate control of an entire branch</title>
+ <para>
+ If your project chooses to have branches (as described in <xref
+ linkend="branches">), it might be a good idea to appoint someone
+ else to be the the head of a branch. If you like focusing your
+ energy on development releases and the implementation of new
+ features, hand total control over the stable releases to a
+ well-suited developer.
+ </para>
+
+ <para>
+ The author of Linux, Linus Torvalds, came out and crowned Alan
+ Cox as <quote>the man for stable kernels.</quote> All patches
+ for stable kernels go to Alan and, if Linus were to be taken
+ away from work on Linux for any reason, Alan Cox would be more
+ than suited to fill his role as the acknowledged heir to the
+ Linux maintainership.
+ </para>
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: patching -->
+
+ <sect2 id="patching">
+ <title>Accepting and Rejecting Patches</title>
+ <para>
+ This HOWTO has already touched on the fact that as the maintainer
+ of a free software project, one of your primary and most important
+ responsibilities will be accepting and rejecting patches submitted
+ to you by other developers.
+ </para>
+
+ <sect3>
+ <title>Encouraging Good Patching</title>
+
+ <para>As the person managing or maintaining the project, you
+ aren't the person who is going to be making a lot of
+ patches. However, it's worth knowing about ESR's section on
+ <citetitle>Good Patching Practice</citetitle> in the
+ <citetitle>Software Release Practices HOWTO</citetitle><xref
+ linkend="esrhowto">. I don't agree with ESR's claim that most ugly
+ or undocumented patches are probably worth throwing out at first
+ sight--this just hasn't been my experience, especially when
+ dealing with bug fixes that often don't come in the form of
+ patches at all. Of course, this doesn't mean that I
+ <emphasis>like</emphasis> getting poorly done patches. If you get
+ ugly -e patches, if you get totally undocumented patches, and
+ especially if they are anything more than trivial bug-fixes, it
+ might be worth judging the patch by some of the criteria in ESR's
+ HOWTO and then throwing people the link to the document so they
+ can do it the <quote>right way.</quote>
+ </para>
+
+ </sect3>
+
+ <sect3>
+ <title>Technical judgment</title>
+
+ <para>
+ In <emphasis>Open Source Development with CVS</emphasis>, Karl
+ Fogel makes a convincing argument that the most important things
+ to keep in mind when rejecting or accepting patches are:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>A firm knowledge of the scope of your program (that's the
+ <quote>idea</quote> I talked about in <xref linkend="chooseproject">);</para>
+ </listitem>
+
+ <listitem>
+ <para>The ability to recognize, facilitate, and direct
+ <quote>evolution</quote> of your program so that the program
+ can grow and change and incorporate functionality that was
+ originally unforeseen;</para>
+ </listitem>
+
+ <listitem>
+ <para>The necessity to avoid digressions that might expand the
+ scope of the program too much and result and push the project
+ toward an early death under its own weight and
+ unwieldiness.</para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ These are the criteria that you as a project maintainer should
+ take into account each time you receive a patch.
+ </para>
+
+ <para>
+ Fogel elaborates on this and states the <quote>the
+ questions to ask yourself when considering whether to implement
+ (or approve) a change are:</quote>
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>Will it benefit a significant percentage of the program's
+ user community?</para>
+ </listitem>
+
+ <listitem>
+ <para>Does it fit within the program's domain or within a
+ natural, intuitive extension of that domain?</para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ The answers to these questions are never straightforward and its
+ very possible (and even likely) that the person who submitted the
+ patch may feel differently about the answer to these questions
+ than you do. However, if you feel that that the answer to either
+ of those questions is <quote>no,</quote> it is your responsibility
+ to reject the change. If you fail to do this, the project will
+ become unwieldy and unmaintainable and many ultimately fail.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Rejecting patches</title>
+
+ <para>
+ Rejecting patches is probably the most difficult and sensitive
+ job that the maintainer of any free software project has to
+ face. But sometimes it has to be done. I mentioned earlier (in
+ <xref linkend="developers"> and in <xref linkend="delegation">)
+ that you need to try and balance your responsibility and power to
+ make what you think are the best technical decisions with the
+ fact that you will lose support from other developers if you seem
+ like you are on a power trip or being overly bossy or possessive
+ of the community's project. I recommend that you keep these three
+ major concepts in mind when rejecting patches (or other changes):
+ </para>
+
+ <sect4>
+ <title>Bring it to the community</title>
+ <para>
+ One of the best ways of justifying a decision to reject a patch
+ and working to not seem like you keep an iron grip on your
+ project is by not making the decision alone at all. It might
+ make sense to turn over larger proposed changes or more
+ difficult decisions to a development mailing list where they can
+ be discussed and debated. There will be some patches (bug fixes,
+ etc.) which will definitely be accepted and some that you feel
+ are so off base that they do not even merit further
+ discussion. It is those that fall into the gray area between
+ these two groups that might merit a quick forward to a mailing
+ list.
+ </para>
+
+ <para>
+ I recommend this process wholeheartedly. As the project
+ maintainer you are worried about making the best decision for
+ the project, for the project's users and developers, and for
+ yourself as a responsible project leader. Turning things over to
+ an email list will demonstrate your own responsibility and
+ responsive leadership as it tests and serves the interests of
+ your software's community.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Technical issues are not always good justification</title>
+ <para>
+ Especially toward the beginning of your project's life, you
+ will find that many changes are difficult to implement,
+ introduce new bugs, or have other technical problems. Try to see
+ past these. Especially with added functionality, good ideas do
+ not always come from good programmers. Technical merit is a
+ valid reason to postpone an application of a patch but it is not
+ always a good reason to reject a change outright. Even small
+ changes are worth the effort of working with the developer
+ submitting the patch to iron out bugs and incorporate the change
+ if you think it seems like a good addition to your project. The
+ effort on your part will work to make your project a community
+ project and it will pull a new or less experienced developer
+ into your project and even teach them something that might help
+ them in making their next patch.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Common courtesy</title>
+ <para>
+ It should go without saying but, <emphasis>above all and in all
+ cases, just be nice.</emphasis> If someone has an idea and cares
+ about it enough to write some code and submit a patch, they
+ care, they are motivated, and they are already involved. Your
+ goal as the maintainer is make sure they submit again. They may
+ have thrown you a dud this time but next time may be the idea or
+ feature that revolutionizes your project.
+ </para>
+
+ <para>
+ It is your responsibility to first justify your choice to not
+ incorporate their change clearly and concisely. Then thank
+ them. Let them know that you a appreciate their help and feel
+ horrible that you can't incorporate their change. Let them know
+ that you look forward to their staying involved and you hope
+ that the next patch or idea meshes better with your project
+ because you appreciate their work and want to see it in your
+ application. If you have ever had a patch rejected after putting
+ a large deal of time, thought, and energy into it, you remember
+ how it feels and it feels bad. Keep this in mind when you have
+ to let someone down. It's never easy but you need to do
+ everything you can to make it as not-unpleasant as possible.
+ </para>
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: branches -->
+
+ <sect2 id="branches">
+ <title>Stable and Development Branches</title>
+
+ <para>
+ The idea of stable and development branches has already been
+ described briefly in <xref linkend="chooseversioning"> and in
+ <xref linkend="delegatebranch">. These allusions attest to some of
+ the ways that multiple branches can affect your software. Branches
+ can let you avoid (to some extent) some of the problems around
+ rejecting patches (as described in <xref linkend="patching">) by
+ allowing you to temporarily compromise the stability of your
+ project without affecting those users who need that stability.
+ </para>
+
+ <para>
+ The most common way of branching your project is to have one
+ branch that is stable and one that is for development. This is the
+ model followed by the Linux kernel that is described in <xref
+ linkend="chooseversioning">. In this model, there is
+ <emphasis>always</emphasis> one branch that is stable and always
+ one that is in development. Before any new release, the
+ development branch goes into a <quote>feature freeze</quote> as
+ described in <xref linkend="freezing"> where major changes and
+ added features are rejected or put on hold under the development
+ kernel is released as the new stable branch and major development
+ resumes on the development branch. Bug fixes and small changes
+ that are unlikely to have any large negative repercussions are
+ incorporated into the stable branch as well as the development
+ branch.
+ </para>
+
+ <para>
+ Linux's model provides an extreme example. On many projects, there is no
+ need to have two versions constantly available. It may make sense to
+ have two versions only near a release. The Debian project has
+ historically made both a stable and an unstable distribution
+ available but has expanded to this to include: stable, unstable,
+ testing, experimental, and (around release time) a frozen
+ distribution that only incorporates bug fixes during the
+ transition from unstable to stable. There are few projects whose
+ size would necessitate a system like Debian's but this use of
+ branches helps demonstrate how they can be used to balance
+ consistent and effective development with the need to make regular
+ and usable releases.
+ </para>
+
+ <para>
+ In trying to set up a development tree for yourself, there are
+ several things that might be useful to keep in mind:
+ </para>
+
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>Minimize the number of branches</term>
+ <listitem>
+ <para>Debian may be able to make good use of four or five
+ branches but it contains gigabytes of software in over 5000
+ packages compiled for 5-6 different architectures. For you,
+ two is probably a good ceiling. Too many branches will confuse
+ your users (I can't count how many times I had to describe
+ Debian's system when it only had 2 and sometimes 3 branches!),
+ potential developers and even yourself. Branches can help but
+ they come at a cost so use them very sparingly.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Make sure that all your different branches are explained</term>
+ <listitem>
+ <para>As I mentioned in the preceding paragraph, different
+ branches <emphasis>will</emphasis> confuse your users. Do
+ everything you can to avoid this by clearly explaining the
+ different branches in a prominent page on your website and in a
+ README file in the <acronym>FTP</acronym> or
+ web directory.</para>
+
+ <para>
+ I might also recommend against a mistake that I think Debian
+ has made. The terms <quote>unstable,</quote>
+ <quote>testing,</quote> and <quote>experimental</quote> are
+ vague and difficult to rank in order of stability (or
+ instability as the case may be). Try explaining to someone
+ that <quote>stable</quote> actually means <quote>ultra
+ stable</quote> and that <quote>unstable</quote> doesn't
+ actually include any unstable software but is really stable
+ software that is untested as a distribution.
+ </para>
+
+ <para>
+ If you are going to use branches, especially early on, keep in
+ mind that people are conditioned to understand the terms
+ <quote>stable</quote> and <quote>development</quote> and you
+ probably can't go wrong with this simple and common division of
+ branches.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Make sure all your branches are always available</term>
+ <listitem>
+ <para>Like a lot of this document, this should probably should
+ go without saying but experience has taught me that it's not
+ always obvious to people. It's a good idea to physically split
+ up different branches into different directories or directory
+ trees on your <acronym>FTP</acronym> or web site. Linux
+ accomplishes this by having kernels in a v2.2 and a v2.3
+ subdirectory where it is immediately obvious (after you know
+ their version numbering scheme) which directory is for the most
+ recent stable and the current development releases. Debian
+ accomplishes this by naming all their distribution with names
+ (i.e. woody, potato, etc.) and then changing symlinks named
+ <quote>stable,</quote> <quote>unstable</quote> and
+ <quote>frozen</quote> to point to which ever distribution (by
+ name) is in whatever stage. Both methods work and there are
+ others. In any case, it is important that different branches
+ are always available, are accessible from consistent locations,
+ and that different branches are clearly distinguished from each
+ other so your users know exactly what they want and where to
+ get it.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </para>
+
+ </sect2>
+
+<!-- Section2: otherdev -->
+
+ <sect2 id="otherdev">
+ <title>Other Project Management issues</title>
+ <para>
+ There are more issues surrounding interaction with developers in a
+ free software project that I can not touch on in great detail in a
+ HOWTO of this size and scope. Please don't hesitate to contact me if you see
+ any major omissions.
+ </para>
+
+ <para>
+ Other smaller issues that are worth mentioning are:
+ </para>
+
+ <sect3 id="freezing">
+ <title>Freezing</title>
+ <para>
+ For those projects that choose to adopt a split development model
+ (<xref linkend="branches">), freezing is a concept that is worth
+ becoming familiar with.
+ </para>
+
+ <para>
+ Freezes come in two major forms. A <quote>feature freeze</quote>
+ is a period when no significant functionality is added to a
+ program. It is a period where established functionality (even
+ skeletons of barely working functionality) can be improved and
+ perfected. It is a period where bugs are fixed. This type of
+ freeze is usually applied some period (a month or two) before a
+ release. It is easy to push a release back as you wait for
+ <quote>one more feature</quote> and a freeze helps to avoid this
+ situation by drawing the much needed line in the sand. It gives
+ developers room they need to get a program ready for release.
+ </para>
+
+ <para>
+ The second type of freeze is a <quote>code freeze</quote> which
+ is much more like a released piece of software. Once a piece of
+ software has entered a <quote>code freeze,</quote> all changes to
+ the code are discouraged and only changes that fix known bugs
+ are permitted. This type of freeze usually follows a
+ <quote>feature freeze</quote> and directly precedes a
+ release. Most released software is in what could be interpreted
+ as a sort of high level <quote>code freeze.</quote>
+ </para>
+
+ <para>
+ Even if you never choose to appoint a release manager (<xref
+ linkend="releasemanager">), you will have an easier time
+ justifying the rejection or postponement of patches (<xref
+ linkend="patching">) before a release with a publicly stated
+ freeze in effect.
+ </para>
+ </sect3>
+ </sect2>
+
+ <sect2>
+ <title>Forks</title>
+ <para>
+ I wasn't sure about how I would deal with forking in this
+ document (or if I would deal with forking at all). A fork is when
+ a group of developers takes code from a free software project and
+ actually starts a brand new free software project with it. The
+ most famous example of a fork was between Emacs and XEmacs. Both
+ emacsen are based on an identical code-base but for technical,
+ political, and philosophical reasons, development was split into
+ two projects which now compete with each other.
+ </para>
+
+ <para>
+ The short version of the fork section is, <emphasis>don't do
+ them.</emphasis> Forks force developers to choose one project to
+ work with, cause nasty political divisions, and redundancy of
+ work. Luckily, usually the threat of the fork is enough to scare
+ the maintainer or maintainers of a project into changing the way
+ they run their project.
+ </para>
+
+ <para>
+ In his chapter on <quote>The Open Source Process,</quote> Karl
+ Fogel describes how to do a fork if you absolutely must. If you
+ have determined that is absolutely necessary and that the
+ differences between you and the people threatening to fork are
+ absolutely unresolvable, I recommend Fogel's book as a good place
+ to start.
+ </para>
+ </sect2>
+ </sect1>
+
+<!-- Section1: users -->
+
+ <sect1 id="users">
+ <title>Maintaining a Project: Interacting with Users</title>
+ <indexterm>
+ <primary>fswd!users</primary>
+ </indexterm>
+
+ <para>
+ If you've worked your way up to here, congratulations, you are
+ nearing the end of this document. This final section describes some
+ of the situations in which you, in your capacity as project
+ maintainer, will be interacting with users. It gives some
+ suggestions on how these situations might be handled effectively.
+ </para>
+
+ <para>
+ Interacting with users is difficult. In our discussion of
+ interaction with developers, the underlying assumption is that in a
+ free software project, a project maintainer must constantly strive to
+ attract and keep developers who can easily leave at any time.
+ </para>
+
+ <para>
+ Users in the free software community are different than developers
+ and are also different than users in the world of proprietary
+ software and they should be treated differently than either
+ group. Some ways in which the groups differ significantly follow:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>The lines between users and developers are blurred in ways
+ that is totally foreign to any proprietary development
+ model. Your users are often your developers and vice
+ versa.</para>
+ </listitem>
+
+ <listitem>
+ <para>In the free software world, you are often your users' only
+ choice. Because there is such an emphasis on not replicating the
+ work of others in the free software community and because the
+ element of competition present in the propriety software model is
+ absent (or at least in an extremely different form) in the free
+ software development model, you will probably be the only project
+ that does what you do (or at least the only one that does what
+ you do in the way that you do it). This means your responsiveness
+ to your users is even more important than in the proprietary
+ software world.</para>
+ </listitem>
+
+ <listitem>
+ <para>In an almost paradoxical situation, free software projects
+ have less immediate or dire consequences for ignoring their users
+ altogether. It is also often easier to do. Because you don't
+ usually need to compete with another product, chances are good
+ that you will not be scrambling to gain the features of your
+ competitor's newest program. This means that your development
+ process will have to be directed either internally, by a
+ commitment to your users, or through both.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Trying to tackle this unique situation can only be done
+ indirectly. Developers and maintainers need to listen to users and
+ to try and be as responsive as possible. A solid knowledge of the
+ situation recounted above is any free software developer's best tool
+ for shifting his development or leadership style to fit the unique
+ process of free software project management. This chapters will try and
+ introduce some of the more difficult or important points in any
+ projects interactions with users and give some hints on how to
+ tackle these.
+ </para>
+
+<!-- Section2: testing -->
+
+ <sect2 id="testing">
+ <title>Testing and Testers</title>
+
+ <para>
+ In addition to your users being your developers, they are also
+ (and perhaps more commonly) your testers. Before I get flamed, I
+ should rephrase my sentence: <emphasis>some of your
+ users</emphasis> (those who explicitly volunteer) are your
+ testers.
+ </para>
+
+ <para>
+ It is important that this distinction be made early on because not
+ all of your users want to be testers. Many users want to use
+ stable software and don't care if they don't have the newest,
+ greatest software with the latest, greatest features. These users
+ expect a stable, tested piece of software without major or obvious
+ bugs and will be angry if they find themselves testing. This is
+ yet another way in which a split development model (as mentioned
+ in <xref linkend="branches">) might come in handy.
+ </para>
+
+ <para>
+ <quote><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink></quote> describes what a
+ good test should look for:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Boundary conditions</term>
+
+ <listitem>
+ <para>Maximum buffer lengths, data conversions, upper/lower
+ boundary limits, and so on.</para>
+ </listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term>Inappropriate behavior</term>
+
+ <listitem>
+ <para>Its a good idea to find out what a program will do if a
+ user hands it a value it isn't expecting, hits the wrong button,
+ etc. Ask yourself a bunch of <quote>what if</quote> questions
+ and think of anything that <emphasis>might</emphasis> fail or
+ <emphasis>might</emphasis> go wrong and find out what your
+ program would do in those cases.</para>
+ </listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term>Graceful failure</term>
+
+ <listitem>
+ <para>The answer to a number of the <quote>what if</quote>
+ questions above is probably <quote>failure</quote> which is
+ often the only answer. Now make sure that it happens
+ nicely. Make sure that when it crashes, there is some indication
+ of why it crashed or failed so that the user or developer
+ understands whats going on.</para>
+ </listitem>
+
+ </varlistentry>
+
+ <varlistentry>
+ <term>Standards conformance</term>
+
+ <listitem>
+ <para>If possible, make sure your programs conforms to
+ standards. If it's interactive, don't be too creative with
+ interfaces. If it is non-interactive, make sure it communicates
+ over appropriate and established channels with other programs
+ and with the rest of the system.</para>
+ </listitem>
+
+ </varlistentry>
+ </variablelist>
+
+ <sect3>
+ <title>Automated testing</title>
+ <para>
+ For many programs, many common mistakes can be caught by
+ automated means. Automated tests tend to be pretty good at
+ catching errors that you've run into several times before or
+ the things you just forget. They are not very good at finding
+ errors, even major ones, that are totally unforeseen.
+ </para>
+
+ <para>
+ CVS comes with a Bourne shell script called sanity.sh that is
+ worth looking at. Debian uses a program called lintian that
+ checks Debian packages for all of the most common errors. While
+ use of these scripts may not be helpful, there is a host of other
+ sanity checking software on the net that may be applicable (feel
+ free to email me any recommendations). None of these will create
+ a bug-free release but they will avoid at least some major
+ oversights. Finally, if your programs become a long term
+ endeavor, you will find that there are certain errors that you
+ tend to make over and over. Start a collection of scripts that
+ check for these errors to help keep them out of future releases.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Testing by testers</title>
+ <para>
+ For any program that depends on user interactivity, many bugs
+ will only be uncovered through testing by users actually clicking
+ the keys and pressing the mouse buttons. For this you need
+ testers and as many as possible.
+ </para>
+
+ <para>
+ The most difficult part of testing is finding testers. It's
+ usually a good tactic to post a message to a relevant mailing
+ list or news group announcing a specific proposed release date
+ and outlining the functionality of your program. If you put some
+ time into the announcement, you are sure to get a few responses.
+ </para>
+
+ <para>
+ The second most difficult part of testing is
+ <emphasis>keeping</emphasis> your testers and keeping them
+ actively involved in the testing process. Fortunately, there are
+ some tried and true tactics that can applied toward this end:
+ </para>
+
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>Make things simple for your testers</term>
+ <listitem>
+ <para>Your testers are doing you a favor so make it as easy as
+ possible for them. This means that you should be careful to
+ package your software in a way that is easy to find, unpack,
+ install, and uninstall. This also means you should explain
+ what you are looking for to each tester and make the means for
+ reporting bugs simple and well established. The key is to
+ provide as much structure as possible to make your testers'
+ jobs easy and to maintain as much flexibility as possible for
+ those that want to do things a little differently.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Be responsive to your testers</term>
+ <listitem>
+ <para>When your testers submit bugs, respond to them and
+ respond quickly. Even if you are only responding to tell them
+ that the bug has already been fixed, quick and consistent
+ responses make them feel like their work is heard, important,
+ and appreciated.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Thank your testers</term>
+ <listitem>
+ <para>Thank them personally each time they send you
+ patch. Thank them publicly in the documentation and the about
+ section of your program. You appreciate your testers and your
+ program would not be possible without their help. Make sure
+ they know it. Publicly, pat them on the back to make sure the rest of
+ the world knows it too. It will be appreciated more than you
+ expected.</para>
+ </listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ </sect3>
+ </sect2>
+
+<!-- Section2: support -->
+
+ <sect2 id="support">
+ <title>Setting up Support Infrastructure</title>
+
+ <para>
+ While testing is important, the large part of your interactions
+ and responsibility to your users falls under the category of
+ support. The best way to make sure your users are adequately
+ supported in using your program is to set up a good infrastructure
+ for this purpose so that your developers and users help each other
+ and less of the burden falls on you. This way, people will also
+ get quicker and better responses to their questions. This
+ infrastructure comes in several major forms:
+ </para>
+
+ <sect3>
+ <title>Documentation</title>
+ <para>
+ It should not come as any surprise that the key element to any
+ support infrastructure is good documentation. This topic was
+ largely covered in <xref linkend="documentation"> and will not be
+ repeated here.
+ </para>
+ </sect3>
+
+ <sect3 id="mailinglists">
+ <title>Mailing lists</title>
+ <para>
+ Aside from documentation, effective mailing lists will be your
+ greatest tool in providing user support. Running a mailing list
+ well is more complicated than installing mailing list software
+ onto a machine.
+ </para>
+
+ <sect4>
+ <title>Separate lists</title>
+
+ <para>
+ A good idea is too separate your user and development mailing
+ lists (perhaps into project-user@host and project-devel@host)
+ and enforce the division. If people post a development question
+ onto -user, politely ask them to repost it onto -devel and vise
+ versa. Subscribe yourself to both groups and encourage all
+ primarily developers to do the same.
+ </para>
+
+ <para>
+ This system provides so that no one person is stuck doing all of
+ the support work and works so that users learn more about the
+ program, they can help newer users with their questions.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Choose mailing list software well</title>
+ <para>
+ Please don't make the selection of mailing list software
+ impulsively. Please consider easy accessibility by users without
+ a lot of technical experience so you want to be as easy as
+ possible. Web accessibility to an archive of the list is also
+ important.
+ </para>
+
+ <para>
+ The two biggest free software mailing list programs are <ulink
+ url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
+ and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
+ long time advocate of majordomo, I would now recommend any
+ project choose GNU Mailman. It fulfills the criteria listed
+ above and makes it easier. It provides a good mailing
+ list program for a free software project maintainer as opposed
+ to a good mailing list application for a mailing list
+ administrator.
+ </para>
+
+ <para>
+ There are other things you want to take into consideration in
+ setting up your list. If it is possible to gate your mailing
+ lists to Usenet and provide it in digest form as well as
+ making them accessible on the web, you will please some users
+ and work to make the support infrastructure slightly more
+ accessible.
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3>
+ <title>Other support ideas</title>
+
+ <para>
+ A mailing list and accessible documentation are far from all you
+ can do to set up good user support infrastructure. Be
+ creative. If you stumble across something that works well, email me
+ and I'll include it here.
+ </para>
+
+ <sect4>
+ <title>Make your self accessible</title>
+ <para>
+ You can not list too few methods to reach you. If you hang out
+ in an <acronym>IRC</acronym> channel, don't hesitate to list it
+ in your projects documentation. List email and snailmail
+ addresses, and ways to reach you via <acronym>ICQ</acronym>,
+ <acronym>AIM</acronym>, or Jabber if they apply.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Bug management software</title>
+ <para>
+ For many large software projects, use of bug management software
+ is essential to keep track of which bugs have been fixed, which
+ bugs have not been fixed, and which bugs are being fixed by
+ which people. Debian uses the <ulink
+ url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
+ (<acronym>BTS</acronym>) although it may not be best choice for
+ every project (it seems to currently be buckling under its own
+ weight) As well as a damn good web browser, the Mozilla project
+ has spawned a sub-project resulting in a bug tracking system
+ called <ulink
+ url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
+ which has become extremely possible and which I like a lot.
+ </para>
+
+ <para>
+ These systems (and others like them) can be unwieldy so
+ developers should be careful to not spend more time on the bug
+ tracking system than on the bugs or the projects themselves. If
+ a project continues to grow, use of a bug tracking system can
+ provide an easy standard avenue for users and testers to report
+ bugs and for developers and maintainers to fix them and track
+ them in an orderly fashion.
+ </para>
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: releasing -->
+
+ <sect2 id="releasing">
+ <title>Releasing Your Program</title>
+
+ <para>
+ As mentioned earlier in the HOWTO, the first rule of releasing is,
+ <emphasis>release something useful.</emphasis> Non-working or
+ not-useful software will not attract anyone to your
+ project. People will be turned off of your project and will be likely
+ to simply gloss over it next time they see a new version
+ announced. Half-working software, if useful, will intrigue people,
+ whet their appetites for versions to come, and encourage them to
+ join the development process.
+ </para>
+
+ <sect3>
+ <title>When to release</title>
+
+ <para>
+ Making the decision to release your software for the first time
+ is an incredibly important and incredibly stressful decision. But
+ it needs to done. My advice is to try and make something that
+ is complete enough to be usable and incomplete enough to allow
+ for flexibility and room for imagination by your future
+ developers. It's not an easy decision. Ask for help on a local
+ Linux User Group mailing list or from a group of developer
+ friends.
+ </para>
+
+ <para>
+ One tactic is to first do an <quote>alpha</quote> or
+ <quote>beta</quote> release as described below in <xref
+ linkend="alphabeta">. However, most of the guidelines described
+ above still apply.
+ </para>
+
+ <para>
+ <emphasis>When you feel in your gut that it is time and you feel
+ you've weighed the situation well several times, cross your
+ fingers and take the plunge.</emphasis>
+ </para>
+
+ <para>
+ After you've released for the first time, knowing when to release
+ becomes less stressful, but just as difficult to gauge. I like
+ the criteria offered by Robert Krawitz in his article, <ulink
+ url="http://www.advogato.org/article/196.html"><quote>Free
+ Software Project Management</quote></ulink> for maintaining a
+ good release cycle. He recommends that you ask yourself,
+ <quote>does this release...</quote>
+ </para>
+
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>Contain sufficient new functionality or bug fixes to be
+ worth the effort.</para>
+ </listitem>
+
+ <listitem>
+ <para>Be spaced sufficiently far apart to allow the user time
+ to work with the latest release.</para>
+ </listitem>
+
+ <listitem>
+ <para>Be sufficiently functional so that the user can get work
+ done (quality).</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ If the answer is yes to all of these questions, its probably time
+ for a release. If in doubt, remember that asking for advice can't
+ hurt.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>How to release</title>
+
+ <para>
+ If you've followed the guidelines described in this HOWTO up
+ until this point, the mechanics of doing a release are going to
+ be the easy part of releasing. If you have set up consistent
+ distribution locations and the other infrastructure described in
+ the preceding sections, releasing should be as simple as building
+ the package, checking it once over, and uploading it into the
+ appropriate place and then making your website reflect the
+ change.
+ </para>
+ </sect3>
+
+ <sect3 id="alphabeta">
+ <title>Alpha, beta, and development releases</title>
+
+ <para>
+ When contemplating releases, it worth considering the fact that
+ not every release needs to be a full numbered release. Software
+ users are accustomed to pre-releases but you must be careful to
+ label these releases accurately or they will cause more problems then
+ they are worth.
+ </para>
+
+ <para>
+ The observation is often made that many free software developers
+ seem to be confused about the release cycle. <quote><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink></quote> suggests that you memorize
+ the phrase, <quote>Alpha is not Beta. Beta is not Release</quote>
+ and I'd agree that tis is a probably a good idea.
+ </para>
+
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>alpha releases</term>
+ <listitem>
+ <para>Alpha software is feature-complete but sometimes only
+ partially functional.</para>
+
+ <para>Alpha releases are expected to be unstable, perhaps a
+ little unsafe, but definitely usable. They
+ <emphasis>can</emphasis> have known bugs and kinks that have
+ yet to be worked out. Before releasing an alpha, be sure to
+ keep in mind that <emphasis>alpha releases are still
+ releases</emphasis> and people are not going to be expecting a
+ nightly build from the CVS source. An alpha should work and
+ have minimal testing and bug fixing already finished.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>beta releases</term>
+ <listitem>
+ <para>Beta software is feature-complete and functional, but is
+ in the testing cycle and still has a few bugs left to be
+ ironed out.</para>
+
+ <para>Beta releases are general expected to be usable and
+ slightly unstable, although definitely <emphasis>not
+ unsafe.</emphasis> Beta releases usually preclude a full
+ release by under a month. They can contain small known bugs
+ but no major ones. All major functionality should be fully
+ implemented although the exact mechanics can still be worked
+ out. Beta releases are great tool to whet the appetites of
+ potential users by giving them a very realistic view of where
+ your project is going to be in the very near future and can
+ help keep interest by giving people
+ <emphasis>something.</emphasis></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>development releases</term>
+ <listitem>
+ <para><quote>Development release</quote> is much a more vague
+ term than <quote>alpha</quote> or <quote>beta</quote>. I
+ usually choose to reserve the term for discussion of a
+ development branch although there are other ways to use the
+ term. So many in fact, that I feel the term has been
+ cheapened. The popular window manager <ulink
+ url="http://www.enlightenment.org">Enlightenment</ulink> has
+ released <emphasis>nothing but</emphasis> development
+ releases. Most often, the term is used to describe releases
+ that are not even alpha or beta and if I were to release a
+ pre-alpha version of a piece of software in order to keep
+ interest in my project alive, this is probably how I would
+ have to label it.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </para>
+ </sect3>
+ </sect2>
+
+<!-- Section2: announcing -->
+
+ <sect2 id="announcing">
+ <title>Announcing Your Project</title>
+
+ <para>
+ Well, you've done it. You've (at least for the purposes of this
+ HOWTO) designed, built, and released your free software
+ project. All that is left is for you to tell the world so they
+ know to come and try it out and hopefully jump on board with
+ development. If everything is in order as described above, this
+ will be a quick and painless process. A quick announcement is all
+ that it takes to put yourself on the free software community's
+ radar screen.
+ </para>
+
+ <sect3>
+ <title>Mailing lists and Usenet</title>
+
+ <para>Announce your software on Usenet's <ulink
+ url="news:comp.os.linux.announce">comp.os.linux.announce</ulink>. If
+ you only announce your software in two places, have it be c.o.l.a
+ and freshmeat.</para>
+
+ <para>
+ However, email is still the way that most people on the Internet
+ get their information. Its a good idea to send a message
+ announcing your program to any relevant mailing list you know of
+ and any other relevant Usenet discussion groups.</para>
+
+ <para>Karl Fogel recommends that use you simple subject
+ describing the fact that the message is an announcement, the name
+ of the program, the version, and a half-line long description of
+ its functionality. This way, any interested user or developer
+ will be immediately attracted to your announcement. Fogel's
+ example looks like:
+ </para>
+
+ <screen>Subject: ANN: aub 1.0, a program to assemble Usenet binaries</screen>
+
+ <para>
+ The rest of the email should describe the programs functionality
+ quickly and concisely in no more than two paragraphs and should
+ provide links to the projects webpage and direct links to
+ downloads for those that want to try it right away. This form
+ will work for both Usenet and mailing list posts.
+ </para>
+
+ <para>
+ You should repeat this announcement process consistently in the
+ same locations for each subsequent release.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>freshmeat.net</title>
+ <para>
+ Mentioned earlier in <xref linkend="evalwhere">, in today's free
+ software community, announcements of your project on freshmeat
+ are almost more important than announcements on mailing lists.
+ </para>
+
+ <para>
+ Visit the <ulink url="http://freshmeat.net">freshmeat.net
+ website</ulink> or their <ulink
+ url="http://freshmeat.net/add-project/">submit project
+ page</ulink> to post your project onto their site and into their
+ database. In addition to a large website, freshmeat provides a
+ daily newsletter that highlights all the days releases and
+ reaches a huge audience (I personally skim it every night for any
+ interesting new releases).
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Project Mailing List</title>
+
+ <para>If you've gone ahead and created mailing lists for your
+ project, you should always announce new versions on these
+ lists. I've found that for many projects, users request a very
+ low-volume announce only mailing list to be notified when new
+ versions are released. freshmeat.net now allows users to subscribe
+ to a particular project so they receive emails every time a new
+ version is announced through their system. It's free and it can
+ stand in for an announce-only mailing list. In my opinion, it
+ can't hurt.</para>
+ </sect3>
+ </sect2>
+</sect1>
+
+ <bibliography>
+
+ <bibliodiv>
+ <title>Printed Books</title>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Fogel</surname>
+ <firstname>Karl</firstname>
+ </author>
+
+ <title>Open Source Development with CVS</title>
+
+ <publisher>
+ <publishername>Coriolois Open Press</publishername>
+ </publisher>
+ <pubdate>1999</pubdate>
+
+ <isbn>1-57610-490-7</isbn>
+
+ <abstract>
+ <para>
+ Fogel's <quote>guide to using CVS in the free software
+ world</quote> is much more than its subtitle. In the publisher's
+ own words: <quote><emphasis>Open Source Development with
+ CVS</emphasis> is one of the first books available that teaches
+ you development and implementation of Open Source
+ software.</quote> It also includes the best reference and
+ tutorial to CVS I have ever seen. It is the book that was
+ <emphasis>so good</emphasis> that it prompted me to write this
+ HOWTO because I thought the role it tried to serve was so
+ important and useful. Please check it or buy it if you can and
+ are seriously interested in running a free software project.
+ </para>
+
+ <para>In May of 2003, the entire book under the GPL. You can
+ find the full text of the book <ulink
+ url="http://cvsbook.red-bean.com/">here</ulink>.</para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry
+ <biblioset>
+ <author>
+ <surname>Lessig</surname>
+ <firstname>Lawrence</firstname>
+ </author>
+
+ <title>Code and Other Laws of Cyberspace</title>
+
+ <publisher>
+ <publishername>Basic Books</publishername>
+ </publisher>
+ <pubdate>2000</pubdate>
+
+ <isbn>0-465-03913-8</isbn>
+
+ <abstract>
+ <para>
+ While it only briefly talks about free software (and does it by
+ tiptoeing around the free software/open source issue with the
+ spineless use of the term <quote>open code</quote> that only a
+ lawyer could coin), Lessig's book is brilliant. Written by a
+ lawyer, it talks about how regulation on the Internet is not
+ done with law, but with the code itself and how the nature of
+ the code will determine the nature of future freedoms. In
+ addition to being a quick and enjoyable read, it gives some
+ cool history and describes how we <emphasis>need</emphasis>
+ free software in a way more powerfully than anything I've read
+ outside of <ulink
+ url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
+ <quote>Right to Read.</quote></ulink>
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Raymond</surname>
+ <firstname>Eric</firstname>
+ </author>
+
+ <title>The Cathedral and the Bazaar</title>
+ <subtitle>Musings on Linux and Open Source by an Accidental Revolutionary</subtitle>
+
+ <publisher>
+ <publishername>O'Reilly</publishername>
+ </publisher>
+ <pubdate>1999</pubdate>
+
+ <isbn>1-56592-724-9</isbn>
+ <abstract>
+ <para>
+ Although I have to honestly say that I am not the ESR fan that
+ I used to be, this book proved invaluable in getting me where I
+ am today. The essay that gives the book its title does a good
+ job of sketching the free software process and does an an
+ amazing job of making an argument for free software/open source
+ development as a road to better software. The rest of the book
+ has other of ESR's articles, which for the most part are posted
+ on his website. Still, it's nice thing to own in hard copy and
+ something that every free software/open source hacker should
+ read.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ </bibliodiv>
+
+ <bibliodiv>
+ <title>Web-Accessible Resources</title>
+
+ <para>
+ This is a list of the web resources pertaining to this HOWTO that
+ I've found most helpful in compiling this information. If you know
+ of others that would help, please don't hesitate to email me at
+ <email>mako@debian.org</email> and we can look into getting it
+ added to the list and represented in the HOWTO.
+ </para>
+
+ <para>
+ I'd recommend that any free software developer (or potential one)
+ skim through these sites because they have each have a lot to say.
+ </para>
+
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Dafermos</surname>
+ <firstname>George</firstname>
+ <othername>N</othername>
+ </author>
+
+ <title><ulink url="http://firstmonday.org/issues/issue6_11/dafermos/">Management and Virtual Decentralized Networks: The Linux Project</ulink></title>
+
+ <abstract>
+ <para>Since the paper includes its own abstract, I thought I
+ would include it here verbatim:</para>
+
+ <para><blockquote><para>This paper examines the latest of
+ paradigms - the Virtual Network(ed) Organisation - and whether
+ geographically dispersed knowledge workers can virtually
+ collaborate for a project under no central
+ planning. Co-ordination, management and the role of knowledge
+ arise as the central areas of focus. The Linux Project and its
+ development model are selected as a case of analysis and the
+ critical success factors of this organisational design are
+ identified. The study proceeds to the formulation of a
+ framework that can be applied to all kinds of virtual
+ decentralised work and concludes that value creation is
+ maximized when there is intense interaction and uninhibited
+ sharing of information between the organisation and the
+ surrounding community. Therefore, the potential success or
+ failure of this organisational paradigm depends on the degree
+ of dedication and involvement by the surrounding
+ community.</para></blockquote></para>
+
+ <para>This paper was referred to me in my capacity as author of
+ this HOWTO and I was very impressed. It's written by a graduate
+ student in management and I think it succeeds at evaluating the
+ Linux project as an example of a new paradigm in management--one
+ that <emphasis>you</emphasis> will be be placing yourself at the
+ center of in your capacity as maintainer of a free software
+ project.</para>
+
+ <para>As a developer trying to control an application and guide
+ it to success in the free software world, I'm not sure how
+ useful Dafermos's argument is. It does however, provide a
+ theoretical justification for my HOWTO--free software project
+ management <emphasis>is</emphasis> a different creature than
+ proprietary software project management. If you are interested
+ in the conceptual and theoretical ways that free software
+ project management differs from other types of management, this
+ is a great paper to read. If this paper answers questions of
+ <quote>how?</quote>, Dafermos answers the (more difficult to
+ defend) questions of <quote>why?</quote> and does a very good
+ job.</para>
+
+
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Gabriel</surname>
+ <firstname>Richard</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
+ <quote>Worse is Better</quote></ulink></title>
+
+ <abstract>
+ <para>
+ A well written article although I think the title may have
+ confused as many people as the rest of the essay helped. It
+ offers a good description of how to design programs that will
+ succeed and stay maintainable as they grow.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Manley</surname>
+ <firstname>Montey</firstname>
+ </author>
+
+ <title><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink></title>
+
+ <publisher>
+ <publishername><ulink
+ url="http://www.linuxprogramming.com">Linux
+ Programming</ulink></publishername>
+ </publisher>
+ <pubdate>Oct 31, 2000</pubdate>
+
+ <abstract>
+ <para>
+ In one of the better articles on the subject that I've read,
+ Monty sums up some of the major points I touch on including:
+ starting a project, testing, documentation, organizing a team and
+ leadership, and several other topics. While more opinionated that
+ I try to be, I think its an important article that I found very
+ helpful in writing this HOWTO. I've tried to cite him in
+ the places where I borrowed from him most.
+ </para>
+
+ <para>
+ I have problems much of this piece and I recommend you read
+ <xref linkend="krawitz"> at the same time you read Monty's
+ article for a good critique.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry id="esrhowto">
+ <biblioset>
+ <author>
+ <surname>Raymond</surname>
+ <firstname>Eric</firstname>
+ <othername>Steven</othername>
+ </author>
+
+ <title><ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">Software Release Practice HOWTO</ulink></title>
+
+ <abstract>
+
+ <para>At first glance, ESR's release practice HOWTO seems to
+ share a lot of terrain with this document. Upon closer
+ examination, the differences become apparent but they are
+ closely related. His document, read in conjunction with mine,
+ will give a reader a good picture of how to go about managing a
+ project. ESR's HOWTO goes into a bit more detail on how to write
+ and what languages to write in. He tends to give more specific
+ instructions and checklists (<quote>name this file this, not
+ this</quote>) while this HOWTO speaks more conceptually. There
+ are several sections that are extremely similar. It's also
+ <emphasis>much</emphasis> shorter.</para>
+
+ <para>My favorite quote from his HOWTO is: <quote>"Managing a
+ project well when all the participants are volunteers presents
+ some unique challenges. This is too large a topic to cover in a
+ HOWTO.</quote> Oh really? Perhaps I just do a poor job.</para>
+ </abstract>
+
+ </biblioset>
+ </biblioentry>
+
+
+ <biblioentry id="cvsbestpractices">
+ <biblioset>
+ <author>
+ <surname>Venugopalan</surname>
+ <firstname>Vivek</firstname>
+ </author>
+
+ <title><ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html">CVS Best Practices</ulink></title>
+
+ <abstract>
+
+ <para>Venugopalan provides one of the best essays on
+ effective use of CVS that I've come across. It is written for
+ people who already have a good knowledge of CVS. In the chapter
+ on branching, he describes when and how to branch but gives no
+ information on what CVS commands you should use to do this. This
+ is fine (technical CVS HOWTO have been written) but CVS newbies
+ will want to spend some time with Fogel's reference before they
+ will find this one very useful.</para>
+
+ <para>Venugopalan creates checklists of things to do before,
+ after, and around releases. It's definitely worth a read through
+ as most of his ideas will save tons of developer head aches over
+ any longer period of time.</para>
+
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ </bibliodiv>
+
+ <bibliodiv>
+ <title>Advogato Articles</title>
+
+ <para>
+ I've found that one of the best resources that any free software
+ developer has at his or her disposal is Advogato.org. If you haven't
+ yet had a chance to visit <ulink url="http://www.advogato.org">the
+ website</ulink>, do.
+ </para>
+
+ <para>
+ I have spent a huge amount of time on Advogato and I've gone
+ through and provided links to the articles that I think might be
+ of particular interest to anyone reading this HOWTO. I think that
+ skimming through these links can be helpful and I promise that if
+ you do, you'll learn a lot. You will learn that my idea of how a
+ free software project should be run is not the
+ <emphasis>only</emphasis> idea. I think that's important.
+ </para>
+
+ <para>
+ If nothing else, there is <emphasis>way</emphasis> more
+ information on that website than I could ever fit into, or
+ reference from this HOWTO. I have listed what I think are the most
+ relevant articles here with short descriptions that I've written.
+ </para>
+
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Hindle</surname>
+ <firstname>Stephen</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/262.html">'Best Practices' for Open Source?</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>March 21, 2001</pubdate>
+
+ <abstract>
+ <para>
+ Touching mostly on programming practice (as most articles on
+ the subject usually do), the article talks a little about
+ project management (<quote>Use it!</quote>) and a bit about
+ communication within a free software project.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Cohen</surname>
+ <firstname>Bram</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/258.html"></ulink>How to
+ Write Maintainable Code</title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>March 15, 2001</pubdate>
+
+ <abstract>
+ <para>
+ This article touches upon the "writing maintainable code"
+ discussion that I try hard to avoid in my HOWTO. It's one of
+ the better (and most diplomatic) articles on the subject that
+ I've found.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ <biblioentry id="krawitz">
+ <biblioset>
+ <author>
+ <surname>Krawitz</surname>
+ <firstname>Robert</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/196.html">Free
+ Source Project Management</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>November 4, 2000</pubdate>
+
+ <abstract>
+ <para>
+ This article made me happy because it challenged many of the
+ problems that I had with Monty's article on <ulink
+ url="http://www.linuxprogramming.com">LinuxProgramming</ulink>. The
+ author argues that Monty calls simply for the application of
+ old (proprietary software) project management techniques in
+ free software projects instead of working to come up with
+ something new. I found his article to be extremely well thought
+ out and I think it's an essential read for any free software
+ project manager.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Martins</surname>
+ <firstname>Lalo</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/128.html">Ask
+ the Advogatos: why do Free Software projects
+ fail?</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>July 20, 2000</pubdate>
+
+ <abstract>
+ <para>
+ While the article is little more than a question, reading the
+ answers to this question offered by Advogato's readers can
+ help. In a lot of ways, this HOWTO acts as my answer to the
+ questions posed in this article but there are others, many of
+ which might take issue with whats is in this HOWTO. It's worth
+ checking out.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Burley</surname>
+ <firstname>David</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/107.html">In-Roads to Free
+ Software Development</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>June 14, 2000</pubdate>
+
+ <abstract>
+ <para>
+ This document was written as a response to <ulink
+ url="http://www.advogato.org/article/72.html">another Advogato
+ article</ulink>. Although not about running a project, this
+ describes some of the ways that you can get started with free
+ software development without starting a project. I think this
+ is an important article. If you are interested in becoming
+ involved with free software, this article showcases some of the
+ ways that you can do this without actually starting a project
+ (something that I hope this HOWTO has demonstrated is not to be
+ taken lightly).
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Moorman</surname>
+ <firstname>Jacob</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/72.html">Importance of
+ Non-Developer Supporters in Free Software</ulink><title></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>April 16, 2000</pubdate>
+
+ <abstract>
+ <para>
+ Moorman's is a short article but it brings up some good
+ points. The comment reminding developers to thank their testers
+ and end-users is invaluable and oft-forgotten.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Orchard</surname>
+ <firstname>Leslie</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/67.html">On
+ Naming an Open Source Project</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>April 12, 2000</pubdate>
+
+ <abstract>
+ <para>
+ I didn't even have a section on project naming in this HOWTO
+ (See <xref linkend="naming">) until Leslie Orchard's article
+ reminded me of it. Thanks to Leslie for writing this article!
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Allen</surname>
+ <firstname>David</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/40.html">Version Numbering Madness</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>February 28, 2000</pubdate>
+
+ <abstract>
+ <para>
+ In this article, David Allen challenges the whole
+ <quote>Major.Minor.Patch</quote> version numbering scheme. Its
+ good to read this as you read <xref
+ linkend="chooseversioning">. I liked the article and it
+ describes some of the projects that I bring up in my discussion
+ of version numbering.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ </bibliodiv>
+ </bibliography>
+
+<!--
+ The GNU Free Documentation License 1.1 in DocBook
+ Markup by Eric Baudais <baudais@okstate.edu>
+ Maintained by the GNOME Documentation Project
+ http://developer.gnome.org/projects/gdp
+ Version: 1.0.1
+ Last Modified: Nov 16, 2000
+-->
+
+<appendix id="fdl">
+ <docinfo>
+ <releaseinfo>
+ Version 1.1, March 2000
+ </releaseinfo>
+ <copyright>
+ <year>2000</year><holder>Free Software Foundation, Inc.</holder>
+ </copyright>
+ <legalnotice id="fdl-legalnotice">
+ <para>
+ <address>Free Software Foundation, Inc. <street>59 Temple Place,
+ Suite 330</street>, <city>Boston</city>, <state>MA</state>
+ <postcode>02111-1307</postcode> <country>USA</country></address>
+ Everyone is permitted to copy and distribute verbatim copies of this
+ license document, but changing it is not allowed.
+ </para>
+ </legalnotice>
+ </docinfo>
+ <title>GNU Free Documentation License</title>
+
+ <simplesect id="fdl-preamble">
+ <title>0. PREAMBLE</title>
+ <para>
+ The purpose of this License is to make a manual, textbook, or
+ other written document <quote>free</quote> in the sense of
+ freedom: to assure everyone the effective freedom to copy and
+ redistribute it, with or without modifying it, either
+ commercially or non-commercially. Secondarily, this License
+ preserves for the author and publisher a way to get credit for
+ their work, while not being considered responsible for
+ modifications made by others.
+ </para>
+
+ <para>
+ This License is a kind of <quote>copyleft</quote>, which means
+ that derivative works of the document must themselves be free in
+ the same sense. It complements the GNU General Public License,
+ which is a copyleft license designed for free software.
+ </para>
+
+ <para>
+ We have designed this License in order to use it for manuals for
+ free software, because free software needs free documentation: a
+ free program should come with manuals providing the same
+ freedoms that the software does. But this License is not limited
+ to software manuals; it can be used for any textual work,
+ regardless of subject matter or whether it is published as a
+ printed book. We recommend this License principally for works
+ whose purpose is instruction or reference.
+ </para>
+ </simplesect>
+ <simplesect id="fdl-simplesect1">
+ <title>1. APPLICABILITY AND DEFINITIONS</title>
+ <para id="fdl-document">
+ This License applies to any manual or other work that contains a
+ notice placed by the copyright holder saying it can be
+ distributed under the terms of this License. The
+ <quote>Document</quote>, below, refers to any such manual or
+ work. Any member of the public is a licensee, and is addressed
+ as <quote>you</quote>.
+ </para>
+
+ <para id="fdl-modified">
+ A <quote>Modified Version</quote> of the Document means any work
+ containing the Document or a portion of it, either copied
+ verbatim, or with modifications and/or translated into another
+ language.
+ </para>
+
+ <para id="fdl-secondary">
+ A <quote>Secondary Section</quote> is a named appendix or a
+ front-matter section of the <link
+ linkend="fdl-document">Document</link> that deals exclusively
+ with the relationship of the publishers or authors of the
+ Document to the Document's overall subject (or to related
+ matters) and contains nothing that could fall directly within
+ that overall subject. (For example, if the Document is in part a
+ textbook of mathematics, a Secondary Section may not explain any
+ mathematics.) The relationship could be a matter of historical
+ connection with the subject or with related matters, or of
+ legal, commercial, philosophical, ethical or political position
+ regarding them.
+ </para>
+
+ <para id="fdl-invariant">
+ The <quote>Invariant Sections</quote> are certain <link
+ linkend="fdl-secondary"> Secondary Sections</link> whose titles
+ are designated, as being those of Invariant Sections, in the
+ notice that says that the <link
+ linkend="fdl-document">Document</link> is released under this
+ License.
+ </para>
+
+ <para id="fdl-cover-texts">
+ The <quote>Cover Texts</quote> are certain short passages of
+ text that are listed, as Front-Cover Texts or Back-Cover Texts,
+ in the notice that says that the <link
+ linkend="fdl-document">Document</link> is released under this
+ License.
+ </para>
+
+ <para id="fdl-transparent">
+ A <quote>Transparent</quote> copy of the <link
+ linkend="fdl-document"> Document</link> means a machine-readable
+ copy, represented in a format whose specification is available
+ to the general public, whose contents can be viewed and edited
+ directly and straightforwardly with generic text editors or (for
+ images composed of pixels) generic paint programs or (for
+ drawings) some widely available drawing editor, and that is
+ suitable for input to text formatters or for automatic
+ translation to a variety of formats suitable for input to text
+ formatters. A copy made in an otherwise Transparent file format
+ whose markup has been designed to thwart or discourage
+ subsequent modification by readers is not Transparent. A copy
+ that is not <quote>Transparent</quote> is called
+ <quote>Opaque</quote>.
+ </para>
+
+ <para>
+ Examples of suitable formats for Transparent copies include
+ plain ASCII without markup, Texinfo input format, LaTeX input
+ format, SGML or XML using a publicly available DTD, and
+ standard-conforming simple HTML designed for human
+ modification. Opaque formats include PostScript, PDF,
+ proprietary formats that can be read and edited only by
+ proprietary word processors, SGML or XML for which the DTD
+ and/or processing tools are not generally available, and the
+ machine-generated HTML produced by some word processors for
+ output purposes only.
+ </para>
+
+ <para id="fdl-title-page">
+ The <quote>Title Page</quote> means, for a printed book, the
+ title page itself, plus such following pages as are needed to
+ hold, legibly, the material this License requires to appear in
+ the title page. For works in formats which do not have any title
+ page as such, <quote>Title Page</quote> means the text near the
+ most prominent appearance of the work's title, preceding the
+ beginning of the body of the text.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section2">
+ <title>2. VERBATIM COPYING</title>
+ <para>
+ You may copy and distribute the <link
+ linkend="fdl-document">Document</link> in any medium, either
+ commercially or non-commercially, provided that this License, the
+ copyright notices, and the license notice saying this License
+ applies to the Document are reproduced in all copies, and that
+ you add no other conditions whatsoever to those of this
+ License. You may not use technical measures to obstruct or
+ control the reading or further copying of the copies you make or
+ distribute. However, you may accept compensation in exchange for
+ copies. If you distribute a large enough number of copies you
+ must also follow the conditions in <link
+ linkend="fdl-section3">section 3</link>.
+ </para>
+
+ <para>
+ You may also lend copies, under the same conditions stated
+ above, and you may publicly display copies.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section3">
+ <title>3. COPYING IN QUANTITY</title>
+ <para>
+ If you publish printed copies of the <link
+ linkend="fdl-document">Document</link> numbering more than 100,
+ and the Document's license notice requires <link
+ linkend="fdl-cover-texts">Cover Texts</link>, you must enclose
+ the copies in covers that carry, clearly and legibly, all these
+ Cover Texts: Front-Cover Texts on the front cover, and
+ Back-Cover Texts on the back cover. Both covers must also
+ clearly and legibly identify you as the publisher of these
+ copies. The front cover must present the full title with all
+ words of the title equally prominent and visible. You may add
+ other material on the covers in addition. Copying with changes
+ limited to the covers, as long as they preserve the title of the
+ <link linkend="fdl-document">Document</link> and satisfy these
+ conditions, can be treated as verbatim copying in other
+ respects.
+ </para>
+
+ <para>
+ If the required texts for either cover are too voluminous to fit
+ legibly, you should put the first ones listed (as many as fit
+ reasonably) on the actual cover, and continue the rest onto
+ adjacent pages.
+ </para>
+
+ <para>
+ If you publish or distribute <link
+ linkend="fdl-transparent">Opaque</link> copies of the <link
+ linkend="fdl-document">Document</link> numbering more than 100,
+ you must either include a machine-readable <link
+ linkend="fdl-transparent">Transparent</link> copy along with
+ each Opaque copy, or state in or with each Opaque copy a
+ publicly-accessible computer-network location containing a
+ complete Transparent copy of the Document, free of added
+ material, which the general network-using public has access to
+ download anonymously at no charge using public-standard network
+ protocols. If you use the latter option, you must take
+ reasonably prudent steps, when you begin distribution of Opaque
+ copies in quantity, to ensure that this Transparent copy will
+ remain thus accessible at the stated location until at least one
+ year after the last time you distribute an Opaque copy (directly
+ or through your agents or retailers) of that edition to the
+ public.
+ </para>
+
+ <para>
+ It is requested, but not required, that you contact the authors
+ of the <link linkend="fdl-document">Document</link> well before
+ redistributing any large number of copies, to give them a chance
+ to provide you with an updated version of the Document.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section4">
+ <title>4. MODIFICATIONS</title>
+ <para>
+ You may copy and distribute a <link
+ linkend="fdl-modified">Modified Version</link> of the <link
+ linkend="fdl-document">Document</link> under the conditions of
+ sections <link linkend="fdl-section2">2</link> and <link
+ linkend="fdl-section3">3</link> above, provided that you release
+ the Modified Version under precisely this License, with the
+ Modified Version filling the role of the Document, thus
+ licensing distribution and modification of the Modified Version
+ to whoever possesses a copy of it. In addition, you must do
+ these things in the Modified Version:
+ </para>
+
+ <itemizedlist mark="opencircle">
+ <listitem>
+ <formalpara>
+ <title>A</title>
+ <para>
+ Use in the <link linkend="fdl-title-page">Title
+ Page</link> (and on the covers, if any) a title distinct
+ from that of the <link
+ linkend="fdl-document">Document</link>, and from those of
+ previous versions (which should, if there were any, be
+ listed in the History section of the Document). You may
+ use the same title as a previous version if the original
+ publisher of that version gives permission.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>B</title>
+ <para>
+ List on the <link linkend="fdl-title-page">Title
+ Page</link>, as authors, one or more persons or entities
+ responsible for authorship of the modifications in the
+ <link linkend="fdl-modified">Modified Version</link>,
+ together with at least five of the principal authors of
+ the <link linkend="fdl-document">Document</link> (all of
+ its principal authors, if it has less than five).
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>C</title>
+ <para>
+ State on the <link linkend="fdl-title-page">Title
+ Page</link> the name of the publisher of the <link
+ linkend="fdl-modified">Modified Version</link>, as the
+ publisher.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>D</title>
+ <para>
+ Preserve all the copyright notices of the <link
+ linkend="fdl-document">Document</link>.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>E</title>
+ <para>
+ Add an appropriate copyright notice for your modifications
+ adjacent to the other copyright notices.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>F</title>
+ <para>
+ Include, immediately after the copyright notices, a
+ license notice giving the public permission to use the
+ <link linkend="fdl-modified">Modified Version</link> under
+ the terms of this License, in the form shown in the
+ Addendum below.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>G</title>
+ <para>
+ Preserve in that license notice the full lists of <link
+ linkend="fdl-invariant"> Invariant Sections</link> and
+ required <link linkend="fdl-cover-texts">Cover
+ Texts</link> given in the <link
+ linkend="fdl-document">Document's</link> license notice.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>H</title>
+ <para>
+ Include an unaltered copy of this License.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>I</title>
+ <para>
+ Preserve the section entitled <quote>History</quote>, and
+ its title, and add to it an item stating at least the
+ title, year, new authors, and publisher of the <link
+ linkend="fdl-modified">Modified Version </link>as given on
+ the <link linkend="fdl-title-page">Title Page</link>. If
+ there is no section entitled <quote>History</quote> in the
+ <link linkend="fdl-document">Document</link>, create one
+ stating the title, year, authors, and publisher of the
+ Document as given on its Title Page, then add an item
+ describing the Modified Version as stated in the previous
+ sentence.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>J</title>
+ <para>
+ Preserve the network location, if any, given in the <link
+ linkend="fdl-document">Document</link> for public access
+ to a <link linkend="fdl-transparent">Transparent</link>
+ copy of the Document, and likewise the network locations
+ given in the Document for previous versions it was based
+ on. These may be placed in the <quote>History</quote>
+ section. You may omit a network location for a work that
+ was published at least four years before the Document
+ itself, or if the original publisher of the version it
+ refers to gives permission.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>K</title>
+ <para>
+ In any section entitled <quote>Acknowledgements</quote> or
+ <quote>Dedications</quote>, preserve the section's title,
+ and preserve in the section all the substance and tone of
+ each of the contributor acknowledgements and/or
+ dedications given therein.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>L</title>
+ <para>
+ Preserve all the <link linkend="fdl-invariant">Invariant
+ Sections</link> of the <link
+ linkend="fdl-document">Document</link>, unaltered in their
+ text and in their titles. Section numbers or the
+ equivalent are not considered part of the section titles.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>M</title>
+ <para>
+ Delete any section entitled
+ <quote>Endorsements</quote>. Such a section may not be
+ included in the <link linkend="fdl-modified">Modified
+ Version</link>.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>N</title>
+ <para>
+ Do not retitle any existing section as
+ <quote>Endorsements</quote> or to conflict in title with
+ any <link linkend="fdl-invariant">Invariant
+ Section</link>.
+ </para>
+ </formalpara>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ If the <link linkend="fdl-modified">Modified Version</link>
+ includes new front-matter sections or appendices that qualify as
+ <link linkend="fdl-secondary">Secondary Sections</link> and
+ contain no material copied from the Document, you may at your
+ option designate some or all of these sections as invariant. To
+ do this, add their titles to the list of <link
+ linkend="fdl-invariant">Invariant Sections</link> in the
+ Modified Version's license notice. These titles must be
+ distinct from any other section titles.
+ </para>
+
+ <para>
+ You may add a section entitled <quote>Endorsements</quote>,
+ provided it contains nothing but endorsements of your <link
+ linkend="fdl-modified">Modified Version</link> by various
+ parties--for example, statements of peer review or that the text
+ has been approved by an organization as the authoritative
+ definition of a standard.
+ </para>
+
+ <para>
+ You may add a passage of up to five words as a <link
+ linkend="fdl-cover-texts">Front-Cover Text</link>, and a passage
+ of up to 25 words as a <link
+ linkend="fdl-cover-texts">Back-Cover Text</link>, to the end of
+ the list of <link linkend="fdl-cover-texts">Cover Texts</link>
+ in the <link linkend="fdl-modified">Modified Version</link>.
+ Only one passage of Front-Cover Text and one of Back-Cover Text
+ may be added by (or through arrangements made by) any one
+ entity. If the <link linkend="fdl-document">Document</link>
+ already includes a cover text for the same cover, previously
+ added by you or by arrangement made by the same entity you are
+ acting on behalf of, you may not add another; but you may
+ replace the old one, on explicit permission from the previous
+ publisher that added the old one.
+ </para>
+
+ <para>
+ The author(s) and publisher(s) of the <link
+ linkend="fdl-document">Document</link> do not by this License
+ give permission to use their names for publicity for or to
+ assert or imply endorsement of any <link
+ linkend="fdl-modified">Modified Version </link>.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section5">
+ <title>5. COMBINING DOCUMENTS</title>
+ <para>
+ You may combine the <link linkend="fdl-document">Document</link>
+ with other documents released under this License, under the
+ terms defined in <link linkend="fdl-section4">section 4</link>
+ above for modified versions, provided that you include in the
+ combination all of the <link linkend="fdl-invariant">Invariant
+ Sections</link> of all of the original documents, unmodified,
+ and list them all as Invariant Sections of your combined work in
+ its license notice.
+ </para>
+
+ <para>
+ The combined work need only contain one copy of this License,
+ and multiple identical <link linkend="fdl-invariant">Invariant
+ Sections</link> may be replaced with a single copy. If there are
+ multiple Invariant Sections with the same name but different
+ contents, make the title of each such section unique by adding
+ at the end of it, in parentheses, the name of the original
+ author or publisher of that section if known, or else a unique
+ number. Make the same adjustment to the section titles in the
+ list of Invariant Sections in the license notice of the combined
+ work.
+ </para>
+
+ <para>
+ In the combination, you must combine any sections entitled
+ <quote>History</quote> in the various original documents,
+ forming one section entitled <quote>History</quote>; likewise
+ combine any sections entitled <quote>Acknowledgements</quote>,
+ and any sections entitled <quote>Dedications</quote>. You must
+ delete all sections entitled <quote>Endorsements.</quote>
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section6">
+ <title>6. COLLECTIONS OF DOCUMENTS</title>
+ <para>
+ You may make a collection consisting of the <link
+ linkend="fdl-document">Document</link> and other documents
+ released under this License, and replace the individual copies
+ of this License in the various documents with a single copy that
+ is included in the collection, provided that you follow the
+ rules of this License for verbatim copying of each of the
+ documents in all other respects.
+ </para>
+
+ <para>
+ You may extract a single document from such a collection, and
+ dispbibute it individually under this License, provided you
+ insert a copy of this License into the extracted document, and
+ follow this License in all other respects regarding verbatim
+ copying of that document.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section7">
+ <title>7. AGGREGATION WITH INDEPENDENT WORKS</title>
+ <para>
+ A compilation of the <link
+ linkend="fdl-document">Document</link> or its derivatives with
+ other separate and independent documents or works, in or on a
+ volume of a storage or distribution medium, does not as a whole
+ count as a <link linkend="fdl-modified">Modified Version</link>
+ of the Document, provided no compilation copyright is claimed
+ for the compilation. Such a compilation is called an
+ <quote>aggregate</quote>, and this License does not apply to the
+ other self-contained works thus compiled with the Document , on
+ account of their being thus compiled, if they are not themselves
+ derivative works of the Document. If the <link
+ linkend="fdl-cover-texts">Cover Text</link> requirement of <link
+ linkend="fdl-section3">section 3</link> is applicable to these
+ copies of the Document, then if the Document is less than one
+ quarter of the entire aggregate, the Document's Cover Texts may
+ be placed on covers that surround only the Document within the
+ aggregate. Otherwise they must appear on covers around the whole
+ aggregate.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section8">
+ <title>8. TRANSLATION</title>
+ <para>
+ Translation is considered a kind of modification, so you may
+ distribute translations of the <link
+ linkend="fdl-document">Document</link> under the terms of <link
+ linkend="fdl-section4">section 4</link>. Replacing <link
+ linkend="fdl-invariant"> Invariant Sections</link> with
+ translations requires special permission from their copyright
+ holders, but you may include translations of some or all
+ Invariant Sections in addition to the original versions of these
+ Invariant Sections. You may include a translation of this
+ License provided that you also include the original English
+ version of this License. In case of a disagreement between the
+ translation and the original English version of this License,
+ the original English version will prevail.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section9">
+ <title>9. TERMINATION</title>
+ <para>
+ You may not copy, modify, sublicense, or distribute the <link
+ linkend="fdl-document">Document</link> except as expressly
+ provided for under this License. Any other attempt to copy,
+ modify, sublicense or distribute the Document is void, and will
+ automatically terminate your rights under this License. However,
+ parties who have received copies, or rights, from you under this
+ License will not have their licenses terminated so long as such
+ parties remain in full compliance.
+ </para>
+ </simplesect>
+
+ <simplesect id="fdl-section10">
+ <title>10. FUTURE REVISIONS OF THIS LICENSE</title>
+ <para>
+ The <ulink type="http"
+ url="http://www.gnu.org/fsf/fsf.html">Free Software
+ Foundation</ulink> may publish new, revised versions of the GNU
+ Free Documentation License from time to time. Such new versions
+ will be similar in spirit to the present version, but may differ
+ in detail to address new problems or concerns. See <ulink
+ type="http"
+ url="http://www.gnu.org/copyleft">http://www.gnu.org/copyleft/</ulink>.
+ </para>
+
+ <para>
+ Each version of the License is given a distinguishing version
+ number. If the <link linkend="fdl-document">Document</link>
+ specifies that a particular numbered version of this License
+ <quote>or any later version</quote> applies to it, you have the
+ option of following the terms and conditions either of that
+ specified version or of any later version that has been
+ published (not as a draft) by the Free Software Foundation. If
+ the Document does not specify a version number of this License,
+ you may choose any version ever published (not as a draft) by
+ the Free Software Foundation.
+ </para>
+ </simplesect>
+</appendix>
projects / fspm_howto / blobdiff