Open Standards Are Necessary but Not Sufficient: The Deeper Forces Behind Platform Capture

The Seductive Simplicity of the Standards Argument

There is a particular comfort in the idea that open standards can solve platform lock-in. The argument is clean and intuitive: if every system speaks a common language, no single vendor can hold the dictionary. For engineers and policy advocates alike, pushing for interoperability requirements feels like progress—concrete, measurable, and politically tractable. The European Union's Digital Markets Act, for instance, has placed interoperability obligations at the center of its approach to reining in dominant platforms. Similar conversations are underway in Washington.

Yet the evidence from the field consistently complicates this optimism. Open standards frequently coexist with profound market consolidation. Email is perhaps the oldest example: SMTP, IMAP, and related protocols are fully open, thoroughly documented, and universally implemented. Despite this, two providers—Google and Microsoft—handle the overwhelming majority of enterprise email in the United States. ActivityPub, the decentralized social networking protocol endorsed by the W3C, powers Mastodon and a constellation of federated services, yet mainstream adoption remains a rounding error compared to the platforms it was meant to challenge. CalDAV and CardDAV have existed for years, but most users still manage their calendars and contacts inside a single vendor's walled garden.

The technology is working. Something else is not.

What Standards Cannot Touch

To understand why interoperability so often fails to deliver on its promise, it is useful to distinguish between three categories of lock-in: technical, organizational, and economic.

Technical lock-in is the layer that open standards directly address. Proprietary data formats, closed APIs, and incompatible protocols all create friction that prevents users from moving to alternatives. When a standard exists and is widely implemented, this friction is genuinely reduced. Migration tools improve. Data portability becomes feasible. Developers can build against a stable interface rather than a vendor's changing whims.

But technical lock-in has long ceased to be the binding constraint for most large organizations. The more durable barriers are organizational. Switching costs are not primarily about file conversion; they are about retraining staff, renegotiating procurement contracts, rebuilding integrations, and absorbing the political risk that comes with any significant technology change. A hospital system that has spent a decade embedding an EHR platform into its clinical workflows faces a migration challenge that no amount of HL7 FHIR compliance will make straightforward. The standard enables the possibility of migration; it does not reduce the organizational disruption.

Economic lock-in is subtler still. Dominant platforms invest heavily in complementary services—storage, analytics, identity management, developer tooling—that are valuable in isolation and even more valuable in combination. A research university that uses a major cloud provider's compute infrastructure, object storage, identity layer, and managed database services is not simply using a platform; it has built a dependency graph that is genuinely difficult to unwind, even when every component has an open-source analog. The economic incentives that created this bundling are not addressed by any standard.

The Adoption Gap and Who Bears Its Cost

There is a consistent pattern across open standards efforts: a small number of technically sophisticated, mission-aligned organizations adopt early, demonstrate feasibility, and then watch adoption stall. The early adopters often bear disproportionate costs—maintaining connectors, writing documentation, absorbing compatibility bugs—while the broader ecosystem waits for the standard to mature. This dynamic is not accidental. Dominant platforms have every incentive to participate in standards bodies just enough to shape specifications in their favor, then delay or partially implement the resulting standards.

This behavior has been documented in browser standards, health data exchange, and financial services APIs alike. Partial implementation is particularly insidious because it allows a vendor to claim standards compliance while preserving meaningful differentiation. A platform that implements 80 percent of an ActivityPub profile can federate just enough to satisfy regulators while ensuring that the remaining 20 percent—typically the features users care most about—remains proprietary.

For the open infrastructure community, this creates a painful asymmetry. Building to a standard requires resources. Maintaining compatibility as dominant players introduce proprietary extensions requires more. The organizations most committed to genuine interoperability are often the least resourced to sustain that commitment over time.

Beyond the Specification: What Actually Needs to Change

If technical standards alone are insufficient, what does a more complete approach look like?

First, interoperability requirements need enforcement mechanisms with teeth. A standard that a dominant platform can nominally satisfy while undermining in practice is not a standard that produces competition. Regulatory frameworks must include testing regimes, audit rights, and penalties calibrated to the scale of the violation—not the scale of the complaint.

Second, the economic incentives around bundling need direct attention. Antitrust analysis that focuses narrowly on price effects misses the way that platform ecosystems create lock-in through complementary service integration. Policy frameworks should examine whether bundling practices functionally undermine the interoperability obligations that exist on paper.

Third—and this is where the open infrastructure community has the most direct agency—the tools that make standards usable need sustained investment. Reference implementations, migration utilities, compatibility test suites, and developer documentation are not glamorous, but they are what transforms a specification into something organizations can actually adopt. At Condor Platform, we have observed that the projects which successfully drive adoption tend to be those that treat tooling as a first-class deliverable, not an afterthought.

Finally, the governance structures of standards bodies deserve scrutiny. When the organizations that have the most to lose from genuine interoperability are also the most heavily resourced participants in the standards process, the resulting specifications will reflect that imbalance. Community-driven projects and nonprofit infrastructure providers need seats at the table—and the capacity to use them effectively.

The Longer Work

None of this is an argument against open standards. Interoperability remains a necessary condition for a more competitive, more resilient digital infrastructure. The point is that it is not sufficient, and treating it as though it were leads to a kind of policy complacency—the assumption that once a standard exists, the problem is largely solved.

The harder work is organizational and economic: changing the incentive structures that make lock-in profitable, building the tooling that makes alternatives viable, and sustaining the governance processes that keep standards honest. Open infrastructure projects that understand this distinction are better positioned to build something that lasts—not just something that complies.