Governance and succession are intimately tied. I feel that part of the problem with WordPress and Rails is that that there is no model for replacing poor governance.
Do you have any model to propose? Because most democratic models you would see for country governance (to which you drew parallels) rely on some key characteristics that don't apply to open source governance, making them not really transferable.
Any co-op, limited company, charitable association, etc can provide a good model - depending on the nature of the project.
As I say, it is probably overkill for most OSS projects. But once you get to a certain size, I think it is obvious that you need a way to ensure the project's longevity.
The death or disgrace of a CEO rarely destroys a company. There's a board their to temper their behaviour, a structure to ensure succession, and (most importantly) a set of expectations upon which their community can rely.
I'm not saying that's the only way to do it. I'm not even suggesting it is the perfect way to do it. But I think it is better than hoping the BDFL doesn't implode.
A few projects have a clear set of members. Most projects don't; they have contributors of code/documentation/triage/community/etc, but no clear delineation of who is or should be an enfranchised member of the project. Often, projects don't end up defining this until they need it as part of establishing some preferred form of governance.
Exactly.
I'm not too versed in political theory, but one thing from my perception that provides coherence/continuity in nations is the immobility of participants (for better or worse of the individual). E.g. if you have 70/30 election outcome you still have to factor in the needs of the 30% as they may provide important economic functions and can't just leave on election loss.
In contrast, in an open source project, even if you can clearly delineate membership and based on that voting rights for a democratic process there is very little preventing the "losers" from forking (it almost entirely comes down to brand). The outcome of that would just be an empty brand shell with a good chunk of their contribution activity gone.
This happened with iojs... Which is where Node as an org today came from. It happened with xfree86 to xorg...
It also fails plenty... I'm the the, you are not entitled to someone else's work. Make your own, or if the license permits, create your own fork... And if you lack the technical ability, sucks to be you.
If the community agrees with you that the original author is doing things wrong, and your new approach is better, they will move with you to the fork.
If the rest of the community doesn't agree with you, they will stay. If some stay and some go, it means only some of them agreed with you.
That's the thing about open source - you don't actually have to form a consensus. You can split off whenever you want.
This is true and is a key property of open source.
But it's also true that network effects and economies of scale are key for how open source projects provide value to their users. Those effects mean that the value an open source project provides to its community is often super-linear relative to the number of users.
A concrete example: If someone writes a blog post about how to use some feature, every other user of the feature can benefit from it. But also every user can potentially write this kind of documentation. So the value people provide through documentation is very roughly quadratic in the number of people reading and writing docs.
Because value like that scales super-linearly with the number of people in the ecosystem, breaking a community in two can result in less total value even if the total number of users of both communities put together is the same.
If you fork and the forks diverge, now a given bit of documentation may only be relevant to one side of the fork. A given person writing some docs may documenting things that are only true for one fork.
Now, since then, the structure has obviously changed... bit it definitely didn't start as a coup d'etat... Debian now has a leadership structures where voting members are defined as well as how leadership positions are voted for. That's far different than a handful of people trying to unseat or take the project away without that infrastructure.
BDFL is perfectly fine as long as original ownership/management has interest in maintaining said position.
Many projects start as someone's project, but become bigger than the one person.
If they keep it as one person's project, that's clear.
If there are other contributors, that's less clear.
If the project has a formal organization with governance, it's not the person's project. They might be grandparented in, like a vestige of a past monarchy, but the governance will evolve, to elections. The royalty will be kept for the tourism dollars.
A great reason for NOT having a formal organization with governance
Not true at all. They have copyright to any code/docs they contribute. Things like CLAs distory this legal reality by forcing you to relinquish your rights and enabling BDFLs to act as if they personally wrote all outside code.
To say nothing of norms of social reciprocity...
poor, according to whom?
But Eugen Rochko was not replaced. He voluntarily stepped down from power because he was personally dissatisfied in the leadership role. Nobody was calling for his ouster. He could have continued as leader of Mastodon for many more years with nobody batting an eyelash. So again, Mastodon is a red herring.