For years, a frequent response by public administrations to excessive supplier dependence (the famous vendor lock-in) has been to require that the software code they purchase be open source. It seems logical: if the code is open, dependency decreases.

However, adopting this model does not guarantee technological autonomy or automatically reduce internal maintenance effort. Therefore, rather than obsessing over Open Source, the best strategy is to identify areas of dependency and select the most appropriate tools for each case.

The Origins of the Open Source Movement

Open Source was born as an ideological reaction to closed software models concentrated around a few large vendors. Over time, it evolved from a niche alternative into standard digital infrastructure (Linux, Kubernetes, PostgreSQL, etc.).

This cultural and technological shift eventually reached public administrations, which for decades had prioritized proprietary solutions for pragmatic reasons: security, vendor support, legal liability, and stability. The unintended side effect was a growing dependence on a small group of suppliers for any system enhancement or adaptation, leaving many public organizations locked into contractual relationships that were difficult to break (vendor lock-in).

In response, several state and municipal regulations have recently tried to reverse this trend. For example, in October 2017, Barcelona approved an explicit policy for free and open-source software usage and development in its Government Measure for Open Digitalization. The city council made prioritizing the purchase of Open Source solutions and systems based on open architectures and standards a core objective. Crucially, the measure also aimed to equip the City Council with in-house technical talent and capabilities to reclaim knowledge and maintain control over digital services.

What makes these regulations compelling is that they do not focus solely on Open Source; they place equal emphasis on other key dimensions, such as investing in internal capacity and building architectures based on open standards. Yet, during implementation, attention almost always centers exclusively on whether the code is open source.

And therein lies the problem.

Focusing too heavily on whether software is Open Source can blind us to a key reality: code availability does not mean a system is designed for easy integration. Sources of dependency persist even with open-source software.

Other Sources of Dependency and How to Address Them

Determining whether a technology generates dependency relies less on whether the code is open or closed, and more on whether the system is interoperable, auditable, and portable.

• Interoperable: Systems can communicate in a structured, standardized way.
• Auditable: System behavior can be evaluated, inspected, and monitored.
• Portable: The public administration can switch vendors without rebuilding its entire infrastructure.

In many cases, the real issue lies in system architecture rather than software licensing. Without an API-first design, shared data standards, and sound tech governance backed by in-house capabilities, opening source code accomplishes very little.

Munich migrated to Linux under the LiMux project to reduce dependency, but years later reversed course and returned to Windows. The problem was not open source itself, but a lack of sufficient in-house capacity and interoperability hurdles with external systems. The license alone failed to deliver autonomy.

Conversely, Estonia built its digital government framework on X-Road, an interoperable data-exchange protocol. Not everything is open source, but the underlying architecture guarantees data control and portability. Similarly, the GTFS standard in urban mobility lets transit authorities change vendors without restructuring their underlying data. The key factor is not the software license, but control of the standard.

This is what public administrations must demand from any tech solution: open standards, well-defined APIs, and true integration capability.

Furthermore, there is an added risk: adopting Open Source software without the internal capacity to maintain it. If an administration lacks technical teams capable of auditing, modifying, and evolving the software, it remains bound to the external vendor. Dependency changes form, but never disappears.

Key Questions Before Procuring Technology

When planning software integration in public administration, asking "Is it Open Source?" matters—but key prerequisite questions must come first:

1. Is it built on open standards?
2. Does it allow us to switch providers without overhauling the system?
3. Does it simplify data exchange with other internal systems or government agencies?
4. Is there a viable long-term strategy for maintenance and evolution?

Open Source is an excellent model, but it is a means, not an end. The ultimate goal is a public administration that owns its processes and data, fully capable of replacing a technology partner without compromising public service delivery. True autonomy comes from modular architectures built on open standards and backed by well-supported, capable public teams.

‍