What does it take to run a successful open-source project? Does leadership go to the best developer? To the smartest geek in the room? In other words, to everyone but me?
No, no, and yes, it turns out, as academic researchers Siobhán O'Mahony and Fabrizio Ferraro recently published in the Academy of Management Journal Just as in off-line, non-developer communities, leadership within open-source communities falls on the shoulders of those who exercise it. Namely, those who care about a project as a community and nurture it, rather than those who simply write th best code within that community.
It is commonly believed that open source communities operate in a meritocratic manner: positions of authority are allocated according to merit. However, it is not clear whether merit in these communities means technical contributions or organization building. One developer, commenting on Debian's 2001 election for leadership, noted, "I have seen a lot of developers go from nobodies to being absolutely huge on the project." So, does a great code guarantee a great leadership position?
The answer is no. The researchers find that the sheer amount of a person's technical contribution does not necessarily guarantee a position for him or her on the leadership team as project leader, project secretary, or developer account manager. Despite espoused preferences for "hands-off leaders," skill in building the organization becomes increasingly important over time. Contrary to a simplistic meritocratic explanation, developers who try to build the organization are more likely to become its leaders. In the Debian community, the informal work of coordinating individual efforts and linking them to community goals plays a vital leadership role, especially as the project matures.
This is consistent with Eric Raymond's views on Linus Torvalds. He's a great developer, but his real genius is in managing development. There's a big difference.
All of which may mean that if you're a commercial or community open-source project, your best project lead may well not be your best developer. In fact, depending on how prickly the personality, you may be better off with someone that gets along well with others but is a less than god-like developer.
in other words, a jerk is a jerk, even if he/she writes great code. You may want them on the project, but you don't want them running it (into the ground).