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.