By Riël Notermans
Ask almost anyone building an office suite in Europe what they’re doing and they’ll say: replacing Microsoft. Look at what they’re actually doing and you’ll see a permanent, self-imposed dependency on Microsoft’s design decisions. Every new format feature Microsoft ships becomes someone else’s backlog item. Every subtle spec change creates another round of compatibility bugs. The OOXML camp built their architecture around Microsoft’s formats from day one. The ODF camp fights for open standards, then spends a lot of engineering budget making sure your .docx renders correctly anyway. Different philosophies, same treadmill. And Microsoft is the one who keeps moving it.
A tale of two strategies
When OnlyOffice launched, it made a deliberate bet: build around OOXML from the ground up. OOXML is the format behind every .docx, .xlsx and .pptx file in existence, controversially pushed through ISO standardization in 2008 but in practice defined and implemented by Microsoft alone. For OnlyOffice, the reasoning was simple: if that’s what the market demands, stop pretending otherwise and just make it work. It’s a coherent position. It also means every architectural decision flows from a format Microsoft controls.
LibreOffice and therefore also Collabora took the opposite stance. ODF, the genuinely Open Document Format, is their foundation. The argument is sound: if you want real sovereignty, you need a format no single vendor owns. But then the procurement checklist arrives. The client needs their existing .docx files to render correctly. The tracked changes need to round-trip. And so a significant share of engineering effort ends up in exactly the same place: chasing OOXML fidelity.
Two different philosophies. Two different starting points. The same dependency waiting at the end of both roads.
Why nobody wins
The fundamental problem with chasing OOXML compatibility is that Microsoft never stops moving. New format features ship with every Office release. Rendering behaviours change subtly between versions. Edge cases multiply. And because Microsoft both writes the spec and ships the dominant implementation, the spec is whatever Microsoft does in practice, not what the ISO document says.
This means the compatibility target is never fixed. You can spend years closing the gap on tracked changes, pivot tables and complex layout rendering, and by the time you get there, the goalposts have shifted. Not out of malice necessarily, just out of the ordinary rhythm of a company shipping software. The effect is the same either way: you are permanently one version behind on a road you did not build and do not control.
ODF advocates are right that this trap exists. And the political momentum is real: Germany’s IT Planning Council recently adopted a binding standard framework requiring ODF and PDF/UA as the only approved document formats across all levels of public administration, with implementation targeted for 2028. The Netherlands and other countries similarly mandate open standards including ODF for all data exchanges in the public sector. The direction is clear.
But political mandates and market reality move at different speeds. As long as organisations need to exchange documents with partners still on Microsoft 365, even the most principled ODF-first project has to keep OOXML compatibility working. Awareness of the trap is not the same as getting out of it.
The one escape
Google Docs did not try to be a better Word. When it launched in 2006, it was slower, had fewer formatting options, and couldn’t handle half the complex documents people had built up over years in Microsoft Office. On paper, it should have lost.
It won anyway. Not by closing the compatibility gap, but by making the gap irrelevant. Google built for a different way of working: online-first, real-time collaboration, the document as a URL rather than a file. Nobody exported to .docx unless they had to send it to someone stuck in the old world. No attachment chains, no “final_v3_ACTUAL_FINAL.docx”, no wondering which version your colleague was looking at.
The formatting limitations didn’t matter because most knowledge work doesn’t need them. It isn’t “open a complex Excel macro workbook from 2014.” It’s writing something together, tracking some data, sharing an update, making a decision. For that, a clean editor with a shareable link beat a feature-complete Word clone every time.
Nobody escaped the Microsoft compatibility treadmill by running faster. Google stepped off it entirely, and built something people actually wanted to use.
The ground is shifting again
There is a second force making the compatibility treadmill less relevant, and it has nothing to do with open standards advocacy. AI tooling does not think in .docx or .odt. Large language models are trained on plain text and markdown, not on the rendering quirks of OOXML or the XML schema of ODF. The cleaner and more structured your content, the better AI can read, summarise, draft and interact with it.
This is not a minor detail. As AI becomes part of everyday knowledge work, the document format question gets reframed entirely. The competitive advantage is no longer “how faithfully does this render a Word file.” It’s “how well does this workspace let AI and humans work together.” Neither OOXML nor ODF was designed with that in mind.
A different starting point
At mosa.cloud, we deliver La Suite Numérique, the open-source workspace built by the French government and trusted by over 200,000 French government users. We chose it because it reflects the same philosophy: build for how people actually work, not for backward compatibility with how they used to.
The document editor is built on BlockNote, an open-source block-based editor designed for modern, real-time collaboration, not a recreation of Microsoft’s ribbon interface from 2007. When you need to open a .docx someone sent you, Collabora handles it or we make sure you can import the information inside.
But the editor isn’t the center of gravity. It’s one tool among many in a workspace that also covers file storage, meetings, mail, AI and more. Not a Microsoft 365 replacement. A workspace for teams that want to get work done.
If that sounds like the kind of workspace your organisation needs, see it for yourself.