Do Open Source Obligations Change with Packaging Ecosystems?

The world of open source software has evolved significantly over the years. What started as a way for developers to freely share code has turned into a complex ecosystem with its own set of norms, expectations and even obligations.

Much has been written about what companies should and shouldn’t expect or demand from maintainers of open source projects, and related compensation considerations. To be clear up front, I fully agree with the general consensus that open source code is freely given and that maintainers who simply publish their code have no obligations beyond what the license states.

But I want to explore a controversial but important topic: what we as a community can and should expect from open source projects and maintainers who participate in packaging ecosystems.

When a maintainer takes the extra step of participating in a packaging ecosystem, I believe that triggers a new realm of obligations and social contracts — and that more public discourse and debate around this topic would be especially healthy for the open source industry at this moment in time when the XZ Utils and similar exploits are creating a special urgency around trust and transparency in build systems. This is a conversation that is way overdue, and at the crux of the modern software supply chain security movement.

New Distribution Models, New Responsibilities

Let’s begin by taking a quick look at how open source has evolved.

Historically, the responsibilities of building and distributing open source software were typically separated. Developers would publish their raw source code, then other communities like Linux distributions would take on the task of packaging and distributing that code to end users. These distribution communities, while often also open source, operated under their own policies and social contracts with users.

However, the rise of language-specific package managers like npm, PyPI and RubyGems blurred this line between “code vs. packages.” Suddenly, publishing packages became accessible to any developer. While this greatly accelerated open source development, it also introduced vastly different security guarantees compared to traditional Linux distribution packages. Many developers, myself included, didn’t fully understand these trade-offs at first.

These package managers made publishing accessible to anyone. They brought similar UX, but vastly different security guarantees. My first memories of Python involved struggling to get NumPy working and not understanding the difference between `apt-get install` and `pip install`, except that one worked and the other didn’t. I didn’t realize or understand the security trade-offs that were involved. The package managers look and feel the same. `npm install` feels a lot like `AppGet install` or `PIP install`, for example but they do completely different things from a trust perspective.

While Linux distribution packages have flatlined, language package repositories have exploded in popularity and become the default way most developers consume open source code. It’s important to understand that these repositories are not magical solutions; they are often volunteer-run and provide only basic curation, format management and malware removal. They operate under their own policies and user agreements.

Defining What Trust Means in Packaging Ecosystems

Crucially, these repositories occupy a privileged place in the ecosystem. The Python community, for example, has placed its trust in PyPI as the default package index. This is an implicit social contract — the community could decide to switch to a different default repository if it ever became unhappy with PyPI’s stewardship.

The same social contract applies to individual packages within these repositories. Maintainers publish packages under namespaces granted to them by the repository, agreeing to follow its policies. The repo maintainers make up the rules for who is allowed to publish to that registry. They take down spam and malware regularly and have recently waded into preventing typosquatting-style attacks and other requirements like multifactor authentication for publishers. In turn, the community uses those packages to build applications and power the open source supply chain.

Ultimately, the community is the boss here. As the end users of packages, the community approves the continued operation of the package repository and the packages within it. Alternative repositories can appear, but the community chooses which one is the default.

This is a multilevel social contract where everyone is dependent on the trust of the community. Even though publishers of code are under no obligation to anyone to do anything, the participants in the packaging ecosystems should have an obligation to follow the requests of the community through this transitive relationship.

The community can’t take away someone’s ability to publish code on the internet, but it can reassign the rights to a particular package namespace if needed. And this is not a power that should be taken lightly!

A Problem Better Solved by the Community (Not Regulators and Lawyers) 

Historically, open source has mostly worked with few formal policies. But with the growing regulatory scrutiny around open source security — as supply chains have come under attack , most recently with the XZ Utils vulnerability — change might be inevitable. Users *rightly* need more security guarantees than are available today, and I don’t expect the status quo to last indefinitely.

If you’re an open source maintainer, you don’t need to worry about your rights. No one can stop you from publishing code on the internet. But when you make the decision to publish your packages into a community repository, you are entering into an agreement with that community. And that community has its own relationships and obligations.

We’re already seeing repository operators collaborating on improved policies for how packages are built, published and maintained. This can be controversial, as end users and maintainers are often large companies that don’t contribute back as much as they could. Studies consistently have shown that the majority of code in most applications comes from open source maintained by a small number of developers. It may seem unfair for them to make demands of unpaid maintainers.

But this is a much greater conversation than merely compensation. A better question is what changes need to be made in chains of trust and transparency in package ecosystems. Instead of resisting change, I believe we should focus on making sure changes work for everyone. We have an opportunity as an open source community to develop new technologies that make what’s best for security the “easy-to-achieve” default for packaging ecosystems.

This isn’t a tide we have to fight against. By working together, we can make sure the open source ecosystem evolves to be more secure and sustainable for everyone involved. We’re all in this together. And we’re going to get a much better result by debating what obligations and social contracts should look like in open source package ecosystems rather than waiting for heavy-handed overcorrection by regulators and lawyers.