2016

Written in January 2016

In my talk at Open Source Bridge last summer, I discussed how I’ve come to see a significant disconnect between the community-focused messages we hear in open source, versus the actual social and economic impact of the practice. In fact, most things we do in open source ultimately enrich corporations, and provide little guarantee of equal participation or benefit for the individual contributors. As a result, when we focus on success stories in open source, we tend to describe the successes of businesses (such as Google or Amazon) and their leaders. In doing so, we gloss over a number of other significant human impacts. I’d like to dig into what goes wrong and why.

These problems include:

  • Situations where the founders and contributors can’t afford to continue working on open source projects because they aren’t receiving enough financial support for their work. They may or may not have tried to commercialize the project: we hear from people who couldn’t find the right business model or the right customer base.
  • Severe burnout, having an impact on productivity, and physical and mental health. This also leads to contributors dropping out, and to products that are undermanaged or abandoned because no one with authority has the energy left to support the community.
  • Neglected expectation management and support systems that leave people who open source their code overwhelmed by support requests–which then drives burnout and related problems. This also can cause people employed at open source software companies to feel like they’re never off the clock.
  • Built-in assumptions about the accessibility of free/open software practices. As others have asked: is it free if you don’t have your own computer? Is it open to people without the leisure time to contribute?

It’s tempting to think that these are just individual problems, outliers in an overall wave of success. But as I’ve studied the history and the practice of open source, I’ve come to believe something else. What we see is the effect of the Open Source Software model doing exactly what it was designed to: making code freely reusable for commercial use.

The Free Software movement, with its focus on protecting what individual people could do with software, had an educational and community benefit, but the licensing terms get in the way of commercial opportunities. The people who founded the Open Source movement saw that they could increase the adoption of free/open source software in companies’ products if they modified these terms of interaction. In a series of discussions, coinciding with Netscape’s announcement releasing the source code for Netscape Navigator (out of which grew the Firefox Browser), participants came up with a definition of “open source” and formed a professional association, the Open Source Initiative (OSI), to promote it.

The role of the OSI is to regulate what software licenses can be officially labeled as “open source”. This means that they can set the terms under which the owners of open source software projects share their code, and the terms that dictate how that code can be used. The specific terms that they have chosen to include are much broader than those given in the original GPL copyleft license of the Free Software movement.

Let’s pause for a moment to understand what copyleft means, because the distinction is important: copyleft (a play on “copyright”) refers to the requirement that anyone who uses code provided under that license within their own product must also share the code under a similarly restrictive license. It’s a way of ensuring that you can’t sell a piece of software that uses my code without also distributing the source code for others to use. This becomes quite a bit more complicated now that many software products are offered as an online service, not an installed product, but I’ve worked on software where we were forbidden to include GPL-licensed code because it would require that we release the code to our product.

So then, the OSI created a definition of open source that allows us to do more things with other people’s code. Some of these things are particularly beneficial to commercial use: being able to reuse or modify someone’s code without sharing the code you create from it in any way, being able to use code without any additional recognition or compensation to its creators. This flexibility has massively enabled the use of open source software in business: we can build an entire software stack out of components that cost nothing and require nothing else from us.

You may have noticed that I’m talking a lot about what benefits companies, but not the impact on individuals. It is often assumed that what benefits companies will help the individual: in the form of jobs, contracts, sponsorship, other kinds of support. But what we’ve actually created is a system where companies can use an enormous pool of free material, of unpaid labor, in order to build their own success and profitability. There is absolutely nothing in this system that discourages that. In effect, we’ve created our own tragedy of the commons, a free set of resources that are used by all, that no one is required to replenish.

Companies do support open source software creators, some of them. When they have to, when it’s strategically advantageous, when it gives them more power over the end product. But as a rule? No, the amount of uncompensated work that happens in the open source ecosystem demonstrates otherwise. We shouldn’t really need volume to see a problem here, though. The fact that this is a system where companies profit from free labor, giving them an incentive to encourage that labor to continue, is already destructive enough. The end result is a level of instability and inequality that threatens the existence of many open source projects.

What can we do about this? To start, we can’t keep doing the same thing and hope it gets better. This means that all of us who work in open source are going to have to understand that we’re part of the problem. We are practicing our work within a model that doesn’t do what we hoped. We want to build community, learn from each other, mentor newcomers, and create ever better code. The way that we’re doing it, however, leaves people sick, tired, depressed, and even lacking the income to look after their own basic needs.

It’s not surprising that Basic Income is getting a lot of attention from those of us who think about these problems. Giving everyone the needed level of financial support, regardless of our work or commercial productivity, would create all kinds of opportunities. This would be excellent, and it’s going to take a lot of political organizing and coalition building to get there. But I think we can take other steps toward solving the problems of open source, inside our own domain.

What if we reconsider the tools we have available, as project maintainers and contributors?

First Aid for FLOSS

One of the most promising things we’ve seen come out of these sustainability conversations is organizations like Ruby Together. They’re actively fundraising on behalf of critical projects in Ruby, and using it to pay contributors. We also see organizations focused on creating on-ramps into open source projects, like Outreachy and Open Hatch. This helps with some of the problems around contributor burnout and turnover.

In addition, more project leaders who have had commercial success are sharing what steps they’ve taken to support their work. One example is a dual-licensing model, as described by Mike Perham of Sideqik. This does require an piece of external support: GPL enforcement, without which the dual licensing model has no teeth. The Software Freedom Conservancy, which does the majority of this work, has been undertaking a major fundraising campaign in order to continue their GPL enforcement program. If you want to see the GPL remain a viable option for supporting software projects, become a member.

Reimagining FLOSS Practice

The things we’re trying now will help some projects, at least for a while, especially if everyone involved in open source is willing to put their money toward sponsorship (which assumes you have money to spend!). But what about the larger problem of a system that excels at extracting intellectual property, and doesn’t have any major levers to force those who benefit to give back?

It’s time we looked at the basic assumptions built into FLOSS practice, including the software freedoms and the OSI mission. Are these the best guiding principles for the software we want to build? Whose needs are protected, and whose are ignored? We could ask:

  • who do we want to contribute to FLOSS projects?
  • what labor is required to maintain our projects?
  • what are the requirements for the above to happen? (Sage Sharp’s talk on Maslow’s hierarchy is a good place to start understanding all the barriers that keep people from participating in open source)
  • what tools can we use to govern and support our projects, internally (like codes of conduct and mentoring programs) and externally (like licensing and community associations)?
  • how do we align internal and external needs in a way that’s supportive of all current and potential contributors?

It’s possible that the end result would look quite different than our current FLOSS practices. Will it turn out that licensing is the best way to convey the contract between the creators and users of open source work? Will we discover other kinds of community and support structures that can transform the way we handle funding and participation? Will we see changes in the social norms that shape our practice? I’m really excited to be exploring these possibilities; we still have so much to learn.

Additional reading: