Consensus does not mean we all agree

I have had a number of colleagues come to me over the years since I've worked in open source expressing frustration and almost hopelessness as they found themselves trying to obtain consensus for their open source contribution.

What I tell them is that just because the community is consensus-based does not mean everyone has to agree with you. 

Here's one definition of consensus I found on the web: General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests.  My dictionary on my Mac makes it even simpler: general agreement.
 
The key word here is general agreement.  I also like the phrase "absence of sustained opposition in substantial issues."

Many people get frustrated working in open source because it feels like any attempt to make a substantial change gets bogged down in numbing committee-like discussions.

Now, I won't deny it, there is overhead in working with open source.  You do need to get feedback, and make a best effort to address comments or concerns.

But that doesn't mean you iterate and iterate and iterate in some Sisyphean nightmare trying to get everyone to accept your change, or that you hunker down and make a change you disagree with. 

If you're a committer, you take the feedback, incorporate what makes sense to you, and if there is absence of sustained opposition, you check it in.  If you are not a committer, then all you need to do is find one committer who supports your change and they can check it in for you.

In the Apache model, sustained opposition is in the form of a veto.  A veto is taken very seriously - if you veto, you had better have a very good reason, and you had better offer an alternative. 

In the OpenSolaris ARC model, reviewers provide comments in the form of TCAs (Technical Change Advised) and TCRs (Technical Change Required).  It's only the TCRs you have to worry about.  Your change won't be accepted withough addressing the TCRs, and generally there are few if any TCRs.

I like the TCR/TCA model because it (a) explicity identifies which issues are causing you to veto a change and (b) requires you to be very clear about what needs to change, rather than just saying "-1".

I learned the principle of "consensus does not mean we all agree" the hard way.  When I was new on the Apache Derby project (my first open source project) I spent three months trying to get agreement on a change that would allow sharing of code between the network-based JDBC driver and the embedded JDBC driver.  It was insane.  I would try to please one person or group, and then another set of people would complain, back and forth.  Finally I got a private email from one of the veterans on the project who said "you're never going to make everyone happy, David.  Nobody's threatening to veto.  Just check it in."

Oh.

So now I offer the same advice to people when they complain to me that they feel if they have to bend over backwards for person X or person Y or they say something like "OK, fine, I'll do it your way, but I don't like it."  Relax.  Consensus does not mean we all agree.  Just check it in.