Dictators in free and open source software

Dictators in free and open source software

Some people seem to challenge the idea that most (if not all) free software projects need a benevolent dictator--that is, somebody who has the last say on every decision. They are quick to point out Linus Torvalds' past "mistakes" (see the speech marks): using BitKeeper to manage the kernel, not allowing "pluggable" schedulers in Linux, etc. As a software developer, I feel that a dictator is absolutely necessary in every free software project. Here is why.

Respect earned by the BDFL

The first reason is probably the most important one: respect. The benevolent dictator for life (BDFL from now on) needs to make decisions -- in fact, a lot of decisions -- and at the same time maintain other people's respect. Decisions are not always popular, and are not always right (especially in other people's eyes). However, the BDFL needs to have the personal and technical charisma in order to keep the team's respect. Nobody would ever dream of forking Linux, because very few Linux developers would abandon Linus and follow the forker. This is true for most projects, and that's why forking is so rare. It must be said, however, that sometimes the BDFL does manages to alienate the development team so much that somebody ends up forking and bringing over most of the original developers. At that point, normally a new project is created (with a new name and inheriting the codebase) and the old one disappears after a while. This is a good thing: the DBFL is there because the crowd wants him or her to be there. It's a dictatorship, but it's an odd one: anybody can walk away at any point, create a new state, or join another one.


The BDFL knows the project inside-out. He or she is the person who will know if a decision will break the project's foundations -- and who knows how to solve a problem keeping the structure as solid as it needs to be. I see this with Drigg (a popular project I maintain) pretty much every week: I realise that my deep knowledge of the project protects it from bad patches and bad feature requests. A BDFL is crucial -- and he or she needs to be the person in charge of making decisions. In commercial software, a dummy-like manager (who doesn't know how to code) will sometimes manage to impose some features or modifications that will necessarily break the software's structure. This happened to me as well -- and I think it happened to most people who worked on proprietary, client-based software.


Free software development is often really fast. Sometimes design and technical decisions need to be made very quickly. While the BDFL can ask for opinions, he or she will be in charge of the final decision. The saying "A Camel is a horse designed by committee" is probably a little too harsh --it obviously depends on the committee -- but it's generally (and sadly) true. Decisions need to be made, and looking at some project's mailing lists, you really wish people stopped discussing things, and somebody said "enough, we'll do it this way".


Making feature requests is a fundamental right. (Please note that demanding features isn't.) Team members can talk about those feature requests and discuss how to implement them. However, code is better. If a user makes a request, and one of the other coders thinks it's a priority, much can be discussed forever, but normally "something must be coded if you want something to happen". A team member will gain respect and credibility if he or she comes up with a patch, and the patch doesn't break the project's structure. This means that contributing team members will take on things they care the most about, and will need to code those things in such a way that the BDFL won't reject them. This helps both the code and people's motivations. And other team members' code needs to be good. Which brings us to the next point...

Sending good patches, and consistency

If a developer knows that his or her patches will be reviewed by somebody who knows the project intimately, and will look for problems, then his or her patches will be better. If instead of the BDFL there's a committee who will decide on each patch by voting, bad patches will end up in the codebase -- patches that will cripple the project's structure, or will have some obscure, hard-to-debug side effects. This can also happen if the BDFL is behaving like a trusting and caring father rather than like a BDFL. And yes, I have accepted patches a little too quickly sometimes, and found myself in this very situation.

Keeping things non-political

A committee will bring politics to the projects. This equation is often true: Politics + Technical project = Disaster. If a committee decides on patches etc., a bunch of members might end up teaming up to get things through for reasons that are not purely technical (see: returned favours, asked favours, and so on). It's true that the BDFL might make political decisions, but they will always focus on the political decisions of one person -- the BDFL himself or herself -- who will know that any bad technical decision will cost the project a lot of development efforts.

To conclude...

I am not a big fan of committees. I believe that a merit-based oligarchy with a BDFL is much more functional, and gets things done much more quickly. I have managed a free software project for nearly a year, and have experienced -- although in a much smaller scale -- what many free software maintainers face every day. If you don't agree with these ideas, you can try forking a project and managing it through a committee. But, you aree likely to end up with a dromedary rather than a horse.

Feel free to prove me wrong.



Paul Gaskin's picture

It definitely makes sense for many existing projects.

However, I keep an open mind for a collaborative process which is less dependent on one person.

Speaking of Drigg, wouldn't Drigg be an interesting tool to apply for organizing a software project?

I have gone to forums for various software projects and found them lacking in the egalitarian social design of the user-moderated forum.

Let users rate each others patches, comments and blog writings about the software project and let leaders emerge by the positive or negative feedback of their peers.

It's worth a try, in my opinion. I'm going to approach projects both ways - as an individual "BDFL" as well as through an open framework for collaboration probably using Drigg for the user-moderated forum.

Db0's picture
Submitted by Db0 on

A voting system for ideas or to judge which patches and bugfixes should jump to the front of the queue is a good concept but I think that bugzillas already have this functionality no?

Terry Hancock's picture

It's important to realize that calling the leader of a free software project a "dictator" is an exaggeration to make a point. There are a number of important ways in which the term is utterly inappropriate from a literal perspective.

The authority of a FS "dictator" exists solely in the willingness of people to follow their lead. There is no coercion or force involved and there are few consequences for failing to follow them (other than that the rest of the crowd probably won't follow you if you break off -- unless of course, you have a really good reason).

It is this freedom of everyone involved in the project that makes all the difference.

In fact, a better analogy is a republic rather than a dictatorship: every contribution to the particular strain of the project that is maintained by its leader is a vote of confidence in that leader, and so long as they maintain the respect of the community, they continue to lead (since it is consensus and direct support rather than voting that determines the leader, an even better analogy is a tribal chief -- but not that many people are familiar with that form of leadership). But of course, the actual decisions are made by the leader rather than by direct voting or consensus.

What the "dictator" thing is really about is that strong, visionary leadership by a single leading person is important to the cohesion of a particular project's mission, quality, and progress.

There is also a strong "founder effect" in free software projects: most people feel that the person who started a project is the most appropriate person to lead it.

Direct democracy isn't the best way to go, and weak leadership in a consensus group can often lead to endless bickering or wavering and no progress. Someone just needs to stand up and say "this is what we're going to do" to cut through that.

Which I think was the real point you were making.

However, a project leader is much less a dictator than (for example) the owner of a sole proprietorship business.

In a world where there are real dictators who seize power and hold it through military force, I think it may be a little insensitive to throw the word around too lightly. You and I may feel confident that we will never have to seriously defend against a true dictatorship being imposed upon us, but not all the world is so lucky. Let's not lose sight of the fact that this "dictator" is a mere abstraction, and not a literal reality. Nor do we want to give credence to the idea that free software's freedom is somehow a sham covering up some form of coercive behavior.

Paul Gaskin's picture

Bush stole the elections of 2000 and 2004. Everything he's done has been un-American, un-Constitutional and 180 degrees opposite of democratic. Bush is a dictator and it's literally torture for some who suffer his merciless authority.

I agree with your opinions on the word dictator. I think there are already more than enough people who say "this is how it's going to be" rather than people who ask "how are we going to do this?"

Ryan Cartwright's picture


Whilst I completely agree with your point on sensitivity regarding the use of the word, to be fair to Tony he didn't just write "dictator" - he wrote benevolent dictator[1]. Tribal leader may be a good analogy but isn't that form of leadership just as open to abuse?

IMHO the key attributes (in no particular order) for any leader are: a willingness to take responsibility, the ability to arbitrate and to be a good listener.

Nor do we want to give credence to the idea that free software’s freedom is somehow a sham covering up some form of coercive behavior.

But haven't you heard? Apparently we're all communists anyway!

[1]Well except in one case where the acronym came out as "dictator benevolent for life"!

Rufus Polson's picture

The article is interesting and well-argued, but seems to me to have one basic Achilles' heel: There are many Free Software projects that don't, in fact, have "dictators" and yet are strong and successful.
Apache dominates the field of web-servers. It has a quasi-democratic structure. Neither Gnome nor KDE are run by dictatorial individuals. Some competing desktop environments are, and one notes that while often artistically successful these others are also-rans in terms of both number of users and richness of capability. Debian springs to mind. For projects of more ordinary size, a very typical model actually seems to involve a small core group of "committers", none of whom really dominate the others, who control the project; Abiword, for instance, is an example. That is to say, an awful lot of Free Software projects are run by committees--and in practice, whatever the jokes about committees, this seems to work. So whatever the theory may say, in reality BDFLs are not necessary for Free Software projects to either exist or be successful.

Yet this is not an unusual argument. So my next question is, why would people often go around talking about the dire need for unitary leadership when in the real world it doesn't seem to be very necessary?
Modern business culture is very accepting of, to the point of often seeming dependent on, the idea that "leadership" is of primary importance and that it is necessary to have someone who will make unpopular decisions. I've tended to suspect that this has less to do with the actual importance of leadership and more to do with justifying the actual structure of business and the power and massive income of CEOs.
But it depends on the idea that popular decision will be the wrong one, and the populace cannot be trusted with decision-making. This is somewhat dangerous at the best of times. But if everyone involved in the decision-making is knowledgeable (as will usually be the case in Free Software), it doesn't even make any sense. Given expertise in everyone involved, chances are that unpopular decisions will be unpopular simply because they are wrong; a lone leader is more likely to mess up than a democratic decision.

One thing a single leader does provide is a clear-cut decision-making process. The process is that the single leader decides. A project without a solid decision-making process of some sort is likely to have problems. A single leader also provides a very *fast* decision-making process; this makes it useful in the military at the tactical level. But in software development it's not too likely that decisions will be made with bullets whistling around your head; split-second decision making is on average rather less important than sound decision-making. There are other kinds of decision-making processes than one-person rule. As long as *something* is in place that will stop discussion from dragging on for eternity with no resolution, there's no particular reason for the something to be benevolent dictatorship.

One thing to be wary of is informal decision-making processes that depend on the group dynamics of the particular people involved. As a project grows and changes, new committers arrive and old ones leave, an informal process that worked can become broken for no obvious reason. That's why as a project grows it may be wise to formalize processes somewhat. But formalizing doesn't require centralizing. Formalizing without centralizing just requires a little more thought.

Terry Hancock's picture

I think the sort of leadership that is required really depends on the type of project. If a project is providing utilitarian infrastructure, can be measured in a very objective way, and requires relatively little creativity, then a "committee" approach can work fine.

If on the other hand, the project requires a creative vision, then somebody has to be the one whose vision it is. The extreme of this is an artistic production, like a movie -- it's long been considered essential to have one guiding vision in creating a movie. Usually the greater the number of people involved in decision-making for a film, the worse the film will be. Some software projects are like that, too.

Of course, you've no doubt noticed that an operating system or kernel probably falls into the former category, so this doesn't explain why Linux should need a "dictator". And maybe it doesn't.

Ben Asselstine's picture

Tony seems to assert that leaders of free software projects should be apolitical. This is ridiculous; just by choosing a free software license, the BFDL is engaging in an important political act.

We need more BFDLs who are aware of the political issues surrounding Software Freedom.

Ryan Cartwright's picture

I read it as Tony suggesting BDFLs should be adept at handling the internal politics of the project not that they should be unaware of or apathetic towards national or international politics.


Maurice Cepeda's picture

I don't mean to start of war, as my response does not pit *BSD against Gnu-Linux but just committee vs. a dictator model.

I have read about how politics affects committees. For instance, at how a NetBSD release was delayed by certain key committee members so that a certain commercial NetBSD based OS could launch on the same date. But actions to prevent this manipulation in the future have been implemented, although I don't know what they are.

I disagree with the dictator model producing better code. If this were true, BSD could would have to be inferior to Gnu-Linux code, but in all my reading BSD code is better. This is easily demonstrated by what's become a joke by now, that Gnu-Linux programs run faster on *BSD, this via FreeBSD's Gnu-Linux compatibility layer. When have you ever heard that a program runs better on a non-native OS? Well, Gnu-Linux apps do on FreeBSD. Now, I've talked to a friend that makes his living as a systems administrator with FreeBSD, and he says that's it's the inferior quality of the Linux kernel, and inversely the better quality of the FBSD kernel why this occurs. I've read this elsewhere, too.

You also see this with BSD wireless drivers, where *BSD (OBSD?) developers have taken a Gnu-Linux wireless driver and rewritten it (at least with what applicable), and doing it in a drastically smaller amount of code. "Less code = better code because there are less things to go wrong", to paraphrase professor Tanenbaum's philosophy. I don't recall which driver this was but googling should bring it up.

IpTables vs. PF, where PF is so simple there is no official graphical program to it, and a few simple lines produces a lot of protection. I know that iptables is such a mess to set up that few people are brave enough to attempt a manual set up. I never have set even attempted this, but I've set pf all by myself. I've also read that iptables is ancient, backwards technology while pf isn't, but I don't know if this is accurate --as I'm not a firewall expert.

Lastly, you can see how the BSD committees held out for better firewire code, waiting years before implementing it because they felt the code was unacceptable, while Gnu-Linux implemented it asap. I personally tried firewire on Mandrake(ppc) (as it was called back then), Yellow Dog (a Red Hat PPC port), Debian (ppc), and Ubuntu (PPC), and perhaps a few more distros that I don't recall. I can personally attest that that Gnu-Linux firewire code was trash, overall. It __only__ worked reliably on Debian and Ubuntu. And this really only counts as one distro, as Ubuntu was/is really just Debian testing.

In the last scenario, Linux fans can claim developmental speed, not quality, and certainly not both (unless you claim that Debian got it right, offering both quality [as per reliability] and speed, but this still does not look good for Linux as only one distro in my testing got it right).

Overall, I tend to agree that a dictator model gets things done. I'm just not sure if it gets it done with better code. I can also see how the dictator model may be necessary, but this probably depends on the circumstances, co-developers sensibilities, and needs. An important question to determine this might be, "Is the project moving forward or is it getting stuck while members are just talking/arguing?". I used to live in a housing coop, I used to be coop president, thus I know too well the sort of problems associated with what can only be described as herding cats.

I don't see a problem with the dictator model as much as a problem with Torvalds, and his short-comings as a leader. I personally don't have too good an opinion of his expertise. I even consider him somewhat ignorant, as per my readings and his critiques of Tanenbaum (read third party assessments of Torvalds by way of academic professors). I don't think the Linux kernel is the product of a genius, just something that snowballed into a better "product" because someone (Torvalds) had the drive and guts, followed and supported by a huge community of admirers, and then millions of dollars of investment (if not more now; IBM is important here) created it so.

As for other issues with the dictator model (mainly associated with Kolivas' leaving Linux development), I've written a bit on it already. Maybe FSM would be interested in publishing it.


Maurice Cepeda

Terry Hancock's picture


Well, I can't say what's true in general, but...

My own personal experience with running Linux-targeted code on BSD systems is that it crashes and is finicky. After investigating, I found out that this was apparently because BSD provided very limited file-handles. This caused bugs with Python code (like Zope) ported to BSD, and in a production situation it would fail in annoyingly unpredictable ways.

I would develop code and test it on my Linux system at home, then I would attempt to deploy it on a BSD server. Invariably it would crash and require extensive work-arounds of mysterious resource problems in order to get it to work again.

This is why I currently run my web hosting services on a Debian GNU/Linux O/S, despite claims that BSD is a "better" server O/S.

So, at this point, I remain skeptical of this sort of claim!

I realize that this is a subjective issue. It may also have been fixed, because I don't think there even was a "Linux-compatibility mode" when I was having those problems.

However, I think that the much better hardware support for Linux outweighs any advantages that BSD has in the kernel design, anyway. That too, is a management issue -- for some reason, many more people contribute hardware/driver code to Linux than to BSD. And as a result, Linux supports more hardware.

Is that because of the BDFL vs committee styles? Maybe.

I think it's most likely due to the difference in licensing, but it might be a challenge to prove that.

Maurice Cepeda's picture

Rather than, "As for other issues with the dictator model (mainly associated with Kolivas' leaving Linux development)", I should have written, "As for other issues with Torvalds' dictator model"(associated with Kolivas' leaving Linux development) ... ".

" ... running Linux-targeted code on BSD systems is that it crashes and is finicky"

The compatibility layer isn't perfect, as not everything runs on it, but what does just flies. It is recognized that it needs work, and to this end it was accepted to be part of Google's summer of code.

"So, at this point, I remain skeptical of this sort of claim!"

I must admit that the notion that the FreeBSD kernel is better than the Linux kernel is mainly based on FreeBSD 4 and Linux 2.4. Well, things have moved on since these versions. I have heard that the latest versions of FreeBSD have lost performance, if only anecdotally, certainly stability. I think Matt Dillon of DragonFly warned of this.

As for Linux's better hardware support, yes, that doesn't escape me. I had Gnu-Linux install on almost anything I've tried it on. Yet, installing *BSD is more like flipping a coin.

Even so, I'd argue that good hardware compatibility is not a sign of good code quality, just that it lacks support. I'm not sure compatibility layer glitches are either, unless we compare it to a *BSD binary Linux compatibility layer, and there isn't one. Let's compare apples to apples, and that's what I did in my earlier comment, I compared *BSD firewire support (or lack thereof) to firewire in Gnu-Linux, wireless to wireless support.

I don't mean to argue for installing *BSD over Gnu-Linux. You can run different OSes depending on what installs and/or what you want/need, and philosophical orientations. I'm just trying to make sense of the idea that the dictator model produces better code than that of the committee. I just don't think this holds, at least not universally.

Generally speaking, I think things either get done fast and sloppy, or slow and well done.

Terry Hancock's picture


The fact that Linux is "better supported" is fair game as regards "quality". A lack of support means lower quality. Why isn't BSD so well supported? I think you have to realize that these things are all parts of the "package deal" that comes with the different developer cultures surrounding BSD and Linux. There's a lot to think about there, and I'm not sure how to draw a full comparison between the two.


You're probably right. But I don't think it argues for the reverse case, either. I also suspect that the management model has little to do with the relative success of BSD versus Linux.

I think that the committee approach can work well when the basic product is widely understood. Once you know what a "word processor" or a "CAD system" or an "operating system" is, then you can easily imagine a bunch of people coming together and deciding what specific features it ought to have and how much they are willing to contribute to make them happen.

I think where you really need leadership is in designing something new, or taking an original approach on an old problem. In those cases, someone has to imagine a solution and then define that solution well enough through their design choices and acceptance of contributions. The more creative the task, the less easy it is to distribute the decision-making.

But even then, "dictator" is quite a misnomer -- it's more of a question of whether anyone will follow your lead. If they will, then great. If not, then you just toil alone or you give up on the project. Most projects of this type involve a lot of individual toil before they ever get high enough profile to receive significant contributions. So, when they do, is it any surprise that people defer to the person who put in all of that unrewarded effort? They've earned it. And they obviously know the project better than anyone else. I think that's why most people are awfully reluctant to fork the project.

Maurice Cepeda's picture

As for arguing the reverse case, whether if the BSD management model can account for the relative success of BSDs vs *Linux, I think that BSDs held out till firewire code stabilised, does suggest this.

How does this affect success (acceptance) of BSDs? Well, what this means for the server admin is that --if it'll install--- he can have confidence in that the system will be ultra reliable and stable.

In Gnu-Linux terms, this is the rough equivalent of the enterprise edition of a distro, which receives tweaks to smooth out rough edges that the community edition never incorporates. We all know distros that produce half baked products. There are a plethora of them around, some of which are produced by well known companies. We all know who they are. It's in their best interest anyway, to have the tweaked version only available for paying customers. Debian is the one well known player that doesn't play this game, what with their high quality control.

Getting back to the BSD model, they don't play this "enterprise" game, and they can't because of their management model demands a stable product right from the start, not afterwards. What does all this mean? *BSDs don't have a more unstable community edition, followed by a "better" enterprise edition because every release is ultra stable and mature. This may account for the little success that BSDs have had. If the BSD product was slightly inferior, so as to be able to create an impressive enterprise/payware edition, then *BSD might be able to garner more visibility and mind share in the general consumer consciousness. After all, for profit companies do advertise their tweaked OSes. The only exception to the BSD "enterprise" edition that I can think of is Wasabi systems, that provides a supposedly polished NetBSD. There was also Wind River, and they retired their BSD/OS in Dec. 31, 2004, and stopped funding FBSD in 2001. Walnut Creek merged with BSDI in 2001, and BSDI properties got bought by Wind River in 2000. So, there isn't a lot in the way of "enterprise" *BSD, as as far as I can tell, just Wasabi. (Perhaps visiting the NetBSD pages will demonstrate otherwise.)

Now, before this sparks a flame war, do we remember the Mandrake community editions that always felt beta and even alpha-ish before becoming Mandriva? Do we remember Red Hat default installs installing with important ports wide open? (Yes, this has been duplicated in computer classes.) Do we remember the dependency hell of Red Hat's package management system? Think about these examples of unmature Gnu-Linux products that resulted in bad user experiences before posting, and therefore bad code.

Of course, I do speak in general terms, mixing the desktop user experience with that of a server, and Gnu-Linux traditionally has *BSD beat on the everyday user experience. But even here this is quickly changing with Desktop BSD, PC-BSD, and Midnight BSD, although I don't think they'll be able to duplicate the Gnu-Linux feature rich experience. To do so, they'll have to incorporate the corresponding missing features. I don't mean to write that this can't be done, just that this means incorporating relatively untested, unstable code, and that's not what *BSD are about. If they do, all the best to them, it'll sure be interesting to test.

Lastly, about BSD code being inferior just because it doesn't install on as much hardware as Gnu-Linux, is salt inferior to sugar because you can't throw salt into your favourite apple pie? No, I don't think so. Maybe (if I can perhaps backtrack a previous argument of mine for a second) they just are good at different things, and in different scenarios. To say the contrary (that Linux code is better), you'd have to prove that both sets of code have as objective to run on as much hardware as possible. I don't think either sets of code have this stipulated. It just happens that one has received more hardware support than another, probably because it has the backing of major hardware manufactures such as IBM.

On the other hand, NBSD does pretty darn good without this sort of backing. So if you want to make this sort of argument, one could say that NBSD code is better hinging on two things combined, 1) the large amount of hardware it installs onto, and 2) that it doesn't receive the support that Gnu-Linux does. Also, remember that NBSD still supports an enormous amount legacy hardware that the 2.6 linux kernel dropped long ago, so you're best to not argue that Linux is better than *BSD on account of hardware support.

Maurice Cepeda

PS-I know that enterprise means you're paying for support. I was solely referring to the tweaked factor that also is part of the payware version. I also used "unstable" in a loose fashion, meaning things don't "just work", necessitating fine tuning or even hacking. About *BSD installing being the luck of the draw ... well, that's my experience with FBSD and OBSD specifically, NBSD installing onto almost anything --if only by way of a painful experience. In any case, if you can't install one BSD, another one will probably install. As for Gnu-Linux installing on almost anything, that's my experience with Debian, specifically.

Author information

Tony Mobily's picture

