Sustaining Open Source Software

In my last post, I rebutted the dangerous thought that in economic terms an open source project is a ‘public good’.

History has already shown us this is an expensive mistake to make. We must consider both the community and the code as one. That — in turn — forces us to think more generally about the sustainability of the community, and the sustainability of the project as a whole.

When we talk about sustainability, we’re talking about the project’s capability to withstand changes. For me this is about the fluctuations in a project’s resources, and how that balances against a project’s pressures.

For infrastructure-type projects, I believe there are four relevant resources: computing, storage, messaging and time.

The first three are commoditisable resources. Providing them at scale for all infrastructure projects is not cheap, but it is possible.

It’s “time” we need to focus on.

Time is the currency of an open source project.

And why do we need time? Because software doesn’t exist in isolation.

As the frequency and complexity of software increases, Lehman’s laws of software evolution come to bear upon most projects. This means that some people — and sometimes just one person — need to put in a constant effort to maintain and satisfy the user base. Dependencies must be updated, security vulnerabilities fixed, and support for new platforms added.

If time is the currency, can we lower the capital required?

We can.

We can explore the options, think deeply about the choices that have to be made in the lifecycle of an open source project, publish guidance and spread it as widely as possible.

We can build tools to automate a project’s workflow and offer them for free on top of our commoditised stack. But to progress, we’re still going to need a source of maintainer time, which means money.

And here’s the thing: Money often comes with influence and incentives.

How can projects make money?

Here’s where our “public good” definition becomes useful. With “public goods”, trade-offs must be made to maintain the whole. These trade-offs will be between the benefit for one consumer versus the benefit for all other consumers.

It also provides us with the two conditions to tweak the dials on: exclusivity and rivalry.

We can introduce exclusiveness by dual-licensing, embargoing new features, removing licence restrictions or segmenting code entirely.

We can use rivalry within the community to encourage consulting, support or bespoke development. Finally, we can use both forces within a hosted, productised service.

These ideas cut through the free-rider problem. But they come with their own challenges neatly enumerated by Nadia here. Many cut straight through the philosophy of open source, but they can work if the influences and incentives are mitigated by using a range of these methods, by balancing incentives against one another.

But can we do better? Can we get the benefits for all without the trade offs for some?