TL;DR - Open-source dependencies are infrastructure, not magic. Maintainer burnout isn’t bad luck-it’s structural, and it’s the root cause behind most abandonment. Maintainers get acquired (Bun → Anthropic), pivot (Radix), or lose control under funding pressure (RubyGems), and successful forks are rare. Treat every dependency as if it has an expiration date: audit them, mirror what’s critical, help fund what you rely on, and plan for abandonment.
Developers love shortcuts. We grab a library, wire it into production, and move on. Reinventing the wheel feels pointless-until the author disappears and the wheel falls off.
Open-source maintenance is fragile by nature - a reminder that, like all code, dependencies have a short shelf life. Maintainers burn out, change jobs, shift priorities, or simply lose interest. I’ve watched this happen across teams and companies for years. A project can be downloaded millions of times and still be one GitHub issue away from abandonment.
Here are some standout examples:
- Lucia Auth - wildly popular, widely adopted, and then suddenly deprecated when its creator-just one university student from Japan-decided to step away. Many teams unknowingly anchored their authentication system to a solo maintainer.
- core-js - one of the most downloaded packages in the entire ecosystem. In 2020, its author was convicted in connection with a tragic motorcycle accident, resulting in jail time. With maintenance disrupted, the internet kept installing it anyway because… what else were we going to do?
Open source is theoretically resilient because anyone can fork a project. In practice, successful forks are extremely rare. Without a foundation, corporate backing, or a dedicated community, most forks flame out quickly. MariaDB is one of the few long-term success stories-and it survived only because it had a company and ecosystem behind it.
This is why companies get nervous. Some organizations outright refuse to rely on unmaintained OSS for core systems. They’d rather pay for something boring and stable than hope a stranger on GitHub keeps a critical dependency alive. It’s not paranoia-it’s risk management.
The Anthropic → Bun Acquisition
Anthropic buying Bun is the perfect modern case study. They didn’t spend millions because they love JavaScript runtimes. They did it because basing their infrastructure on a small independent team was a gamble. If anything happened to Bun’s maintainers, Anthropic’s stack would be exposed.
So they solved the uncertainty the corporate way: they bought the project.
This is “don’t rely on a single maintainer” at enterprise scale.
The Radix Team Pivot
Another interesting example is the Radix UI team shifting into a new company almost overnight. The library still exists, but the roadmap instantly became fuzzier. When the people behind a project move on-even if they’re not solo maintainers-the ecosystem feels the tremor.
Developers often underestimate this: it’s not only lone creators who walk away. Entire teams-backed by funding-can pivot and leave a project directionless.
The RubyGems Takeover
If acquisition and pivots are two ways a project slips out from under you, funding pressure is a third-and it’s the one people assume is the solution. In 2025, the RubyGems takeover saw maintainers lose control of a project they had stewarded for years after pressure from a funding source shifted its priorities.
It’s a useful counterpoint to “just pay maintainers.” Money keeps the lights on, but the wrong model of money can be its own kind of abandonment: the project survives on paper while the people who built it get pushed out. The healthiest funding is decentralized-no single sponsor holding the roadmap hostage.
Why Maintainers Walk Away
When we ask “is this package still maintained?” we treat abandonment as bad luck-a maintainer who happened to lose interest. But a 2025 report on burnout in open source makes the case that it’s structural and predictable. The numbers are grim: 73% of developers have experienced burnout at some point, 60% of maintainers have considered leaving open source, and 60% receive no payment for their work at all. Meanwhile 96% of companies depend on the code they’re producing for free.
Here’s the uncomfortable part. That question in the title-the reasonable, responsible thing a good engineer asks before adding a dependency-is, from the other side of the repo, one of the exact straws that breaks people. One maintainer described why he quit:
“enough issue follow-ups, like, ‘is this maintained?’, ‘are you gonna fix my issue?’, I had to say that I had to give it up.”
Toxic behavior isn’t rare, either. In one study, two-thirds of non-technical emails on the Linux kernel mailing list were uncivil, and the most common patterns were insults, entitlement, and demandingness. This creates a death spiral: rude users burn out the maintainer, the maintainer gets curter, issues take longer to resolve, and the burnout deepens until the project quietly dies.
AI is pouring fuel on this. Maintainers now report a flood of low-quality “slop” pull requests-contributors save time by generating code with an LLM, and that time gets transferred to the maintainer at the review stage, where reading machine-written code was described as “mind-numbing.” As curl’s Daniel Stenberg put it, “We need to reduce the amount of sand in the machine.” The dependency you’re evaluating today may be maintained by one exhausted person losing a race against their own issue tracker.
The Takeaway
Open source isn’t guaranteed. It’s powerful, liberating, and insanely productive-but it’s not immortal. If you depend on it, treat it like infrastructure, not magic.
A few practical rules:
- Audit your dependencies. Don’t blindly trust transitive installs.
- Mirror what matters. You should be able to build critical systems even if npm disappears tomorrow.
- Expect churn. Your favorite library might not be your favorite next year.
- Fund, don’t just contribute. Small PRs help, but the structural fix is reliable payment. A burned-out maintainer is a supply-chain risk you can actually help retire.
- Plan for abandonment. Assume every dependency has an expiration date.
Open source is one of the greatest forces in software. But its longevity depends on people-and people move on. Building with that reality in mind is how teams stay resilient.
FAQ
How do I know if an npm package is still maintained?
Check the date of the last release and the last commit, the ratio of open to closed issues, whether recent issues get responses, how many active maintainers there are, and whether the project has corporate or foundation backing. A single-maintainer package with stale activity is a risk, no matter how many downloads it has.
What should I do if a dependency is abandoned?
Audit how deeply it’s embedded in your codebase, look for an actively maintained fork or alternative, vendor or mirror the code if it’s critical, and budget time to migrate. Assume abandonment is possible before it happens rather than scrambling after.