“Rough consensus and running code” is the phrase that captures how the IETF makes decisions. It was crystallized by David Clark in a plenary talk at the 24th IETF meeting in Cambridge, Massachusetts, in July 1992, titled “A Cloudy Crystal Ball: Visions of the Future.” His slides, archived at MIT and copyrighted David Clark 1992, contain the line that became the community’s motto: “We reject: kings, presidents and voting. We believe in: rough consensus and running code.”
The phrase has two halves, and both matter. “Rough consensus” means that decisions are not made by counting votes but by reaching a broad sense of agreement in which the substantive technical objections have been genuinely addressed. It does not require unanimity; a small number of holdouts cannot block progress simply by refusing to agree, but neither can a majority steamroll an unresolved technical concern. “Running code” means that proposals are validated by actually building them. A specification that has been implemented and shown to interoperate carries far more weight than one that exists only on paper.
RFC 7282, “On Consensus and Humming in the IETF” by Pete Resnick, published in June 2014, sets out the philosophy in careful detail. It explains that the IETF often gauges the sense of a room by asking people to hum rather than vote, precisely to avoid turning a discussion into a tally. Its central principle is that “lack of disagreement is more important than agreement”: the goal is not to find what most people want, but to ensure that all the technical objections have been heard and resolved. As the document insists, “hums should not be used as votes.”
The approach was forged in contrast to the more formal, committee-and-ballot style of traditional standards bodies, and it was a defining feature of the internet community during the so-called protocol wars, when the IETF’s pragmatic, implementation-first culture competed with the formally specified OSI model. The TCP/IP protocols won in part because they ran, and ran widely, before they were ever blessed by a formal standards process.
As a piece of engineering culture, rough consensus and running code has proven remarkably durable. It encodes a healthy skepticism of both authority and paperwork: trust what works and what knowledgeable people broadly agree on, rather than what is decreed or merely voted through. The idea has spread well beyond the IETF and is frequently invoked wherever open technical communities prefer demonstrated results over formal process.