Increasing your organization sovereignty with open source software: a three step approach¶
open source is growing everywhere¶
Open source is rising like the wind: from its academical beginning in Berkeley and Massachusetts in the 1970s, it slowly reached mass usage in the datacenter and on consumer devices in the 2000s. Already in the 2010s, infrastructure market analysts noted that the open source licensing model was dominant in IT Infrastructure products coming to the market: easily available without central procurement, source code access to understand the internals if needed, and of course, gratis ! Today most of the open source infrastructure software is contributed by large companies, Intel, Red Hat (IBM), Google, Meta and Suse being the 2025 top five Linux kernel contributors
Now as the adage says, open source is gratis as long as your time is unlimited. Within community open source projects, someone can be surprised by the dedication of project maintainers, however there is no guarantee that a bug report will be addressed, or over the long term viability of the project. The default rule is: you have the code, but you should support the software yourself, and if you want something extra you write a patch !
This is why besides community driven open source projects enterprise open source vendors appeared in the 1990s proposing support for popular open source software. You pay a yearly fee to get access to a network of support engineers and upstream developers, who will troubleshoot and fix bugs in the open source project for you. Red Hat, Suse, Proxmox, follow this business model. These businesses usually sell a subscription which also includes an update service, where you get backported patches in a convenient way. However to comply with the GPL you are perfectly allowed to use the software without the subscription service. See What if a subscription is not renewed in the Red Hat subscription FAQ. As a concrete example in my 5 year tenure as a Red Hat Technical Account Manager I worked with Red Hat engineering to fix around 15 Linux, Kubernetes, and OpenShift bugs that my customers reported.
As it turned out that it is more difficult to make money with Enterprise open source than with proprietary software, a new model appeared in the 2000s, the open-core model, where most features of a software are gratis under an open source license and paid add-ons are offered as proprietary software. Gitlab, Kafka, Oracle VirtualBox, Visual Studio Code, are following this model. The opencore model was actually so popular, that for-fee real open source is often confused with it. For instance it is common to hear CentOS being called the open source version of Red Hat Enterprise Linux (RHEL), but this is a fallacious statement. The source code of Red Hat Enterprise Linux is very much available to Red Hat customers, you just need to activate the correct repositories in the package manager: this is where a rebuild like Rocky Linux get its source code.
And so now is a need for Sovereignty¶
Sovereignty is itself a broad concept, originating in political sciences to mean the nation-state whole control over what is happening within its frontier. The term gained in popularity in IT with the rise of public cloud computing: in its most common form sovereignty means that EU states expect their data to be hosted within EU borders, so that European data privacy and protection laws can be enforced.
With export regulations on the rise, sovereignty can have a second meaning: how much is a software infrastructure depending on export regulations from a single nation. The critical example here is the fate of the Amsterdam Trade Bank: a healthy business on its own, it went bankrupt in three weeks as its Russian ownership meant email access and cloud infrastructure where shut down abruptly following sanctions against Russia 2022.
Also hit by trade sanctions following the attempted invasion of Ukraine, the Russian Sberbank was however able to migrate 42 000 RHEL servers to their own derivative RHEL derivative on the course of two years (link in Russian), also building their own Debian based Desktop distribution in the same move.
A related concept to sovereignty in open source is Sustainability. In community based open source, there is always the risk of depending on a single project with a single maintainer, on which a large number of other software rely. This is why many organizations contribute to open source sustainability programms to avoid systemic risks. American tech giants fund the open source Security Foundation in collaboration with the White House, Japan largest industries contribute to the Civil Infrastructure Platform, and Germany backs the Sovereign Tech Fund.
a well known software risk
Evaluate the risk¶
The first we need to consider in moving following an open source Sovereign strategy is evaluate the risk: in case of a sudden export regulation change where would be my the hardest it ? The largest risk are managed services, followed by anything that is Internet exposed and needs frequent security updates, like a mail service. A lower risk is a database server, not directly exposed to the outside world, and a very low risk are shadow IT desktop tools. At the bottom is simply hardware, because although there are firmware updates, upgrade cycles for firmware are much longer.
Assess the cost and feasibility of alternatives¶
Once the risks are evaluated, we need to assess the alternatives. Alternatives to a public cloud provider are easily found, as this is a thriving business, and there is a large choice of open source virtualization software to run virtual machines on premises (from simplest to full features: libvirt, Ganeti, Proxmox VE, KubeVirt, OpenStack) To maximize sovereignty we should focus on open source products which ideally:
- have a large vendor-neutral community
- where you can find local commercial support in your area
- where there is availability of skilled professionals
The Linux kernel, Ceph, Kubernetes, PostgreSQL, the Apache http server, Debian, score all high on these criterias.
A large vendor-neutral community is useful to avoid a single copyright holder deciding a license change of the project. This has happened in the past when vendors Hashicorp, ElasticSearch, MongoDB, Redis decided to change their license to a more proprietary one. This risk is bigger if the vendor is publicly traded, as there is more pressure for a short term monetization attempt to satisfy the board.
To give examples of software deployments matching those three criterias, the TU Wien IT is running with good success a Ceph Cluster with support from croit.io, a Germany based storage specialist. For OpenStack and Kubernetes, the European based StackHPC is providing support to Datalab.
Implement¶
Although many teams (including myself) think they can implement everything on their own, it makes often sense to use external consulting to validate an install of a downloaded gratis open source product before going into production. For Ceph, OpenStack and Kubernetes, I would even go as far as to say that this should be mandatory, or you should use a ready to use opinionated distribution like OpenShift/OKD for Kubernetes and really know what you are doing. Ideally when looking for support and consulting partners, you should look into partners who have commit access to the upstream project, like the France based Freexian where all employees have the Debian Developer status. External consultants should only review and never do the software install themselves, as this would remove the sense of ownership from the admin team.
Finally the cost of migration should be taken into account: if the sovereignty risk and the cost of the software is low, a change must not be pursued above all cost. It was for instance evaluated in TU Wien that the low cost of Oracle Database University licenses does not justify a complex application migration to PostgreSQL.
To the infinite and beyond¶
Finally for very large organizations, the highest level of sovereignty is achieved when the employees themselves participate in the development of the open source software, writing code and doing code reviews. Again going back to a TU Wien example, the research data repository software InvenioRDM, is developed as an open source project co-maintained with CERN and other universities. Although ambitious, every organization betting on open source should consider giving the possibility for dedicated employees to contribute to open source projects that the organization is using.
XKCD Comics License: https://xkcd.com/license.html