Skip to main content
Tag

OpenJS Foundation

Open Infrastructure is Not Free: A Joint Statement on Sustainable Stewardship

By Blog

An Open Letter from the Stewards of Public Open Source Infrastructure

Over the past two decades, open source has revolutionized the way software is developed. Every modern application, whether written in Java, JavaScript, Python, Rust, PHP, or beyond, depends on public package registries like Maven Central, PyPI, crates.io, Packagist and open-vsx to retrieve, share, and validate dependencies. These registries have become foundational digital infrastructure – not just for open source, but for the global software supply chain.

Beyond package registries, open source projects also rely on essential systems for building, testing, analyzing, deploying, and distributing software. These also include content delivery networks (CDNs) that offer global reach and performance at scale, along with donated (usually cloud) computing power and storage to support them.

And yet, for all their importance, most of these systems operate under a dangerously fragile premise: They are often maintained, operated, and funded in ways that rely on goodwill, rather than mechanisms that align responsibility with usage.

Despite serving billions (perhaps even trillions) of downloads each month (largely driven by commercial-scale consumption), many of these services are funded by a small group of benefactors. Sometimes they are supported by commercial vendors, such as Sonatype (Maven Central), GitHub (npm) or Microsoft (NuGet). At other times, they are supported by nonprofit foundations that rely on grants, donations, and sponsorships to cover their maintenance, operation, and staffing.

Regardless of the operating model, the pattern remains the same: a small number of organizations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users, including commercial entities that generate demand and extract economic value, consume these services without contributing to their sustainability

Modern Expectations, Real Infrastructure

Not long ago, maintaining an open source project meant uploading a tarball from your local machine to a website. Today, expectations are very different:

  • Dependency resolution and distribution must be fast, reliable, and global.
  • Publishing must be verifiable, signed, and immutable.
  • Continuous integration (CI) pipelines expect deterministic builds with zero downtime.
  • Security tooling expects an immediate response from public registries.
  • Governments and enterprises demand continuous monitoring, traceability, and auditability of systems.
  • New regulatory requirements, such as the EU Cyber Resilience Act (CRA), are further increasing compliance obligations and documentation demands, adding overhead for already resource-constrained ecosystems.
  • Infrastructure must be responsive to other types of attacks, such as spam and increased supply chain attacks involving malicious components that need to be removed.

These expectations come with real costs in developer time, bandwidth, computing power, storage, CDN distribution, operational, and emergency response support. Yet, across ecosystems, most organizations that benefit from these services do not contribute financially, leaving a small group of stewards to carry the burden.

Automated CI systems, large-scale dependency scanners, and ephemeral container builds, which are often operated by companies, place enormous strain on infrastructure. These commercial-scale workloads often run without caching, throttling, or even awareness of the strain they impose. The rise of Generative and Agentic AI is driving a further explosion of machine-driven, often wasteful automated usage, compounding the existing challenges. 

The illusion of “free and infinite” infrastructure encourages wasteful usage.

Proprietary Software distribution

In many cases, public registries are now used to distribute not only open source libraries but also proprietary software, often as binaries or software development kits (SDKs) packaged as dependencies. These projects may have an open source license, but they are not functional except as part of a paid product or platform. 

For the publisher, this model is efficient. It provides the reliability, performance, and global reach of public infrastructure without having to build or maintain it. In effect, public registries have become free global CDNs for commercial vendors.

We don’t believe this is inherently wrong. In fact, it’s somewhat understandable and speaks to the power of the open source development model. Public registries offer speed, global availability, and a trusted distribution infrastructure already used by their target users, making it sensible for commercial publishers to gravitate toward them. However, it is essential to acknowledge that this was not the original intention of these systems. Open source packaging ecosystems were created to support the distribution of open, community-driven software, not as a general-purpose backend for proprietary product delivery. If these registries are now serving both roles, and doing so at a massive scale, that’s fine. But it also means it’s time to bring expectations and incentives into alignment.

Commercial-scale use without commercial-scale support is unsustainable.

Moving Towards Sustainability

Open source infrastructure cannot be expected to operate indefinitely on unbalanced generosity. The real challenge is creating sustainable funding models that scale with usage, rather than relying on informal and inconsistent support. 

There is a difference between:

  • Operating sustainably, and
  • Functioning without guardrails, with no meaningful link between usage and responsibility.

Today, that distinction is often blurred. Open source infrastructure, whether backed by companies or community-led foundations, faces rising demands, fueled by enterprise-scale consumption, without reliable mechanisms to scale funding accordingly. Documented examples demonstrate how this imbalance drives ecosystem costs, highlighting the real-world consequences of an illusion that all usage is free and unlimited.

For foundations in particular, this challenge can be especially acute. Many are entrusted with running critical public services, yet must do so through donor funding, grants, and time-limited sponsorships. This makes long-term planning difficult and often limits their ability to invest proactively in staffing, supply chain security, availability, and scalability. Meanwhile, many of these repositories are experiencing exponential growth in demand, while the growth in sponsor support is at best linear, posing a challenge to the financial stability of the nonprofit organizations managing them.

At the same time, the long-standing challenge of maintainer funding remains unresolved. Despite years of experiments and well-intentioned initiatives, most maintainers of critical projects still receive little or no sustained support, leaving them to shoulder enormous responsibility in their personal time. In many cases, these same underfunded projects are supported by the very foundations already carrying the burden of infrastructure costs. In others, scarce funds are diverted to cover the operational and staffing needs of the infrastructure itself.

If we were able to bring greater balance and alignment between usage and funding of open source infrastructure, it would not only strengthen the resilience of the systems we all depend on, but it would also free up existing investments, giving foundations more room to directly support the maintainers who form the backbone of open source.

Billion-dollar ecosystems cannot stand on foundations built of goodwill and unpaid weekends.

What Needs to Change

It is time to adopt practical and sustainable approaches that better align usage with costs. While each ecosystem will adopt the approaches that make the most sense in its own context, the need for action is universal. These are the areas where action should be investigated:

  • Commercial and institutional partnerships that help fund infrastructure in proportion to usage or in exchange for strategic benefits.
  • Tiered access models that maintain openness for general and individual use while providing scaled performance or reliability options for high-volume consumers.
  • Value-added capabilities that commercial entities might find valuable, such as usage statistics.

These are not radical ideas. They are practical, commonsense measures already used in other shared systems, such as Internet bandwidth and cloud computing. They keep open infrastructure accessible while promoting responsibility at scale.

Sustainability is not about closing access; it’s about keeping the doors open and investing for the future.

This Is a Shared Resource and a Shared Responsibility

We are proud to operate the infrastructure and systems that power the open source ecosystem and modern software development. These systems serve developers in every field, across every industry, and in every region of the world.

But their sustainability cannot continue to rely solely on a small group of donors or silent benefactors. We must shift from a culture of invisible dependence to one of balanced and aligned investments.

This is not (yet) a crisis. But it is a critical inflection point.

If we act now to evolve our models, creating room for participation, partnership, and shared responsibility, we can maintain the strength, stability, and accessibility of these systems for everyone.

Without action, the foundation beneath modern software will give way. With action — shared, aligned, and sustained — we can ensure these systems remain strong, secure, and open to all.

How You Can Help

While each ecosystem may adopt different approaches, there are clear ways for organizations and individuals to begin engaging now:

  • Show Up and Learn: Connect with the foundations and organizations that maintain the infrastructure you depend on. Understand their operational realities, funding models, and needs.
  • Align Usage with Responsibility: If your organization is a high-volume consumer, review your practices. Implement caching, reduce redundant traffic, and engage with stewards on how you can contribute proportionally.
  • Build With Care: If you create build tools, frameworks, or security products, consider how your defaults and behaviors impact public infrastructure. Reduce unnecessary requests, make proxy usage easier, and document best practices so your users can minimize their footprint.
  • Become a Financial Partner: Support foundations and projects directly, through membership, sponsorship, or by employing maintainers. Predictable funding enables proactive investment in security and scalability.

Awareness is important, but awareness alone is not enough. These systems will only remain sustainable if those who benefit most also share in their support.

What’s Next

This open letter serves as a starting point, not a finish. As stewards of this shared infrastructure, we will continue to work together with foundations, governments, and industry partners to turn principles into practice. Each ecosystem will pursue the models that make sense in its own context, but all share the same direction: aligning responsibility with usage to ensure resilience.

Future changes may take various forms, ranging from new funding partnerships to revised usage policies to expanded collaboration with governments and enterprises. What matters most is that the status quo cannot hold.

We invite you to engage with us in this work: learn from the communities that maintain your dependencies, bring forward ideas, and be prepared for a world where sustainability is not optional but expected.

Signed by

Alpha-Omega

Continuous Delivery Foundation

Eclipse Foundation (Open VSX)

OpenJS Foundation

Open Source Security Foundation (OpenSSF)

Packagist (Composer)

Perl and Raku Foundation

Python Software Foundation (PyPI)

Rust Foundation (crates.io)

Sonatype (Maven Central)

Organizational signatures indicate endorsement by the listed entity. Additional organizations may be added over time.

Acknowledgments: We thank the contributors from the above organizations and the broader community for their review and input.

What’s in the SOSS? Podcast #26 – S2E03 JavaScript’s Big Footprint: Robin Bender Ginn on Leading OpenJS and Open Source at Scale

By Podcast

Summary

Robin Bender Ginn, Executive Director of the OpenJS Foundation, joins us to talk about JavaScript’s massive footprint, the challenges of sustaining critical open source projects, and the importance of security in the web ecosystem. She shares her journey, insights on community-led development, and how OpenJS is building a healthier future for the JavaScript ecosystem.

Learn more and register for JSConf North America: https://events.linuxfoundation.org/jsconf-north-america/register/

Conversation Highlights

0:00 JavaScript’s Critical Web Presence
0:51 Robin Bender Ginn Introduces OpenJS Foundation
2:01 Core Challenges Facing JavaScript Ecosystem
4:12 Managing Older Projects and Outdated Software
8:23 Solutions and Security Improvements
12:12 Individual Impact and Community Involvement
14:35 Wrap-Up and Call to Action

Transcript

Robin Bender Ginn: 0:02
Anything you do requires JavaScript, whether it’s AI or in the metaverse. People forget that JavaScript is a critical part of delivering almost everything you do.

CRob: 0:17
Welcome, welcome, welcome to What’s in the SOSS, the OpenSSS podcast where we talk to amazing people and technologists within the space of open source, open source supply chain and software security. We have a real treat today. We have a friend of the foundation, Robin Ginn, and we are going to hear some amazing stuff about her little corner of this amazing world called open source. So, Robin, why don’t you introduce yourself and maybe share what’s your open source origin story for our audience?

Robin Bender Ginn: 0:51
Super cool. Well, hey, thanks for having me. I’m just super psyched to be here. We kind of have a little I would say we have a little corner for JavaScript. We have a big sort of footprint in the world. If you think about the web, JavaScript’s in 98% of the world’s websites. And I have the honor of being the executive director of the OpenJS Foundation. I’ve been there since the beginning and OpenJS was the merger of the Node.js Foundation with the JS, the JavaScript Foundation, a little over five years ago. So, I came on after a long career at Microsoft doing open source to lead up this wonderful organization. So super psyched to be here.

CRob: 1:39
That’s cool and we’re very glad for all the amazing work that comes out of your community super used around the web. From your perspective, having done this for a while, what do you see are some of the core challenges facing the world of JavaScript and the web ecosystem that impacts security?

Robin Bender Ginn: 2:01
Well, you know, I think we have the coolest developers around. Again, anything you do requires JavaScript, whether it’s AI or in the metaverse. People forget that JavaScript is a critical part of delivering almost everything you do. But unfortunately, one of the key challenges is the world of tech suffers from this shiny penny we call it the shiny penny syndrome.

Robin Bender Ginn: 2:26
People love the latest and greatest things and, you know, sometimes JavaScript and the web may not be seen as strategic as it truly is. That sort of creates a kind of a ripple effect on some other challenges we face. So whether that is raising money, you know, sustainability is very important. We have a lot of volunteers running our open source projects. As opposed to some company led projects, we have a lot of community led projects. So if you think about Node.js, it was downloaded 2 billion times last year, wow, wow. And that’s a lot of volunteers and, unfortunately, a lot of companies who all rely on, for example, Node.js, treat our really hardworking, passionate volunteers like they are their paid support staff and create a lot of demands on these folks. So those, you know, leads to burnout and all these other things.

CRob: 3:33
And that’s something that many of the communities we talk with and interact with feel similarly. They have similar challenges.

Robin Bender Ginn: 3:39
Yeah.

CRob: 3:42
Yeah, I think you probably touched on this a bit with your statement of being kind of a seminal foundation for the web. It’s hard to be a little older speaking as someone that has a little more gray in their hair than they used to, and OpenJS holds some really interesting kind of oldies but goodie type projects like Node.js and jQuery. You know how that impacts your maintainers and end users, where it seems like there are so many people that are using outdated or unsupported open source software?

Robin Bender Ginn: 4:22
Yeah, I mean, it does you know? Sometimes it sucks to be old, but in our case I would say that we have broad adoption. So Node.js, again 15 years old, it’s basically everywhere. Node is everywhere. Express.js, you know, 30 plus million. You know weekly downloads. Jquery, 18 years old. It’s in 92% of the world’s websites. So you know, what’s great is the adoption, the stability. The maintainers, many of them have been with the project for 10 plus years. It’s awesome.

Robin Bender Ginn: 4:59
And yeah, so we have this beautiful culture around these projects. You know, some of the challenges are a couple of things that we fixed. One is that our infrastructure got to be a little messy.

Robin Bender Ginn: 5:17
Let’s just put it that way, not quite like wobbly servers in people’s closets, but you know we had to do like an archaeological dig over the last couple of years to find out who in the years past, you know, had a handshake deal with this IT infrastructure company, who had access. So we’ve, you know we’ve done a lot on the infrastructure front to kind of clean that up. But, as you mentioned, a core challenge with older projects is that a lot of people are still using old versions that are unsupported and outdated.

Robin Bender Ginn: 5:55
We did some research with IDC Research Al Gillen, a pretty prominent open source developer analyst, and found that three quarters of a billion websites are using out of date jQuery, and of those people we surveyed which is pretty consistent with some other data we’ve seen a third of those reported having security and privacy incidents in the last two years. Yes, the Node project has done some other research to find that three quarters of users on Node.js are using old and outdated versions. Again, with 2 billion downloads, that’s pretty significant too. So we have created a couple of tools for people to see if they’re using current versions, and for us, it may not be our projects that could create a vulnerability, but it’s really a canary in the coal mine. So, for example, if you’re using old jQuery, if you’re using old Node, probably everything else under the hood is old too.

CRob: 7:03
It’s a really good guess.

Robin Bender Ginn: 7:05
Yeah, so if you want to kind of check your website, you can go to healthyweb.org to see if your jQuery is out of date and then the Node project. If you go on GitHub on Node.js, it’s /is-my-node-vulnerable and you can find out if you’re using an outdated version or not.

CRob: 7:29
This is a really kind of a systemic problem. I’ve talked a lot about this with Brian Fox from Sonatype and others in the ecosystem, and this is something that is again another very common problem. We have a lot of different language ecosystems, and, while the nuances of how to work in that particular space is a little different, a lot of the core challenges are identical.

Robin Bender Ginn: 7:52
Yeah, that’s why we wanted to sort of create this sort of idea of a health check. Like you know, you get your health check once a year, make sure you know everything’s spot on with your physical. We want people to like, maybe yearly, like you change your batteries and your smoke alarm, why don’t you take a look at what versions you’re using?

CRob: 8:13
That’s awesome advice. Yeah, so, but it can’t be all doom and gloom. What do you see as some kind of pathways to move us forward to a better future on the web?

Robin Bender Ginn: 8:23
Yeah, we have had a lot of industry support, government support and support from folks like you at OpenSSF and our friends Alpha-Omega. So if you think about, you know, the IT infrastructure, we really solved that problem through funding from the Sovereign Tech Agency oh, excellent, which was wonderful. They provided funding for us to do, you know, kind of that archaeological dig, so to speak, and we essentially modernized all of our OpenJS hosted projects onto just a few handful of software companies, whether it’s CDNs or clouds, and that has all been consolidated, migrated, and now we have some great partnerships in place for people who are sponsoring that work. So, for example, like CloudFlare, DigitalOcean, fastly, Microsoft Azure and others. So we know that six months from now, two years from now, that they’re going to be supporting our infrastructure. And what else was your other question? Oh, on how you know.

CRob: 9:37
What else do we do to move it forward? What do you do to move it forward?

Robin Bender Ginn: 9:39
Yeah, I mean really, I think one of the inherent problems with relying on volunteers is the one missing component to our maintainers is having people with security expertise. That is kind of a secret sauce for talking, you know.

CRob: 9:57
Yeah, it is so.

Robin Bender Ginn: 10:00
Through grants, through Alpha-Omega, we’ve been able to fund security engineers.

CRob: 10:05
Yes, oh, that’s awesome.

Robin Bender Ginn: 10:06
Which we couldn’t have done it otherwise. I mean, I think this is maybe the fourth year we’ve had a Node grant from Alpha-Omega. Four years ago the Node project did not have an active security working group. Today it’s a very robust working group. Back in the day four years ago it was very difficult to put out security releases for Node. It was 26 steps for every release.

Robin Bender Ginn: 10:33
Imagine with someone without expertise who wants to sign up for that in their free time nobody right, yeah, so, um, as part of the work um, that security working group now has fully automated their security uh releases, so it’s been like a game changer for the Node project.

CRob: 10:51
I bet Well. It also relieves a lot of the burden from the regular maintainers as well, right?

Robin Bender Ginn: 11:02
Absolutely. They’ve also put out some permissions, guides and policies on what defines a vulnerability and what doesn’t. Our OpenJS Foundation Security Working Group, which we call it LabSpace security working group, which we call it Lab Space. We’re opening up our own CNA, which is pretty cool, so we’ll be communicating more about that. The thing about JavaScript is that I think security vulnerability reports, probably like others, have become like car alarms Ignore, ignore, ignore. So hopefully, with some new policies and kind of having a little more control with this with our own CNA, we’ll kind of alleviate some burden for our folks.

CRob: 11:40
Oh, that’s excellent. That’s so exciting to hear about those amazing changes. I’m so happy for you all.

Robin Bender Ginn: 11:47
Yes, I know, honestly, we couldn’t have done it without the grants that we’ve received from you all and the membership support and the government grants, which we hopefully will go after some more Excellent.

CRob: 12:02
And thinking about can an individual make a difference in the space of web security or are they totally at the mercy of big tech in the space of web security.

Robin Bender Ginn: 12:12
Are they totally at the mercy of big tech? No, I think one of the flip sides of having these community-led projects is that if you want something, if you want to influence an open source project, we kind of have a doers, not a talkers policy. Excellent. So if you’re a doer, if you want a feature, if you want to help, all you have to do is show up. I think, again, we have the most warm and welcoming and fun group of community members. So, as you know, with open source, you can just come to any of our meetings. We have a radical transparency policy at OpenJS in our projects. So our meetings are almost all streamed live on YouTube and on our YouTube channel. So if you want to just lurk, if you want to participate, if there’s something especially you want, you can just be a doer, just show up and do the work. Also, there’s so many ways that you can make a difference. If coding is not your thing, but you want to make a difference, I like to say content is queen.

CRob: 13:17
I love that I’m going to open source that.

Robin Bender Ginn: 13:20
Absolutely so. You know we do a lot with training, documentation, uh, community organizing, um, and so that’s again brought new, brought new community members to our projects that’s amazing.

CRob: 13:35
Well, let’s move on to the rapid fire part of our session here. Right on, let’s do it fire, rapid fire. A couple quick and crazy questions for you. We’ll start off with a controversial one vi or emacs, neither. Oh, what’s your editor of choice?

Robin Bender Ginn: 13:57
I am a writer, I write about code the same.

CRob: 14:03
That’s awesome, cool cool, we’re neutral.

Robin Bender Ginn: 14:05
I’m neutral at Open.js well said, there you go.

CRob: 14:11
Who’s your favorite open source mascot?

Robin Bender Ginn: 14:15
Well, the rocket turtle probably. We had a mascot contest for the Node project 15 years ago. When it was created. We had a turtle icon and a rocket icon and you can see the rocket turtle is our new mascot, that’s awesome. Yeah.

CRob: 14:34
What’s your favorite adult beverage? Water, water flavored water, water, water flavored water, water flavored water well, that is a responsible choice, yes, adult beverage, so I don’t know I had a person just tell me coffee, which I was like you know, you’re right, I love coffee. That is my favorite adult beverage too.

Robin Bender Ginn: 14:55
Yeah, I, yeah, I don’t know.

CRob: 14:58
And then uh kind of uh as we wrap up here thinking about, uh, what call to action would you have for our audience or what advice would you like to share to a newcomer trying to break into this amazing space?

Robin Bender Ginn: 15:13
Um, yeah, I think the one thing I would say is you know, if we had one, I would encourage folks to join our Slack channel. That might be kind of an easy entry way, maybe even a little easier than trying to figure out what’s going on in GitHub. We have so many different channels. We have an icon right on the homepage of our website, so whether you’re interested in security or package metadata, interoperability or standards, we’ve got like an all-star group working on TC39 and some W3C projects. An easy way to get to know folks perhaps is our Slack channel and then you can see what’s going on. We also have a book club and events and other fun things, so you can get to know us. But yeah, it’s a very friendly group. You can always reach out to me too if you’re just not sure where to go, and I’m happy to introduce you to folks in each of these areas.

CRob: 16:08
Well, excellent. Thank you so much for showing up and sharing a little bit about this amazing space that, as you shared, runs a lot of our world today, and especially how we interact with software and services and applications. So thank you for all the work that your foundation does and thank you for the amazing things you do for the community.

Robin Bender Ginn: 16:28
And thanks, CRob, and for all of your folks. You provide a lot of guidance. I know we sometimes bend the rules a little bit to customize things for JavaScript, but you know You’ve got to make things for JavaScript, but you know You’ve got to make it work for the environment you live in. We do. We take all of what the OpenSSF creates and then we maybe tweak it a little bit for what works for our maintainers and end users. And we’ve been working on and we’ll be publishing on our website some new guidelines as well.

CRob: 16:56
Well, I look forward to reading it. Thank you for joining us. Have a great day.

CRob: 17:09
Like what you’re hearing. Be sure to subscribe to What’s in the SOSS on Spotify, Apple Podcasts, antennapod, pocketcast or wherever you get your podcasts. There’s a lot going on with the OpenSSF and many ways to stay on top of it all. Check out the newsletter for open source news, upcoming events and other happenings. Go to openssf.org/newsletter to subscribe. Connect with us on LinkedIn for the most up-to-date OpenSSF news and insight and be a part of the OpenSSF community at openssf.org/getinvolved. Thanks for listening and we’ll talk to you next time on What’s in the SOSS.