Back in April Henri Yandell wrote an interesting post about the ASF's community mantra titled "How we lie to ourselves". In that post he contrasted "despot" driven projects and community driven projects, and he used Codehaus as an example of an organization that focuses on despot driven projects. Of course, he could have equally well used Linux, Python, or any of a number of fine open source projects as his example.

The term "despot" (or to use the Python community's label, "Benevolent Dictator For Life") inserts a lot of unhelpful color into this particular discussion. It is very rare to find a human endeavor in which no one displays that quality known as leadership. Sometimes it takes on the form of articulating a vision. Other times it takes the form of doing whatever needs to be done. In other settings it means stepping in to cool a raging discussion between project participants. There are various kinds of leadership, and all of them are necessary in a project of any size. As Henri points out, even ASF projects contain people who act like leaders - title or not.

I like to think of the two viewpoints this way: If you want to look at leadership as giving someone authority, then there are two kinds of authority. There's positional authority. That's where you give someone a title and then people follow the instructions of the person with the title. But there's another kind of authority, which is much more powerful (at least I think so). Call this relational authority, the authority that stems from the relationship that you have with another person. We all have (I hope) people that we trust enough that we let them "tell us what to do". We've given those people a place of "authority" in some sphere of our lives. In the "despotic" projects that I've observed up close, in every single one of them, the despot had gained significant relational authority, in addition to whatever their supposed title conferred.

A few more thoughts from "The Success of Open Source":

On the nature of open source leadership:

While leaders of other large projects have different personality traits, they do tend to share an attitude that underemphasizes their own individual importance in the process. And they share, more importantly, a commitment to invest meaningful effort over time in justifying decisions, documenting the reasons for design choices and code changes in the language of technical rationality that is the currency for this community

Because anyone can join and leave at any time, the leader is in a sense more dependent on followers than the other way around. The core question then becomes, How can a leader fail his followers? The simple answer, which captures the unusual power dynamic, is "lack of responsiveness to those led."

On the nature of the core freedom of open source (which is actually a freedom of community as opposed to property):

Albert Hirschman's classic argument from Exit, Voice, and Loyalty is a useful metaphor here. While the open source process certainly encourages the use of voice, open source licenses are design explicitly to empower exit rather than loyalty as the alternative when voice fails. The core freedom in free software is precisely and explicitly the right to fork.

In other words, positional authority without relational authority is moot, and the community is always free to vote with its feet.