Good old software did not vanish, it lost its exit

The question sounds nostalgic, but it points to a real structural change. Good older software usually lived on the user’s machine, stored its working files in visible folders, and kept running after the vendor lost interest. A spreadsheet, drawing program, file manager, audio editor, FTP client, or desktop database could be copied to another disk, backed up with its documents, and opened years later if the operating system still supported it. The software’s value sat near the user. That made it slower to change, harder to monetize after purchase, and easier to keep.

The old bargain was local control

The old bargain was not perfect. Crashes were common, installation was messy, drivers failed, copy protection annoyed customers, and security updates were weaker than today. Yet many people remember old tools as better because the product did not constantly renegotiate its relationship with them. Menus stayed where they were. A license key unlocked the program instead of starting a billing relationship. Files remained legible. The software was an object with a version, not a remote policy that could change before breakfast. When a company released a bad upgrade, users could often keep the old installer, wait, or switch without losing the archive of their own work.

Modern software moved the center of gravity away from that bargain. Updates became automatic, identities became mandatory, cloud storage became default, and business models shifted from purchase to recurring revenue. The result is not merely aesthetic. The user’s exit got weaker. A note-taking app that stores notes in a proprietary cloud, a design tool that gates exports behind a paid account, or a phone app removed by a store can become less durable than an old program on a dusty CD. Preservation groups now treat software as cultural and technical heritage because executable code, source code, formats, and dependencies can disappear even when the memory of the product remains. Software Heritage describes its mission as collecting, preserving, and sharing publicly available source code because software embodies technical and scientific knowledge that can otherwise be lost.

The better question is not whether the past was pure. It was not. The better question is where the qualities people miss went. They went into niches, open-source projects, professional tools, command-line utilities, local-first applications, and small products whose economics still reward craft. They also went into infrastructure that most users never see: compilers, databases, version-control systems, media codecs, package managers, and libraries. The visible consumer layer became noisier because it was pulled toward engagement metrics, bundles, upsells, telemetry, platform rules, and investor expectations. The stable craft did not vanish; it became less visible behind accounts, dashboards, and stores.

Good older software felt good because it gave users a stable mental model. You learned the tool once, then used that knowledge for years. That kind of continuity matters. It lowers training cost, protects muscle memory, and lets workers build judgment instead of relearning an interface after every redesign. Durability is a product feature, even when it does not appear on a pricing page. Modern teams often measure activation, retention, average revenue, conversion, seat expansion, or feature adoption. Those measures can be useful, but they do not automatically value the quiet benefit of leaving a tool alone.

So the answer is neither romantic nor cynical. Good software from the past scattered across three places: projects whose incentives still favor ownership, regulated or professional markets where breakage is costly, and preservation work that tries to keep old code from becoming unreadable history. The rest was reshaped by economics. Once software became a service, the vendor kept a permanent hand on the switch. That gave users faster patches, richer collaboration, and easier onboarding. It also made them tenants in tools they once owned. The pain people feel is the loss of control, continuity, and credible exit.

For buyers, that older bargain created a habit that is easy to underestimate. Teams could freeze a working setup, document it, train new staff on it, and postpone upgrades until the operational reason was strong. That pause had economic value. It reduced surprise, protected old files, and let people build internal procedures around stable behavior. Modern software can still offer the same stability, but it must choose it deliberately through versioned interfaces, long support windows, portable data, and a refusal to treat every logged-in user as an experiment candidate. That is the emotional core behind the nostalgia. It explains why a ten-year-old workflow can feel more civilized than a brand-new dashboard.

The software did not vanish, the contract changed

The most important change was contractual before it was visual. Software stopped behaving like a finished product and began behaving like an ongoing relationship. In the boxed-software period, a user paid once, received a version, and bore the risk that it might age badly. In the SaaS period, a user often pays every month, depends on the vendor’s servers, and accepts that features, interfaces, limits, prices, and terms may change during the life of the product. That is a different commercial object, even when the icon looks familiar.

The service model solved real problems. Vendors can patch vulnerabilities quickly, synchronize work across devices, restore files after hardware failure, and reduce the pain of manual upgrades. Enterprise buyers also prefer predictable operating expenses and centralized management. Salesforce reported fiscal 2025 revenue of $37.9 billion and described subscription and support revenue as the dominant part of its business, while Microsoft reported fiscal 2025 revenue of $281.7 billion and highlighted Azure surpassing $75 billion in revenue. Those figures are not side notes; they show where the software industry learned to put its energy.

The cost is that the vendor’s business logic now sits inside the product experience. A desktop application could annoy users with upgrade reminders, but it could not easily move a daily feature into a higher tier without shipping a new version and risking revolt. Modern software can change access through account flags, server-side limits, experiments, and pricing plans. Research on SaaS pricing models notes that subscriptions and pricing structures increase the complexity of variability management because pricing is tied to strategy, market trends, and technology. Research on pricing-driven feature toggling goes further: feature access can be regulated according to a user’s subscription, which means pricing constraints become part of the codebase.

That is why some modern products feel less honest than their predecessors. The user is not imagining the change. A button may still exist, but its meaning can change depending on plan, geography, account history, experiment cohort, or administrative policy. The product becomes conditional. A once-simple editor may ask users to sign in before exporting. A tool may keep the free tier but narrow its limits. A collaboration product may add AI summaries because it increases plan differentiation, not because the core workflow demanded it. The product roadmap starts answering two masters: user need and revenue architecture.

This does not make subscriptions evil. A reliable cloud service costs money to run every day. Security teams, support teams, compliance work, hosting, backups, observability, and incident response are not optional for serious products. The problem begins when a company treats recurring revenue as permission to disturb mature workflows without a proportional user benefit. A subscription should buy stewardship, not constant friction. Users accept paying for maintenance when the vendor protects speed, stability, privacy, export, and continuity. They resent paying for surprise gates, redesign churn, and features that consume attention without improving the job.

The old contract also had hidden failures. Users could be abandoned on unsupported software, lose work through corrupt files, or discover that a vendor’s license server no longer activated a purchased program. Modern services can be kinder when they publish migration tools, maintain APIs, and communicate support windows. Google, for example, announced that Stadia players could access their game libraries until January 18, 2023 and that hardware and game purchases made through its stores would be refunded, a better shutdown than many abandoned services received. Yet refunds did not preserve the cloud gaming environment itself.

The better standard is not old versus new. It is whether the contract respects the user’s investment. Good modern software tells customers how long it will be supported, how data can leave, which features require the network, what changes are coming, and what happens when the vendor shuts down. Bad modern software hides these dependencies until the user is trapped. The missing software from the past is often missing because ownership was replaced by access without a matching right to leave.

The contract also changed language. Old marketing promised a program; modern software often promises a workspace, platform, cloud, experience, or ecosystem. Those words sound harmless, but they imply dependence. A platform wants governance power, because it must coordinate identities, permissions, integrations, analytics, storage, and partner access. The user receives convenience, yet also accepts that the vendor may reinterpret the tool’s purpose. The software is no longer only the thing installed; it is the rulebook around the thing. That matters.

Lean tools survived where incentives stayed small

A surprising amount of good software never disappeared. It survived in places where the business model remained modest. Text editors, terminal tools, open-source libraries, indie Mac utilities, Linux programs, emulators, media converters, password managers, note systems, and programmer tools still carry the older spirit of speed, local files, visible settings, and respect for keyboard muscle memory. These products are rarely the loudest in advertising because they do not need to justify huge sales teams or quarterly expansion targets. Their strength is that a small group can understand the whole product.

Small incentives change design. A lean tool does not need to create a new pricing event every quarter. It can fix bugs, refuse fashionable features, and leave a good workflow intact. Restraint becomes a competitive advantage. Many excellent tools are boring in the best sense: they open quickly, do not force a tour, store data in ordinary formats, and avoid collecting information unrelated to the task. Their makers often know that the user bought the tool for work, not for a relationship with a platform. That design culture still exists, but it is easier to find among independent developers and open-source maintainers than inside products optimized for expansion revenue.

Open source has carried much of this old craft, although it carries its own burden. The OpenSSF Census III study was derived from more than 12 million observations of free and open-source libraries in production applications at more than 10,000 companies, and it identified usage patterns that matter for security. Its findings underline a contradiction: the industry depends heavily on code maintained by communities, but many widely used packages are sustained by limited contributor time and uneven security practices. Good old software did not merely move into open source; some of it became critical public infrastructure without public-infrastructure funding.

The best lean tools also benefit from stable scopes. A calculator, archive utility, text editor, vector drawing program, or database browser can be excellent because its domain has boundaries. The work may be deep, but it is not infinitely expandable. A narrow promise protects quality. Products that promise to become the operating system for every department face a different pressure. Each new segment wants integrations, dashboards, roles, permissions, analytics, workflows, templates, and AI features. Large software becomes heavy not only because engineers are careless, but because the sale often rewards breadth before polish.

Users sometimes confuse oldness with quality because the surviving old tools are the winners. Terrible programs from the past are gone from memory, while WordPerfect, Winamp, HyperCard, Photoshop, AutoCAD, Vim, Excel, FileMaker, or classic Mac utilities remain as symbols. That survivor bias matters. Many old applications were hostile, unstable, undocumented, or locked to hardware that failed. Yet the survivors reveal a design lesson: software ages well when its core abstractions stay true. A spreadsheet grid, a plain-text buffer, a timeline, a canvas, a folder tree, or a command prompt can outlast fashions because users can build durable skills on top of them.

GitHub’s 2025 Octoverse report shows that software creation is not slowing down: developers created more than 230 new repositories per minute, merged tens of millions of pull requests each month, and pushed nearly one billion commits in 2025. That scale does not guarantee better end-user software, but it does show that craft has not disappeared. It has multiplied. The problem is discovery. The tools that most respect users are often buried below venture-backed suites, app-store charts, SEO pages, and enterprise procurement lists.

Good software from the past went where the incentives still allow it to be good. It lives in tools that can say no, projects that publish formats, maintainers who care about speed, and buyers who reward durability. It is less visible because the modern market rewards distribution as much as design. The craft survived; the default channel changed.

This is why the search for good software often ends outside the biggest brands. A mature utility with ten thousand loyal users may never become a unicorn, but it may give those users something more precious: predictability. Scale is not the same as quality. Large companies can build excellent tools, but their internal incentives often ask products to carry sales strategy, data strategy, and portfolio strategy at once. A small product can remain answerable to the craft of one job. It also explains why old-style loyalty often gathers around tools that never chase every adjacent market. It is not nostalgia for age; it is respect for bounded promises.

The subscription layer changed product design

Subscriptions changed the rhythm of software work. A permanent revenue relationship pushes teams to keep proving that the product is alive. That proof can be useful when it funds maintenance, security patches, accessibility work, compatibility updates, and support. It becomes destructive when the product needs visible novelty even after the core job is solved. A purchased tool can mature quietly. A subscription product is often asked to produce new plan tiers, usage limits, add-ons, dashboards, or bundled services that justify renewal conversations.

The effect reaches into design meetings. A feature is no longer judged only by whether it solves a user problem. It may also be judged by whether it increases upgrade conversion, protects gross margin, defends a bundle, creates an enterprise-only permission, or raises the perceived gap between plans. Pricing becomes a design material. Research on Pricing4SaaS describes subscription pricing as part of the operation of SaaS systems, not a detached billing page. Research on pricing-driven feature toggles shows that subscription limits may require conditions throughout the codebase. Once that architecture exists, product teams can change commercial boundaries faster than users can rebuild habits.

That is why software can feel as if it is decaying even while engineering effort increases. Engineers may be shipping more code than before, but some of that code manages plans, entitlements, telemetry, experiments, billing states, sales-led administration, compliance prompts, consent records, and AI usage meters. The user sees friction, not effort. The product surface becomes crowded with business infrastructure. In the boxed era, the business model was mostly outside the software after purchase. In the SaaS era, it can appear in disabled buttons, locked exports, usage banners, storage warnings, trial countdowns, and plan-comparison modals.

The subscription model also changes risk tolerance. A vendor with steady recurring revenue may invest in reliability, but it may also accept gradual annoyance if churn remains below a threshold. The customer success team can rescue large accounts, while smaller users absorb degraded experience. Analytics can make this rational: if a redesign increases revenue and only a minority leaves, the change may be judged successful. The metric can win against the craft. Older software had feedback loops too, but they were rougher. A bad release could sit unsold on shelves. A modern service can segment backlash, roll back for some users, and keep the monetizing change elsewhere.

Regulators have noticed subscription friction, especially cancellation friction. The FTC announced a final “click to cancel” rule in October 2024 after receiving more than 16,000 comments, but the Eighth Circuit vacated that rule in July 2025 on procedural grounds. The current U.S. federal posture still treats deceptive negative-option practices as subject to Section 5 requirements, including clear disclosure of material terms and cancellation information, but the broader rule’s fate shows how contested subscription governance remains.

For software quality, cancellation rights matter because they restore discipline. A product that is easy to leave must keep earning its place. A product that traps data, hides cancellation, or breaks exports can drift further from user value. Exit is the missing quality-control mechanism. The best subscription software behaves like a responsible steward: it publishes APIs, respects exports, avoids surprise limits, and makes billing understandable. The worst behaves like a landlord with a confusing lease.

The subscription layer did not kill good software by itself. It funded many reliable services that could not exist as one-time purchases. Yet it changed the default question from “Does this tool solve the job well?” to “Does this relationship keep expanding?” That shift explains much of the unease. The old tools ended when the user stopped using them. The new tools keep asking for renewal, attention, data, and acceptance. Good software did not vanish; it became harder to separate from the revenue machinery around it.

A healthier subscription culture would separate renewal from disturbance. Users do not object to paying for a product that remains compatible, secure, and cared for. They object to paying while the product becomes harder to use. Maintenance is a feature users recognize, even when vendors understate it. Release notes that say less but mean more, a stable import path, a fast launch time, and a plain export button may create more trust than a page of new banners. The products people praise longest usually protect yesterday’s competence while adding tomorrow’s repairs. That is a product principle, not a memory trick. It keeps renewal tied to trust. Over time. too.

Cloud software broke the old archive habit

Cloud software changed failure from a local event into a service event. Old software could rot on your machine, but it rarely disappeared for everyone on the same day. A program might stop working after an operating-system upgrade, but copies survived in drawers, archives, FTP mirrors, university servers, and personal backups. Cloud products concentrate that risk. When a service shuts down, removes an API, changes a data model, or ends a free tier, the user’s copy is often not enough because the software’s real behavior lived on remote infrastructure.

The benefit is obvious. Cloud tools made collaboration normal, reduced manual backup habits, enabled real-time documents, and let small teams rent infrastructure that once required capital and staff. For many organizations, the cloud improved reliability compared with a neglected office server. Yet preservation becomes harder when the product is partly a running service. A screenshot is not a working copy. To preserve a cloud product, one may need client code, server code, databases, identity systems, billing assumptions, API contracts, storage buckets, dependencies, configuration, and legal permission. That is why cloud shutdowns feel different from losing an installer.

Google Stadia illustrates the distinction. Google said players would have access to their games library until January 18, 2023 and that it would refund Stadia hardware purchases made through the Google Store and game and add-on purchases made through the Stadia store. That softened the financial harm. It did not make Stadia itself preservable as a consumer product. The games, controller, streaming stack, account services, and licensing relationships depended on an operating cloud service. Once that service ended, the experience could not be placed on a shelf like a cartridge.

Adobe Flash shows another version of the archive problem. Adobe stopped supporting Flash Player after December 31, 2020, blocked Flash content from running in Flash Player beginning January 12, 2021, and said no further updates or security patches would be issued after end of life. Security reasons were real; unsupported browser plugins can expose users to risk. Yet the move also cut off access to a large body of web art, games, learning material, and interactive experiments unless they were migrated, emulated, or preserved by specialists. Security and memory collided.

Institutions now treat digital preservation as an active practice, not a passive storage habit. The Library of Congress describes digital preservation work in terms that include packaging, ingest, storage monitoring, file formats, and metadata. Software Heritage focuses on source code because source is often the most durable way to understand and rebuild software. The Internet Archive’s software collections and browser-based emulation work show another path: keep executable culture accessible even when the original hardware and distribution channels are gone.

The practical lesson is sharp. Software that depends on a cloud service needs an end-of-life design before launch, not during the shutdown announcement. That design should answer whether users can export all content, whether open formats exist, whether API documentation will be archived, whether self-hosting is possible, whether read-only access will survive, and whether user-created work can remain usable without a subscription. These choices are unglamorous, but they decide whether a tool becomes part of people’s working memory or turns into a broken login screen.

Cloud software did not make old quality impossible. Some cloud tools are excellent because they protect data, publish APIs, communicate outages, and respect migration. The problem is that cloud architecture gives vendors power that old desktop vendors did not have at the same scale. The user cannot preserve what the user never possessed. The old archive habit failed because the product moved from files and binaries to live systems controlled by someone else.

This also changes cultural memory. A novel, film, or album can be copied, catalogued, and cited even when its publisher changes strategy. Software needs a working environment. The artifact includes behavior, not only files. A lost service can take with it social graphs, saved states, moderation decisions, level editors, automation histories, and the small rituals that made the product meaningful. That is why preservation must record context as well as code. Museums, archivists, and enthusiasts can emulate old machines, but a live service also needs server logic, authentication behavior, and data relationships. If those parts were never released or documented, the archive becomes reconstruction rather than preservation. That gap makes cloud longevity a governance question, not only a technical one. It explains why users ask for export tools as fiercely as they once asked for installers.

App stores became product governors

App stores changed software distribution from a file exchange into a permissioned market. A store is not only a shelf; it is a rule-setting institution. It decides which apps may reach users, which payment systems may be used, which APIs are acceptable, how screenshots and metadata appear, how reviews affect trust, and when an app is too old to remain listed. That governance can protect users from malware and fraud. It can also make developers dependent on policies they did not write and users dependent on a curator whose incentives are not identical to theirs.

Research on app stores describes them as online software stores where users browse, buy, download, and install applications, and argues that research has often focused on apps rather than stores themselves. That distinction matters because the store shapes software engineering practice. Apple tells developers that apps should change and improve to stay on the App Store, and its App Store improvement process includes evaluating and removing apps that no longer function as intended, do not follow current review guidelines, or are outdated. Maintenance becomes a platform condition, not only expectation.

This solved a real consumer problem. The old internet was full of fake installers, toolbar bundles, unsigned downloads, abandoned shareware sites, and malware masquerading as useful tools. A curated store gave ordinary users a safer default and gave small developers a distribution channel they could not have built alone. Yet the price was a narrower form of ownership. On phones especially, many users cannot install software with the same freedom they had on personal computers. The gate moved closer to the device, and software that does not fit the gatekeeper’s rules may never reach the audience.

That shift changed product design. Developers design around review guidelines, store search, in-app purchase rules, platform UI conventions, privacy labels, entitlement requests, and ranking algorithms. Store optimization can become as important as product ergonomics. Review delays and compliance concerns may discourage experiments that would have been easy on the open web. Small developers also face sudden risk when a rule changes, an account is suspended, or a feature depends on a private API. The result is a cleaner market for users but a less sovereign one for both users and builders.

The European Union’s Digital Markets Act directly targets gatekeeper power. The Commission describes gatekeepers as large digital platforms providing core platform services such as app stores, search engines, and messenger services, and says the DMA creates obligations and prohibitions for those companies. Apple says its EU changes include alternative app marketplaces and alternative payment options, while also warning that these changes introduce risks including malware, fraud, scams, pirated software, and reduced ability to remove harmful apps. The conflict is not imaginary: openness and safety both have costs.

The old software world had more chaos and more user agency. The app-store world has more safety and more central control. Neither model is clean. A user who wants a secure phone may welcome strict review; a developer building a lawful tool outside mainstream taste may see the same review as private regulation. The question for good software is whether the store protects users without freezing competition, suppressing repair, or forcing every product into the same commercial shape.

Good software did not vanish in app stores; some of it thrives there. The problem is that the store’s definition of good may differ from the user’s. A stable utility that needs no updates can be labeled stale. A powerful tool may be rejected because it touches forbidden system functions. A private app may be impossible to distribute outside a sanctioned channel. The store became part of the product, and that means good software now depends on the quality of governance as much as the quality of code.

Governance affects memory. If a store removes an app, users may retain installed copies for a while, but new users cannot discover it through the channel and existing users may lose reinstall rights after changing devices. Distribution scarcity replaces physical scarcity. An old disk could be scratched, yet someone could image it, lend it, or archive it. A removed mobile app may become a rumor unless the developer can distribute elsewhere. For businesses, app-store dependence creates hidden risk. A company may build its customer relationship on a platform account, payment rule, ranking model, or entitlement system it does not control. The channel becomes a business dependency as real as hosting or payroll.

Platforms learned to extract value after adoption

People often describe modern software decay with moral language, but the mechanism is economic. A platform becomes most tempted to worsen after users and partners are already dependent on it. At the beginning, a product must be generous enough to attract people. Later, switching costs rise: files accumulate, contacts move in, workflows form, staff are trained, plugins are bought, and public identity becomes tied to the service. At that point, the company can take more value from the relationship without losing everyone at once.

Cory Doctorow’s “enshittification” became the popular label for this pattern after he used it to describe platforms that first serve users, then business customers, then themselves. The American Dialect Society selected “enshittification” as its 2023 Word of the Year, a sign that the term captured a broad frustration with platform decline. The term is rude, but the analysis is useful: the product can get worse while the platform gets better at extracting value.

Software is especially vulnerable because switching costs are often invisible until the user tries to leave. A social platform has network effects. A design tool has file formats. A project-management system has history. A CRM has customer records, automations, permissions, dashboards, and sales habits. A cloud editor has documents stored in its own model. A mobile platform has purchases, defaults, photos, messages, and accessories. Dependency compounds quietly, then becomes bargaining power for the vendor.

This helps explain why older tools feel cleaner. A boxed program could be abandoned, but it usually could not rewrite itself into a worse bargain after adoption unless the user installed the new version. A platform can. It can alter ranking, reduce organic reach, charge for previously free access, insert ads, change APIs, remove clients, add surveillance, or make export cumbersome. It may frame these changes as security, quality, simplification, or sustainability. Sometimes those reasons are true. Sometimes they are convenient masks for a transfer of control.

Regulatory activity around mobile platforms reflects the same concern. The U.S. Justice Department and state attorneys general sued Apple in March 2024, alleging monopolization or attempted monopolization of smartphone markets under Section 2 of the Sherman Act. The UK Competition and Markets Authority opened an investigation into Apple’s mobile platform in January 2025 and later confirmed strategic market status for Apple and Google in mobile platforms. Reuters reported on July 8, 2026 that Apple lost a challenge against EU rules that treat iOS and its App Stores as gatekeeper services under the DMA. These cases are allegations, designations, and rulings in active regulatory systems, not proof that every platform decision is abusive.

The deeper point is that software quality includes bargaining structure. A beautiful interface can still belong to a hostile market. A fast tool can still be dangerous if the user’s work cannot leave. A secure platform can still overreach if it blocks competitors or repair under the cover of safety. Good software requires credible checks on the vendor’s future behavior. Those checks may be export formats, open protocols, antitrust law, interoperability duties, repair rights, public APIs, or a real competitor that users can choose without losing everything.

The old software people miss had its own forms of lock-in, especially proprietary file formats and hardware dependencies. Yet many desktop tools left users with a frozen copy of the relationship. Platform software keeps the relationship alive and adjustable. That is powerful when the vendor acts as steward. It is corrosive when the vendor treats dependence as an asset to mine. Good software went missing where adoption became a trap rather than a bond of trust.

The extraction pattern also explains why users feel betrayed rather than merely disappointed. People invest more than money in software. They invest habits, trust, documents, templates, automations, team procedures, and reputational capital. When a product changes the bargain after those investments are sunk, the loss feels personal. Lock-in turns ordinary product changes into forced negotiations. A user might accept a worse coffee shop by walking elsewhere; leaving a software platform may require weeks of migration, retraining, cleanup, and broken integrations. Good vendors understand that dependence creates responsibility. They avoid taking every advantage the market permits. They publish deprecation notices early, preserve old APIs where possible, and price changes in ways that do not punish users for trusting them. Platform decay begins when management treats dependency as leverage rather than stewardship. That restraint is part of quality. It earns loyalty. now.

The economics behind software decay

The decline people feel is not caused by one villain. Software quality is pulled by incentives that often conflict with user comfort. A team may want speed, clarity, stability, and craft. A company may also want higher recurring revenue, cheaper support, more data, stronger lock-in, faster enterprise sales, investor growth, and defensible platform power. When those pressures collide, the visible product can become heavier, less predictable, and less respectful even while the organization hires more engineers.

Older commercial software often monetized the release. A major version had to be compelling enough to buy, so vendors bundled improvements into visible upgrades. That model could encourage bloat, but it also gave users veto power: skip the upgrade. Modern software monetizes access, usage, seats, storage, AI credits, administration, compliance features, and integrations. The revenue event is continuous, so the product is never fully finished. A mature workflow that needs quiet maintenance may be less attractive internally than a new tier that can be measured in expansion revenue.

The table below does not claim every old product was better. It maps the incentives that explain why a solid older tool and a modern service can feel different even when the modern service has better infrastructure.

Table 1: Incentives that changed software behavior

The pattern matters because each incentive can be rational on its own. Together they can make software feel less like a tool and more like a managed relationship.

Financial pressure is not abstract. Large software companies report revenue in forms that reward cloud growth, subscription retention, and platform usage. Microsoft reported $281.7 billion in fiscal 2025 revenue and said Azure passed $75 billion in revenue for the first time. Salesforce reported fiscal 2025 revenue of $37.9 billion and later fiscal 2026 revenue of $41.5 billion. These companies build many useful products, but their scale shows why product design is now tied to retention, bundling, security operations, data-center economics, and AI infrastructure. The balance sheet reaches the interface.

A small utility can delight by staying narrow. A public company must often explain growth. That pressure does not automatically ruin software, but it changes what is rewarded. A manager who removes clutter may improve user trust yet reduce the list of launchable features. A team that keeps an old workflow stable may prevent churn but struggle to show novelty. A designer who adds a pricing banner can tie work to measurable revenue. Measurement can favor visible extraction over invisible relief.

The same logic explains why users encounter AI features in products that did not need them. Some AI additions are useful: search, summarization, accessibility, code assistance, translation, anomaly detection, and support triage can reduce real work. Others appear because AI creates new plan tiers and investor stories. GitHub’s 2025 Octoverse report said more than 1.1 million public repositories used LLM SDKs and that AI-related repositories exceeded 4.3 million. That growth shows a real technical shift, but it also gives software companies another reason to repackage familiar tools.

Software decay is often the sum of small rational choices. Add telemetry to understand usage. Add a banner to improve conversion. Move export behind an account to reduce abuse. Bundle products to raise retention. Redesign navigation to fit new modules. Each decision may have a defensible memo. The cumulative result can make the tool slower and less direct. Good software survives when leadership treats restraint as a business asset, not as a lack of ambition.

Another force is organizational distance. In a small software company, the person hearing a user’s complaint may be close to the person changing the code. In a large platform, the complaint may pass through support scripts, analytics dashboards, product managers, compliance teams, sales priorities, and executive targets before it becomes work. The user’s pain gets translated into metrics, and the translation may lose detail. A thousand minor irritations can be statistically acceptable if none produces a crisis. Decay also arrives through accumulation. A product adds one prompt, one permission screen, one setup checklist, one assistant panel, one upgrade notice, one integration banner, and one redesigned navigation item. Each addition has an owner and a reason. The user receives the pile. Good software requires someone with authority to remove things that are locally successful but globally harmful.

A useful test is whether a company can name the user benefit of each commercial layer. Entitlements, metering, and bundles are sometimes legitimate, but they should not obscure the main job. Good economics make good behavior easier. Bad economics ask every screen to sell something. Once the selling layer dominates, users feel that the tool has stopped working for them, even when the codebase keeps growing. Users notice. Every week. too.

Security turned updates into a permanent duty

Security is the strongest argument against pure nostalgia. A tool connected to modern networks cannot be treated like a finished chair. It depends on operating systems, browsers, cryptography, libraries, identity providers, package repositories, hardware security modules, and cloud APIs that keep changing. Attackers also change. A program that felt finished in 2005 may be reckless in 2026 if it parses untrusted files, opens network ports, stores passwords badly, or depends on abandoned libraries.

This is where older software really did lose ground. A local program that never touched the internet could age gracefully. Most useful software now touches the network directly or indirectly. Even offline-looking tools may sync licenses, update templates, call cloud models, fetch fonts, render web content, or load third-party packages. The maintenance surface expanded. Users may miss the quiet of old software, but quiet can be dangerous when it means no patches, no vulnerability disclosure, no dependency updates, and no supported way to respond to a flaw.

NIST’s Secure Software Development Framework, SP 800-218 Version 1.1, recommends a core set of high-level secure software development practices for mitigating software vulnerabilities. CISA’s Secure by Design work frames security as a core vendor responsibility rather than a burden pushed mainly onto customers. The SLSA framework focuses on software supply-chain integrity, including preventing tampering and improving confidence in packages and build systems. These frameworks show that modern software quality includes processes users never see.

The European Union’s Cyber Resilience Act makes the same point in regulatory language. The Commission says the CRA aims to safeguard consumers and businesses buying software or hardware products with digital elements, and that it addresses inadequate cybersecurity and the lack of timely security updates. That is a direct challenge to the old habit of shipping software and walking away. A secure product now needs a support life, and that life costs money.

Security also explains some decisions users dislike. Automatic updates reduce exposure windows. Store review can block known malware. Code signing can make tampering harder. Cloud identity can centralize revocation. Deprecation can remove dangerous components. Yet each protective measure can also become a control point. A vendor can use update channels to force redesigns, app review to block competition, identity checks to collect data, or security claims to discourage repair. The same mechanism can protect or dominate, depending on governance.

Adobe Flash remains the classic example of painful security-driven retirement. Adobe stopped supporting Flash Player after December 31, 2020 and blocked Flash content beginning January 12, 2021, citing the absence of future security patches and the need to help secure systems. Many people lost convenient access to old web content, but leaving an unsupported plugin active would have created serious risk. Good software preservation and good security were not aligned by default.

The better answer is not to freeze software forever. It is to design maintenance that respects users. A vendor can patch vulnerabilities without moving menus every month. It can publish long-term support releases, document end-of-life dates, keep old file readers, and separate security fixes from monetizing interface changes. Security should not be a blank check for churn. Users are more likely to trust updates when updates do not smuggle in plan gates, ads, telemetry expansion, or unnecessary workflow changes.

Old software felt good partly because it changed less. Modern software often must change to remain safe. The craft challenge is to reconcile those truths. Good software in 2026 is not merely fast and pleasant; it is maintained, auditable, patchable, and honest about its dependencies. The past offers a lesson in restraint, not a license to ignore security.

Security also changed the moral contract between vendor and user. A company that ships networked software now holds a duty to monitor serious defects after sale. Users cannot reasonably audit every library, cryptographic choice, build pipeline, or update package. Trust moved from the installer to the development process. That process must be documented enough for enterprise buyers, regulators, insurers, and security researchers to judge it. Modern buyers increasingly ask about software bills of materials, vulnerability disclosure, secure build practices, and support periods because an attractive interface says little about the risk behind it. The discomfort is that security work rarely produces the feeling people associate with good old software. It adds prompts, updates, certificates, account checks, and permissions. The task is to keep those safeguards proportionate and legible. Clear defaults, patient explanations, and quiet patching keep protection from feeling like punishment. That matters.

The maintenance burden outgrew nostalgia

Nostalgia treats maintenance as a minor chore because users rarely saw it. Modern maintenance is a product in itself. A serious application must track operating-system changes, browser engines, processor architectures, graphics drivers, accessibility APIs, localization, payment rules, privacy law, identity standards, vulnerability disclosures, package updates, app-store requirements, cloud-provider changes, and customer support obligations. Good old software could be a masterpiece with a small surface. Good current software often survives by managing a web of moving parts.

Windows 10’s end of support shows the scale of this burden. Microsoft says Windows 10 support ended on October 14, 2025, that devices still function, and that security updates for Microsoft 365 on Windows 10 continue for a limited period ending October 10, 2028. That kind of lifecycle policy matters because software does not exist alone. Applications depend on operating systems, and operating systems depend on driver ecosystems, hardware support, certificates, browsers, update channels, and security teams. Compatibility is a moving agreement, not a permanent fact.

Old applications could also depend on fragile components: 16-bit installers, discontinued runtimes, serial dongles, obsolete codecs, old database engines, or hardware drivers that no longer load. The difference is that many users experienced those failures as isolated problems. Today a common dependency can affect millions of installations quickly. A package update, certificate expiry, API change, or cloud outage can break products across companies. The burden of reliability moved from individual machines to shared ecosystems.

This is why modern teams invest in observability, staging, canary releases, incident response, secure build pipelines, dependency scanning, and rollback systems. Users may never ask for those features, but users notice when they are absent. Reliability work is invisible until it fails. The tragedy is that invisible reliability often competes for budget against visible novelty. A company can advertise AI summaries more easily than a cleaner dependency graph. It can sell a new dashboard more easily than a quieter incident runbook.

Open-source maintenance makes the problem sharper. The OpenSSF Census III work found production use of many FOSS libraries across more than 10,000 companies, and the broader security community has repeatedly warned that widely used packages may depend on a small number of maintainers. This is not a reason to distrust open source. It is a reason to fund it, audit it, and treat dependency choice as a business decision. A free library can become a paid risk when no one budgets for its care.

Maintenance also includes saying no. Every added module increases test surface. Every supported platform increases build complexity. Every integration creates another failure path. Every pricing plan can multiply entitlement cases. Every AI feature can add latency, cost, privacy review, and unpredictable output. A product can become worse because it says yes too often. Old software sometimes felt better because it carried fewer promises. Durability depends on disciplined scope, not only on skilled programming.

The best modern software treats maintenance as editorial work. Teams prune unused features, keep old documents readable, remove dead dependencies carefully, publish migration paths, and make boring performance work part of the roadmap. They do not confuse constant change with care. They know that users want improvements, but they also want yesterday’s work to open tomorrow. That expectation is fair.

The past cannot simply be restored because the environment changed. A networked tool without security maintenance is negligent. A cloud service without incident response is reckless. A mobile app without platform updates may disappear from stores. Yet the feeling behind the complaint remains valid. Users miss software that seemed finished because finished meant calm. Modern software needs to earn the same calm through quiet maintenance, stable contracts, and honest support windows.

The maintenance burden also explains why abandoned software can remain beloved but unsafe. A retired program may still launch, but its file parser might contain old vulnerabilities, its help links may point to dead domains, its update server may be hijackable, or its embedded browser may accept modern web content it cannot safely handle. Running is not the same as being safe. That distinction is hard for users because software feels alive when the window opens. Good maintenance should be boring enough that users barely notice it, yet transparent enough that they know it exists. A changelog that separates security fixes from feature changes helps. A support matrix that names dates helps. A clean offline mode helps. The craft is not to avoid maintenance; it is to make maintenance feel like care rather than interference.

Open source carried the old craft forward

Open source preserved many qualities people associate with older software: inspectability, portability, community memory, stable file formats, and the possibility of repair by someone other than the original vendor. The best open-source projects make software feel less like a rented room and more like shared infrastructure. Users can copy the code, fork it, audit it, package it for old systems, or pay maintainers to adapt it. That does not guarantee excellence, but it changes the power relationship. The vendor cannot simply remove a local copy from existence.

This is why many durable tools live in open ecosystems. Linux, PostgreSQL, SQLite, Git, Blender, OBS Studio, VLC, Inkscape, GIMP, Python, R, Apache, Nginx, and countless libraries have outlasted product cycles because no single commercial roadmap owns their survival. Some are backed by companies, foundations, governments, universities, or individual maintainers. Some are messy. Some lack polish. Yet their durability comes from a crucial property: the source and the community can outlive one sponsor.

Open source is not magic. The OpenSSF Census III study shows how deeply modern production applications depend on free and open-source libraries, but that dependence creates security and maintenance duties. A package used by thousands of companies may still be maintained by one tired person. A transitive dependency may enter a product because another library needs it. A malicious package can exploit the trust built into package managers. Freedom to inspect code does not mean someone actually inspected it.

Still, open source answers part of the question, “Where did good software go?” It went into code that runs everywhere but is rarely seen directly. The databases behind services, the compilers behind apps, the cryptographic libraries behind secure connections, the version-control systems behind teams, and the media tools behind creators often come from open ecosystems. Consumer software may feel worse while the invisible infrastructure beneath it becomes stronger. That contrast can confuse users. The industry can become technically more capable while the everyday interface becomes more manipulative.

Open-source tools also preserve the older idea that users deserve technical agency. A command-line utility may not flatter beginners, but it usually accepts text, writes text, documents flags, and composes with other tools. That culture values plain interfaces and durable contracts. The Unix habit of small programs working together still influences modern developer tools because it reduces dependence on one huge application. A user can replace one component without losing the entire workflow. That modularity is one reason many expert tools age better than consumer suites.

The weakness is funding. Open-source sustainability remains uneven because the people who benefit from code are not always the people who pay for its care. Companies may treat community projects as free raw material until a vulnerability or abandonment event forces attention. Good software cannot live on admiration alone. Foundations, sponsorship, paid support, public grants, security audits, and procurement rules can all move money toward maintenance. If society depends on a project, society needs a way to maintain it.

Open source carried the old craft forward, but it also inherited the modern burden. It must patch vulnerabilities, document supply chains, manage contributors, resist maintainer burnout, and survive ecosystem churn. Its value is not that every project is beautiful. Its value is that the user has a path besides waiting for a vendor. When a proprietary service decays, the user can complain. When an open project decays, the user can sometimes repair, fork, fund, or preserve it. That difference is a form of freedom.

The best future software will probably mix open foundations with paid stewardship. Users do not need every product to be free. They need the core of their work to remain understandable, movable, and repairable. Open source keeps that possibility alive when commercial software forgets it.

A practical test is whether a project invites continuity. Can another team build it if the founder leaves? Are file formats documented? Are releases reproducible? Are governance decisions visible? Can a business buy support without turning the project into a closed product? Openness needs institutions as well as licenses. The healthiest projects make contribution possible without making maintenance heroic. They reduce the gap between admiration and responsibility. This is where open source can improve on nostalgia. Old proprietary software sometimes died with its company. Open projects can survive through forks, archives, and new maintainers, but only if the surrounding community keeps social and technical pathways open. That is progress. now.

Dependency chains made small projects critical

Software used to fail in ways users could often see: a missing disk, a bad driver, a broken installer, a corrupt file. Modern software fails through chains. A tiny dependency can sit inside thousands of products without most users knowing its name. A package may handle logging, parsing, compression, date formatting, authentication, image processing, or build automation. If it breaks, becomes malicious, loses a maintainer, or exposes a vulnerability, the failure can travel across products that appear unrelated.

This dependency economy made software faster to build. Developers do not rewrite everything from scratch; they assemble proven components and focus on the product’s distinctive work. That is good engineering when the components are maintained and understood. It becomes fragile when organizations import packages casually, fail to track versions, or assume popularity equals safety. Reuse lowers development cost while raising coordination risk. The user sees a single app; the security team sees a supply chain.

OpenSSF’s Census III was built from more than 12 million observations of FOSS libraries in production applications at more than 10,000 companies. Its purpose was not nostalgia; it was visibility. Organizations cannot secure or preserve what they cannot name. A modern product may depend on direct packages, indirect packages, container images, build tools, scripts, APIs, and cloud services. If a vendor cannot produce a reliable inventory, it cannot answer basic questions after a vulnerability appears.

The software bill of materials became important for that reason. It is not glamorous, but it records what a product contains. A bill of materials does not solve security by itself, just as an ingredient label does not make food safe. It makes response possible. If a library is compromised, teams can find where it is used. If a license conflicts with a product, lawyers can respond. If a component is abandoned, maintainers can plan migration. Good maintenance starts with knowing the inventory.

Dependency chains also help explain modern bloat. A simple-looking app may ship large frameworks because that is how the team moves quickly across platforms. A desktop tool may include a browser engine for UI. A mobile app may bundle analytics, ads, authentication SDKs, crash reporters, experimentation frameworks, and payment libraries. Each addition may save work, but the user pays with disk space, memory, network calls, permissions, and update size. The old handcrafted program could feel faster because it carried less inherited mass.

The hidden cost is institutional memory. If engineers assemble a product from many packages without understanding the trade-offs, the codebase may become difficult to reason about. A major version bump in one dependency can require changes across the system. A licensing shift can force replacement. A maintainer can archive a project. The dependency graph becomes part of the product’s future, even though it is rarely shown to customers. Buyers who ask only about features miss a major durability risk.

This does not mean “write everything yourself.” That would recreate old bugs and waste talent. The better standard is deliberate dependency selection. Teams should prefer maintained projects, clear licenses, modest scope, reproducible builds, signed releases, and exit paths. They should remove unused packages and separate optional integrations from core workflows. They should fund critical dependencies when business value depends on them. Good software from the past felt self-contained. Modern software can rarely be fully self-contained, but it can be honest about its parts.

The best modern craft is not anti-dependency. It is dependency literacy. A durable product treats small external projects as responsibilities, not as free shortcuts. That is where some of the old software spirit went: into maintainers who keep quiet packages working so larger tools can exist at all.

Dependency literacy also belongs in procurement. Buyers often ask whether a product has a feature, not whether the vendor can support the dependencies behind that feature. Better questions are plainer: Which critical open-source packages are used? How are vulnerabilities triaged? How fast are patches shipped? What happens when a dependency is abandoned? A vendor that cannot answer has a maintenance problem, even if the demo works. The same discipline applies to internal teams. A developer choosing a package is making a future support promise. That promise should be visible to managers, not buried in a lockfile no one reviews.

Choosing fewer packages can be as strategic as choosing better ones. It reduces audit work, update pressure, and failure paths. Small dependency graphs age better because teams can understand them without folklore.

Feature toggles made pricing part of code

Feature toggles began as a practical engineering tool. They let teams turn behavior on or off without shipping a whole new release. Used well, toggles support testing, staged rollouts, emergency rollback, regional compliance, beta programs, and operational safety. A team can expose a feature to one group, monitor errors, and retreat if it fails. That is better than forcing every user into a risky release at the same moment.

The same mechanism became a commercial tool. In subscription software, toggles can decide which customer sees which feature, how much usage is allowed, whether an export option works, whether an AI assistant is available, or whether an administrator can set a policy. Research on pricing-driven feature toggling describes the challenge of regulating feature access according to subscription limits and managing conditions throughout the codebase. Pricing no longer lives only in billing; it can live in every workflow.

That architecture explains a peculiar feeling in modern software: the tool seems present but withheld. A button may appear greyed out. A feature may work during trial but vanish later. A workspace may show a report but block export. A product may advertise an integrated workflow that requires three different plans across three departments. The user is not simply using software; the user is moving through a permission maze. The product is split into entitlements.

There are legitimate reasons for entitlements. A vendor must manage costs when features consume cloud compute, storage, model inference, human review, or compliance support. Enterprise permissions may require separation from consumer tools. Regional rules may require different behavior. Abuse controls may limit risky actions. Yet the user’s patience depends on whether restrictions feel connected to real cost and safety. A plan gate on a costly AI feature is easier to understand than a plan gate on exporting one’s own data.

Feature toggles can also create technical debt. A temporary flag may stay for years. Old plans may require old behavior. Sales exceptions may create custom cases. Migrations may be delayed because high-value customers depend on a legacy toggle. Engineers then maintain a product that behaves differently for different customers, regions, and contracts. Complexity moves from the pricing page into the codebase. Users see inconsistency; developers see branching logic; support teams see confused tickets.

The older desktop model had commercial gates too: standard, professional, enterprise, student, trial, and upgrade editions. The difference was tempo and visibility. A boxed edition had a relatively fixed boundary. A SaaS boundary can shift server-side and can be tested on small groups before the public understands the change. That agility is powerful, but it can make trust fragile. Users cannot plan around a tool if the tool’s capabilities are contingent on opaque account state.

Good software uses toggles with discipline. It names temporary flags, deletes them after rollout, documents customer-facing limits, avoids feature gates that trap user data, and gives support teams clear explanations. It separates operational safety toggles from monetization toggles. It treats export, backup, accessibility, security, and identity recovery as trust features, not upsell inventory. A feature gate should never hold the user’s own work hostage.

This is one place where old software’s virtue was structural. Once installed and unlocked, it usually did what the version did. Modern software can do more, respond faster, and tailor experience, but it can also become less reliable in meaning. The future of good software depends on commercial restraint inside the code. A product can have pricing tiers and still respect users. It must draw the line where the user’s dependence begins.

Feature toggles also affect support truth. Two customers may call about the same screen and see different behavior because their accounts sit behind different flags. Documentation then becomes conditional, training videos age quickly, and support teams must ask which plan, region, experiment, and migration cohort the customer belongs to. Conditional software is harder to explain. It is also harder to trust because users cannot easily tell whether a missing feature is a bug, a limit, or a commercial decision. The old fixed-version model was less flexible, but it gave users a shared reality. Modern teams need to recreate that clarity with better labels, account transparency, and fewer permanent exceptions.

Pricing flags should expire like food in a refrigerator. If no one owns removal, the product accumulates stale commercial logic. Old flags become old promises, and old promises become migration debt. Users deserve that clarity. always.

Design polish gave way to metric pressure

Many older applications felt polished because designers and engineers could optimize for repeated use. The person who learned the tool was treated as the main customer, not only the person arriving for the first time. Menus, shortcuts, panels, and settings could remain stable for years. A professional user might discover depth slowly and gain speed through memory. That design style respected the fact that software is often a workplace, not a brochure.

Modern product teams measure far more. They track activation, conversion, retention, feature adoption, session length, onboarding completion, churn risk, search use, clicks, revenue per account, support contacts, and experiment outcomes. Measurement can expose real problems, especially when users struggle silently. It can also distort judgment. A metric sees the event, not always the craft. A redesign may increase clicks because users are lost. A notification may improve engagement while lowering concentration. A wizard may improve onboarding while hiding where the real controls are.

App ecosystems intensified this pressure. Store ranking, review scores, install conversion, screenshots, release cadence, and subscription conversion influence product choices. Research on user reviews and app updates found that more than sixty percent of matched reviews were irrelevant to release notes, and that relevant reviews varied across feature requests, complaints, bug reports, and praise. That means feedback is noisy. Good teams read it carefully; weaker teams chase the loudest signal or the easiest number.

Design polish is also expensive in a way metrics can undervalue. Removing a step may require architecture work. Making a complex screen understandable may require saying no to sales requests. Keeping keyboard shortcuts stable may constrain a redesign. Supporting old workflows may complicate onboarding. Polish is often the result of restraint, and restraint does not always create a launch announcement. A team can spend months making software feel calmer and have little to show in a growth dashboard except fewer complaints.

This helps explain why many products now feel overexplained and underconsidered. They offer banners, tours, tooltips, empty-state prompts, assistant widgets, upgrade cards, and celebratory modals, but basic tasks may require more waiting, scrolling, or permission checks. The product talks more while listening less. Good older software often had the opposite flaw: it could be cryptic, but once learned it moved quickly. The best modern design should combine approachability with expert speed. Too often, it chooses onboarding theater over long-term fluency.

Metric pressure also encourages constant surface change. A manager can run experiments on button labels, layouts, defaults, and upgrade prompts. Some experiments improve products. Others erode the stable mental model users need for real work. A tool that changes too often taxes the user’s memory. This tax is rarely counted. Training documents become stale. Support teams answer new questions. Experienced users lose speed. The organization sees activity; users feel churn.

The cure is not to abandon metrics. It is to subordinate metrics to product judgment. Teams should measure whether tasks finish faster, whether exports succeed, whether error recovery improves, whether support tickets drop for the right reasons, and whether expert users retain speed after redesigns. They should treat annoyance as a cost even when revenue rises. Good design research includes the user who stays for five years, not only the user who signs up today.

Good software from the past did not always look better. Some of it looked ugly. What people miss is the feeling that the interface was not constantly negotiating for attention. Polish means the tool disappears into the work. That standard is still possible, but only when leadership protects it from metric hunger.

Metric pressure also changes language inside companies. A user no longer “cannot find export”; export has a drop-off rate. A pricing prompt no longer interrupts work; it improves conversion. A redesign no longer slows experts; it increases engagement with a new navigation model. These translations are not always dishonest, but they can sterilize pain. The words used internally shape what gets fixed. Teams that speak plainly about frustration are more likely to reduce it. The strongest product cultures combine measurement with taste. They ask whether a change makes the product easier to live with, not only whether it moves a chart.

Users feel this cultural difference quickly. A product shaped by taste removes one annoying step. A product shaped only by metrics may add two more because each one has a dashboard. Judgment is the missing control surface. Good teams protect it. daily.

Performance costs hide behind faster hardware

A modern laptop or phone is vastly more powerful than the machines that ran old office suites, audio tools, and graphics programs. Yet many users feel software has not become proportionally faster. Hardware gains often disappear into heavier frameworks, larger assets, background services, telemetry, cross-platform layers, and network waits. The user experiences this as a small betrayal: the computer improved, but the button still lags.

Performance decay is rarely caused by one bad choice. A team may choose a cross-platform framework to ship on Windows, macOS, Linux, and the web with fewer engineers. It may embed a browser engine to reuse web skills. It may add analytics to understand failures. It may load remote configuration to support experiments. It may include AI features that call distant servers. Each choice can be rational. Together, they can make a note app feel heavier than an old desktop database.

Research on mobile application size found an “unprecedented growth” in mobile app size and argued that much of this growth may reflect poor resource and code management rather than proportional increases in functionality. The authors warned that large app downloads and updates can hurt users in bandwidth-constrained regions and contribute to a digital divide. Bloat is not only an aesthetic complaint; it can decide who can afford to use software.

Performance also hides in energy use and attention. A bloated app drains battery, heats the device, consumes mobile data, and competes with other work. A slow launch discourages quick capture. A lagging editor interrupts thought. A heavy update can block a user at the moment of need. Old software nostalgia often centers on immediacy: click the icon, get the tool. That immediacy is not childish. Latency changes behavior. People use fast tools more naturally because the tool does not demand planning.

Cloud architecture complicates performance. A web app can be excellent when it caches well, syncs intelligently, and avoids blocking local actions on remote calls. It can be miserable when every click depends on network round trips, account checks, entitlement checks, analytics calls, and overloaded services. Users may blame their device when the real cause is product architecture. A local-first design can help by letting work proceed offline and syncing later. Many modern apps still choose server authority for simplicity, control, or monetization.

Performance is also a management issue. A team must decide that speed matters before it can protect speed. Budgets, tests, and review processes should include launch time, memory use, bundle size, network calls, battery impact, and responsiveness under poor conditions. Speed should be treated as a feature with owners, not as a vague virtue. The best old software often gained speed by necessity because hardware was scarce. Modern software must choose scarcity artificially through performance budgets.

Users can tell when a product respects their machine. It does not start unnecessary background agents. It does not force huge updates for tiny changes. It does not load five dashboards before showing one document. It does not assume every user has unlimited bandwidth. It lets the main action happen before secondary services wake up. These details create trust because they show the vendor values the user’s time and hardware.

Good software went missing where faster hardware became an excuse to stop caring. The cure is not primitive technology. Modern tools can be rich, accessible, secure, and collaborative while still being fast. The old lesson is discipline: every added layer must earn its weight.

Performance is also a fairness issue inside companies. Engineers often test on new machines, office broadband, and warm caches. Users run older laptops, crowded phones, poor networks, locked-down corporate devices, and overloaded browsers. The average developer environment is not the average user environment. A product that feels acceptable in headquarters can feel hostile in a classroom, warehouse, train, clinic, or small business with weak connectivity. Good teams test under constraints. They measure cold starts, slow networks, low memory, battery drain, and offline recovery. That habit turns nostalgia for speed into an engineering requirement.

Speed work also forces architectural honesty. If a team cannot explain why a simple action needs a remote call, a large bundle, or a blocked main thread, the design has drifted. Fast software usually has fewer excuses. It does not treat every extra abstraction as free. It respects the user’s device as part of the product, not as an infinite subsidy. That respect is visible. especially under pressure.

Mobile software normalized planned replacement

Phones changed the emotional contract of software because they made software inseparable from hardware, identity, payments, cameras, location, notifications, and daily communication. A phone app is rarely just an app. It depends on operating-system versions, store policies, device permissions, push services, account systems, cloud sync, and hardware features. When any of those layers changes, an app that once worked may become unavailable, unsupported, or practically unusable.

This differs from the old personal-computer habit. A user could keep an old laptop offline and run a beloved program for years. A phone is harder to freeze. It is a security device, a payment device, a camera, a medical-alert surface for some users, a banking channel, and a social identity hub. It must receive security updates, and its app ecosystem expects current frameworks. The device’s safety role makes stasis harder. That is a legitimate reason for upgrade pressure, but it also normalizes short software lifecycles.

App stores reinforce that rhythm. Apple says apps should change and improve to stay on the App Store, and its app improvement process includes removing apps that no longer function as intended, fail current guidelines, or are outdated. From a platform view, this keeps the store safer and more useful. From a preservation view, it means old apps can disappear even if users still value them. The store’s maintenance standard can conflict with historical continuity.

Mobile monetization also trained users to accept conditional access. Free apps with ads, in-app purchases, subscriptions, coins, boosts, premium filters, cloud backup, and paywalled exports became normal. Some of that made software affordable to people who would not pay upfront. It also made many products depend on engagement, attention, and behavioral data. A simple utility could become a funnel. A game could become an economy. A photo editor could become a subscription. The phone turned software into a daily marketplace carried in the pocket.

The repair problem deepens the story. A mobile device may be physically repairable in theory but constrained by software pairing, diagnostic access, serialized components, activation locks, or cloud identity. The FTC’s “Nixing the Fix” report identified software locks and firmware updates among repair restrictions, and repair advocates have long argued that software control can limit lawful physical repair. Ownership of hardware now depends on software permissions.

Mobile app design also normalized interruption. Push notifications, badges, streaks, permission prompts, widgets, live activities, and account reminders reach users outside the moment of intentional use. Older desktop software usually waited for the user to open it. Modern mobile software often reaches outward. That can be useful for messages, travel alerts, medicine reminders, security warnings, and delivery updates. It becomes corrosive when every product claims urgency. Attention became an operating-system resource, and many apps compete for it.

The best mobile software resists those defaults. It asks for few permissions, works under weak connectivity, exports data, avoids dark patterns, supports old devices where safe, and explains why updates matter. It treats notifications as promises, not marketing inventory. It lets users accomplish a task quickly and leave. These qualities echo old software because they restore intentional use. A phone can still host excellent tools, but the platform’s gravity pulls toward account dependency, upgrade pressure, and continuous engagement.

Good software from the past seems missing on mobile because the device made software more governed, more networked, and more commercial at the point of use. Some of that governance protects users. Some of it reduces agency. The honest answer is that mobile software made planned replacement feel normal, even when a stable tool would have served people longer.

There is another quiet change: mobile users often rent continuity from the platform. Photos, passwords, messages, backups, and purchases follow the account. That convenience is powerful, but it makes the platform the memory keeper. A platform account becomes a private archive, and losing it can be worse than losing a single computer. Old software taught people to back up folders; mobile software teaches them to trust synchronization. Planned replacement also affects developers. Supporting older devices costs testing time, complicates design, and may block newer APIs. Dropping support can be rational. The obligation is clear communication and data preservation.

A better mobile culture would let the user distinguish safety updates from commercial churn. It would keep old data readable, publish device-support horizons, and stop pretending that every removal is progress. A phone can be current without being restless. The platform should protect the user from real threats while letting stable tools remain stable when they are safe.

Enterprise procurement rewarded suites over tools

Business software changed because buyers changed. The user is often not the buyer. Procurement teams, security teams, finance, legal, executives, and IT administrators may all shape the decision before daily users touch the product. Their concerns include security, compliance, integration, support, identity, audit logs, billing, and vendor risk. Yet this buying structure rewards suites that answer organizational checklists, even when a smaller tool would serve users better.

A suite has appeal. One vendor, one contract, one identity system, one invoice, support, and one compliance review can reduce administrative burden. Vendors can offer enterprise controls, uptime commitments, regional data options, migration services, and integration roadmaps. For a company with thousands of employees, those features matter. Administrative simplicity can beat product elegance. The buyer may accept a slower interface if it reduces complexity and satisfies review.

The cost is that software can become designed around the sale rather than the daily task. A product may add dashboards for executives, permission layers for administrators, AI summaries for presentations, compliance exports for auditors, and integration claims for procurement. The daily user receives a crowded interface because every stakeholder got a tab. A focused old tool served the person doing the work. A modern enterprise suite serves the buying committee. The result is not always worse, but the center of empathy moves.

Vendor consolidation also weakens exit. A company that adopts a suite for email, documents, identity, storage, chat, device management, and security may find that replacing one part means disturbing many others. That bundle can be efficient, but it creates bargaining power for the vendor. The suite becomes infrastructure, and infrastructure is hard to leave. Microsoft’s fiscal 2025 report highlights the scale of cloud and platform revenue behind this model, while Salesforce’s annual results show the strength of subscription and support revenue in enterprise software.

Enterprise buyers also reward roadmap promises. A vendor can win a deal by showing future AI, analytics, compliance, or workflow features that reassure executives. A small focused product may be better today but lose because it lacks a grand platform story. That pushes software makers toward breadth. Every product wants to become a workspace, operating layer, system of record, or intelligence platform. The ambition expands before the craft catches up.

This is one reason workers complain about tools that their employers still renew. The product may meet the contract’s goals while failing the user’s day. It may centralize data, simplify administration, and satisfy security requirements, yet still slow the person writing a report, processing a claim, designing a part, scheduling a job, or answering a customer. Quality becomes split between organizational quality and human quality. Good software must serve both, but enterprise procurement can overweight the first.

A better procurement culture would include user-speed tests, migration tests, export tests, accessibility reviews, cancellation clarity, and long-term support questions. It would ask whether the product respects expert workflows after six months, not only whether it demos well in a sales call. It would give daily users formal influence before renewal. The best contract is not always the best tool, and companies pay for that gap through training, workaround spreadsheets, shadow IT, and morale loss.

Good old software often reached organizations through departments that needed a specific job done. Modern enterprise software often arrives as part of a strategic platform decision. That shift explains why tools can feel worse while procurement looks successful. Software went from being bought for the craft of a task to being bought for governance of an organization. The challenge is to make governance support craft instead of burying it.

Enterprise software also suffers from “checkbox gravity.” A feature may exist because it helped win a contract. Once present, it must be documented, tested, and supported. The suite grows because removing a feature may anger one large account. Sales promises become product mass. That mass slows the people whose work the suite was meant to serve. Good enterprise buyers can counter this by treating simplicity as a requirement. They can ask vendors to show task completion, not only architecture diagrams. They can measure time saved. Procurement can reward calm software if it chooses to.

The internal economics are subtle. A suite that saves the IT department time may cost every employee a few minutes each day. Multiplied across a company, that loss can exceed the administrative saving. User time belongs in the business case. If procurement ignores it, the organization buys neat management and pays with scattered frustration.

Preservation became a legal and technical job

Keeping software alive used to mean keeping a copy. Now it means preserving code, dependencies, formats, licenses, runtime behavior, documentation, and legal permission. A program is not only its executable. It may require a compiler version, operating-system API, graphics library, database schema, cloud service, activation server, certificate, font, codec, or hardware peripheral. Without those pieces, the copy may be historically interesting but unusable.

Institutions have adapted. Software Heritage aims to collect, preserve, and share publicly available source code. The Library of Congress treats digital preservation as an active workflow involving packaging, ingest, storage monitoring, file formats, metadata, and related practices. The Internet Archive’s software collections use emulation to make old software accessible through browsers. Preservation is no longer a shoebox; it is infrastructure.

The legal side is complicated. Copyright law, license agreements, anti-circumvention rules, trademark concerns, server code, and abandoned rights can all restrict preservation. In the United States, the Librarian of Congress periodically adopts exemptions to the DMCA’s anti-circumvention prohibition. The 2024 Federal Register rule continues a triennial process of exemptions, including repair-related and preservation-related issues, but exemptions are narrow and time-limited rather than a universal right to keep every program working. Legal permission often lags behind cultural need.

Cloud software adds a further obstacle. If a service was never distributed, archivists may not have the server code. If the server code exists, it may include secrets, user data, third-party licenses, proprietary models, or infrastructure assumptions that cannot be published. Even when code is available, running it may require identity systems, payment integrations, moderation tools, and content databases. Preservation of cloud products can therefore require cooperation from the vendor before shutdown. Without that cooperation, the archive becomes fragmentary.

Adobe Flash forced society to face this problem at scale. Its retirement improved security, but it endangered access to a large body of interactive culture. Emulators and preservation projects can rescue some content, yet the transition shows that formats controlled by one runtime can create cultural debt. A proprietary runtime can become a historical bottleneck. The better long-term path is open standards, documented formats, and exportable assets before a platform reaches end of life.

Preservation also matters for business continuity. A company may need to read old contracts, engineering drawings, medical records, research data, or accounting files decades after the original software vendor is gone. If the file format is proprietary and undocumented, the organization may be trapped. If activation servers are dead, the program may not launch. If old operating systems cannot be secured, the archive may require isolated machines. Good software therefore includes a legacy strategy. It should document formats, support export, and offer read-only access after commercial life ends.

Users can support preservation by preferring open formats, saving installers where lawful, exporting important work, documenting workflows, and choosing tools with clear data models. Organizations can go further by requiring archival clauses in contracts and testing restoration before a crisis. Backup is not preservation unless restore works. A folder full of files means little if no maintained tool can read them.

Good software from the past did not disappear only because companies became greedy. Some disappeared because nobody planned for legal and technical continuity. The software industry built extraordinary tools while treating longevity as an afterthought. That must change. If software shapes culture, work, science, and memory, then preserving it is not a hobby. It is part of responsible production.

Preservation requires humility from vendors. Many companies assume a shutdown is clean if they give notice and export files. That is not enough when the product created behaviors, metadata, automations, and community practices that do not fit a flat export. The archive must preserve meaning, not only blobs. A project-management export without comments, permissions, timestamps, and attachments may be legally safe but historically and operationally weak. A mature vendor should plan for sunset from the first architecture review. That means open formats where possible, documented APIs, migration partners, read-only modes, and escrow arrangements for critical public-interest software. The best time to design an exit is before anyone needs it.

Public institutions have a special duty here. Schools, libraries, courts, hospitals, and governments should not adopt systems that trap records in fragile formats or vanish behind abandoned portals. Public memory needs public-minded software contracts. The private sector should care too, because litigation, audits, and customer service often require old data long after a vendor relationship ends. That obligation is practical. now.

Rules now push against lock-in

Regulators have begun to treat software lock-in as a market and consumer problem, not only a private annoyance. The law is starting to ask whether users, developers, and businesses can leave, interoperate, repair, and understand the products they depend on. The answer remains uneven, but the direction matters. The old software bargain gave users local control by default. Modern rules try to recreate pieces of that control inside cloud, mobile, and connected-device markets.

The Digital Markets Act targets gatekeepers that control core platform services such as app stores, search engines, operating systems, and messaging. The European Commission says the DMA sets objective criteria for identifying gatekeepers and imposes obligations and prohibitions. The Data Act, applicable from September 12, 2025, addresses data access and includes cloud switching and portability goals. The Cyber Resilience Act addresses products with digital elements and the lack of timely security updates. Together, these rules define durability as a public-interest issue, not only a product preference.

The table below summarizes the regulatory themes that matter most for the future of good software.

Table 2: Regulatory pressure on modern software lock-in

These rules do not restore the old world. They try to make modern software dependence less one-sided.

Apple’s response to the DMA shows the tension. Apple says it created hundreds of APIs and options for alternative app marketplaces and alternative payments in the European Union, while warning that the changes introduce risks including malware, fraud, scams, harmful content, and reduced ability to remove problematic apps. That is a serious policy conflict: openness can reduce lock-in while increasing governance risk. Good regulation must face both sides rather than pretending one value erases the other.

Competition enforcement is moving in parallel. The U.S. Justice Department and state attorneys general sued Apple in March 2024, alleging monopolization or attempted monopolization of smartphone markets. The UK CMA investigated Apple’s mobile platform under its strategic market status framework and confirmed Apple and Google had substantial, entrenched market power in their mobile platforms. These proceedings show that platform rules are no longer treated as purely internal product decisions. Private software governance is becoming public policy.

Regulation can fail if it is too slow, too vague, or too focused on paperwork. It can also create compliance burdens that smaller developers struggle to carry. A giant platform may absorb complex rules more easily than a small competitor. That is why the best policy must connect rights to practical implementation: usable export, tested interoperability, documented APIs, repair access, security support, and clear enforcement. A right that exists only in a legal text does not help a user migrate a decade of work.

The point is not that regulators will make software good. They cannot design a calm interface or write a clean file format by decree. They can change the bargaining conditions. They can make lock-in less profitable, force gatekeepers to justify rules, require security care, and reduce switching barriers. Good software still needs craft, but craft survives better when users have rights.

The old software world gave control accidentally through technical limits. The new world needs control deliberately through design, contract, and law. That is a profound change. The software that people miss will not return as nostalgia. It may return as portability, interoperability, repairability, and support obligations.

The rulemaking trend also pressures companies to define what they mean by safety. A gatekeeper can no longer assume that “security” ends the argument. It may need to explain why a restriction is proportionate, whether a less restrictive alternative exists, and how users or developers can challenge decisions. Good governance requires reasons, not only policies. That shift may improve software quality indirectly because it forces platforms to document the trade-offs they once controlled privately. Users should not expect law to remove all friction. Portability can still be messy, and interoperability can expose compatibility risks. But law can make the exit door visible, documented, and harder to close.

The July 2026 Apple decision in the EU shows that the argument is not theoretical. Reuters reported that the General Court rejected Apple’s challenge to DMA enforcement around iOS and app-store gatekeeper designation, while Apple continued to argue that the rules threaten privacy and security. The court result strengthens regulatory pressure, but the policy debate remains alive because the security trade-offs are real.

Regulation also changes product strategy. A vendor that expects portability duties may design cleaner data models from the beginning. A platform that expects scrutiny may write clearer developer rules. A manufacturer facing cyber duties may budget for support after sale. Rules shape architecture before enforcement begins. That is why software buyers should track law as part of vendor risk, not as a separate compliance topic.

Right to repair exposed software as control layer

Right-to-repair debates revealed something many users already suspected: software can decide whether ownership is real. A device may be in the user’s hands, but firmware, diagnostics, serialized parts, cloud activation, calibration tools, and cryptographic pairing can determine if repair works. The wrench is no longer enough. Repair increasingly requires permission from code.

The FTC’s “Nixing the Fix” report identified software locks, firmware updates, end-user license agreements, proprietary diagnostic software, and other restrictions as part of the repair landscape. The report did not say every manufacturer argument is false; safety, security and privacy can matter. It did show that repair barriers are not only mechanical. They are also contractual and digital. The repair shop now meets the software stack.

This matters beyond phones and laptops. Cars, tractors, medical devices, appliances, cameras, printers, industrial machines, and smart-home products all contain software. When a vendor controls diagnostic access or pairs replacement parts through software, independent repair becomes harder. When firmware updates disable third-party components or cloud accounts block activation, a product can be owned physically but controlled operationally. The question “Where did good software go?” becomes “Who decides what the machine may do after sale?”

Anti-circumvention law complicates the answer. The 2024 Federal Register rule on exemptions to the DMCA’s circumvention prohibition reflects a recurring process for allowing certain lawful activities, including repair and preservation-related activity, under defined conditions. These exemptions matter because software locks may otherwise make ordinary repair legally risky. Yet narrow exemptions are not the same as broad ownership freedom. A repair right that requires legal expertise is weak in practice.

Manufacturers have real concerns. A bad repair can create safety hazards. Unauthorized access to diagnostics could expose personal data. Tampered firmware can weaken security. Counterfeit parts can fail. These risks should be addressed directly. But they should not be used as blanket justification for blocking independent repair, withholding parts, or making devices disposable. Good software can support secure repair through authenticated tools, audit logs, limited privileges, documented calibration, and clear warnings without forcing every repair through a monopoly channel.

Right to repair also intersects with sustainability. A device retired because of a software lock becomes waste even if its hardware could serve longer. Software that refuses parts, blocks batteries, or ends server support can shorten product life. Durability is environmental as well as technical. The old software world produced waste too, but connected devices multiply the effect because so many physical objects now depend on software permission.

For consumers, the practical question is whether a product remains useful when the vendor is not involved. Can it be repaired by an independent shop? Can parts be calibrated? Can the device work without a cloud account? Are firmware updates documented? Does the manufacturer support security without disabling lawful repair? Can data be exported before service? These questions belong in product reviews as much as camera quality or processor speed.

Good software should make repair safer, not impossible. It should guide technicians, protect sensitive data, verify part quality, and preserve user choice. When software becomes a lock whose main purpose is channel control, it stops serving the owner. That is where much good software went: into devices that could have been repairable but were made dependent on permission. The repair movement exposes the deepest lesson of modern software: control is often hidden in code that users never see.

Right to repair also changes how people evaluate updates. A firmware update can improve security, but it can also alter part compatibility, diagnostic access, or device behavior. Users and repair shops therefore need release notes that explain repair-relevant changes. Silent firmware policy is bad ownership policy. If a vendor changes calibration, pairing, or supported components, the owner deserves to know. This is where software quality meets trust. A company that respects repair reduces suspicion around updates. A company that hides repair restrictions trains users to fear every patch. Security and repair need not be enemies if vendors design for both.

The same logic applies to schools, hospitals, farms, and small businesses. A locked device can become a local economic problem when authorized service is far away or expensive. Independent repair is not only a hobbyist demand. It is resilience for communities. Software that blocks it centralizes power in places where downtime is costly.

A repairable product also needs graceful failure. If a cloud diagnostic service is down, basic repair should not become impossible. If an account is locked, the owner should have recovery options. Repairability is a design requirement, not a gesture.

AI coding changes the next maintenance problem

AI coding tools are not a side story. They change how software is produced, reviewed, and maintained, and they will shape whether the next generation of tools feels better or worse. Code assistants can speed up routine work, suggest tests, translate APIs, explain old code, generate documentation, and help small teams build features that once required more staff. That is real value when the human team remains responsible for architecture, security, and product judgment.

The risk is not that AI writes code. The risk is that organizations treat generated code as free progress without funding the review and maintenance it creates. GitHub’s 2025 Octoverse report said AI-related repositories exceeded 4.3 million and that more than 1.1 million public repositories used LLM SDKs. A separate 2025 study of AI-generated code in public GitHub repositories examined files attributed to major AI tools and identified thousands of Common Weakness Enumeration instances through CodeQL analysis, while also finding that most analyzed files did not contain identifiable CWE-mapped vulnerabilities. The evidence supports caution, not panic.

AI may improve old-software preservation. It can help translate legacy languages, summarize undocumented code, generate tests around old behavior, and explain dependencies to new maintainers. A small team inheriting a neglected codebase may use AI as a reading companion. That could rescue software that would otherwise be abandoned. Yet AI can also create plausible misunderstandings. If a tool rewrites code without understanding why an old edge case exists, it can erase hard-earned knowledge. Maintenance requires memory, and AI has no lived memory of the incidents that shaped a system unless humans preserve it.

AI features inside end-user software also repeat earlier economic pressures. Some additions are genuinely useful: transcription, search, accessibility, translation, anomaly detection, and summarization can reduce work. Others appear because AI creates a new plan tier, a new investor narrative, or a reason to collect more data. Users can tell the difference. An AI feature that shortens a real task feels like craft. An assistant panel that blocks the interface, hallucinates, or upsells credits feels like another layer of noise.

Security work must adapt. AI can help find vulnerabilities, but attackers can use AI to generate exploit ideas, phishing text, malicious packages, or variant code. Vendors will need stronger review, testing, provenance tracking, and secure-by-design habits. NIST’s SSDF, CISA’s Secure by Design guidance, and SLSA-style supply-chain thinking become more relevant, not less, when code generation accelerates. The faster code appears, the more disciplined review must become.

AI also threatens software taste. A model can generate many features quickly, but it cannot decide which features should not exist. It can fill a settings page, write a wizard, and draft onboarding text. It cannot feel the irritation of a user whose quiet workflow now has five extra panels. The old software people miss was often shaped by scarcity. Limited time forced teams to choose. AI reduces some production scarcity, which makes editorial restraint more important. The bottleneck moves from typing code to choosing meaning.

Good AI-assisted software will keep humans responsible for architecture, security, privacy, and user respect. It will disclose when AI is used where that matters, avoid sending sensitive data without clear consent, offer non-AI paths for core work, and treat generated output as draft material. It will use AI to reduce toil rather than increase lock-in. It will help users leave, not trap them in proprietary summaries and embeddings they cannot export.

AI may bring back some of the old magic if it helps small teams build fast, local, respectful tools. It may worsen software if it becomes a factory for features no one asked for. The outcome depends on incentives. AI amplifies product culture. In a careful culture, it can repair and explain. In an extractive culture, it can decorate decay at scale.

There is also a labor issue. If AI makes it cheap to create code but not cheap to understand responsibility, companies may produce more systems than they can maintain. A codebase can grow faster than institutional knowledge. Generated code still enters the human maintenance queue. Someone must decide whether it fits the architecture, whether it handles failure, whether licenses and data use are acceptable, and whether it should exist at all. The better use of AI may be less glamorous: writing regression tests for old behavior, finding dead code, explaining error paths, drafting migration guides, and helping maintainers understand unfamiliar modules. Those jobs strengthen durability rather than merely increasing feature volume.

Local-first software points to a quieter answer

Local-first software offers one of the clearest answers to the complaint about lost quality. It puts the user’s work on the user’s device first, then uses the network for synchronization, collaboration, and backup rather than making the server the only source of truth. The idea does not reject the cloud. It changes the order of dependence. Work should continue when the network is weak, the vendor is down, or the user wants a personal archive.

This approach restores several old virtues without denying modern needs. It brings back fast local interaction, offline access, file-like ownership, and user-controlled backups. It can still support multi-device sync, sharing, conflict resolution, encryption, and team collaboration. A local-first note tool, writing app, database, or design system can feel modern while keeping the user’s work close. The difference is architectural respect: the app treats the device as a real home for data, not merely a terminal for a remote account.

Local-first design also improves exit. If data lives in documented local formats, a user can back it up, inspect it, migrate it, and sometimes repair it. If sync is an added service rather than the only way the product exists, a vendor shutdown is less catastrophic. The product may lose collaboration features, but the user’s archive remains. That is a better failure mode than a login screen that no longer accepts credentials. A graceful failure is a feature.

This does not mean local-first is easy. Synchronization is hard. Conflict handling is hard. Encryption is hard. Sharing permissions are hard. Collaboration across devices and teams requires careful design. Companies may also prefer server authority because it simplifies billing, analytics, enforcement, and support. A local-first product may be harder to monetize through usage gates because the user’s data is less captive. That is precisely why the architecture matters. It resists some of the pressures that made software feel worse.

Security trade-offs need honesty. Local data can be lost if a device fails and backups are poor. A stolen laptop can expose files if encryption is weak. Sync conflicts can confuse users. Enterprise administrators may need retention and discovery controls. Local-first does not remove responsibility; it relocates it. Good products must make backup, encryption, and recovery clear. They should not romanticize local storage as automatically safer. The old desktop era taught that local files without backup can vanish in one disk failure.

The strongest local-first tools combine local speed with transparent sync. They show where files live. They make export ordinary. They avoid hiding the user’s own work inside an opaque account. They let individuals use the product without surrendering future access. For teams, they provide administrative controls without making every action depend on the vendor’s server. They offer cloud convenience while preserving local dignity.

Local-first also has cultural value. It trains users to understand that their work is theirs. A student can keep notes after graduation. A writer can archive drafts. A researcher can preserve data with a paper. A small business can move records if a vendor changes price. The user’s archive becomes independent of the vendor’s mood. That independence disciplines the vendor. If users can leave without losing themselves, the product must compete on care.

Good software from the past went missing where the network became a leash instead of a bridge. Local-first software turns the network back into a bridge. It may not fit every product, especially large real-time platforms, but it points toward a healthier default for personal and professional tools. The future does not need to abandon the cloud; it needs to stop treating the cloud as ownership’s replacement.

Local-first design also changes the emotional tone of software. A user who knows work exists locally tends to feel less anxious about price changes, outages, account mistakes, and acquisitions. That confidence matters. Trust is partly architectural. A product that lets users keep their own archive feels calmer because its failure modes are less absolute. Businesses can adopt the same principle. A company may still use cloud sync and collaboration, but it should keep recoverable local or independent copies of critical records. The question is not whether the cloud is bad. The question is whether the organization can function if the cloud relationship changes.

A local-first product should still make recovery easy for ordinary people. Files hidden in obscure folders are not enough. Users need clear backup paths, readable exports, and conflict messages they can understand. Ownership must be usable, not merely theoretical.

Interoperability became the practical antidote

Interoperability is the plainest cure for software decline because it weakens captivity. When tools can exchange data through open formats, documented APIs, and shared protocols, users can choose better software without abandoning their history. That choice changes vendor behavior. A company that knows customers can leave must compete on quality, price, reliability, and respect. A company that controls the only door can let the room deteriorate.

Older software often failed this test. Proprietary formats trapped users inside word processors, graphics tools, accounting packages, and databases. Yet the desktop era also produced durable interoperability habits: plain text, CSV, PDF, email protocols, image formats, archive formats, command-line pipes, and file-system conventions. These humble standards preserved work across decades. The most durable software culture is often built on boring formats.

Modern cloud tools sometimes weaken interoperability by calling export a feature rather than a baseline. A user may get a ZIP file, but lose comments, permissions, version history, automations, tags, links, or metadata. An API may exist but be rate-limited, expensive, incomplete, or unstable. A product may support import from competitors more carefully than export to them. That asymmetry tells users where the business interest sits. Good software treats exit and entry with equal seriousness.

The EU Data Act reflects this problem at policy scale. The Commission says the Data Act allows consumers to transfer data and switch between cloud providers, and it applies from September 12, 2025. The Digital Markets Act also targets gatekeeper services and contestability. Regulation cannot solve every technical detail, but it can make portability and interoperability harder to dismiss as optional. Switching costs are now a policy concern.

Interoperability also supports preservation. A documented format can be read by future tools. A public API can be archived and reimplemented. A standard protocol can allow alternative clients. A platform that supports interoperable messaging, file access, or identity reduces the damage if one product fails. The preservation lesson is simple: if no one else can understand the data, the user’s archive depends on the vendor forever. That is too fragile for serious work.

Vendors often resist interoperability for reasons that are not entirely cynical. Supporting stable APIs costs money. Open formats can constrain new features. Interoperable systems can introduce abuse, spam, inconsistent behavior, or security risk. A poorly designed export can leak data. A shared protocol can be exploited. Openness needs engineering discipline. The answer is not reckless openness; it is documented, tested, permissioned interoperability with security models that do not pretend lock-in is the only safe option.

Businesses should make interoperability a procurement requirement. They should test export before signing, not after cancellation. They should ask whether APIs cover the full data model, whether documentation is public, whether limits are fair, whether webhooks exist, and whether deletion and migration are auditable. They should prefer vendors that support standard formats. A beautiful product with no exit is a future migration crisis.

For individual users, interoperability means choosing tools that keep notes in Markdown, photos in standard formats, calendars in exportable files, passwords in transferable vaults, and documents in formats that other programs can read. It means distrusting products that make import easy and export vague. A good tool does not fear the user’s freedom.

Interoperability is not glamorous. It does not photograph well in a launch video. Yet it is the backbone of durable software. The old tools people miss often worked in personal ecosystems the user could understand. Modern software can recreate that strength by making boundaries porous. Where software went bad, exit became expensive. Where software stays good, movement remains possible.

Interoperability also reduces political fights inside organizations. If data moves cleanly, teams can choose specialized tools without turning every choice into a permanent platform war. Finance can use one system, design another, support another, and still exchange reliable records. Open boundaries make specialization safer. Without them, every department is pressured into the same suite because integration fear wins. Developers benefit too. A stable API or format lets a small company build alongside a large platform rather than asking permission for every idea. That is how ecosystems stay creative after the original platform matures.

The technical work can be dull: schemas, versioning, authentication scopes, rate limits, change logs, and test suites. That dullness is exactly why it matters. Interoperability fails when nobody funds the boring edges. A polished export button that drops half the record is not portability; it is theater.

Small teams still build good software

Good software still appears wherever a small team can stay close to the user and the code. Small teams often have the shortest path between pain and repair. They do not always have more talent than large companies, but they have fewer layers between a real complaint and a product decision. A founder can notice that a menu is annoying. A maintainer can reject a feature that would slow the product. A support email can become a patch.

The strongest small tools usually share traits. They have a clear job, plain pricing, visible release notes, fast launch times, local or exportable data, honest support, and a maker who can explain why the product exists. They are not always pretty. They may lack enterprise dashboards, procurement packets, or giant integration catalogs. Their advantage is that the product has not been asked to become everything. A narrow tool can be generous inside its boundaries.

The modern market makes small-team software harder to find. App-store charts favor scale, ads favor funded companies, search results favor content budgets, and enterprise buyers favor vendors with compliance paperwork. A small product may be better for the actual work yet invisible to the buyer. That is why communities, newsletters, open-source repositories, professional forums, and word of mouth still matter. They function as human discovery systems for tools that do not win through paid distribution.

Small teams also face real risks. A beloved tool can depend on one developer’s health, finances, or motivation. Support can collapse after growth. Security work can exceed the team’s capacity. A platform rule change can break distribution. An API dependency can disappear. Indie software is not automatically durable. Users should respect small developers by paying for tools they rely on, keeping backups, and understanding support limits. Developers should protect users by documenting exports and continuity plans.

Some of the best small-team software is paid, not free. A fair price can keep the tool independent from ads, surveillance, and investor pressure. Users who demand everything free often push makers toward business models they later dislike. The old shareware culture understood this better than many modern users: pay the person who built the thing, and the thing may remain answerable to you. Direct payment can align incentives when the product scope stays honest.

Large companies can learn from small teams by creating internal product boundaries. A small team inside a large company can own a focused workflow, protect speed, and say no to unrelated initiatives if leadership allows it. The problem is not size alone; it is loss of accountability. When a product becomes a container for every strategic theme, the user disappears. Good software needs someone responsible for the whole experience, not only for a metric slice.

Small teams also prove that modern users still reward craft. People pay for writing apps, database tools, password managers, development utilities, calendar clients, design plugins, automation tools, and niche professional software because those products reduce friction. They may not dominate headlines, but they build loyalty. That loyalty is often quieter than platform growth, yet it is more stable. Trust compounds when the product keeps its promise.

The answer to the user’s question is partly hopeful. Good software did not all become worse. Much of it went small, specialized, and sometimes quiet. It lives where makers know the work, where users can speak plainly, and where the business does not require constant extraction. Finding it takes more effort because distribution favors giants. But it exists, and it reminds the industry that craft is still a viable strategy.

Small teams can also preserve personality. Many users like software that has a point of view: a writer’s tool that refuses clutter, a database that favors plain structure, a calendar that respects keyboard use, a drawing app that starts instantly. Large products often sand away those choices to serve every segment. Taste is easier to protect at small scale. It can be wrong for some users and exactly right for others. The weakness is succession. A good small product needs a plan for what happens if the maker stops. Source escrow, export formats, documented internals, and a public sunset promise can turn personal craft into durable trust.

Small teams should not romanticize themselves. A tiny company can ignore accessibility, delay security patches, or disappear overnight. Users should look for signs of operational maturity as well as charm. Good small software is both personal and prepared. It has backups for the maker’s absence.

Good old software also had blind spots

Any honest answer must admit that older software was not a lost paradise. Many old programs were insecure, inaccessible, unstable, undocumented, and hostile to new users. They crashed without autosave, stored data in fragile formats, ignored screen readers, assumed one language, mishandled Unicode, lacked encryption, required obscure drivers, and treated backup as someone else’s problem. The past produced masterpieces, but it also produced plenty of junk.

Survivor bias shapes memory. People remember the tools that lasted, not the piles of shovelware, spyware, broken installers, incompatible drivers, registration hassles, and vanished vendors. A beloved old program may feel better because only its best years are remembered. The bad releases, corrupted files, and support nightmares fade. Nostalgia edits the archive. Good analysis must separate the qualities worth preserving from the failures that modern software rightly fixed.

Modern software improved many things. Autosave saves work. Cloud backup rescues lost devices. Accessibility APIs support more users. Unicode and localization widened participation. Sandboxing reduces some risks. Store review blocks some malware. Version control improves collaboration. Managed updates patch vulnerabilities faster. Browser-based tools let people work without complex installation. These gains are real. Users who miss old software often miss control and simplicity, not necessarily the whole old technical environment.

Older software also had harsh gatekeeping. It often assumed users could understand manuals, file systems, driver settings, and cryptic errors. A professional tool might reward experts while excluding beginners. Modern onboarding can be annoying, but the goal of making software understandable is not wrong. Clarity for new users is a moral improvement when it does not destroy speed for experienced users. The best products serve both by offering simple starts and deep paths.

Security was the biggest blind spot. Many old programs trusted files, plugins, macros, and networks too easily. They ran with broad permissions and little isolation. They were often updated manually, if at all. A world of connected devices cannot return to that model without unacceptable risk. The right lesson from old software is not “never update.” It is “update with restraint and respect.” Security maintenance should protect the user’s work without treating every update as a chance to redesign the business model.

Old business models had problems too. Paid upgrades could pressure vendors to add visible features even when users wanted fixes. Copy protection could punish honest customers. Proprietary formats could lock data away. License audits could scare organizations. Vendors could vanish without refunds or export paths. The old contract gave control, but not always fairness. The task is to keep the control while improving fairness, security, and accessibility.

This distinction matters because nostalgia can become an excuse for bad recommendations. Telling users to run obsolete software on connected systems may be unsafe. Telling businesses to reject cloud tools entirely may ignore collaboration and resilience needs. Telling developers to avoid subscriptions may ignore the cost of maintenance. A serious answer must be selective. Keep local ownership, stable interfaces, speed, export, and user respect. Reject insecurity, exclusion, hidden formats, and abandonment.

The past is useful as a design library, not as a destination. It shows that software can feel calm, durable, and personal. It also shows why maintenance, security, and accessibility had to improve. Good modern software should combine old control with modern care. That is harder than copying the past, but it is the only answer worthy of users who need tools they can trust for years.

Old software could also be socially narrow. Many products were built for offices, languages, bodies, and networks that designers assumed were normal. Modern accessibility and internationalization work corrected some of that exclusion. A tool is not truly good if only a narrow group can use it well. This is an area where modern software should not imitate the past. The better nostalgia is specific. Users want stable mental models, speed, ownership, and dignity. They do not need the return of unreadable error codes, fragile installers, or indifference to disabled users. The distinction keeps criticism fair.

There is also a class difference in nostalgia. Power users remember tools they mastered; casual users may remember confusion. A program that felt efficient to an expert could feel punishing to a new worker. Good software should let skill grow without making entry humiliating. That is a modern lesson worth keeping. It protects the beginner while still rewarding practice. The past teaches, but it should not govern. Only selectively. not blindly.

Businesses need durability clauses now

Businesses should stop treating durability as a nice-to-have. A software contract should say what happens when the relationship changes. Companies ask about price, security, uptime, integrations, and support, but many do not test whether they can leave. That is dangerous. A tool that holds customer records, engineering files, financial workflows, legal archives, or operational history can become a business dependency as serious as a lease or loan.

Durability clauses should start with data. The contract should define export scope, export format, metadata coverage, attachments, comments, audit logs, version history, and timing. It should state whether exports are available during billing disputes, after cancellation, and after the vendor announces shutdown. It should define whether APIs provide the same data as the interface. A backup that omits the working context is not enough. A project board without status history or a CRM export without activity records may fail when the business needs evidence.

Support life matters too. Vendors should publish update periods, deprecation timelines, API retirement notice, browser and operating-system support, and migration assistance. The Cyber Resilience Act shows that security updates for products with digital elements are becoming a regulatory expectation in the EU. NIST’s SSDF and CISA’s Secure by Design guidance also show that secure development practices are part of software quality, not extras. The contract should connect security promises to dates and duties.

Businesses should also demand change discipline. A vendor should explain how major interface changes are announced, whether long-term support channels exist, whether administrators can delay disruptive changes, and whether feature removals require notice. For critical workflows, surprise redesigns can create operational cost. Training materials break. Standard operating procedures become stale. Support teams lose speed. A software change can look minor to the vendor and expensive to the customer.

AI clauses now belong in durability planning. If a product uses AI to summarize, classify, recommend, or generate content, the contract should say whether prompts, outputs, embeddings, fine-tuning data, and model-dependent records can be exported or deleted. It should state whether customer data is used to train models. It should describe fallback behavior if an AI feature is withdrawn. AI output should not become another proprietary trap.

Repairability and interoperability belong in procurement even for cloud services. The buyer should ask whether the product supports standard formats, whether webhooks and APIs are documented, whether integrations can be replaced, and whether self-hosted or escrow options exist for critical systems. The EU Data Act’s cloud switching goals make this mindset more current, but businesses should not wait for law to save them. Exit should be tested before signing, not during a crisis.

Durability clauses also protect vendors. Clear expectations reduce angry exits, support disputes, and accusations of bad faith. A vendor that documents migration honestly may lose some lock-in, but it gains trust with serious buyers. The best customers understand that software maintenance costs money. They are more willing to pay when the vendor treats their data and workflows with respect.

A practical buying process should include an exit drill. Export data from a trial account. Restore it into another tool or archive. Read the API documentation. Ask support about cancellation. Check deprecation notices. Review the security lifecycle. Run the product on a slow machine. Involve daily users before renewal. The demo should include leaving. That single habit would expose many weak products before they become expensive dependencies.

Good software in business is not only the product that wins the RFP. It is the product that remains usable, explainable, secure, and recoverable after the sales cycle ends. Companies that buy for durability will get better software because they will reward vendors for the qualities people miss from the past.

Durability clauses should also define deletion. A company leaving a vendor needs proof that data was removed from production systems, backups, analytics stores, support attachments, and AI pipelines. A vendor that cannot explain deletion cannot fully explain custody. Regulated sectors should treat this as central vendor risk. The same logic applies to acquisitions. If a vendor is sold, customers should know whether terms, data handling, and support commitments transfer unchanged. A product may feel stable until ownership changes. Contracts should make continuity stronger than the press release.

A buyer does not need to make every contract long and hostile. It can use a simple durability schedule covering export, deletion, support dates, API notice, and migration assistance. Plain obligations beat vague assurances. Vendors that already practice good stewardship should welcome clarity because it distinguishes them from products that rely on confusion.

Users can spot quality before lock-in

Individual users cannot audit an entire software company, but they can look for warning signs before becoming dependent. The first question is where your work lives. If a note, photo, design, password vault, budget, or project exists only behind one account, the tool deserves extra scrutiny. If the product stores data locally in a readable format or offers complete export, the user’s future is safer.

The second question is whether the product respects the main task. A good tool opens quickly, asks for few permissions, explains necessary accounts, avoids surprise notifications, and keeps basic actions close to the surface. A weak tool greets the user with banners, upgrade prompts, tours, AI panels, and locked buttons before the job begins. Friction at the start often predicts friction later. The first session is not everything, but it reveals what the company thinks is important.

Users should test export early. Create a small sample, add comments, attachments, tags, or formatting, then export it. Open the result somewhere else. If the export is broken, incomplete, hidden, or paywalled, treat that as a major defect. A product that makes leaving hard before you depend on it will not become kinder after years of data accumulate. Export quality is product quality.

Update behavior is another signal. Good vendors publish clear release notes, separate security fixes from feature changes, and communicate removals before they happen. Bad vendors hide major changes under vague wording, force redesigns without explanation, or treat complaints as resistance to progress. Users should prefer products that support stable workflows and offer settings that respect expert habits. A tool that changes constantly may be lively, but it can also be unreliable in meaning.

Privacy and permissions matter. A flashlight, calculator, writing tool, or local editor should not ask for access unrelated to its job. A cloud collaboration tool may need more permissions, but it should explain why. Users can check platform privacy labels, permission prompts, and account requirements. Unnecessary access is a trust smell. It may signal analytics hunger, advertising incentives, or careless design.

Pricing should be legible. A fair subscription states limits, cancellation terms, storage rules, AI credit costs, and what happens after nonpayment. A suspicious product hides cancellation, buries limits, or locks core user data behind continued payment. The vacated FTC click-to-cancel rule showed how contentious subscription cancellation remains in the United States, while current negative-option guidance still stresses disclosure and cancellation information. Users should treat unclear billing as a product warning, not a paperwork issue.

Community signals help. Search for complaints about lost exports, account bans, pricing changes, slow performance, and support silence. Look at how the vendor responds. A company that admits limits and fixes problems is safer than one that speaks only in marketing language. Small tools may lack huge support teams, but honest makers usually explain trade-offs plainly.

Users should also avoid perfection traps. No product is permanent. Even excellent tools can be sold, abandoned, or broken by platform changes. The goal is not to predict forever; it is to reduce damage. Keep independent backups, use standard formats, document workflows, and avoid putting all memory in one platform. The safest software relationship is one you can survive leaving.

Good software is easier to spot when users value calm over novelty. A tool that does one job well, stores work clearly, supports export, patches security, and respects attention is already rare enough to matter. That is where the old quality still lives.

Users should also notice whether a product treats offline work as a failure or a normal condition. A respectful app lets people read, write, and recover core data when the network is poor. A captive app turns every outage into helplessness. Offline behavior reveals who really controls the work. Even cloud tools can cache drafts, queue changes, and avoid blocking simple tasks on distant services. Another signal is support language. Human, specific answers suggest a team that understands the product. Vague scripts suggest distance. A vendor’s response to criticism often predicts its future behavior better than its launch page.

Reviews can help, but only if users read them for patterns rather than star averages. Complaints about a removed export, sudden price jump, broken offline mode, or ignored security issue matter more than irritation about a color change. Look for evidence of stewardship. A product with fewer features but better care may be the safer long-term choice. always.

Builders can design for graceful aging

Software builders have more power than they sometimes admit. A product can be designed to age gracefully from the first release. That does not mean freezing it. It means protecting the user’s work, memory, and trust while the code evolves. Graceful aging is a design discipline: stable concepts, documented formats, clear support windows, careful deprecations, recoverable data, and honest change logs.

The first rule is to preserve the user’s mental model. Interfaces can improve, but the core nouns and verbs should remain stable unless there is a serious reason to change them. A writing tool should respect documents, drafts, folders, search, and export. A finance tool should respect accounts, transactions, categories, reports, and auditability. A design tool should respect canvases, layers, assets, and output. Stable concepts let users grow expertise. Without them, every redesign resets skill.

The second rule is to make data portable by default. Use standard formats where possible. Document proprietary formats when necessary. Provide complete export, not a symbolic dump. Include metadata, attachments, comments, history, and relationships where the workflow needs them. Keep old readers for old files. If a product creates a new format, publish migration paths before users ask. The user’s work should outlive the product’s current strategy.

The third rule is to separate care from churn. Security fixes, compatibility updates, and performance work should not be bundled with avoidable interface disruption. Release notes should tell users what changed and why. Deprecations should include dates, alternatives, and migration tools. Enterprise customers may need staged rollout controls, while individuals need plain warnings. The Cyber Resilience Act and secure-development frameworks make support duties more formal, but good builders should treat those duties as craft.

The fourth rule is to limit hidden dependency. If the product needs a cloud service, say what fails offline. If AI features depend on remote models, say what data leaves and what happens if the model changes. If an app relies on a store entitlement, explain the account requirement. If a feature is plan-gated, do not disguise it as a broken button. Honest dependency is less damaging than hidden dependency.

The fifth rule is to budget for removal. Every feature added creates future maintenance. Builders should remove dead flags, prune unused settings, retire experiments cleanly, and resist features that serve pricing more than users. Feature toggles should have owners and expiry dates. Analytics should be limited to questions the team is prepared to act on. AI features should reduce real toil or remain absent. A product that cannot say no cannot age well.

The sixth rule is to design the sunset before the sunset. If the product shuts down, users should have export tools, read-only access where possible, documentation, migration partners, and notice that respects the depth of dependence. A cloud product should know its failure mode. A local product should keep activation from becoming a death switch. End-of-life planning is user respect in advance.

Builders should also test under ordinary constraints: slow devices, weak networks, large files, old accounts, assistive technologies, and messy migrations. A product that works only for clean demos is not durable. Performance budgets, accessibility reviews, and restore drills catch decay before users do. These practices are not glamorous, but they create the feeling people call good software.

The old masters of software craft were not perfect; many had the advantage of smaller scopes and simpler networks. Modern builders have harder conditions but better tools. Graceful aging is the bridge. It lets software improve without making users feel evicted from their own habits.

Builders should define a “trust budget” alongside a performance budget. Every interruption, account requirement, permission request, plan gate, and telemetry event spends trust. Some spending is justified. Too much makes the product feel hostile. Trust is depleted by small cuts, not only by scandals. A team that tracks those cuts can prevent decay before it becomes reputation damage. Good builders also make boring work visible internally. Performance cleanup, accessibility fixes, export repairs, dependency updates, and documentation should count as product achievements. If leadership celebrates only new features, the product will age badly.

The same applies to account systems. If an account is needed only for sync, the local tool should still open when the account service fails. If licensing requires activation, the vendor should prevent activation from becoming a future death switch. A license check should not become historical erasure. Builders can avoid that trap with offline grace periods and archival unlock plans.

The future of good software is exit

The simplest answer to the original question is this: good software went wherever users still have exit. It went into open-source projects, local-first tools, small utilities, professional products with stable contracts, standards-based workflows, and services that let customers leave without losing their work. It faded where exit became expensive: closed clouds, captive stores, proprietary formats, bundled suites, unclear subscriptions, repair locks, and platforms that change the bargain after adoption.

Exit is not the opposite of loyalty. It is the condition that makes loyalty honest. A user who can leave but stays is giving real trust. A user who cannot leave is trapped, even if the product still looks polished. Vendors sometimes fear portability because it reduces lock-in. Better vendors understand that freedom to leave makes staying meaningful. It forces the product to earn renewal through care rather than captivity.

The future of good software will not look exactly like the past. Security obligations will remain. Cloud collaboration will remain. App stores will remain. AI assistance will remain. Regulation will grow. Supply-chain work will matter more, not less. The right goal is not to return to dusty boxes and abandoned installers. The right goal is to recover the user’s practical power inside modern systems: export, repair, portability, stable interfaces, support windows, local copies where possible, and clear contracts.

This requires buyers to reward different things. Businesses should pay for maintenance, not only features. Individuals should support tools that respect data and attention. Regulators should focus on switching, interoperability, repair, and security duties that users can actually exercise. Developers should treat deletion, export, and end-of-life design as first-class features. The market will produce better software when durability is paid for and lock-in is penalized.

It also requires a cultural change inside software companies. Growth is not the only sign of life. A mature product can improve by becoming faster, calmer, safer, and easier to leave. Those achievements may not fill a keynote, but they matter to people who depend on the tool every day. A company that removes friction rather than adding another monetized layer is not lacking ambition. It is practicing respect.

The user’s question carries grief because software became intimate. It holds writing, photographs, businesses, friendships, memories, health data, finances, art, and identity. When tools decay, people feel that part of their own history is being managed by someone else’s dashboard. Software quality is personal because software stores personal work. That is why the loss of old control hurts more than a normal product complaint.

There is still reason for optimism. The industry now has better security frameworks, stronger preservation institutions, more open-source infrastructure, growing regulatory attention, and many makers who understand the problem. Users are also more alert. They ask about export. They notice lock-in. They distrust needless churn. They reward tools that feel calm. Those pressures can change what gets built.

Good software from the past did not disappear into a single grave. It scattered into practices that must be chosen again: local ownership, open formats, measured updates, honest pricing, repair rights, maintainable code, and respectful design. The next era of good software will belong to products that combine modern safety with old dignity. The best tools will not merely add features. They will give users something rarer: confidence that their work remains theirs.

Exit also protects innovation. When users can move, new tools can compete on merit instead of begging incumbents for permission. A small developer can build a better editor, calendar, database, or repair tool if formats and APIs are open enough to make migration possible. Portability is pro-innovation, not merely pro-consumer. It lets the market test whether the old platform still deserves its place. The future will still contain trade-offs. Some systems need central coordination, strong identity, and strict security. But central control should be justified by the job, not assumed as the default.

A good exit culture also changes support. Instead of treating cancellation as failure, the vendor treats it as a final service moment. Clean export, clear deletion, and respectful offboarding leave the door open for return. A graceful goodbye is part of product quality. Companies that understand this will earn reputations that outlast individual contracts.

The most durable products will treat exit as a lifecycle, not a button. They will design onboarding, daily use, billing, support, migration, and shutdown as connected moments. The relationship stays healthier when every stage respects the user’s autonomy. That is the opposite of the trap that made so much modern software feel worse.

Reader questions about durable software

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Cyber Resilience Act
Official European Commission page used for the article’s discussion of cybersecurity duties, products with digital elements, and timely security updates.

SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
NIST publication page used for the article’s treatment of secure software development practices and maintenance obligations.

Secure by Design
CISA resource used for the article’s discussion of vendor responsibility for customer security outcomes.

SLSA
Official Supply-chain Levels for Software Artifacts page used for the article’s explanation of software supply-chain integrity controls.

Nixing the Fix
FTC report page used for repair restrictions, software locks, firmware updates, and ownership analysis.

Exemption to Prohibition on Circumvention of Copyright Protection Systems for Access Control Technologies
Federal Register final rule used for the article’s discussion of DMCA Section 1201 exemptions and repair-related legal limits.

The Digital Markets Act
European Commission DMA page used for gatekeeper power, app-store governance, interoperability, and contestability.

Update on apps distributed in the European Union
Apple developer support page used for alternative app marketplaces, web distribution, and DMA implementation in the European Union.

Data Act
European Commission page used for data access, cloud switching, and portability analysis.

Justice Department Sues Apple for Monopolizing Smartphone Markets
DOJ announcement used for antitrust allegations involving smartphone markets and platform control.

Apple’s mobile platform
UK Competition and Markets Authority case page used for strategic market status analysis of Apple’s mobile platform.

Apple loses challenges against EU rules to curb Big Tech
Reuters report used for the July 2026 court decision involving Apple, iOS, app stores, and Digital Markets Act gatekeeper designation.

A message about Stadia and our long term streaming strategy
Google announcement used for cloud-service shutdown analysis and the distinction between refunds and preservation.

Adobe Flash Player End of Life
Adobe page used for the Flash shutdown timeline, security-patch end, content blocking, and migration context.

Windows 10 support has ended on October 14, 2025
Microsoft support page used for operating-system lifecycle, security updates, and compatibility pressure.

Mission
Software Heritage mission page used for source-code preservation, software fragility, and long-term accessibility.

Digital Preservation at the Library of Congress
Library of Congress page used for preservation workflows, storage monitoring, file formats, and metadata.

MS-DOS Emulation
Internet Archive help page used for browser-based emulation and software preservation examples.

Open Source Usage Trends and Security Challenges Revealed in New Study
OpenSSF release used for Census III findings on open-source usage, production libraries, and security visibility.

Census III of Free and Open Source Software
Linux Foundation research page used for open-source dependency and package-ecosystem context.

Octoverse 2025
GitHub report used for repository growth, AI-related repository adoption, and current developer ecosystem scale.

App Review Guidelines
Apple guideline page used for app-store review, update expectations, and removal rules.

App Store Improvements
Apple support page used for the process of evaluating and removing outdated or nonfunctional apps.

Microsoft 2025 Annual Report
Microsoft annual report used for revenue context and the economic scale of cloud software.

Salesforce Announces Fourth Quarter and Fiscal Year 2025 Results
Salesforce investor release used for subscription and support revenue context in enterprise software.

Salesforce Delivers Record Fourth Quarter Fiscal 2026 Results
Salesforce investor release used for updated enterprise software revenue context.

Pluralistic: Tiktok’s enshittification
Cory Doctorow’s post used for the article’s explanation of platform decay and value extraction after user adoption.

2023 Word of the Year Is “Enshittification”
American Dialect Society page used for public recognition of the term “enshittification.”

What Is an App Store? The Software Engineering Perspective
Research paper used for the argument that app stores are software-engineering stakeholders, not merely distribution shelves.

Trimming Mobile Applications for Bandwidth-Challenged Networks in Developing Regions
Research paper used for mobile app size growth, resource bloat, and bandwidth-related access issues.

Pricing4SaaS: Towards a pricing model to drive the operation of SaaS
Research paper used for SaaS pricing structures and pricing-driven variability management.

HORIZON: a Classification and Comparison Framework for Pricing-driven Feature Toggling
Research paper used for subscription-based feature access and pricing-driven feature toggling.

Pricing4SaaS: a suite of software libraries for pricing-driven feature toggling
Research paper used for implementation context around pricing-controlled feature toggles.

The Role of User Reviews in App Updates
Research paper used for app-review and release-note analysis in the discussion of metric pressure.

Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories
Research paper used for the article’s balanced discussion of AI-generated code, vulnerabilities, and review duties.

Federal Trade Commission Announces Final “Click-to-Cancel” Rule Making It Easier for Consumers to End Recurring Subscriptions and Memberships
FTC announcement used for the subscription-cancellation discussion and public-comment context.

Rule Concerning the Use of Prenotification Negative Option Plans
Federal Register page used for current negative-option disclosure and cancellation context after the click-to-cancel rule was vacated.