With an Europe that is struggling with innovation and an uncomfortable reliance on US tech, shifting towards increased open source adoption is more important than ever. For what it’s worth, The European Commission has throughout the last decade launched several Open Source Strategies, with another one in the making these days. Launching strategies is something that the EU is good at, but acting on them, well, not necessarily so much. 

As stated in this article, “Brussels hopes wider public adoption of open-source tools will replace expensive or data-extractive proprietary software, reinforcing Europe’s technological autonomy.” Nice words, but it is something with putting your money where your mouth is. When The European Commission last summer proposed a record-breaking seven-year 2 trillion euro budget to boost autonomy, competitiveness, and resilience, open source was once again barely mentioned. 

What does this seem to show us: 1. There is an ambition and willingness to transition to open source solutions, but 2. The EU doesn't really know how, have the tools to do so, or know how to put this transition into actual budget numbers. 

The community must help public institutions adopt

There are simply put, two ways to go about this for the open source community. Wait for the EU to figure out how to adopt and allocate more funds to open source software and initiatives (which can take another couple of decades), or, help them make this transition, by trying to remove the most prominent barriers and frictions for adopting Open Source Software (OSS). Of course there do exist public institutions that have the drive, competence and willingness to transfer to open source, regardless of EU, but for the masses to do so, the open source community must likely help them. 

Understanding the barriers

For individual open source projects it starts by understanding what these adoption barriers and frictions are, and how they differ from any barriers and frictions experienced among private companies. 

While a private company’s reluctance is usually rooted in competitive advantage and risk-to-revenue, a public institution’s reluctance is often more structural, rooted in procurement law, political accountability, and bureaucracy. So what does this mean more specifically? 

Public institutions operate under high levels of scrutiny and rigid legal frameworks that often make "free" software surprisingly difficult for them to adopt. Here are some of the places one runs into challenges:

• The "Accountability Gap": In the public sector, having someone to blame is a vital administrative requirement. If a proprietary system fails, there is a vendor contract and a legal entity to hold liable. With OSS, the "vendor" is often a global community, which makes assigning blame (and seeking damages) legally complex for government entities.

• Procurement and Tender Cycles: Government procurement templates are historically designed for proprietary models (e.g., asking for "cost per license"). OSS doesn't fit these forms easily. In addition, public sector budgets are often divided into CAPEX (one-time purchases) and OPEX (running costs). OSS often requires higher OPEX for maintenance and in-house staff, which is harder to get approved than a one-time license purchase.

• Legacy Systems: Governments often rely on "mission-critical" systems that are decades old. These "black box" legacy systems were designed to be proprietary, and integrating them with modern, open-source stacks can be expensive or technically impossible without specialized (and costly) talent.

• Political Risk Aversion: If a government spends millions on a known brand (like Microsoft or SAP) and it fails, the decision-maker can claim they followed industry standards. If they choose a "community project" and it fails, it is often framed by political opponents as a waste of taxpayer money on an "experimental" solution.

• Security Concerns: Worries that "open code" acts as a roadmap for hackers (often referred to as "security through obscurity") do exist. They are concerned that state actors or malicious groups will find vulnerabilities in code that is publicly viewable.

NAV (The Norwegian Labour and Welfare Administration) is often highlighted as one of the leading actors in the adoption and use of OSS among public institutions in Norway.

Which barriers can Open Source projects address directly

Many of the barriers are of course outside the areas of direct and significant influence for a specific open source project. Such as long-term legislative anchoring. The CAPEX heavy budgeting. The outdated procurement templates. The legacy systems used today. And some of the risk aversion felt by public employees and politicians. 

However, one can still try to mimic the structures of proprietary vendors, and hence remove some of the legal and financial friction that stops a public institution from saying "yes." Here are some barriers that can be addressed, and how one actually can address them.

The Liability Barrier

Public institutions often require a legal entity to be responsible if things go wrong. A project can address this by offering enterprise support contracts (“someone” to blame). Even if the code is free, the project can sell a support tier that includes a signed Service and Support Level Agreement (SLAs), including guaranteed response times. As a minimum one can have a structured on-demand support setup. An easy way to establish contact with the core team and ask questions if anything should happen. 

The Budget Barrier

As discussed, governments often have millions for "buying things" (CAPEX) but struggle to find pennies for "hiring people" (OPEX). A project can address this by packaging as a "capital asset", offering a perpetual support license or a long-term "pre-paid" maintenance package (e.g., a 5-year support deal). This SLA approach allows the institution to pay a large upfront sum from their CAPEX budget, treating the software like a one-time purchase. It may resonate better with many of the current procurement templates used within the public sector today.

The Documentation & Compliance Barrier

Public sector IT must comply with strict accessibility, security, and data privacy laws (like GDPR or Section 508). Instead of "wiki-style" docs, projects can provide documentation mapped to government frameworks (e.g., NIST in the US or BSI in Germany). Further, providing a Software Bill of Materials (SBOM) - a list of every third-party component in the code - allows government security teams to vet the project instantly for known vulnerabilities.

The Installation & Integration Barrier

Public sector IT teams are often overworked and under-trained in niche open-source stacks. Creating a "hardened" version of the software that comes with security settings (e.g., SELinux profiles, encryption-by-default) pre-configured to meet common government standards may be appreciated among some. With an SLA or a structured support setup, one could also provide a clear path to helping out with the integration through the core team or the community. Alternatively one can identify and vet local IT companies, allowing the institution to hire a local firm they already trust to handle the open-source implementation.

The Procurement Barrier  

The "Request for Proposal" (RFP) process is the graveyard of many open-source projects because they don't know how to respond to 200-page bid documents. In addition, open source projects aren’t commercial actors, and don’t necessarily actively seek users. As an alternative, the project can instead provide a "procurement toolkit" on its website - pre-written answers to common government questions about security, licensing, and data ownership. And also, remind governmental institutions about the narrative related to national security and independence, flagged by both EU and national governments. 

The Motivation for Shifting to Open Source is There

There seems to be a will, and strong geopolitical reasones for making the shift towards more open source. But it won’t happen by itself, at least not in the foreseeable future. So it will most likely be critical to help public institutions in choosing open source. The pushes are not only coming from the governmental institutions, also the Open Source Initiative is clearly making their stand by communicating the benefits of a transition towards more open source software directly to the EU commission. 

With a more conscious approach to the topic, one should encourage the open source community to help guide and facilitate for the EU, and its governmental and public institutions, in choosing open source to a larger degree in the future. Because, while the private sector makes their decisions from business strategy, speed to market, and protecting intellectual property, the public sector focuses more on laws, public opinion, and rigid budgeting. Lowering the barriers and frictions related to these elements can actually be influenced.