I was recently asked to write something about the project that I work on – RDO – and one of the questions that was asked was:
A healthy project has a visible lead(s). Who is the project lead(s) for this project?
This struck me as a strange question because, for the most part, the open source projects that I choose to work on don’t have a project lead, but are, rather, led by community consensus, as well as a healthy dose of “Just Do It”. This is also the case with RDO, where decisions are discussed in public on the mailing list, and on IRC meetings, and those that step up to do the work have more practical influence than those that just talk about it.
Now, this isn’t to say that nobody takes leadership or ownership of the projects. In many senses, everyone does. But, of course, certain people do rise to prominence from time to time, just based on the volume of work that they do, and these people are the de facto leaders for that moment.
There’s a lot of different leadership styles in open source, and a lot of projects do in fact choose to have one technical leader who has the final say on all contributions. That model can work well, and does in many cases. But I think it’s important for a project to ask itself a few questions:
- What do we do when a significant number of the community disagrees with the direction that this leader is taking things?
- What happens when the leader leaves? This can happen for many different reasons, from vacation time, to losing interest in the project, to death.
- What do we do when the project grows in scope to the point that a single leader can no longer be an expert on everything?
A strong leader who cares about their project and community will be able to delegate, and designate replacements, to address these concerns. A leader who is more concerned with power or ego than with the needs of their community is likely to fail on one or more of these tests.
But, I find that I greatly prefer projects where project governance is of the people, by the people, and for the people.