So for "open" projects, specifications in particular, there is a very common governance structure: the Core Team.

The idea is that feedback is taken from all over the community, and there is a small Core Team of dedicated "full-time volunteers" who ultimately make the decisions and are responsible for resolving issues.

This is extremely common; in this post I'm going to mainly take Matrix as an example, but it applies the same way to almost every other 'open specification' project.

Now, while this model sounds great on paper, it has some serious issues that lead to poor community representation, and a specification that is ultimately not truly open. Not through any malice, but as a consequence of the practicalities of governance.

The biggest issue that I want to talk about here, is the "full-time volunteer" thing. The assumption is that there must be a few people who can keep an overview of the whole thing, the 'big picture', and who have a lot of time to spend on that.

Just one problem: almost nobody can afford to volunteer full-time. It's virtually impossible to combine such a task with the full-time job that one needs to live... unless the 'volunteering' is on company time, and that's where it goes wrong.

Because of the high time demands placed by the core governance role, the end result is that Core Teams are almost always made up of people representing their employers. If not explicitly, then implicitly - because if you don't make your boss happy, you might not get to continue working on this on the clock.

Which, in turn, means that the only representation in such an "open" specification is corporate representation, and there's no real way for the community to be represented. Even someone who *wants* to represent the community, is still beholden to their funder's priorities and expectations.

This, in turn, can have disastrous consequences; in the case of Matrix, for example, the spec process often blocks on invisible internal discussions among Element employees! This is very unlikely to be intentional sabotage; it is just the logical practical outcome of this governance model.

That then makes it even more difficult for 'outsiders' from the community to participate, because they don't even get to see much of the discussion, they're essentially flying blind and can't afford the time to untangle all the internal discussions.

The Core Team becomes ever more centralized, ever less transparent, and the community is ever less represented. This is how an open spec dies.

(I want to emphasize again that this criticism is *not* specific to Matrix; it is a widespread problem.)

So... how to solve this? Well, let's start by identifying the root of the problem: the "heavy Core Team" approach. Appointing a 'responsible team' makes a lot of sense in a corporate environment, but not in a community process. It is a hierarchical construct that will lead to hierarchical outcomes.

What you want is a more decentralized model; specific people overseeing individual proposals/categories, for example, without a "top-level Core Team" that calls the shots. Instead, focus on mutual cooperation.

Likewise, you want to ensure that 100% of spec discussion is public, in an easy-to-find location, well-referenced. It should take almost no effort to find the whole history of a proposal.

Be wary of implicit Core Teams; even without appointing one explicitly, make sure that it doesn't become de-facto governed by those who have the most time to spend.

Expect those with a lot of time to spend some of it to make participation easier for those with less time, instead of doing spec work directly.

I'm sure that there are many more approaches that can work here, but hopefully these are some useful pointers to identify and avoid the problem!

And if we're lucky, maybe we can use these principles to pull some existing "open" specs back from the cliff edge.

@joepie91 so we know how not to do governance and we have an example of one particular project that's not working; are there any projects that stand out to you as doing governance really well?

@vyr I wouldn't say I know of anything doing this really well *on the whole*; the corporate hierarchical model of governance is unfortunately very entrenched.

That said, there are certainly some specific bits of governance that are hopeful here:
- On fedi, the way that a lot of things are handled through some form of community consensus, despite Gargron
- NixOS assigns *different* shepherds to every RFC, avoiding a "heavy Core Team" (though there *are* governance issues of an unrelated nature): https://github.com/NixOS/rfcs#rfc-steering-committee
- Matrix *is* designed such that protocol extensions can be widely implemented and tested prior to being considered in the formal spec process at all, and PR review threads are consistently used to keep the MSC review process accessible... but well, there's also a reason I took the spec process as a whole as an example here

@joepie91 thanks! the Nix stuff sounds particularly interesting