When it's railroading time, you get railroads.
When the railroads turn into the personal satrapies of rail-barons, you get trustbusters.
A couple decades ago, it was online service time. We had the users, the telcoms systems, the computers, the modems, so we got platforms.
We had that, but we lacked something important: effective antimonopoly enforcement. Lax merger laws allowed companies with access to capital markets to buy out or neutralize all their competitors, so we got monopolies.
Klobuchar's bill is hugely important. The reason we have monopolies is that we stopped enforcing anti-monopoly law 40 years ago. Monopoly isn't a tech problem, it's everywhere from sneakers to glass bottles to pro wrestling to candy to aerospace.
Take ERs: monopolists love ERs because we don't choose which ER to use, nor when. You can't shop for an ER from the back of an ambulance. You don't know going in whether you're going to spend $1m or $1k. And you'll buy whatever services the ER tells you to buy.
Or power-grids: demand for electricity is both inelastic (you need power when you need power) and price-insensitive, and that inelasticity increases with demand: that is, when it's freezing or boiling out, everyone wants electricity.
Tech, of course, has its own technical characteristics. Chief among these is its flexibility. At a deep, theoretical level our digital tools and networks are capable of interoperating with one another in ways that no physical technologies can match.
Think of the Australian rail-system. In the mid-19th century, would-be rail-barons laid differing gauges in hopes of conquering the nation's logistics and transport.
For 150+ years, engineers have tried to solve the "multi-gauge muddle" by designing multi-system railcars.
Hundreds of designs for cars that retract and extrude different wheelbases have been tried, and none ever caught on. Instead, Australia is tearing up and re-laying thousands of kilometers' worth of track. With physical tech, "compatibility" often means starting from scratch.
Not so with digital tech. If you are an OS company whose rival has locked up all office docs in a proprietary format, you don't have to convince all its customers to abandon their documents and start over. You just make a compatible program:
With digital and physical tech, network effects drive high switching costs, but when it comes to digital, network effects are a double-edged sword.
With interoperability, a walled garden can easily become a feed-lot, where customers for a new service are neatly arrayed for competitors to come and harvest.
Good tech policy emphasizes interoperability when it comes to demonopolizing the digital world. Long before the US ACCESS Act and the EU Digital Markets Act, Mike Masnick published his seminal "Protocols, Not Platforms" paper.
And Daphne Keller's work on "Magic APIs" presaged the ACCESS Act's idea of forcing tech companies to expose the APIs they use internally so that competitors can plug into their services:
(that paper is outstanding, BTW, with clear-eyed assessments of alternatives, like a digital fairness doctrine, "common carriage" rules, an "indecency" standard for content moderation – basically a checklist for "So you've got a plan to fix tech – did you think of ____?")
Masnick's "protocols" are a vision for a decentralized, better internet. Keller's Magic APIs describe a legal path to getting there. My own work on Competitive Compatibility (nee Adversarial Interoperability) describes how we'll STAY there.
Because monopolies are good at subverting regulation, so any Magic API rule would be brittle – dependent on the tech companies not sabotaging those APIs by moving the important data-flows away from the mandatory APIs.
That's why we have to strip monopolists of the power to ask a court to block interoperators: take away the wildly distorted copyright, patent, terms of service and other legal doctrines that Big Tech ignored during its ascent, but now enforces against would-be competitors.
With both interop mandates and a legal right for new entrants to force interoperability through technical means, tech giants will face consequences if they subvert antimonopoly rules.
The choice becomes: either respect the intent of a mandate and preserve interop; or be plunged into a chaotic arms-race with competitors who switch to scraping, bots, and reverse-engineering.
All of this is incredibly wonkish, a highly specialized debate that involves highly technical propositions about how digital technology works today, how it used to work and how it might work – layered atop a similar, highly technical understanding of antitrust law.
The Venn overlap of "deep understanding of digital tech" and "deep understanding of antitrust debates" isn't so much a slice as it is a sphincter, and the debate has been equally narrow, but when it's railbaron time, you get trustbusters.
The tech monopoly/interop debate is going mainstream. Francis Fukuyama and his colleagues at the Stanford Working Group on Platform Scale have a proposal similar to the ACCESS Act, where third parties mediate between monopolists, new entrants and users.
The Stanford proposal calls them "middleware companies," but they're conceptually interchangeable with the idea of a "data fiduciary": companies that act as referees when a new co-op, startup or nonprofit wants to plug into a monopolist's service.
This is clearly an idea whose time has come – it's present in the EU's DMA and the US Access Act, and latent in the UK CMA report:
Importantly, it's an approach that recognizes the distinctive character of tech – taking account of the power of interop to break open walled gardens and unravel network effects.
What's especially interesting about this work is that it appears to have been developed in parallel to pre-existing work from Masnick and Keller (and me) – it's a case of convergence between the tech-policy world and the broader world of policy.
After all, while Masnick and Keller's work is well known inside of tech policy, that's just our obscure, nerdy corner of the policy world – now they're escaping that corner, becoming self-evident to people from traditional policy backgrounds.
My hope is that the trend continues – that we see ideas about Competitive Compatibility/Adversarial Interop join the idea of API mandates, so that we produce durable anti-monopoly systems, not just anti-monopoly rules.
Most important, though, is restoring an appreciation for the importance of interoperability in preventing monopolies and promoting technological self-determination for communities and individuals.
Because such a sensibility can escape the legislative world and be enacted via fast-moving, easier-to-use policy tools. For example, we could (should!) make interop a feature of all government procurement rules.
No school district should buy devices for students without securing the right to sideload the apps they need on them – imagine buying 50,000 Ipads at public expense and then having Apple boot the app you rely on out of the App Store!
Likewise, no district should buy Google Classroom without securing a legally binding guarantee not to block interoperators who want to integrate other ed-tech services into the curriculum, with or without Google's cooperation.
Procurement and interop are as old as the Civil War, when the Union Army demanded firearms and ammo that had multiple manufacturers. As the state-level Net Neutrality rules (which bar governments from using non-neutral ISPs) showed us, procurement can shape markets.
Procurement is just for starters. Right now, tech companies caught breaking the law are handed down fines that are less than the profits their lawbreaking generated – instead, we could demand interop as part of any settlement.
A barrier to interop is contract law: terms of service, EULAs, arbitration, etc. States wield enormous power over contracting terms: states can declare certain contractual language against public policy and thus unenforceable.
If, say, California were to pass a rule nullifying the mountain of abusive garbage that has become standard in digital "contracts," it would be in a position to export fair usage terms to the country in just the same way it exports robust emissions standards.
Mamot.fr est un serveur Mastodon francophone, géré par La Quadrature du Net.