Skip to content

Why consensus-decision making is better for open source projects

Many of us use consensus-style decision making in our free/open source projects such as Apache’s lazy consensus model, but often we have a practice or even a governance of having things end up in a majority-wins voting process.

In a majority-wins voting model, the dynamic is one where the dissenters are marginalized — the majority has to put the dissenting minority in the position of being a “loser” in a vote.

In a consensus-decision model with blocking, you have a situation where it becomes the duty of the entire group to take care of the dissenters’ concerns.

In general, consensus decisions force the group to focus on a compromise around the best-possible solution. When people are in the position of being a winner or a loser, the effect is to make people solidify around one of two extremes that may not represent the best possible solution.

Often achieving consensus only requires clarification of a misunderstanding or minor adjustments to the original proposal. This occurs even where no one has blocked, but the appearance of -0 (or a stand aside) will also make it clear that the original proposal might need more thought — getting a -0 from a leading thinker in a group spurs others to wonder if maybe there is more that can be done to make the proposal fully supported.

There are a lot more details to how things work in practice in a consensus-decision model, which I covered fairly well in the Appendix to the CentOS Project Board governance, quoted here:

In the CentOS Project a discussion toward a decision follows this process:

  1. A proposal is put forth and a check for consensus is made.
    1. Consensus is signified through a +1 vote.
  2. A check is made for any dissent on the proposal.
    1. Reservations? State reservation, sometimes with a ‘-1’ signifier
      1. Reservations about the proposal are worked through, seeking consensus to resolve the reservations.
      2. A reservation is not a vote against the proposal, but may turn into a vote against if unresolved. It is often expressed with an initial -1 vote to indicate reservations and concerns. This indicates there is still discussion to be had.
    2. Stand aside? No comment, or state concerns without a -1 reservation; sometimes the ‘-0’ signifier is used.
      1. This option allows a member to have issues with the proposal without choosing to block the proposal, by instead standing aside with a +/-0 vote.
      2. The stated concerns may influence other people to have or release reservations.
    3. Block? Vote ‘-1’ with reasons for the block.
      1. This is a complete block on a proposal, refusing to let it pass. A block is a -1 vote and must be accompanied with substantive arguments that are rooted in the merit criteria of the Project – protecting the community, the upstream, technical reasons, and so forth.

Block (-1) votes used as a veto are typically used only when consensus cannot otherwise be met, and are effectively a veto that any sitting Board member can utilize with sufficient substantiation.

In writing the original section of The Open Source Way, I didn’t go so far as to recommend the abandonment of the majority-wins voting method, instead I said, “Seek consensus — use voting as a last resort.” That section (unfinished) is now going to get a rewrite where I’ll definitely come down against majority-wins, and write out more of the why.

Partially I owe my improved understanding from using the consensus model in a business collective where I’m a partner, Santa Cruz Pedicab. Working with the model in the physical world made me intensely aware of the human impact of majority-wins by comparison, and convinced me it was really the backbone to a welcoming community.