Interoperability is the feature

A platform boundary becomes more valuable than the product inside it.

A platform launches open. Documented APIs, generous terms, third-party clients encouraged. It grows, because being easy to build on is how you recruit the ecosystem that makes you valuable in the first place.

Then it closes. Rate limits appear, terms change, the API that third-party clients depend on gets deprecated and the data export turns awkward. No moral failing of particular companies is required to explain this: it's what the incentives produce once the ecosystem has been recruited and the switching cost paid.

Why engineers should treat this as a design input¶

Because the closing is predictable, which means you can design for it.

The practical question when you adopt a platform isn't whether its terms are good today. It's what the exit looks like, and specifically:

• Can the data be exported in a documented format, completely, without negotiation?
• Is the interface we depend on a published standard, or is it this vendor's API?
• If the terms changed tomorrow, what's the recovery path and how long is it?

Those have real answers, and the answers are usually worse than people assume, because nobody has tested them.

Specify the exit before you sign¶

The only moment you hold leverage over a supplier is before the contract exists. After that, the party you are buying from has a predictable future incentive to make leaving hard, and no obligation beyond what you wrote down.

So write it down. Put the export format, its completeness and its cadence into the specification alongside the functional requirements, and treat an unexercised export clause as a promise rather than a capability. Exercising it annually as an acceptance test is what makes the difference; a fire drill beats a fire certificate.

What this makes possible¶

Specified boundaries do more than protect you from a supplier.

Competition on the merits of the product. When the interface is public, a small supplier can offer a better implementation and a customer can take it without rebuilding their business. That is how we got competing web browsers, competing mail servers and competing SQL databases. Every market where you can change supplier in a fortnight is one where suppliers have to be good.

The small team gets to participate. If messaging, identity, payments or social graph access are specified rather than proprietary, a four-person company can build a client or a specialist tool for a niche the platform will never serve: a reader for someone with low vision, a client that works over a 2G link, a tool for a language with twelve thousand speakers. None of those are commercially interesting to a platform with a billion users, and all of them matter enormously to the people who need them. An open boundary is an accessibility policy by other means.

Public institutions stop being hostages. A hospital, a council or a school that can move its records between systems can replace a supplier that has become expensive or negligent. Today it frequently cannot, which is why public bodies run software everyone involved knows is inadequate. Specified data portability is the cheapest improvement available to public procurement.

And the engineering benefit: an interface with more than one implementation is an interface whose spec gets tested. Single-implementation standards drift into "whatever the vendor does", and every ambiguity becomes a production bug years later.

The interoperability mandates turning up in digital-markets regulation are an attempt to make the boundary a public property rather than a private one: messaging interoperability, data portability, access to platform functions on non-discriminatory terms.

Whether they work is an open question, and the engineering concern is a narrow one. A mandated interface that is technically compliant and practically unusable satisfies the regulation and achieves nothing. An API with a compliant schema, punitive rate limits and no stability guarantee meets the letter of the thing.

Which makes the specification the battleground¶

The quality of the specification is the whole game, so look at who is in the room. A standards working group is staffed by whoever can afford to send engineers to it for three years: the three or four largest implementers of the thing being standardised, plus a few academics and the occasional underfunded nonprofit. Those implementers have the strongest commercial interest in the specification being ineffective. They need not obstruct anything; they need only be patient, argue for optionality and win on detail.

The tells are consistent, and you can read them off a draft:

• Everything important is optional. A MAY where there should be a MUST is a clause that will never be implemented by the one party whose implementation matters.
• No conformance suite. A standard with no executable test of compliance cannot be failed, and therefore cannot be enforced, whatever the statute says.
• Extension points with no registry. The documented escape hatch through which a vendor re-establishes its proprietary interface inside the compliant one.
• Performance unspecified. Correct, slow and rate-limited is a complete defence.

Privacy is the stick used to beat every interoperability mandate. Opening a boundary does expose data to more parties, and "we cannot do this safely" is a real argument that is also very convenient for an incumbent. Encrypted messaging interoperability is hard and needs its protocol work done in public. A platform arguing for user privacy while running the largest behavioural advertising operation on earth is making a commercial argument in a safety costume. Both halves are true.

Watch too for the mandate that entrenches rather than opens. A rule that only the largest platforms must comply, implemented through a certified-partner programme with an approval queue, becomes a licence scheme the incumbents administer. Non-discriminatory terms mean nothing if only a funded company can complete the onboarding.

Protocols with multiple independent implementations and no corporate owner do exist, and they are short of people and money rather than short of ideas.

An interface you cannot reimplement is a dependency rather than a standard. That is why we specify our own boundaries and publish them. The interoperability you offer is a commitment about your own future behaviour, and it is the first thing a later owner of the company will withdraw quietly. Writing it into the product as a documented format and a complete export, tested in CI, makes it harder to remove than a promise in the documentation.