The REALISE project community explorer introduces key topics for nurturing a healthy community that supports open innovation in software. The topics cover community structure, operation and management. They will help you decide how to best support your project's community. The explorer also allows you to record what topics you have covered and any choices you have made. Once you've completed the topics you will be ready to guide your project out of the REALISE Incubator with the reassurance you have addressed the basics required for community health. Please note that the explore does not save your settings between page visits.
The Community Explorer is created using jQuery Mobile (jQm) in order to provide a compelling and accessible user experience on many mobile devices as well as desktops. However IE doesn't display jQm well, so while the community are working on improving support, IE users might like to try Firefox, Chrome or Opera .
In order to reach sustainability a project needs to attract a diverse community of users and developers.
Reaching such diversity requires minimal barriers are presented to new and existing users and developers, which in turn requires transparency, ease of access, and clear documentation of processes.
Attention to common community tools, documents and processes is combined with community management
A key step is the creation of governance document that clearly describes the community structure as well as the management and decision making processes to be followed by the community.
Keep these principles in mind as you work through the explorer topics. The tool will also be useful when reviewing your community as your project matures.
The size of a project will influence several of your community management choices and it is sensible to have a realistic concept of the size. There are several ways to measure project size such as number of participants, complexity of deliverables or diversity of either.
Perhaps a single developer or small code base.
Many developers or complex code base.
Community members interact with a project in various ways and their usual interactions can be used to define a number of common roles. These roles can then be used to understand and define the community structure and the various processes to be followed. Common roles include:
A project needs to maintain a clear vision and direction in order to stay healthy and this requires leadership. Leaders will need to continuously consider and carefully respond to the opinions of all community members and this is achieved through open inclusive discussion. However when final decisions have to be made the project needs to know who can make them.
An individual has the final say in all decisions. Perhaps a small project with single developer. In larger projects the person taking this roles is called a 'Benevolent Dictator' . Projects may start with this model and later change as the size increases.
A group of people all having the same voting rights. Note that it is possible to have a committee of one, and it is then possible to increase without change of mode.
A loose collection of people making decisions in variable ways.
In addition to knowing who makes decisions, a project needs to define how they are made. In order to ensure community health it is important that everyone feels their opinions are represented so it is usual for most decisions to be resolved through open discussion and debate. When this does not resolve the issue, or if the decisions are felt to be important enough, then more formal procedures are needed. A sole decision maker can make the decision while a group will invoke an agreed voting procedure. An example of such a key decision point is when to accept contributions into the repository.and another is when to promote people to roles that allow direct update of the repository.
Perhaps a small project with single developer. Also a so called 'Benevolent Dictator' who has the final say in all decisions. They are called benevolent as they will consider all parties and the project health. Projects may start with this model and change as the project size grows.
Voting is used. A common technique use is the lazy consensus which allows decisions to be made without every one responding. Formal voting is carried out and every member has a say. However only decision makers votes count in the tally (binding).
Votes are used but a final tie breaker is made by one person
Healthy communities encourage people to engage and gradually increase their level of engagement. So users are encouraged to contribute. Contributors are encouraged to progress to be able to directly update the project resources, and then to become part of the decision making processes.
All open source projects have some degree of gaining status through earning merit, however some of the roles that the project defines have a direct influence on the project and its resources. Accordingly a project needs to define the progression route and methods into those roles so as to safe guard its assets.
Privileges are bestowed from above and may be limited or unofficial. This can be seen in projects which have a benevolent dictator.
Privileges are earned and voted on by the decision makes. This can be seen in meritocratic communities.
Projects need contributions from community members in order to progress and meet the community needs. Accordingly the process for receiving, reviewing and accepting contributions must be carefully considered. Open Source licensing is dependent on copyright IP law and so the IP ownership of all contributions must be carefully managed. This will include having Contributor Licence Agreements signed by contributors.
Users require stable and supported 'products' that are easy to download & install. Developers, however, usually want to work with the latest and greatest code that includes other developer's changes. They are also content to get the source code and build. Open source projects use regular, controlled releases to meet the user demands for ease of installation, quality and stability. Each release is a frozen snapshot of the code with a declared level of quality.
A project needs to decide how releases are managed, including when, how and by whom. These details should be made public in a release procedure document.
Ad-hoc releases may be driven by milestones decided as part of planning. Such milestones may be specified by time, feature set or quality level (bugs fixed). Ad-hoc releases can also occur between regular releases in order to provide an emergency fix.
Regular releases allow users to plan for upgrades and maintenance.
They can also allow other dependent projects to synchronise their development efforts and release cycles.
This is sometimes called
Users are vital for any project and users require support with problems or requests for information etc. Each project needs to decide which channels are used for support and how these channels operation. Community support systems provide a simple and direct way for users to engage and contribute.
Only a few basic on-line community tools are required to support the above and to ensure a diverse community can grow and operate. There are best practices for setting up and operating each tool and good examples can be found by exploring successful projects.
A key decision is whether to use an existing forge or self host. Using existing forges has many benefits, especially for young or small projects
This important document describes the community structure and operation by describing the roles, decision processes, contribution process and support mechanism. These work together and define the character of the community. Governance models are often positioned somewhere between the 2 common approaches of a meritocracy and a benevolent dictator. Clearly defining the governance model allows interested parties to understand how they can engage.
Here are some resources that cover community development and management in depth: