Benevolent Dictator

From P2P Foundation
Jump to navigation Jump to search

= one of the often-cited roles in Open Source projects, an aspect of Peer Governance

Benevolent Dictatorships = a form of peer governance where the ultimate authority lies with a few, sometimes one person.


Henrik Igo [1]:

"How do you control a programming project that involves tens – or, in the case of Linux, hundreds – of programmers working in different parts of the globe, particularly when the workers are volunteers who have no official status as employees on the project?

Linus is the benevolent dictator of the Linux project. He didn’t coin the expression himself; it comes from Eric Raymond’s essay ‘The Cathedral and the Bazaar’, in which the author studies the various organizational forms of Open Source projects. Although the dictatorship model is not the only way Open Source projects are run, it is by far the most common and the least formal. Guido van Rossum, the creator of the programming language Python, is known publicly in Python circles as BDFL – Benevolent Dictator for Life. Apparently Python programmers have no intention of ever letting poor Guido enjoy a well-earned retirement.

A benevolent dictator is the leader of a project and the person who alone has all the power to make decisions.1 Often this authority is a natural consequence of the leader being the instigator of the project, as Linus is in the case of Linux.

For those of us living in Western democracies, talk of dictatorship could sound suspicious. Although the directness of a dictatorship is sure to be cost-effective and helps to create a light organizational structure, history has taught us something about the problems inherent in such a system. Alas, few monarchs or dictators have ever been known for their benevolence. So, despite the cost, inefficiency and frustration caused by the negotiations, compromises and voting in a democracy, we have learnt the lessons of history and chosen to live under a democratic system of government. Linus Torvalds may score well above average for benevolence, but can we really trust that his successor – when that day comes – isn’t a total disaster?

The answer is yes, because it isn’t as if Linus is the leader of Linux by chance and it’s just a lucky fluke that he is benevolent. Actually, it’s quite the other way around: he’s the leader only – and I repeat – only because he’s as smart as he is.

The principles of Open Source generate a curious dynamic, which directly influences the hierarchy of the project organization and the relationships of its members. What would happen if for some reason Linus decided to screw things up and out of spite started making stupid decisions for Linux? Within twenty-four hours the other Linux developers would leave him to fool around on his own, make a copy of the Linux source code somewhere Linus couldn’t get his hands on it and keep working without him. It’s also extremely likely that the hackers involved would quickly elect – more or less consciously and more or less democratically – a new benevolent dictator.

All that is possible because the code itself is open and freely available for anyone to use. As dictator, Linus has all the authority while at the same time having no power whatsoever. The others see him as their leader only because he is so talented – or benevolent. There is a fascinating equilibrium of power and freedom. The dictator has the power and the others have the freedom to vote with their feet.

But in some other environments the dictator model doesn’t work so well. If your boss isn’t up to his job, it’s a bad thing, but what can you do about it? The army must blindly obey its commander-in-chief, but if he proves to be a sick tyrant what choice do the soldiers have about what they do? Such situations lack the openness that is inseparable from the Open Source process. Without openness there can’t be complete trust in other members of the organization; instead, we are stuck with having to use the unwieldy processes of democracy to protect ourselves against power struggles and a variety of other forms of mean-spiritedness. Openness is so integral to the system of an Open Source project that such precautionary measures aren’t necessary.

As a dictator Linus Torvalds is living evidence of the benefits of the openness principle. Openness leads directly to Open Source projects being free of the usual excess of inhibiting project organization, and to them getting along in a way that is surprisingly lightweight, nimble and cost-effective. Could that mean the dictatorship model might work in a more traditional organization? There is at least one example of it being so.

The World Wide Web Consortium (W3C) is a standardizing organ that has created nearly all the technologies that constitute the World Wide Web. Standards published by the W3C are, among others, HTML, CSS Style Sheets, XML, DOM (part of JavaScript), the PNG and SVG image formats and lots of other technologies of which we make daily use by surfing the Web. Some 450 IT businesses and organizations are members of the W3C, beginning with Microsoft and IBM.

Interestingly, the decision-making process of the W3C as it prepares standards resembles that of the Open Source dictatorship model. Preparation of a standard is done in a working group specialized in the field, and it works very openly. Trial versions of the standards are released so that anybody can comment on them. When the working group is ready, the proposal is brought to a vote. All member organizations are eligible to vote and each of them has one vote.

After the vote the W3C leader alone either approves or discards the proposal, no matter what the result of the vote. In practice, the W3C strives to get everybody in agreement, but the decision-making system itself clearly resembles the benevolent dictator model. Since the W3C was founded, Tim Berners-Lee has been its leader. He is the same guy who developed HTML and other Web technologies while working at CERN in the early nineties. He is the Linus Torvalds of the Web – creator and dictator.

As at the W3C, decisions regarding the development of Linux are usually made after thorough discussion. Linus in particular takes the advice of his closest and longer-term colleagues, who within the community are known as his lieutenants. These lieutenants are like mini-dictators, and each one has their own area of responsibility within the project. Just as for Linus, their authority is based on talent proven over a period of years and the trust that it has generated. The dictatorship is therefore a meritocracy.

There have also been instances where, despite Linus being against a particular solution, he has grudgingly had to accept what is wanted by the majority. If he didn’t, one day he might not be the dictator anymore. The open system works lightly, but is nonetheless democratic." (


Summary by Vasilis Kostakis

"Stalder (2008) submits that leadership in peer projects is not egalitarian, but meritocratic: “Everyone is free, indeed, to propose a contribution, but the people who run the project are equally free to reject the contribution outright … The core task of managing a Commons is to ensure not just the production of resources, but also to prevent its degradation from the addition of low quality material.” Further, benevolent dictatorships are common (Bauwens, 2005a; 2005b; Malcolm, 2008). For instance, these can be found in Linux project where Linus Torvalds is the benevolent dictator (Malcolm, 2008) or in Wikipedia where Jimmy Wales holds that role. Coffin (2006) highlights the necessity for a benevolent dictator (who typically is one of the founders of the project), adding that the foundation developers and the early adopters set the project ethos as well. The founder, along with the first members, upholds the right to fork. Axel Bruns (interview with Bruns, 2009) defines benevolent dictators “as ones of several heterarchical leaders of the community, who have risen to their positions through consistent constructive contribution and stand and fall with the quality of their further performance.” It is obvious that through such leadership roles, they may need to push through unpopular decisions. As Bruns notes, “if they abuse that power, theirs become a malicious leadership” and what we should expect at this point is “a substantial exodus of community members.” Therefore, following Bruns’ narrative, “the continued existence of the project at that moment would depend very much on whether the number of exiting members can be made up for in both quality and quantity by incoming new participants.” (

Eric Raymond: Are P2P processes 'benevolent dictatorships'?

"Eric Raymond had the same limitations in mind when he noted that open source projects are often run as "benevolent dictatorships." They are not benevolent because the people are somehow better, but because the dictatorship is based almost exclusively on the people's ability to convince others to follow their lead. This means that coercion is almost non-existent. Hence, a dictator who is no longer benevolent and alienates his or her followers loses the ability to dictate. The ability to coerce is limited, not only because authority is reputation-based, but also because the products that are built through a collaborative process are available to all members of the group. Resources do not accumulate with the elite. Therefore, abandoning the dictator and developing in a different direction - known as "forking" in the Open Source Software movement - is relatively easy and always a threat to the established players." (

Tony Mobily: Why a Benevolent Dictator is needed

From Tony Mobily at

"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.” (


On the role of Jimmy Wales in Wikipedia


"“The Arbitration Committee exists to impose binding solutions to Wikipedia disputes. This solution may be anything up to and including a ban from editing Wikipedia for a period of time. The Arbitration Committee is the last step in the dispute resolution process — it is a last resort to be turned to when all else has failed. Other steps, including discussion between users and, where appropriate, mediation, should be tried first. The Arbitration Committee exists to deal with only the most serious disputes and cases of rule-breaking. Until the beginning of 2004, Jimbo Wales, the current head of the Wikimedia Foundation, which governs Wikipedia, dealt with all serious disputes and was the only person with the authority to ban users who were not engaging in simple vandalism (straightforward vandals can be blocked by any administrator). This role has now largely been passed to the Arbitration Committee.

Jimbo wrote:

"The Arbitration Committee [...] can impose a solution that I'll consider to be binding, with of course the exception that I reserve the right of executive clemency and indeed even to dissolve the whole thing if it turns out to be a disaster. But I regard that as unlikely, and I plan to do it about as often as the Queen of England dissolves Parliament against their wishes, i.e., basically never, but it is one last safety valve for our values." ( )

Linus Torvards and Linux

By Lee Fleming (Harvard Business School), David M. Waguespack (University of Maryland):

Rivlin (2003) illustrates how Linus Torvalds (the original author of LINUX) realizes that his authority is technically derived, tenuous, and constantly in need of collective reaffirmation:

His hold over Linux is based more on loyalty than legalities. He owns the rights to the name and nothing else. Theoretically, someone could appropriate every last line of his OS [operating system] and rename it Sally. “I can’t afford to make too many stupid mistakes,” Torvalds says, “because then people watching will say, hey, maybe we can find someone better. I don’t have any authority over Linux other than this notion that I know what I’m doing.” He jokingly refers to himself as “Linux’s hood ornament,” and he’s anything but an autocrat. His power is based on nothing more than the collective respect of his cohorts.” (

More Information

  1. Benevolent dictator governance model,
  2. Peer Governance
  3. Open Life. Book by Henrik Ingo


“Interview: Guido Van Rossum; Benevolent Dictator for Life” 2005. Linux Format 64 (March),pp. 60-63.