Ethics in Open Source (2 Part Series)

The Open Source movement, as championed by the OSI, prizes absolute openness above all other concerns. Openness, they claim, is an absolute good, from which all other virtues flow, not to be questioned or criticized. It doesn’t matter if that openness enables evil in the world, without openness we cannot have truly collaborative software development communities. So the claim goes.

I want to question this claim. Openness seems like a good thing, but I think there's plenty of room for disagreement. I am going to argue that there is nothing absolute about openness, that openness is not an end in itself, but a tool that we can use for good or ill. It turns out to be a pretty good tool when used to build and empower communities. But it can also be an effective tool for exacerbating existing injustices, and creating new ones.

Maybe we’re valuing the wrong thing. What if we look at Open Source values through the lens of moral philosophy, by applying Scanlon’s contractualist theory of morality? When we do that, I think it becomes pretty clear that we ought to discard openness as an axiom, and start thinking about other ways to build software collaboratively that do not make us accessory to horrors. We can create open communities, better communities, more inclusive communities, without Open Source.

The Open Source movement has always been focused on code. The result is a system that sadly neglects people. Many maintainers find themselves in a curious place. On one hand, we have people who regret seeing their code used for unethical purposes, but, because of the Open Source values they previously embraced, are unable to do anything except watch their code become weaponized. Others, perhaps not grasping that the gift economy has been usurped by more powerful forces, struggle to figure out how to make ends meet even as their labor creates immense value for others. We find ourselves in this position because the key Open Source values exacerbate an existing injustice: Because the OSI definition of Open Sources values the consumers of code over creators, Open Source helps concentrate power in the hands of already powerful actors at the expense of maintainers. I feel that not only could we do better, we have a moral imperative to find better development models.

In short, Open Source doesn’t provide the democratization that proponents think it does. Instead it creates opportunities and incentives for the privileged to unjustly exploit maintainers. Moreover, insofar as we want (and we do want) to make community-driven software development a more inclusive place for everyone, then it is particularly important that we are not inviting the already disadvantaged into a system designed to exploit them.

Instead, I’d like to replace ideologies that focus on code, and what others can and cannot do with the code we create, with ideologies that focus on people, specifically with a focus on who benefits, and who doesn’t, from the code we create. What does a people-centric collaborative software development model look like? I’d like to explore some basic properties that such a model ought to have, as a starting place for building new institutions to support productive, non-exploitative software development.

What we owe to each other

Morality is inherently, whatever theory you subscribe to, about people. (Footnote: The following discourse isn’t going to satisfy my fellow moral philosophers. I apologize for that; my goal in this section to address an audience new to these ideas. The result is something rather watered-down and anodyne, but hopefully nevertheless illuminating for those who have never encountered these ideas before.) We don’t (usually) worry about the moral consequences of, for example, treating a thing badly, except insofar as that treatment has consequences for people. Without worrying too much about the nuances around this claim (and there are plenty), this is largely because we don’t think that objects (like a toy, or a shoe) are morally considerable, that is, put crudely, worth worrying about (although cf. Shintoism). But we do think that people are worth worrying about, that our treatment of them matters deeply. Some of us will extend this consideration to animals; a few to plants; certainly many of us will extend it to entire ecosystems. But very few of us are worried about how the outcome of an action affects a stone, for example. And almost no-one isn’t worried about how the outcome of an action affects other people, which is the basic point I’m trying to make.

So, people come first when we worry about the outcomes of our decisions, that is to say, when we reflect on the morality of an action. Morality is a question of how we treat people.

I myself have become increasingly convinced that T.M. Scalon’s contractualist theory of morality is a productive framework for thinking about how to treat people. I’m not going to summarize the theory here, as it has quite a lot of moving parts—you can read the Stanford Encyclopedia entry on your own time. But I will (roughly) summarize the key takeaway for this discussion, which is that insofar as our concern is understanding how we are to live together as humans (and that certainly concerns me, and it sure as hell is a central concern of any collaborative software development model), then the normative content of our moral judgments derives from whether we are treating our fellow humans as humans. If our choices derive from (or can ever be justified by) dehumanizing our fellow humans, then those choices are wrong. And therefore if our choices come from (and only from) a place of respect and recognition of other people, then our choices are right. (Footnote: An important part of Scanlon’s theory is that intent doesn’t enter into this determination. The road to hell is paved with good intentions. The question is this: If we look at the complete set of all reasonable justifications for a particular choice, do any of those dehumanize others, regardless of intent?)

I like this theory, because it provides a fairly straightforward litmus test that we can apply to different situations. And, unlike consequentialism, it doesn’t require us to engage in fanciful accounting of future (and hence unknowable) outcomes, nor can it be easily tweaked and twisted to give us the answers we want. So let’s run with it, apply it to Open Source, and see what comes out.

A moral appraisal of Open Source

Unlike ethical theories, Open Source dogma is concerned primarily with code, and to the extent that it is concerned with people, that concern is with the wording of software licenses. Open Source, as defined by the OSI, is focused on what people can do with code that is licensed as Open Source. (If you haven’t yet read the OSI definition of Open Source at the previous link, I encourage you to do so now.)

You might not think, therefore, that there are interesting moral implications or that we could use an ethical theory to judge the Open Source definition, but I disagree. Code is created by people, and consumed by people, and because the Open Source definition attempts to regulate how people can interact with code licensed as Open Source, choosing to create or to consume Open Source software is, therefore, a moral choice—a decision whose outcome affects others, and reflects the relationship we wish to have with them.

I encourage you to read the definition for yourself, but there are two principles in particular that I think deserve closer attention:

1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

These clauses exist for what was perceived by their author to be a very good reason: The very core of Open Source is the idea that everyone should be able to take advantage of Open Source code. In principle, this sounds great! There shouldn’t be any grounds for excluding people from accessing the source code, and making what use of it they want. That just is the very idea, and the goal is a world in which source code is set free, and software development democratized so that anyone and everyone can participate, and anyone and everyone can benefit.

But, if we dig a little deeper, we see that these two clauses have an interesting feature: They privilege the consumer of Open Source code over the producer, by requiring that the producer give up certain rights. The producer is not allowed to put any conditions on who can use the code. Moreover, the second clause effectively prevents the producer from charging for access to the code—they are permitted to do that, but those who receive the code are permitted to redistribute that code for free, effectively negating the producer’s ability to charge. This is actually a quite important point that we will come back to later, but for now the important takeaway is that producers, by adopting Open Source, have locked themselves into a situation where they lose all control over their code once it’s released to the wild.

This is pretty absurd. But it’s a predictable outcome when we lose sight of our moral compass, and start prioritizing things and ideas over people. Let’s explore this situation in more detail.

Who benefits from Open Source?

At first blush, this seems an easy question to answer: Everyone! You get some code, and you get some code, and you get some code!

But this only holds true in libertarian utopian fantasies. The reality is quite different: It is true that you and I benefit to a certain degree, but large companies derive massive value from Open Source, and have every incentive to do so without reciprocation. The key is that Open Source is literally about exploiting unpaid labor. One of the key benefits of Open Source is that that by outsourcing development to teams of unpaid labor, companies can reduce their costs. This was a large part of ESR’s argument for why Open Source is a competitive advantage for companies, although he couches the point as “cost sharing”—the idea being that companies can share resources to develop open solutions. The reality in 2019 is better described as companies outsourcing their development to free labor to realize significant cost savings.

At OSCON 2019, Amazon’s VP of Cloud Architecture Strategy, Adrian Cockcroft, reinforced this view, and took it further:

So now that Open Source business is using the developer community as a force multiplier for engineering: It means they don’t have to invest as much in engineering as if they were doing 100% of this themselves, because the community is actually doing some of their engineering for them...and then you take the enthusiasm of those people, and you use that to create market awareness, and you invest in that market, so know you’ve got your marketing…you’re using open source to magnify your effect in the marketing side.

Although Adrian is specifically talking about companies who build business models around Open Source products, what he says can be applied, mutatis mutandis, to the way Amazon and other large companies exploit Open Source software as well. So while you and I can reap modest benefits from Open Source, commercial enterprises are able to literally hire free labor for their engineering and marketing departments, at scale. This is certainly a real advantage of Open Source—for those companies.

OK, fine, so companies can see real monetary benefits from the free labor Open Source provides. Is that really so bad?

Yes. Yes it is.

Let’s look at how this plays out on the maintainer side of the equation.

The costs of Open Source development

The challenge we face is not that companies are getting free labor. The challenge is that when large corporations are able to extract large amounts of value from open source, those providing the value are expected to continue to do so on the ground that the gift economy is ideologically pure, and that requesting money for labor provided is greedy, at best. It creates an informal institution, whose entire aim is maintaining a status quo in which Open Source maintainers feel obligated to continue to support software, even when it’s not in their own interest.

Which leads us to the bizarre situation in which those who have decided to pursue Open Source as a full-time career are in a constant state of panic. Consider, for instance, Buster Neece, the maintainer of AzuraCast. He has, for reasons that are utterly irrelevant to this discussion, opted to work on AzuraCast more or less full time. And why not? It’s a piece of software that delivers value to its users, and he is rightfully proud of what he’s built. And yet, Buster has, time and again, pleaded for money from the community, from those who derive value from the software. And plead he must, for without that money, his ability to simply pay the rent is at stake.

What kind of world have we created where we encourage people to sacrifice their free time, their families and friends in the name of creating software? This world we live in is, let’s be honest here, fucking deranged, and its values twisted up beyond recognition. We value software for software’s sake, and ignore the human costs—and worse, we encourage the very creators to themselves devalue their own labor, believing that if volunteer work is good, then more volunteer work is better, unto the point of burnout. By any rational notion, whether you subscribe to Scalon's contractualist ethics or not, this situation is morally repugnant.

But it gets worse than just the plight of an individual. Those individual’s choices, in the face of harrowing demands upon their time, can affect millions of others. Consider this flaming piece of the NPM hellscape. I’ve spoken with Tierney, I know what the module in question is. I won’t reveal anything here, but I will say this: It is a critical piece of Internet infrastructure that was abandoned because the maintainer could no longer uphold their perceived obligations, and decided that the demands upon their time were no longer worthwhile. This module represents a single point of failure for a shockingly large swath of the internet, and yet I cannot imagine any reason to blame the maintainers for jumping ship.

Never mind the sagas of leftpad and event_stream, modern versions of Grimm’s fairy tales, stories we tell our children to scare the shit out of them, and keep them from wandering into the woods alone at night.

We have built a system that depends upon the unpaid, unappreciated labor of thousands, and then created incentives for them to jump ship, leaving the rest of us at the mercy of the Fates. This isn’t sustainable. And it sure as hell isn’t morally defensible.

The Problem of Evil

There’s also the question of who fails to benefit from Open Source. What happens, when Open Source code is used by individuals or organizations to commit atrocities or to violate human rights? Many Open Source developers and maintainers are waking up to the idea that this is happening, today, are unsettled by it, and are looking to change the way their code can be used.

At this moment in the United States, families and children are being locked away in camps in what appears to be a gross violation of human rights by a government entity called Immigrations and Customs Enforcement, or ICE. And it is pretty clear that Open Source code is playing a role in this situation. Which seems to imply that anyone who has ever contributed to the Open Source projects utilized by ICE are complicit (at least to a degree), in these human rights violations. At the very least, those software maintainers would in some cases strongly prefer their code not be used for these sorts of purposes.

To wit, consider the case of Chef, a company that builds and sells support contracts for Open Source tool to manage computer infrastructure. It recently came to light that Chef had done business with ICE, who used the product in the course of their business with these incarceration camps. When the news broke, Seth Vargo, and ex-employee of Chef, was particularly distraught, as he knew that a great deal of Open Source code he created and maintained was being used. So he did something incredibly brave: He pulled his code from GitHub, more or less instantly disabling Chef’s offerings.

This was, at best, only a temporary measure, as the nature of Open Source means that Chef need only pull archives of Seth’s code to restore the lost functionality, and legally speaking there is nothing Seth can do to stop this, because he licensed his code as Open Source. And Open Source code is available for evil people to use for evil purposes.

Indeed, the very nature of Open Source means that of course Open Source code can and will be exploited to violate the rights of other. Indeed, according to the OSI, this is not only a natural consequence, but is to be tolerated. Tolerated! Here is what OSI has to say on this very topic:

Can I stop "evil people" from using my program?
No. The Open Source Definition specifies that Open Source licenses may not discriminate against persons or groups. Giving everyone freedom means giving evil people freedom, too.

Whiskey. Tango. Foxtrot.

What if, like Seth, or like many others, we’d rather not have our hard work used to create and perpetuate injustices, even human rights violations? In a world that places openness above all else, there is little that we can do.

Open Source is morally problematic

If I am being bombastic, I would go so far to say that Open Source is a moral travesty, even as it has provided us with innumerable benefits. This is not a utilitarian calculus. This is a claim about what we owe to each other. Open Source encourages us to strip away the humanity of maintainers, and focus only on the code. Only the code, and its freedom (as though a thing can be free), matter in the Open Source universe. But by dehumanizing maintainers, Open Source has created a culture that discards moral considerations in the name of profit.

Open Source encourages theft

I think we can agree that if I extract value from your labor, you deserve compensation. Money just is the medium for exchanging value, and without compensation, there is no fair exchange of value. There’s just me stealing your labor. The users of AzuraCast are stealing the labor of Buster Neece. Amazon is stealing the labor of MongoDB’s engineers. It’s a tragedy of the commons at planet scale.

What makes this theft particularly pernicious is that it is awfully casual, and really quite meaningless in the individual case. Were I a passing user of AzuraCast or event_stream, it is not clear that I owe Buster Neece or Dominic Tarr a financial debt. The software is free to download, free to setup, free to use. The support forums (often GitHub Issues) are open to anyone to post a request (actual replies on the other hand…).

Indeed, the very nature of Open Source is to encourage us to think in this way, that we are entitled to the software, because of course using Open Source software in whatever way we choose, unencumbered of obligations of any kind, is my ESR-given right. It’s built right into he very definition of Open Source.

1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

Open Source undermines the autonomy of maintainers

Precisely because Open Source is so focused on the agency of those consuming software, it automatically rejects the agency—and hence the humanity—of maintainers.

What if we, like Seth, wanted our agency as creators considered? The creators of JSON inserted an interesting clause into their license that JSON is not to be used for evil. That’s an awfully broad term, open to interpretation, yes. Coraline Ada Emke recently published the Hippocratic License which attempts to leverage the UN’s Declaration of Human Rights to achieve something similar in a way more likely to have legal bite. The 996.ICU license protests the working conditions imposed upon Chinese software engineers, by enshrining restrictions on working conditions on the users of the licensed software. These kinds of clauses exists as a plea to entertain the idea that creators should have some say over their creation, that they are human, morally considerable entities, not to be forgotten on the way to monetizing all the things. They would really rather not see their work contribute to injustice in the world. (So say we all.)

Yet, as I’ve mentioned, this runs counter to the OSI’s position on the absolute importance of openness. If we want to consider the moral implications of our code, we cannot do so seriously when constrained by the dogma that openness is more important than the people our code impacts (or the people who create and maintain that code).

I think there’s still a lot to be said on this topic. There’s growing interest from some quarters in preventing their work from being weaponized, or used to perpetuate injustices. I think this is a perfectly rational desire, but as you can see the whole thing is incredibly complicated. Watch this space.

Open Source creates incentives for maintainers to undermine their own best interests

OK, so if Open Source is immoral, why not just walk away from it? Why not do…well, something else? Because it’s not that easy! Open Source has created a culture in which we expect that developers will contribute to Open Source code, as a matter of course. Better yet if they are maintainers. Better still if they are maintainers of popular projects. We lionize the creators of Open Source software, not just individually, but systematically. We have built entire institutions around the importance of being a part of the Open Source movement.

Want to be taken seriously as an engineer? Want a job in Tech? Need a portfolio of work? Require a measure of reputation in the developer community? Better have a track record of contributions to Open Source! Or better yet if you can show that you are a maintainer of a popular Open Source project. For many, you are your contribution graph.

Moreover, we live in a culture that values helping others at our own cost. We valorize selfless acts of kindness, and I think Scanlon’s ethical framework makes it easy to see why. Sacrificing something of yourself for others is the ultimate expression of respect for a fellow human as a human. But this expression of respect can be taken too far. When we engage in sacrifice until we have sacrificed all we have to give, or that sacrifice begins to impact our friends and family, or when we begin to expect that sacrifice from others, these are all situations where we fail to respect the humanity of people: ourselves or our family or other helpers.

And indeed, this kind of expectation, that we are entitled to the sacrifices maintainers make, has become the norm, as one commentator has shared. This culture of entitlement is rampant in the Open Source world, but maintainers have only so much to give. This culture of entitlement that surrounds Open Source, was created by the expectation that we get our software for free, is deeply morally problematic.

Working with Open Source is a privilege that, when exercised skillfully, gets you the best reputation, the best jobs. If you don’t have the time or money or will to take the time to provide labor for free towards an Open Source project, then you find yourself increasingly in the margins of the tech world. Open Source perpetuates systematic injustices. The ability to participate creates new opportunities to participate, and failure to participate lands you in a place where you cannot find the resources to continue participating. So get your commits in while you can.

Open Source denies the humanity of maintainers

Let’s tie this all back together. Scanlon’s conception of morality tells us that choices that devalue the humanity—the agency, the rationality—of others are wrong, and choices that respect the humanity of others are (therefore) right.

When we choose to participate in the world of Open Source, whether as maintainers or as consumers, we perpetuate systematic injustices against other maintainers. We contribute to a gestalt that rewards Open Source software and contribution. We extract unpaid labor from a workforce that might or might not want their labor extracted thusly. We send a message that we don’t care about the intents, and therefore the agency, of the maintainers of the software we use.

Open Source is unwilling to consider the humanity of those impacted by code

In the same vein, precisely because Open Source values maintain that Open Source code must be made available to all without discrimination, every time we release new code into the Open Source ecosystem, we risk our code being used by actors intent on doing evil, on creating injustices, on denying the humanity of those impacted by our code. Even if we have the best of intentions, Scanlon is pretty clear: Our choice to release code that could be used in this way is wrong.

Open Source is Immoral

Here it is. If you’ve followed me this far, and haven’t figured out where we’re going yet, the only possible conclusion is that choosing Open Source is therefore wrong, in the strongest moral sense of the term.

So what if we just didn’t? What if we chose not to participate in the Open Source ecosystem, while attempting to keep what makes Open Source actually valuable and interesting, what would that even look like?

People > Software

Well, it’s early days yet, but leveraging Scanlon’s ethics, we can at least see some principles, some concrete points of leverage to rally around and to focus our collective thinking around the kind of change that collaborative software development world needs to see.

If we want to move into a post-Open Source world, we first and foremost need a new term for what it is we do that captures what we stand for. I don’t know what that term is, but it isn’t Open Source (capitalized) or open source (lower case) or F(L)OSS (which is just Open Source (capitalized) with a conjunction to something else). I’m going to use the term “collaborative development”, but only because I’m not very good at naming things, and we need a name, and it will do for now.

Here are some candidate principles to guide an ethical conception of collaborative development.

Maintainers are people, and deserve to be treated as such.
Concerns about the “freedom” of software are overblown, and are just an attempt to hide from the complexities of dealing with people, to hide behind that false claim that we can separate technology from messy human things like politics and morality. Let’s instead begin with people, and treat technology as an extension of maintainers as people, an expression of maintainers’ needs and desires. Let’s stop thinking of software as a good to be traded freely, and start thinking about software as a product of human labor, labor that deserves consideration.

Technology exists to serve human needs.
(And not the other way around.) Trying to isolate software from politics is like trying to isolate cold from heat, or the evening star from the morning star. Instead of trying to isolate technology from messy human concerns, we should instead embrace this relationship by acknowledging that software is first and foremost meant to solve human problems. Our failure to collectively acknowledge this order of priority is what’s landed us in this mess.

We’re all in this together.
Open Source values large economic actors that consume software over the maintainers. Open Source creates incentives against contribution back, and sharing experiences. But one interesting effect of making the source code freely available, is that it can help lift others up—by giving them the opportunity to understand how their tools work, they can improve them. This in turn opens our tools to improvement through widening the range of experiences that inform how those tools should work, broadening the kinds of problems that exist that those tools can help solve. When we recognize that making source code available is first and foremost a mechanism for sharing and growing in the context of an ever-expanding community, we also recognize that the virtues of collaborative development are human-centered virtues. Not technology-centered, or business-centered. But Open Source as an institution doesn’t cast the virtues that way, because of its focus on making collaborative development palatable to business, ends up privileging business over the shared community of creators, and transforms would-be contributors into passive consumers. We should acknowledge that making source code available is first and foremost a way of acknowledging our own individual limits, and an invitation to others to help us transcend those limits, and find ways to capitalize on that invitation.

What comes next?

OK, there are some values. I bet we could come up with more. But for now they are just words on paper. How do we socialize them, normalize them, make them the default way that we approach software development as a community of collaborators? Institutions.

Our current institutions—including formal institutions like the OSI, and informal institutions like the relationship between Open Source contribution and recruiting—, need to shift because they lead us to make morally bad choices, choices that devalue human agency and rationality.

So we need new institutions to encode, propagate, and normalize these Human-centered values. Institutions that acknowledge that humans are at the center of technology, and that morality is a central part of thinking about and regulating human activity. Not technology, not “freedom” of code. We need to incorporate moral values and an understanding of the political nature of humans as first-class citizens in the pantheon of software development. We need institutions to legitimize this view, to show that collaborative development can be more than just the freedom to take code from maintainers for your own ends, but as a tool for advancing our very humanity, to frame software development at very large, social scales in just the way the FSF and OSI have done before. To not just legitimize the plight of the maintainer, but to center maintainers as humans, make them the center of a new value system, and normalize those values among developers of all stripes.

That’s a tall order!

The Ethical Source movement, started by Coraline Ada Ehmke, aims to redefine the terms by which we openly collaborate on software. She offers her own alternative to the Open Source definition, one that places ethical concerns front and center. I think this is a pretty exciting development, and worth discussing further.

I envision Maintainerati as an additional step in this direction. By pure chance, three humanities academics are now at the reins, and our mission has become to understand the challenges that maintainers face at both a local and a global scale, and to provide the frameworks for overcoming those challenges, which includes normalizing human-centered principles like those I articulated above as a replacement for oppressive OSI dogma. There is undoubtedly room for other institutions as well, as we are going to need all the help we can get. We'll be setting up a discussion forum in the coming days, where we hope you will join us to move this conversation forward.

This has only been a cursory introduction to just how problematic Open Source software is. There’s still a lot to be said. I’ve laid out some puzzle pieces, and showed that they belong to the same puzzle, but I haven’t really begun to assemble them yet.

I don’t know what comes next, what a post-Open Source world looks like. But I want to find out. I want to know what a model of collaborative development that values the autonomy of the creator, and the value of why they create, over the “freedom” of code, over the interests of the powerful, looks like. This is something that can only be found from the bottom up, by rejecting the institutions, formal and informal, that have framed the conversation for the past twenty-plus years, and creating a new set of principles—principles founded on the mutual respect for our fellow humans instead of abstract concepts. It’s not going to be an easy road, or a short road, but I am committed to understanding what this new model could be.

We live in a world in which there is a lot of weight placed on “Open Source values”. This is just dogma. I want to shift the ideology away from “politics-neutral values” and onto people. What’s valuable are people. Everything else, including software, is instrumental. What does a people-centric model of collaborative, open software development look like?

I have no idea, but I’m really excited about the possibilities. Will you join those of us exploring them?

Further Reading

If this topic interests you, then I recommend the following reading: