Open Source Projects Don't Fail Due to Code, They Erode From Within

Open source projects rarely collapse in one dramatic moment; instead, they erode quietly. You notice it when releases stall, when issues pile up with no replies, and when the same two names consistently appear in every commit log. This is precisely what happened with Express and Lodash – two of the world's most used JavaScript projects and long-standing pillars of the Node.js ecosystem. For a period, both were far closer to irrelevance or accidental self-destruction than most people realize.

This article expands upon my talk, What Comes After Chaos? Lessons from Reviving Express and reimagining Lodash. If you prefer video, you can watch it here.

Express and Lodash have profoundly impacted the modern web, appearing directly or indirectly in millions of Node.js applications and production websites. Their ubiquity, rather than trending popularity, made them indispensable. Express silently powers millions of servers, spanning dozens of repositories and billions of yearly downloads. Lodash resides within production applications, build tools, and frameworks, boasting billions of weekly installs and dependencies. This isn't just a "popular project"; this is infrastructure.

Yet, scale does not protect against decay; sometimes, it accelerates it.

When the Backbone Starts Cracking

Before its turnaround, Express exhibited all the symptoms of a project that had outgrown its own structure. Deep architectural decisions from the early Node.js era became performance and maintenance liabilities. Issues included monkey patching, compatibility with Node.js versions that should no longer be in use, and a test suite too unstable to be trusted by Node's own integration systems. Express 5 had been "almost ready" for nearly a decade. Meanwhile, the effective bus factor hovered around one, governance was informal at best, and the backlog of issues and pull requests relentlessly grew.

Lodash faced a different challenge. The project carried an extraordinary burden for years, and the problem was never a lack of commitment, but the inadequate structure surrounding it. Compounding this, hundreds of variant packages and a fragmented CI system made progress harder and riskier than desirable. The community was clamoring for Lodash 5, while the project was struggling just to sustain Lodash 4 without collapsing under its operational weight.

This often marks the point where idealized views of open source confront harsh reality. At this scale, burnout isn't theoretical; it becomes visible and measurable in contribution patterns, response times, and maintainer availability. It was evident in contribution graphs, response times, and the fact that two contributors carried more than half of Express's maintenance for years. It was also reflected in broader studies showing how close most maintainers are to walking away.

Crucially, the problem wasn't merely that things were broken, but that no one had a sustainable way to fix them.

Chaos Is Organizational Before It Is Technical

People often assume software collapses due to code issues. It doesn't. Code can be rewritten. Systems collapse when they lack the surrounding structure to make decisions, handle conflict, and distribute power.

The first real change in Express wasn't a commit; it was governance. This meant establishing a proper Technical Committee, defining roles like repository captains and committers, implementing transparent processes, and forming working groups with real responsibility instead of vague goodwill. Security was treated as a systemic concern, not a checklist: threat modeling, external audits, incident response playbooks, and a dedicated triage team were implemented. Releases were no longer wishful thinking; they were scheduled, maintained, and communicated.

These changes were critical because they rebuilt something more important than code: trust. This trust extended not just to users, but to contributors, companies, and the wider ecosystem. Express was reintegrated into Node.js infrastructure testing, achieved Impact Project status under the OpenJS Foundation, and finally shipped Express 5 with a clear roadmap beyond it.

Lodash is following a similar path, albeit with its own constraints and culture. It's transitioning from a Benevolent Dictator for Life (BDFL) model to a Technical Steering Committee, deprecating large parts of its variation ecosystem to regain control over complexity, and rebuilding its CI system so releases are no longer heroic efforts. The focus has shifted to stability, security, and progressive modernization, rather than prioritizing new features.

This work is slower, less visible, and less exciting on social media. But this is what transformation looks like in mature infrastructure.

Not Everything That Looks Like Drama Is One

When projects as significant as Express or Lodash make changes, the internet often frames it as a crisis or scandal. This manifests as spam PR incidents, blog posts asking "Is this project dead?", and threads about abandoning libraries for "lighter" alternatives. Most of this noise misses the point. Mature ecosystems will always generate friction because they have gravity. However, not every moment of tension is a failure; sometimes, it's simply the cost of moving from informal to intentional.

What truly matters is not whether conflict exists, but whether the project has the structures in place to handle it without burning people out.

What Actually Survives After Chaos

Express today is more than just a framework; it's an organization. Lodash is no longer merely a utility library; it's a project learning how to scale its governance as much as its code. The invisible work behind this shift is often overlooked: mentoring new maintainers, distributing decision-making, documenting processes, creating safe spaces for disagreement, and ensuring security and sustainability are treated as first-class concerns, not afterthoughts.

Open source doesn't survive on pull requests alone. It thrives on structure, shared ownership, and the uncomfortable decision to stop being heroic and start being boring.

And that is what comes after chaos. Not perfection. Not a happy ending. Just transformation – slow, deliberate, sometimes frustrating, and absolutely necessary. If you have ever typed npm install express or npm install lodash, you have already been part of that story, whether you knew it or not.

It's also worth stating the uncomfortable truth: this wasn't fixed because a magic pile of money suddenly appeared. Support does matter, and initiatives like the Sovereign Tech Fund have made a real difference in making this work possible. However, funding alone does not solve structural problems. In most cases, the resources are still insufficient. Structure, governance, and shared ownership carried more weight than any budget ever did. Even when projects are "rescued" and celebrated, their long-term sustainability remains fragile. Recovery is a phase, not a conclusion; it requires constant maintenance.

What Comes After Chaos… it’s just transformation.