One Maintainer, 10,000 Dependencies: What Happens When They Quit?

The Challenge

Your compliance team just finished mapping your organization's software dependencies. The audit revealed something uncomfortable: seventeen of your critical libraries are maintained by single individuals. Three of those maintainers haven't committed code in six months.

This isn't a hypothetical scenario. Researchers recently screened close to four thousand unique papers on open-source sustainability and found that a few volunteers often keep critical components like OpenSSL, curl, and log4j running. The same research sorted open-source software into fourteen sub-genres based on governance, funding, and origin. They discovered that the structure of an open-source project predicts its sustainability risk better than stars, forks, or commit frequency.

For compliance teams, this creates a concrete problem. You're responsible for ensuring software supply chain integrity under frameworks like NIST CSF v2.0 and ISO 27001. But how do you assess risk when the "vendor" is an anonymous developer who maintains your authentication library between their day job and parenting duties?

The Environment and Constraints

Most organizations track open-source dependencies through automated scanning tools. You get a bill of materials, vulnerability counts, and license compliance flags. What you don't get: governance structure, maintainer count, or funding stability.

This gap matters because different open-source models carry different risks. A community-driven project like Debian operates under collective governance with distributed decision-making. A single-maintainer project operates under one person's availability, expertise, and willingness to continue. When Nadia Eghbal's foundational report on open-source sustainability identified the underproduction problem, she wasn't describing a technical issue. She was describing a structural one.

Your constraints as a compliance team:

• You can't eliminate open-source dependencies; your engineering team relies on them.
• You can't dictate which projects maintainers should work on.
• You can measure license compliance and known vulnerabilities, but sustainability risk requires different metrics.
• Most procurement and vendor risk frameworks assume commercial relationships with SLAs.

The Approach Taken

Organizations addressing this challenge started by reframing the question. Instead of "Is this dependency secure?" they asked "What happens if this dependency disappears tomorrow?"

The typology research provides a practical framework. Projects fall into categories based on three factors: origin (individual, company, or community), funding model (volunteer, sponsored, or commercial), and governance structure (single maintainer, small team, or distributed community).

Here's what compliance teams can actually measure:

Maintainer depth: Count active contributors with commit access. A project with one maintainer who handles 95% of commits carries different risk than a project with five maintainers who each handle 20%. You can pull this from GitHub's contributor graphs or GitLab's analytics.

Governance documentation: Does the project have a documented decision-making process? Community-driven projects typically publish governance models. Single-maintainer projects often don't, which isn't a failure but signals structural risk.

Funding transparency: Is the maintainer sponsored? Does a foundation back the project? Commercial backing doesn't guarantee sustainability, but it changes the risk profile. A maintainer with corporate sponsorship has different incentives than a volunteer working nights and weekends.

Response patterns: Track issue resolution time and security patch cadence over twelve months. A single maintainer who consistently patches critical vulnerabilities within 48 hours demonstrates reliability. A team that takes three weeks to acknowledge security reports demonstrates risk, regardless of team size.

Some teams built internal scorecards. For each critical dependency, they assigned risk levels:

• High risk: Single maintainer, no documented succession plan, volunteer-only.
• Medium risk: Small team (2-4 people), some sponsorship, informal governance.
• Low risk: Distributed governance, foundation backing, documented processes.

This isn't about avoiding high-risk dependencies. It's about knowing which ones require mitigation.

Results and Metrics

Organizations that implemented dependency governance tracking found they could answer questions their auditors were starting to ask. When your SOC 2 Type II audit asks about software supply chain controls, you can point to documented risk assessment processes that go beyond CVE scanning.

The practical outcomes:

• Identification of single points of failure in your stack.
• Ability to prioritize which projects deserve financial sponsorship.
• Data to support engineering decisions about when to fork or replace dependencies.
• Documentation that satisfies supply chain security requirements in NIST CSF v2.0 (specifically the Identify and Govern functions).

Teams also discovered that high-risk dependencies weren't always the ones they expected. A logging library maintained by one person might be more stable than a framework maintained by a company that's pivoting its business model.

What They Would Do Differently

The main lesson: start this assessment before you need it. Waiting until a critical maintainer announces they're stepping down gives you no time to evaluate alternatives or contribute resources.

Teams also learned that automated tooling helps but doesn't solve the problem. You can't scan a repository and automatically determine governance quality. Someone needs to read the CONTRIBUTING.md file, check the project's decision-making history, and understand the maintainer dynamics.

Another insight: contributing financially to critical dependencies isn't charity. It's risk management. If your organization depends on a library maintained by one person, sponsoring that maintainer's work is cheaper than the incident response costs when they disappear.

Takeaways for Your Team

Build a dependency governance matrix for your critical libraries. Track:

1. Number of active maintainers (not just contributors).
2. Governance model (documented or informal).
3. Funding source (volunteer, sponsored, commercial).
4. Security response time over the past year.

For high-risk dependencies, document your mitigation strategy:

• Have you identified alternative libraries?
• Can you contribute resources to improve project sustainability?
• Do you have the expertise to fork and maintain if necessary?

Update your vendor risk assessment process to include open-source projects. The fact that you're not paying for a license doesn't mean you have no relationship with the "vendor." You're depending on their work. Treat that dependency with the same rigor you'd apply to a commercial software provider.

Finally, recognize that this fourteen-category typology isn't academic taxonomy. It's a practical tool for predicting which projects will still exist in three years. Your compliance framework should account for that.

OpenSSL curl