The Open-By-Rule Benchmark

What does authentic open source community governance look like? An open source community will involve many people gathering for their own independent reasons around a free software commons with source code licensed under an OSI-approved open source license. But there’s more to software freedom than just the license. The key question any potential co-developer will want to ask is “what is the governance” – on what terms are people participating?

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. (Update: To be clear, this rule is mostly about ensuring patents associated with code contributions cannot be exercised against the code. Obviously a non-OSI-approved license disqualifies the entire project from being open source, but a community with no rules to protect members from contributor patents will score 0 or -1 on this point)
No Copyright Accumulation
A community that is open-by-rule will not require assignments which accumulate  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). (Update: This point used to say “aggregation” but that word was confusing to students of the GPL so I’ve changed it to “accumulation”.)

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.
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.


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 – indicators to see if it’s open-by-rule.

I welcome submissions of community data to allow me to publish new ratings. There’s an index of ratings so far.

8 Responses

  1. Simon,

    I’m not sure I agree with this point:

    “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.”

    Surely patent protection is only relevant for a corporate-owned (or started) project? In any case, with this rule you’re taking a stand that the “liberal” licenses (BSD, MIT, Artistic) aren’t open. This seems like dangerous ground to tread if you’re trying to get all OSS projects insterested in your evaluation.

    Also, this rule:

    “The direction a project takes should be derived by loose consensus from the commitments of the proven participants.”

    … seems like a good idea, but very hard to evaluate. I think you need some specifics in here of how to measure this.

    • Hi Josh,

      The big problem with those older “liberal” licenses is that they don’t give the assurance that corporate participants in a project will share patents (which they are guaranteed to be accumulating as they participate) equally with all derivatives of the project. The lack of such a commitment does not make the license in any way “un-open”, it just forces a larger burden onto the rest of the governance.

      A more modern “liberal” license such as Apache v2 does not suffer from this problem. So yes, I do believe this point has wider applicability than just corporate-sponsored projects. It’s also worth noting those projects may not have the same protections, as the corporate sponsor is unlikely to suffer any harm whatever if they attempt to litigate against a competitor in their community.

      As for the Roadmap point, I agree that some more specifics would be good; I am hoping they will come out of the experience of “running” the benchmark against projects. I felt I had to start somewhere.

      • Seems like patent protection is a bigger issue than whether the license is “modern” or not. Why not just focus on the cause of the problem, which is attitude to patents, rather than the symptom, which is the license.

        • For me, “modern” here is a synonym for “handles patents as well as just copyrights”, so I’d considered that dealt with, but yes, I’ve revised the wording to make that clear.

  2. […] Simon Phipps’ open-by-rule benchmark […]

  3. […] and activism around other issues (regarding the first, some good recent writings includes those by Simon Phipps and Bradley Kuhn, but the prominence of copyright arrangements therein reinforces my point). But […]

  4. […] The Open-By-Rule Benchmark […]

  5. […] Simon explores this in his Webmink Articles,  The Sentinel Principle and more effectively in The Open by Rule Benchmark. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: