Subject: improving project maintainership
From: Tom Lord <lord@regexps.com>
Date: Thu, 7 Feb 2002 18:09:05 -0800 (PST)


[added a CC:]


       >> Tom:
       >>
       >> But the larger point I wanted to make is that there doesn't need to be
       >> a single authoritative maintainer for each project.  There can be a
       >> GNU maintainer, a Debian maintainer, a SuSe maintainer, a Red Hat
       >> maintainer, etc. 

	 [That was poorly expressed -- a better explanation is given
	  below. -t]
	

       
   > RMS	
   > 
   > Debian and Red Hat can make their own versions of our programs; that
   > is the freedom of free software.  But we want it to be clear, on our
   > server, what version is the official GNU version.  If a Debian version
   > is reachable through our server, we do not want any confusion about
   > which version is the official one.  And we don't want a SuSe version
   > as such to reachable through our server at all.  We do not like
   > SuSe's policies on non-free software.

   > So I see this as a serious potential problem.  Do you have any
   > solution in mind for it?


Yes, I have a solution in mind.  I said "there doesn't have to be a
single authoritative maintainer" but that's not quite the right way to
put it.

Maintainers should be doing the job of keeping coherent the efforts
that go towards producing all the separate versions of a particular
project: their job is to ensure that, in spite of the divergence into
separate distributions, effort is nevertheless shared and, overall,
development remains coherent.  There should be two-layers of
maintainers: one for the shared project, and one for the various
organizations distributing their own versions.  Ideally the shared
project maintainer should be making available to the per-organization
maintainers an organized collection of base revisions and menus of
available patches in various stages of development.  From those base
revisions and menus, the per-organization maintainers should be able
to, in a largely automated way, stitch together their particular
distributions.  The flow goes both ways: the per-organization
maintainers would have the role of contributing to and helping to
maintain the library of base revisions and patch sets.

I think the question of "which is the official version" is a symptom
of a larger problem.

We have a collection of companies and individuals who say that they
work with free software in part because of the benefit of sharing
their efforts with other people working on the same software.  At the
same time, when it comes down to specific projects, the cooperation
isn't happening as effectively as it should.

This is a deep structural problem.  Maintainer-ship of the larger
public projects is resource starved.  Administration of the public
projects is by mechanisms that makes the maintainers a bottleneck for
incorporating contributed changes, making coherent plans, and
coordinating developers.  Semi-private forks, fragmented developer
communities, dominated projects, stalled development of unfunded
enhancements, and a general lack of coherence in planning architectures
and features for sibling projects are the result.

There is another perspective on this circumstance: one that says
"That's basically good.  Decentralized development is winning.  We
shouldn't try to mess with it.  Anarchy rules."  That's far from
entirely wrong -- but anarchy does not equate with resource
starvation, disorganization, and power struggles.  We can implement an
improved shared-project maintainer-ship without forsaking anarchy.

I think the solution starts with beefing up the maintainer-ship of
public projects with more resources and better techniques.

"More resources" means that there should be a greater number of more
senior people being well paid to be full time maintainers for shared
projects.  There should be a self-imposed "tax" on FS-based businesses
for that purpose.

"Better techniques" means that maintainer-ship should be run more with
eye towards keeping all the developers coordinated, in spite of their
divergent goals.  

Some simple techniques would help a lot: more consistency in
config/build/test/install conventions; more consistency in
documentation; a single package system; better management of
inter-package dependencies; clear maintenance of bootstrapping paths
(automating the build path from a minimal cross-compiler to a complete
self-hosting system).  Addressing those simple problems in a
community-wide way would save, for example, distribution vendors a lot
of trouble, hence money, and thus provide a return on their
self-imposed maintainer-ship tax.  (Yes, I know that GNU has its own
conventions in these areas, but they are not widely attended to and
probably not complete enough.)

Some sophisticated-but-achievable techniques would also help:
distributed revision control; IETF-style working groups to plan
cross-cutting architectural issues; inter-organizational tactical
programming drills; processes for code review; processes for
automated, distributed testing; ...  Each of those items is a
multiplier for the contributions of each participant and a big
improvement to the benefits of sharing efforts.

I don't think it's something that GNU can do alone.

-t