Subject: Re: endemic problem?
From: "Stephen J. Turnbull" <>
Date: Fri, 09 Aug 2002 13:26:22 +0900

>>>>> "scott" == scott capdevielle <> writes:

    scott> I still don't understand what a meta maintainer is?  What
    scott> do you do with the bite size chunks once you've picked them
    scott> out?

Sorry, I'm still a little jet-lagged.  Overcompensating for my usual
excessive verbosity.  :-)  Back to form:

A maintainer is a person who works on the software, and has to have a
good general overview of how everything works---he may have to fix it
some day.  The meta-maintainer is a person who works on the
organization, and has to have a good idea of how everything and all
the people fit together, but not necessarily how it works.  Usually
s/he also does recruiting for the project.

The idea is to pass off the bite-size chunks to other people (non core
developers) to actually work on.  It fits really well with academic/
dilettante personalities (like mine), who want to know a little about
everything.  Plus networking inclinations---knowing which inactive
developer might be able to answer a question but has no time to write
code, etc.

The problem that it addresses is that TODO files rarely include LOC or
programmer-hour estimates, even when they exist.  Many reasonably
capable programmers need little more than "read these two sources
files (the upstream and downstream modules), total 1500 LOC, and fix
it somewhere in this module, 350 LOC", and they're ready to go---but
if you have something like XEmacs (3.5 million lines of code according
to wc(1)), where do you start?[1]  The meta-maintainer knows.  "Code
ROADMAP" files, again, rarely fit the bill.

Of course usually the maintainer does the meta-maintenance stuff, but
it can be made into a full-time job by itself if you have a bunch of
willing part-timers who need a bit of direction.  It also makes more
work for the core developers, because you must have a review process.

There's one other problem from Tom's point of view, I suspect.  And
that is that he would like to arrange for the part-timers to share any
revenues "in proportion to contribution".  I don't see how to do that,
without giving the meta-maintainer huge scope to assign credit.  This,
of course, could create conflicts if there were significant revenues
involved.  This doesn't seem to bother the thousands of unpaid
volunteers on the Linux kernel or the hundreds who contribute to
Python, though, so it may not be that big a problem.

[1]  Of course the volunteers can figure this out themselves.  But
it's less fun than actually writing code, and typically the knowledge
of where to start exists.

Institute of Policy and Planning Sciences
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