More than a licence, we need to commit to a sustainable digital infrastructure.

A (very) brief history of open software movements

Both free software and opensource have had tremendous success.

Steve Klabnik has provided a great historical review of the origin of free software with Stallman’s GNU announcement in 1983. Underpinning the free software movement was a profound critique of the role that patent law and private sourcing had come to play in stifling innovation and creativity.

The copyleft principle, e.g. GPL (Source : David Ing)

Fifteen years later, just when the internet was booming, the opensource reaction was devised to allow a more permissive use of the licences. As per Eric S. Raymond:

Specifically, we have a problem with the term “free software”, itself, not the concept. I’ve become convinced that the term has to go. The problem with it is twofold. First, it’s confusing; the term “free” is very ambiguous (something the Free Software Foundation’s propaganda has to wrestle with constantly). Does “free” mean “no money charged?” or does it mean “free to be modified by anyone”, or something else? Second, the term makes a lot of corporate types nervous. While this does not intrinsically bother me in the least, we now have a pragmatic interest in converting these people rather than thumbing our noses at them. There’s now a chance we can make serious gains in the mainstream business world without compromising our ideals and commitment to technical excellence — so it’s time to reposition. We need a new and better label.

Licensing under open source permissive conditions is friendlier to private source copyrights, allowing the path to opencore business models (typically an opensource project licenced apache 2.0 + an enterprise version that brings additional paying features).

The permissive principle, e.g. apache 2.0 (Source : David Ing)

Whatever your stand on the copyleft/permissive debate, a lot has changed since 1998. Enterprise IT is mostly organized around opensource, according to a survey from Redhat. Even Microsoft has become an opensource advocate, at the same time its strategy moved from selling a closed source operating system to a more agnostic cloud infrastructure. The general trend is that permissive licences are growing faster than copy-left ones, mainly due to the fact that most of the large companies forbid the internal use of GPL and its variants.

% split between licence types (Source: WhiteSource)

VCs also are quite fond of the opensource model, as many great ventures have been built upon it:

Levine describes the current trend as an opensource renaissance. Is that so?

Open software is at a crossroads

For many reasons, the opensource model, despite its successes, is now under enormous pressure, especially due to the asymmetry between cloud players and small projects.

Critical projects require more investment

This starts as a classical free rider issue: GAFAs in particular have been criticized for they take and don’t give back. At least not enough. One large complaint has been around the critical projects such as openssl, often maintained with very limited resources. The core infrastructure initiative was created after the famous heartbleed bug illustrated the lack of resources.

What heartbleed demonstrates is that opensource software requires substantial time and effort to create and to sustain. One way to do that is with direct funding, which is why foundations exist. Another idea is for employers to redirect some time to opensource projects, as suggested by the openfriday initiative for instance.

The (partial) shift to non-OSI licences

A more recent fight has been going on between AWS (and to a lesser degree, other cloud players) and some well-known projects, such as redis and mongo. This has led to new licences, such as the BSL (Business Source Licence) introduced by MariaDB, which aren’t recognized as opensource by the OSI. The said goal of project re-licencing is to protect and expand the revenues, as they claim they don’t get their fair share from cloud platforms. In short, they feel (rightly so) that they get the recognition, but not the money.

For instance, database vendor coackroachDB has published the rationale they’ve been following for choosing a relicencing between apache 2.0 to BSL (and falls back to apache 2.0 after a few years, leaving enough time for protecting their innovation). The source code is still available for use, except if you want to directly compete by selling it as a service. The licencing issue becomes a more direct competitive argument between projects, as demonstrated by their competitor’s statement, to use an opencore model instead.

We have removed every barrier that developers face in adopting a business-critical database and operations engineers face in running a fleet of database clusters.

So opensource versus BSL puts forward very similar arguments as opensource versus closed source. Back to origins.

Making money out of opensource is fundamentally difficult

At the core of the problem, is that a successful open source project in no way guarantees a successful business model. It also means that very good projects may fail, despite their technological soundness. We owe to the projects that described their journey, such as Rudder, or made a post-mortem analysis, such as RethinkDB. As with any other business, one needs to demonstrate its added-value.

Luckily, new initiatives such as COSS make the process of commercializing opensource more mainstream. Bruce Perens has published an early draft of what he calls post-open source, which is worth looking at.

Too much falls on individual maintainers

Recent trends include the use of opensource in decentralized projects, as a medium for protocol implementations. This aligns quite well with the cultural background of blockchain ecosystems, but relies in practice on a small number of contributors. Especially the Ethereum project is well-known for organizing decisions around a small number of core developers.

More generally speaking, maintainers are strained. Two thirds of the most popular projects rely on one or two people only, meaning that most projects are limited by the so-called truck factor, which risks incapacitating parts of the IT supply chain. Worse even. More and more maintainers have official said they quit. Sometimes due to reddit uproars, or for other legitimate priorities, the fact is that we’re living a form of disenchantment.

Some have developed new sponsorships to support their work, through platforms such as patreon. But that’s only concerning a few superstars or people willing to take the risk to spend most of their time on their project, including a large part on communication around the project. However interesting that is, it doesn’t seem to solve the real issues.

The tragedy of commons is under-optimal

We actually fall into a situation well-known to economists (Nobel winner Elinor Ostrom in particular), under the label, tragedy of the commons:

For end users, Open Source projects are public goods; the shared resource is the software. But for Open Source companies, Open Source projects are common goods; the shared resource is the (potential) customer.

This means we have makers and takers, and currently no governance model able to provide the right incentives for cooperation at scale.

Makers and Takers, according to Dries Buytaert

To many developers, this doesn’t seem either fair or sustainable. If we don’t find a solution, everyone will loose.

What comes after opensource?

Behaviour is more important than copyright

And so, Steve Kabnik poses an interesting question : what comes after opensource? He posits that programmers are very much interested in the production process of software. Said differently, open sourcing is about behaviour, even more than it is about copyright. That could maybe, he argues, open the path to “Open Development Certified” programs, or even “Developer Unions”. I don’t anything of the sort just yet, but it highlight the fact that there is a need for ecosystems that foster real collaboration.

The need for a sustained digital infrastructure

Institutional support is probably critical to set incentives right. In short we need to treat opensource as a digital infrastructure. Nadia Eghbal wrote an interesting report in 2016, “Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure”, that highlights the challenges that remain true as we speak. The current pandemic crisis further demonstrates that our societies are highly dependent on internet networks and applications, both for leisure (e.g. streaming, gaming) and work (e.g. videoconferencing, telemedicine). It is the first time that we really see, at planet scale, how critical it has become to our resilience.

Addendum August 2020: “Working in Public: The Making and Maintenance of Open Source Software”, by Nadia Eghbal, provides additional insights on how opensource projects are organized.

The 4 classes of opensource projects

The digital infrastructure therefore becomes a much more strategic asset, worth being sustained and defended. In Europe in particular, the extreme dependence on foreign companies is currently scrutinized. Most services aren’t designed with security in mind, despite growing fears around cyber threats, and the debates around zoom have publicly exemplified the issues to the general public. Opensource doesn’t make software more secure in itself, but at least it avoids security by obscurity and facilitates responsible disclosure policies, as shown by Github security lab for instance. Just the fact that the code can be reviewed by independent security researchers, without the fear of legal issues, is already a big deal. My take is that companies would also greatly benefit from a more transparent approach, possibly avoiding “name and shame” (a huge reputational risk) by demonstrating a real commitment.

At the same time, the worrying surveillance trend is making opensource even more required, especially for building privacy blocks such as encryption technologies, where states themselves are likely to interfere.

The openness extends to the rest of the supplychain

The current crisis also calls for a redesign of supplychains in general, not limited to software. There’s room for open publication (especially for scientific articles), open standards, open protocols (e.g. blockchain), open data, open hardware (e.g. RISC-V), open design, and so on. That makes both the issue both more important (as it spreads to full product life cycles) and more pressing. Otherwise, the same causes will lead to the same effects.

What about large companies?

Despite being well-funded, they can’t do everything. Their shareholders actually demand a high return on investment, so it’s in their best interest to find a collaborative ground with smaller, more specialized projects, so that they don’t have to do everything by themselves.

For successful opensource projects, redis and mongo and the likes, providing infrastructure as a service, is a different business. One could argue that part of their past success is also due to the fact that cloud providers embedded their product into their offering, enabling vast network effects. Even if their own investors logically push to get a larger piece of the cake, nothing proves it will work out as they expect. In effect, re-licensing is just an individual exit game strategy and doesn’t solve the systemic issue.

On the contrary, I would argue that it opens the path to legal disputes, as everyone comes with a new licencing variant, which impacts far beyond cloud companies. Take the example of Zeebe for instance (which implements BPMN like workflows): “Users are not allowed to use Zeebe for providing a Commercial Workflow Service in the Cloud”, what the hell is that supposed to mean? Any software vendor, providing an online workflow configuration tool based on their service, would likely fall into the category, but it’s not 100% clear. Using non opensource licences increases the risk of non compliance to Yet Another Specific Licence, willingly or not. We loose all the signaling attached to well-known licence terms.

Instead of a fight over licencing, there is therefore a way forward. A partnership in which cloud vendors would pay to support the integration and maintenance of opensource into their offering. Everyone remains focused on their core business proposal. However, this remains a case by case negotiation, and the power today clearly goes to the cloud vendor.

That is why we need to institutionalize good practices.

An O-Corp movement for digital commons?

In short, I believe we need a new IP and cooperation regime. The blunt fact is that financing and re-financing is the crux of the matter. A solution will likely require:

1. public and collaborative funding for core technological assets (development but also maintenance). This is what we start to see in critical infrastructure such as energy (already well accustomed to financing physical infrastructures and networks) or with cryptofunding (like gitcoin or psfoundation) ;

2. coupled with private funding to develop products and the related business model linked to those core assets. Those companies, startups or incumbants, would be bound to partly refinance the open assets. The trust in the system could therefore be objectified with a sort of digital “credit score” (based on how much you refinance the digital infrastructure, in %).

The good news is that there’s nothing revolutionary in the approach: it already exists, when for instance, one sub-licences, non exclusively, a patent. We would have to expand it to the specific case of open licencing, in practice replacing a mere membership (to a foundation) to include success fees. The investment (and return on investment) logic easily fits into the accounting and regulatory frameworks of large companies, while ensuring a longer term partnership with innovative projects. Of course, as I’m not a legal specialist, I’m sure it would be more complex that saying it could work, there are probably many hurdles, so I’d love to discuss the idea with other people.

Participating to the commons would also make sense with regards to B-Corp movements, which already provide a legal framework that can be used directly today, in many countries. Beyond the financial commitment, it would give ground to a more general impact and community orientation. Why not an O-Corp movement, in which the participation to the open commons is a mission as meaningful as the main business objective?

To conclude, I certainly don’t think I have the solution. Those are only preliminary thoughts, which I hope other people will find useful too. I’m open to the discussion.