Welcome!

Open Source Authors: Liz McMillan, Maureen O'Gara, Jeremy Geelan, Reuven Cohen, Lavenya Dilip

Related Topics: Open Source

Open Source: Article

Exploring Governance in the World of Open Source

What we can learn from Wikipedia

How Do You Herd Cats?
Fortunately, collaborative governance isn't quite as bad as herding felines. For one thing, most every collaborative effort will share several traits, including not just governance issues but personnel types as well. When it comes to landing on the pro or con side of the governance line, you'll find two basic types: the Don't Cares who bear no further mention and the Zealots who won't hear of governance.

Open zealots tend to believe "open" will solve all problems. Open is a magic bullet. There are few ways to deal with this kind of thinking, except to present the evidence with care and patience. That evidence shows that many efforts really start with a benevolent dictator. This is Jimmy Wales in Wikipedia, Linus Torvalds in Linux, and many more. Such projects may appear to have less governance once they scale and decision making is passed onto "the masses," but to get them off the ground, a single determined voice is usually required. The perception that establishing an "open environment" does not require leadership, and perhaps even dictatorial leadership, is simply not supported.

Skeptics are the flip side of that coin and see nothing but problems with the open collaborative approach.This seems intuitive - the more complex the problem, the more up-front planning is required. But many an open source zealot would say that this premise has largely been disproved by the development of Linux. An operating system seems sufficiently complex to make the case. Linus Torvold's "Many eyeballs tame complexity" is their mantra.

If you need to address the concerns of a zealot, just remember that these are not just any eyes, they are well-informed eyes. They're eyes just as the skeptics eyes have access to all the information they need to participate intelligently in any community governance decision. These aren't uninformed users; these are eyes that both understand and have access to the source code. Central governance is obviously a requirement, but taming a skeptic means providing an alternative to the iron-fisted project manager-style governance that skeptics typically favor.

An examination of the governance of Wikipedia, the Apache Foundation, and other open source communities shows that projects that are open start as a small tightly controlled project that establishes norms, then as it scales it evolves mechanisms to sustain governance - like steering committees. The rules of these committees are not always apparent because they were established during the embryonic stages. Hence, there is always a core steering committee construct that makes scalable unilateral decisions and conducts some amount of its business "behind closed doors." Initially, the benevolent dictator and his small community are even more closed.

The perception appears to be correct: you can't leave every decision to the masses. What is incorrect is the assumption that complete openness is a requirement for success - making fear of complete openness an argument for not adopting any openness. Admittedly, there are purists (zealots) who say that nothing should be hidden, but there is little evidence to support that this leads to successful collaboration and self-organization.

Balance, Therein Lies the Rub
Fortunately, finding a proper balance between the skeptics and zealots in your project isn't completely a black art. There are common even universal principles involved. A thorough example is Elinor Ostrom's work on "Governing the Commons." This paper set out to find the middle ground between government regulations (authority) as well as privatization (no commons at all) and the negative effects of entirely unmanaged selfish inclinations ("open" inclination). Based on self-management, she crystallized principles based on common pool resources such as fisheries, grazing lands, and water supplies, which included:

  • Clearly defined boundaries
  • Rules for resource use to suit local conditions
  • Participation in collective decisions
  • Monitoring
  • Graduated sanctions
  • Conflict resolution mechanisms
  • Government recognizes users rights to organize

Ostrom's perspective is that "...the evolution of social norms within a community is a more effective means of accomplishing cooperation than the imposition of external rules." That's a lot harder than promulgating policy. The good news is, if you look across "self-organizing communities" characterized by Wikipedia, The Apache Foundation, and the broader open source movement, they do seem to adhere to these principles, many of which go back to the Magna Carta. (This may introduce some controversy because the Magna Carta begins to limit the authority of the king by making the king subject to law - was the king being required to "eat his own dog food"?) We are now blending sociology, political science, and computer science, so let's address each in turn (a Grand Unified Theory - not just for physics anymore).

Clearly defined boundaries are necessary because people are animals and animals are territorial.

Consider that a corporate silo or a programmer's area of technical expertise is much like a person or a group's territory. People create them because that's what animals do. Yet, there is a constant fight against the "corporate silo" (just try Googling the topic), so the damage that occurs here is well known to all. And it seems like eliminating them is a losing battle.

Adhering to the principle of specifying rules to suit local conditions shows its value when you look at the damage governance from "on high" can do when issued with the ignorance of local practices. Technology has its own examples. For instance, since the 1980s the "PC software culture" suggested that you include a readme file with your distribution. Everyone knows what to do with the readme. The readme is instructive when considering "social norms" because the practice evolved as a very common-sense solution to a common problem. There is no law or policy that says if you create a software distribution for a PC it should include a readme; it's just what people do.

Let the folks who have to do it, manage it. It's a bit of a stretch but here's a different statement of that policy: "The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States, respectively, or to the people" (Article X [the tenth amendment] to The Constitution of the United States). Let the people who know conditions and enforce the rules control what they are. This is the only way to scale up (and if you are at the top you might get to play some golf occasionally).

More Stories By James Irwin

James Irwin is an open source software architect at Unisys Corporation. He has degrees and work experience in both the computer science and psychology fields.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.