Leadership in most organizations is top-down. The CEO tells the VP, who tells the director, who tells the manager, who instructs his employee to do work. Culturally most people are conditioned to think that's expected. But open source communities rarely work that way, and that's one of the oddities people discover upon getting involved in open source--and often they need a period of acclimation to get used to it. It’s also certainly one of the strengths of open source communities, as well as one of the least understood functions, even among those in communities of practice.
While there is the traditional hierarchical approach to leadership at one extreme, there's also the other extreme, which is popularly referred to as crowdsourcing. Many people confuse open source and crowdsourcing—to be clear, open source doesn’t mean just taking input from anyone within earshot. While collective wisdom from everyone isn't necessarily bad, it often tends to encourage pie-in-the-sky thinking and lots of wishes for ponies and unicorns. (For more on this, read Chris Grams’ “Why the open source way trumps the crowdsourcing way.”)
So how are open source communities led? Largely by the people doing the work. Most groups have a loosely defined common goal (build software widgets, or develop a awesome, open source, computer-based fourth grade math curriculum), and decisions are made by the people doing the work. There's no manager in place dictating edicts about how things must be done or what objectives to seek after. Many people object to this method, call it anarchy, and claim that it impedes progress. It's true that if the same set of people was coerced into a single direction, they might make more progress, but there likely wouldn't be the same level of innovation.
That freedom on the part of people doing the work to change direction a bit (or a lot) is incredibly powerful, and while those changes may not always be better (a matter for interpretation), they are far more innovative. People, especially volunteers, also tend to be happier about participating, which means they contribute more and are more engaged.
Then what is leadership in open source communities? It's accountability. It's shouldering the responsibility for making sure work gets done. Largely that means making sure that those who want to do work can do it—that there are no roadblocks for those doing the work. It may also mean doing the work yourself if no one else steps up. Sadly, many people don't realize this and work towards attaining “leadership roles” in order to set forth grand visions to be handed down to the people doing the work—the hierarchical model. This almost always fails in a community. In the relatively short history of open source software, the timeline is rife with examples that resulted in forks or abandonment, and the most common outcome, for those people to be ignored or considered irrelevant.
In short, if there's a change you want made, and you aren't participating in making it happen, then you aren't doing it the open source way.
1 Comment