The Perpetual Upgrade: Software's War Against the Product You Already Own
In 1924, representatives of the world's leading light bulb manufacturers gathered in Geneva to formalize an arrangement that engineers had understood for years: a bulb that lasted too long was a commercial liability. The Phoebus Cartel set a maximum lifespan of 1,000 hours and enforced it with fines. The technology to produce longer-lasting bulbs existed. The business incentive to deploy it did not.
Ninety years later, Adobe Systems discontinued its perpetual license model for Creative Suite and moved the entire product line to a monthly subscription. Users who had purchased Creative Suite 6 outright—a product that still functioned, that had not degraded, that performed every task it had performed on the day of purchase—found themselves facing a choice: pay indefinitely or lose access to new file formats, new platform compatibility, and the collaborative features that their clients and employers had come to expect. The product had not failed. The commercial environment around it had been deliberately restructured to make ownership untenable.
The Phoebus engineers shortened the lifespan of a physical object. Adobe shortened the commercial lifespan of a functioning one. The underlying strategy is the same. The execution is considerably more sophisticated.
The First Era: Licensing as Extraction
The software industry's relationship with permanence has been adversarial from its earliest commercial phase. In the 1970s and early 1980s, software was often bundled with hardware—purchased once, used indefinitely, and updated only when the hardware itself was replaced. The emergence of the standalone software market created an immediate commercial problem: a well-designed program, once sold, might serve its owner for years without generating additional revenue.
Microsoft's response to this problem during its period of maximum market power is instructive. The company's version upgrade cycle for Windows and Office was not driven primarily by user demand or by the pace of genuine innovation. Internal communications released during the antitrust proceedings of the late 1990s revealed a company acutely aware that its installed base—users perfectly satisfied with existing software—represented a revenue ceiling rather than a foundation. The solution was a combination of file format changes that made older versions progressively less compatible with documents created in newer ones, hardware requirement escalations that made new operating system versions unusable on existing machines, and the withdrawal of support that exposed older systems to security vulnerabilities.
None of these mechanisms required the product to malfunction. They required only that the ecosystem around the product be continuously restructured to make non-upgrade increasingly costly. This is a more durable obsolescence model than physical failure, because it cannot be repaired.
The UI Redesign as Planned Disruption
Among the more underappreciated tools in the digital obsolescence arsenal is the interface redesign. When a company alters the visual and navigational structure of a product that users have learned to operate fluently, it imposes a relearning cost that functions as a form of deliberate friction. This friction has several commercial uses.
For subscription products, periodic redesigns reset the user's sense of familiarity and reinforce dependency on the platform rather than on any accumulated personal skill. A user who has mastered a particular workflow in a project management application is, in a meaningful sense, locked in—not by contract, but by competence. A redesign that invalidates that competence serves the platform's interest in preventing users from feeling that they have outgrown their need for guidance.
For products competing with established alternatives, redesigns can also function as strategic confusion. When Twitter—now X—undertook its most disorienting interface changes following its 2022 acquisition, the effect on user behavior was measurable and, from a competitive standpoint, arguably intentional: users who could not navigate the new environment were presented with a moment of maximum receptivity to alternatives. That this sometimes drives users toward competitors rather than toward deeper engagement reflects the limits of the strategy, not its novelty.
The deeper pattern is older than software. Byzantine tax collectors periodically revised their accounting systems not because the revisions improved collection efficiency, but because complexity served the interests of those who administered it. The parallel is imperfect but instructive: systems that require continuous expert mediation are systems that generate continuous revenue for their administrators.
Compatibility as a Revenue Instrument
The most technically sophisticated obsolescence mechanism in digital commerce is compatibility engineering—the deliberate construction of ecosystems in which older components cease to function not because they have failed but because the surrounding infrastructure has been updated around them.
Apple's periodic deprecation of application programming interfaces—the underlying connective tissue that allows software to communicate with hardware—has forced third-party developers to undertake expensive rewrites on schedules determined by Apple's product roadmap rather than by any genuine technical necessity. Applications that functioned flawlessly on one iOS version are rendered non-functional by the next, not because the application has degraded but because Apple has withdrawn the compatibility layer the application depended upon. The user who purchased the application is now presented with a simple choice: purchase the updated version or lose the functionality.
This mechanism is particularly effective because its costs are distributed across the ecosystem. The developer absorbs the rewriting cost. The user absorbs the repurchase cost. Apple absorbs neither, while collecting a percentage of every transaction the system generates.
The East India Company's spice trading operations in the seventeenth century employed a structurally similar approach: by controlling the ports through which spices moved, the Company could impose new tariff structures that rendered existing trade relationships uneconomical without altering the underlying commodity. The merchant who had built a profitable route under one tariff regime found the route unprofitable under the next. The solution, in both cases, was to pay the controlling party again.
Subscription as the Terminal Form
The subscription model represents the logical endpoint of the digital obsolescence strategy because it eliminates the need to engineer obsolescence at all. When a user does not own the software—when access is contingent on continuous payment—the question of product lifespan becomes irrelevant. The product can be excellent, durable, and continuously improving, and it will still generate recurring revenue, because the alternative to payment is not continued use of an older version but immediate loss of access.
This is why the migration of enterprise software, creative tools, and productivity applications toward subscription licensing has been so rapid and so uniform across the industry. It is not that subscription models are better for users—the economics of software ownership versus rental are straightforwardly unfavorable to users in most cases—but that they are unambiguously better for vendors.
The historical record on this point is unambiguous. Every industry that has successfully converted a one-time purchase into a recurring payment has done so over the resistance of consumers and to the sustained financial benefit of producers. Cable television. Automobile financing. The medieval tithe. The subscription economy is ancient. The software industry simply found a new delivery mechanism.
The Cost of Impermanence
What the digital obsolescence model has accomplished, across four decades of iteration, is the elimination of the consumer's ability to exit the payment relationship without sacrificing accumulated investment. The user who has stored a decade of photographs in a proprietary cloud format, or built a business workflow around a subscription platform, or integrated a smart home device with a manufacturer's ecosystem, is not a customer in any traditional sense. They are a dependent.
The guild masters of medieval Europe understood that the most durable form of economic power was not the ability to produce something valuable but the ability to make others unable to function without your continued participation. Software companies have reconstructed this insight in code. The product was never really the point. The dependency was.