IETF broke the OSI-TCP/IP deadlock not by voting but by counting running code

the problem

OSI, backed by governments and telephone monopolies, was the 'official' standard; the volunteer-built internet protocol looked doomed

background

what everyone would do

The textbook response to a standards conflict is to out-organise the rival at the formal table — fight for votes in ISO, secure government mandates, lobby the purchasers who are legally bound to buy OSI kit. All of that was available to the OSI camp and none of it worked for the internet side, which had no delegates, no mandates and no seat at the official table to begin with.

what they saw

A standard is not won in the standards body — it is won in the field, by whoever is already running. Legitimacy follows working code, so they changed who wins from ballots to deployments: not 'who is right?' but 'what is already running?'

the move

Instead of contesting OSI on its own formal turf, the internet engineers refused to vote at all. By 1992 the IETF had made explicit a governing principle David Clark named in a talk that year: 'We reject kings, presidents and voting. We believe in rough consensus and running code.' A standard was settled not by a yes/no ballot but by whether enough people had actually built and run it — the code in the field, not the number of delegates in the room, was the arbiter.

why it works

Rough consensus and running code works because it re-routes the decision from an arena the challenger cannot win (official committees, procurement mandates, votes) to an arena it dominates (working implementations already spread across thousands of networks). A formal standard is finished only on publication, so it can always be 'not done yet'; running code is finished the moment it demonstrably works, so it wins acceptance through adoption while the rival is still being specified. Crucially, the mechanism is self-reinforcing: every new deployment of TCP/IP is itself the 'vote', so the criterion accumulates in one direction, and the formal standard's own complexity (OSI's completeness killed it — too much to finish, too little running) becomes a liability rather than a virtue.

the payoff

OSI had too much complexity and too little running code, while TCP/IP was already live on thousands of networks — so it won by adoption, not vote. By the mid-1990s TCP/IP prevailed and OSI quietly lost.

where it breaks

It fails where 'running' cannot be observed or compared — safety-critical or regulated domains that legally require a finished, certifiable standard before anyone is allowed to deploy (aviation, medical devices, finance), where an informal runner can't legally be the arbiter. It also needs one side actually to have working code: if both candidates are only paper designs, or both are half-broken, 'running code' decides nothing. And it trades away rigor and interoperability guarantees that a formal process would have delivered; that cost is acceptable on the open internet but can be fatal where broken implementations leak into the market.

what came after

Rough consensus and running code didn't just win one battle — it became the governing norm of internet standardisation, carried from the IETF into the W3C and most open-collaboration processes since. The mechanism outlived the specific protocols that first proved it.

references

1. [1]IEEE Annals of the History of Computing — 'Rough Consensus and Running Code' and the Internet-OSI Standards War (A.L. Russell)IEEE, 2006doi.org
2. [2]Computer History Museum — Networking revolution: the protocol warsComputer History Museum, 2000computerhistory.org

keep it

same kind of clever

• 1983 · ARPANETOne flag day put every network on TCP/IP and made the Internet
• 1956 · Malcom McLean / ISOOne steel box replaced the longshoreman's back and remade world trade
• 1700 · Asante Empire (gold-weight system, mrammuo)Asante traders weighed gold one way among themselves and another way with Europeans