On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu <c...@qos.ch> 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.
Yup. 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 :) Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
