The Tools That Disappeared in 2025

Every year takes a few tools with it. The 2025 list was longer than most. The vendors, the projects, the open source tools the working developer depended on, the ones that did not survive the acquisition, the funding cut, the…

A single empty tool hook on a dark wood workshop wall, dim warm amber side light, deep navy shadows, no people visible.

Every year takes a few tools with it. The 2025 list was longer than most. The vendors, the projects, the open source tools the working developer depended on, the ones that did not survive the acquisition, the funding cut, the maintainer burnout, the shutdown notice that landed in the inbox the developer did not want to open. The honest framing matters here, because the tool the developer has been using for ten years does not get a funeral. The tool gets a deprecated notice, a migration guide nobody wrote, a quiet exit that the working developer discovers three months too late.

What follows runs as the working version of the obituary. The shorter version is what the developer actually has time to read.

What disappeared and why

Three categories, in roughly that order of how much each one hurt. The first runs as the acquired and absorbed, where the small vendor that had the niche tool got bought by the large vendor that wanted the customer list, the product got absorbed into the larger product, the workflow the developer had built around the small tool broke in the integration. The second runs as the funding cut, where the open source project that depended on the company sponsorship lost the sponsorship when the company ran out of runway, the project that had three maintainers working full time ended up with one maintainer working part time, the project that depended on the maintainer ended up depending on the maintainer’s free time. The third runs as the maintainer burnout, where the project that the single maintainer had been carrying for a decade ended when the maintainer burned out, the project that the industry depended on ended with the maintainer’s blog post, the burnout that the industry could have prevented if the industry had funded the maintenance.

What replaced them

Three patterns, in roughly that order of how much each one worked. The first runs as the direct successor, where the new project picked up the user base, the documentation, the maintainer, the new project that the user migrated to with the migration script the user could run. The second runs as the adjacent tool, where the tool the developer was already using picked up the feature, the developer did not need a new tool because the tool the developer had added the capability, the adjacent tool that absorbed the workflow without forcing the migration. The third runs as the role elimination, where the workflow the old tool supported ended because the workflow itself became obsolete, the developer did not replace the tool because the developer did not need to do the work anymore.

What the list teaches

Three lessons, in roughly that order of how much each one matters. The first runs as the bus factor, where the project that depended on the single maintainer ended when the single maintainer ended, the bus factor that the contributor agreement never addressed, the bus factor that the working developer should check before the working developer depends on the tool. The second runs as the vendor lock in, where the tool the developer chose because the tool was the best at the time turned into the tool the developer could not leave because the tool got acquired, the lock in the open source license was supposed to prevent, the lock in the developer discovered when the developer tried to migrate. The third runs as the maintenance funding, where the open source project that the developer uses every day sits funded by the maintainer’s free time, the funding the developer can contribute to, the funding the developer should contribute to before the next maintainer burns out. The developer who checks the bus factor, avoids the vendor lock in, and funds the maintenance serves as the developer who survives the next round of disappearances.

Abstract disappeared tools as glowing cyan fading outlines on a dark navy surface, dramatic chiaroscuro lighting from above.
Tools that disappeared in 2025: 3 categories the loss came from, 3 replacements the developer adopted, 3 lessons the working developer took from the list.

The bottom line

The tools that disappeared in 2025 sat as the reminder that the working developer’s stack sits on foundations the working developer did not build. The bus factor, the vendor lock in, the maintenance funding, those three are the levers the developer actually controls. The developer who pulls the three serves as the developer who survives the 2026 list, which is already being written.

Sources & Further Reading

All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.

Spotted an error? Email the editor. Corrections are issued with a visible correction note.

Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.

Continue reading