Munich Open Source Strategy: Beyond the Linux Desktop

The financial case is concrete, but it needs context

Munich's projected savings are part of the argument. The city expects the infrastructure and collaboration migrations to save roughly €1.5 million or more each year. It has also described savings of about a million euros annually from a wider shift toward open-source software.

Those numbers shouldn't be treated as one tidy comparison. They may cover different scopes or projects, and the breakdown doesn't show exactly which costs are included. The useful takeaway is simpler: Munich is pitching recurring savings as a practical reason to change, not just leaning on an abstract case about software freedom.

A real business case has to include more than license fees. Migration work, training, support, security maintenance, integration changes, and the cost of running old and new systems in parallel all matter. Open-source products can reduce vendor costs that recur year after year, but they don't make operations free. The city still needs people to deploy, maintain, and secure what it runs.

In situations like this, the better comparison is total cost over a defined period - not the price you see on a renewal invoice. If lower license costs come with a bigger support burden, the switch may not save money. And if the new system is easier to adapt, can be reused elsewhere, and reduces reliance on a single supplier, the benefits can extend beyond a single budget line.

A migration can be selective without being inconsistent

A mixed environment can be the sensible end state. A city may use open-source software for project management and databases, while keeping proprietary applications where replacement would create unacceptable operational risk. That isn't really a failure of principle. It's often the only way to make the change survivable.

Munich's strategy ties open-source adoption to practical public-sector goals: budgets, reliable services, and software that can be used across the administration. That framing helps decision-makers evaluate the work. The practical differences between open-source and proprietary software are still relevant - but the final decision has to be made system by system.

The reversal was political, not proof that Linux couldn't work

After Munich's 2014 municipal election, the political context shifted. In November 2017, the council voted to return its computers to Windows, with a target year of 2020. The transition from LibreOffice to Microsoft Office took longer, and it wasn't fully completed until 2023.

Munich's chief digital officer, Laura Dornheim, has described the reversal as political rather than the result of a fundamental technical failure. She said open source in the public sector often runs into trouble when it isn't aligned with the political agenda. The previous administration's decision to return to Windows followed a change in political leadership; the source account also notes Microsoft's commitment to establish its German headquarters in Munich.

This history changes the question. "Did Linux work?" is too narrow. Even a technically workable deployment can be reversed if the coalition backing the project changes, if employees keep running into friction, or if the project isn't tied to priorities that remain important after an election.

The lesson isn't that political support can replace technical quality. It can't. The lesson is that technical quality alone doesn't make a public-sector program durable. Procurement decisions, budgets, and long-term operating models are shaped inside political institutions. If those institutions don't see a continuing reason to support the system, a functioning deployment can still be undone.

Why the current approach is less exposed to one big reversal

A full desktop migration gives opponents a single, high-profile target. It hits many users at once, and daily compatibility problems become hard to ignore. A set of smaller infrastructure changes may be less dramatic, but each one can be defended with its own cost and operational fit.

That doesn't mean politics disappears. Contracts can change, budgets can get cut, and a future administration can choose a different direction. Still, smaller projects can build evidence as they go - actual costs, service reliability, user feedback, and reuse by other departments. That evidence gives the next decision a better base than a symbolic commitment to a particular stack.

Munich's experience is a helpful reminder for anyone planning a major IT transition: track adoption and service outcomes, not only the number of machines moved. For a related look at the organizational side, see this guide to planning a sustainable software migration.

Examples include traffic analysis and municipal AI

One example is DAVe, Munich's application for documenting and analyzing traffic data. The city has used it since 2021, and Wolfsburg has adopted it too. The second deployment matters because it shows how an internal project can turn into something useful beyond the original city.

This isn't only about avoiding duplicate development. If municipalities can reuse software, they can also share practical knowledge about deployment, maintenance, and the requirements that show up in everyday use. Reuse still isn't automatic, though. A code repository doesn't guarantee that another city can install or operate the product. Documentation, governance, support expectations, and a clear maintenance plan determine whether the software is genuinely reusable.

Munich is also working on MUCGPT, a municipal AI application that helps employees handle tasks like drafting and proofreading emails. This is a practical, limited use case. It doesn't mean a language model can safely make decisions about residents or replace professional judgment. As with any AI deployment, the city still has to think about data handling, accuracy, access controls, and human review.

The city's Open Source Sabbatical program supports developers working on open-source projects. It also addresses a common weakness: organizations can rely on shared components without contributing enough to keep them healthy. Supporting the ecosystem helps ensure the tools Munich uses are maintained by more than a tiny group of overextended people.

Reuse needs coordination, not just good intentions

Dornheim has argued that matches between software developed by one city and needs in another shouldn't be left to chance. That's a practical observation. Municipal IT teams often have limited visibility into what other administrations have built, and they may not have a straightforward way to assess whether a project is suitable for reuse.

A more systematic public-sector approach could make it easier to find available software, understand its maintenance status, and identify who would actually use it. It would also clarify responsibility for security updates and what support an adopting organization should expect. Without that, public code might be available on paper but hard to trust operationally.

For municipalities, the value of shared software depends on the full lifecycle: procurement, deployment, contribution, maintenance, and eventual replacement. A digital sovereignty strategy isn't achieved just by publishing code. It depends on whether an organization can understand, run, and adapt the systems it relies on.

1. Start with a specific operational problem

Don't start with "we need to adopt open source." Start with a problem you can actually verify: rising renewal costs, limited control over data, an unsupported product, difficulty integrating systems, or software that multiple departments need.

A concrete problem makes it easier to compare options and justify time and funding. If the only goal is to change the label on a product, the effort will struggle once the initial enthusiasm fades.

2. Compare the full cost and the exit options

Build a total-cost view that includes migration, hosting, support, training, integrations, and ongoing maintenance. Compare realistic operating scenarios over several years, and include the cost of staying where you are - not only what it would cost to switch.

Then look at control. Can you export your data? Can you move to a different supplier or hosting environment? Do you have access to the code and the skills to maintain the system? Those questions apply to both proprietary and open-source software, but open source can offer more options when the organization has the capacity to use them.

3. Pilot against real workflows

A pilot has to include the integrations and users that reveal the likely failure points. Testing a project-management tool with one technically confident team won't tell you much if the intended rollout spans multiple departments with different workflows.

Set measurable criteria before the pilot starts. For example:

• Can staff complete the essential tasks without workarounds?
• Do existing documents and systems still work as expected?
• Are security, backup, and recovery requirements met?
• How much support work will the new system create?
• Does the expected cost advantage still hold after implementation costs are counted?

4. Build the political and operational coalition

A durable program needs an owner beyond the person who originally proposed it. That means pulling in IT operations, procurement, security, legal teams, service managers, and the people who actually use the software. It also means explaining the project in terms leaders can weigh: service continuity, cost control, data protection, and shared value.

Munich established an Open Source Program Office in 2024 to coordinate this work. Not every organization needs a dedicated office, but someone has to own standards, support the teams doing the work, and make decisions about whether to publish or contribute.

5. Treat maintenance as part of adoption

The initial migration is only one phase. After launch, someone has to handle upgrades, vulnerabilities, backups, incident response, and user support. If the software is shared with another city, you also need clarity on who maintains it and how contributors coordinate changes.

This is where open-source programs can get fragile. Organizations may budget for implementation and assume community support will carry the ongoing load. Sometimes that works. Often it leaves critical dependencies underfunded. A better approach is to identify the components the service depends on and decide how the organization will support them.