The Dutch Government Is Replacing Microsoft With NixOS. Every Previous Government Linux Migration Failed. Here Is Why This One Might Not.

The Dutch Government Is Replacing Microsoft With NixOS. Every Previous Government Linux Migration Failed. Here Is Why This One Might Not.

On September 25, 2026, a story crept to the top of Hacker News with 567 points: the Dutch government is building DAWO — Digitaal Autonome Werkomgeving Overheid, roughly “Digitally Autonomous Government Workspace” — using NixOS as its operating system foundation. The discussion thread ran to 308 comments. Most of the commentary fell into two predictable camps: cheerleading for open-source sovereignty and cynical dismissal based on thirty years of failed government Linux migrations.

Both camps are wrong in interesting ways, and the reason why is entirely architectural. I’ve been running NixOS on production infrastructure since 2022, I watched Munich’s LiMux project collapse from the outside while consulting for a European logistics firm that was also considering a Linux migration at the time, and I’ve thought a lot about why governments keep failing at this. The Dutch DAWO project is doing something structurally different. That doesn’t guarantee success. But the failure mode this time, if it fails, will be different from every previous failure — and that distinction matters more than most coverage acknowledges.

Why Every Previous Government Linux Migration Failed (The Actual Reasons)

The Munich LiMux project is the canonical cautionary tale. Munich started migrating 14,800 city employee computers to Linux in 2003. By 2014, over 80% of workstations ran LiMux. By 2017, the city council voted to migrate back to Windows. The official reasons cited were “compatibility issues” and “user complaints.” The real reasons were more specific and more instructive.

The first failure mode was configuration drift. In a traditional Linux deployment, each machine accumulates configuration changes over time. An administrator tweaks a setting here, installs a package there, adds a local workaround for a specific user’s needs. After eighteen months, the machine that was installed from an identical image bears only superficial resemblance to every other machine. This isn’t unique to Linux — Windows installations drift too — but the enterprise Windows ecosystem has mature tooling (Group Policy, SCCM, Intune) built over decades specifically to fight this drift. Linux didn’t.

The second failure mode was the update consistency problem. Security patches arrive continuously. Applying them consistently across thousands of machines, testing that they don’t break anything, and rolling them back when they do — this is unglamorous operational work that is genuinely hard. On traditional Linux distributions, a kernel update requires rebuilding a dependency tree that you discover is inconsistent in ways the package manager didn’t catch at install time. I watched a Debian-based government deployment in 2021 where a glibc update caused silent failures in a critical document processing pipeline. It took three weeks to diagnose because the failure wasn’t uniform across all machines — some had already received the update, some hadn’t, and the divergence was invisible from any central management console.

The third failure mode was rollback impossibility. When something breaks on Windows in an enterprise environment, there are established procedures: restore from backup, use System Restore, reimage from a known-good snapshot. These procedures are documented, tested, and understood by the IT staff that enterprise organizations hire. On traditional Linux, rolling back a package update is technically possible but practically tortuous. You’re fighting against the stateful nature of a system that has accumulated months of changes and expects everything to be consistent at a point in time that no longer exists cleanly.

The fourth failure mode — and the one that actually killed LiMux — was the application compatibility layer. When 14,800 employees run LibreOffice and their external collaborators send Microsoft Office files with tracked changes, embedded macros, and complex formatting, the compatibility layer takes constant abuse. Each incompatibility is small. Each workaround is reasonable. After a few years, the accumulated weight of ten thousand small incompatibilities is unbearable. This isn’t a solvable problem at the OS level. It’s an ecosystem network effect problem, and no Linux migration has ever cleanly solved it.

Understanding these four failure modes precisely is what makes DAWO interesting. NixOS directly addresses three of them. The fourth — application compatibility — it does not solve, and the Dutch government’s approach to that problem is where this gets genuinely complicated.

What NixOS Actually Is (And Why It’s Different From “Linux But Different”)

The HN thread contained this comment: “why not just use linux?” This question, asked without irony, reveals a fundamental misunderstanding that pervades most coverage of NixOS. NixOS is Linux — it runs the Linux kernel. What it changes is everything else about how the system is managed.

NixOS uses a functional package manager called Nix that treats every package installation as a pure function. Given the same inputs — source code, build flags, dependency hashes — you always get the same output. This output is stored in the Nix store at a path that includes a cryptographic hash of everything that went into building it: /nix/store/7n9i4cxscxnn55m9drxhf1hy0hh3iifm-firefox-127.0/. Two machines that install Firefox 127.0 with identical configurations will have that package at the same hash path. This is not a convention. It is enforced by the build system.

The system configuration lives in one or a few declarative files, typically /etc/nixos/configuration.nix. This file is not documentation describing what you did to set up the system. It is the complete specification from which the system’s current state is derived. If you delete the file and rebuild from scratch using it, you get the same system. This property is called reproducibility, and it sounds academic until you consider what it means operationally for configuration drift: there is no configuration drift. The system’s state is always derivable from the configuration file. Drift is architecturally impossible because state that isn’t declared in the configuration doesn’t persist across rebuilds.

Updates in NixOS work through generations. When you apply a change — update a package, change a configuration option — NixOS builds a new generation of your system and activates it. The previous generation remains intact. Rollback to the previous generation is a single command: nixos-rebuild switch --rollback. At boot time, you can select any previous generation from the bootloader menu. This isn’t a snapshot mechanism with all the space and performance overhead snapshots imply. Because Nix packages are immutable and identified by content hash, multiple generations share the vast majority of their storage — the changed packages take up space, unchanged packages don’t need to be duplicated.

For a government IT department managing thousands of machines, these properties translate directly into operational capability. A security patch for OpenSSL can be tested in a staging environment, validated, and deployed to production with the guarantee that what was tested is what got deployed. If the patch causes problems, rollback is uniform and reliable. Configuration drift — the bane of every large-scale Linux deployment I’ve encountered — is eliminated by construction.

What DAWO Actually Builds

The DAWO project, based at code.overheid.nl/MinBZK/DAWO-NixOS with community collaboration on Codeberg, is building a NixOS-based desktop environment for Dutch government employees. The stated goals are five: digital autonomy (reducing dependency on US cloud providers), improved collaboration between government agencies, security and data protection, innovation in government workflows, and auditability of IT systems.

The auditability goal is where NixOS is uniquely powerful in ways that traditional Linux distributions cannot match. In a conventional enterprise Linux deployment, an auditor asking “what software is running on this machine and how was it built?” receives either a package list from the package manager — which doesn’t tell you whether the binaries were tampered with after installation — or a complex audit trail that assumes you’ve been logging everything and nothing has gone wrong. With NixOS, the cryptographic hash in every package path is a verifiable proof of provenance. The running system can be verified against the configuration that produced it. This matters for government compliance in ways that are hard to overstate: regulators increasingly want not just “what are you running” but “can you prove it is what you say it is.”

France’s government has been running parallel experiments. The French government’s cloud team has published Securix (a hardened NixOS variant) and Bureautix-example (an office desktop configuration built on Securix). The Securix documentation is written in both English and French — a detail that came up in the HN thread and is worth noting because it reflects a genuine commitment to making these tools available across European governments rather than keeping them in a French-only silo.

Germany has been slower. The LiMux disaster left institutional scars that make German government IT departments deeply risk-averse about Linux migrations. openDesk, the German government’s open-source office suite initiative, is progressing but doesn’t address the OS layer in the way DAWO does. This fragmentation across European governments — each running their own NixOS experiment rather than coordinating on a shared base — is the legitimate criticism in the HN thread, and it’s worth taking seriously.

The Three Problems DAWO Doesn’t Solve

I want to be precise about what NixOS doesn’t fix, because the architecture enthusiasm in the HN thread sometimes glosses over these.

The first unsolved problem is MDM and policy enforcement at scale. Windows’ Group Policy has been developed over twenty-five years. It can enforce hundreds of specific behaviors: require screen lock after N minutes, prevent USB storage, mandate specific proxy settings, block specific application categories. NixOS can achieve similar outcomes through configuration, and the DAWO project is exploring Osquery for endpoint visibility (visible in their issue tracker). But the tooling ecosystem for NixOS enterprise management is not mature. If you’re managing 50,000 government workstations and need to push a policy change to all of them within four hours because of a security incident, the NixOS toolchain is workable but the established playbooks don’t exist yet.

The second unsolved problem is the application compatibility layer that killed LiMux. This is the most significant structural risk in DAWO. Dutch government employees collaborate extensively with external parties — EU institutions, contractors, international organizations, citizens — who send Microsoft Office files. LibreOffice has improved dramatically since the LiMux era, but complex Excel workbooks with VBA macros, heavily formatted Word documents with tracked changes from multiple reviewers, and PowerPoint presentations with embedded media still don’t render identically. NixOS can make LibreOffice installations perfectly reproducible across all government machines. It cannot make LibreOffice parse Microsoft’s binary formats with 100% fidelity. The DAWO team is exploring alternatives including “Mijn Bureau,” a web-based office suite, but as of now this remains an open problem.

The third unsolved problem is training and change management. The HN commenter who observed that “this thread is hopelessly tone-deaf to non-technical people’s experience” has a point. A 58-year-old civil servant who has used Windows for twenty years, who navigates her daily work through muscle memory for specific menu locations and keyboard shortcuts, will find the transition to a NixOS desktop disorienting regardless of how elegantly the system was built. This is not a technical problem. It is a human factors problem, and it requires investment in training, support, and leadership commitment that no amount of declarative configuration solves.

The Structural Case for Why This Attempt Is Different

Given those three unsolved problems, why do I think DAWO has better odds than LiMux? Four reasons.

First, the timing is different. In 2003 when Munich started LiMux, web-based applications were immature. The entire logic of enterprise computing assumed native Windows applications as the primary work surface. In 2026, a Dutch government employee can do most of their daily work in a browser — the government portal, EU systems, most internal tools — and “native application” increasingly means a web application wrapped in Electron or a Progressive Web App. The application compatibility surface that LiMux had to solve is significantly smaller in 2026 than it was in 2003.

Second, the geopolitical context is materially different. LiMux was a cost-cutting measure and an ideological statement about open source. DAWO is a sovereignty project in the context of the Trump administration’s systematic pressure on European governments to accept US surveillance tools as preconditions of diplomatic cooperation. When the US government is actively leveraging software market position as geopolitical leverage — which is now documented across multiple European capitals — the political will to endure transition pain is categorically different. In my experience advising organizations on technology decisions, political will is the variable that most determines whether a migration succeeds or gets abandoned. Munich abandoned LiMux partly because the political will evaporated when the project ran into friction. DAWO’s political will is rooted in something more durable.

Third, the community model is different. DAWO is building in the open, in collaboration with French government initiatives, with the explicit goal of creating a reusable blueprint. The fact that France’s Securix and the Netherlands’ DAWO-NixOS are separate projects is a weakness, but the fact that both exist, are open source, and are watching each other’s approaches is a strength. The network effects of multiple governments contributing to overlapping NixOS tooling gradually produce something more robust than any single government could build alone.

Fourth — and this is the NixOS-specific argument — the failure mode is recoverable. One of the things that killed LiMux was that once configuration drift accumulated, there was no clean path back. Systems had diverged enough from their installation images that a true reset was impractical; instead you got increasingly expensive remediation work on increasingly divergent machines until someone decided it was cheaper to reimage everything with Windows. NixOS generations mean that if DAWO deploys a change that breaks something, they can roll every machine in the fleet back to the previous known-good state in minutes. This completely changes the risk calculus for trying things. You can be more aggressive about testing new configurations because the cost of being wrong is low.

The Comparison: Previous Government Linux Migrations

The French Gendarmerie migration — which HN commenters rarely bring up — is instructive precisely because it succeeded. The Gendarmerie approach was methodical: they identified the specific application requirements of each role, replaced Windows-only applications with cross-platform alternatives before migrating the OS, ran mixed Windows/Linux environments during the transition period, and invested heavily in internal training capacity. By 2014 they had 72,000 machines on Ubuntu with an estimated savings of €2 million per year on Microsoft licensing. The lesson isn’t “Linux migrations succeed” — it’s “migrations succeed when you solve the application problem before you solve the OS problem.” DAWO’s development of “Mijn Bureau” before completing the OS migration suggests they’ve internalized this lesson.

The Geopolitical Dimension That Technical Coverage Misses

I want to be direct about something the engineering-focused HN discussion largely avoided: DAWO is happening because European governments have concluded that their reliance on US technology infrastructure is a sovereign risk, and that risk assessment changed materially in 2025.

The mechanisms of leverage are documented. The US CLOUD Act allows US law enforcement to compel US technology companies to produce data stored on European servers, regardless of European data protection law. Microsoft, Google, and Amazon all operate under US jurisdiction. In the current geopolitical environment — where the Trump administration has used trade and security relationships as explicit leverage in technology policy negotiations with European governments — the dependency on US cloud infrastructure isn’t just a privacy concern. It’s a policy autonomy concern.

I’ve seen this play out in procurement decisions I’ve been adjacent to. In 2024, a European government agency I was advising on infrastructure decided not to migrate a particular workload to AWS because their legal team concluded that the CLOUD Act exposure was unacceptable for the sensitivity of the data involved. Two years earlier, the same legal team would have cleared that migration without serious concern. The threat model changed.

NixOS doesn’t solve data sovereignty by itself. You can run NixOS on servers that are still hosted in US-jurisdiction cloud environments. But the combination of NixOS-based workstations, European-jurisdiction hosting (which the DAWO blueprint explicitly addresses in its cloud components), and open-source software whose code can be audited by European agencies is a coherent sovereignty architecture. The individual components aren’t new. Assembling them into a government-grade deployment blueprint is what DAWO is doing.

What I’m Watching For

The DAWO project will be a meaningful data point for whether NixOS’s architectural properties translate into operational advantages at government scale. The things I’m watching:

The office suite problem. If DAWO deploys to a significant pilot group — say 500 employees in a ministry that has heavy external collaboration requirements — and the LibreOffice/Mijn Bureau compatibility story holds up for six months without the accumulated friction that killed LiMux, that will be genuinely significant. If they quietly extend the migration timeline because the file compatibility issues are worse than expected, that will confirm the LiMux lesson one more time.

The MDM toolchain. The DAWO issue tracker discussion around Osquery for policy enforcement is nascent. By mid-2027, I expect either a credible NixOS-native MDM story has emerged from the community — possibly built partly by DAWO itself — or the project has compromised by adopting a third-party Linux MDM tool with the attendant complexity. Either outcome is informative.

The inter-government coordination story. France’s Securix and the Netherlands’ DAWO are currently separate. If there’s a formal collaboration agreement that produces shared infrastructure — shared build caches, shared security patching pipelines, shared package maintenance — within the next eighteen months, the European government NixOS ecosystem becomes significantly more robust. If each country continues building its own independent stack, the maintenance burden will eventually exceed what each individual government can sustain.

The Germany variable. Germany is the largest EU government IT environment and has the deepest Microsoft dependency of any major European government. If the German government doesn’t join this ecosystem, the network effects are limited. If Germany joins — even in an observer capacity with a small pilot — the resources flowing into the shared infrastructure would change the viability calculus substantially.

The Engineering Argument for NixOS at Scale

Let me make the engineering case as precisely as I can, because I think it’s underarticulated in most coverage.

A government IT department managing 50,000 workstations on traditional Linux faces something I call the “known-good problem”: at any given moment, you have limited confidence that the machines in your fleet are running what you think they’re running. Configuration drift is real, and it accumulates through legitimate channels — a local administrator installs a package to debug an issue, a user installs a browser extension that modifies system behavior, an automated update changes a dependency version — not through malice. The consequence is that when you need to investigate a security incident, you’re working against a background of uncertainty about what “normal” actually looks like.

NixOS’s cryptographic provenance model means you can have genuine confidence about what’s running. Every package on every machine is either in the declared configuration — and therefore has a known hash that can be verified — or it isn’t. There’s no middle ground. An audit query that asks “does any machine in our fleet have this specific version of curl running outside of the declared configuration?” is answerable with certainty on NixOS. On traditional Linux, that question requires heuristics and incomplete logs.

For security-conscious government environments — and in 2026, all government environments should be security-conscious — this isn’t an abstract property. Supply chain attacks, the class of attack that the SolarWinds compromise demonstrated at government scale in 2020, work by inserting malicious code into software that trusted systems then install and run. A NixOS environment where every package is verified against a known hash, where the configuration is declarative and auditable, and where any deviation from the declared state is structurally impossible is meaningfully harder to compromise via supply chain attack than a traditional Linux deployment. Not immune. Harder.

My Position

The reflexive cynicism about government Linux migrations is understandable given the history. But it applies to the wrong thing. The failure modes of LiMux and similar projects were real, and they were structural — they weren’t caused by insufficient political will or insufficient funding. They were caused by properties of traditional Linux distributions that made maintaining a large fleet of machines reliably inconsistent and making configuration changes confidently impossible.

NixOS changes the structural properties. Configuration drift is eliminated. Rollback is reliable and uniform. Provenance is cryptographically verifiable. These aren’t marketing claims — they’re architectural properties that emerge from the functional package management model that Nix has been building toward for twenty years.

The things that could still kill DAWO are the things NixOS doesn’t fix: the office compatibility layer, the MDM toolchain maturity, and the training and change management required to migrate non-technical civil servants. These are real risks. The Dutch government is going into this with more awareness of these risks than Munich went into LiMux, and the DAWO blueprint suggests they’re trying to address them methodically. Whether they succeed is an empirical question that will be answered over the next three years.

I’ll say this: the first time I watched a NixOS system rollback from a bad configuration with a single command while a traditional Linux system in the adjacent rack required three hours of manual remediation, I understood viscerally why the architecture matters. Multiply that by 50,000 government workstations and multiple years of operation, and the reliability advantage is substantial. The Dutch government isn’t betting on ideology. It’s betting on an architecture with properties that meaningfully reduce operational risk at scale. That’s a reasonable bet.

Falsifiable Predictions

By the end of 2027: The DAWO project will have completed a pilot deployment of at least 1,000 workstations in at least two Dutch government ministries. The pilot will surface significant office compatibility friction — I estimate a 70% probability that LibreOffice file fidelity issues require at least one extension of the pilot timeline. France’s Securix and the Netherlands’ DAWO-NixOS will either have formal collaboration infrastructure (shared build caches, coordinated security patching) or one of the projects will have quietly deprioritized OS-level work in favor of application-layer alternatives. By the end of 2028, if DAWO reaches 10,000+ active workstations without reversal, it will be recognized as the first large-scale European government Linux migration that structurally succeeded — not just politically endured. Germany will not have joined a shared European government NixOS ecosystem by the end of 2027; the institutional inertia is too large and the Microsoft relationship too embedded. I’ll revisit this in 2028.

The NixOS Developer Experience Problem and Why It Doesn’t Disqualify Government Use

The HN thread contained a lengthy comment from a developer who found NixOS “annoying” — he objected to the Nix language, the hashed store paths, the systemd dependency, and the restrictions on his preferred debugging workflows. This is a legitimate perspective from a developer who wants to customize a system extensively. It is not the relevant perspective for a government workstation deployment.

Government IT deployments are not designed for developer customization. They are designed for consistency, auditability, and manageability. The properties of NixOS that frustrate a developer who wants to run a patched llama.cpp build or install packages from six different sources are exactly the properties that make NixOS attractive for a fleet of civil servant workstations. An IT administrator doesn’t want the 47-year-old policy analyst in the Ministry of Finance to be able to install arbitrary software. The administrator wants to declare exactly what the workstation should look like and have the guarantee that all 2,000 workstations in that ministry look exactly that way.

I’ve spent time with both enterprise IT administrators and developers using NixOS, and their evaluations of the same features are mirror images. Developers find the immutability constraining. Administrators find it liberating. This isn’t surprising — their jobs require fundamentally different things from a system. The Dutch government is deploying workstations for civil servants, not development environments for engineers. The developer experience criticism, while valid in its proper context, is misdirected at DAWO.

There’s a related point about the Nix language specifically. The criticism that Nix requires learning a new DSL is fair — Nix is not YAML, it’s not Ansible, it has its own syntax and evaluation model that takes time to internalize. For the DAWO project’s IT administrators who will be writing and maintaining configurations, this is a real training investment. But the alternative is a mutable system that requires the same administrators to maintain bespoke automation scripts, undocumented local changes, and institutional knowledge that lives in the heads of specific people rather than in auditable configuration files. The Nix language’s learning curve is front-loaded. The operational savings from having everything in version-controlled, reproducible declarations compound over years. For a government department with an expected lifespan of decades rather than years, that tradeoff is favorable.

A Note on Codeberg and the Self-Hosting Question

One detail from the HN thread that deserves more attention: DAWO originally self-hosted its code at code.overheid.nl — a Forgejo instance operated by the Dutch government — and recently moved community collaboration to Codeberg. Several commenters questioned whether hosting on Codeberg (a German nonprofit) achieves the sovereignty goals that DAWO is pursuing.

This criticism is understandable but misses the actual architecture. The canonical source for DAWO code remains at the Dutch government’s self-hosted Forgejo instance. Codeberg is used for community collaboration — issues, discussions, pull requests from external contributors. The government isn’t trusting Codeberg with its authoritative code. It’s using Codeberg as a community-facing interface while keeping the authoritative source under direct government control.

This is actually a sensible architecture that mirrors how large open-source projects handle the distinction between their canonical repository and their community-facing collaboration platforms. The Linux kernel maintains its authoritative source at kernel.org while accepting contributions that flow through GitHub mirrors, mailing lists, and subsystem maintainer trees. DAWO is doing something structurally similar, and the sovereignty argument applies to the authoritative source — which is self-hosted — rather than the community interface.

Codeberg’s recent policy on AI-generated code (discouraging “projects mostly consisting of LLM-generated code”) also came up in the thread, with the observation that some DAWO commits appear to be LLM-assisted. This is a real tension that DAWO will need to address if it wants to remain on Codeberg long-term. But it’s a governance question, not an architecture question, and it doesn’t affect the technical merits of what DAWO is building.