Platform Enclosure Did Not Happen to the Internet. It Was Built Into It.

In this article:

• What the Internet Was Before It Was a Set of Platforms
• How Client Server Architecture Enclosed the Digital Commons
• What Platform Enclosure Means for Businesses Operating Inside It
• Why Enclosure Is the Structure, Not an Outcome
• Frequently Asked Questions
• What is platform enclosure and how does it differ from simple market dominance?
• What does digital commons mean in the context of internet infrastructure?
• What is the exit cost of platform enclosure?
• References

The 17th century enclosure of English common land was not a sudden seizure. It was an incremental process of legal and physical change that converted shared resources into private property over generations. What people lost was not the land itself. What they lost was access, governance, and the ability to organize their lives around a resource they had helped sustain. The digital commons went the same way, for the same structural reasons, in a much shorter time. The mechanism was architectural before it was legal, and it was designed before most of the people affected knew they were inside it.

The internet was designed as a network of peers. This is not a nostalgic characterization of an early internet that never fully existed. It is a description of the technical architecture: a communication protocol that assumed every node was equivalent, that required no central permission to connect two machines, and that treated hierarchy as damage to be routed around rather than as structure to be enforced.

In 2010, Eben Moglen, chairman of the Software Freedom Law Center, described this at a lecture at the Internet Society of New York as a network "designed as a system of pure nodes, assuming that every switch in the net is an independent freestanding entity whose volition is equivalent to the volition of the human beings who own and control it." Every participant was equivalent in capability. No participant required another's permission to communicate. The value of the network was distributed among all the nodes, not concentrated in any center.

That architecture was a commons in Elinor Ostrom's sense: a shared resource governed by participants rather than extracted by a single owner. Ostrom's Nobel recognized research on commons governance demonstrated that shared resources can be managed sustainably when participants govern access collectively, prevent overextraction, and distribute both the benefits and the costs of governance among those who depend on the resource. The early internet's open standards, peer routing, and protocol transparency were the technical expression of exactly this kind of collective governance. No company owned the protocol. No company owned the right to determine who could participate or on what terms.

What occupied the network was not a commons. The software that came to fill the space between the underlying protocol and the human being using it was built on entirely different assumptions. Those assumptions were the beginning of enclosure, and they arrived before most people using the network had a framework for recognizing what enclosure meant in a digital context.

The enclosure of the digital commons did not begin with Facebook or Google. It began with the operating metaphors that became dominant in the software that populated the network. Client server architecture was not inherently extractive. In its original X Windows formulation, the server was the machine at the human end of the network connection, serving the human's needs. What the Windows operating system made dominant was an inversion: the server became the entity with power, the client became the entity that received services on terms the server defined.

Moglen identifies this inversion as the originating error. Windows created "a political archetype in the net which reduced the human being to the client and produced a big centralized computer which now provided things to the human being on take it or leave it terms." The human at the keyboard, who was supposed to be a peer in a network of equals, was recategorized as a client: someone who receives rather than participates.

This recategorization had structural consequences that extended far beyond Microsoft. Once client server became the dominant metaphor for how computers related to each other, infrastructure followed it. Servers accumulated resources at the center. Clients thinned at the edge. The logs of network activity, the records of what was said and by whom and when, accumulated on server infrastructure rather than on the machines of the people whose activity generated them. The people who owned the servers owned the records. The peers of the network had become clients of the center, and the center held everything that documented their activity.

Moglen describes Microsoft as the first major platform encloser in this structural sense: not through intent but through the logic of building infrastructure whose business model depended on keeping people inside it. The platform management logic he attributes to Microsoft is the same logic that produced Facebook, Google, Shopify, and the SaaS ecosystem that followed. Each of these represents not a new kind of company but a more complete realization of the same client server enclosure that began with the operating system.

The specific mechanism of how this enclosure operates on digital commons is mapped in detail in Digital Enclosure: How SaaS Platforms Fence the Commons. The exit mechanism, and why enclosure is specifically designed to make it expensive, is documented in Digital Enclosure Is Designed to Make Exit Expensive.

For businesses, platform enclosure is an operational experience before it is a theoretical framework. It arrives as a specific calculation: the cost of migrating to a competitor exceeds the cost of accepting a price increase, policy change, or feature degradation on the platform you currently use. That calculation, made in favor of accepting the worse deal, is the platform's enclosure working exactly as designed.

The mechanism is the migration cost. A business that has run its customer communications, operational history, or workflow automations through one platform for three years has not simply spent money on software. It has built an asset: a record of what it has done, who it has served, and how it has operated. That asset is real. The problem is that the asset exists in a format and on infrastructure the platform controls. It is not portable in any practical sense. Migrating it requires either accepting the gaps in the export format or paying for the consulting work to bridge those gaps. The switching cost is not the competitor's onboarding fee. It is everything you built on their land.

Ostrom's framework for commons governance makes clear why this is an enclosure rather than simply a business relationship. In a commons, the costs and benefits of using the shared resource are governed collectively by the people who depend on it. In platform enclosure, the costs accumulate with the platform's users while the benefits accrue to the platform. The users cannot change the terms because they do not govern the resource. They can only accept the terms or absorb the exit cost. The governance structure is the enclosure.

The infrastructure alternative that restores governance to the user, the stack that runs on hardware and software the business controls, is documented in Decentralization: The Stack That Does Not Extract and in Commons Based Infrastructure for Independent Businesses.

The enclosure framing matters because it clarifies what kind of problem platform dependency is. It is not a quality problem. An enclosed platform might deliver excellent software. It is not a pricing problem. The fee might seem proportional to value. It is a structural problem: the relationship being built between the business and the platform is designed such that exit becomes more expensive over time regardless of software quality or pricing fairness. The enclosure is not a consequence of the platform going bad. It is the condition the platform was designed to produce.

Moglen describes platforms as "places you can't leave, stuff you're stuck to." The stickiness is not a product of satisfaction or habit. It is a product of structural design. Every feature that saves you time, every workflow you automate, every integration you build deepens the switching cost. The platform improves, and in doing so it encloses you further. The improvement and the enclosure are the same process running simultaneously.

The historical parallel is exact. The enclosure of English commons proceeded partly by making the land more productive through private management, then using that productivity to justify private ownership of what had been shared. The improvement was the argument for enclosure. Digital platform enclosure follows the same logic. The product genuinely gets better, the workflow value is genuine, and in getting better it makes the switching cost higher. The quality and the lock in are not in tension. They are the same investment producing two different outcomes for two different parties.

What Moglen proposed in 2010 was not to wait for platforms to reform or regulators to force them. His argument was architectural: rebuild the infrastructure at the edge, put the server back in the hands of the user, restore the peer to peer logic the internet was designed around. "We need to rearchitect services in the net," he said. "We need to redistribute services back towards the edge. We need to devirtualize the servers where your life is stored and we need to restore some autonomy to you as the owner of the server."

That argument is what open source software, infrastructure you operate yourself, and platform cooperative models represent in practice. Not a rejection of software or services, but a restoration of the governance relationship the internet was designed to support and that platform enclosure systematically dismantled.

Market dominance means a company has more customers than its competitors. Platform enclosure means the infrastructure of a market has been designed such that exit is structurally expensive regardless of whether better alternatives exist. A dominant company can be displaced by a better product. An enclosing platform designs switching costs into the infrastructure itself, making displacement expensive independent of product quality.

The internet was designed as a shared infrastructure governed by open standards: a commons in the sense Elinor Ostrom described, where resources are held and governed collectively rather than extracted by a single owner. Platform enclosure is the privatization of that commons. The shared infrastructure designed to serve all participants gets replaced by substitutes owned by the vendor that serve vendor interests first and participant interests only so long as those interests align.

The exit cost of platform enclosure is not the cost of subscribing to a competitor. It is the cost of reconstructing, on different infrastructure, everything you built on the enclosed platform: your data, workflows, integrations, historical records, and the operational knowledge embedded in how your team uses the tools. That cost is structural, accumulates over time, and is the mechanism by which enclosure maintains dependency independent of product quality.

Moglen, Eben. Freedom in the Cloud. Internet Society of New York, 2010.

Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press, 1990.

Doctorow, Cory. Pluralistic. pluralistic.net.

Electronic Frontier Foundation. eff.org.

Free Software Foundation Europe. fsfe.org.