Hacker News Reader

Comment by sph | Hacker News Reader

> There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too.

BDFL governance is extremely underrated in the opensource world. People attribute the success of the Linux kernel to its open contribution style, but I will argue that Linux is successful because there's a dictator at the top that enforces a direction, a long term goal, and most importantly, says NO.

Community based governance is a direct cause of that jwz's Cascade of Attention-Deficit problem one can find all over the open source world, especially Linux desktop related.

View on HN

Does FreeBSD have a BDFL?

We don't have enough data points to determine if what you are saying is correct. I have also seen lots of BDFL projects smoke out.

Is the lesson that actual dictatorships only survive long term if 1) the dictator is a nice person and 2) they eventually get managed by an open democratic process?

I think you are actually describing the two clocks problem. Lots of BDFL projects have their own Cascade of Attention-Deficit issues, the project only goes in the direction the BDFL actually cares about.

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.

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?

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.

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.

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.

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).

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

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

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.

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

Underrated in the open source world — whilst at the same time, feels obvious in the writing world?

Imagine an author has gotten started writing volumes 1 and 2, and those volumes became popular — maybe the Harry Potter books as an example. Now, adding more authors with equal "story-line decision making power", or a committee, for volumes 3, 4, 5, is a weird idea, right.

Look at what happened with Game Of Thrones! Total disaster at the end that ruined the whole thing for everybody.

> I will argue that Linux is successful because there's a dictator at the top that enforces a direction, a long term goal, and most importantly, says NO.

Linux is made because of many people all over the world, but it is successful because of the BDFL at the top. A consistent sense of mission absolutely benefits a project in the long term. There just isn't anyone that's going to get your idea better than you, when you're doing something that you know enough about to seriously get started on.

I think it's _just_ underrated; I think it's underrated in the business and government worlds too. A good leader should take different points of view into account, but should also be able to make a decision when needed.

Reply on news.ycombinator.com