From The Art Of Community by O'Reilly (http://www.artofcommunityonline.org) by Jono Bacon
With a firm understanding of the needs and aspiration behind governance, let’s now take a few minutes to look at some of the existing approaches to governance that some communities have taken.
Of course, there are thousands of communities around the world, with varying governance approaches. Fortunately there are patterns in the chaos, and there are three prevalent themes in many communities. These are:
Dictatorial charismatic leadership:
Governance and decision-making that is largely driven and controlled by a single person.
Enlightened dictatorship:
Governance that effectively has no formal leader but in which leadership is determined by reputation in the community.
Delegated governance:
Governance that is delegated to a series of smaller units that all fit together to form a single governing body.
Let’s take a quick spin through these different themes and see how they apply to our own communities. This can then provide us with an idea of how we want to structure our own governance.
Dictatorial Charismatic Leadership
People hate the word dictator. It typically gets something of a bad reputation in polite conversation. Unfortunately, history has taught us that many of the most famous “dictators” were mass-murdering psychopaths who foisted their attitudes onto their people. I am sure that it was for this reason that some of you may have been little surprised to read that there is a type of acceptable governance that is driven by dictators. Fortunately, mass murder is not a common practice in these communities.... Dictator-led communities work just like they say on the tin: they are communities in which a single person calls the shots. This person will often set direction and focus, approve what is acceptable in the community, and in technical communities will be the arbiter of what gets included in the project. If you still can’t stomach the word dictator, substitute charismatic leader in your mind each time I use it.
Now, I know what you are thinking: this doesn’t sound at all very community spirited. A community in which one person acts as the funnel through which everyone else must flow? Surely that can’t actually work! You would be surprised. There are many dictator-led communities that are popular and generate very large communities. Two very prominent technical examples of this include Linux and Python. Within these communities exist two very visible leaders: Linus Torvalds and Guido van Rossum, respectively. Linus and Guido are the people who have traditionally decided on direction, set focus, and accepted or rejected contributions.
In the free software world, one of the most notable cases of dictatorship was the choice of the third version of the GNU General Public License, perhaps the software license in most widespread use by free software projects (including Linux). Years of discussion went into this license, including intense meetings and negotiations with representatives of companies and software projects of all sizes. Yet in the end, someone had to make a decision, and that person was the illustrious president of the Free Software Foundation, Richard Stallman.
Although the dictators in these communities are typically the original founders of the community, this does not mean that they don’t lean on the community for help and assistance in judging contributions to the project. Typically these leaders will handpick trusted and reliable members to lend a hand. In these communities there is often no open governance, no elections, and no community-discussed focus and direction.
Despite these communities’ restrictive nature, time and time again contributors join up and enjoy their involvement. Despite this, however, I would personally recommend against a dictator-led community for a few reasons:
Lack of transparency:
Earlier I went into detail about why openness and transparency are important in volunteer communities. Dictatorial communities are something of an antithesis to this approach, and their leaders always face the risk of not being representative of the views of the wider community.
Bus factor:
Communities that have a single, strongly focused leader face considerable risk if that leader gets hit by a bus. Other, more openly governed communities are often able to transition to other leaders more efficiently.
Direction:
Communities with a single leader who decides what direction the community takes can have difficulty expanding their focus. As an example, if your community is building a website, the leader may stick with outdated ideas of how it should be structured and behave after the rest of the world has moved to new technologies and architectures. There is a very real risk of “it’s my ball and we are playing my game” with this approach. Of course, if you are the founder of your community, only you can decide whether the dictatorial approach is suitable. In almost all scenarios I would recommend against it, and if you are keen to have a strong level of control, at least delegate some control to councils (as we will discuss in the section “Delegated Governance” later on).
Technical communities who have successfully implementated of the dictatorial model often refers to their primary leader as a benevolent dictator. This term is inspired by historical leaders such as Mihailo Obrenović III, Prince of Serbia; Maria Theresa of Austria; and Frederick II of Prussia, who led and governed their people as dictators but applied rationality to their approaches.
In historical terms, this rationality was manifested as religious toleration, freedom of speech and the press, and the right to hold private property. In the technical space, benevolent dictators apply the same sense of rationality to toleration, and freedom of speech and press, but also often inspire open contributions, delegated responsibilities, and more.
Enlightened Dictatorship
In contrast to dictatorship and benevolent dictators, a popular form of community that has grown in both online and offline communities is enlightened dictatorship. With this approach the concept is simple: there is essentially no leader.
Confused? Don’t be.
Not all collaborative communities need leaders; they just need a general ad hoc agreement of what is not acceptable. When your community knows what is “not cool,” it means that all other contributions are, by definition, “cool.” While this may sound like an environment driven by chaos and mismatched focus, many communities have been productive with this approach. Although there is no formal leader, the sense of leadership naturally grows out of reputations that are developed and matured within the community.
At its heart, this is a pure form of meritocracy: when people do great work, they become thought leaders. Although some communities may enable people to climb the ladder based upon meritocracy, in an enlightened dictatorship there simply is no ladder. An interesting example of this approach is the KDE project. Founded by Matthias Ettrich, KDE set out to build an easy-to-use desktop environment, and it has become popular among Linux and other Free Software enthusiasts. One such enthusiast was myself. Back in 2001 I joined the project, attracted not only by its purpose and direction, but also by the apparent openness in the community. To participate back then involved learning a fairly stiff set of programming tools that was commanded by the Aladdin’s Cave of complexity that is the C++ programming language.
My C++ skills were...frankly...pants. I tried my best to learn. I bought books, I read websites, took courses, and even watched tuition videos hosted by a man with a kipper tie. Despite my bumbling attempts at C++, one magical opportunity existed: I knew that if I could gain those skills, I was welcome in that community. Of course, these days a more diverse menu of opportunities is available for those who want to participate in KDE, but even in the dark age of when I was involved, openness was always present.
Although KDE has hundreds of contributors from around the word, there is no formalized leader that exists beyond the limited set of developers who look after the different chunks of code (called modules) and the release manager. It is the many developers involved in KDE who are the arbiters of which bugs get fixed and what features are added. This makes for an interesting dynamic when interacting within the group and how the group is perceived by the outside community. This dynamic has created something of a mantra of “those who code get their way,” a position that some cherish as a pure approach to open source community and some believe makes a community less approachable. Whichever the position you take, the KDE project has made great strides in productivity.
One of the most evident places this mantra is exercised is within the KHTML portion of the project, which produces technology for displaying web pages. As WebKit (an alternative technology originally based on KHTML) has gained traction within the embedded and desktop markets, many people from outside the community have questioned why KHTML is still maintained at all and not been abandoned in favor of WebKit.
Ian Reinhart Geiser, a longtime KDE contributor and member of the KHTML project, explains:
Technical arguments aside, it is the choice of the maintainers of KHTML to keep maintaining their code base and continuing its life. There is no active movement against WebKit and in fact there is a smaller group of developers who are working on a KDE version of WebKit. The will of the KHTML developers is what decides the technical direction of progress in the KDE project.
It is the presence of enlightened dictatorship that Geiser arguably believes has enabled the KHTML developers to push forward with their own approaches that they feel happy with. Although it may not make sense to some, it exemplifies the freedom in this project for raw technical contributions to define direction—a freedom that has helped the project maintain its flexibility and its momentum.
Delegated Governance
Our final approach to governance is the one I find most appropriate, open, transparent, and conducive to robust community. In essence, it puts governance in the hands of an openly nominated and elected group of people who have respected and recognized expertise. There are many powerful examples of this approach to governance in place, and it is one that we have used extensively in the Ubuntu project. We are not alone, though; each of the major Linux distributions takes the same approach, including Debian, Fedora, and OpenSuSE.
In delegated governance, the founders of the project nominate a diverse body of leaders to represent the best interests of the community. This governing body has a mandate and a set of responsibilities, along with a transparent procedure for electing or otherwise replacing members, and these members are typically chosen for their well-respected contributions to the community. Although the approach is very open and transparent, it does have one distinctive risk: complexity.
Building an open yet responsible governance body is not a particularly simple task. You need to know what you want to achieve, how to structure the governance, what the requirements of your members are, and how to ensure that your community is fully supportive of the authority put in the hands of the resulting Community Council.
That can appear complicated to put in place, and can also seem overly complex to your community. As such, we need to work hard not only to craft an effective governance body, but to communicate to the whole community the way governance works and get them on board. Again, we can do this. We just need to pay keen attention to detail and ensure we tick all the right boxes.
THE UGLY B-WORD: STILL UGLY
Here I need to throw out another quick reminder of the importance of avoiding bureaucracy. Always remember that most people view governance as neither cool nor interesting. Our goal is to keep the amount of governance infrastructure and documentation to an absolute minimum while still maintaining the quality and objectivity that we strive for.