579.rst

TBD re Governance
#################
:date: 2022-03-11 18:59
:author: james
:slug: 579
:status: draft

People often ask about open source project "governance" when they're really asking about "participation". Participation comes before governance. Participation ranges from basic things like "How do I contribute (e.g., code or documentation)?" to larger questions like "What are the available routes for investing in this project?", "How would one go about gaining influence in this project?", etc.

That last one might sound like a governance question, but it's really not. For the most part, influence in a FOSS project is achieved by committing developer time and other resources. Of course, it's still important to implement those commitments in smart, strategic ways -- different techniques are appropriate for different projects. One can't just barge in with massive PRs. All I'm saying is that it's usually not about governance. One can go very far along the participation road before ever running into a genuine governance issue.

So what is actual governance about?

Governance is what groups use to make decisions about the allocation of collectively-owned non-replicable resources. Since these kinds of resources do exist in FOSS projects, there is such a thing as governance. It's just not about the code itself -- since the code can be copied under its FOSS license, it is a replicable (in economic terms, "non-rivalrous" and "non-excludable") resource.

So, for example: how Global MegaCorp Incorporated allocates its developers' time in the project is *not* a governance issue, because the developers' time is not the project's resource to make decisions about. On the other hand, the content on the project's web site is a governable thing, because there can only be one web site (if the project forks, now there are two projects, but each still has its own web site).

Similarly, the project's trademark policy is a governable thing. Of course, it might be the case that the primary corporate sponsor just owns the trademarks, but that just means the governance mechanism is very simple: that sponsor decides how to use the trademarks. And one good way for the sponsor to gain influence and standing in the project is to invite the project's members to design a trademark policy, and then commit to both adhering to it and enforcing it. (Notice this is a bridge between participation and governance!) Also, sometimes projects have project-owned money or physical resources, and these are obviously matters for governance.

But the *main* governable thing most projects have is the project's overally technical/social identity itself -- its credibility, essentially. That's what I'm getting at with the examples of the web site and the trademark policy. The only thing that makes a project's releases "official" is that everyone (every user, that is) agrees that the project is the source of its releases. That social identity is a non-replicable resource -- its non-replicability is precisely why hard forks are meaningful and schismatic -- and therefore things that affect it are properly a subject of governance.

Thus, while day-to-day development questions are generally just "participation" matters, once there is serious disagreement about whether (say) a given feature should go in to the project or not, the possibility opens up that it may rise to becoming a governance matter. Since dealing with governance matters is usually much more heavyweight than dealing with participation matters, experienced open source project participants will usually work pretty hard to achieve consensus on even contentious technical questions before falling back to formal governance mechanisms.

Now, the formal governance mechanism might just be "the BDFL decides" or "the main corporate sponsor decides, because they said all along that this project is operating in Rocket-Ship-To-Mars archetype mode". That's fine, as long as everyone's up front about it. People can always fork, after all. But I think as projects mature, then generally tend toward more group-oriented governance mechanisms (though B2B open source is at least one exception -- you don't see multi-party democracy flourishing in Android-land, and that's okay: it's no indictment of Android, it's just how the particular copy named "Android" of that code is governed).