It pains me that so many have come and gone from the fedi and I think mostly because of this governance issue. Mastodon is clearly a lightning rod for this community, not-perfect but successful enough and I have enjoyed contributing to it, while blissfully unaware of so much of the history and context. In any case…
Recognizing over the past couple months that successful FOSS projects do exist, and in an attempt to learn best practices, I went on a minor quest to find good FOSS project structures which led me to Pieter Hintjens. His work was partly in politics and writing but he also developed software (notably ZeroMQ’s core library) and in the process he developed a paradigm for distributed FOSS development that I can’t take my mind off of. Having understood the power of protocols, he wrote one as a community contract which was adopted and instrumental for their development.
In a nutshell, this paradigm recognizes that software tends to mirror the organization that creates it (Conway’s law). So if you want distributed software that operates independently as well as together, then you’d better have an organizational principle that allow developers to do the same. The cornerstone is about discussing and defining problems first, then merging pretty much anything that addresses a valid problem. All the QA stuff is handled through automation, devs implicitly staking their rep when they PR, and reverting when it goes wrong. This means quick merges, it means no gatekeeping based on substance or features, letting the market decide, and it just feels like software development that matches the fediverse itself.
I’m currently experimenting with a fork that operates by that contract (called C4). I think C4 could apply to many projects and alleviate a ton of friction so hope to be able to share results soon. If you’d like to help, read the contract and let me know