incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <>
Subject Re: an experiment
Date Tue, 17 Aug 2010 06:16:00 GMT
 On 08/16/2010 09:32 PM, Justin Erenkrantz wrote:
> On Mon, Aug 16, 2010 at 6:26 PM, Ross Gardler <> wrote:
>> I've already decided that I'm going to have to recruit a number of key
>> mentors to help me protect the project during incubation.
> Historically, I think there are two classes of podlings:
>  - one which has a self-governing community and just needs to get
> indoctrinated in the "Apache Way" (SpamAssassin, Subversion, etc.)
>  - one which doesn't have a self-governing community (thrift, traffic
> server, etc.)
> Perhaps Greg is on to something with having us split up the process.
> It's always bugged me that there were two different classes that we
> tried to shoehorn into one process.
> Accordingly, in these two models, the role of the mentor is very different:
>  - self-governing community: making sure they get introduced to the
> right people and understand the minimum requirements; but, really,
> they shouldn't interfere with the actual day-to-day governance.
>  - no self-governing community: helping the developers understand what
> it means to self-govern.

As a non-member, with cursory interaction with Apache over a very long
term (some very small contributions to some projects), and a very recent
interest in getting a project into incubation at Apache, this problem
looks very different to me.

Supposition: Involvement in projects will always follow a power-law for
# of interested parties.  Even within Apache, some projects will
dominate with a large number of interested parties, and the rest will
eventually taper off into a "long-tail."

Supposition: Due to potential "bit-rot", Apache wants to make sure that
projects have an ongoing commitment over time.  Otherwise, projects will
start out, gather some interest, and then people will drift off an do
something else.  Unchanged left-over code will "bit-rot" - as the
language/compilers and supporting libraries for the code in question
change, the code that works on top of those libraries/languages needs to
stay current.  Security problems might crop up in the most obscure
places, and need to be addressed by an active community.

Consequence: Apache wants to make sure that projects sustain a
commitment over time.  Incubation is the proxy for judging this question
- if a project makes it through incubation, presumably it will sustain
itself.  The proxies are indirect data points, like three independent
committers, filing reports on time, voting out a release, nailing down
licensing issues.

This brings me to Justin's analysis.  The distinction that Justin makes
above doesn't seem quite right to me.  To me, it isn't a question of
"self-governing" - Apache should be able to clearly lay out a process,
deadlines & guidelines - and sure as heck, people who write down rules
for how a computer works ought to be able to follow rules/processes for
people.  If they cannot, they don't belong at Apache, as they cannot
self-manage.  Lay out the rules, however odd they might be, and as long
as they're clearly communicated, and there are people who are familiar
with the rules to guide newbies along, you'll get people who can

For the projects that fall on the high end of the power-law spectrum,
following the rules isn't a problem.  And I suspect, actually, it isn't
really for projects on the low-end of the spectrum - except that they're
simply unfamiliar just like everyone else, and might need more
training/attention/mentoring, because they're less likely to have the
experts from Apache already deeply involved.  Putting my former
management hat on, (and oversimplifying dramatically) this seems like a
training/education problem, and you solve it with a bunch of techniques
- training sessions, "quizzes", materials that everyone is expected to
master, presentations/interactions at conferences, etc.  This probably
isn't all that theoretically hard, it just needs a little bit of
constant attention, and needs to be applied to all newcomers.  What
makes it practically difficult is that it isn't interesting to people
who want to right code, and it is actually hard to do well, as the best
materials take the viewpoint of a newcomer.

I see a particular problem screaming out of the incubation reports for
many of projects in incubation (and the problem we're having with our
proposal). How to attract and sustain attention from people already
involved with Apache, and attracting committers from everywhere?  As I
see it, this almost by definition falls out of the "power-law" curve I
mentioned above.  There will be some percentage of projects (1/2,
1/3rd?) that struggle to meet the criteria laid out.  Self-governing
*shouldn't* be a problem, because people should be told up front -
"understand these materials, then see if you really want to join the
party."  What will naturally be a problem, though is that the bottom
half or bottom third of the incubating projects need to attract and
sustain attention.  Seems like developing and sustaining that attention
really should be the role of the incubator - training on the rules ought
to be an incidental piece.

Anyway, coming back to Justin's division, I see three or four chunks
instead of his two:
- high visibility projects.  Really no doubt that they have commitment
over time.  Just need training on rules.  Switch from incubation to full
project should involve as few rule changes as possible, so as to
minimize retraining.
- near-high projects - like high-visibility projects, but run the risk
of having "spoilers" that can sap the community, and other things that
can derail the involvement.  How do you protect against that?
- middling projects - can get lost in mechanics - like simply delivering
a release.  Can be killed by a small amount of community-sapping
behavior.  Need prodding from the community to release early, release
often, and sustain high standards.  Need some help gathering interest,
and need to fend off community sappers.
- low visibility projects - like middling projects, but need lots of
help with gathering interest.  Need prodding to spend less time coding,
and more time community building - reaching out to other Apache
projects, contacting and engaging with similar open-source projects not
at Apache, perhaps working with people in academia, blogging, etc.

My point - a one-size fits all approach is effectively doomed to cause
some unnecessary failures.  That doesn't mean that you cannot have one
set of rules for what must be done, but it does mean that how those
rules are applied is effectively different.  Put differently, does the
incubator aim to help projects succeed at Apache once accepted into
incubation, or does the incubator simply let chips fall where they may,
and let interesting projects die?

Maybe I'm just a naive newbie to look at it this way, but I thought I'd
throw out my $0.02.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message