SustainOSS 2017: The Report

On June 19th, 2017, one hundred people gathered in San Francisco to create a cultural shift in how we think about the sustainability of open source software.

Open Collective was one of the organizers and today we’d like to share with you this report that is the result of those conversations, workshops, proposals, discussions and thousands of post-it notes everywhere!

You’ll find the full document here — authored by Ben Nickolls based on the outputs generated by everyone on the day — and we recommend reading it in full. But for convenience, we’ve made a short version below, highlighting the key recommendations.

Context

The first thing to note is that the event introduced a new actor into the open source ecosystem. The sustainers joined the maintainers (who manage contributions and take responsibility for the quality and governance of their projects), contributors (who contribute their time and experience to a project) and consumers or users (who utilize a project to achieve their own goals.)

We defined sustainers as those individuals or organizations who are concerned with the fragile state and future of highly-used and impactful open source projects.

Giving sustainers a name emphasizes the importance of sustaining open source and enables the larger community to create events for them; do research on why and how they do what they do; and provide them with the necessary resources to be successful. It gives sustaining open source an entity.

Recommendations in this report are made for all actors in the ecosystem.

Flying quickly over the context, two main things can be highlighted. First, the imbalance between users and contributors growth is shifting the egalitarian nature of the ecosystem, and contributors are overwhelmed by demands from commercial users and less supported by peers. On top of this, the proliferation of projects that solve increasingly niche problems results in code contributions having less impact on the reputations of the contributors which makes the time spent in open source less financially rewarding.

So, what are we talking about when we talk about sustainability?

When we talk about sustainability, we are talking both and equally about the sustainability of resources and the sustainability of its people.

Key Recommendations

Create sustainable communities

The community of contributors and maintainers is central to the ability of an open source project to serve its users. For an open source project to become a healthy environment that doesn’t lead to maintainer burnout or become a burden for a very small group of people, it must put the needs of these communities first.

Free the maintainer

Many users of OSS rarely consider the needs of the community behind a project. This is understandable given that the norms established around software development and licensing have put the needs of users first. We should work to establish a new social norm that frees maintainers from the enormous weight of the responsibility that they feel to sustain a project so many users rely on. Developing and releasing software into the world does not bind them to it forever. Maintainers should have the freedom to choose how they will engage with contributors, whom they chose to engage with and, most importantly, when they will engage with a project themselves.

Optimize project governance for contribution and retention

Reciprocally, maintainers should acknowledge that they often design practices and processes that put themselves at the center of a project. Project maintainers often react to the influx of activity on a successful project by aligning practices to suit their needs. As a consequence, they raise the barrier of entry for new or novice contributors in order to reduce the workload of existing maintainers. While this makes sense from the perspective of optimizing for less maintainer workload, maintainers must recognize that centralization of responsibility results in more pressure on fewer people, leading to fatigue and eventual burnout. Instead we need to create and promote best practices projects that support new contributors and create a path for them to take a greater part in the decision making and direction of the project over time.

Raise the value of non-code contributions

The production of OSS deals almost exclusively with writing code. Consequently, the developer is often the sole focus of a project and code contributions are valued more than other types of contributions (documentation, community guidance, on-boarding, etc.). Engineers therefore become the decision makers. They build the structures, processes and norms around the production of code which can neglect the needs of other types of contributors. Recognizing and elevating the contribution of all participants in a project will legitimize their concerns, raise their profile, leverage the same motivations that lead to developers to contribute and create stronger software that is the product of a more diverse range of perspectives and skills.

Commit to the commit

Open source contributions are often made on the basis of immediate and individual needs. Little thought is given to the long term maintenance these contributions require. Contributors should recognize this and accept a degree of responsibility for the maintenance of their contributions as long as they are in use. In exchange, maintainers should provide a clear way for contributors to accept this responsibility and engage with the community to do so.

Use money as an incentive for open source

There is a polarizing reaction to money within an open source project, specifically with regards to paying for a contributor’s time. This perception is damaging to projects that lack some of the other traits that motivate contributors to engage with a project, including many mature, well-used, ‘infrastructure-type’ projects. Removing the cultural aversion to money in open source can enable code contributors to keep building software while incentivizing others to take on other equally important but less implicitly rewarding tasks like resolving issues and bug triaging. By sharing guidance on how to manage money as an incentive, we can provide a stable foundation of support while enabling contributors and maintainers to continue to build value within projects.

Recognize, value and invest in OSS

The support networks that currently exist for open source are severely limited because companies do not contribute financially to projects. Many companies fail to recognize the value that building upon open source software adds to their bottom line. And those who do acknowledge the value open source brings to their products, find it very difficult to account for that value and are unable to justify any meaningful investment in it. Projects work around company policies to create ways in which support can be provided. Largely these come from marketing activities: event or site sponsorships that may distract from the goals of a project itself, or hiring engineers to work on those projects, which often brings conflicts when prioritizing milestones.

The open source ecosystem will not be sustained for the future unless projects, supporting organizations and companies work together to create a sustainable, influence-free source of finance to maintain their shared digital infrastructure.

Lower barriers for open source projects to manage finances

Open source communities are organic, disperse and loosely associated groups of contributors and maintainers that do not align with any territorial, legal or financial boundary. This means that even when projects have the financial support and governance processes necessary to pay for contributor’s time, they must still navigate barriers around corporate structure, banking and employment law. We need to create institutions and organizations that will abstract and insulate projects from these burdens, allowing projects to accumulate and distribute funds as they see fit.

Prepare maintainers for a sustainable future

We must prepare maintainers today for the future that we wish to see tomorrow. They will need to model incomes, costs and make appropriate budgetary decisions. They will need to negotiate agreements on behalf of their community. They may even need to defend their projects legally.

We must prepare maintainers for the business of open source.

Last words:

The first Sustain event was a resounding success. Over 100 participants came together to learn, to share and to explore the key issues surrounding the sustainability of OSS. Together we framed a lot of the concerns and challenges in a way that participants can take to their friends, colleagues and employers. We also saw a number of participants sharing their experiences, mapping the route to solving some of these problems and the current solutions that they have employed successfully to solve them. Many of the key recommendations stem from these experiences.

We are already working toward holding a second event in 2018, either on the east coast of the US or Europe and we look forward to welcoming participants back to share what they have learned and to continue pushing toward a more sustainable future for OSS.

Join here for SustainOSS 2018 convos!

If you’d like to make your own analysis, here is the raw data from the event as well as the post-its. Please share with us if you do. ❤

To the participants and sponsors of Sustain and to every contributor to open source software, we thank you.

The Sustainers.

Acknowledgments

Report team: Ben Nickolls (Author), Pia Mancini (Data wrangler, editor), Justin Dorfman (Data wrangler, editor), Robert Gibb (Editor)

Event organizers: Chad Whitacre, Pia Mancini, Justin Dorfman

Special thanks: Brandon Keepers at GitHub, Nadia Eghbal at GitHub, Allen “Gunner” Gunn at Aspiration and Jerod Santo and Adam Stacoviak at Changelog.

Event Sponsors: GitHub, StackPath, 8th Light, Waffle.io, JS Foundation, Iron.io, Core Infrastructure Initiative (Linux Foundation), Google Open Source, Alfred P . Sloan Foundation, Lawrence Livermore National Laboratory, Aspiration, Open Collective, Sticker Mule, Unixstickers, Gratipay, Changelog, Maintainer Mountaineer