The challenge of continuity in open-source development

It’s all in the name.

A “maintainer” leads and supports an open-source project with necessary maintenance like code reviews. They also maintain in the continuity sense: They’re the steady presence handling feedback from a community of users.

But like your fantasy-football commissioner who disappeared after no one paid their dues, sometimes maintainers are ready to step away from a project.

And some succession plans are better than others. Open-source software security company Sonatype’s 2026 “State of the Software Supply Chain” report found that up to 15% of open-source components in enterprise dependencies are end-of-life (EOL), or abandoned without anyone ready to patch vulnerabilities as they arise. That means “permanent exposure,” Sonatype wrote, and “organizations inherit flaws that cannot be remediated upstream.”

Additionally, many open-source packages are maintained by just one person, as Josh Bressers, VP of security at software composition analysis company Anchore, explored in an August 2025 post.

We spoke with open-source maintainers about continuity pressures, the consequences of an uncontinued project, and what resources are available to help.

Pressure point 1: A growing community. Martin Woodward, VP of developer relations at code mega-platform GitHub, has experienced the “flattering” highs of working on an open-source project that unexpectedly catches fire with users. An early email-testing library, he told us, became the “first kind of project that people actually relied on.”

That popularity can quickly turn to pressure, as a growing user base expresses their needs and wants with a creator who only has so many hours in a day. A consumer accustomed to downloading software for free, for example, might “have expectations around support and serviceability that are probably not aligned with your ability to provide support,” he said.

Maintainers, Woodward told us, are constantly encouraging people and growing their skills “hoping some small percentage of them will stick around, and that they can potentially take on the project.” (Somebody eventually took over the email library, he told us, “which was fantastic.”)

Meanwhile, the open-source community continues to grow. A 2026 global survey conducted by enterprise open-source support company OpenLogic revealed that 98% of 712 global respondents (individuals working with open-source in their orgs) “either increased or maintained their use of open-source software in the past year.” (They cited driving factors like vendor lock-in and costs.)

That user growth can lead to stress among the maintainers. Maintainers often take on their open-source efforts in addition to their regular full-time jobs. A November 2024 report from software security company Tidelift, which polled over 400 open-source maintainers, found that 6 out of 10 respondents considered themselves “unpaid hobbyists.” (And over a third considered quitting.)

Pressure point 2: A growing codebase. Linux Foundation fellow and Linux maintainer Greg Kroah-Hartman handles bug reports regularly—and a lot more of them lately, thanks to AI.

“You do your best work ever possible because it’s all public,” Kroah-Hartman said. “That’s my name. You can’t hide behind it, so you feel responsible for it.”

Tech support. Open-source projects like the Linux Foundation, Python, Kubernetes, and GitHub host a variety of events, workshops, and community-building efforts.

GitHub’s maintainer support includes:

• Dedicated funds. GitHub Sponsors, for example, allows you to “see your top dependencies” and pay contributors.
• Successors. This capability enables ownership continuity.
• Security tooling. GitHub’s Security Lab provides automated vulnerability detection.
• Networking. A Maintainer Community hub allows the sharing of best practices.

But set expectations. The very definition of open source—that it’s released in the public domain—means the code, by its very nature, is let go, according to Dan Lorenc, CEO of open-source security company Chainguard.

“Open source can’t be abandoned. It’s abandoned the minute you slap that license on it and make a release,” Lorenc said. Lorenc has maintained many open-source projects—in a formal capacity on popular, well-staffed tools like Minikube and the Google-developed Skaffold, and less formally at home on the weekends. (He also supported an “EmeritOSS” effort to assist with abandoned codebases.)

Sometimes Lorenc will revisit a “weekend” project and be surprised to find someone filing a bug report, or sharing that they’re using it at a bank, he said.

“'I’m like, ‘Whoa, whoa, whoa. I never told you to do that. I haven’t even looked at this code, but all right, let me try to help you out,’” he said.

Lorenc recommended being very clear about expectations of support. “You don’t owe them anything, unless you wrote some blog saying you’re going to be maintaining this thing forever and everyone should start using it,” Lorenc told us.

Community building. May is also Maintainer Month at GitHub, where the company hosts closed-door sessions with software pros to discuss their burdensome challenges and offer assistance and resources.

“You feel that there are people out there who understand you and support you, and life becomes a lot easier,” Woodward said. “It’s about building the community around you.”

Woodward added he’s rarely surprised when someone in these discussions reveals that they’re also a volunteer in their community or their church. That defines a maintainer as well: “They’re the type of people that put their hands up and do stuff.”