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. 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 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.
- Contribute when possible. Even small contributions help keep maintainers afloat.
- 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.