1.    Introduction

Clear and transparent governance is a key part of any open development project. It defines the rules of engagement within the community and describes what level of influence a community member can expect to have over a project. In addition, it enables members to decide their level of involvement with that community.

The community encourages loyalty rather than legalities. Members are free to take the code and create alternative projects as long as this is for the benefit of the community, rather than for a single individual or company.

As you may see in Voting section, not everyone has a binding vote. This happens in order to give the decision making authority to those who share a common vision and, just as importantly, are willing to work towards that shared vision.

2.    Roles And Responsibilities

For each role listed below you may find more details in Structure and Roles section.


Anyone who has an interest in the community may become a member. Actually, there is no community if it does not have purpose and this is given by its members.

Users who continue to engage with the project and its community will often become more and more involved. Such users may find themselves becoming contributors.


Community members who wish to take part in concrete ways in the community running may become a contributor, and contributions can take many forms. All contributions are to be submitted as patches that should be validated by committers or project maintainers.

Contributors engage with the project through forum, blog, Idea box, projects, and mailing lists. There is no expectation of commitment to the project, no specific skill requirements and no selection process.

Contributors can be nominated as committers as soon as they proved their attachment to the community projects and willingness to help in reaching their goals.


Committers are community members who have shown that they are dedicated to the continuous development of the projects through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.

Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player.

Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way.

It is important to recognize that committership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the Technical Committee in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.

A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become project maintainer, and thus part of the Technical Committee.

Technical committee

The technical committee consists of all project maintainers. Its main role is to set a vision and strategy for the community, as a whole, especially from the technical and business point of view, to decide upon matters that cannot reach a consensus among the members of the community. Its members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.

Members of the technical committee do not have significant authority over other members of the community, although they are to vote on new committers. They have access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.

The technical committee leader is voted for by its memners. Once someone has been appointed leader, he/ she remains in that role until choosing to retire, is removed by a majority vote. He/ she  has no additional authority over other members of the technical committee: the role is one of coordinator and facilitator, but also to ensure that all governance processes are adhered to.

Steering committee

This is a group of decision makers with the role of a moderator: the instrumental inspirational authority, expected to draw both the development vision and the guidelines of the community.

3.    Support

All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.

4.    Contribution Process

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For more details, please visit section How to Contribute and Structure and Roles.

5.    Decision Making Process

Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced member. Most of these discussions will take place in public spaces (such as forums). It may happen that some sensitive discussions will occur on a private area (such as private mailing list).

In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.

Decision making typically involves the following steps:

  • Proposal
  • Discussion
  • Vote (if consensus is not reached through discussion)
  • Decision

Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should post a proposal on available forums (built within,, on the issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.

For more details on how a proposal may reach consensus and be approved, please see  Types of approval.


Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. For more details please see section Voting.