The free software commons

The Free Software movement has been remarkably successful. As a result, the collective of free and open source software has become a kind of commons; a public, shared resource that benefits everyone. But, it's not clear to me that the leaders of that movement actually know this is what they've done, or that this was the truly valuable outcome of the goals they pursued. Now that this commons exists, it needs to be tended, and protected. Otherwise, it will suffer the same fate as most of our historical commons: it will be plundered and enclosed by private capital interests.

I'm writing this in the wake of the XZ backdoor event. That's not exactly what this post is about, but it helped to crystalize thoughts I've been mulling for a while, now. So, for context, let me summarize the story, as it stuck in my mind.

1. XZ is a widely deployed mid-stack Linux system dependency
2. It is maintained by a single developer
3. Over the course of at least 2 years, a well-resourced malicious actor worked to both isolate and gain the trust of that maintainer
4. The malicious actor amplified the routine abuse that maintainers already deal with, which contributed to the maintainer's burnout and depression
5. The malicious actor succeeded at manipulating the maintainer into bringing them on as a co-maintainer
6. The malicious actor inserted an RCE backdoor into XZ
7. The backdoor was luckily detected early, largely because it introduced some performance degradation that was noticed by a Postgres maintainer

Like I said, this article isn't about the XZ story, but it is inclusive of it. The attack deeply exploited the precarious state of the commons. And it illuminates so many of the factors driving that precarity.

How is Software a Commons?

A commons is a shared, public, community resource that people both benefit from and contribute to. It provides some measure of support and security to people. The example that I expect most people are familiar with is the modern public library. Libraries provide their communities with access to information, education, tools, and shared space. People can use these resources as they like, within the rules set by the library ensure the resources continue to be available over time. The library in turn is sustained by the community. Taxes, donations, and volunteers are what keep libraries running.

I think the ecosystem of free and open source software also forms a kind of modern commons. It provides people with support in the form of freely available tools. People can use open source as a space to practice and learn. We can gain knowledge and mentorship. And we support the commons itself when we contribute our own open source projects, patches, documentation, and experience. This all provides people with some degree of security, in the broadest sense of the word. We can be assured that our free and open source tools won't be taken away. That the things we build can continue to function. That the skills we gain are our own.

That security—in the broadest sense of the word—is what makes the collection of open source software a commons. Security is protection against risk and loss. Security is dependability. We can depend on Free Software into the future, in ways that we can't with proprietary software. Apple can decide to stop supporting your old iPhone and it will just stop working. EA can decide to shutdown their license servers and your games will just not run anymore. The same is not true of Linux, for example. Even if every Linux maintainer quit today, your copy would continue to run as it is until your hardware failed. And you could take up the work that would patch defects or allow it to run on newer hardware if you choose.

I can't possibly do a better job of explaining what the commons are than Astra Taylor does. If you have the time you should just read her book, The Age of Insecurity, or listen to the lecture series based on that book.

2023 CBC Massey Lectures: Astra Taylor

Filmmaker and writer Astra Taylor explains how society runs on insecurity – and how we can change it.

CBC Radio

Securing Open Source

The commons of open source software provides people with a measure of security. But it also needs to be secured itself. Yes, that includes security in the infosec sense of exploits and backdoors, like the end of the XZ story would suggest. But also in the broader sense of protecting the ecosystem itself, as suggested by the rest of the XZ story. I've seen numerous calls to support open source maintainers in the past week. Too many to list. I'll highlight this example from Tidelift, because it's a common sentiment that's been widely shared:

xz, Tidelift, and paying the maintainers

Learn about last week’s xz library backdoor hack, its link to maintainer burnout, why we need to pay open source maintainers, and how Tidelift can help.

TideliftLuis Villa

The thing is, "paying maintainers" is not the solution. Yes, it would help those projects and those maintainers. And yes, those projects and maintainers that could get paid are a cornerstone component of the open source commons, to borrow a phrase from that blog post. But it doesn't support the commons, and I worry that in isolation, paying maintainers actually speeds the degradation of the commons. It could establish a hierarchy and gatekeepers. It would shape the way people engage with open source. Instead of a common good, it becomes a sort of vendor. It's only a commons so long as engaging with it is voluntary, self-governed, and self-beneficial. Capitalism already regards the work that goes into building open source software as simply free labor. Paying maintainers, without changing anything else about the situation, is a capitulation to that view. On some level, many of the people doing this work know that. That's how we get essays like I am not a Supplier, and the final paragraph of the Tidelift blog post:

We have gone to all the wells in our quest to squeeze more labor from these stones. Paying the maintainers is the only one left on which to build the foundation of a future of secure, reliable, resilient software industry. Join us! The maintainers need your support.

When well-governed, we have numerous examples of commons that can be sustained all but indefinitely. In fact, they seem to mostly fail as a result of either enclosure or extraction. So far, free software has been adequately robust against enclosure. But in the last few years, the threat has shifted to extraction. Licensing bait-and-switch tactics are a recent example. Vendorizing maintainers could very well be the next.

Governing the Commons

To be perfectly clear, I am not arguing against paying maintainers. I'm arguing that paying maintainers is a narrow response that will have detrimental side effects unless it goes hand-in-hand with other measures. The most critical of those is governance. I view this as the next step that the Free Software movement needed to take years ago. That didn't happen, and I would mostly be speculating if I tried to give reasons why not. But that's in the past and we're in the present. It still needs to be done, and the second best time is now.

Governance is a tricky thing. It's never ending, and highly situational. And it's not magic. The simple fact of governance will not prevent bad things from happening. That's in part because that governance is present whether we recognize it or not, and we cannot stop bad things from happening. Governance enables us to respond when they do. The philosophy of Free Software should guide the way projects are governed every bit as much as it guides the way they're licensed. The Freedom promoted by that movement could also be called autonomy. Proper governance would safeguard that autonomy. This work is unfamiliar in the open source ecosystem, but it's not actually excessive, or even new. It's already being done. What would be new is tools, resources, and guidance to help projects do it better.

Without some kind of intentional governance, projects become the fiefdoms of their creators, or their most active maintainers. It may seem unfair to ask that maintainers govern their projects, in addition to building, designing, documenting, supporting, and even marketing. And you're right, it is. The problem is that they already do, whether they know it or not. A "benevolent dictator for life" is doing governance just as much as a dedicated foundation would. I say it's even more unfair to expect them to do it alone. The change I'm suggesting is that we recognize and support project governance. We share and discuss and learn from the experience. And we consider governance as a signal in how we use those projects.

Let's return to the example of the XZ incident. In hindsight, it's clear the project and the maintainer were struggling. He was working alone for years. He had a bug tracker and a mailing list that were both filled with aggressive and demanding outsiders. And he had no one to help. No backup, no plan for succession, nothing. The thing that alarms me about the situation is that no one found this alarming at the time. This kind of scenario is so normalized that downstream projects didn't even notice it. Even though many of those downstreams are considerably more well resourced. Would paying the XZ maintainer have helped? It's hard to say, but if it came with additional expectations, then I suspect it would have actually been a detriment. Another option would have been to reduce demands on the XZ project and maintainer. As software engineers, we sometimes look for ways to apply back pressure. The systems we build are sociotechnical systems. We're part of them just as much as the hardware and software are. One of the functions of governance is to apply and respond to that back pressure at the social layer of the system. No one did that. No one seems to have even had the capability of doing that. That's the lack of governance.

If money really is the only way companies can contribute, then why not pay for that? A significant aspect of governance is telling people no and sanctioning bad behavior. That's emotionally taxing work, even without considering how much personal investment a maintainer likely has in their project. What if instead of paying maintainers to implement a security checklist, we paid moderators to restrict abuse on mailing lists? You know, for example. What if a maintainer could ask for help in rejecting out-of-scope feature requests? What if they could join arbitration coops? We have not "gone to all the wells," just the ones that turn open source into labor.

Becoming Commoners

The thing is, paying for services is not the only way companies can contribute. Companies can actually just contribute. Rather than extracting resources that they assemble into products to sell us, companies could be good neighbors and help to maintain the commons itself. How many bug reports and feature requests come from companies that are just consuming a project, with no other relationship? Their using free software is one thing, that is the whole point, after all. But making demands is something else entirely. If they're making demands on the commons, then it seems only right they should make contributions, too.

This isn't even hard. Many companies try to claim ownership of the entire coding output of their hired programmers, regardless of whether it's done on unpaid time, with the programmer's own resources, or even completely unrelated to their paid work. They can stop doing that. The money that purports to be so readily available could be put to banning that practice. To go one step further, companies can just authorize their workers to contribute to open source projects wherever it's relevant. I noted on Mastodon that I have countless time either heard or said that I was waiting on an issue to be picked up in an open source project. As professional developers, we don't do this because we're individually lazy or selfish or demanding. Mostly. We wait for someone else to contribute because we're actually not allowed to make those contributions ourselves. Companies can stop that practice, too. Or use their money to have it banned. Either of these steps would help in ways that extend dramatically beyond simply paying existing maintainers.

But never mind companies, our own existing institutions can take the lead. We could have services that explain and recommend decision making frameworks in the same way we have summaries of software licenses. For that matter, how many thousands of meetups do we host focused on programming languages, libraries, frameworks, apps, or even just tech as a concept? How much more benefit would we get by replacing even a small fraction of those with issue triage parties?

I'm imagining these things, and I'm inviting you to imagine them, too. And to keep imagining beyond this tiny window of possibility. Our world and our technology is all too often bent to serve the preferences of capital. But Free Software has been a rejection of that dynamic, and that's powerful. You can just make the software that suits you, you can share it with other people, and they can share with you. You don't need permission from IBM, or from Microsoft, or even from your boss to do it, and that's powerful, too. That's the commons. If our goal is to support open source maintainers, that's the support I would choose. And that's the future they deserve.

Cover photo by Pixabay