<HTML
><HEAD
><TITLE
>Maintaining a Project: Interacting with Developers</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Free Software Project Management HOWTO"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Starting a Project"
HREF="starting.html"><LINK
REL="NEXT"
TITLE="Maintaining a Project: Interacting with Users"
HREF="users.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Free Software Project Management HOWTO</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="starting.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="users.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="DEVELOPERS">3. Maintaining a Project: Interacting with Developers</H1
><P
> Once you have gotten your project started, you have overcome 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 just as many
opportunities for failure. In the next two sections, I will
describe running a project by discussing how to maintain a
development effort through interactions with developers and with
users.
</P
><P
> In releasing your program, your program becomes free software. This
transition is more than just a larger user base. By releasing your
program as free software, <EM
>your</EM
> software
becomes the <EM
>free software community's</EM
>
software. The direction of your software's development will be
reshaped, redirected, and fully determined by your users and, to a
larger extent, by other developers in the community.
</P
><P
> The major difference between free software development and
propriety software development is the 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 simply don't
have to worry about. <EM
>As the person leading development of
a free software project, you must harness the work of fellow
developers by making responsible decisions and by responsibly
choosing not to make decisions. You have to direct developers
without being overbearing or bossy. You need to strive to earn
respect and never forget to give it out.</EM
>
</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="DELEGATION">3.1. Delegating Work</H2
><P
> 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 <A
HREF="users.html#RELEASING"
>Section 4.3</A
>) 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.
</P
><P
> <EM
>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.</EM
>
</P
><P
> Delegation is the political way of describing this process of
<SPAN
CLASS="QUOTE"
>"letting go."</SPAN
> 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 <EM
>a group</EM
> of
developers. A group of developers can only be maintained through
respectful and responsible leadership and delegation.
</P
><P
> 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:
</P
><P
> 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. <A
HREF="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD"
TARGET="_top"
>Managing
Projects the Open Source Way</A
> argues that <SPAN
CLASS="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)."</SPAN
> 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.
</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN470">3.1.1. How to delegate</H3
><P
> 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.
</P
><P
> Like anything, its easier to watch others delegate than to do it
yourself. In a sentence: <EM
>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.</EM
> The following ideas might be good places
to start or good sources of inspiration:
</P
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="AEN475">3.1.1.1. Allow a larger group of people to have write access to your CVS
repository and make real efforts toward rule by a
committee</H4
><P
> <A
HREF="http://httpd.apache.org/"
TARGET="_top"
>Apache</A
> 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 <A
HREF="http://httpd.apache.org/ABOUT_APACHE.html"
TARGET="_top"
>online.</A
>
</P
><P
> The <A
HREF="http://www.debian.org/"
TARGET="_top"
> Debian Project</A
>
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 <A
HREF="http://www.debian.org/social_contract"
TARGET="_top"
>social
contract</A
> and a <A
HREF="http://www.debian.org/devel/constitution"
TARGET="_top"
>constitution</A
>. 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, <SPAN
CLASS="QUOTE"
>"appoint delegates or delegate decisions to the
Technical Committee."</SPAN
>
</P
><P
> 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
<EM
>nothing</EM
> 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.
</P
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="RELEASEMANAGER">3.1.1.2. Publicly appoint someone as the release manager for a
specific release</H4
><P
> 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.
</P
><P
> 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.
</P
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="DELEGATEBRANCH">3.1.1.3. Delegate control of an entire branch</H4
><P
> If your project chooses to have branches (as described in <A
HREF="developers.html#BRANCHES"
>Section 3.3</A
>), 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.
</P
><P
> The author of Linux, Linus Torvalds, came out and crowned Alan
Cox as <SPAN
CLASS="QUOTE"
>"the man for stable kernels."</SPAN
> 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PATCHING">3.2. Accepting and Rejecting Patches</H2
><P
> 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.
</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN500">3.2.1. Encouraging Good Patching</H3
><P
>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
<I
CLASS="CITETITLE"
>Good Patching Practice</I
> in the
<I
CLASS="CITETITLE"
>Software Release Practices HOWTO</I
><A
HREF="b811.html#ESRHOWTO"
>[ESRHOWTO]</A
>. 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
<EM
>like</EM
> 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 <SPAN
CLASS="QUOTE"
>"right way."</SPAN
>
</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN508">3.2.2. Technical judgment</H3
><P
> In <EM
>Open Source Development with CVS</EM
>, Karl
Fogel makes a convincing argument that the most important things
to keep in mind when rejecting or accepting patches are:
</P
><P
> <P
></P
><UL
><LI
><P
>A firm knowledge of the scope of your program (that's the
<SPAN
CLASS="QUOTE"
>"idea"</SPAN
> I talked about in <A
HREF="starting.html#CHOOSEPROJECT"
>Section 2.1</A
>);</P
></LI
><LI
><P
>The ability to recognize, facilitate, and direct
<SPAN
CLASS="QUOTE"
>"evolution"</SPAN
> of your program so that the program
can grow and change and incorporate functionality that was
originally unforeseen;</P
></LI
><LI
><P
>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.</P
></LI
></UL
>
</P
><P
> These are the criteria that you as a project maintainer should
take into account each time you receive a patch.
</P
><P
> Fogel elaborates on this and states the <SPAN
CLASS="QUOTE"
>"the
questions to ask yourself when considering whether to implement
(or approve) a change are:"</SPAN
>
</P
><P
> <P
></P
><UL
><LI
><P
>Will it benefit a significant percentage of the program's
user community?</P
></LI
><LI
><P
>Does it fit within the program's domain or within a
natural, intuitive extension of that domain?</P
></LI
></UL
>
</P
><P
> 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 <SPAN
CLASS="QUOTE"
>"no,"</SPAN
> 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.
</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN534">3.2.3. Rejecting patches</H3
><P
> 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
<A
HREF="developers.html"
>Section 3</A
> and in <A
HREF="developers.html#DELEGATION"
>Section 3.1</A
>)
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):
</P
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="AEN539">3.2.3.1. Bring it to the community</H4
><P
> 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.
</P
><P
> 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.
</P
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="AEN543">3.2.3.2. Technical issues are not always good justification</H4
><P
> 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.
</P
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="AEN546">3.2.3.3. Common courtesy</H4
><P
> It should go without saying but, <EM
>above all and in all
cases, just be nice.</EM
> 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.
</P
><P
> 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BRANCHES">3.3. Stable and Development Branches</H2
><P
> The idea of stable and development branches has already been
described briefly in <A
HREF="starting.html#CHOOSEVERSIONING"
>Section 2.4</A
> and in
<A
HREF="developers.html#DELEGATEBRANCH"
>Section 3.1.1.3</A
>. 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 <A
HREF="developers.html#PATCHING"
>Section 3.2</A
>) by
allowing you to temporarily compromise the stability of your
project without affecting those users who need that stability.
</P
><P
> 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 <A
HREF="starting.html#CHOOSEVERSIONING"
>Section 2.4</A
>. In this model, there is
<EM
>always</EM
> one branch that is stable and always
one that is in development. Before any new release, the
development branch goes into a <SPAN
CLASS="QUOTE"
>"feature freeze"</SPAN
> as
described in <A
HREF="developers.html#FREEZING"
>Section 3.4.1</A
> 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.
</P
><P
> 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.
</P
><P
> In trying to set up a development tree for yourself, there are
several things that might be useful to keep in mind:
</P
><P
> <P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Minimize the number of branches</DT
><DD
><P
>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.</P
></DD
><DT
>Make sure that all your different branches are explained</DT
><DD
><P
>As I mentioned in the preceding paragraph, different
branches <EM
>will</EM
> 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 <SPAN
CLASS="ACRONYM"
>FTP</SPAN
> or
web directory.</P
><P
> I might also recommend against a mistake that I think Debian
has made. The terms <SPAN
CLASS="QUOTE"
>"unstable,"</SPAN
>
<SPAN
CLASS="QUOTE"
>"testing,"</SPAN
> and <SPAN
CLASS="QUOTE"
>"experimental"</SPAN
> are
vague and difficult to rank in order of stability (or
instability as the case may be). Try explaining to someone
that <SPAN
CLASS="QUOTE"
>"stable"</SPAN
> actually means <SPAN
CLASS="QUOTE"
>"ultra
stable"</SPAN
> and that <SPAN
CLASS="QUOTE"
>"unstable"</SPAN
> doesn't
actually include any unstable software but is really stable
software that is untested as a distribution.
</P
><P
> If you are going to use branches, especially early on, keep in
mind that people are conditioned to understand the terms
<SPAN
CLASS="QUOTE"
>"stable"</SPAN
> and <SPAN
CLASS="QUOTE"
>"development"</SPAN
> and you
probably can't go wrong with this simple and common division of
branches.
</P
></DD
><DT
>Make sure all your branches are always available</DT
><DD
><P
>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 <SPAN
CLASS="ACRONYM"
>FTP</SPAN
> 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
<SPAN
CLASS="QUOTE"
>"stable,"</SPAN
> <SPAN
CLASS="QUOTE"
>"unstable"</SPAN
> and
<SPAN
CLASS="QUOTE"
>"frozen"</SPAN
> 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.</P
></DD
></DL
></DIV
>
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="OTHERDEV">3.4. Other Project Management issues</H2
><P
> 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.
</P
><P
> Other smaller issues that are worth mentioning are:
</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="FREEZING">3.4.1. Freezing</H3
><P
> For those projects that choose to adopt a split development model
(<A
HREF="developers.html#BRANCHES"
>Section 3.3</A
>), freezing is a concept that is worth
becoming familiar with.
</P
><P
> Freezes come in two major forms. A <SPAN
CLASS="QUOTE"
>"feature freeze"</SPAN
>
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
<SPAN
CLASS="QUOTE"
>"one more feature"</SPAN
> 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.
</P
><P
> The second type of freeze is a <SPAN
CLASS="QUOTE"
>"code freeze"</SPAN
> which
is much more like a released piece of software. Once a piece of
software has entered a <SPAN
CLASS="QUOTE"
>"code freeze,"</SPAN
> all changes to
the code are discouraged and only changes that fix known bugs
are permitted. This type of freeze usually follows a
<SPAN
CLASS="QUOTE"
>"feature freeze"</SPAN
> and directly precedes a
release. Most released software is in what could be interpreted
as a sort of high level <SPAN
CLASS="QUOTE"
>"code freeze."</SPAN
>
</P
><P
> Even if you never choose to appoint a release manager (<A
HREF="developers.html#RELEASEMANAGER"
>Section 3.1.1.2</A
>), you will have an easier time
justifying the rejection or postponement of patches (<A
HREF="developers.html#PATCHING"
>Section 3.2</A
>) before a release with a publicly stated
freeze in effect.
</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN613">3.5. Forks</H2
><P
> 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.
</P
><P
> The short version of the fork section is, <EM
>don't do
them.</EM
> 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.
</P
><P
> In his chapter on <SPAN
CLASS="QUOTE"
>"The Open Source Process,"</SPAN
> 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.
</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="starting.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="users.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Starting a Project</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Maintaining a Project: Interacting with Users</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
