This document has been superseded by a briefing note the OSS Watch website.

A governance model describes the roles project participants can take, and the process for decision making within the project. In addition it describes processes for communicating and sharing within the project team and community. It is the governance model that prevents an open source project from descending into chaos, and it is the governance model that describes the ground rules for participation in the project. This document highlights the challenges of adopting a governance model in open source projects and describes the key areas such a model needs to cover.

Why does a project need a governance model?

A clear governance model allows potential contributors to understand how they engage with the project, what is expected of them and what protections are provided to ensure their contributions will always be available to them. It also describes the quality control processes that help assure potential users of the viability of the project. There are almost as many variations on open source management strategies as there are open source projects. It is therefore critical that you clearly communicate your policies and strategy to potential users and developers of your product as it is one of the most important steps towards sustainability through open development.

Governance models range from the centralised control of a single individual or organisation (benevolent dictatorship) to distributed control awarded in recognition of contributions (meritocracy). It is possible to create a governance model at any point along this spectrum. Similarly, it is possible to move along this spectrum as the project matures. The table below provides a few examples of common models (this table is derived from work presented in Open Source Software: Is It Worth Converting?)

Type

Objective

Control Style

Community Structure

Examples

Exploration Oriented

Sharing innovation and knowledge

Cathedral-like central control

Project leader, many readers

GNU, Perl, Linux Kernel

Utility-oriented

Satisfying an individual need

Bazaar-like decentralised control

Many peripheral developers, peer support to passive users

GNU Linux (excluding Kernel)

Service-oriented

Providing stable service

Council-like central control

Core members instead of project leader, many users that develop systems for end users

Apache, PostgreSQL

Governance Models In Use

This document describes the content of a typical governance model. However, it may first be useful to examine a few examples that can be found in the existing open source projects.

Firstly, lets glance at the Ubuntu model. This model focuses on describing the structure of the community and the responsibilities each part of that structure have. 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 the governance model, but the technical management processes are clearly documented.

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

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 as such is an example of the kind of model that has been found to work in the academic environment. The Taverna model, like the Ubuntu and ASF models focus on project structure and management processes.

Barriers to adopting a governance model

There are a number of reasons why projects fail to define a governance model in the early stages. Perhaps the most common are:

Each of the first three concerns could, potentially, be valid but they need not be. A governance model need not be complex, nor need it be rigid, as one of its purposes is to define how and when project management would be willing to allow others to influence strategy. The final concern, that the project is too young is always invalid. This is because any potential contributor to the project needs to know how to contribute efficiently and effectively, and they need to know how their contribution will be handled. Without clear guidance on these matters most people will walk away rather than join an immature project. However, if they are shown that they can help guide the project as it matures, they may decide to stay. A single external contributor may have a major affect on the sustainability of your project, you simply cannot afford to risk losing that contributor as a result of a small saving of effort in the early stages of your project.

In order to further encourage the drawing up of a clear governance model as early as possible we will briefly explore each of the above concerns.

"Red tape"

Some people perceive that governance models are nothing but "red tape". Whether this is true or not they are or not depends on how carefully the model drawn up. The goal is to make it simple but effective. A governance model 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. It is this transparency that encourages third parties to join the project. They can see how the project is run and can predict how the project will react to their contributions before any significant effort is expended on that work.

A successful governance model is designed to make the process of making and evaluating third party contributions easier, not harder. It removes the uncertainty that can lead to wasted time for both parties in the exchange.

[FIXME: small projects do not see the need for a governance model, there is noone on the outside so why worry about it? The solution is to start with the lightest possible governance model one can, e.g. PI has veto and delegation rights, lazy consensus rules. This can then be evolved over time into either a clearly defined BD model or a meritocratic model, or wherever on the scale the project decides to settle].

Loss of flexibility and agility

The fear that a governance model will constrain the project as it adapts to a changing environment exists because there are many poorly governed projects that display this behaviour. However, 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, whilst ensuring that the core project team do not lose control. The issue of control is discussed in the following section, here we will focus on flexibility and agility.

Since it is not possible for a project to be all things to all people, the goal of a sustainable project is to be as complete a solution as it can be for its core stakeholders, whilst still being of interest to other interested parties. The project must be ready to accept input from unexpected quarters, and must be able, wherever possible, to accommodate their needs. Doing so significantly increases the pool of resources the project can draw upon in its quest for sustainability. However, trying to be all encompassing will nearly always result in failure.

The solution is to adopt a governance model that provides mechanisms for clearly defining and enforcing the boundaries of acceptability within the project. It is designed to allow the project leaders to prevent seemingly random explorations of new directions, whilst at the same time allowing complimentary work to occur under a unified banner.

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, like all the concerns addressed here, a well written 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 bean all decisions are made by the community as a whole (e.b. The Apache HTTPD Server and DoJo).

It is worth noting that 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. Therefore the illusion of control is only ever as real as the support of the community who respects the leadership of those in control. Consequently, regardless of the contents of the governance model, it is possible for those who fundamentally disagree with the controlling influences to start a new project. It is therefore not the role of a governance model to prevent this. The models role is to clearly define what influence a potential contributor is likely to have over a projects strategic direction. This will impact on the kind of contributor the project can attract and will encourage those not in agreement with the strategic direction of the project to go elsewhere and pursue their own strategy.

The project is too young

Finally, we return to the issue of a project being too young to attract third parties and therefore it not need concern itself with how to manage them. All projects have to start somewhere, and it is not uncommon for projects to feel that a governance model is not yet necessary.

It is our contention that it can never be too soon to defin a suitable governance model. Without one, the chances of third parties contributing are considerably reduced. This is for a number of reasons. Firstly, they will not know how to contribute; secondly, they will not be sure what happens to their contribution; thirdly, the project will not look serious about engaging with third parties; finally, there is no visible assurance that their contributions will be managed in such a way that they will remain of value to the original contributor.

Since a project never knows when a contributor might stumble upon them it is important to be ready from the earliest possible date. Each missed opportunity to attract contributors means a missed contribution to the sustainability of the project. The first contact between a project and a contributor is the most important. A bug fix provided by a third party may result in multiples of people not being affected by the bug, which results in more users, which in turn encourages the first contributor to continue their work, thus producing more contributions.

Therefore a project can never be too young to adopt a governance model.

How do open development projects make decisions?

In the following section we discuss what needs to be included in a governance document. This section first discusses decision making in open development projects. This is a key part of a governance document and is central to many of the fears examined in the previous section. Decision making in an open development project appears, at first site, to be a complex issue. Most of us have sat on committees where reaching an agreement has, on occasion, been extremely difficult. It is therefore worth taking a little time to recognise that a number of streamlined decision making processes have emerged in open development communities that prevent deadlock situations occuring.

The two most commonly found decision making techniques within open development projects are a centralised process and a decentralised one. Nearly all projects will start life with a centralised model through necessity and familiarity. A new project will normally have a small number of initial contributors, perhaps as few as one. In a small team centralising decision making is easy and is akin to what is found in non-open projects. As a result all decisions are made by this small team. However, as a successful project grows more and more people will be willing to contribute to the objectives of the project. As this growth occurs the decision making process may need to evolve.

Project founders who maintain individual lead throughout the entire life of the project are sometimes called 'benevolent dictators'. A benevolent dictator is responsible for providing 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 interest of the project, rather than of any particular individual or institution. A good benevolent dictator needs to be able to balance any conflicting requirements of the community members. This is not an easy task, and before setting oneself up as a benevolent dictator one should ask "Can I be a good benevolent dictator?"

Whilst 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 are able to fully understand the full details of a problem being addressed. Consequently the benevolent dictator will refrain from making decisions in areas they are less expert in. As the project grows in size and scope these areas of uncertainty will grow and so the dictator will feel unable to make a decision more frequently.

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 Linux recognises that by taking sides he will influence those who are undecided and thus influence 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 a decision this can result in sub-optimal decisions.

It is therefore better, in a medium to large project, to allow discussion to proceed and only indicate a decision in the unlikely event that there is no visible consensus emerging and a decision has to be made in order to proceed. Thus, the dictator seeks 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 model for a centrally controlled project it is important to indicate that whilst the decision making power is centralised the distributed community is expected to inform that decision through debate. Failure to do this will result in some individuals turning their back on the project fearing that there is little opportunity for them to bring their expertise to the project.

Whilst some projects maintain a tight control on the decision making process others feel it is more effective to allow the community as a whole to make decisions. In this case, an increased need for a formal decision making process occurs since there is no one person able to break a deadlock. The membership structure in such communities looks flatter than in those led by a benevolent dictator, and it often is. However, contributors who have earned the respect of the community through frequent and useful contributions tend to have a "louder voice", this is often called the "meritocratic model".

The meritocratic model is designed 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 formal responsibility for 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, this is sometimes called "lazy consensus".

Lazy consensus means that most decisions within a meritocracy are made in exactly the same way as they are in the benevolent dictator model. It is only in the case of a deadlock that the two processes differ. In a meritocracy a vote is called in order to break deadlocks. In the case of a vote only members of the community with enough merit have a vote.

How to Design a Governance Model

This section presents a general framework for creating a project governance document. It describes the main areas that need to be addressed, along with an explanation of why each section is important. At the end of this document we provide 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 OSS Watch are [here to assist mailto:info@oss-watch.ac.uk] UK higher and further education projects developing a governance model.

The main sections of a typical governance document include:

  1. Overview
  2. Roles and responsibilities
  3. Support
  4. Decision making process
  5. Contribution process

We'll discuss each of these sections below. For examples of how they might look see our example BenevolentDictatorGovernanceModel and MeritocraticGovernanceModel.

Overview

This section should provide a brief summary of how the project is managed linking forward to each individual section as appropriate. It should provide key information, such as the licence the software is available under, who the copyright holder is, and how users can become involved with the development of the project.

This section should be short, 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 within the project, along with any authority each role carries. It should also describe the level of commitment required of people in each role, and how one seeks to engage in each role. The goal of this section is to make it clear who can contribute and how they may contribute, who manages the project and how people 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" etc. Generally the more detail is provided, the more likely is that people will be able to identify things they can do to contribute. However one should be careful not to limit the kind of contributions people can make. That is, 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 the "Product Managers" job. For this reason, many projects opt for broad titles that describe a wide range of activities, so in this example the act of managing a release and managing roadmaps would both fall under 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, however, 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 owners.

There is no right or wrong answer as to the way to define roles and responsibilities. In general we feel specific titles are more restrictive than broad titles with clearly defined (optional) responsibilities.

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. It is these users who may become future contributors or customers of commercial support providers, either way it is users who are key to the sustainability of a project. An open source project must look after its users. The support section of the governance model describes the available support channels and how each is used. As well as defining how the channels are used the governance model provides a means to prevent support being spread too thinly across multiple channels. Spreading too thinly prevents a critical mass of activity occurring and thus the kind of self-supporting community that that reduces the support overhead of the project team does not evolve.

Decision making process

How 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, or worse still, the process being ignored, thus disenfranchising a 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 openness of the decision making process is the main focus of this section. 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. However, it is a myth that open source projects need to allow anyone to make a decision, in fact they certainly should not just hand out decision making power without good reason. Methods for creating the right control structure were outlined in the previous section "How do open development projects make decisions?"

Contribution process

This section is designed to document 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 is not intended to be a full description of the tools, but rather a clear description of the process the tools are provided to support. Clear processes of contribution are necessary for two key reasons; the first is to guide newcomers to the project; the second is 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 therefore describes the expectations of the project has with respect to copyright clearance, coding standards and documentation for any contribution. I also describe what happens once a contribution has been made by a third party along with an overview of the review processes and feedback mechanisms that will ensure the contributor is able to understand why a contribution is rejected and what changes will lead to acceptance, if that should be the case.

Conclusion

Adopting a governance document as early as possible is critical for the creation of a successful open development project. No barrier should prevent the project initiators from documenting their model at project inception. There is no need for the first version of the projects governance model to be fully detailed, a framework setting out the starting position is sufficient. The governance model certainly does not 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 whilst 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 will need to be concise, accessible, and easy to refer to. It will focus on the main aspects of the decision making structure and decision making mechanism but will need to be flexible enough to address the increasing complexity associated with the growth of its community and interaction with the external world.

There is an infinite number of potential governance models ranging 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 example BenevolentDictatorGovernanceModel and MeritocraticGovernanceModel helpful in formulating an initial mode. OSS Watch are also happy to assist staff in UK HE and FE institutions when creating a governance model to suit their projects needs.

OSSWatchWiki: GovernanceModel (last edited 2013-04-15 13:56:20 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.