A common belief says that swapping the operating system ends vendor lock-in. Developers debating DAWO, the Dutch government’s project to replace its Microsoft desktop stack, call the OS the easy part.
Describe every machine as code with NixOS and you get the same system on every box. The hard part is replacing the tools people already know, like a shared spreadsheet or a chat thread.
Table of Contents
- Why swapping the operating system looks like the whole job
- Why the office suite is the real wall
- Where the OS swap still pays off
- Check AI contribution rules before you build
- How to pitch a vendor independence project
- FAQ
- Sources
Why swapping the operating system looks like the whole job
DAWO is a Dutch government initiative to replace the standard Microsoft desktop stack. It’s built as separate, replaceable building blocks rather than one product. There’s an operating system (DAWO-NixOS, “installation building blocks for a reproducible workplace”), cloud infrastructure, collaboration tools and an AI layer. Everything, including the code and roadmap, is public.
The project states five goals:
- Digital autonomy.
- Better collaboration between government and society.
- Security and data protection.
- Innovation.
- Government IT systems that are easier to inspect and verify.
The pitch is simple. Don’t let one vendor’s product decisions decide how your civil service does basic computing.
The OS layer is where that looks easiest. NixOS lets you describe an entire machine, with its packages, services and configuration, in one declarative file. The builder produces the exact same result every time. Machines don’t drift apart, and nobody waits on a vendor’s patch cadence to keep them consistent.
Why the office suite is the real wall
The strongest point in the discussion wasn’t about NixOS at all. Developers argued that swapping the operating system was never the hard part. The hard part is the software people spend their day in.
One commenter put it plainly. LibreOffice and Collabora still can’t match Microsoft 365’s real-time collaboration without real friction for ordinary teams. That means co-editing a spreadsheet, commenting and syncing changes across a large org.
Another developer went further. Cloning Office feature for feature will always land short, they argued, at roughly 80% parity at best. The more useful goal is a rethink of the workflow itself, rather than a lookalike of Excel.
That’s harder than swapping a kernel and a package manager. Every employee has muscle memory built around a specific product. This is a habit migration more than a technical one. Coverage that treats the move as a political statement skips this part.
The technical risk is low and well understood. Getting thousands of people to give up tools they’re fluent in has no clean engineering solution.
Where the OS swap still pays off
The infrastructure work still matters, and the thread showed DAWO has company. France already ships its own hardened NixOS build for government agencies, called Securix. It has a companion example for building office deployments on top of it. Germany runs a comparable open desktop and collaboration effort called openDesk.
None of the three governments appears to share a codebase. They reached the same answer on their own: declarative, auditable infrastructure. That’s why platform teams outside government reach for the same tool. Once your fleet is code, replacing the vendor underneath becomes a configuration change instead of a re-provisioning project.
One developer sketched how they’d run a fleet like this at scale:
- Make every machine’s filesystem read-only.
- Push configuration from a single central source.
- Serve the package store over the network (for example, over NFS) instead of storing it on each box.
No machine then holds local, mutable state that could diverge from the definition. There’s nothing to patch by hand and nothing left to drift. Most companies stop earlier: servers defined declaratively, but still left to pile up local state. A declarative build plus an immutable, centrally served runtime removes that whole category of “works on this one box” incidents.
Check AI contribution rules before you build
One point from the discussion is easy to miss. The project’s code is mirrored to Codeberg. Developers flagged that it may run into that platform’s new policy restricting AI-generated contributions to open source projects.
DAWO lists an AI layer among its building blocks and frames the whole initiative around verifiability. Meanwhile, the code-hosting ecosystem it depends on is moving to restrict AI-authored commits. Any organization building verifiable, open infrastructure with AI help faces that tension. Check for it before you’re a few hundred commits into a similar project.
How to pitch a vendor independence project
Maybe your company turns to you when someone says “we’re too dependent on vendor X.” Be honest about where the real cost sits.
The infrastructure layer is usually the tractable part: servers, OS images, configuration. Tools like Nix, Ansible or a solid golden-image pipeline can get you real independence there in months, not years.
The tools your employees live in all day are where these projects tend to stall. So don’t lead the pitch with the infrastructure migration. Lead with a realistic estimate of how long people need to give up a product they’re fluent in. That number decides whether the project survives contact with the organization.
FAQ
Is NixOS a realistic replacement for Windows in an organization?
At the operating system layer, yes. NixOS describes a machine’s entire configuration as code and reproduces it exactly. That removes drift and dependency on a vendor’s patch cycle. Government IT projects in the Netherlands, France and Germany have independently adopted this approach.
What’s the hardest part of replacing Microsoft 365 with open source tools?
The collaboration suite, more than the operating system. LibreOffice and Collabora still struggle to match Microsoft 365’s real-time, multi-user editing without friction. Cloning Office’s feature set also doesn’t solve the deeper problem of employees’ workflow habits.
How do you manage configuration drift across a large fleet of machines?
Make every machine’s filesystem read-only and push configuration from one central source. Serve the package store over the network instead of storing it locally. That removes the local, mutable state that normally makes machines drift apart.
Sources
- Article: DAWO, by the DAWO project.
- Discussion: Hacker News thread, for the counterpoints on the office suite, the France/Germany comparisons, and the read-only fleet pattern.