A benevolent dictatorship is a project controlled by a single leader. Perhaps the most commonly cited example of the benevolent dictator model is the Linux Kernel, which is run under the direct decision making leadership of Linus Torvalds. Being a benevolent dictator is not an easy job. It requires diplomacy and community-building skills, in-depth technical knowledge of all aspects of the project, and exceptional levels of commitment and dedication. However, as the Linux Kernel project illustrates, it can be very effective. This document describes the benevolent dictator governance model and provides a template for projects wishing to adopt this model and create their own governance document.
The governance model under which a project run is described in a governance document. The following description of a benevolent dictator model will provide a useful template for drawing up your own governance document. This template can be reused in its entirety or edited to suit your needs. Like most of our materials, it is available under a Creative Commons licence (see footer for details) and can therefore be reused and modified, as long as attribution to OSS Watch is maintained.
For information about the purpose of governance models, or for a discussion of the benefits of one model over another, please see our general document on GovernanceModels.
Template governance document
Despite the apparent structural differences between benevolent dictatorships and meritocracies, the benevolent dictator model and the MeritocraticGovernanceModel subscribe to the same open source principle of sharing the code and encouraging everyone to contribute back to the community. It is no surprise, therefore, that benevolent dictators and project management committees in meritocratic models both exercise their decision making power through loyalty rather than legalities. They all know that members are free to take the code and create alternative projects. In fact, this ability to fork is very important to the health of open source communities, as it ensures that those involved in project governance strive to make the right decisions for the community, rather than for a single individual or company.
However, there are notable differences between the two models, particularly with regard to how decision making within the community is carried out. In the example below, the project is led by a benevolent dictator and managed by the community. That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the benevolent dictator, who in case of disagreement has the last word. It is the benevolent dictator's job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way. In turn, it is the community's job to guide the decisions of the benevolent dictator through active engagement and contribution.
Roles and responsibilities
Benevolent dictator (project lead)
Typically, the benevolent dictator, or project lead, is self-appointed. However, because the community always has the ability to fork, this person is fully answerable to the community. The project lead's role is a difficult one: they set the strategic objectives of the project and communicate these clearly to the community. They also have to understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term.
In many ways, the role of the benevolent dictator is less about dictatorship and more about diplomacy. The key is to ensure that, as the project expands, the right people are given influence over it and the community rallies behind the vision of the project lead. The lead's job is then to ensure that the maintainers make the right decisions on behalf of the project. Generally speaking, as long as the maintainers are aligned with the project's strategy, the project lead will allow them to proceed as they desire.
Maintainers are programmers who have made valuable contributions to the project and are now relied upon to both contribute code and screen the contributions of others. Typically, a maintainer will focus on a specific aspect of the project, and will bring a level of expertise and understanding that earns them the respect of the community and the project lead. The role of maintainer is not an official one, it is simply a position that influential members of the community will find themselves in as the project lead looks to them for guidance and support.
Maintainers have no authority over the overall direction of the project. However, they do have the ear of the project lead. It is a maintainer's job to ensure that the lead is aware of the community needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, maintainers are given informal control over their specific areas of responsibility, and are assigned rights to directly modify certain areas of the source code. That is, although maintainers do not have explicit decision making authority, they will often find that their actions are effectively the decisions made by the lead.
Contributors are community members relatively new to the project. They make valuable contributions, such as those outlined in the list below, but generally do not have the authority to make direct changes to the project code. Contributors engage with the project through communication tools, such as email lists, and via reports and patches attached to issues in the issue tracker.
Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. To become a contributor, you simply have to perform one or more actions that are beneficial to the project.
Some contributors will already be engaging with the project as users, but will find themselves doing one or more of the following in addition:
- supporting new users (current users often support new users best)
- reporting bugs
- identifying requirements
- supplying graphics and web design
- assisting with project infrastructure
- writing documentation
- fixing bugs
- adding features
As contributors gain experience and familiarity with the project, they may find that the project lead starts relying on them more and more. When this begins to happen, they gradually adopt the role of maintainer, as described above.
Users are community members who have a need for the project. They are the most important members of the community: without them, the project is nothing more than a white elephant. Anyone can be a user; there are no specific requirements.
Users should be encouraged to participate in the life of the project and the community as much as possible.
Common user activities include (but are not limited to):
- evangelising about the project
- informing developers of project strengths and weaknesses from a new user's perspective
- providing moral support (a 'thank you' goes a long way)
- providing financial support
Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become contributors, as described above.
Decision making process
The benevolent dictatorship model does not need a formal conflict resolution process, since the project lead's word is final. If the community chooses to question the wisdom of the actions of a maintainer, the project lead can review their decisions by checking the email archives, and either uphold or reverse them.
Anyone can contribute to the project, regardless of their skills, and there are many ways to contribute. For instance, you can be active on the project mailing list and issue tracker, or you can supply patches. The various ways of contributing are described in more detail in a separate document.
The developer mailing list is the most appropriate place to ask for help when making your first contribution.
The benevolent dictator governance structure is a difficult one to manage and requires a very special person in the role of project lead. However, it can work very well because it is simple. Accordingly, the template we have provided defines a clean and manageable model that clearly identifies the main roles in the project, the decision making process that is most commonly found and the activities that are undertaken within the project. When creating your own governance document, ensure that it provides the necessary signposts for newcomers to a project, clearly indicating how they can contribute and how their contributions will be recognised.
Having, and documenting, a governance model is an essential part of building an open source software community, but it is only one of many steps that you will need to take. Our document 'How to build an open source community' describes the general community development process.