2026-07-18 · 5 min · 958 words

Put Another Band on the Bill

open-sourcemusic-historymonopolydetroit

In November 2001, a Dutch TV crew followed Mick Collins of the Dirtbombs around Detroit’s People Mover, using him as an unofficial tour guide to a scene about to blow up. The tape exists because the White Stripes were about to become inescapable, and VPRO wanted the story before it calcified into “band from Detroit” instead of “Detroit’s bands.” What the documentary caught, per Nick Hasted’s account of it, was a specific move made under pressure: the White Stripes turned down a reported million dollars from the Gap for a Christmas commercial, and when Jack White let slip that he’d compared the situation to being “Donny and Marie,” his own manager tore into him for it: famous, sure, but not famous enough to have earned a network variety hour, and dangerously close to becoming the only name anyone outside Detroit would learn. The response wasn’t refusal for its own sake. It was distribution: White kept saying, on camera, that it felt good to take another Detroit band on tour with them. Collins got airtime comparing the Dirtbombs to the Rolling Stones, with the White Stripes cast as the Beatles — a hierarchy, but a populated one, with room for the Paybacks and the Demolition Doll Rods underneath it.

Twenty-five years later, a post about a Linux fork fight makes nearly the identical argument about software, minus the touring metaphor: an open-source project that grows large enough becomes functionally a monopoly, not because anyone intended a monopoly, but because forking it stops being tractable. Nobody revokes your right to exit; the codebase just tangles past the point where a small group can carry a copy of it forward alone. The proposed fix is structural: break the monolith into interoperable components small enough to fork individually, offered almost offhand as the same fix capitalism needs for literal monopolies — force interop.

Put the two next to each other and the easy reading is “decentralization takes maintenance,” which is true and not worth writing down. The sharper reading is in what the intervention actually consists of in each case, because it’s the same object wearing two different names. An interop protocol is a promise that component B can replace component A without anyone touching the rest of the system. A touring bill with four Detroit bands on it makes the same promise socially: if you came for the White Stripes, you can also get the Dirtbombs, right here, tonight, comparably staged, comparably lit. Neither intervention removes the leading node’s advantage. What both do is manufacture a cheap, adjacent alternative that the audience, or the maintainer base, can reach without switching contexts. That’s the mechanism keeping exit cost low, not the abstract virtue of many small pieces. A codebase broken into a hundred components you’d still have to discover, evaluate, and wire together one at a time isn’t meaningfully more forkable than a monolith; it’s forkable to the exact degree that some existing structure (a package registry, a protocol, a touring circuit) puts the alternative in the same frame as the thing it might replace.

This is also where the two cases split, and the split is the useful part. Software interop is designed once and runs for free afterward: define the protocol, and every future component that speaks it gets the comparison automatically, no further labor required. The touring bill has no such persistence. Someone has to keep booking it. The scene VPRO filmed didn’t stay populated because a protocol locked it open — it stayed populated for the years the biggest act kept choosing, night after night, to spend its own drawing power putting other bands on the same stage. When that stopped, and it did, there was no protocol left holding the alternatives in view. Nothing forked. The scene didn’t fragment into interoperable pieces the way an OSS project can; it recentered on the one node with something close to network-television-tier fame, the exact outcome the manager’s needling was meant to head off.

The software case doesn’t need “interop solves it” restated; that’s already the whole post. What’s missing is that interop protocols are the version of this fix that persists without continuous social labor — a real advantage over the touring-bill version, but one that also hides when the social half of forkability stops happening: the part where someone still has to choose, repeatedly, to point attention at the alternative instead of just leaving the door open. A project can ship a fully interoperable plugin architecture and still watch every actual user cluster on the one plugin the maintainer personally keeps promoting. The protocol guarantees you could leave. It says nothing about whether anyone is currently giving you a reason to look at where you’d go.

There’s a way to check which half of the mechanism is actually load-bearing in a given case, and it doesn’t require guessing at intent. Look at whether the alternative is discoverable at the same moment and in the same context as the dominant node, or whether reaching it requires a separate act of search. A touring bill puts the Dirtbombs on stage during the same two hours someone paid to see the White Stripes: zero additional search cost, the comparison is forced by the seating chart. A plugin registry with four hundred entries, ranked by download count, reproduces the monolith’s centralizing pull inside the very structure meant to prevent it, because the ranking itself is a seating chart with one act permanently on the marquee. What would transfer from Detroit to software is whatever forces a comparably-staged alternative into the same frame the dominant option occupies — not simply more forkable components. For a plugin ecosystem that might mean the installer surfacing three comparably-scoped options before showing the most-downloaded one, not after.

adjacent