The Silicon Industrialists - Part 3: The Return of the Bind

The debate about AI's economics keeps returning to the same questions: why it costs so much, why spending keeps rising while returns remain uncertain, and why the same handful of companies fund the labs, run the infrastructure, buy the startups, and sell the results back to each other.

The usual answers point to the nature of AI itself. This article argues that AI did not create most of the structure producing these outcomes. It inherited it.

The personal computer, independent software, and the open internet had once broken a pattern that earlier infrastructure technologies repeatedly fell into. That escape rested on three separations: the machine could be changed without losing the software, the software could be bought without remaining permanently dependent on the vendor, and a company could reach its customers without permission from whoever owned the layer underneath.

Over the next three decades, those separations weakened. Computing recentralised around shared services, ownership dissolved into subscriptions, the capability to build and specify migrated outward, distribution narrowed to gated storefronts, and the account began joining those dependencies into a single enforceable system.

Each step was useful on its own and most looked like an improvement at the time. But the institutional conditions that had once kept the layers apart expired or were never rebuilt for the new ones. The result was a stable, well-functioning structure that increasingly shaped which kinds of companies and products could be recognised, financed, bought, staffed, and built.

AI arrived inside that structure.

The debate about AI's economics keeps coming back to the same questions. Why does it cost so much? Why does the spending keep rising when the returns remain uncertain? Why are the same handful of companies funding the labs, running the infrastructure, buying the startups, hosting the models, and selling the results back to each other? And why does the most transformative technology in a generation keep ending up looking like the same old enterprise software, implemented by the same consulting firms?

The usual answers point to AI itself. The compute is too expensive. The models are too large. The chips are too scarce. The data requirements are too demanding. Those explanations are not wrong. AI does require enormous amounts of compute, capital, infrastructure, and specialised hardware.

But they leave two questions unanswered. Is this particular structure really the only way a transformative computing technology like AI can develop? And if it is not, how did AI end up inside it?

The history of computing gives us an answer to both.

The personal computer and the internet once developed under very different conditions. Underneath them was something no previous infrastructure technology had produced. An economic arrangement built around three separations:

• The machine could be changed without losing the software.
• The software could be bought without remaining permanently dependent on the vendor.
• And a company could reach customers without needing permission from the owner of the underlying infrastructure.

Those separations are what made the software economy different from every major infrastructure industry before it. They also show that the structure AI occupies today was not the only possible way for a transformative computing technology to develop.

But over the next three decades, those separations would gradually weaken, and computing would begin to take on the structure of much older infrastructure systems.

Before computing, major privately financed infrastructure technologies had tended to follow a different pattern. Railroads, electricity, and telephony required enormous investment before there were enough customers to pay for it. Scale concentrated the industry into fewer hands. But as the new infrastructure spread, it also began weakening the businesses, pricing systems, and sources of value of the very customers whose payments were supposed to sustain it.

That pattern is the double bind. The infrastructure still has to be paid for just as the sources of value that supported it are weakening. The companies that own it then start using the parts they control to protect the revenue they need: access, pricing, distribution, financing, or even the pace of the transition itself, as the value supporting the system begins to shrink.

Over time, that control does more than determine who wins. It begins to determine which kinds of businesses and technologies can develop at all. Railroads, electricity, and telephony all passed through versions of this pattern. Computing escaped it because the layers above the infrastructure were kept open and separable.

And that outcome was not simply the natural result of better technology. AT&T's monopoly was kept out of computing, allowing new companies to explore the technology. IBM separated software from hardware under legal and competitive pressure, creating a new product category. And the early internet was deliberately kept open before any single company could turn the network into its own toll road.

But what is built can also be allowed to decay. And what had been kept separate was gradually rejoined.

Part 1 traced the double bind through the AI economy itself. Part 2 showed how computing had once escaped that pattern.

This article traces how the separations that made computing's escape possible were gradually reversed:

• Computing moved back toward shared infrastructure whose proprietary services became part of the product itself, while the crowded landscape of providers thinned to a handful.
• The durable copy dissolved, first into conditional licences and then into subscriptions that disappeared the moment you stopped paying.
• The organisational knowledge needed to specify and replace those systems migrated outward into vendor and consulting ecosystems.
• The route between maker and buyer narrowed from an open web to a handful of gated storefronts.
• The account, something so ordinary nobody experienced it as infrastructure, began joining those separate dependencies into a single enforceable system.
• The institutional conditions that had once kept these layers apart expired without successors.
• And the resulting structure began shaping not just which companies won, but which kinds of products could be recognised, financed, bought, staffed, and built in the first place.

Each step was useful on its own, and most looked like an improvement at the time. By the mid-2010s, computing had already been reshaped around shared infrastructure, recurring access, externalised capability, gated distribution, and joined identity.

And then AI arrived inside it.

The machine becomes a service

Before what we recognise today as the cloud, if you wanted to run a business on the internet, you owned the infrastructure or rented specific, identifiable machines. A startup bought servers and collocated them in a data centre. A small operation paid a few dollars a month for shared hosting. This was space on someone else's server, shared with other small websites. A large corporation operated entire rooms of machines, managed by engineers it employed. The scale differed enormously but the structure did not.

But running your own infrastructure meant living with operational problems. Things like a disk failing at 3am or a power supply dying on a Friday evening. Capacity planning was almost always wrong. If you bought too little, your site went down when traffic spiked; if you bought too much, the machines sat idle. And security was whatever the person who set up the box remembered to configure. Hosting providers could take much of this off your hands for an extra charge, offering monitoring, hardware replacement, even managing your databases and applications. But you still chose what ran on the machines, and the components were standard. The database was a database anyone could run and the web server was a web server anyone could install.

For a large enterprise, the problems were different. They ran dedicated data centres, bought capacity years in advance, and often left expensive hardware idle outside peak periods. Different divisions and regions frequently duplicated the same infrastructure because coordinating everything centrally was difficult. The systems worked, but running them required a great deal of money, staff, and planning.

What both had in common was that changing one supplier did not force you to change everything else. If your hosting provider raised prices or went under, you moved. You copied your setup and transferred it somewhere else. If a hardware vendor became too expensive or difficult, the next purchase went to a different one. The hosting provider gave you the machine and the connection. It did not also provide its own proprietary integrated database, login system, file storage, and application services.

That relationship began to change when the machine stopped being the thing you rented and became something more.

In 2006 Amazon launched AWS. What it offered was fundamentally different from traditional hosting. Instead of contacting a provider, choosing a plan, waiting for setup, and then managing the machine yourself or paying someone else to do it, AWS made infrastructure self-service. You created an account, added a payment method, chose what you needed, and the system made it available almost immediately. Amazon had taken the purchasing model it had perfected in online retail and applied it to computing infrastructure.

Microsoft Azure followed in 2010, building on Microsoft's long-standing relationships with business customers. Google Cloud Platform followed in 2011, using the experience Google had gained running its own enormous online services. They came from different directions, but the result was the same. Infrastructure was no longer just a machine you rented. It was becoming something you accessed and managed through an account.

But each managed service also created a new dependency. S3 stored your files through Amazon's own system, Lambda ran your code inside Amazon's environment, and DynamoDB was a database that existed only inside AWS. Each solved a real problem, but each worked in Amazon's particular way. You were no longer simply renting a machine. You were building parts of your system around proprietary services supplied by the same company. Leaving therefore meant more than copying your software to another server. Anything built around Amazon's database, storage, networking, or other services might have to be changed or rebuilt. The more of those services you used, the more expensive leaving became.

People understood this problem early. Cloud dependency and vendor lock-in were debated almost from the beginning. Open-source projects such as OpenStack tried to provide an alternative, while tools such as Docker, Kubernetes, and Terraform made applications easier to move between AWS, Azure, Google Cloud, and private data centres. These tools genuinely reduced the problem. An application packaged in a container can often be moved without being rewritten.

But moving the application is not the same as moving the whole system. The databases, login systems, network setup, storage, and other services around it may still depend on the original provider. The tools made leaving easier, but they could not make every part of the system portable.

The industry moved to the cloud anyway because the benefits were enormous and the alternative was continuing to manage all of this yourself. Although the dependency was visible, many buyers decided the trade-off was worth it.

But once infrastructure began moving into this model, the crowded landscape of providers quickly began to thin to a handful of options. The reason was that building a successful cloud required two conditions that rarely existed together.

• The massive capital to build and operate data centres, networks, and global infrastructure at enormous scale,
• the engineering capability to run software systems as reliable services across that infrastructure.

Amazon had retail cash flow and the internal infrastructure problem that produced AWS. Microsoft had Office and Windows revenue, a huge installed enterprise software base, and growing experience operating internet-scale services such as Hotmail, MSN, and Xbox Live. Google had advertising cash and search-scale distributed systems.

The challengers tended to fail for different reasons depending on where they came from.

Traditional enterprise technology companies had capital, customers, and deep technical experience, but much of that experience had been built around selling hardware, software, and large managed systems rather than operating a continuously evolving public platform at internet scale. IBM acquired SoftLayer for $2 billion in 2013, invested billions more, and spent years struggling to combine incompatible internal architectures into a coherent cloud offering. HP invested about a billion dollars in Helion and shut it down in January 2016 after concluding it could not compete at that scale. Dell announced plans for its own public cloud, then abandoned them and shifted toward helping customers use other providers instead. Oracle entered late and still held only roughly 2 percent of the infrastructure market years after launching its cloud business.

The European telecoms had a different problem. Deutsche Telekom, BT, and Orange already had money, networks, data centres, and large customer bases, but operating communications infrastructure was not the same thing as building a programmable platform developers could use to assemble software on demand. They possessed much of the physical substrate, but not the software capability that had grown inside Amazon and Google from running enormous internet services. Deutsche Telekom's IT arm, T-Systems, fell from more than ten billion euros in annual revenue and fifty thousand employees to roughly four billion and half the workforce over a decade, eventually refocusing on helping customers migrate to AWS, Azure, and Google Cloud rather than competing with them.

And the more customers a provider had, the further its costs could be spread. Lower prices attracted more customers, more customers funded more services, and more services deepened the dependency. AWS accelerated the cycle through repeated price cuts backed by a much larger parent company. From its launch in 2006 to 2012, it cut prices more than twenty times. A standalone cloud provider had to fund everything from cloud revenue alone. Amazon could prioritise scale first and let profitability follow.

That made the middle of the market increasingly difficult to sustain. Providers that were too small to match the hyperscalers' scale, but too large to survive as niche specialists, gradually disappeared as independent competitors. GoGrid was bought and absorbed into a larger managed-services company. Joyent was acquired by Samsung and redirected toward Samsung's own infrastructure. Rackspace, once one of AWS's most visible rivals, eventually stopped competing with the hyperscalers directly and instead built a business helping customers run workloads on AWS, Azure, and Google Cloud.

Railroads, telephony, and electricity took decades to concentrate around a few large providers. Cloud did it in little more than one.

Today AWS, Microsoft, and Google receive roughly two-thirds of worldwide spending on cloud infrastructure. The same companies also control the login systems, the productivity software, the app marketplaces, and increasingly the AI services that run on top of it. They account for nearly half of all data-centre capacity worldwide. The share of data-centre capacity still run by companies on their own premises has fallen from more than half in 2018 to roughly a third.

The startup that once bought a server and placed it in a data centre increasingly begins inside a cloud account. The enterprise that once expanded its own server rooms increasingly rents capacity from an outside provider. Computing had moved away from machines the customer controlled and back toward large shared systems run elsewhere. The terminology was new (instances, serverless, microservices) but the basic relationship looked more like that of the mainframe era.

The machine had recentralised. But the buyer still had another form of independence. The software could still be owned, and the people who understood it could still build, specify, and replace it. Both of these were the next to go.

The product dissolves

When you bought software, you had it. A disc, a downloaded file, something that installed on your machine and ran there. The vendor could release a new version but couldn't take away the one you had. You could keep using it for years, refuse to upgrade, reinstall it if your computer broke. And software suites like Lotus 1-2-3, WordPerfect, Photoshop, Microsoft Office launched at several hundred dollars each. They were priced like equipment and were expected to last.

But ownership was gradually being hollowed from two directions at once. Since the early 1980s, each generation of anti-piracy restriction (copy protection, serial numbers, install limits, and finally online activation) made the copy harder to use freely. More importantly, each step extended the vendor's control further beyond the moment of sale. A transaction that had once ended when money and the copy changed hands increasingly left the vendor with continuing power to decide where the software could run, how often it could be installed, and eventually whether it would run at all. By 2001, Office XP and Windows XP required the software to contact Microsoft's servers before it would run. The copy still sat on your machine, but it would not start without the vendor's permission, continuing the relationship after the sale.

At the same time, owning the software mattered less if it could no longer work properly with the systems around it. This happened wherever one product's file format became widely used across an industry. Once customers, suppliers, colleagues, contractors, or public bodies exchanged work in that format, compatibility stopped being a convenience and became necessary for doing business. Microsoft Office in offices, Autodesk AutoCAD in engineering and architecture, and Adobe Photoshop in design were only the most visible examples. But the same pressure appeared in accounting systems, publishing tools, legal software, specialist engineering packages, and countless smaller professional markets.

Once enough of an industry exchanged work through one product's files, switching software no longer meant simply replacing a tool. It meant risking the ability to exchange work with everyone else. New versions could usually read older files, while older versions increasingly struggled with files created by newer ones. You still owned the copy. But part of its usefulness now depended on a file format and upgrade cycle controlled by the vendor.

By the late 2000s, the durable copy had lost ground from both sides. But it was still there.

What came next actually replaced it.

In 2003, Valve launched Steam and changed the relationship between the buyer and the copy. Instead of buying a game, keeping the disc, and proving ownership with a serial number, the purchase became attached to a Steam account. The game could still be downloaded and stored locally, but the right to use it now depended on an account maintained by Valve. The serial number had linked the copy to a purchase. Steam linked the purchase to an ongoing relationship with the vendor. Apple launched the iTunes Store the same year and pushed music in a similar direction. The record shop and the CD collection on the shelf were compressed into an account and a digital library. The files still lived on the buyer's computer, but the record of what had been bought and authorised increasingly lived with Apple.

The two platforms were selling different things, but both moved ownership away from a self-contained copy and toward a continuing account relationship.

At first, it still felt like ownership. If you bought a game on Steam, it remained in your library indefinitely. But what you owned now lived inside a library controlled by the vendor rather than on a shelf in your house. Adobe pushed the change much further in 2013. Photoshop, Illustrator, and the rest of its creative tools had previously been sold as one-off purchases, sometimes costing as much as $2,600. Adobe moved them entirely to a subscription of about $50 a month. More than 5,000 people signed a petition against the change, but Adobe went ahead anyway.

By the middle of the 2010s, subscriptions were becoming the standard model for professional software installed on the user's own computer. The program could still run locally, but the permanent right to keep using it was disappearing. Autodesk, whose software had become standard across large parts of engineering and architecture, stopped selling new perpetual licences in 2016 and moved customers toward subscriptions.

Microsoft followed a softer version of the same path. It still sells a one-time purchase edition of Office, currently Office 2024, but that version increasingly sits apart from the continuously updated Microsoft 365 product. The subscription version may look much like the software people once bought outright. The difference is simple: stop paying, and eventually you lose the right to use it.

And for many buyers, the switch to the subscription model was a relief. For Adobe users the $2,600 box had been a barrier while $50 a month was manageable. The subscription meant always having the current version without the compatibility anxiety of falling behind. The industry that had spent twenty years tightening the screw through activation and format pressure had finally offered an alternative that felt like freedom from exactly the problems it had created. The price was that you no longer had anything if you stopped paying.

Perpetual alternatives for these products still survive. Affinity offers photo editing, design, and publishing tools for a one-time purchase. DaVinci Resolve provides locally installed professional video editing software without a subscription. A popular free, open-source alternative to Microsoft Office for word processing, spreadsheets, and presentations, called LibreOffice runs entirely offline with no account or subscription. In each case the product works, but the market share is marginal. Currently roughly 18 percent of creative tools, under 5 percent of productivity, under 2 percent of gaming are outside the major subscription-based platforms. The alternatives still exist, but they are too marginal to shape the market.

But ownership was only one form of independence. An organisation that still understood how its systems worked could replace the product, commission another, or build around it regardless of whether it owned the copy or rented it. What changed next was that this capability began leaving too.

For most of the software industry's history, the systems a company depended on were built either by its own staff or specifically for it. Banks wrote their own trading systems. Airlines built their own reservation systems. Telecoms built their own billing systems. When something broke, their engineers could diagnose it because they understood how the system had been built and why. Larger organisations also hired specialist firms such as Logica, EDS, and Capgemini to build software for them. The outside company might leave when the project ended, but the software remained with the client.

The same model existed at a much smaller scale. A two-person software company in Athens might build invoicing software for accounting firms. A small company in Thessaloniki might write point-of-sale software for local retailers. Across southern and eastern Europe, Latin America, and much of Asia, many small software firms made their living by understanding what a local customer needed and building it for them. The requirements came from direct conversations with the customer. The software was delivered, installed, and ran on the customer's own machines.

In every case, the starting point was what the organisation actually needed, and the software was built around that.

From the 1970s onward, that relationship began to reverse. Companies like SAP, Oracle, and PeopleSoft offered a different model. Instead of building software around how one organisation worked, they built a standard product that could be sold to thousands of organisations and then configured for each customer.

And the economics strongly favoured that model. A product could be developed once and sold repeatedly, rather than rebuilt for every client. In 1970, US companies spent roughly three times as much on programming services as they did on software products. By 1985, companies were spending more on software products than on programming services. By 1990, spending on software products was roughly $34 billion, compared with about $10 billion on programming services. The shift made sense. A configurable package was cheaper to buy, easier to support, and easier to justify than a custom-built system. Alongside it came a new management assumption: custom-built IT was increasingly treated as costly, risky, and outside the organisation's real business. Buying the standard package became the disciplined choice.

And that argument was sound, but only up to a point. No organisation needed to build its own word processor, and no accounting firm needed a custom spreadsheet. For genuinely common tasks, standard software was cheaper, easier to support, and easier to maintain. But the same logic was gradually applied to systems that shaped how the organisation itself worked: how it managed customers, organised its workforce, and ran its operations. At that point, the vendor was no longer just supplying a tool. Its assumptions about how the work should be done were built into the product.

The financial case was easy to make because the costs of doing things internally were obvious. They appeared directly in staffing and IT budgets. The costs of adopting the vendor's way of working were harder to see. Consulting fees, process changes, switching costs, and the gradual loss of people who knew how to do things differently accumulated slowly across different budgets and over many years.

Previously, the customer could commission the core system and use external specialists to build it. But as packaged business software matured and multiplied, the vendor increasingly supplied the core system and the specialists were paid to make the customer fit around it.

SaaS completed the transition. When the software moved to the vendor's own infrastructure, everyone received the same product. Customisation shrank to configuration that offered the customer preset options the vendor provided. The vendor also took over deployment, upgrades, and infrastructure and ensured that every user was on the same version. The organisation's IT staff, already reduced by the package transition, lost another reason to exist as more of the work they had once performed moved to the vendor.

And much of that operational work had been genuinely wasteful. Maintaining an internal email server, patching an ERP installation, and running a data centre for a mid-sized company all consumed skilled people on problems that were not the organisation's core work. The decision to stop paying those costs was defensible. What was harder to see was that the work had not disappeared but instead had moved from the organisation's own staff into the vendor and consulting companies now doing it on their behalf.

And each replacement cycle reduced the organisation's internal technical capability further. Early enterprise projects still depended heavily on employees who understood the business and could explain its requirements to the people building the system. Later projects relied increasingly on vendor-certified consultants, while internal teams shifted from developers, architects, and systems engineers toward project coordination and vendor management. The knowledge of how the organisation's systems worked, and why they had been built that way, moved outward with them.

The migration is also visible in the spending. In the early 2000s, roughly sixty-five percent of enterprise IT budgets went to internal staff and development, with about thirty-five percent flowing outward. By 2024 that relationship had reversed: external services, software, and managed platforms accounted for roughly fifty-three percent, against forty-seven percent for internal staff.

The external software industry changed with it. Companies that had once built independent systems for clients were absorbed into larger consulting and integration businesses. EDS, once one of the world's largest independent IT services companies, was bought by HP in 2008 and later folded into a larger consulting business. Logica, another major custom-software and IT services firm, was bought by CGI in 2012. The surviving industry increasingly organised itself around major vendor platforms such as SAP, Salesforce, and Microsoft rather than around building a client's core system independently.

The technical work did not disappear. It moved into implementing and adapting those platforms. For major systems, implementation, integration, and migration can now cost several times the software licence itself. That money pays for people who know how to configure the vendor's system, connect it to everything else, and adapt the organisation around it.

But as more of that knowledge moved outside the organisation, another dependency formed. A company could keep using the system every day while gradually losing the knowledge needed to replace it. It might no longer know which processes were essential, why the system had been configured in a particular way, or what a replacement would need to do differently. The loss was not only of people who could build software, but of people who could define what should be built in the first place.

Some organisations still build and maintain their own systems. Walmart built proprietary supply chain technology when the doctrine said to buy SAP. JPMorgan Chase employs over fifty thousand technologists. In each case the capability works, but these are exceptions inside a market where the overwhelming majority run on software they do not control.

The buyer's exit had weakened twice over. They no longer owned the software, and they no longer retained the knowledge to replace it. But that dependency was not complete as long as independent alternatives could still reach customers directly.

The route gets gated

For most of the software industry's commercial history, getting software to customers meant getting a box onto a shop shelf. A developer usually needed a publisher or distributor that already had relationships with retailers. The publisher handled things like manufacturing, packaging and getting the product into stores, and the retailer took its own share when it sold. By the time everyone had been paid, the developer might receive only 30 to 40 percent of what the customer spent.

It was an expensive way to reach the buyer, but there were many publishers, distributors and shops. If one publisher would not take your product, another might. If one retailer stopped stocking it, others still existed. No single company controlled the route between the developer and the customer.

At the same time, shareware and download portals offered a parallel route. Download.com and Tucows hosted and listed software for users to find and download, but they did not take a cut of the eventual sale. The online payment was handled separately by small processors like RegNow, which took 5 to 15 percent. Discovery and payment were performed by entirely different entities with no relationship between them. A developer could use one site for visibility and a separate processor for payment, and replace either without affecting the other.

That changed when distribution, billing and access began to be combined in the same place. And the first systems to pull those steps together appeared on mobile.

NTT DoCoMo launched i-mode in Japan in 1999. It gave subscribers a curated menu of services chosen by the carrier, with purchases charged conveniently directly to the phone bill. DoCoMo handled the billing and took only a 9 percent commission, passing the rest to the service provider. The model grew rapidly and showed that a mobile carrier could control both access to services and the payment relationship around them.

Western carriers copied the architecture, but made it much more extractive. Vodafone Live!, Orange, O2 and T-Mobile built their own portals, while publishers and aggregators were inserted between developers and the carrier to handle contracts, billing and the work of adapting software to dozens of different handsets. Carriers could take 30 to 50 percent of the customer price before those intermediaries took their own share, leaving developers with less than half. By the mid-2000s, the carrier portal had become the normal route for reaching mobile users.

A few years later, gaming arrived at a similar model from a completely different direction.

Steam’s launch in 2003 had already tied purchases to an account, but it also solved another problem for Valve: the large share of revenue taken by the retail chain. Two years later, Valve began opening Steam to games from other developers, turning what had started as infrastructure for its own products into a general distribution platform. For developers, Steam offered a direct route to the customer at a 30 percent cut. For buyers, it replaced scattered retail with a single storefront and a single stored payment method. The intermediary chain that had defined PC game distribution was compressed to one step. The route was simpler, cheaper, and better for everyone inside it. It was also a single point of control where none had existed before.

The model expanded further into the gaming world. GOG launched in 2008 with a DRM-free model, and Epic followed with the Epic Games Store in 2018. Publishers like EA and Ubisoft built storefronts around their own catalogues. None of them managed to displace Steam, which still accounts for roughly three quarters of PC digital game sales. Even consoles followed the same pattern. By 2025, around 85 percent of PlayStation game sales were already digital. Physical retail remained, but its role was shrinking. As more games were bought and delivered digitally, the retailer no longer needed to hold and distribute the software itself. Even when a box was still sold in a shop, it could increasingly contain little more than a code that sent the buyer back through the platform's own storefront. The retail channel had not disappeared, but it was becoming an outer layer around a distribution route controlled elsewhere.

And on mobile, that transfer of control went further. Instead of merely reducing the retailer's role, the operating-system vendor could become the distribution route itself.

Apple released its first iPhone in 2007. Originally Apple expected third-party software to run as web applications inside Safari. Developers found that too limiting, and a jailbreak community appeared almost immediately to install native software outside the company's control. Apple's answer was the App Store launched in July 2008. It offered developers native access to the phone, but only through a single controlled route. Apple reviewed each app, handled distribution and payment, and kept 30 percent.

Compared with the carrier portals, this was a major improvement. The chain of developer, publisher, aggregator and carrier collapsed to developer, Apple, customer, while developers no longer had to adapt the same application to dozens of different handsets. But control had also moved somewhere stronger: from the carrier's portal to the operating system itself.

Google launched the Android Market the same year and applied much of the same structure. Two operating-system vendors now sat at the centre of mobile software distribution worldwide. The model then spread beyond phones. Apple launched the Mac App Store in 2011, and Microsoft built the Windows Store into Windows 8 in 2012.

But desktop distribution developed differently. A Windows or Mac user could still download software directly from a developer's website and install it, and by the time the stores arrived that route was already familiar and deeply established. The difference shows up in the market: The App Store and Google Play handle roughly 94 percent of mobile software spending, while the Mac and Windows stores account for only around 15 percent of consumer desktop software spending. On desktop, the store became another option rather than the default route.

Mobile was different because Apple and Google already had the customer before the store opened. Apple had iTunes, with hundreds of millions of people who had already stored a credit card, built a library and tied a device to an account. Google had the account people already used for email, search and maps. The storefront therefore arrived as an extension of an existing relationship rather than as a new one.

That made the default extraordinarily difficult to displace, even on a mobile operating system that remained technically open. Each purchase strengthened it further because the transaction left behind an account, a payment relationship and a library that accumulated over time. A rival store was not simply another shop. It asked the customer to establish a second commercial relationship alongside the one through which the device already worked.

Google Play arrived pre-installed, already connected to the user's account, already carrying their payment details and previous purchases. Amazon built a competing Android store and eventually withdrew it from ordinary phones. The European Union's Digital Markets Act later forced Apple to allow alternative app marketplaces on iOS in Europe, but creating a legal route did not recreate the old open distribution model. The alternative still exists inside an operating system, device relationship and account system controlled by Apple.

The infrastructure had recentralised. The copy had dissolved into subscriptions. The knowledge to build and specify independently had migrated outward. The route between maker and buyer had narrowed to a handful of gated storefronts. A company could, in principle, still change its cloud provider without changing its software vendor, or switch its distribution channel without renegotiating its identity.

The account becomes infrastructure

The previous three sections show how separability was lost. Infrastructure moved into shared platforms. Software became recurring access rather than a durable copy. The knowledge needed to replace or rebuild it increasingly moved outside the organisation. The paths through which makers reached buyers became fewer and more controlled.

But these were still separate dependencies. A company could, in principle, change its cloud provider without changing its software vendor, or switch its distribution channel without touching its other supplier relationships.

What changed that was something far more ordinary than any of them and that was the account.

The login, the email address, the stored credentials, none of these things looked like infrastructure. But as more systems began to depend on the same identity, relationships that had previously been separate could increasingly be joined through it. That is what makes the account different from the dependencies that came before.

Until then, identity had been fragmented by default. Your email address came from your internet service provider and carried nothing else with it. Your files lived on your hard drive and your bookmarks lived in your browser. If you wanted to participate in a forum, you created a username. If you wanted to join a different forum you created a different username. The companies you dealt with reached you directly. Your bank had your details because you gave them in person and a magazine subscription was between you and the publisher. Inside the enterprise, the structure was the same: an employee might log into the network with one set of credentials, open a completely different email system with its own password, and access a VPN with a third. It was inconvenient, but each system was independently replaceable. No single entity could see all of a person's relationships at once, and losing any one account left the others untouched.

Gmail changed the consumer side of this. Before services like Gmail became dominant, an email address was often something that came with an internet connection. Change provider and the address might disappear with it. Gmail broke that relationship. Google launched it in 2004 with a gigabyte of free storage, at a time when services like Yahoo offered only a few megabytes. This gave people a reason not only to move their email away from the company providing the connection, but to keep the same account for years. Instead of constantly deleting old messages to stay within a tiny storage limit, or carefully filing emails into folders so they could be found again, users could let their correspondence accumulate and simply search through it later.

That was crucial because the address could now outlive the infrastructure underneath it. You could change internet provider, move house, replace your computer, or change phone company and still keep the same Gmail address. Over time, that persistent address became more than somewhere people sent messages. It became the stable identifier through which other people and other services continued to recognise you.

But the address didn't stay a communication channel. Services started using it as a contact field making it the way they reached you. Then they began using it as a verification channel making it the way they confirmed you were who you said you were. Then it became the recovery mechanism, essentially the way you got back into every other account when you forgot a password. Then, for many services, it became the login itself. "Sign in with Google" turned the email address into a skeleton key, and everything else accumulated around it: calendar, storage, documents, photos, contacts, payment methods, logins to services that had nothing to do with email. Each addition was a convenience. But the accumulation of these conveniences was also a dependency.

The critical transition came when the account stopped being just the way you used Google's own services and became the way other people and organisations reached you too. When your calendar was a Google calendar, other people scheduled meetings with you through Google. When your documents were Google documents, your colleagues collaborated with you through Google. Once your email became the recovery address for your bank, your employer’s VPN, or your children’s school portal, access to those services partly depended on keeping that Google account whether those institutions had chosen Google as a supplier or not. Google was no longer just serving you; it had become part of how other organisations reached and recognised you.

Microsoft reached the enterprise side through a different door, and much earlier.

Through the late 1990s, corporate email and corporate identity were separate systems. Platforms like Lotus Notes or Novell GroupWise had their own directories. An enterprise could replace one without disturbing the other. Active Directory, which launched with Windows 2000, was built into the operating system itself as a directory for the organisation: its employees, computers, groups, and the permissions connecting them. It gave the company one place to define who belonged to the network and what each person or machine was allowed to access.

The critical step came when Exchange 2000 dropped its built-in directory entirely and required Active Directory to run. From that point on, the email system and Windows’ identity system were architecturally inseparable. One corporate account could now govern access to the network, files, mailbox, applications, security policies, and remote access. Any system using Windows authentication depended on the same directory. The organisation increasingly operated through it.

And to be fair this solved a real problem. Before the joining, enterprise identity was a security catastrophe. Employees reused passwords across dozens of systems because each demanded its own. A terminated employee could retain access to half the company's tools for weeks because there was no central place to revoke it. Things like conditional access, instant deprovisioning, enforced multi-factor authentication across connected applications, all these were genuine achievements that made organisations materially safer. But with the benefit came the structural cost. Once email, identity, and access to other applications depended on the same directory, replacing that directory no longer meant changing one system. It meant potentially reconfiguring access across large parts of the organisation.

Then the cloud migration carried the joined system outward. Exchange moved from a server the organisation operated itself to Exchange Online in Microsoft 365. Identity moved more gradually. Companies could still keep Active Directory on their own networks, but Microsoft introduced Azure Active Directory as the identity layer for its cloud services. Over time, that cloud identity system (now Entra ID) took on more of the work of deciding who belonged to the organisation and what they could access.

Once that identity layer was established in the cloud, Microsoft could attach more services to it. Things like SharePoint for documents, Teams for communication, Power BI for analytics, Dynamics for CRM. Each used the same identity backbone, so adopting another Microsoft service no longer meant establishing an entirely new relationship. It was increasingly just another room in a building the organisation had already entered.

But the deeper change came when the directory began reaching outside the organisation. Third-party applications such as Salesforce, ServiceNow, and Workday could use Entra ID to recognise employees and apply the organisation’s access rules. Microsoft’s directory was no longer just managing access to Microsoft systems. It was becoming the gateway through which employees reached software supplied by other companies.

This was not universal. Organisations built heavily around Unix or Linux could retain independent identity systems using LDAP, Kerberos, FreeIPA or similar tools. But that path remained mostly confined to specialist environments. As Linux spread through enterprise servers, most organisations did not build a separate workforce identity around it. They connected those machines back into Active Directory, and later into the same small group of cloud identity providers used by the rest of the organisation.

Apple reached a similar position from a different direction than Google or Microsoft: through the device. For the consumer, the Apple ID came to govern the phone or computer itself, along with purchases, iCloud storage, messages, payments, backups, and device recovery. With Activation Lock, the account could even determine whether the physical device could be used at all.

But Apple never became the organisation’s directory in the way Microsoft did. Companies could manage Apple devices through their own management systems while the employee’s Apple identity remained separate underneath. Apple therefore captured the device layer without absorbing the organisation’s identity layer. This was a different route to dependence, and showed an important limit on how far that type of capture extended.

And what determines how far that capture can extend is not simply how many users a company has, but what the account has become responsible for. Meta provides a useful counterexample precisely because it did push identity beyond its own services. Facebook Connect and later Facebook Login allowed people to use their Facebook identity on third-party sites and apps, carrying parts of their profile and social graph with them. But that reach stopped relatively shallow. Meta never became the identity layer through which organisations managed employees, devices, documents, cloud infrastructure, or most of the other systems people relied on for work and daily operations.

Lose a Facebook account and some third-party logins may need to be replaced, along with access to Meta’s own services. Lose a Google account that other services use for login or recovery, and access to systems Google does not operate may also be affected. In an organisation, lose the identity system employees use to enter dozens of applications, and access to those applications can fail even though they belong to completely different vendors. Google and Microsoft went further because their identities became attached not only to authentication, but to communication, storage, productivity, devices, administration, and cloud services.

That is the important distinction. An account becomes infrastructure not merely when other systems can recognise it, but when enough important systems begin relying on it that losing the account disrupts activity beyond the vendor’s own products. Its importance is therefore not measured by user count or third-party login adoption alone, but by the depth and breadth of the dependencies accumulated around it.

Beneath these identity systems sits another dependency that is easier to see from the security literature than from market analysis. Email still serves as a recovery mechanism for many online accounts, which means compromising one inbox can unlock access to services operated by completely different companies. Researchers have described email as a kind of “master key” and mapped the chains and loops created when accounts recover one another.

What has not been mapped is the provider-level structure underneath those chains. We do not know how many Microsoft accounts rely on Gmail, how many Apple accounts were created with Gmail addresses, or which provider sits at the bottom of the largest number of recovery paths. The dependency exists but its distribution does not appear to have been measured. And almost all of the existing research treats it as a security problem rather than asking what it means when competing identity providers depend on one another for recovery.

But whatever the original path by which these dependencies accumulated, the commercial value of controlling an identity layer did not remain accidental forever. By 2023, Microsoft was describing that value openly to investors. Charlie Bell, then EVP of Microsoft Security, said that Entra contributed to “indirect monetization” elsewhere in the stack. In 2024, Chief Commercial Officer Judson Althoff explained that once enough identity protection was in place, customers could “graduate” into the more expensive Microsoft 365 E5 tier. Another Microsoft executive described the broader sales motion even more plainly: secure the licence first, then upsell to increase revenue per user. The joined account had not necessarily been designed as a capture mechanism from the beginning. But by this point, its ability to expand the commercial relationship was understood and deliberately used.

Infrastructure, software, distribution, and payment could now all recognise the same customer. Changing one of those relationships could therefore disrupt access to the others as well. And once other companies began depending on that identity to reach the same customer or employee, identity did something the other dependencies had not. It turned separate dependencies into a single connected system.

The window that closed

Infrastructure recentralised. Ownership dissolved into subscriptions. The route between maker and buyer narrowed to a handful of gates. And identity joined them into a single system.

The obvious question is why none of this triggered some kind of response. And it should have, because none of these changes went unnoticed. In 2009, a UC Berkeley research group noted that cloud APIs were "essentially proprietary" and that they made it difficult for customers to extract their data and programs. The same year, the European Network and Information Security Agency classified vendor lock-in as a critical, top-tier structural security risk. And in March 2009, an IBM-led coalition that included Cisco, HP, Sun, SAP, Red Hat, and AT&T published the Open Cloud Manifesto calling for open standards and mandatory interoperability. Not surprisingly, AWS, Google, Microsoft, and Salesforce refused to sign it.

Standardisation efforts followed over the next several years. Apache Deltacloud, launched in 2009, offered an open API intended to let the same tools manage multiple cloud providers. DMTF's Cloud Infrastructure Management Interface, introduced in 2011, aimed to standardise how cloud infrastructure was managed across vendors. The Unified Cloud Interface project, developed between 2008 and 2010, attempted something broader: a common interface across different cloud services.

Each was trying, in a different way, to recreate the separation that open protocols had provided at the network layer. None succeeded. The dominant providers had no commercial incentive to implement standards that would make their services easier to replace, and no institution had the authority to require them to do so. The risks of outsourcing had been discussed in management literature for decades. Identity concentration was not a new concern either; it had already prompted a direct institutional response once before, in the FTC’s 2002 Passport consent order.

When Microsoft launched .NET Passport in 1999 as an explicit attempt to create a universal identity system, it ran into resistance from several directions. Microsoft was already fighting a federal monopolisation case over its use of Windows to extend control into adjacent markets. Sun and other technology companies organised the Liberty Alliance to build an alternative identity standard rather than let Microsoft become the default. And users and businesses were wary of placing a single company between themselves and large parts of the web. Together, those pressures were enough to stop Passport from becoming the universal identity layer Microsoft had envisioned.

The institutional apparatus could recognise identity capture when it arrived as an explicit proposal. Passport announced what it wanted to become, and that made the threat easy to identify. But what followed over the next decade looked nothing like that. Gmail offered an email address that stayed with you when your internet provider changed. That address became a recovery mechanism, then a login, then a way into services operated by other companies. No single step looked like the construction of an identity infrastructure, so no equivalent response ever formed.

And the same problem extended beyond identity. Proprietary formats were treated as a competition problem. Outsourcing dependency was treated as a management problem. Identity concentration was treated as a privacy problem. Cloud lock-in was treated as a procurement problem. Each issue was visible, and sometimes produced a response, but each was examined inside its own category. What the institutions failed to recognise was that these apparently separate problems were becoming parts of the same structure. And they were reconstructing the kind of joined dependency that earlier generations had learned, at considerable cost, to prevent.

The earlier institutional response followed a specific logic. It did not try to prevent infrastructure from consolidating where the economics pushed it that way. What it did was prevent the company that owned the infrastructure from automatically controlling everything built on top of it.

Part 2 of this series traced three versions of that logic. The 1956 AT&T consent decree drew a boundary around the telephone monopoly and kept it out of adjacent markets. IBM's 1969 unbundling separated software and services from the machine, helping create an independent software industry. And when the internet backbone was privatised, open interconnection conditions preserved a network in which no single operator could decide who reached whom. The mechanisms differed, but the principle was the same: concentration at the foundational layer did not have to mean control over the layers above it.

Each of those arrangements, however, was tied to the technology it had been built around.

The AT&T decree was formally superseded by the 1982 Modified Final Judgment, the agreement that led to the breakup of the Bell System in 1984. Its successor imposed new restrictions on the divested telephone companies, but those were progressively relaxed through the late 1980s and 1990s, and the Telecommunications Act of 1996 replaced much of the old framework with a different statutory regime. The containment principle survived inside telecommunications law, but it was never carried forward into the new computing platforms, software companies, or the cloud providers that were becoming the new infrastructure.

The IBM case was dismissed in January 1982, the same month as the AT&T settlement. By then the separation between hardware and software had become commercially established and did not disappear with the case. But the principle behind it was never applied again. The cloud providers began gradually to rebundle infrastructure with databases, applications, identity, and distribution. They essentially reconstructed at a higher level the kind of joined stack IBM had once controlled but no institution treated it as the same structural problem.

The internet case was different again. The openness itself survived. TCP/IP, HTTP, SMTP and the basic exchange architecture remained open, and no single company gained ownership of the network layer. But that principle stopped there. The services built above the network were not given equivalent conditions. Cloud APIs, document formats, identity systems, and application marketplaces could become proprietary infrastructure even though the network beneath them remained open. The old boundaries had not simply vanished. They had remained attached to the layers they were designed for while computing moved upward into new ones.

And while these protections were fading, the way concentration was judged was changing too. The question increasingly became not whether one company controlled the layers above its infrastructure, but whether consumers were paying more or getting less. The shift was a response to real problems with the old way of judging monopoly power. The tests for deciding when a company’s size or market position had become a problem could be subjective, and different officials could reach different conclusions about the same market. The new approach tried to make the test more concrete by focusing on things that could be measured clearly, especially things like prices and output.

That made some cases easier to judge, but it also narrowed what counted as a problem. If prices stayed low and services kept improving, a company could still become deeply embedded in the infrastructure around an industry without triggering the same concerns it did based on the old rules.

Between 1984 and 1989, the Department of Justice filed no civil monopolisation cases in any industry. These were also the years when the personal computer industry was consolidating and the software market was taking the shape it would keep for the next two decades. By the time SaaS and cloud began to consolidate, this kind of structural concentration was harder to recognise as a problem. Prices were falling, services were improving, and cloud infrastructure was cheaper and easier to access than what it replaced. By those measures, the system looked like a success.

And software moving onto the network created dependencies that the older safeguards had never been designed to address. Control could now come through subscriptions, proprietary interfaces, identity systems, and outsourced capability rather than ownership of a physical network or machine. The old separations still existed, but they did not reach these new layers.

There was another difference. In the earlier cases, government had often helped build, organise, or use the infrastructure while still retaining the power to investigate the companies that came to dominate it.

Farmers organised against the railroads through the 1870s, building enough pressure that Congress created the Interstate Commerce Commission in 1887, six years before the financial panic of 1893 triggered a severe national depression. The Senate ordered the Federal Trade Commission to investigate electrical holding companies in 1928, a year before the crash. That investigation ran for six years and produced 101 volumes of evidence that fed directly into the Public Utility Holding Company Act of 1935. The FCC began investigating AT&T in 1938, nearly two decades before the 1956 consent decree.

In each case, government was not standing outside the system. Through railroad land grants, utility franchises, and the sanctioned telephone monopoly, it had helped build, finance, franchise, or legitimise the infrastructure while still retaining the power to investigate the companies that controlled it. That dual role meant evidence was already being gathered before the crisis arrived. When correction became politically possible, much of the case had already been built.

SaaS/cloud also received government support. In 2011, Cloud First required federal agencies to consider cloud services before making new IT investments, pushing more government systems toward commercial cloud providers. But no equivalent structural investigation developed alongside that push. Government promoted the new architecture without building the counterweight that had existed in earlier infrastructure eras.

To be fair, institutional attention has not disappeared. US state attorneys general have pursued technology companies over privacy, competition, and consumer protection. Federal agencies have also brought major cases against companies such as Google and Meta. Outside the US, the EU's Digital Markets Act and Data Act, and the UK CMA's cloud investigation, address parts of the same problem.

But they mostly focus on behaviour within the existing system: how companies use data, how hard it is to switch, or whether competition is being restricted inside a particular market. They do not ask the older structural question: should the company that owns the infrastructure also be allowed to control the layers built on top of it? The focus is mainly about making the current structure work better, not about whether parts of it should be separated.

Jurisdiction makes the problem harder. The companies that own all this infrastructure are American. In the earlier infrastructure binds the separations between the core infrastructure and the markets built on top of it were imposed by the US federal government. Authorities outside the US and individual states can set rules for their own markets, but they cannot reorganise these companies globally in the same way the US federal government could.

And even the current federal cases mostly seek to change how companies behave, not how they are structured. And the federal government itself is now deeply dependent on the same system it would have to examine: its agencies run on hyperscaler infrastructure, buy through the same vendor ecosystems, and reproduce many of the same dependencies through procurement.

There was a period when this could still have gone differently. When the cloud was new, when subscriptions had not yet replaced ownership across much of the industry, when identity had not yet become part of the same stack, and when many organisations still retained more of the ability to build and operate systems themselves.

At that stage, the dependencies were easier to address because they had not yet become tightly joined. Software sold by subscription could still have been required to leave customers with a usable copy if the service ended. Cloud providers could have been required to make it easier for customers to move their software and data from one provider to another, even if the exact technical standards took time to develop. People could have been given a way to move their digital identity from one provider to another before a single account became the key to accessing many different services.

The problem was that nobody required these protections while the system was still taking shape. At the same time, the US federal government was judging concentration mainly through prices and output while also becoming a customer of the same cloud and software systems it would have needed to examine.

That window closed. Once infrastructure, software, distribution, and identity had become tied together through the same accounts and platforms, separating them became much harder. It was no longer enough to place a rule around one part of the system. Doing so would mean pulling apart systems that entire organisations now depended on, often after much of their own technical knowledge had already moved outside the organisation.

The old safeguards had been designed for a world where these layers were still separate enough to deal with one at a time. By the time anyone might have tried to use them again, the system had become too tightly connected for those older tools to fit.

The field narrows

In the earlier double binds, innovation was suppressed by controlling access. The railroad that owned the only track into a region could decide which businesses reached customers cheaply enough to survive. An independent oil refiner might have a better product, but a larger rival that could promise the railroad steady volumes might secure lower freight rates. That advantage could wipe out the smaller refiner’s edge before the market ever tested it. An electrical holding company that controlled the local utility could favour its own generating companies or affiliated suppliers when deciding who received access to the grid, putting an independent producer at a disadvantage before it had a fair chance to compete. AT&T went further and controlled what could physically connect to the telephone network: independent answering machines, modems, fax machines, and other devices could be excluded unless AT&T allowed them.

The mechanisms differed, but the effect on the market was clearly visible. A competitor could build something better and still be prevented from reaching the customer, connecting to the infrastructure, or competing on equal terms. The innovation existed but the bottleneck stopped it from spreading.

But the SaaS/cloud structure rarely excludes anything outright. What it does is quieter and in some ways more complete. It shapes which futures can plausibly exist. And it does that less by blocking alternatives than by making some of them harder to see, harder to finance, and harder to fit into the structures through which products are bought, staffed, and built.

The shaping begins with the loss of internal technical capability documented earlier in this article. When the people who understood how the organisation's systems worked leave or are replaced, the organisation loses more than day-to-day control. It also loses some of its ability to define what it needs without relying on vendors, consultants, or existing product categories to frame the problem. Procurement that once began with "what should this system do?" increasingly begins with "which product in this category should we buy?" The question narrows before the evaluation starts. And as buyers default to familiar products, those vendors gain more customers, more consultants, more case studies, and more reasons for the next buyer to choose them too. That pulls still more knowledge toward the vendor and away from the buyer.

The loss feeds the narrowing, and the narrowing accelerates the loss. None of it requires anyone to refuse an alternative outright.

Enterprise buyers increasingly shop through product categories that the largest vendors helped define. If an organisation needs to manage customer relationships, it buys a CRM. If it needs to manage its workforce, it buys an HCM platform. Most major CRM systems are built around the same basic model. Sales opportunities sit in a pipeline, move through stages, appear on dashboards, and feed into forecasts. Companies can customise the fields and workflows, but the underlying logic is similar: selling is represented as a sequence of stages that management can track and measure. That model is genuinely useful, especially in large organisations. But part of its strength is that it is easy to measure and manage. Stages can be recorded, counted, compared, forecast, and reported upward. Alternative approaches like relationship-based or trust-based selling are much harder to reduce to the same kind of dashboard.

The software did not invent this model from nothing. It selected and formalised the parts of existing sales practice that could be turned into software. Once that happened, the resulting model became easier to buy, staff, compare, and report on than approaches that did not fit the same structure. A company that asks "which CRM should we buy?" has already accepted the basic shape of the answer. The harder possibility to imagine is that it might manage customers in a completely different way, using a system that would not look like a CRM at all. The choice looks open, but the question has already narrowed it.

And the loss goes further than making existing alternatives harder to see. Once an organisation stops building systems around its own way of working, it also loses some of the ability to evolve and develop new ways of working that do not fit an existing product category. A different sales process does not have to be rejected by a CRM vendor to disappear from consideration. If the organisation no longer has the people or the software capability to turn that process into a working system of its own, the idea may never get far enough to become an alternative at all.

None of this means that standardisation itself is unusual. Large organisations have always tried to make work easier to compare, manage, and coordinate, and global businesses need common systems to operate across countries. But coordination does not require every organisation to adopt the same underlying process model. Different firms can work internationally while keeping different internal methods, suppliers, and technical systems.

The important change is where the standard increasingly comes from. It is no longer only an organisation deciding how to organise itself. The product category, software architecture, consultant ecosystem, procurement rules, and professional training increasingly arrive from outside the organisation before that decision is made.

And once the organisation accepts the preformed category, the next choice is narrower still. In 6sense's 2025 study of nearly four thousand enterprise buyers, the vendor eventually chosen was already on the opening list ninety-five percent of the time. Four out of five deals went to the vendor the buyer had ranked first before speaking to a salesperson. That ranking comes already influenced by the dominant vendors' case studies, the features the category has taught buyers to compare, and what their peers already use. Much of the choice is therefore shaped before the formal sales process even begins.

Cloud marketplaces add another advantage for products already inside the existing stack. Large companies often agree in advance to spend a fixed amount with AWS, Azure, or another large cloud provider over several years in exchange for better pricing and commercial terms. All these are advantages that smaller providers are much less able to match. A Fortune 500 company might even commit tens of millions of dollars in these arrangements. Software bought through the provider's marketplace can count toward that commitment while software bought elsewhere usually does not. So if a company is choosing between two similar products, the marketplace option can use money it has already agreed to spend, while the outside option needs separate budget. Buyer surveys show the effects of all this: many enterprise purchasers say using up existing cloud commitments is a major reason for buying through a marketplace. The outside product simply starts at a disadvantage.

The consulting industry reinforces the same pattern from the implementation side. When a company chooses software, it is not only choosing the product. It also has to ask who can install it, adapt it to the organisation, and keep it running afterwards. That gives large platforms another advantage. SAP reports more than twenty-five thousand partners delivering roughly ninety percent of its customer implementations. Salesforce counts more than a million partner certifications across its ecosystem. Microsoft's partner network includes more than four hundred thousand organisations. A large installed base attracts more consultants and integrators because there is more work available. That larger pool of expertise then makes the platform easier and less risky to implement. And when implementation looks easier and safer, the product itself becomes easier to approve and procure. Each new implementation then expands the installed base again, which attracts still more expertise around the platform.

Business education reinforces the pattern too. SAP provides ready-to-use teaching material to more than three thousand universities across over a hundred countries. Students do not simply learn general ideas about how businesses hire people, buy supplies, or manage sales. They learn those processes through SAP's own system and its own categories: Recruit-to-Retire, Source-to-Pay, Lead-to-Cash, Design-to-Operate. They complete exercises inside SAP software and can earn SAP certifications as part of their studies. Salesforce does something similar through Trailhead and university partnerships, where students learn CRM concepts while working directly with the Salesforce platform. So graduates leave with more than the vendor's vocabulary. They have learned how the vendor represents the work, how its system expects the process to run, and often how to operate that system themselves. The vendor's model has become part of their professional training.

Everything so far describes how the buyer's field is narrowed. But the narrowing does not stop at procurement. It reaches back further into what gets built in the first place.

A software startup in the 1990s could begin with a computer, a developer, and access to an open internet. Today, a startup is much more likely to begin inside a cloud account, build on services that belong to that provider's ecosystem, and raise money from investors who already treat that architecture as normal. The financing system then measures the company using a standard set of SaaS metrics: recurring revenue growth, customer retention, gross margin, customer acquisition cost, and lifetime value. Those measures are useful, but they also make some kinds of companies easier to understand and value than others. And the same pressure appears when the company tries to sell. Enterprise buyers may expect recognised hosting, single sign-on, security certification, and familiar contract structures. Distribution may depend on marketplaces or storefronts that impose their own rules and account systems.

None of these gates necessarily rejects a different company outright. But a company whose architecture, revenue model, or distribution strategy does not fit the expected pattern is harder to fund, harder to buy from, and harder to distribute. The problem is that the surrounding system is better prepared to recognise one shape than another.

When shaped demand meets shaped supply, the result can look like ordinary market selection. The buyer arrives expecting a CRM-shaped answer. The startup has already learned that a CRM-shaped company is easier to fund, sell, and procure. When they meet, the purchase appears to confirm that this is simply what customers wanted. But both sides arrived with their choices already narrowed. And the successful sale then reinforces the pattern: it becomes another customer reference, another reason for consultants to specialise in the category, and another data point showing investors and future buyers that this is the shape that works.

None of this is visible from inside. The buyer sees choice, the builder sees opportunity, and the investor sees a market. The narrowing only becomes visible from the position of someone who has built something that doesn't fit.

Suppose a founder has built something genuinely different: a new way of working, a new kind of tool, something that could be built for twenty thousand euros and sold from a server with a fibre connection. And suppose it works remarkably well.

The difficulty begins when the founder tries to reach the market. Selling to enterprises may mean meeting expectations around certification, integration, recognised hosting, marketplace availability, security, and procurement. Selling to consumers brings a different set of pressures. The founder has to be discoverable through search, social platforms, app stores, or advertising; handle payments and accounts in the forms those channels expect; and often comply with platform rules before the product can reach the buyer at all. Seeking outside funding means entering a system that is most comfortable with recurring revenue, cloud architecture, growth, retention, and other metrics that became standard for evaluating SaaS and cloud businesses. These gates don't necessarily block the company. But each asks the founder to make decisions about scale, architecture, revenue model, and company structure before the market has provided enough evidence to show which answers are actually right.

The twenty-thousand-euro business can therefore become a two-million-euro seed round. Some of that extra money buys capability the company may genuinely need as it grows: security, authentication, reliable billing, support, and infrastructure that can handle more users. But some of it buys those capabilities before the company knows whether it needs them at that scale. And some buys something else entirely: legibility. The company needs the right shape, the right metrics, and the right language to be understood by investors, buyers, and distribution channels. Even the language of startup pitching reflects this pressure to appear as something familiar: "the Salesforce for X," "the Uber for Y." A new idea becomes easier to explain by translating it into a form everyone already recognises.

The result is that the cost of becoming a company can rise far above the cost of proving the product itself. That extra cost arrives before the founder knows whether the market actually needs it.

And once the founder pays that cost, the pressure does not stop at the company around the product. It can begin changing the product itself. The company runs on the same cloud, adopts the same subscription model, reports the same metrics, and builds for the same procurement and distribution channels as the companies it might otherwise have challenged. Features that help it fit those channels are easier to justify than features that do not. Decisions about architecture, pricing, and target customers begin to reflect what the surrounding system expects. The invention may still be somewhere in there, but the company that reaches the market may no longer be the company the original idea would have produced.

Competition inside the permitted shape is not the same as competition over the shape itself. Faced with that shape, a product might be reshaped into something recognisable, remain small enough to escape the system, or never get funded at all. The market can still look highly competitive because many companies are competing inside the same basic model.

What is harder to see are the alternatives that never became large enough to leave evidence behind. They have no customers, balance sheets, or market-share statistics to count. The earlier software economy described in this article allowed many more small firms, tailored systems, and different architectures to coexist under lower capital requirements and more open distribution.

The comparison alone cannot prove how much of the lost diversity came from these pressures; some other features of the software economy changed as well. But many of the changes that made alternatives harder were themselves part of the same transition to the SaaS/cloud. Things like greater platform dependence, standardisation, consolidation, and growing implementation requirements all developed inside that shift.

That makes the pattern consistent with the pressures documented above. When financing, procurement, distribution, implementation, and professional training all make some forms easier to recognise and support than others, we should expect fewer different forms to reach the market.

The bind that doesn't break

Not every double bind ends in financial collapse. After the Panic of 1893, a quarter of American railroad mileage entered bankruptcy. The electrical holding companies collapsed a generation later, with fifty-three major companies bankrupt and hundreds of thousands of ordinary investors wiped out. In both cases, the financial system eventually made the bind impossible to ignore.

But AT&T's double bind followed a different path. The industrial costs were obvious: the network required enormous, continuous investment. The loss of value was much quieter. The closed boundary held back independent equipment makers, data services, and entire industries that would only emerge once the system was opened. The value they might have created disappeared before it had the chance to form.

By the time AT&T's monopoly had consolidated, the United States had already learned something from the railroad and utility disasters. The telephone system was financed more cautiously, its rates were controlled, and its owners received steady rather than spectacular returns. The financial arrangements that had allowed railroad debt and electrical holding-company pyramids to spiral out of control had largely been removed. AT&T did not need a new wave of speculation to keep the network running. Every month, millions of subscribers paid into a system that generated enough reliable income to maintain the infrastructure and give its owners a predictable return.

For most of the twentieth century, the American telephone system worked remarkably well. Service was reliable and eventually near-universal. The equipment was engineered to last decades and did. And at the centre of the system sat what may have been the most productive research institution ever assembled: Bell Labs, the research laboratory that invented the transistor, information theory, the solar cell, the laser. Whatever the bind was costing, it was not competence, and it was not progress. The money circulated in a closed loop. The research produced patents, the manufacturing arm built the equipment, the operating companies bought it at internally set prices, and the cost settled into the rates every subscriber paid. There was no panic or rush to exit because there was nothing that looked like failure.

But the cost sat somewhere else, and it did not look like a cost at all. AT&T controlled what could connect to the network, which meant outside companies could not simply build a new device and sell it to telephone customers. Modems, answering machines, fax machines and other equipment all depended on AT&T allowing them onto the system. Fax technology, for example, had existed for decades before it became widely available over the telephone network.

And AT&T made absolutely sure things stayed that way. When a small company attempted to sell a plastic cup that snapped over the mouthpiece so a caller could speak privately, they took them to federal court. In the end it took an appeals ruling just to establish that a customer could attach a piece of plastic to their own telephone. And no alternative network could easily grow around the edges, because any rival whose subscribers could not reach Bell's customers was at an immediate disadvantage. None of this registered as loss. Subscribers received excellent service from the dominant system and had little reason to notice the possibilities that never developed outside it.

That is the shape of the second kind of bind. The gap is between what the system delivers and what might have developed if its boundaries had been more open. And that gap is almost impossible to see at the time, because nobody can point to what was never allowed to grow.

What eventually closed the gap was not the market. Federal investigations into AT&T's monopoly and business practices had been building since the late 1930s, and the case against Bell was filed in 1949. What appears to have changed the outcome was the Second World War, which brought government scientists and military engineers directly into Bell's research system. After years of working alongside Bell researchers, they understood not just what the system could do, but what its closed structure was holding back. The 1956 consent decree drew on that knowledge. The war created the opening, but the investigators, lawyers, and institutions capable of acting on it were already in place.

We cannot know what would have happened otherwise. The pressure might eventually have forced a more abrupt break, or the system might have continued for decades, excellent and closed. What we can see is what followed the decree: answering machines, modems, fax machines, independent equipment makers, and eventually entire industries built on data moving over telephone lines. Many of the underlying ideas had existed for years. What the bind held back was the conditions that allowed inventions to become industries. And that is the difficult part: the scale of the loss only became visible after the boundary opened.

What the SaaS/cloud structure shares with AT&T is not the mechanism, but the difficulty of seeing the cost while the system is working well. The individual dependencies were visible early in its formation. What was harder to see was how they were beginning to reinforce each other. The SaaS/cloud system delivered cheaper infrastructure, better software, and broader access than what came before. By the measures institutions had come to rely on (lower prices, better services, broader access) the system looked successful. What those measures could not show was what kinds of alternatives had become harder to build, fund, or reach.

But there is also an important difference. AT&T was one company. Its telephone network, equipment business, research arm, and operating companies all sat inside the same system, so the boundary around it could at least be identified. The SaaS/cloud structure is spread across several companies instead. Microsoft might control the identity an organisation uses to reach software running on AWS, while Apple controls how another company reaches the customer. Financing, procurement, and distribution can reinforce those relationships without any one company owning the whole system. There is therefore no single boundary to open. The old solution was to contain the infrastructure owner and keep the layers above it open. That does not map neatly onto a system whose dependencies are spread across several firms.

The railroads and electrical holding companies eventually made their failures visible through collapse. AT&T did not; its stability concealed the cost until the boundary was opened. The SaaS/cloud system did not crash either, and no comparable accident of history forced it open. Whether it had genuinely stabilised or was already building toward some other correction cannot be known, because AI interrupted that trajectory.

AI arrived inside the structure those decades had built: the same cloud accounts, subscription models, venture circuits, and procurement channels. What it added was something SaaS/cloud had not yet produced: industrial-scale infrastructure costs colliding at a frantic pace with a technology that erodes the revenue base meant to pay for them. That changes the balance fundamentally. The system is no longer following the relatively stable path SaaS/cloud had settled into, and what happens next is much harder to predict.

Was all this inevitable?

At the end of Part 1 I asked whether any of this was inevitable. Whether the only possible path for a transformative technology like AI was to be bound to nineteenth-century economics, existing capital structures, and the infrastructure owners and procurement channels that were already in place.

Part 2 of this series showed that the bind was broken once. The consent decree, the unbundling, and the conditioned privatisation were all specific decisions, made by specific people. Each prevented the owner of a foundational layer from controlling everything built above it. The escape was not a natural outcome of technological progress. It was engineered by people who understood how control over infrastructure could shape the markets built above it, and who acted before those boundaries closed.

This article has shown how that escape was gradually reversed. Each step was individually rational, but together they rejoined relationships that earlier decisions had deliberately separated. At the same time, the tools that had kept those relationships apart expired, were redesigned, or were never rebuilt for the new dependencies taking their place.

Was this inevitable? The history suggests that the bind itself may be hard to avoid. What is not inevitable is how it breaks. The escape proved that the bind can be opened deliberately, by specific people making specific decisions, without waiting for the crash. New forms can be allowed to emerge without destroying the system that came before them, or the economy around it.

What was not inevitable was that those earlier separations would be allowed to disappear. The rules that had once kept infrastructure, software, and distribution from collapsing into the same hands were tied to a very different technological world. They cannot simply be reapplied to a system built from cloud services, subscriptions, identity layers, marketplaces, and dependencies spread across several companies. And before anyone has worked out what could replace them, AI is already changing the economics of that system. Whether a different arrangement can be built again and what it would require when the previous instruments no longer exist is the subject of Part 4.