Debian still having trouble with merged /usr

Compare, say, the models used by Rust, Fedora and many other projects, where ownership is shared and changes are made through "change proposals" that are signed off on by a smaller group that determines if sufficient consensus exists in the community for them to go through. This means you keep the do-ocratic nature, heavy discussions and consensus building. However, crucially, once decisions have been made, they can be implemented (or reverted) by the change owners without requiring much work from anybody else. That is, imo, a much better approach than giving everyone a shotgun and their little patch of "don't tread on me" land to viciously squabble over.

Yes, watching it in action is for masochists. If you ever wanted an example of why you should not look at how the sausage is made, it's Debian. After watching it in action, I find myself surprised when it comes to a conclusion. Yet despite appearances, if you look how Debian has transformed itself over the years, it's made many fundamental changes to how it operates, and some like reproducible builds have literally set the pace for the rest of the software world to follow.

If you evaluate it by end results, then Churchill's quote summarises the situation well: "It has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.…"

The technical committee is one of Debian's hidden gems. Not because it has power to force anything - as this illustrates it doesn't. All it's writings do is collect the facts, and organise the arguments. In doing so it makes it possible for the 1000 odd people in the project to assess the situation without having to wade through tons of emails, IRC chats, Debconf discussions, half or which are flamewars. The "power" of the technical committee is without it, the project would not reach an informed consensus in many cases. Instead the loudest voice would win.

It looks to be the best in class of any open source project. Sadly, it contrasts to how Debian handles other more personal conflicts. Debian like all large organisations works because on a whole, there is conflict is solved by consensus rather than one group ousting another. If it is to survive, the Debian project has to protect itself form such individuals who generate more heat than light by banning them from mailing lists, infrastructure, wiki's and even expulsions. It does that of course, but as a DD myself what happened behind the scenes to justify those decisions is so opaque (which is usually justified with "privacy" handwaving), it's impossible to feel comfortable with them. I wish we had a committee as diligent as the technical committee summarising those situations.