commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Date Wed, 10 Aug 2011 06:02:49 GMT
On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu <> wrote:

> * On the ASF model
> In a nutshell, while the ASF is a great organization in many ways, it
> is not a meritocracy mainly because merit is not measured at all and
> at the project level no responsiblity is accrued on merit beyond
> committership. BTW, the BDFL model is not a meritocracy
> either. Finding a good model for running organisations is no simple
> matter. The Apache model may even be better than some but it bothers
> me that the ASF misrepresents itself as a meritocracy.


Damn... should probably say more.

It tries to be meritocratic for adding committers. It's damn hard to
track how much someone is contributing sometimes. I wrote a JIRA
Contributions report that I like a lot - with each release I look and
see who was involved in the release and whether anyone who is a
non-committer stands out as having  done a chunk.

Beyond that it's mostly peer/respect driven. Getting to be a member is
based on respect of peers; leading to new groups having low members
while the culture overlaps with the new group.

Discussions are still meritocratic, in that they favour those prepared
to do the work, but that's only at the meme level and not in any of
the actual methods; meaning you have to be pretty obstinate to push
past that inactive committer -1. The loose meme is that inactive
should only be casting -0 and +0.

Getting your way (per se) in discussions is also peer/respect driven;
meaning you have to expend energy on convincing others rather than
coding. An annoying drag on your time to code. There are culture memes
that can lessen that, but they're not well communicated.

Rules for Revolutionaries is definitely the best, though I rarely seem
to see it actually documented for a project. We don't have a rule for
revolutionary change for example. I spent lots of time trying to
convince people that we should do a JDK 1.5 Lang; then realized I
should just start on a branch (or trunk; I forget which).

So here's our Commons Rules for Revolutionaries:

  * Give heads up. Make a branch and JFDI. Then discuss.
  ** Subnote. If not a Commons committer; then discuss making a
sandbox branch, make a branch and JFDI.
  *** Subsubnote. If not an Apache committer; make a github fork or
svn copy, JFDI and discuss.

Maybe that will help someone in the future :) I always wonder if that
would have helped in log4j.

End of ramble :)

It does worry me, the balance between innovation and stability (rules
for revs), and the interaction of lots of skilled people. On the
latter the meme is "Go to ApacheCon". Meet someone face to face and
much of the irritation that can build up fades away.

Looking forward to meeting many of you at ApacheCon Vancouver :)


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

View raw message