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.
One property Debian has, which most projects don't have, is a very clearly established electorate to enfranchise.
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.
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.
Most organisation (in my country at least) have a written set of objectives and a legal structure which diffuses power.
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.
Sure there is... Forking and convincing a significant portion of users and contributors to move with you.
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.
> 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.
Ian Murdock was not forced out of Debian; he resigned in 1996 to focus on school, work, and family. He passed the leadership of the project to Bruce Perens at that time.
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.
Until such a time when my compiler learns to take "the community" as input and still produce working binaries as output, things will remain all about the code. C'est la vie.
But if it is someone's project, why should they have to leave if governance doesn't go the way they wish? The point of open source is sharing your work so others can use it and edit it. They have done their part and they maintain it as they choose whether that suits who uses it or not. I create open source projects myself, because they are applications I need or want. They are open source licensed so feel free to use them as such but my original code will develop and evolve as I choose.
> But if it is someone's project, why should they have to leave if governance doesn't go the way they wish?
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.
It depends how the other contributors are gained. If they choose to help voluntarily, then they have no claim on the development of the project. They can help to mould it as they choose but that is it. If it doesn't go the way they want they have no right to oust the creator.
> If they choose to help voluntarily, then they have no claim on the development of the project.
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.
I think this is all under the assumption that your goal is to make the project as successful as possible. If that's true, then if people think you should step down, you should. BUT can that happen? If you're trying to maximise project success, how can you also be so bad that people want you to step down? If you're not contributing but good-hearted, then you should select someone to run it day to day, but retain ultimate power in case that person turns out worse than you.
> I feel that part of the problem with WordPress and Rails is that that there is no model for replacing poor governance.
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.