Open-source security is not a solo activity

Over time, many open-source maintainers face the same problem: they lack the time to do all of the work that their project needs, and no one else is stepping up to provide adequate help. Maintainers, though, are often reluctant to throw in the towel. The result is suboptimal all around; the maintainer is stressed out, project quality suffers, and users face security risks that they may not be fully aware of. At the 2026 Open Source Summit North America, Robin Bender Ginn spoke about this problem, when it might be time for maintainers to pass the torch, and the responsibilities of users.

Ginn is the executive director of the OpenJS Foundation, which promotes adoption and development of JavaScript technologies. As a result, her talk was in large part focused on maintainers of JavaScript-related projects. She began with the scale of that ecosystem; more than 98% of web sites include JavaScript code, she said, and there were more than two billion downloads of Node.js in the last year.

That scale means that there is a lot of pressure on maintainers. They may see the use of their projects grow from thousands of users to millions of users to "oh my gosh, I'm like maintaining global infrastructure". When that happens, burnout can follow. That leads to the question, Ginn said, "when does continuing to maintain that project increase the [security] risk instead of reduce it?" It might be more harmful than helpful to continue to maintain a project.

Signals of decline

There are two types of signals to look for when it comes to the security of open-source projects, she said: technical and human. The technical signals include things like CVEs taking longer to be fixed, the release cadence slips, or the continuous-integration (CI) pipeline breaks without any response. The human signals, Ginn said, may be harder to see; a maintainer may stop replying, pull requests go unreviewed, or the tone shifts in some of the reviews. "People get a little grumpy." From the outside, it might appear that maintainers are simply disengaged. From the inside, "it's often like a sign of survival because, you know, human capacity is finite".

If a package has not been patched or hasn't received commits in 12 months, for example, "that is a good indication you should migrate now". If a project has a single maintainer, no governance documentation, and no SECURITY.md file stating its security policy, "you may want to engage and sponsor" it, she suggested. If a project has a single maintainer, "particularly in the JavaScript world", it doesn't mean the project isn't healthy. But it is a good idea to support those folks, she said.

Many of the libraries that are relied upon today, she said, exist because JavaScript was missing important features such as async/await and standardized browser APIs. It is possible to deprecate some of those libraries because the platform has caught up, Ginn said. For example, Ecma International's TC39 committee on ECMAScript (JavaScript) standards work has brought a number of features to the language specification. Having features built into JavaScript, rather than implemented as separate libraries that are pulled in as dependencies, means a smaller attack surface, she said. Native implementations tend to be patched more quickly, and there is less polyfill code.

Investment, not heroics

Next, Ginn moved to talking about the importance of funding security work for open-source projects. It is difficult to find security folks to work on projects, and security improvements do not come from heroics: "They come from structure and they come from funding."

As an example, she was surprised to find that the Node.js project did not have a security working group four years ago. It became the first project to receive funding from Alpha-Omega, and also received money from the German government through the Sovereign Tech Agency to provide budget for dedicated security engineering. The result is that Node.js now has "a dedicated security group that's thriving". The project has a threat model, predictable CVE processes, secure defaults, and a clear end-of-life process for releases. "They went from 26 steps for a security release to, like, one or two". Nothing about the code changed, Ginn said, but it reduced stress on the maintainers.

Ginn said that end users also have a responsibility in keeping a project healthy. "When you depend on a healthy project like Node, your role isn't just to consume it, it's to help sustain it." She encouraged people to ensure that they are staying current with releases to help prevent vulnerabilities, and to keep up-to-date with news from the projects such as the fact that Node.js is changing its release schedule. Ginn also asked for responsible disclosure through official security channels, rather than reporting security vulnerabilities in public tickets.

"Healthy projects do not stay healthy by accident", she said, and called for people to participate in security working groups and help fund projects and maintainers they depend on.

Reducing scope

Another path to better security is reducing the scope of a project. Ginn brought up the jQuery JavaScript library; she said that about 78% of the top one million web sites use jQuery, and that its content-delivery network serves 78 billion requests per month.

Its popularity is due to the fact that it solved many problems that, early on, JavaScript did not. Since then, the jQuery maintainers decided to start deprecating parts of the project that had been replicated in the JavaScript platform. For example, the maintainers deprecated the jQuery Mobile project in 2021.

From the outside, Ginn said, deprecation may look like abandonment—but it is not. "Many times it's just the maintainers doing the responsible thing. It's making the project smaller, safer, and more sustainable." How the larger ecosystem reacts to deprecation matters, she said. Healthy communities follow maintainers' communications, including their blogs, social-media presence, and so forth. She advised that those using open-source projects "contribute before complaining", such as by helping with documentation, or assisting with migration.

Stability through governance

Sometimes a project does not need to reduce scope, it just needs better structure. Ginn used the Express project as an example. It is a web framework for Node.js that has more than 52 billion downloads per year. It was managed by two maintainers, until one stopped and the other became overburdened. The pressure became overwhelming, she said, and updates stopped.

Eventually, in 2024, the community stepped up to provide a plan called Express Forward to move the project out of maintenance mode and replace the single-maintainer model. It started with the "boring" work of release automation, cleaning up the issue tracker, and so forth.

Another project, the Lodash utility library for JavaScript, also had a single maintainer. John-David Dalton had a long streak of committing code every day for years, until he had "a really difficult period in his life" that caused a lot of stress and led to burnout. "This is, again, what he does in his free time, not his full-time job." This is an uncomfortable truth about open-source software, she said, "one person's life events can slow down [development of] software used by millions of applications" and create a supply-chain risk.

Ultimately, the OpenJS Foundation stepped in to help, and the project received funding from the Sovereign Tech Agency. The community formed a technical committee and worked to simplify the project. "They treated it as feature complete and focused on making it sustainable." That included deprecating APIs that now had native JavaScript equivalents, reducing support for obsolete runtimes, and making the library smaller.

Ginn noted that a single maintainer burning out can affect millions of applications. The responsibility for security updates falls on too few people. When someone burns out the question becomes who can realistically carry the responsibility of a project moving forward?

She talked a bit about the Linux Foundation's LFX Insights project, which analyzes open-source projects and attempts to measure the health of their communities. "So now your security teams can also look at the code, and then they can look at the community health".

Security incidents show how fragile the ecosystem is, she said. Ginn pointed to the Leftpad incident, Log4j vulnerability, and phishing attacks that are plaguing the npm ecosystem that is used to deploy packaged software for Node.js. These are not just coding problems, they are sustainability problems:

In open source, we like to celebrate the hero maintainer, the person who keeps that project alive forever and forever and forever. But, you know, the expectation of maintaining it forever is actually a security risk because deprecation actually isn't abandonment. Sustainable ecosystems require funding, governance, shared responsibility, and a lot of help from friends in the community. So letting go, when done responsibly with notice, migration paths, [and] community support, we don't consider it failure. We consider it leadership because the most secure projects are the ones that know when to merge, when to maintain, and when to move on.

It should not all fall on the shoulders of maintainers, though. Governments are relying more on open-source projects, she said, and she hoped that more of them would follow Germany's lead in funding projects. Companies that rely on open source should be assigning people to work on it; she named a few companies, such as Bloomberg, Netflix, and Target that are dedicating people's time to work on open source. "We recommend that you take an audit of the top 20 open-source projects you may use and just pick one and engage" by helping to review bugs, triage security issues, or test pull requests. "Anything that we can do to help those maintainers would be amazing".

Questions

Ginn had a bit of time left for questions; the first attendee who spoke up wanted to know about the effects of agentic AI on projects, and the flood of pull requests that it was enabling. How was that going to affect things? Was it going to improve things or burn more people out?

"All of the above", Ginn said. Right now it is super painful. The Node.js project had just instituted a policy that any pull request should be less than 5,000 lines of code, and large pull requests must be done by a core contributor. "So hopefully that will mitigate it some". Alpha-Omega had funded a new security engineer for the foundation, but that had barely made a dent in what they were facing, she said.

Another attendee wondered if a community forks a deprecated project, does the original developer have a responsibility to help with it, or is it solely up to the new maintainers? Ginn said that it was the latter and mentioned that some companies are forking projects and then selling support as a business model.

Ginn's talk provided some interesting case studies in stabilizing important open-source projects. Of course, the presence of a foundation and help finding funding were key ingredients in the success of those efforts. Those are, unfortunately, resources that are not readily available to many maintainers outside of ecosystems with support infrastructure, like that of the OpenJS Foundation.

[Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Minneapolis to attend the Open Source Summit.]