I came across this very thought provoking blog post by Brain Aker of MySQL and /. fame. I think he raises some very important points about OSS development and how to create a successful new project. However some of the advice can also be applied retroactively to existing projects. I especially find his comments regarding "old boys clubs" important. Sometimes when you have a successful project it becomes hard to manage the influx of new people. So the old boys start to feel most comfy when they ignore the new guys. Patches are a good basis (though you still need people to have a look at the patches) of judgement to let new guys in. After all with good patches the project should be moving forward. I think in PHP we have a very similar policy to the "Three Commits, Ding, Ding, Ding" policy Brain applies. And that is a good thing.
A bit more on the "old boys club" stuff though. The long time contributors usually get some slack here and there. For example a long time contributor might get away with filing a bug report that lacks detail, because you trust that the bug is real and not just an end user errror. And thats all fine and dandy. Also we are all people and if we spend a lot of our spare time on something, it should be a bit comfy to hang around at.
It gets tricky though if a long time contributor tries to put his old boys club status weight behind an argument in a technical discussion. Yes, the old boys know the history of the project, while the new guy doesn't. So the new guy might still think that something like "magic quotes gpc" is something that could help people, while the old boys know that stuff like this only comes back to bite you. At the same time the new guy might be thinking out of the box and the old guys just lack imagination and therefore think of the proposal in terms of futile past attempt.
The key thing is that the old boys keep double checking if they are open minded. That they double checking if they are abusing their old boys credit and if they are giving new guys a chance or not. In the end, solid technical arguments should always win out against old boys club credit.
Yes, absolutely. Thanks for the reminder. 8)
You might want to proof-read the post (especially the first paragraph). :)
Good point .. sorry about that. Guess I should take a bit more time when I write a blog post. Was kind of hard to interpolate what I was trying to say even for me :)
And of course this means making sure *we* don't become the old boys.
The way I do this is to automatically assume that someone who gives an idea might have some knowledge that I don't. Therefore, a statement like "MySQL isn't a mature database!" is obviously bunk because there's no knowledge in the world that can make someone come to that conclusion; it's already a mature database.
However, a statement like "DRBD is best for high availability" makes me ask questions like "high availability as in having an easy hot failover, or as in having the system not go down when there are tons of writes?" because in the latter situation, master<->master replication is better. But maybe, just maybe, there's something I don't know, like a new version of DRBD that works more like row-based replication, and where you can have a live MySQL server.
