Rough Consensus

🎵 Origins & History
⚙️ How It Works
🌍 Cultural Impact
🔮 Legacy & Future
Frequently Asked Questions
References
Related Topics

Overview

Rough consensus emerged in the early 1990s within the Internet Engineering Task Force (IETF), crystallized by David Clark's iconic 1992 mantra: 'We reject kings, presidents, and voting. We believe in rough consensus and running code.' This philosophy contrasted sharply with the bureaucratic International Organization for Standardization (ISO) processes during the Internet-OSI wars, favoring pragmatic engineering over formal votes. The IETF, evolving from the Internet Activities Board (IAB) in 1986, adopted this to standardize protocols like TCP/IP amid explosive internet growth, rejecting the OSI model's rigid hierarchy.

⚙️ How It Works

In IETF working groups, chairs assess rough consensus through informal methods like show-of-hands or the legendary 'humming'—where participants hum to indicate support, anonymizing votes to prevent bandwagon effects as detailed in RFC 7282 by Pete Resnick. It's not majority rule; 51% fails, but 99% excels, requiring reasoned explanations for dismissing objections, unlike W3C's stricter 'substantial support' model. This ties directly to 'running code,' prioritizing implementable prototypes over endless debate, influencing standards development in bodies like the World Wide Web Consortium (W3C).

🌍 Cultural Impact

Rough consensus has profoundly shaped internet culture, enabling interoperable standards that power Google, TikTok, and ChatGPT without corporate lock-in from players like Cisco or Microsoft. By fostering competition through generic protocols, it avoided vendor biases seen in early MySpace Music or proprietary ISO efforts, promoting open source ethos akin to GitHub and Linux Foundation projects. Its rejection of unanimity prevented single vetoes, echoing libertarian vibes in 4chan communities and Reddit's upvoting-downvoting mechanics.

🔮 Legacy & Future

The legacy of rough consensus endures in IETF's RFC process, but debates rage over its scalability in a post-Snowden era amid Web3, Polygon zkEVM, and AI-driven standards like those from OpenAI. Critics argue it overlooks ethical goals beyond functionality, as noted in evolutions beyond David Clark's creed, potentially clashing with EU regulations or Belt And Road Initiative tech diplomacy. Future adaptations may integrate principles from Khan Academy's collaborative learning or scenario planning in complex systems like SLAM Technology.

Key Facts

Year: 1992
Origin: Internet Engineering Task Force (IETF), USA
Category: technology
Type: concept

Frequently Asked Questions

What exactly is 'rough consensus'?

Rough consensus, as defined in IETF practices and RFC 7282, is general agreement without requiring unanimity—typically 80-90% support where objections are addressed or dismissed with reasoning. It's judged by chairs via humming or hands, explicitly rejecting 51% majorities or single vetoes, differing from W3C's model by emphasizing 'no sustained opposition' from key stakeholders.

How does humming work in IETF meetings?

Humming anonymizes opinions: the chair proposes an idea, participants hum loudly for agreement or silence for opposition; volume gauges support without identifying speakers, preventing social pressure seen in hand votes. Detailed in RFC 7282 by Pete Resnick, it's a tool for rough consensus, not a vote, and can be appealed to area directors.

Who coined 'rough consensus and running code'?

David Clark coined the phrase in his 1992 IETF speech, capturing the ethos against kings, voting, and bureaucracy in favor of pragmatic engineering. It contrasted IETF's success with ISO's failures, prioritizing working prototypes like TCP/IP over paperwork.

Why avoid unanimity in standards bodies?

Unanimity allows one intransigent blocker to halt progress, as critiqued in IETF docs and Mark Nottingham's writings; rough consensus ensures debate resolves valid concerns while advancing robust standards for interoperability across Google, TikTok, and beyond.

Contents