Not all open source is created equal

This is a guest blogpost by Marc Linster, SVP, EnterpriseDB

Open Source, Free and Open Source Software, Code Available, GNU General Public License (GPL), Berkeley Software Distribution (BSD), Business Source License (BSL) — aren’t they all the same? Why does that matter? Isn’t it all Open Source?

I often encounter these questions in discussions with CIOs, CDOs, developers and software cognoscenti. In discussions with my colleague Bruce Momjian, co-founder of the open source project postgreSQL, I have learned that the differences are substantial and meaningful. In my past life as an IT leader, I cared about virulent licenses, such as the GPL, and permissive licenses, such as BSD. But I never understood the deeper mechanisms behind the open source projects and why those structures should matter to strategic decision makers.

Many open source projects, such as MongoDB or CockroachDB, are largely driven by single commercial entities. These projects use open source licenses, such as GNU General Public License, or ‘source available’ licenses like Business Source License, that allow the users to inspect the code and potentially contribute to the code, but the majority of development is funded and driven by a single commercial entity. In these projects, there is a very limited ‘community’ effect.

Why should a CDO or CIO care? Because the companies behind those software projects fund, drive, and manage the roadmap and majority of the development, users are actually betting on these commercial entities, rather than on the community-driven open source projects. If the commercial venture fails, then the project slows (or even fails), and eventually, the project turns into a zombie. Maybe there is still some movement forward, but this certainly stifles innovation. These vendor-driven open source projects can also have cost structures that compare to old fashioned software businesses with minimal community leverage — but their markets have open source economics, with the associated price compressions and free use of the software in many scenarios, including the use by hyper cloud providers, such as AWS or Azure.

These pressures can lead to sudden changes in software license models, away from recognised open source software models to commercially optimised models. This happened to MongoDB (2018 change from GNU AGPL to Server Side Public License SSPL) and CockroachDB (2019 change from Apache 2.0 to a version of BSL for all new major releases). Users who bet on such open source software are suddenly confronted with fundamentally changed cost and license models.

Are there open source projects that are fundamentally different? Is it possible to create open source projects that are not funded and controlled by commercial entities? Linux and PostgreSQL are two examples of such projects.

PostgreSQL is driven by a loose confederation of regional PostgreSQL groups, lightly governed by a core team, whose internal rules prevent commercial entities from taking control of the project or the software. This has contributed to a collaborative innovation mechanism driven by the core team, a group of committers and a large circle of contributors. Some of these are freelancers or volunteers, and some work for companies that use PostgreSQL or provide commercial services associated with the software. It is remarkable that while many of those companies collaborate on the software, they compete in the market. Also, PostgreSQL adopted a variant of the extremely permissive and simple open source license BSD, commonly known as the PostgreSQL License. All of this ensures that no commercial entity can acquire or control PostgreSQL.

The Postgres roadmap is defined and created through a meritocracy, focused on what the contributors deem necessary and useful, and what the committers deem solid and sustainable after careful peer review. This bottom-up, grass-roots driven innovation makes sure that the roadmap focuses on useful features, immediately related to innovation needs, with minimal technology debt.

Why does this matter to a CIO or CDO? Because the roadmap is motivated by adding value and not dictated by the sales-driven commercial concerns of a single company, the rate of innovation remains high. True community-driven open source projects are a much safer bet, and likely to persist long after other ventures have succumbed to market and cost pressures.

How does a project like PostgreSQL deal with hyper cloud providers? PostgreSQL encourages collaboration and contribution, including with the hyper cloud providers. Today, many cloud providers, such as Azure, Google, or Alibaba are actively involved in the PostgreSQL community process and are making meaningful contributions.

Community-driven open source structures are the basis for lasting innovation and resilience in the face of a rapidly changing software world. Such projects create a better foundation for long-term and strategic decisions underlying digital transformations, innovative data strategies or new product developments. CIOs and CDOs who want to make long-term bets on open source need to consider more than just viral vs. non-viral licenses — they also have to make sure that the underlying operating models are resilient, vibrant, and set up to help them innovate well into the future.