---
name: Implementer Consensus
slug: implementer-consensus
type: process
status: unstable
version: 0.indefinite
released: "whenever two browser vendors agreed on something"
maintainer: "the web, loosely"
dependencies:
  - patience
  - competing-implementations
  - good-faith
  - shared-pain
license: "Unwritten. Understood."
tags:
  - standards
  - governance
  - web-platform
  - collective-intelligence
  - folklore
---

Implementer Consensus

What it actually is

The moment when multiple independent parties, each with strong reasons to disagree, stop disagreeing enough to ship the same thing.

How it works

No one owns the trigger. The process looks like this:

A specification exists, partially. It has gaps. The gaps are load-bearing.
Two or more implementers write code against the spec independently.
The code disagrees. Tests reveal this. Sometimes users reveal this first, loudly.
Someone files an issue. The issue attracts opinions. The opinions attract counter-opinions.
A meeting happens. Or a thread. Possibly both, sequentially, covering the same ground.
One party concedes something small. Another party concedes something adjacent.
Nobody is happy. The spec is updated. Tests are written. The thing ships.

This is consensus. It does not feel like agreement. It feels like exhaustion that has been formatted correctly.

Features

Interoperability: things built by strangers work together, which is genuinely remarkable
Legitimacy: decisions are harder to reverse when multiple implementers made them
Distributed accountability: no single party can be blamed for the outcome (this is a feature to some, a bug to others)
Slow: yes, intentionally, because fast consensus is usually just one party winning quietly

Known bugs

Can be captured by the parties with the most engineers attending the meeting
"Rough consensus" sometimes means "the loudest objectors gave up"
Consensus on behavior does not imply consensus on rationale, which causes the same argument to recur in three years
silence is frequently misread as agreement
A spec can achieve implementer consensus while remaining completely misunderstood by developers who use it

Error codes

ERR_CONSENSUS_NOT_REACHED       One party ships anyway. See: browser history.
ERR_FALSE_CONSENSUS             Everyone agreed on the words, not the meaning.
ERR_CONSENSUS_DECAY             Was true in 2018. Two implementations have since diverged.
ERR_QUORUM_INSUFFICIENT         Only one implementer showed up. Counts as a monologue.
WARN_CONSENSUS_BY_ATTRITION     The dissenting party stopped attending. Handle with care.

Edge cases

When exactly two implementers agree and both are owned by the same parent company, consensus is a different shape
A working group can ratify consensus that does not actually exist among shipping code
Sometimes the community reaches consensus first and implementers follow. This is rare and should be celebrated when it occurs.
A single dominant implementation creates a gravity well. Other implementers often achieve "consensus" by orbiting it.

FAQ

Is this the same as a vote? No. Votes have counts. Consensus has vibes that get written down.

Who decides when consensus is reached? The chair, usually. Or the passage of time. Often both.

Can one company block consensus indefinitely? Technically no. Practically: ask WebSQL.

What happens when consensus breaks down after shipping? web compatibility becomes the new spec. The original document becomes archaeology.

Changelog

Pre-2000: consensus meant "Netscape and Microsoft fought and someone lost"
2004-2012: the WHATWG era. Consensus found by shipping first and documenting second.
2015-present: process matured. Slower. More principled. Still occasionally on fire.

drafting spec…