The open-by-rule governance benchmark

Open Meritocratic Oligarchy

First, who is in charge? As I've considered this issue over many years, it's become more and more apparent that the most effective answer to this is "an open, meritocratic oligarchy." That's a mouthful, but it summarises the governance strategy of the most effective communities, including the Apache Software Foundation and the GNOME Foundation among many others.

• Oligarchy refers to governance by an elite rather than by the majority - good governance is not a democracy with one vote on every issue for every participant.
• That elite is however not a closed, self-perpetuating group, nor does it rule forever. Instead the group is open - to change, to challenge, through transparency and by election.
• The form the openness takes is a meritocracy, where the new leaders are those who in the eyes of the community are seen as most deserving to lead by virtue of their contributions and not their affiliations or glorious past. You can tell if the meritocracy is working - the leadership will have representatives of most or all of the key kinds of participants.

There are other approaches, such as the benign dictator, but that's a risky path to tread for new governance and I'd never recommend it.

Good Rules

That's all very well, but what about the community rules - are they all community-equal, with no special cases? There are so many areas that a community will make rules, including rules of behaviour (look for anti-bullying and gender-equality rules especially), but for me the rules diagnostic of a genuine intent to create a community of equal opportunity for all include:

Modern License

The project will have a modern, OSI-approved license that delivers patent protection from everyone to everyone (Apache, Mozilla/CDDL and GPLv3 all do this) and treats all participants equally. An added bonus is that the license is compatible with a wide range of relevant code in other projects.

No Copyright Aggregation

A community that is open-by-rule will not require assignments to aggregate the copyrights of the participants into the hands of a single entity, for reasons I've previously explained. If it does, it will do so in a community-equal way by putting control of the aggregated copyright in the hands of a non-profit organisation controlled by the community or on their behalf (like SPI). 

Trademark Policy

There will be a community-equal trademark policy, granting every participant the same rights to use of the trademarks and placing control of those trademarks in safe, representative hands (ideally a non-profit foundation like SPI again). Community-equal may involve putting the trademarks effectively beyond use (as the Apache policy does in practice), as long as it applies to everyone without exception. A trademark that is under the exclusive control of one community member will be a problem if the community tries to take a direction that member objects to.

Roadmap and Schedule

The direction a project takes should be derived by loose consensus from the commitments of the proven participants. If there's a published roadmap that is visibly derived from the contributions of a diverse set of participants all present for their own independent reasons, it's a good sign that you're dealing with an open community. If the community transparently builds each release according to that roadmap, and resists back-room deals to include features unexpectedly, you're on good ground. If you find large, monolithic or unexpected contributions, go look for reasons why. 

While not infallible, these four rules provide a great lens through which to scrutinise community governance. When these rules are missing or malformed, go looking for a member claiming they are more equal than everyone else for some reason.

By Its Fruit

After all the rule-making is considered, the real test of a community is how it actually works. Is it a place with equal opportunity, real, open development and a future that's in the hands of the co-developers?

Multiple co-developers

A real community will over time accumulate many participants, each present for their own independent reasons. If most of the work is being done by just one entity or their partners after a reasonable time has elapsed, there's a problem.

Forking is feasible

While an OSI-approved license guarantees the right to fork a project, there may be practical barriers that make it infeasible: 

• Watch out for corporate agreements that include "no forking" rules so that large participants are hamstrung.
• Check there are multiple co-developers with multiple affiliations so that there are people to work on a fork.
• Ensure that the development process is open, public and documented using open source tools.
• Check the documentation is under an open license - it's hard to fork if all the documentation is withdrawn.
• Check the trademark policy.

Transparency

Can you find everything about the community, including why things happened as well as what happened?  Are all the governance conversations visible (apart from the bits where personal privacy is appropriate)? Can you track all the commits and find out why each was made? An open-by-rule community will have it all there somewhere, including the dirty laundry (arguments, trolls and the like).

Again, there are more indicators available, but these are the ones I instinctively look for to check the health of a community for signs of a lack of community equality.

Benchmark

The sign of practical, pragmatic software freedom is the presence of community equality that's guaranteed by fair governance - the open-by-rule community. There's no 100% guaranteed formula of course - any system complex enough to serve the real world of real people will include within itself the game that eventually plays it.

But these are the markers I instinctively look for in open source community governance. Read my test of it against the new proposed governance for the OpenJDK community.

This article first posted at ComputerWorld UK. Follow Simon as @webmink on Twitter and Identi.Ca.