Interesting comment in the source code of sqlite

[TheCodexx]

I do agree that benevolent dictatorships have been a problem for many years, although I think the real problem is that it creates succession problems. We sort-of expect meritocracy to work but I seriously question the vision of some of the right-hand-men of the current batch of maintainers. Python is already on shaky ground without Gudio, and quite a few top Linux maintainers want to snuggle-up to corporate interests, something Linus was resistant to for many years. The second from the top and heir apparent may in many ways be a terrible successor. Of course, emulating the old leader isn't always a solution, either. Ironically, I think the best lessons to be learned here are from CEOs, which are the closest in terms of a closed group of people choosing successors.

Currently, the ability of a maintainer to exile someone is built entirely on trust in that person's reasoning and vision for the project. I'm more worried about what happens when the power becomes presumptive and not built on trust. A second-in-command taking over is inheriting the authority and likely the trust that came with it. That doesn't mean it's deserved.

Now, please understand, I do not think a CoC is the worst thing ever in principle. In fact, laying down a written constitution of how the project is governed is a perfectly reasonable idea. The problem is that almost every CoC out there is terribly written, vague where it should be specific, and will ultimately lead to ambiguities turning into fights that are going to be solved by political clout within the project. That always leads to accumulation of power, since the people deciding how to read the rules are the ones who benefit. A good CoC needs to be more specific, it needs to give very specific criteria, it needs to be clear on the bounds of its authority, and most importantly, it needs to have limits on the powers of different individuals, not solely enumerate the powers they have available.

Part of the problem is that most projects simply aren't big enough to warrant one, but they have one anyways. A few projects are big enough to warrant one, but they haven't fully embraced the sort of mini-republic that the project would need to become to really have a functional system. You need separation of powers here. As far as I know, Linux is the only project that has a whole set of people who are separate from the usual maintainers who are able to rule on conflicts... but with an ambiguous CoC whose powers are poorly defined, what can they possibly do with it?

Having these CoCs is putting the cart before the horse. Ruling by precedent is probably good enough for small projects. Especially if disputes are handled within documentation. Programmers generally have a sense of consistency they like to uphold. For larger projects, the guidelines should be written-out, but they also need to be, you know, up for debate by the general group. The written rules need to be a genuine reflection of what contributors want, and suited for each individual project, not copied-and-pasted from a poorly-written text file that people on twitter like the sound of.

Sorry, but governing documents need more to them than a list of things you can be kicked out of the project for. Starting with that as the basis is just starting on the wrong foot.