Five Times Versus Twenty Per Cent
Open the edge of a system and innovation multiplies. Open its foundations and almost nothing happens.
The question nobody asks
Arguments about whether the foundations of a technical system should be changeable are conducted almost entirely in the language of flexibility. Should the rules be alterable? Who gets to alter them? By what majority, through what process, with what safeguards? People take violently opposed positions on these questions while sharing an assumption so quiet that it is rarely stated: that what is at stake is the system’s capacity to improve.
I think that assumption is wrong, or at least it is not the interesting part. Competition does not disappear when you close off one of its channels. It relocates. If the foundations can be altered, altering them is a strategy available to anyone with resources, and it will be pursued by whoever finds it the cheapest route to advantage. If they cannot be altered, that route is shut and the same people must spend the same money on something else. The something else is building.
This is not a claim about virtue. Nobody in the story is more public-spirited than anybody else. It is a claim about a payoff structure and the behaviour it selects for — which makes it, in the end, an empirical claim about where effort actually goes. And that means somebody can check it.
Somebody has.
The number
Kevin Boudreau studied twenty-one handheld computing systems over the period 1990 to 2004, and asked a question that turns out to be exactly the right one. Platform owners can open up in two quite different ways. They can grant access — let outsiders build complementary components that interoperate with the platform. Or they can go further and give up control over the platform itself, sharing equity, narrowing their own vertical scope, letting outsiders contribute to the core.
These get lumped together under the single word “open,” and Boudreau’s finding is that they should not be. He measured what each did to the rate at which new devices were introduced.
Granting complementors access accelerated new device development by up to a factor of five. Giving up control over the platform itself produced an effect roughly an order of magnitude smaller — and in several specifications not statistically distinguishable from zero.
Granting access to independent hardware developers was associated with up to a fivefold acceleration in new device development. Going further and giving up control over the platform produced an effect that was still positive but roughly twenty per cent — an order of magnitude smaller, and in several specifications not significant at all.
Opening the edge multiplied the innovation rate. Opening the base did almost nothing.
I want to be careful about what this does and does not establish, because the temptation to over-read it is strong. Boudreau’s measure of innovation is narrow: the rate at which new devices appeared. His sample covers a period after the systems were established, when devices were emerging on top of relatively stable platforms rather than during a phase of carefully orchestrated cross-component design. And the variation in platform control he observes is incremental — he says himself it may be too small to trigger the mechanisms that devolving control is theorised to trigger. His own conclusion is that the result challenges any all-encompassing metaphor of “openness,” which is a warning to me as much as to anyone, because “fixed” and “open” are not the same axis and I should not pretend they are.
But the shape of the result is hard to argue away. Where innovation actually happened was at the periphery, on top of something that was not moving.
Parnas convicts himself
Why would that be? The answer was published in 1972, in a paper about how to cut a piece of software into pieces.
David Parnas took a small system — an index producer — and decomposed it two ways. The first way was the one nearly every programmer produces: make each step in the processing a module. Input, then shift, then sort, then output. Draw the flowchart and cut along the lines.
The second way used a different criterion. Begin, Parnas said, not with a flowchart but with a list of the design decisions most likely to change. Then design each module to hide one such decision from all the others. His modules therefore did not correspond to processing steps at all. One of them just stored lines and offered functions for getting and setting characters, concealing entirely how the storage actually worked.
He then ran five likely changes against both designs. The results were lopsided. Changing how characters were packed into words forced changes in every module of the first design, because the storage format was the interface and every module had to know it. In the second design the same change was confined to one module, because nobody else knew anything about it.
That much is standard software engineering and has been taught for fifty years. The passage that matters for this essay is the one where Parnas turns on himself.
He had carefully hidden how the shifted lines were stored or computed. But he had also specified the order in which they came out. And he realised he had not needed to. Programs could have been written knowing only that the required lines existed, that none appeared twice, and that you could recover the original from a shift. By fixing the order, he wrote, he had given more information than necessary and so unnecessarily restricted the class of systems that could be built without changing the definitions. He had ruled out, for instance, a system where the shifts came out already sorted and the sorting module did nothing at all.
He classified this as a design error.
Sit with that for a moment, because it is the whole argument in one sentence. The claim is not that interfaces should be absent — without a fixed interface nobody can build anything independently. The claim is that every detail you expose in a fixed interface removes systems from the set of things buildable without changing it. The commitment is what makes independent work possible. The size of the commitment determines how much independent work is possible. Over-specify and you have not made the system more capable; you have converted decisions that could have been made freely and locally into decisions that can only be revisited by renegotiating the commitment itself.
Parnas noticed something else, almost in passing, that bears directly on Boudreau’s number. In the first design the interfaces were complex table formats — consequential decisions, essential to each module’s efficiency, whose development had to be a joint effort across the development groups. In the second the interfaces were abstract: function names, parameter counts and types. Simple decisions. And so, he observed, independent development could begin much earlier.
A light, fixed interface does not merely permit parallel work. It permits parallel work sooner, and with less negotiation. The heavier the interface, the more of the project is consumed agreeing before anyone can build — and whoever shapes that agreement shapes what everyone else will have to accommodate.
Rules instead of managers
Carliss Baldwin and Kim Clark took the principle and gave it an economic structure. In their framework, a modularised design splits into parts that are visible — design rules everyone must obey for the pieces to work together — and parts that are hidden, where decisions do not affect anybody else.
The visible rules are the fixed thing. The hidden modules are free. And the freedom is not despite the fixity; it is constituted by it, because it is precisely the guarantee that the rules will hold that lets somebody build without consulting anyone.
Baldwin states the organisational consequence more baldly than I would have dared. Because interoperability is ensured by adherence to design rules, the modules of a system need not be subject to unified governance, hierarchy, or direct authority — except for following the rules. The platform sponsor does not need to exercise direct authority over the providers of options so long as they respect the design rules.
Read that as economics and it says: adherence to a fixed design rule is a substitute for governance. Where the rule holds and is known, the coordination that would otherwise require authority, negotiation or hierarchy is obtained for nothing. The rule does the work a manager or a committee or a vote would otherwise have to do.
Two things follow immediately and neither is decoration.
The substitution requires the rule to be fixed and known. A rule that might change is not a substitute for governance; it is an object of governance. The moment a builder has to form a view about what the rules will be next year, she is back inside the politics of the architecture, and the coordination cost the rule was supposed to eliminate reappears as anticipation, lobbying, or hedging.
And module boundaries, in Baldwin’s phrase, are thin crossing points in the task network — places where transaction costs are low. More modules means more places a third party can insert something. Her formulation of what this means competitively is the best one-line statement of edge innovation I know: entrants do not have to build a better system, or even a better platform. They only need to build a better module.
That is what a fixed base buys. Not the absence of competition, but competition at a scale a small entrant can actually reach.
Where the effort goes instead
So what happens when the rules are contestable?
The substitution runs backwards. Governance reappears, and because the architecture now determines who wins, influence over the architecture becomes an asset with a return. Every participant faces a portfolio choice between investing in modules and investing in rules — and the returns are not comparable. Module returns are incremental and competed away; that is what low transaction costs at a boundary means. Rule returns are step functions. A clause that only your module satisfies does not improve your position at the margin. It removes your competitors’ investment from the board.
The operative variable is not whether the rules can change but what changing them costs relative to building at the edge. Where the ratio is low, effort flows into the rules. Where changing the rules is expensive and building is free, effort flows into building.
Which is why the interesting variable is not fixity at all. It is the cost of changing the rules relative to the cost of building at the edge. A proprietary sponsor can revise cheaply while nobody else can revise at all. A committee that adopts by vote, with no requirement that anything be built first, makes rule change cheap for anyone who can field a delegation. But a body that demands multiple working, interoperating implementations before a proposal advances has made rule change expensive — you must do the engineering anyway — while leaving building free.
That third arrangement has a history, and it is worth knowing how it was arrived at.
Seven hundred people in a room
By the late 1980s the internet had a real problem: it was going to run out of addresses. In June 1992, meeting in Kobe, its architecture board drafted a discussion document proposing to solve it by adopting a protocol borrowed from the rival OSI standards effort. One board member later recalled that they went through eight revisions in under a fortnight and thought their wording was very careful.
Then journalists got hold of it.
What happened next is the most instructive episode I know of in this whole territory. The community did not debate the technical merits. It revolted. People felt betrayed — that the board was handing the field to an enemy they had fought for years. The same board member’s summary of the reaction is one sentence: the board had no right to make such a decision alone. Another participant later called it a constitutional crisis. At the July meeting in Cambridge, roughly seven hundred people demanded that the newly formed Internet Society intervene to keep control of the standards process where it had been. The board backed down. Vint Cerf addressed the meeting and removed his three-piece suit layer by layer to reveal a T-shirt reading “IP on Everything.” David Clark gave the plenary in which he said: we reject kings, presidents, and voting; we believe in rough consensus and running code.
Three things about this.
It was a proposal. Not a decision, not a deployment — a draft discussion document. On any ordinary account of technical disagreement, seven hundred people in revolt is wildly disproportionate. On the account in this essay it is exactly proportionate, because a change to a visible design rule is not one technical proposal among others. It is the single move whose consequences are not contained. It lands on every module at once, and everyone who had built against the rule discovers simultaneously that their insulation from collective decision-making was conditional all along.
The crisis was not about which protocol. It was about who had the right to decide. The historian’s own summary is the cleanest statement of the mechanism I have found anywhere: strains in the technical architecture prompted strains in the organisational architecture. Governance had been dormant precisely because adherence to design rules had been substituting for it. Propose to move the rules and it comes back — not gradually, but in a fortnight, with a full room.
And the resolution was not a better decision procedure. It was the rejection of having one. What replaced it was a cost: running code, meaning multiple actual interoperable implementations demonstrated before a proposal can advance. They responded to a governance crisis by making rule change expensive rather than by making it well-governed. That is the move this essay recommends, arrived at empirically by people who had just watched the alternative up close.
The same derivation, in 2010
There is a version of this reasoning I did not expect to find, written by a protocol designer with no apparent knowledge of any of the literature above.
In a forum thread on 17 June 2010, Satoshi Nakamoto set out why Bitcoin’s transaction script works as it does. The premise was that the base could not be revised: once version 0.1 shipped, the core design was — his phrase — “set in stone for the rest of its lifetime.”
From that premise he derived the interface. Because it could not later change, he wanted it to support every transaction type he could think of. The obvious approach, adding a special-purpose type per case, he rejected for a stated reason: each would need its own code and data fields whether used or not, and each would cover exactly one case. That road ends, in his words, in “an explosion of special cases.” So he generalised — a script in which the transacting parties describe their transaction as a predicate the network evaluates, with nodes needing to understand it only far enough to check whether the sender’s conditions are met.
That is information hiding, arrived at independently, under exactly Parnas’s constraint and avoiding exactly Parnas’s error. The nodes are hidden modules; the predicate evaluator is the visible rule; and the rule was made general rather than enumerative specifically so it would never have to change. In the same thread he lists what the generality was for — escrow, bonded contracts, third-party arbitration, multi-party signature — with the observation that although these were things to explore later, they had to be designed in at the beginning to make sure they would be possible.
It is worth being precise about what this shows and what it does not. It shows that fixity was the design premise rather than a later rationalisation, and that the generality of the interface followed from it. It does not show the design was correct. A designer’s account of his own intentions is evidence of intention and nothing more.
The strongest objection, which is not mine
I would be doing the reader a disservice if I stopped here, because the best argument against this position is in the same literature and it is formal.
In 1988 Joseph Farrell and Garth Saloner modelled standardisation by committee against standardisation by market leadership, and found for the committee. The committee is slower and less likely to reach any outcome before a deadline, but it is more likely to achieve actual coordination — and it outperforms the market mechanism even once you price in the value of speed. Three years earlier the same authors had shown that the benefits of standardisation can trap an industry in an inferior standard when a better one exists, a phenomenon they named excess inertia. One of their motivating examples is the US National Bureau of Standards declining to write interface standards for the computer industry precisely because it feared they would retard innovation.
So: committees are good, and fixed standards can trap you. Both peer-reviewed, both formal, both pointing the other way.
Three things reconcile this, and only the first satisfies me completely.
They are modelling a different problem. Their committee coordinates parties who have not yet committed to anything and who all prefer some standard to none. This essay is about revising a rule that already has an installed base built on it. And that distinction is theirs, not mine: they observe that by the time a committee convenes, participants often hold vested interests in incompatible positions, that the consensus principle demands more than a simple majority, and that the result is a battle of wills in committee while users wait. Their model studies conflict among parties with nothing sunk. Revision is the case where the sunk positions already exist.
Their welfare result is conditional in a way that lets my case through. The committee wins, they show, where firms have less private incentive than they should to achieve compatibility. Where private incentive is excessive — where the private return to controlling a standard exceeds the social value of the coordination it provides — the market mechanism is superior. That excessive-private-return case is precisely the rent-seeking case. Their theorem does not cover it; it explicitly excludes it.
And their closing caveat is my variable, stated in 1988. If design decisions are cheaply reversible, they note, the losses from mistakes may be small compared with the benefits of untrammelled experimentation and the direct costs of running committees. Reversibility — change cost — determines whether committee coordination is worth its price.
What survives is narrower than what I started with, and I would rather say so than let it stand. Committees are good at getting uncommitted parties to agree. The case against them is a case about revision under sunk commitment, and about the conditions under which the private return to owning a rule outruns the social value of the coordination it delivers.
Who actually pays
One last piece, because it tells you where the bill lands.
Timothy Bresnahan and Shane Greenstein gave the activity at the edge its proper economic name: co-invention. Users, through their own experimentation and discovery, make a technology more valuable — an activity distinct from original invention, and, they argue, frequently the actual bottleneck in technical progress. Purely technical progress is rarely enough to make an invention economically important.
That is the favourable half. The unfavourable half is their empirical finding about the shift from mainframe to client/server computing, which was a base-layer change of the kind this essay is about. What determined the sequence in which organisations adopted, they found, was co-invention costs — not benefits. And because it was not the highest-value adopters who moved first, the usual information spillovers were blocked and accumulated experience was wasted.
So when a base layer moves, the party who pays is the co-inventor at the edge. And the payment is not a licence fee or a migration tool. It is the destruction of accumulated, idiosyncratic, non-transferable understanding of how to use the old one. When Novell moved NetWare off its own protocol onto TCP/IP in 1998, it shipped compatibility drivers and migration agents to price that destruction down — and its own documentation conceded that because of the complexity there was no single migration utility. It could not be priced down very far.
What follows
Four claims, in descending order of confidence.
Competition is conserved. It moves to whichever margin is contestable, and if you leave the rules contestable that is where it goes.
A fixed base is what makes edge innovation possible, because it makes specialisation rational and permission unnecessary. Where the ground does not move, committing five years to becoming the best in the world at one thing is a bet on your own competence. Where it might move, the same commitment is a bet on a committee.
The operative variable is not fixity but change cost relative to build cost. That is a design variable, and it is the one to ask about: what would it cost a well-resourced party to change the rules, and what does it cost anyone to build without changing them? Where the first is low and the second high, expect capture. Where the first is high and the second low, expect building.
And the returns in such a system accrue to knowledge rather than to claims. Which ought to be encouraging to anyone who actually makes things. Where the ground is still, you cannot buy a position. You have to earn one by understanding a domain better than your competitors do.
Set the base. Then go and build something at the edge, where the work is — and where, on the only decent measurement we have, the innovation runs five times faster.
Sources. Every source named here was read. Where a finding cuts against the argument, it is reported above rather than omitted.
Boudreau, “Open Platform Strategies and Innovation: Granting Access versus Devolving Control,” Management Science 56(10), 2010. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM 15(12), 1972. Baldwin, Design Rules, Volume 2, ch. 13, Harvard Business School Working Paper 19-073, 2019. Russell, “’Rough Consensus and Running Code’ and the Internet–OSI Standards War,” IEEE Annals of the History of Computing 28(3), 2006. Farrell and Saloner, RAND Journal of Economics 16(1), 1985, and 19(2), 1988. Bresnahan and Greenstein, Brookings Papers on Economic Activity: Microeconomics, 1996. Nakamoto, BitcoinTalk, 17 June 2010. Novell developer AppNotes, 1998–99.