Responding to @Tobie’s thread on examining open source as a commons.

In the context of digital abundance, the open source code itself can be infinitely copied.

1. open source code = public good

2. support, maintenance, etc. = common good

3. paying customers = common good (assuming multiple consultants or hosting services etc.)

From my understanding of @Dries' Makers and Takers post, the distinction between a public good which can’t be depleted and a common good which can be, and must be protected, is key.

The activity around open source code is a common good. It is provided by the maintainers and other contributors. @tobie mentions maintenance, but also documentation, marketing, communication, responding to issues, and so on.

The “consumers” of these activities may evolve into new contributors, so in one model providing this activity will grow the commons. And even the add to the public good of the code if the new contributors eventually provide code, too.

But taking time for these activities is a scarce resource, as Tobie points out. Sponsorship and similar types of funding can potentially “buy” more of a maintainer’s time, so they can provide more support for (2) – but isn’t really a business model or a commons management strategy on its own.

Finally, my third point from above. Dries made this point quite clearly: if you have multiple businesses built around an open source code base, the (paying) customers are a common good: they can (mostly) only be the customer of one business.

Approaches that restrict aspects of a project to paying users run the risk of making this no longer a common or public good, and yet Ostrom mostly proved that “good fences make good neighbours”. This is the challenge we face that @tobie highlights, and the ongoing experimental phase that I see open source at large moving into.

For a sustainable commons that goes beyond code, we need more makers than takers.