A “Benevolent Dictator” project is led by a single leader. When talking about the “Benevolent Dictator” model, the most commonly cited example is probably the Linux kernel project, which is directly led and decided by Linus Torvalds. Being a “Benevolent Dictator” is not easy. A “Benevolent Dictator” needs to have communication and community building skills, comprehensive technical knowledge of the project, and extraordinary dedication and focus. However, as the Linux kernel project demonstrates, the “Benevolent Dictator” model is very effective. In contrast to this management control is the meritocratic governance model, where participants influence the project by making contributions and gaining recognition.
The organization of the project is explained in the governance document. The second section provides a template for projects that wish to use the “Benevolent Dictator” model and create their own governance documents. You can use this template exactly as it is, or modify it according to your specific needs. Like most of the materials we provide, you can obtain this template under a Creative Commons license by simply attributing it to OSS Watch, and reuse and modify the template. For a discussion of the purpose of governance models or the pros and cons of various models, please see our governance models documentation.
Introduction
Although there are obvious structural differences between the meritocratic governance model and the “Benevolent Dictator” model, both are based on the same open source philosophy of sharing code and encouraging everyone to contribute to the community. Therefore, it is not surprising that both the “Benevolent Dictator” and the meritocratic project management committee exercise decision-making power through loyalty rather than legal means. Both the “Benevolent Dictator” and the meritocratic project management committee understand that members can freely obtain code and create similar projects. In fact, this ability to fork is crucial to the healthy development of the open source community, as it ensures that project governors strive to make the right decisions for the community rather than for individuals or individual businesses. Nevertheless, there are significant differences between the two models, especially in how decisions are made within the community.
“Benevolent Dictator” Governance Document Template
Overview
This project is led by a “Benevolent Dictator” and managed by the community. That is, the community actively maintains the project on a daily basis, while the “Benevolent Dictator” is responsible for setting the overall strategic direction of the project. In case of disagreement, the “Benevolent Dictator” has the final decision-making power. The responsibility of the “Benevolent Dictator” is to resolve disputes within the community and ensure the coordinated development of the project. The responsibility of the community is to guide the decisions of the “Benevolent Dictator” through active participation and contributions.
Roles and Responsibilities
“Benevolent Dictator” (Project Lead)
Typically, the “Benevolent Dictator” (or project lead) can self-appoint. However, since the community always has the ability to fork, the “Benevolent Dictator” is fully responsible to the community. The project lead’s job is challenging; they are responsible for setting the project’s strategic goals and communicating clearly with the community. The project lead must also understand the entire community, meet various conflicting needs as much as possible, and ensure the long-term development of the project.
In many ways, the role of “Benevolent Dictator” is more like a diplomat than a dictator. As the project expands, it is crucial to ensure that the right people influence the project and that the community is united to achieve the project lead’s vision. Therefore, the project lead’s responsibility is to ensure that committers (see below) make the right decisions that benefit the project. Generally, as long as committers can follow the project strategy, the project lead will allow them to commit in their preferred way.
Committers
Committers are participants who have made valuable contributions to the project and currently write code directly to the repository and review others’ code. Often, committers are programmers, but sometimes they may be other contributors. Committers usually focus on a certain aspect of the project and earn the respect of the community and the project lead with their professional skills and level of understanding. Committers do not need to be formally appointed; influential community members who provide guidance and support to the project lead are committers.
Committers cannot determine the overall development direction of the project. But they are valued by the project lead. The responsibility of committers is to ensure that the project lead understands community needs and common goals, and to participate in project development or facilitate contributions to the project. They often have informal control over the specific areas they are responsible for and have the right to directly modify the source code in certain areas. That is, although committers do not have explicit decision-making power, their actions often have the same effect as the project lead’s decisions.
Contributors
Contributors are community members who do not want to become committers or have not been given the opportunity to become committers by the “Benevolent Dictator”. Contributors make valuable contributions to the project (see the list below), but usually do not have direct permission to change project code. Contributors participate in the project through communication tools such as mailing lists, and by submitting reports and patches for issues in the issue tracker, as detailed in our community tools documentation.
Anyone can become a contributor. Contributors do not need to make a commitment to the project, have no specific skill requirements, and do not need to go through screening. To become a contributor, a community member only needs to make one or two beneficial contributions to the project.
Some contributors have already been users of the project and have contributed in one or two of the following areas:
- Supporting new users (current users can often support new users most effectively)
- Reporting bugs
- Identifying requirements
- Providing graphic design and web design
- Programming
- Assisting with project infrastructure
- Writing documentation
- Fixing bugs
- Adding features
As contributors gain more project experience and deeper understanding of the project, the project lead gradually becomes more dependent on them. At this point, they will gradually take on the role of committers, as described above.
Users
Users are community members who have a need for the project. They are the most important members of the community: without users, the project would be meaningless. Anyone can be a user, with no specific requirements.
We encourage users to participate in the project and community as much as possible. User participation ensures that the project team can meet user needs. Common user activities include (but are not limited to) the following:
- Promoting the project
- Informing developers of the project’s strengths and weaknesses from a new user’s perspective
- Providing moral support (a simple “thank you” is a great encouragement)
- Providing financial support
Users who continue to participate in the project and community often find themselves becoming more deeply involved. Such users may then develop into contributors, as described above.
Support
We encourage all community participants to help the project management team provide support to new users. Participant support is one of the ways the community grows. People seeking support should understand that all support for the project is voluntary, so support is only provided when time permits. If users want guaranteed response times or results, they should consider signing a contract with a vendor to purchase support services. (Of course, the vendor must be an active member of the community.) However, for users who want to participate in the project in their own way and help other users, community support is the ideal channel.
Contribution Process
Anyone, regardless of their skills, can participate in the project in multiple ways. For example, contributors can be active on project mailing lists and issue trackers, or provide patches. For more information on how to participate, please see our roles in open source documentation.
For contributors making their first contribution, the developer mailing list is the best tool for them to seek help.
Decision-Making Process
Since the project lead has final decision-making power, the “Benevolent Dictator” model does not require a formal conflict resolution process. If the community questions whether a committer’s action is wise, the project lead can review archived emails and choose to support or overrule their previous decision.
Summary
The “Benevolent Dictator” governance structure is not easy to manage and requires the appointment of a dedicated project lead. However, the “Benevolent Dictator” governance model is very effective because of its simplicity. The template provided in this article defines a reasonably manageable model and explains the main roles, activities, and decision-making processes of open source projects related to it.
When creating a “Benevolent Dictator” governance document, ensure that you provide the necessary information about the roles of the project lead and other contributors roles, clearly explain how new participants should contribute to the project, and how their contributions will be recognized.
Original article by Ross Gardler and Gabriel Hanganu, published on February 15, 2010, last updated on November 7, 2013
Reprinted with permission: Developer Relations »
