Healthy open source communities usually include a wide range of people with different ideologies, goals, values, and points of view—from anarchists to CEOs of major corporations. The normal approach for making decisions that affect the entire community should be an attempt to reach consensus through discussion; however, what if you’re attempting to make a decision that is critically important, but there are irreconcilable differences in the community?

The Xen Project community had such a decision to make in the wake of the XSA-7 security issue about the project’s security policy. We knew beforehand that there was unlikely to be consensus, so we thought carefully about how we could approach the discussion.

Our main goals were to find a “center of gravity” of the community preference, and to make sure that the people who didn’t get what they wanted felt like their voice was heard and taken into consideration. In this article, I’ll briefly summarize my conclusions from that experience.

1. Have a clear fall-back in case consensus is not achieved

When communities form, decisions are usually made by simple discussion and agreement. There are no formal procedures for making decisions in the absence of consensus, because it’s seen as heavyweight and unnecessary. Indeed they are unnecessary, until you reach a decision for which consensus cannot be reached. Then having a clear way forward is critical.

This way forward could be entrusting such decisions to a “Benevolent Dictator for Life,” or a majority vote of committers or other community members, for example. Whatever your community chooses, make sure that before you start your discussion, everyone knows what will happen if the discussion fails to reach consensus, and make sure that that decision-making process is one you can trust. Knowing what the fall-back plan is changes how people argue.

In the Xen Project, at the time of XSA-7, our founder had recently faded from the scene, and we were just in the process of writing down our governance documentation. So we added a clause that said that in the event the community could not come to a decision, the committers would vote on the issue.

2. Start with a discussion in your normal forum (but don’t stop there)

Open source lives on online discussions, whether on email lists, forums, or bug trackers. For most purposes, these work well. But, for major decisions affecting the entire community, they have several weaknesses.

List discussions are unlikely to give a clear picture of the community as a whole for several reasons. They favor people who like to argue, those who are more articulate or have more experience in English (or whatever language the discussion is in), and those who feel like they’re in the “in” crowd and will have a popular opinion. Finally, they hide how many people are in agreement with someone who speaks up.

With this in mind, use the discussion to explore different sides of the issue. Raise awareness of the discussion by a blog post (if appropriate) to make sure that the entire community is able to weigh in. If you still don’t have consensus, then after the major factions have emerged, move on to the next step.

3. Run a survey

The goal of a survey is to get a picture of how the community as a whole feels about the different options. Start by summarizing the important options people were advocating in the discussion. Then for each of these options, ask people to choose one of four answers:

• This is a terrible idea and I would argue against it.
• I’m not happy with this idea, but I wouldn’t argue against it.
• I’m happy with this idea, but I wouldn’t argue for it.
• This is a great idea, and I would argue for it.

We gave the option for the survey to be anonymous, but said that if community members included their names, their selections would be given more weight.

4. Identify the “center of gravity” of the community opinions

If you have one option that has all “this is a great idea” votes and no “this is a terrible idea” votes, then you’re done. If not, look for the option that seems to be the best compromise for everyone involved.

This may take a bit of digging. Don’t look only at aggregate numbers; if people oppose an idea, look at what they favor instead. In our case, there was one option that had a number of “this is good” and “this is great” votes; and the people who voted “this is terrible” voted that way for opposite reasons—about half wanted the most restrictive option, and the other half wanted the least restrictive option. People opposing it for opposite reasons indicated to us that it was probably in the center of the community opinion.

5. Write up a concrete proposal to which people can give feedback, then use the fall-back decision to decide on it

Based on the results of our survey, I wrote up a concrete proposal for how to change the security policy and posted it to our mailing list. We held a formal vote of committers, it passed unanimously, and our community got back to doing hypervisor development. No major disruptions happened as a result.

For a more complete description of the issue, and how the Xen Project ran the discussion and did the analysis, attend George’s Marking Community Decisions Without Consensus talk on August 22nd at LinuxCon in Toronto.