Subject: Re: project management (was Re: [lord@regexps.com: ... )
From: "Stephen J. Turnbull" <stephen@xemacs.org>
Date: Fri, 30 Aug 2002 21:17:22 +0900

>>>>> "Norbert" == Norbert Bollow <nb@cisto.com> writes:

    Norbert> Does anyone have a good HOWTO document on managing a Free
    Norbert> Software project in such a way that the project meets
    Norbert> both the needs of the sponsoring Free Software Business,
    Norbert> and also the needs of the Free Software community as a
    Norbert> whole?

I don't know of a document.

I'd suggest that the first thing to do is sit down with the rest of
the executive committee and hammer out what it is that you want to do
for the community.  This is going to vary by person and personality.

Be generous about giving up some of your own pet causes in view of:

Second, pick a very small subset of those things, and decide to be
excellent at them.  Of course synergy with the sponsor's business
interests is useful, but don't limit yourself to that.  Consider VA
Linux and Sourceforge---they originally thought (at least that's what
they said) that it was PR and demonstration of their systems'
capabilities, but it turned into a consulting business, too.  (Maybe
they knew that ahead of time?  But it didn't seem like it.)

Third, spend energy and other real resources on community relations.
Don't assume that "we're an FSB, good community relations are
automatic."  In particular, look for other FSBs/FS Projects you can
cooperate with.  This struck me in an extended visit to BitMover
recently.

Their rationalizing of their license struck me as phony.  Not
insincere, but more that they must be fooling themselves somehow.  But
their hosting of pure open source project repositories, especially
Linux, made me feel better about _them_---though not about their
license!---and it certainly is a contribution to the community even if
it is self-promotion at the same time.

As a side effect, any one FSB working on community relations improves
the image of all of them.

Fourth (and this is my own hobby horse) make sure that it is plain
that contributing to other open source projects on company time is
_encouraged_.  By that I mean that developers should be encouraged to
spend time doing the scutwork of packaging up and contributing work
that they've already done on behalf of their employer, not that they
should be encouraged to moonlight.  (Moonlighting also has the
disadvantage that the contribution tends to be associated with the
developer rather than the organization making the contribution.)

There are all sorts of barriers--- local deadlines, local tree is
variant from upstream, dealing with queries from upstream, foreign
BTS/VC/SCM systems, etc.  I would guess this represents a significant
cost for commercial distros for packages they don't see as part of
their competitive advantage.

Eg, a fair number of bug reports from people who build their XEmacs
from scratch for the first time turn out to be due to downstream
changes by the distro that somehow never get contributed to the
mainstream code base.  Sure, we share responsibility to contact the
relevant maintainers, check the RPM %specs%, etc.  Responsibility is
not the point, this is a valuable _contribution_ that downstream FSBs
can make if they want to.  It is especially useful if other deadlines
can be relaxed a bit for developers making upstream contributions;
this kind of work is so easy to put off forever.

Fifth, contributions in kind (eg, the relaxed deadlines just
mentioned) are _real_ costs.  Budget them, don't just hope your
employees will put in an extra 15 minutes per day.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py