There are a lot of creative ways to manage collective decision making. The Apache Foundation has very creative decision making that extends beyond the Boolean yes/no pick list. When only coordination is required, lazy consensus (few positive votes with no negative "veto" vote) is enough to get going. (If enough are willing and no one objects, let's proceed.) When a decision is required, participants vote with numbers (+1, 0, and -1). This is still the familiar Boolean (yes/no) vote if you allow people to abstain. However, there are some modifications. First, a negative vote requires an alternative proposal or detailed explanation for the negative vote. Effectively, it's more work to disagree than agree. Pretty clever, really. (This sort of makes the assumption that people's ideas tend to be good ones. Conversely, a social norm protects contributors from making half-baked proposals because no one wants to have their time wasted developing objections or alternative proposals.) Consensus gathering is the process of considering alternative proposals that address any objections.

We also need to address the sticky issue of "who gets to vote?" A common theme across open communities is whoever does the work. The Apache Foundation refers to this as a "do-ocracy" or "meritocracy." Eric Raymond, open source spokesman, guru, and author of the New Hacker's Dictionary, provides some perspective of the open source community when he refers to it as seniority - but this is not how many years you worked for the company; seniority refers to the longevity and effort put into the project on which you are voting.

In a way, principles discussed bear on Ostrom's number 6, the conflict resolution mechanism. We have seen ways to reduce conflict through defining governance limits, reduction through social norms respected by community members, and simplistic conflict resolution mechanisms such as a mandate from a benevolent dictator. But sooner or later, there comes a point where preventative and simple mechanisms just don't work and the conflict is protracted. Ostrom's principle is simply that there must be conflict mechanisms. While this seems obvious, there are some subtle aspects to this principle in practice worth considering.

For one, any conflict resolution mechanism must be accessible to anyone in the community. They also need to be effective, which again sounds obvious but the need is plain when you look at one of Ostrom's examples: a water-sharing system. Here, she observed that "...conflict-resolution mechanisms often exist only in the form of documents, regulations, etc., and are not implemented in everyday interactions. Consequently, in practice they are either neglected or simply do not work." It would be fair to say if the mechanisms are not effective, they really do not exist.

Any resolution mechanism must take into consideration the type of conflict they represent - typically boundary conflicts, use conflict, or a combination of the two. Last, resolution mechanisms must take into consideration the type of resource over which the conflict occurs.

Ostrom's last principle, that government recognize users' rights to organize, requires adding the implied "self" - users rights to self-organize. This seems obvious in any commons effort that "grew up" based on open principles, but may not seem so obvious to an established corporate environment. It may require more examination for organizations that have established "closed" communities and all the social norms that surround it.

Conclusion
What can we conclude from these observations? For one, that the challenges of governing in an open way are hardly new to the technology sector. In addition, it takes a patient and through approach when looking into the governance of concrete resources for principles that apply to virtual resources. Execution extends to factors beyond written policy such as establishing social norms, markets and incentives, and the technology and tools behind the processes. Clearly there are patterns that offer us the opportunity to extract the best of the community-based initiatives and apply them within our organization to inject energy, engage the brightest, and improve efficiency by maximizing creative involvement.

References

• Wikipedia Entry for "Governance"
• Raymond, Eric S. (1999, 2001) The Cathedral & The Bazaar.  O'Reilly Media.
• Apache Foundation How It Works
• Scaling Consensus: Increasing Decentralization in Wikipedia Governance
• Thinking Outside the Domain: Revisiting the Function of Identity Information Across Digital Communities.
• http://rspas.anu.edu.au/papers/melanesia/discussion_papers/larmour96_1.htm
• Ostrom, E. (1990). Governing the Commons: the evolution of institutions for collective action. Cambridge University Press, Cambridge.
• Silverthorne, Sean. HBS Cases: How Wikipedia Works (or Doesn't)
• http://weblog.infoworld.com/realworldsoa/archives/2006/08/observation_you.html
• Interstate River Compacts, Collaboration, and Water Conflicts:
• Conflict-Resolution Mechanisms in Uzbek Water Users' Associations: One of the Important Institutional Criteria