<primary>fswd!developers</primary>
</indexterm>
+ <para>
+ Once you have gotten the project started, you have gotten over the
+ most difficult hurdles in the development process of your
+ program. Laying a firm foundation is essential, but the development
+ process itself is equally important and provides an equal number of
+ opportunities for failure. In the next two sections, I will and
+ cover running a project by discussing how to maintain a project
+ rhough interactions with developers and with users.
+ </para>
+
+ <para>
+ The difference between free software development and propriety
+ software development is th developer base. As the leader of a free
+ software project, you need to attract and keep developers in a way
+ that leaders of proprietary software projects sipmly don't have to
+ worry about. <emphasis>As the person leading development of a free
+ software project, you must harness the work of fellow developers by
+ making responsible decisions and by and by choosing not to make
+ decisions responsibly. You have to direct developers without being
+ overbearing or bossy. You need to strive to earn respect and never
+ forget to give it.</emphasis>
+ </para>
+
<!-- Section2: delegation -->
<sect2 id="delegation">
<title>Delegating Work</title>
- <para></para>
- </sect2>
-<!-- Section2: branches -->
+ <para>
+ By now, you've hypothetically followed me through the early
+ writing of a piece of software, the creation of a website and
+ system of documentation and 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>
- <sect2 id="branches">
- <title>Stable and Development Branches</title>
- <para></para>
+ <para>
+ <emphasis>Like the parent of any child who grows up, it's now time
+ to wince and smile and do most difficult thing in any parents
+ life: It's time to let go.</emphasis>
+ </para>
+
+ <para>
+ Delegation is the politcal 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 reponsible
+ 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. <emphasis>A free software project is nothing
+ without the involvement of a group of developers. A group of
+ developers can only be maintained through respectful and
+ responsible leadership and delegation.</emphasis>
+ </para>
+
+ <para>
+ As your project progresses, you will notice people who are putting
+ signfigant amounts of time and effort into your project. These
+ will be the people submitting the most patches, posting most on
+ the mailing lists, engaging in long email discussions. It is your
+ responsiblity to contact these people and to try and shift some of
+ the power and responsiblity of your position as the project's
+ maintainer onto them (if they want it). There are several easy
+ weays you can do this:
+ </para>
+
+ <sect3>
+ <title>How to delegate</title>
+
+ <para>
+ Like anything, its easier to see how others delegate than to do
+ it yourself. In a sentance: <emphasis>Keep an eye out for other
+ qualified developers who show an interest and sustained
+ involvement with your project and try and shift responsibility
+ towards them.</emphasis> The following ideas might be good places
+ to start or good sources of inspiriation:
+ </para>
+
+ <sect4>
+ <title>Allow a larger group of people write access to your CVS
+ reponsitory and make real efforts towards 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 certain
+ aspects of the projects. All these developers can upload into
+ the main ftp servers, and vote on major issues. Direction for
+ the project is determined by the project <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) and a technical
+ committee and a project lead. There is a project lead as well
+ but the lead's main responsiblity 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 who lead who can do
+ <emphasis>nothing</emphasis> but delegate can serve as a
+ charicature of how a project can involve and empower a huge
+ number of developers and grow to a huge size.
+ </para>
+
+ </sect4>
+
+ <sect4>
+ <title>Publicly appoint someone as the release manager for a
+ specific release.</title>
+
+ <para>
+ A relase manager is usually responsible for coordinating
+ testing, encforcing a code freeze, being responsible for
+ stability and quality control, packaging up the software, and
+ placing it in the approrpriate 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 to somenoe 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 a break.
+ </para>
+ </sect4>
+
+ <sect4>
+ <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, had total control over the stable releases to a
+ well-suiteded 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: freezing -->
+<!-- Section2: patching -->
- <sect2 id="freezing">
- <title>Freezing</title>
+ <sect2 id="patching">
+ <title>Accepting and Rejecting Patches</title>
<para></para>
</sect2>
-<!-- Section2: codecram -->
- <sect2 id="codecram">
- <title>Avoiding the Code Cram Effect</title>
+<!-- Section2: branches -->
+
+ <sect2 id="branches">
+ <title>Stable and Development Branches</title>
<para></para>
</sect2>
-<!-- Section2: patching -->
+<!-- Section2: otherdev -->
- <sect2 id="patching">
- <title>Accepting and Rejecting Patches</title>
+ <sect2 id="otherdev">
+ <title>Other Development issues</title>
<para></para>
</sect2>
+
+
</sect1>
<!-- Section1: users -->
projects / fspm_howto / blobdiff