mei 🌒& @ckie@pixie.town

1080641564208

okay I think I can accept being hot *gets hotter*

@amber TO CLARIFY: THIS IS ABOUT ROPE BONDAGE AND NOT MASTODON INSTANCE MODERATION

Webkit was never supposed to be compiled

This is real compiler output, done by real compilers:

-DSTATICALLY_LINKED_WITH_WTF
-Wno-tautological-compare
UnifiedSource-f2e18ffc-31.cpp.o

"Hello, I would like to compile six thousand seven-hundred seventy-seven targets"

They have played us for absolute fools

kids these days will never get to experience the expectant excitement of this screen ever in their life. not the tense sound as it reads your disk or the clicky sounds of your harddrive as the game is installed, or the celebratory drive opening as you finish... soulless downloads is all we have left. pour one out for....

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.