Brian "Krow" Aker's Idle Thoughts - Three Commits, Ding, Ding, Ding

I dislike old boy's club. Not the part where you sit around in gab, but the part where people have to wait at the door to get in.

Something about them rubs me a bit raw.

Open Source has this problem in spades. The bar to commit to the major projects is not problematic in that it is high, it is a problem because it is not written down. It is often fuzzy, or worse personality dependent (so much for the meritocracy that is espoused).

Here is a story for you...

A few weeks ago I went to the Velocity Summit O'Reilly held in San Francisco (not to be confused with the Velocity Conference which I still owe an abstract to Jesse for), and I talked about my current topics, as always MySQL, and as of recent libmemcached.

Somewhere during on of the sessions we got off on a tangent about distributed source control (another favorite topic of mine), and how it made vendor versions simpler to deal with. Which is another way of saying that it encourages forks (not the kind you put in your eye).

Hallelujah!

I'm all for forks. They are a sign of health. They are not really much of a motivator for old boy's clubs though. The group I was with talked about that for a few moments. What was my surprise? The number of other people in the room that were hostile to the old boy's clubs. It was a common annoyance in the room.

Despite the ongoing fear of forks, open source projects remain very stuck in the proprietary world of software when it comes to contributions. Few are good at this, and most become an old boy's club of some sort. It is too much effort to create casual fixes for the average user. Which means it is impossible for the most part to make significant changes.

The Hanging fruit of features are left hanging until they either rot or... well they just keeping hanging around.

When I started working on libmemcached I decided to adopt a new strategy.

In the README I put "three good patches get you commit access". The fabled "you must be at least this...", was put into words. Any three patches and its yours.

So today some three months later? Five committers, and one person who is just one patch away. Most effort is still coming from me, but it is not all of the effort. The best bug fixers are coming in from a user (user's code better then straight developers, it is the nature of need). Documentation has all been strengthened from users.

To me five people is a success. It proved the point to me that it was better to grant access, then act as a gatekeeper for others.

It is a success that has shown off a few new problems.

Release. Just because you can commit, does not mean you can release. This is a problem, since it creates a bottleneck.

Regression. We need better regression testing, and by better I mean more. The current candy in my eye is the "BuildBot" project. I like the concept, but I want to see something more. I want all open source projects being filtered into a network where users can run slaves that do regression testing for them.

Coding Guidelines I've never written down what exactly my coding style is. It is hard for others to follow what they do not know.

The last one is solvable, the other two I am trying to think up solutions for. I've pinged several people in large organizations to plant the seed for what I want to see happen with mass regression. It will take a few more months to see if anyone bites on it.

Release might be solvable alongside regression. For years I've said that internally in MySQL we needed to just generate binaries with each push. Each push is either green or not, and green ones should be acceptable for a release (and if they are not... well then there is a problem with the regression system).

Any open source projects should be able to do this (I'm amazed at how many pulls I see coming off my Mercurial trees, where users now just grab the tip of the tree). The problem with pulling directly from mercurial is that there is no way to know if the build you just pulled is good or not. There are no green lights, and to me this creates a barrier. Solving feedback on regressions to commits would make this go away.

Another thought on this topic.

Three commits might be too many. It is easy to roll back changes in a source control system. Perhaps take a queue from other groups? The folks at wikipedia have figured out a good formula for an on-line encyclopedia.

Maybe, just maybe, revision control should be open access. There is a fear of trojans, but would it be possible for an open project to monitor itself? Wikipedia does a good job of rolling back malicious changes, could a similar gatekeeping system work for source code?

How about a code reviewing captcha?

I am left with the thought that open source is still more about source, and not so much about being "open".

If Open Source wants to really move beyond the proprietary model, it needs to give some thoughts on how to open up the model.