Whether you want to contribute to open source projects or you want to have your own open source project, it is important to know/find out which project's contributor has the authority to help you make a contribution, for example. In open source, this is called project governance. Project governance is a group of community-elected developers from the project's contributor base that are able to make technical decisions about the project's future [1]. Every open source project has a governance model. However, this model may vary from project to project. In this article, we describe some of the most common open source governance models.

Variance in open source governance models

Different projects may have different governance models. For you to have an idea, governance models can go from centralized control by a single individual or organization (also called benevolent dictatorship) to distributed control awarded in recognition of contributions (also called meritocracy) [2].
Figure 1 shows the range of open source governance models and some examples of projects in those categories. It is also illustrated in the image whether the project encourages contributions from broad sources (bazaar-style) or has a small core of dedicated contributors (cathedral style). For example, the Linux project encourages contributions from everyone and the project is often released, but the governance is done by Linus Torvalds, who has the final say on the contributions included on each release. The project GNU Emacs follows another approach. Emacs has a small team of committed contributors and less frequent releases. Although the project is governed by Richard Stallman, there are maintainers who run the project with a more open contribution model.

Figure 1: Governance models - Image extracted from [2]

Diving deeper into the different open source governance models.

We present below an explanation of the different open source governance models.

• Do-ocracy: Projects that adopt this governance model tend to value those who do the work as those who make the decisions. That is, contributors that invest the most time, energy, and attention to the project have the most authority and influence over decisions in the project. Projects that follow this model claim that they don't have a governance model, since the model is implicit in the everyday tasks and interactions of contributors.
• Founder-leader: This is the most common governance model in projects with a small number of contributors. Basically, the individual or group who started the project are those who establish the project visions, and control permissions to merge the code, for example. It is typically clear who has the power and authority, and who are the decision-makers for project matters.
• Self-appointing council or board: projects governed by this model appoint a number of leadership groups to govern various aspects of a project. Those groups are often called the steering committee, committer council, technical operation committee, board of directors etc. This model might be useful for projects that do not have a sponsoring foundation and establishing electoral mechanisms is difficult.
• Electoral: this model allows projects to govern through elections. Contributors might vote for candidates to fill out various project roles. Typically, open source communities that follow this model establish and document electoral procedures.
  Corporate-backed: individual companies may choose to distribute their software under the terms of an open source license as a way of reaching potential developers and users. Under this model, the governing organization may note accept contributions from anyone outside of it, or require a contributor agreement (CLA) to accept a contribution.
• Foundation-backed: Some projects might choose to be managed by a non-profit or trade association. This model ensures that a single project participant doesn't have exclusive control of the project's resources. In some cases, the foundation leadership and project leadership can form a single governance structure that manages all aspects of the open source project. In other cases, the foundation manages some matters such as trademarks and events, but other governance structures such as code approval are handled by the project leaders.

How do projects apply these governance models in practice?

Projects might follow one or more than one governance model. Classical examples of projects following the Founder-leader model are Linux, Python, Perl, SciPy, Wordpress, Pandas, and Vim. Projects that are under foundations such as all Apache projects and the TARS project hosted under the TARS Foundation follow the foundation-backed, electoral, and do-ocracy.

Why should your project have a governance model?

A project governance model has many advantages for open source projects. First, it reduces the risk of project abandonment or not being maintained. Second, it eliminates single-vendor control. When projects start having a certain success, they start to realize that without a governance model, there is a great risk of the vendor making choices that are good for the company's strategy, but not for the entire ecosystem. Finally, it's a safe place for innovation. That is, when a project has an open governance model, developers trust that their contributions will be accepted based on merit and what's best for the project. This allows projects to attract people with a different experience and background, making them stronger.

TLDR-summary:

Adopting a governance model as early as possible is critical for the success of an open source project. Choose the best governance model for your project and document it so that other contributors know who to contact in case they need to.

About the author:

Isabella Ferreira is an Ambassador at TARS Foundation, a cloud-native open-source microservice foundation under the Linux Foundation.

References:

[1] https://developer.ibm.com/articles/open-governance-community/
[2]http://oss-watch.ac.uk/resources/governancemodels