Open code for closed services: The Open Source paradox of the cloud

In recent years, several high-profile, single-vendor Open Source projects made the news by switching to more restrictive licenses. Some saw this as a manifestation of evil and greed, questioning the single-vendor model entirely; others interpreted it as a sign of the growing economic unsustainability of Open Source in the current market structure. Both arguments have some merit but fail to consider external conditions.

Open Source software has become the backbone of critical infrastructure across society – from our economy and cultural platforms to national defense. As a result, there’s a growing expectation that all parts of the Open Source community need to adopt more professional approaches to code development and management. New regulations such as the EU’s Cyber Resilience Act are increasing the push for projects to morph into commercial single-vendor ones, as a way to find stable money streams for quality assurance, security and documentation. This change is generally done in good faith and has no more likelihood of going awry than non-profit benevolent dictatorships. Luckily, if trust becomes an issue, community-driven forking serves as a practical solution in both scenarios.

At Open-Xchange, we develop widely used free software like Dovecot and PowerDNS, employing several dedicated people that can only be maintained through significant revenues. Starting from the on-premise deployment market, we originally built those revenues through an open-core model, allowing us to keep most of the codebase free while monetizing extensions, customization and necessary management systems only for large commercial deployments. Still, some people consider even the open-core model as “impure.” As the market moves to the cloud, companies like Open-Xchange are often told that they should free all code and only sell cloud services based on it. That model, however, is exactly what led other firms to take a step back and renounce their open licenses because of a fundamental problem: the cloud market is neither fair nor free.

Photo by Stock Birken on Unsplash

As Open Source developers and as citizens, we now live under the dominance of a few big tech companies that have managed to amass an amount of money never seen before in private hands. Large tech companies have a significant advantage. They can leverage a small portion of their vast resources to undercut the cloud services or directly copy the software of any Open Source competitor, regardless of size, effectively killing it. The irony is that these companies leverage the open nature of our software to create closed-off, controlled ecosystems. These walled gardens often rely on tracking and profiting from user data. This approach fragments the internet and concentrates power in the hands of a few companies, potentially limiting future innovation and user choice.

Today’s browsers and mobile OSes are yesterday’s Windows, yet the reaction that our community had in the 90s against Microsoft’s restrictive practices is nowhere to be seen against the restrictive practices of today. Today’s monopolists often become the keynote speakers, funders and thought leaders of our activities. We often seem too focused on the openness of the code to care about the openness of the Internet and of the digital society in general.

Photo by Reuben Farrugia on Unsplash

We know how to keep code free, but we don’t know how to deal with big tech dominance and their exploitation of open source as a major building block to enclose and erode the openness and plurality of our digital infrastructure and society. If we cannot address this problem, we will continue quarreling on commercial versus non-profit funding models while the Internet around us will die.

This article is part of our series on Practical Open Source (POSI) program. POSI aims facilitate the discussions about doing business with and for Open Source. The 2024 edition consists of blog posts on and a panel at All Things Open in October. More details and how to pitch on the POSI 2024 page.

Source of this article:

Leave a Comment