Voting vs Consensus

I’ve been thinking a lot lately about the word “consensus” as it is used in open source, and how it relates to the notion of *voting* on decisions.

While the English word consensus has a number of nuances, it usually means “everyone more or less agrees”. The nuance usually comes up between *most* of the community vs complete solidarity and agreement on a decision. It doesn’t usually mean complete unquestioning agreement, but it means that everyone can live with the outcome.

A vote, on the other hand, draws a bright line between YES and NO, and, one might argue, creates two camps, with winners and losers, which is pretty objectively a worse outcome than everyone agreeing. As a result, many open source communities shy away from a vote, because it is divisive – in the strictest sense of the word – ie, that it divides a group into two subgroups.

There’s a lot of tension and nuance here, though. In open source, we value diversity of opinion because it creates new ideas that you don’t get when everyone is in complete agreement. So in one sense, you want to cultivate, and encourage, disagreement. But you also, eventually, need to make a decision when those disagreements are intractable, and you can’t say yes to both options.

Furthermore, insisting on universal agreement forces some people to pretend to agree, in order to get along, or because there is pressure to achieve this artificial consensus. Voting allows people to express their dissent, yet still move on for the good of the entire community.

This is especially true when it comes to non-technical decisions, where there is not a clear, verifiable, testable, correct answer. And, frequently with non-technical decisions, reverting that “patch” later on is difficult, expensive, or even impossible.

Take, for example, naming a project. There is no right answer. (There may be some obviously wrong answers.) The answer cannot be tested or verified. And once decided, reverting that decision would be expensive, by many measures of expense, both socially, and in terms of work that would need to be done. If community members are deeply invested in their ideas, it may be time for a vote.

As observed in a private conversation earlier today, smart people should see the way the tide is running, and concede early to avoid deepening dissention. But, at the same time, people who see their position as objectively correct (hyperbolically, good vs evil), rather than merely being an arbitrary opinion (hyperbolically, red vs yellow) have an obligation to advocate for that position. This can be hard to disambiguate, when various people disagree about which category the disagreement falls into.

You should not vote “too soon”, nor should you vote “too late”. Too soon would mean don’t vote while there seems to be progress towards consensus. Too late looks like when there is no progress, and everyone is simply reiterating their arguments. MUCH too late would look like when the discussion starts to become angry or personal – that’s a clear indication that you’ve waited too long.

Another critical aspect is that once the vote has taken place, those who were not on the “winning” side must be willing to accept that this is, in fact, the desire of most of the community, and then move on, for the good of the community. Your dissent is noted. Your idea was considered. But another idea “won”, and it’s time to accept that and move on. This is exceptionally hard, but it is an indication that you’ve put the good of the community over your own personal victory. Accepting defeat is sometimes the most community-centric thing that you can do.