Three ways to improve the sustainability of open source projects

Open source software has been astoundingly successful. Today, it is the basis upon which much of our technology is built, technology that keeps us warm, safe, and happy. Open source projects enable young developers to learn from veterans and entrepreneurs to build million-dollar companies in the space of months.

As great as open source is, we need to be looking out for its future.

There is a fundamental risk to the sustainability of open source. The value exchange between the users and the creators of open source projects is not always equal. Users of open source benefit significantly by being able to build on top of open source components, saving time and money.

And while it’s difficult to categorically say that open source projects have fewer significant contributors and supporters today than they did ten or fifteen years ago, it anecdotally feels like that is often the case.

Nadia Eghbal’s seminal Ford Foundation-sponsored study Road and Bridges provided us countless examples, as did the first Sustain OSS workshop, held in June 2017 and attended by over 100 people concerned about the future sustainability of open source.

So what can we do today to ensure that open source projects continue to be supported by the joyful, harmonious, and respectful group of contributors and supporters we would all love to see? And how can we ensure we are cultivating the contributors of the future?

Here are three simple tips from the Sustain OSS workshop:

Remember that it’s free software, and set expectations accordingly

For users, we should start by remembering there are no guarantees or warranties in open source software. We risk burning out maintainers when we place the same expectations on them that we put on those who get paid for creating software.

For maintainers, we should accept that releasing software into the world does not bind you to it forever. We can establish a new norm in which maintainers decide how, whom, and when to engage. Maintainers need to be clear about where those boundaries lie, and we should respect them.

Optimise for n+1 maintainers

Reciprocally, maintainers need to recognise that they often build processes into their projects that establish themselves as the central authority. This creates a bottleneck.

When it comes to new contributors, maintainers can lower barriers to entry by being a little more forgiving in the first instance, focusing on the motivations behind the contribution, not the content. They can then create an on-ramp or funnel to give those contributors an increasing amount of responsibility until they are experienced enough to become a maintainer of the project.

A common—though not categorically recommended—approach to this is to be freer with rights to commit to a project, in order to distribute the workload of reviewing and merging in other contributions.

Make it not just about code

Code is often the central theme of a project’s governance model (explicitly or implicitly). But projects are the culmination of expertly executed guidance, process, documentation, illustration, and design.

The folks behind these kinds of non-code contributions have exactly the same motivations as developers contributing code. Welcome them for a new perspective, a more diverse range of opinions, and a happier group of people. The Open Source Design project has some great resources on creating an environment for designers to contribute. That’s a good place to start.

A SLA, a contributor funnel, and a HR policy? This is starting to sound not entirely dissimilar to a business. And you’d be right. Open source is more successful than any one single commercial technology company. And if business is going to take the best of open source and build upon it then open source should take the best of business and build upon that too.

Want to learn more about how to make open source more sustainable? If so, consider signing up for updates or following us on Twitter.