Governance models

by Ross Gardler and Gabriel Hanganu on 15 February 2010 , last updated

Introduction

A governance model describes the roles that project participants can take on and the process for decision making within the project. In addition, it describes the ground rules for participation in the project and the processes for communicating and sharing within the project team and community. In other words it is the governance model that prevents an open source project from descending into chaos. This document explains why a governance model is necessary, considers some of the challenges associated with adopting a governance model in open source projects, and looks at the key areas such a model needs to cover. It also describes how to encapsulate your governance model in a governance document.

Why does a project need a governance model?

There are almost as many variations of open source management strategies as there are open source projects. It is therefore critical that a project clearly communicates its policies and strategies to potential users and developers of the project’s outputs. A clear governance model also allows potential contributors to understand how they should engage with the project, what is expected of them and what protections are provided to ensure that their contributions will always be available to them. In addition, it describes the quality control processes that help to assure potential users of the viability of the project. The development and communication of a clear and concise governance model is one of the most important steps a project can take towards sustainability through open development.

Governance models range from centralised control by a single individual or organisation (benevolent dictatorship) to distributed control awarded in recognition of contributions (meritocracy). You can find governance models at any point along this spectrum; it is also possible for a project’s chosen governance model to move along this spectrum as the project matures. The diagram below illustrate some examples FOSS projects and where they fall on the scale. They also illustrate the whether the project encourages a contributions from broad sources (bazaar-style) or have a small core of dedicated contributions (cathedral style). For more about these contribution models, read Eric Raymon’s essay The Cathedral and the Bazaar. It’s interesting to note that a particular governance style doesn’t automatically imply a particular contribution model, although projects do tend to start as cathedral-style benevolent dicatotorships and move towards bazaar-style contribution or meritocratic-style governance (or both) as they mature.

Governance Models and Contribution Models

A graph showing where 5 open source projects sit on the scale from Benevolent Dictatorship to Meritocratic governance, and on the scale from Cathedral to Bazaar-style contribution

  • Linux is Raymond’s classic “Bazaar”, encouraging contributions from anyone, making releases early and often. It is governed by Linus Torvalds, who has the final say on which contributions are included in a release.
  • GNU Emacs is Raymond’s classic “Cathedral”, with a small team of committed contributors and less frequent releases, and governed by Richard Stallman. It is worth noting, however, that Stallman no longer has the same role that he had when Raymond write his essay, and the current lead maintainers run the project with a more open contribution model.
  • Apache HTTPD, as an Apache project, follows a formal meritocratic structure. It invites anyone to contribute their code.
  • Apache OODT, again, follows Apache’s meritocratic model. However, it is developed Cathedral-style by a core team who don’t actively invite others to contribute, and who make releases when they feel they can guarantee a certain level of quality.
  • Ubuntu has a benevolent dicator, in the form of the project’s founder and funder Mark Shuttleworth. However, many decisions are delegated to the Community Council and Technical Board, whose members are appointed by the community through a meritocratic process. Some core parts of the system are developed Cathedral-style within Canonical, Shuttleworth’s company. However, community developers are often invited to develop key parts of the system, such as the Core Apps initiative for the Ubuntu phone platform.

Governance models in use

Let’s look at some example governance models. First, consider the Ubuntu governance model. This model focuses on describing the structure of the community and the responsibilities associated with each component of that structure. It also outlines the decision-making processes found within the project. The Ubuntu project has opted to separate developer information from the structural information found in their governance document, but the technical management processes are also clearly documented.

The Apache Software Foundation has two sets of governance documents for each project. The first concerns the foundation’s governance, which sets out the structure of the organisation as a whole. The foundation also provides a set of documents on key processes found within its projects, such as decision making. However, since each project is free, within certain constraints, to define its own variations of these processes, many projects have their own governance documentation. See the Apache Forrest governance description for an example.

Our third and final example of a governance model in practice is found in the Taverna project. This is an example of an open source project that has grown within the academic community and so demonstrates a model that has been found to work in the academic environment. The Taverna model, like the Ubuntu and ASF models, focuses on project structure and management processes.

Barriers to adopting a governance model

In spite of the importance of defining a governance model at the outset, many projects fail to do so. There are a number of possible reasons for this. Among the most common are:

  • the process is perceived as ‘red tape’
  • there is a concern that the project will lose its sense of direction
  • it is felt that control of the project’s strategy will be lost
  • the project is thought to be too young or to small to attract active users or developers

Although each of the first three concerns is potentially valid, these fears are easily dispelled by using an appropriate governance model. However, the final concern, regarding the age of the project, is never valid. This is because any potential contributor to the project needs to know how to contribute efficiently and effectively, and how their contribution will be handled. Without clear guidance on these matters, most people will walk away rather than join an immature project. But if those early adopters are shown that they can help to guide the project as it matures, they may decide to stay. A single external contributor may well have a major effect on the sustainability of a project, so project initiators can simply not afford to risk losing that contributor as a result of trying to save a small amount of effort in the early stages.

It is helpful to address each of the above concerns as early as possible in the life of the project, so that they do not become a barrier to adopting a clear governance model. Let’s explore them in a little more detail.

Red tape

Some people perceive a governance model to be nothing but red tape. But it is not necessarily true that defining a governance model is an unnecessary bureaucratic exercise: it depends on how carefully the model is drawn up. The goal is to make the model simple but effective. It need not have a rule for handling every situation; indeed, it should not attempt to do so. Instead, the model should provide a lightweight way of guiding the management of the project in a clear and transparent way. This transparency will encourage third parties to join the project. They can see how the project is run and predict how it will react to their contributions before expending any significant effort on that work.

It is important to note that a governance model should make the process of making and evaluating third party contributions easier, not harder. It should remove the uncertainty that can lead to wasted time for everyone involved.

Loss of direction

The fear that a governance model will constrain the project as it adapts to a changing environment may be attributed to the fact that there are many poorly governed open source projects that are indeed limited in their agility. However, the problem is caused by the lack of a clear governance model rather than the provision of one. A good governance model will actually increase the agility of the project, as it defines how new contributors can take the project in unexpected directions without interfering with its core goals. It provides a mechanism for allowing the community as a whole to define the direction they feel the project should take, while ensuring that the core project team does not lose control. The issue of control is discussed in the next section; here we will focus on vision and direction.

Since it is not possible for a project to be all things to all people, the goal of a sustainable project should be to provide as complete a solution as it can for its core stakeholders, while still being of interest to other potential stakeholders. The project must also be ready to accept input from unexpected quarters, and must be able, wherever possible, to accommodate their needs in its future vision and direction. Doing so significantly increases the pool of resources the project can draw upon in its quest to become sustainable. However, trying to be all-encompassing will nearly always result in failure, as effort becomes spread too thinly over the problem domain.

The solution is to adopt a governance model that provides mechanisms for clearly defining and enforcing the boundaries of acceptability within the project. The model should be designed to allow project leaders to avoid unnecessary and wasteful diversions by potentially rogue elements within the community. The model must also ensure that those with aligned strategies can undertake complimentary work in a collaborative and constructive way. This kind of collaboration broadens the scope of the project without significantly increasing the demands on the originating project team.

Loss of control

Perhaps the biggest fear of all is that the governance model will pave the way for third parties to take control of the project. After all, a governance model encourages third-party participation by empowering those parties within the project. However, as with all the concerns addressed here, a well-designed governance model ensures that control remains precisely where the project leadership wants it. This may mean that all decision making is controlled by a central organisation (e.g. MySQL and SugarCRM), or it may mean that all decisions are made by the community as a whole (e.g. Apache HTTPD Server and DoJo ).

When deciding on the level of control required by your project team, consider how the efforts of the team are to be sustained. If, for example, the project is producing a high-profit product that will be exploited commercially, there is some benefit in maintaining control while encouraging collaboration. It is true that choosing a centralised model ensures that product evolution is optimised for the chosen exploitation route. However, it does limit the breadth and depth of contributors likely to take an interest in the project, as their strategic goals may differ.

On the other hand, if the project is producing a component part that, in itself, is of low commercial value, the aim is usually to ensure that the component is as widely used as possible. In those circumstances, the goal would be to maximise participation by allowing all interested and active partners to participate in strategic planning.

When communities split (forking)

One of the strengths of the open source licensing model is that anyone has the right to take the code and develop it independently of the copyright holder. This is called forking. This means that the control exerted by the project leadership is only as strong as the support the community gives that leadership.

Regardless of the contents of the governance document, it is possible for those who fundamentally disagree with the controlling influences to start a new project. It is not the role of a governance model to prevent such forking of the project. Rather, it should clearly define the influence a potential contributor is likely to have over a project’s strategic direction. It is only through careful management of the community that open source project leaders remain ‘in power’. Clearly setting out the rules of the community in this way is an important part of this management process.

The project is too young or too small

Finally, we return to the issue of a project being too young to attract third-party users and contributors and therefore not needing to concern itself with how to manage them. It is very common for projects to feel that a governance model is not yet necessary, but this, in our opinion, is never the case.

It is never too soon to define a suitable governance model. Without one, the chances of third parties wishing to contribute are considerably reduced. This is for a number of reasons:

  • potential contributors will not know how to contribute
  • they will not be sure what will happen to their contribution
  • the project will not look serious about engaging with third parties
  • there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor

Since you never know when a contributor might stumble upon your project, it is important to be ready from the earliest possible date. Each missed opportunity to attract contributors damages the sustainability of the project. Remember also that it is the first contact between a project and a contributor that is the most important. For example, a bug fix provided by a third party could result in several people having a better user experience, which could result in more users. This, in turn, would make the project more attractive to users and contributors.

Another common misconception is that there are not enough potential users or contributors to make it worth courting them. Again, we would contend that a single contribution that improves the quality and usability of the product is worth having. The effort involved in creating an adequate governance model is usually less than the effort involved in all but the smallest of contributions.

A final concern that is often raised is that the project is too small to cope with an influx of third-party users and contributors. This illustrates a lack of understanding of how open development works: firstly, even the largest of projects do not attract more than a handful of active developers at any one time. Secondly, a well-managed community will be largely self-supporting. This is particularly true for decentralised communities.

How do open development projects make decisions?

Decision making in an open development project appears, at first sight, to be a complex issue and is central to many of the fears examined in the previous section. Many people know, for example, how difficult it can be for a committee to reach a decision. Documenting the process by which decisions are made is therefore a key part of a governance model, and it is worth taking a little time to explore the various approaches commonly taken to prevent deadlock situations from occurring in open development communities.

Decision making in open development projects can range from fully centralised to fully decentralised. Through necessity and familiarity, nearly all projects will start life with a centralised model, with a small number of initial contributors, perhaps as few as one. As a result, all decisions are made by this small team. For a small team, centralising the decision making is easy, and is akin to what is found in closed projects. However, as a successful project grows, more and more people will be willing to contribute to the objectives of the project. The decision making process may need to evolve accordingly.

Benevolent dictatorships

Project founders who maintain control throughout the entire life of the project are sometimes called benevolent dictators. A benevolent dictator is responsible for determining the general direction of the project and making the final decisions when the community is in disagreement. As more and more members join the community, the benevolent dictator strives to ensure that these decisions are in the best interests of the project, rather than the interests of any particular individual or organisation. A good benevolent dictator needs to be able to balance the conflicting requirements of community members. This is no easy task. Before you set yourself up as a benevolent dictator you should ask: ‘Can I be a good benevolent dictator?’

While the project team is small, and the community of users is small, it is possible for the benevolent dictator to make all decisions in a traditional top-down manner. However, as the community grows, this becomes more and more difficult. Very few people will be able to fully understand all the details of the problem being addressed. Consequently, may feel uncertain about making decisions in areas in which they are less expert. As the project grows in size and scope, these areas of uncertainty will grow, and so the dictator may feel unable to make a decision as frequently as required.

For this reason, an effective benevolent dictator gradually takes on the role of arbitrator and coordinator. They do not, as a rule, take sides in any particular debate. ‘I’d much rather have 15 people arguing about something than 15 people splitting into two camps, each side convinced it’s right and not talking to the other,’ says Linus Torvalds. Here Linus recognises that by taking sides he will influence those who are undecided and thus steer the development of consensus in an unintended way. This is acceptable if he himself has a firm opinion, but in areas where others are more qualified to lead the process, it could result in sub-optimal decisions.

In a medium to large project, it is usually better for leaders to allow discussion to proceed and only indicate a preference in the unlikely event that there is no visible consensus emerging. Thus, the benevolent dictator tries to prevent fruitless debate, but encourages informative debate. In this way, they can be seen as a chairperson rather than a dictator.

When writing the decision making section of a governance document for a centrally controlled project, it is important to indicate that while the decision making power is centralised, the distributed community is expected to inform that decision through debate. Failure to do this may alienate some individuals, who fear that there is little opportunity for them to bring their expertise to the project.

Meritocracies

While some projects maintain tight control over the decision making process, others feel it is more effective to allow the community as a whole to make decisions. In this case, there is an increased need for a formal decision making process, since there is no single person able to break a deadlock.

The membership structure of such communities typically looks flatter than in those led by a benevolent dictator. However, contributors who have earned the respect of the community through frequent and useful contributions tend to have a ‘louder voice’. This means that leadership figures will still emerge and those figures must, like the benevolent dictators, wield their perceived authority with care. This model of earning authority through contribution is often called the meritocratic model.

The meritocratic model tries to ensure that new entrants to the community feel engaged and involved from the very first day. It gives everyone a voice and rewards those who make valuable contributions by providing mechanisms for recognition, such as increased visibility within the project (this is discussed in more detail in our example meritocratic model). As with the benevolent dictator model, decisions are made by listening to the community and eventually taking action based on the consensus that emerges. However, in many cases there is no need for discussion, since the correct path is obvious. In this case, it is sufficient to simply state one’s intentions and allow time for someone to object. In the absence of an objection, it is assumed that the community agrees with the proposed action. This is sometimes called ‘lazy consensus’.

The effect of lazy consensus means that, in practice, most decisions within a meritocracy are made in a way that is very similar to that of projects operating under a benevolent dictator model. That is, once someone has earned the merit to allow them to define a course of action, the use of lazy consensus allows them to just go ahead and take whatever action they want. Just as a benevolent dictator could do. In the case of a disagreement that cannot be resolved by discussion the two models differ. In most meritocracies, a vote is called in order to break these deadlocks; in such votes, all members of the community have a vote, but only those community members who have earned enough merit will have a veto.

How to draw up a governance document

Once you have established which model you will adopt, you need to draw up a governance document that details the process by which decisions are made and contributions are recognised. Below we present a general framework for creating a project governance document. It describes the main areas that need to be addressed, and explains why each section is important. At the end of this document, you will find links to example governance documents that illustrate the range of options available to you when designing your own model. It is also worth noting that projects can work with OSS Watch on developing a governance model; [contact us for more information.

The main sections of a typical governance document include:

  • Overview
  • Roles and responsibilities
  • Support
  • Decision making process
  • Contribution process

We’ll discuss each of these sections below. For examples of how they might look, see our example Benevolent Dictator Governance Model and Meritocratic Governance Model.

Overview

This overview section of the governance document should provide a brief summary of the project objectives and how it is managed, linking forward to each individual section as appropriate. It should also provide key information, such as the licence covering the project outputs, who the copyright holder is, and how users can become involved with the development of the project.

The overview should be short, as the objective is to give people an immediate understanding of what is expected of them if they wish to engage with the project.

Roles and responsibilities

This section describes the formal roles and their authority within the project. It should also describe the level of commitment required and how one seeks to engage in each role. The goal of this section is to make it clear who manages the project, who can contribute, how they may contribute, and how they should behave if they wish to directly influence the project.

The defined roles may be quite general, such as ‘user’, ‘contributor’, ‘committer’ or ‘project management committee member’, or they may be very specific, such as ‘release manager’, ‘bug manager’, ‘community manager’, ‘product manager’, and so on. Generally, the more detail provided, the more likely it is that people will be able to identify things they can do to contribute. However, be careful not to limit the kind of contributions people can make. For example, someone with the title ‘release manager’ may feel that it is not appropriate for them to assist with managing project roadmaps, which appears to be part of the ‘product manager’ role. For this reason, many projects opt for broad titles that describe a wide range of activities. For example, the tasks of managing a release and managing roadmaps might fall within a single role - perhaps ‘committer’ - and individuals within that role will self-select the activities they wish to contribute to.

Conversely, failing to give specific responsibilities to people can result in a lack of contributions in a given area of activity. This needs to be balanced against the fact that it is not always possible to instruct members of a community to carry out defined tasks, as they may not be in the employ of the project leaders. Roles are described in more detail in a separate document.

Support

This section documents support processes within the project. For most open source projects, the support channels are the main contact with users of the project. These users may become future contributors or customers of commercial support providers, and are therefore key to the sustainability of a project. An open source project must look after its users.

The support section of the governance document also describes the available support channels and how each is used. It also provides a means for preventing support from being spread too thinly across multiple channels. The risk of spreading too thinly is that it prevents a critical mass of activity occurring in a single location. As a result, the kind of self-supporting community we seek to develop in order to reduce the support overhead of the project is inhibited.

Decision making process

The way in which decisions are made is critical to the success of an open development project. A process that is too time consuming may result in decisions being deferred, thus delaying the project; worse still, the process may be ignored, thus disenfranchising part of the community. Conversely, a process that is not well defined may result in arguments about whether a decision is valid or not, again resulting in delays and splits within the community.

The efficiency and transparency of the decision making process should be the main focus of this section of the governance document. It is this process that assures potential contributors that their efforts will be handled fairly by the project and will remain of value in the future. Methods for creating the right control structure are outlined above.

Contribution process

This section documents how people should contribute to the project. It details the various types of contribution being sought and the tools available for making and managing those contributions. This section should not provide a full description of the tools, but rather a clear explanation of the process the tools are provided to support.

Clear processes relating to contribution are necessary for two key reasons:

  • to guide contributors to the project
  • to reassure potential users that the quality control and legal oversight of all contributions is sufficiently robust to produce a reliable and legally sound software output

This section of the governance document should therefore describe the expectations the project has with respect to copyrights management, coding standards and documentation. It should also describe what happens once a contribution has been made by a third party, including details of the process that is followed when a contribution is deemed unsuitable for the project.

Conclusion

Adopting a governance model and drawing up a project governance document as early as possible are critical for the creation of a successful open development project. Nothing should prevent the project initiators from documenting their model at project inception.

However, there is no need for the first version of the project’s governance model to be fully detailed; a framework setting out the starting position is sufficient. Nor does the governance document need to account for every possible future scenario. The idea is to start with a simple and manageable model that will send clear signals to potential contributors. A successful open development project needs to be welcoming to those who are likely to contribute in a way that improves project sustainability, while preventing those with incompatible needs from wasting their own time and that of the project team in fruitless engagements with the project.

In order to be effective, a governance document needs to be concise, accessible and easy to refer to. It should focus on the main aspects of the decision making structure and mechanism, but needs to be flexible enough to address the increasing complexity associated with the growth of its community and interaction with the external world.

Governance models can range from fully centralised control to fully decentralised. The ideal starting model is one that recognises the initial structure of the project and provides a clear way for third-party contributions to be made and managed within the project. Readers may find our Benevolent dictator and Meritocratic templates helpful in formulating an initial document. OSS Watch can also work with projects to create a governance document to suit their needs; [contact us for more information.

Further reading

Links

Related information from OSS Watch