Rough Consensus
At the 24th IETF meeting in Cambridge, Massachusetts, July 1992, Dave Clark gave a plenary presentation titled “A Cloudy Crystal Ball.” One slide became a defining credo: “We reject: kings, presidents, and voting. We believe in: rough consensus and running code.”
Clark had been chief protocol architect of the internet from 1981 to 1989 and chaired the Internet Activities Board. He knew how decisions get made when the stakes are high and the participants are distributed.
Rough consensus: when the room hums assent, not when everyone explicitly agrees. When objections have been heard and addressed, even if some people still disagree.
This is profoundly different from both voting and consensus:
Voting counts heads. 51% wins. Minorities get overruled.
Consensus requires everyone to agree. One holdout blocks everything.
Rough consensus requires that objections be addressed, not that everyone be satisfied. The question isn’t “does everyone agree?” but “can anyone not live with this?”
The “running code” part matters. Ideas get tested against reality. Working implementations trump theoretical arguments. If you think the design is wrong, build something better.
Lawrence Lessig called this credo, in 1999, “a manifesto that will define our generation.”
This approach built TCP/IP, DNS, HTTP — the protocols that run the internet. Progress over perfection. Working systems over complete agreement.
Voting gives you winners and losers. Consensus gives you paralysis. Rough consensus gives you something that ships.
Go Deeper
Books
- Where Wizards Stay Up Late by Katie Hafner & Matthew Lyon — History of the internet’s creation. How decisions actually got made.
- Code by Lawrence Lessig — On how internet architecture embodies values.
Essays
- RFC 7282 “On Consensus and Humming in the IETF” — The actual IETF document explaining rough consensus. Short and readable.
- Dave Clark’s original “rough consensus and running code” slides are archived online.
Related: [[bricolage]], [[galls-law]], [[emergence]]