A (software) dictator is not necessarily good. But let me double down and say that a community cannot create a product as good as a single head at the top can do, for the single reason that people care only about their own garden, and integration needs someone to oversee and be responsible for all parts.

There is no Steve Jobs in a democratic committee.

As usual, Fred Brook's Mythical Man-Month had some valuable insights on this back in 1975:

> To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. The architect or team of architects should develop an idea of what the system should do and make sure that this vision is understood by the rest of the team. A novel idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point being, if a system is too complicated to use, many features will go unused because no one has time to learn them.

* (This is quoted from the Wikipedia page as I don't have an online copy of MMM to hand).

Cannot seems rather strong. I haven't been paying very much attention, but I was under the impression that Postgres doesn't have a dictator?

It's evolved. There was a point that Tom Lane was the last line of defense against anything that strayed too far.

Heck at one of Postgres conferences there was a shirt that said something like "Tom Lane reviewed my patch and all I got was this stupid shirt."

While he was not a BDFL style person, in the past, if he didn't like a change, it didn't make it in.

Or Rust, which - whatever you might think of it - does not feel very designed-by-committee.

Rust governance is more amazing than Rust the language and that is saying something.

Here’s the thing: you need both. You need breadth AND focus. Breadth tends to come from the community and focus from a small number of individuals. But both are important.

Keeping both of those balls in the air at once is why being a software coordinator like this is such an exhausting job.

The main differentiation (and risk) with BDFL projects is having (or not) a very competent (like one percenter) BDFL.

The structure of a committee project doesn't make it better or worse than BDFL. It just makes it more average. Any greatness present is toned down. And substandardness is brought up.

This also main reason the "led by greatness" BDFL projects are better than the committee run ones and the "led by less than great" BDFL projects "smoke out". The committee's tend towards the middle of the bell curve, BDFL's are all over the place.

>Does FreeBSD have a BDFL?

No, but it doesn't have as much success as Linux either

this is IMHO no different the real world - a 'good' despot/monarch/etc can be a good leader, but this is highly dependent on the situation (read: leader), and leadership transition process is always a risky one. Democracies/Republics work well so long as the community has a generally shared vision, but can be hampered when there is too much dissent, but generally avoid the succession problem

OT: Indeed, a good dictatorship is better than any democracy, but it doesn't work in practice because for every Augustus there's 10 Caligula.

Democracy is just the least worse political system.

Democracy is more of a principle (is just means that legitimacy of government comes from some aggregate choice of the governed), than a political system. Radically different political systems can be classified as democracies, all the way from direct vote (self-organized communes, also Switzerland) to complex federations with layers of indirect representation, such as the USA or the EU -- with a lot of other interesting alternatives such as sortition.

In a FOSS it is very easy to fork, so if the BDFL get's mad you can just say thanks and fork the project and continue. So that keeps BDFL in check.

IRL you own a plot of land, or a home. Or you have a small factory, and there are a lot of network dependencies, who does you sell the supplies, where you sell your products. It the local BDFL get's mad it is very difficult to move. (Specially if there are some cash flow controls were you can't get out with the money that you get selling your home or that you have saved.)

You can fork Linux if the dictator doesn’t suit you, but you can’t fork a nation. You also can’t switch to another nation that is more appealing, generally. Finally, Linux can’t imprison and torture you if you criticize it

If you're comparing FreeBSD to Linux then I think that says a lot about the merits of BDFLs, really.

Did FreeBSD not have the discussion about this years ago? Though they did not have a single person, but a 20 person core team, which were cut down to a 9 person core team that is voted for every 2 years.

http://freebsd.dk/sagas/freebsd/#id1

The core team doesn’t really make technical decisions. It’s more for administrative/social/governance type stuff.

Who would then make the technical decisions? The owners of the different sub systems?

There's no hard rule. The committers are expected to behave like a civilised human beings, ie talk to each other to reach consensus.

Let's say you have a fix for some driver used on ARM. You'll submit it via Phabricator to get ARM maintainers to review it. If they don't, because eg they don't have time, then you'll probably commit it anyway, but if someone points out you did something wrong, you'll be expected to fix it.

Sounds similar to debian, which is also a very successful and stable project.