You arrive in a city you have never visited before. You are tired. You find your room, open your suitcase, pull out a charger, and plug it into the wall. The small green light comes on. You think nothing of it, because nothing happened. You moved between two countries, two electrical grids, two regulatory regimes, and the machine in your hand simply continued to work.

Behind that uneventful moment sits more than a century of meetings, arguments, technical drawings, and compromises between people who will never meet you. The plug fits because somebody, somewhere, decided that it should – and decided further that the decision should be written down, made public, and not owned by anyone. We almost never notice this kind of work. We only notice it when it fails: the adapter that does not fit, the document that does not open, the part that cannot be replaced. Standards are the infrastructure we live inside, and like most infrastructure, they are invisible until they are not.

The public agreement

A standard is a public agreement about how things should fit together. Two words in that sentence carry the weight: public and agreement. Public, because the rules are written down and anyone can read them. Agreement, because nobody imposes them alone; they are negotiated between parties who accept that the shared space is more valuable than any individual advantage within it.

This distinguishes a standard from two things it is often confused with. It is not a law, because no state enforces it directly. And it is not a product, because no company owns it. A standard sits in a peculiar middle ground – it is something that belongs to everyone and to no one, maintained by institutions whose only task is to keep it coherent and accessible. The metric system is a standard. So is the size of a sheet of A4 paper, the shape of a stop sign, the gauge of a railway track, the dimensions of a shipping container. None of these things were inevitable. Each of them was once contested, and each of them was resolved not by conquest but by convention.

A civic act, not a technical one

It is tempting to treat standards as a matter for engineers. They are not. Or rather, they are only incidentally so. The engineering is the easy part. The hard part is the decision that the rules of a shared space should not belong to any single actor – that the measurement of length, the width of a road, the voltage in a socket should be held in common rather than owned.

The history of standards is, almost without exception, a history of fragmentation followed by painful consolidation. In the nineteenth century, European railways had dozens of incompatible track gauges, because each company built its own. Goods had to be unloaded and reloaded at every border, and sometimes at every regional boundary. The loss was enormous, and it was eventually resolved not because engineers invented a better track but because societies decided that the common good of interoperability was worth more than the private advantage of incompatibility. The same story repeats with screw threads, with time zones, with paper sizes, with electrical systems. Each consolidation was a political act dressed in technical clothing.

When we say a standard is public, then, we are saying something quite radical. We are saying that a certain category of rules – the ones that govern how we connect to each other – must be held outside the market, because if the market owns them, the market can charge rent on the simple act of cooperation.

What standards give us

From the point of view of the person who uses them – which is to say, all of us, every day – open standards provide three things that are easy to take for granted until they are gone.

The first is interchangeability. Because the rules are public, anyone can build to them. If the lamp you bought five years ago breaks, you can replace the bulb with one from any manufacturer. If your supplier raises prices unreasonably, you can switch to another. If a company goes out of business, its customers are not stranded. You are not captured by the choices you made in the past, because the choices were made against a common framework rather than inside a private one.

The second is continuity. What works today will still work tomorrow, and what was made yesterday still works today. This is a quieter gift, but it may be the most important one. A standard that is public and stable means that your past remains legible to you. The documents you wrote twenty years ago, the tools your grandfather used, the measurements recorded in an old building plan – all of these remain available, because the rules that governed them are still available. Continuity is how a society talks to itself across time. It is how we remain connected to what we have done and what has been done for us.

The third is shared ground. Standards let people who have made different choices still cooperate. You and I do not need to use the same brand, the same supplier, the same tool. We only need to agree on the interface between us. A standard is, in this sense, a kind of peace treaty – a recognition that a common format for exchange matters more than uniformity of preference. It is the opposite of a monoculture. It is the condition that makes plurality possible without chaos.

When the rules become private property

Now consider what happens when the rules of a shared space are privately owned.

Imagine that the thread on every screw in your country belonged to a single company, and that using a screw at all required permission from that company. Imagine that the gauge of the railway tracks was the property of one firm, and that every other operator had to pay to run trains on lines they did not own. Imagine that the voltage of the electrical grid was licensed, and that plugs from any other manufacturer simply did not fit.

The three goods we just described begin to erode. Interchangeability disappears, because you cannot replace one part with another without the owner’s permission. Continuity depends on the corporate survival of a single actor: if the company changes its terms, raises its prices, or goes bankrupt, you lose access not just to a product but to the entire category of things that depended on it. Shared ground shrinks until it includes only the people who have paid the same licence as you have. Cooperation becomes a privilege extended by a third party, rather than a right held between equals.

This sounds absurd when we imagine it happening to physical infrastructure. We would never accept it for screws or rails or electricity. And yet the history of standards is also the history of attempts to do exactly this, resisted successfully in some domains and less successfully in others. The reason we have open standards for physical infrastructure is not that anyone thought them obviously good. It is that societies fought, sometimes for decades, to keep them out of private hands.

The ancestor question

There is a useful way to think about all of this, which is to ask what kind of ancestor we want to be.

Every time we accept an open standard, we are making a small bet on behalf of people who do not yet exist. We are saying that the thing we are building – the document, the product, the system – should remain accessible to them, even though we will not be here to help them open it. We are choosing to be hospitable to a future we cannot see. And every time we accept a closed one, we are making the opposite bet. We are saying that our successors will have to rely on the continued goodwill of a private actor to reach back to what we have made. We are outsourcing their access to our own lives.

This is not a technical question. It is a civic one, and it is also a moral one. Standards are how a society decides whether its own infrastructure should be owned or shared, whether its past should be accessible or licensed, whether its future should be open or gated. They look like engineering. They are really a quiet, continuous answer to the question of what we owe each other, and what we owe to those who come after us.

So the next time you plug something into a wall and it simply works – the next time a door handle fits, a page prints cleanly, a part slots into place without thought – consider for a moment what had to be true for that to happen. Consider who refused to own it. And ask yourself what kind of ancestor a closed standard lets you be.

Earlier in this series I described the invisible architecture of lock-in as three stacked layers. A document depends on its format, which depends on a rendering engine to become visible, which depends on the fonts that give it its final shape. Each layer is a dependency the user rarely sees and almost never chooses deliberately, and together they explain why “just open it in something else” so often fails. The argument has always been structural rather than moral: it does not matter whether the vendor is benevolent or predatory, because the dependency exists either way.

Two pieces of news from late June give me occasion to extend that architecture. They are not, at first glance, about formats at all. But read structurally, they reveal two further layers of dependency that sit on top of the technical ones. Layers I left implicit until now because the technical case was enough to make the point. It is worth making them explicit, because they complete the account of what dependency actually means.

The first piece of news: Microsoft has extended free security updates for Windows 10 by a further year, to October 2027. The original end date for consumer support was October 2026. Hundreds of millions of users, and the institutions that manage them, had organised their procurement, their budgets, and their migration planning around that date. Then the date moved, quietly, through an editor’s note appended to a blog post, with no formal announcement.

The second: Italy’s competition authority, the AGCM, has opened an investigation into whether Microsoft adequately informed consumers when it integrated its Copilot and Designer AI tools into Microsoft 365 and moved subscribers onto more expensive plans. The allegation, still under investigation, concerns transparency and consent: whether users were given a genuine choice, or were migrated to a costlier tier unless they actively opted out.

I want to be careful here, because the temptation is to treat these as two instances of the same thing, and they are not. They are two sides of one coin. A coin has two faces and a single substance. The substance, in both cases, is that the user is not in control of his desktop stack. The faces are different, and naming them precisely is what gives the argument its force.

The temporal layer

The Windows 10 extension is not, on its surface, bad news. A further year of free security updates is, taken in isolation, a gift to users who cannot or will not upgrade. If you read the story as a tale of corporate character – Microsoft breaking its word, Microsoft flip-flopping – you reach for the weakest version of the argument, and you hand a critic the easy reply that extending support is pro-consumer.

The structural reading is harder to answer. The point is not that the date was wrong, or that moving it was wrong. The point is that the date was never yours. The lifecycle of your own desktop – when it is supported, when it is abandoned, when you must spend money on new hardware – is governed by a vendor’s strategic calendar, not by your operational needs. You reorganised a year of planning around October 2026 because Microsoft told you to, and you will reorganise again around October 2027 for the same reason. A benevolent vendor moving the date without consulting you proves the point exactly as well as a cynical one would. You do not own the clock.

This is the fourth layer. Above format, rendering, and fonts sits time. Your dependency is not only in the file, it is in the calendar.

There is a detail in this story that sharpens the point rather than softening it. The free extension is not unconditional: to enrol without paying, a user must sign in with a Microsoft account and sync settings to the company’s cloud. So the price of keeping your old operating system alive is to move more of yourself into the vendor’s stack. The remedy deepens the dependency it claims to relieve. This is the difference, which I have written about before, between a solution and a substitution. A solution would reduce your dependence. A substitution merely relocates it from the operating system to the account.

The commercial layer

The Italian investigation looks, at first, like a different kind of story altogether: a matter of consumer-protection law, of disclosure and dark patterns, with no obvious connection to open standards. And it would be a mistake to press it into service as evidence of format lock-in, because that is not what it is about. The discipline of letting structure carry the argument requires resisting exactly that kind of stretch.

But it illustrates a different layer cleanly, and the layer is real. When your productivity suite is a proprietary bundle, the vendor can change what you are paying for, and how much, without your meaningful consent. New tools you did not ask for are folded into the package, the price rises to match, and the path to opting out is, allegedly, buried. Whether the AGCM ultimately finds against Microsoft is not the point I am making, as the investigation may take until 2027 to conclude. The point is that the arrangement permits this. The economic terms of your daily work are set by a party that is not you, and can be revised by that party at a moment of its choosing.

This is the fifth layer. Above format, rendering, fonts, and time sits price. Your dependency is in the invoice as much as in the file.

What the layers have in common

Five layers, then: format, rendering, fonts, time, price. The first three are technical and largely invisible. The last two are not technical at all, and they are the ones the user feels most directly, in a migration deadline he did not set, in a subscription cost he did not agree to. Listing them together changes the character of the argument. Lock-in is no longer a catalogue of technical grievances of interest mainly to specialists. It is a complete account of dependency, and it reaches every part of how a person works: what his documents are made of, when his tools will stop being supported, and what he will be charged for them.

What unites all five is a single absence: the user has no exit. He cannot take his documents elsewhere without loss because of the technical layers, he cannot escape the vendor’s calendar or its pricing because of the other two. Every one of these dependencies is only possible because there is no door.

That is why I have spent this series on formats, and on rendering, and on fonts, and now on calendars and invoices. They are not separate complaints. They are the same observation seen from different angles, and the observation is this: an open format and a free application are not, in the first instance, about cost or ideology. They are an exit, they are the door that makes every one of these dependencies optional rather than fixed. The Open Document Format and LibreOffice do not promise that you will never depend on anyone. They promise something narrower and more important: the dependency is one you have chosen, and one you can leave.

A vendor’s calendar will always move. A vendor’s prices will always rise. These are not scandals, they are simply what it means to be governed by someone else’s strategy. The only question that matters is whether you are free to walk away when they do. Everything in this series has been an argument that you should arrange your affairs so that you can.

Images by Manfred Steger from Pixabay

There is a sophisticated mechanism by which proprietary technology ecosystems maintain their grip on users and institutions, even when those users and institutions believe they are making free choices, using open standards, and building independent digital infrastructure.

The mechanism does not work through force, but through a subtler and more durable strategy: the layering of dependencies, in which each layer obscures the one beneath it, so that when the system fails the apparent cause is something other than the real one.

It is a structural pattern with identifiable components and predictable failure modes, and with a single political consequence: the systematic attribution of interoperability failures to open alternatives rather than to the proprietary dependencies that actually cause them.

Understanding all of this is essential for anyone working on a genuine interoperability policy, because without it even the best-intentioned policy interventions address the visible symptom while leaving untouched the larger problem of the underlying architecture, which goes on working exactly as designed.

The perception of malfunction

Let us start from the user’s experience, because this is where the political damage occurs.

A document is created in Microsoft Word and sent to a colleague who uses LibreOffice on a Linux desktop. The colleague opens the file. Something is wrong: a table has shifted, the text has reflowed, a font looks different, the page breaks have moved.

The experience is familiar to millions of people in institutional settings that have adopted, or are considering adopting, open source software. It is the experience that generates the helpdesk tickets, the emails of pure frustration to the IT department, the conversations that end with “can you just send me a PDF?”, and the broader sentiment, consolidating over time, that open source software is not ready for professional use.

What is the cause of this failure? Users will blame LibreOffice, IT managers will blame format incompatibility, policymakers will blame the immaturity of open standards.

These are all wrong answers. Or rather, they are all answers to the wrong question, because they describe where the failure manifests rather than where it originates.

The actual cause is a set of interdependent technical systems, each contributing a different failure mode, all producing a single visible result.

The format contains proprietary structures that only Microsoft’s implementation handles correctly. The rendering introduces platform-dependent variations that the format specification does not control. The proprietary fonts cannot be legally bundled with open source software.

Three distinct failure modes producing the same symptom, and equally invisible to the user, who perceives only that things worked in Word and do not work in LibreOffice.

This is the architecture of layered dependency. Each layer absorbs the causal chain and emits a different signal, one that points toward the open alternative.

Layer One: the format and its hidden features

The first layer is the most discussed and the most politically visible: the document format. The conflict between ODF and OOXML has been extensively documented, litigated within standards bodies, and debated in national parliaments and in the European institutions.

But even within this well-mapped terrain, it is worth clarifying the specific mechanism of obscuration at the format layer.

OOXML, the format Microsoft Office produces by default, exists in two conformance levels. Strict is a reasonably clean specification. Transitional is something categorically different: a format designed to encode the accumulated behaviour of earlier Microsoft Office versions, preserving decades of proprietary implementation choices as normative elements of an apparently open standard.

OOXML Transitional includes VML — Vector Markup Language, a proprietary drawing format from the late 1990s that predates and contradicts the DrawingML system defined elsewhere in the same specification.

It includes references defined as “as in earlier versions of Microsoft Office”, which make sense only if one has access to those earlier versions and to their undocumented implementation details.

It includes extensions that allow Microsoft to embed proprietary functionality in documents, invisible to non-Microsoft implementations, and capable of causing silent rendering differences ranging from minor visual variation to complete layout failure.

Crucially, OOXML Transitional is what Microsoft Office produces by default.

Every time a user saves a Word document without selecting a different format, they produce a file optimised for the Microsoft ecosystem and subtly hostile to every other.

Users do not know this is happening, because the choice is made for them at the format level, and when the document fails in LibreOffice, the format layer’s contribution to that failure is invisible. The user sees a rendering problem, not a format problem.

This is the first layer of obscuration: proprietary format constructs masked by the label “industry standard”, producing errors that appear to be implementation shortcomings in the receiving software.

Layer Two: rendering and its unspecified behaviour

The second layer is less discussed, less politically visible, and for these very reasons more durable as a source of interoperability failure: text rendering.

Document format standards specify content. They define what a document contains: text, structure, logical relationships, embedded objects, and formatting instructions.

What they do not specify, and what none of the major document format standards has ever specified, is how that content should be rendered. The translation of encoded content into visible glyphs on a screen or a page is left to the implementation, and different implementations make different choices.

These choices operate across several subsystems.

Shaping engines — the software components that translate sequences of Unicode characters into sequences of glyphs, and that handle the complex rules of scripts such as Arabic, Devanagari and Thai — differ by platform.

HarfBuzz, the open source shaping engine used by LibreOffice and by most Linux applications, produces correct, standards-compliant output, but that output may differ in detail from Windows’ Uniscribe or DirectWrite engines, particularly for complex scripts with context-sensitive glyph selection.

The differences are almost always invisible for Latin text, but for the non-Latin scripts used by a significant portion of the European public sector and citizenry, they can be significant.

Hinting interpretation varies across rendering engines. Fonts embed hinting instructions — algorithms that adjust glyph outlines for crisp display at low screen resolutions — but those instructions are interpreted differently by different renderers.

A font optimised for Windows’ GDI rendering engine may display with different weight and spacing under FreeType on Linux, even at identical sizes.

The differences are minute for any single character, but they affect the perceived quality of the text and contribute to the general impression that open source environments are slightly less polished.

Line-breaking and justification algorithms are the most significant source of rendering variation and the most direct cause of document reflow.

The algorithm that determines where to break lines — how to distribute words across a line of a given width, whether and how to hyphenate, how to handle justified text — is an implementation choice that no format specification regulates.

Microsoft Word’s line-breaking algorithm is proprietary and undocumented, and it is very different from LibreOffice’s. Both are legitimate implementations of the same function, and they can produce different line breaks; different line breaks mean different page breaks; and different page breaks mean that a document paginated in Word will not be paginated the same way in LibreOffice.

This is not a defect in implementation quality, but the normal and predictable consequence of differing rendering choices that document format standards do not define. And it produces errors that are invariably attributed to the software receiving the document, because that is where the visible difference appears, rather than to the specifications that are their cause.

The rendering layer is the most technically complex component of the layered dependency and the hardest to address, but it is also the layer that most clearly reveals the dimensions of the problem: an error generated by a different choice made by two projects, attributed solely to the open source software, on the basis of an entirely unjustified, almost faith-based trust in the quality of the proprietary software.

Layer Three: fonts and the dependency on proprietary resources

The third layer completes the picture and, in many practical settings, causes the greatest damage: fonts. Here we will not analyse font-level lock-in as such, but will instead explain how the font layer operates within the layered dependency model.

Fonts interact with both layers above. At the format level, fonts appear as named references: a document declares that the body text is set in Calibri and the headings in Cambria. If those two fonts are not available on the receiving system — and this is the case on every system for which a licence for the proprietary fonts has not been acquired — the software must substitute them.

Substitution changes the metrics, and the metrics in turn change the geometry. Altered geometry produces reflow, broken layouts, forms overflowing their margins; and here too the failure is attributed to the application receiving the document.

At the rendering level, fonts interact with the shaping engine, the hinting system and the antialiasing pipeline in ways specific to each font’s design and embedded instructions. A font optimised for the Windows rendering stack will display differently under FreeType, even before any substitution occurs, and this contributes to the overall visual divergence between environments.

What makes the font layer particularly effective as a lock-in mechanism is the combination of legal unavailability and the user’s lack of information. The proprietary fonts at the heart of the problem — Calibri and Cambria, and before them Arial and Times — are not available under any kind of open source licence.

This is a legal constraint that open source software cannot overcome, but one that users perceive not as a licensing problem but as a software problem — not as the consequence of a strategy but as proof that open source software cannot handle ordinary documents.

Only Aptos, the latest of Microsoft’s proprietary fonts, is released under a partially restrictive licence, since it ties use to a download from Microsoft’s site. It can therefore be installed by Linux users too, and used legally, but this has not been communicated widely enough, so the lock-in mechanism is only reduced, not eliminated.

Why “invisible” is the key word

Each of the three layers would be a manageable problem if it were visible, and if users had the chance to see clearly that the error originates in the proprietary format, or in the insufficient rendering specifications, or in the proprietary font. Visible problems can be addressed and solved on the basis of accurate diagnosis and targeted intervention.

The strength of this scheme lies in its obscurity. Each layer acts as a signal re-encoder: it takes the output of the layer beneath it and re-emits it as something that looks like a different kind of problem.

So the dependency on proprietary fonts produces an error that looks like a software rendering issue; the rendering problem produces an error that looks like an implementation shortcoming; and finally the proprietary format structure produces an error that looks like a failure to comply with standards.

By the time the error reaches the user, its origin is completely obscured, and responsibility is systematically redirected to the last element in the chain: the open source software, which was merely trying to display a document designed to defeat it.

This is not a coincidence arising from poor design.

Software that generated random errors would be a problem for the company that developed it, because user frustration would flow back toward the originating software.
A system that generates errors at the boundary with competitors, in such a way that they are always attributed to those competitors, is a competitive asset.

Here the question of intent matters less than the question of structure: whatever the motivation behind the original design decisions, the resulting architecture functions as a constraint, and its effects are observable and measurable.

How policy responded, and where it failed

The policy response to document lock-in has concentrated on the format: mandating the use of ODF and open formats in public procurement, and guaranteeing that government documents can be created and consulted without the use of proprietary software. Unfortunately, these interventions have almost never been paired with penalties to enforce compliance, and the rules have often been ignored.

Moreover, these format mandates have not addressed the use of proprietary fonts in document templates, so by fixing only the upper layer they leave the lower one exposed and fully operational, where it is less visible and less politically salient, and therefore more durable.

Documents continue to fail at the boundary with open source software, and users continue to blame the latter. The political will behind the format mandate is progressively eroded by user complaints about interoperability problems, which seem to contradict the promise of the open, standard format mandate itself.

An institution that deploys LibreOffice but fails to address rendering consistency — allowing a mixed infrastructure of Windows and Linux systems to exchange documents without recognising that rendering variation is not a software defect — risks creating an internal interoperability problem that could be used to justify a return to monoculture.

The rendering layer has received almost no policy attention. No major digital sovereignty framework specifies rendering-fidelity requirements. No procurement standard defines conformance in terms of visual consistency across implementations.

The tools to address this problem — reference rendering implementations, rendering test suites, fidelity benchmarks — exist only as prototypes or proposals, and have not been integrated into any serious policy framework.

Knowing this pattern is a political act

The invisible layering of dependencies is a pattern born of nearly fifty years of unregulated evolution of personal productivity software, and one that threatens to make the path toward digital sovereignty extraordinarily complex.

It matters to give the pattern a name, so that it can be used in policy discussions, in parliamentary questions, in procurement specifications and in the public debate on digital sovereignty, at every level, including by the media.

The invisible layering of dependencies connects phenomena that do not appear to be related — document format incompatibilities, rendering variation, font substitution failures — and shows that they are expressions of the same underlying architecture.

Once these phenomena are seen as a pattern rather than as isolated technical problems, an appropriate policy response becomes clearer, because it is not enough to fix a single layer and mandate a single standard — even though that is a fundamental first step.

It is necessary to make all the dependencies legible and to integrate them into interoperability policies that address format, rendering and fonts explicitly and specifically, with enforcement mechanisms applying to all three layers.

The open source and open standards community has built the technical foundations for genuine interoperability: open formats are mature and solid, open source applications are fully up to the task, and there are hundreds of openly licensed fonts, many of them metric-compatible with the proprietary ones.

The architecture of lock-in does not persist because the alternatives are inadequate. It persists because policy has not yet learned to look beyond the visible surface of format conformance and to recognise the underlying layers where proprietary dependencies go on operating — invisible and ignored — doing the work they were designed to do.

When The Document Foundation was announced sixteen years ago, some people found the name a little flat. It didn’t sparkle. It named an object — the document — rather than a product, a movement, or an aspiration. Today, that same name is worth a second look, because it turns out to have pointed at exactly the place the digital sovereignty debate would eventually arrive.

To see why, it helps to ask a simple question: when you are locked into a piece of software, where does the lock actually live?

The intuitive answer is “in the application.” You feel trapped by the program — its menus, its habits, the licence you keep renewing. But the application is replaceable. You can install a different one tomorrow. What you cannot so easily replace is your documents — the years of contracts, records, reports, and correspondence you have produced. And if those documents are saved in a format that only one company’s software can fully read, then the lock was never really in the application at all. It was in the file.

This is the quiet mechanism behind most document lock-in. The format does the trapping. As long as your organisation’s memory is stored in a format controlled by a single vendor, you depend on that vendor to read your own past — and that dependency does not end when you switch programs, because the documents come with you.

This is also why “digital sovereignty” is not, at root, a question about geography or about which company you buy from. It is a question about control: whether you, and not a supplier, hold the keys to your own information over time. An organisation that cannot open its own archives without permission is not sovereign over them, wherever it happens to be located.

The answer is older and simpler than the debate that has grown up around it: open document standards. A document saved in an open, fully published format — one any software can implement, today or in fifty years — belongs to the person who wrote it, not to the company whose program happened to create it. The format stops being a lock and becomes what it should always have been: a neutral container for your own words.

The name said this all along. It put the document at the centre, because the document is where the question is decided. Sixteen years on, the rest of the conversation is catching up — and we have only just begun to scratch the surface.

A welcome commitment to open standards — and why it should end with ODF as Euro-Office’s native document format.

The Euro-Office pre-announcement has generated considerable coverage across the European press over the past few days. The Document Foundation welcomes the attention that open standards are receiving — and welcomes still more the commitment the announcement makes to them. Before the discussion settles, we would like to clarify one point and state one expectation.

Several reports have described Euro-Office as “the first European open source office suite.” Reading the pre-announcement carefully, we do not find the coalition making that claim, and it is not one we would endorse. Europe has been building free and open source office software for many years: LibreOffice, developed by this Foundation and a worldwide community, is itself European, mature, and far from alone.

The “first” framing appears to have emerged in the speed of a launch day rather than in the text of the announcement. We note it not to claim precedence — precedence is not the point — but because accuracy serves the cause of open standards better than enthusiasm alone.

Read on its merits, the announcement gives a great deal to welcome. The promise to improve support for the OpenDocument Format is precisely what the European free software community has long asked for, and we take it in good faith and with genuine appreciation. We have always held that sovereignty begins with the format, not with the logo on the application — and a coalition that understands this is one worth encouraging.

We would also state an expectation, in the spirit of encouragement rather than demand. Improved support is a beginning, not a destination. A format that is merely supported is one a suite can read and write as a courtesy, while a native format is the one in which its documents are created, stored, and trusted across the years — and that is precisely where digital sovereignty is won or lost.

The only destination consistent with the sovereignty Euro-Office invokes is ODF as its native document format. A genuinely European, genuinely sovereign office suite cannot treat the open standard as a concession to outsiders, it has to speak ODF as its mother tongue. The Document Foundation looks forward to that moment, and will be glad to acknowledge it when it comes.

Dear office suite users,

In recent days you will have read various articles announcing the arrival of Euro-Office, which is being “marketed” as the first open-source office suite developed in Europe. We feel compelled — reluctantly, since open source should rest on transparency, not deception — to correct this claim. The first open-source office suite developed in Europe was OpenOffice.org in 2001, based on StarOffice’s source code, followed by LibreOffice from 2010.

These are two genuine open-source office suites, built from source code that originated in Europe. They are not a freeware clone of MS Office whose code provenance is undisclosed, nor a product that has rebranded itself out of pure opportunism to ride today’s wave of Digital Sovereignty.

It is worth remembering that many of those who champion Digital Sovereignty today were silent back in 2006, when the open ISO/IEC ODF standard — the pillar of Digital Sovereignty — was announced: not only did they not listen to us during all these years, but in some cases they greeted us with a condescending smile.

If we can speak of Digital Sovereignty in Europe today, it is thanks to The Document Foundation and LibreOffice community members at large, who kept the flag of open-source office suites flying when everyone was predicting their demise, and who continued to develop the only truly open and standard format that guarantees Digital Sovereignty, as it provides full user control over content.

Document formats are a subject still rife with misinformation. This is understandable on the part of Microsoft, which developed and controls the horrible proprietary OOXML format, designed precisely to prevent Digital Sovereignty by maintaining content lock-in. It is far less understandable on the part of companies that claim to advocate open source, such as those promoting Euro-Office.

Euro-Office defaults to the fully proprietary OOXML document format, developed and controlled solely by Microsoft. This makes it a de facto ally of Microsoft in its content lock-in strategy, with control remaining firmly in Redmond and far from Europe.

So, despite what is being written in support of Euro-Office — the latest of the office suites developed in Europe, and not the first — the announcement is not against Microsoft. On the contrary, it strengthens Microsoft’s strategy against European Digital Sovereignty, or, if you prefer, against the freedom of European users to control and manage their own content.

Berlin, 5 June 2026 – The Document Foundation today announced the release of LibreOffice 26.2.4, the fourth maintenance update to the LibreOffice 26.2 branch. Building on the major feature release published on February 4, 2026, this update delivers targeted bug fixes and stability improvements contributed by a global community of developers and QA engineers.

LibreOffice 26.2.4 is available for immediate download at libreoffice.org/download/ for Windows, macOS, and Linux.

Users of LibreOffice 25.8.x should update to LibreOffice 26.2.4 as LibreOffice 25.8 branch will reach end of life on June 12, and after that date the software will not receive security updates. In late August 2026, The Document Foundation will announce LibreOffice 26.8.

LibreOffice 26.2 introduced a broad set of improvements to daily productivity workflows, including Markdown import and export, connector shapes in Calc, multi-user Base, faster EPUB export, and mandatory Skia rendering on macOS and Windows for better graphics performance. LibreOffice 26.2.4 consolidates these advances with a focused set of fixes, addressing issues identified by users and testers since the initial release.

List of fixes in RC1: wiki.documentfoundation.org/Releases/26.2.4/RC1. List of fixes in RC2: wiki.documentfoundation.org/Releases/26.2.4/RC2.

LibreOffice users, free software advocates and community members can support The Document Foundation and the LibreOffice project with a donation at www.libreoffice.org/donate.

When a public administration is told its documents are stored in “an ISO standard format,” the assumption is reasonable: an ISO standard ought to be a clean, implementable specification that any qualified software vendor can support. Standards exist precisely so that nobody is locked to a single supplier.

OOXML — ISO/IEC 29500, the format behind Microsoft’s docx, xlsx and pptx files — does not work this way.

The standard is split into two conformance classes. Strict is the clean version: a modern document format, free of legacy baggage, that an independent implementer could reasonably support. Transitional is everything else: a vast catalogue of compatibility features, deprecated elements, platform-specific behaviours, and references to undocumented quirks of Microsoft Office versions from the 1990s. The Transitional class exists to ensure that documents converted from the old binary doc, xls and ppt formats can be represented in XML without loss.

There is one detail that matters above all others: Microsoft Office has never produced Strict OOXML by default. The option to save in Strict format is available in the installed desktop applications but is absent from the browser-based versions of Microsoft 365 — and Microsoft’s various editions have long differed in which features they offer, with the macOS version historically providing a different set of options from the Windows version. The “ISO standard” that public administrations are actually storing their documents in, when they use Office, is Transitional — the messy one. Strict is a feature you can find if you know where to look, on the platforms where Microsoft has chosen to support it. That is not the treatment a serious open standard receives.

This has consequences that go well beyond a technicality.

The standard codifies undocumented legacy behaviour. Transitional OOXML contains compatibility flags whose specification amounts to “behave like Word 95” or “lay out footnotes like Word 97.” These are not formal definitions. They are references to the behaviour of specific commercial software products released more than thirty years ago — products whose layout algorithms were never published. An independent implementer wishing to render such a document correctly must reverse-engineer software from the Windows 95 era. This is not standardisation in any meaningful sense; it is the codification of one vendor’s implementation history as a global norm.

The standard perpetuates known bugs. Excel famously treats 1900 as a leap year — it was not — because Lotus 1-2-3 did so in the 1980s, and Microsoft chose binary compatibility with Lotus over arithmetic correctness [1]. OOXML Transitional preserves this bug. The default workbook setting in every xlsx file you have ever opened encodes a date arithmetic error from the era of MS-DOS. A spreadsheet calculating durations across February 1900 will produce wrong answers, and the standard requires this.

The standard includes obsolete graphics formats. Vector Markup Language (VML) was submitted by Microsoft to the W3C in 1998 as a candidate vector graphics standard. The W3C rejected it in favour of SVG. VML should have died there. Instead, it lives on inside OOXML Transitional, because documents converted from doc files contain it, and Microsoft Office continues to emit it. Implementers must support both VML and its modern replacement, DrawingML, to handle real-world files.

The conformance class problem is structural. Strict was meant to be the future and Transitional the temporary bridge. Two decades after standardisation, Transitional remains what Office produces, what users receive, and what any competing implementation must support to be useful. The clean standard exists on paper. The standard that exists in practice — and that Microsoft Office produces by default — is the messy one.

For public administrations, this matters in three specific ways.

For archives. A document format that depends on undocumented behaviour of 1990s applications is not a safe long-term archival format. The ISO label provides a false reassurance: the parts of the standard your documents actually use are precisely the parts that are least specified and most dependent on a single vendor’s tooling.

For procurement. Specifying “ISO/IEC 29500” in a tender does not guarantee interoperability or vendor neutrality. It guarantees that documents will conform to a specification of which the practically deployed variant is, in effect, whatever Microsoft Office does. This is the opposite of what an open standard is meant to deliver.

For sovereignty. European institutions, national governments, and regional administrations increasingly recognise that the choice of document format is a sovereignty question. A format whose definitive reference implementation is a single American company’s commercial product cannot serve as the technical foundation of European digital autonomy — whatever its ISO number.

The alternative is not hypothetical. The OpenDocument Format (ODF), ratified as ISO/IEC 26300 twenty years ago this month, was designed from the outset as an implementer-neutral standard. Its specification is complete, self-contained, and does not require knowledge of any specific commercial product’s history. Multiple independent implementations exist. It is, in the proper sense of the term, an open standard.

For administrations weighing format policy, the question is not whether OOXML is “a standard.” It is. The question is what compliance with that standard actually entails, what it demands of implementers, and whether that serves the long-term interests of the institutions storing their work in it.

For those interested in the technical detail behind these claims, we attach a companion deep-dive [2] cataloguing the Transitional features, their categories, and the specific structural problems they introduce.

[1] The history of the 1900 leap year bug is well documented. Joel Spolsky, who worked on the Excel team at Microsoft in the early 1990s, recounted in My First BillG Review how Excel inherited the bug from Lotus 1-2-3 to preserve binary compatibility. Microsoft’s own support documentation openly acknowledges the bug and explains why it will not be fixed: doing so would invalidate every date in every existing Excel worksheet.

[2] The companion deep dive document in PDF format, cataloguing the Transitional features, their categories, and the specific structural problems they introduce: A Standard in Name Only a Deep Dive

Executive Summary

This proposal suggests restarting LibreOffice web, mobile, and cloud development by structuring the project into a set of independent initiatives. Each initiative can be pursued separately from the others, and their deliverables will be useful improvements to LibreOffice even without the other components.

• Responsive user interface
• Web distribution based on desktop version using WebAssembly
• Mobile distributions based on desktop version
• Document server and integration
• Client-server collaborative editing

One of the greatest risks to large software projects is schedule slip due to dependencies between components. By structuring the project as independent initiatives with separate deliverables, rather than a single monolithic project, we can reduce that risk. This approach also calls for a high level of code sharing across the desktop, web, and mobile versions, which will reduce both our initial development and long-term code maintenance costs.

The result of this project will be a blended web, mobile, and cloud offering and development strategy, which will signal to the public that LibreOffice is on a clear trajectory toward achieving technical parity with the major commercial office suites. In lieu of invasive first-party cloud service integrations, we will aim to offer server components that are lightweight and inexpensive to host, and make it easy for users to work with multiple server providers.

Please note that this document is intended as a strategy proposal, not as a technical specification or project plan. Technical and planning commentary in this document should be considered speculative. Additional work is needed to prepare concrete implementation plans for each initiative, should we choose to proceed with this strategy.

Market Analysis

Consumers

Due to the nature of our project, we have relatively little visibility into the needs of our end users. We also have limited resources to conduct primary market research, in part out of consideration for user privacy. Most of our institutional understanding of end user needs comes from engaged community members who volunteer their time to advocate for their particular interests, which may not be representative of larger populations.

Rather than investigate the needs of end users directly, we can instead borrow from economics and examine the revealed preferences of consumers: if a great majority of people select one product over its alternatives, ceteris paribus, we may safely assume those people prefer that product. Thus, the features our major competitors use to distinguish themselves can serve as signposts for what users consider when choosing between cloud-enabled office suites.

Service Providers

One special case is the group of users who are invested in deploying and operating cloud-enabled office suites. This category ranges from institutional IT decision-makers, to on-premises cloud software vendors such as Nextcloud.

The Document Foundation has not been previously involved with developing or marketing a cloud-enabled office suite. As a result, we have few direct contacts we can use in order to gather requirements. However, we may be able to draw some conclusions about what this category of consumer wants based on public comments and prevailing economic and regulatory conditions.

For server operators, the world looks quite different today than it did when the LibreOffice project was founded. Application hosting costs have risen dramatically, driven by a complex interaction of increasing energy costs, server component supply chain disruptions, excess demand due to AI speculation, and vendor consolidation. We can no longer expect users to host applications that perform unnecessary computation inside the datacenter, where space, hardware, and energy are all at their most expensive – and are needed for other business activities.

In addition to more immediate financial concerns, software sustainability / “green coding” has continued to develop among policy, government procurement, and investor risk management (ESG) circles. For one concrete example, the 2024 French RGESN V2 (“Référentiel général d’écoconception de services numériques”) mandates software eco-design principles and resource efficiency for certain types of public procurement. Many other jurisdictions are developing similar regulations, including Germany and the UK.

In order for a LibreOffice cloud initiative to succeed, we must at minimum offer software that server operators can afford to host. While these macroeconomic conditions are still evolving, it seems clear enough that service providers will grow increasingly sensitive to operating costs, and will prefer applications that require less energy, bandwidth, and system memory in the short term. As there is currently no energy-efficient cloud office suite based on open document standards, it is possible that open standard adoption will be impaired should we fail to provide one.

Competitors

The cloud-enabled office suite market is overwhelmingly dominated by two competitors: Microsoft and Google. Their products are closed-source, distributed under restrictive terms, lack on-premises hosting [1], and are tied to proprietary document formats. Combined, Microsoft and Google capture roughly 96% of the total addressable market. The remaining 4% is divided among a long tail of small vendors, with office suite products that range from the purpose-built for specific national markets, to nascent general-purpose suites that have yet to achieve product-market fit. Market shares for firms within this 4% long tail are too low to individually estimate with any accuracy.

We are all familiar with this breakdown, but it does not go without saying. It takes conscious effort to maintain a clear perspective about a global market. Due to our history, we have interacted with office suite projects from the long tail of this market more than we have interacted with the market leaders. This history risks leading us to focus on the wrong problems.

In order to achieve the goals of our foundation, we need to reset our expectations. Revealed consumer preferences suggest there are only two cloud-enabled office suites that offer what users need: those of Microsoft and Google. We should aim high, and plan with the intention that we will provide credible alternatives for Microsoft and Google products that comply with our values.

Microsoft 365

Distinguishing features

It is Microsoft Office
Microsoft Office is considered the default office suite by most prospective users, and the Microsoft 365 web offering benefits from this association.

Feature-limited web version with streamlined user interface
Much like their sole competitor, the Microsoft 365 web versions offer a greatly simplified user experience which is optimal for everyday, quick document authoring. The user interface is stripped down, but looks visually similar enough to the desktop applications to be familiar to experienced users.

Full-featured desktop versions available for advanced users
The Microsoft 365 web versions do not replace the classic desktop versions. Both versions are provided to users, and the web version guides users to open documents in the desktop version for editing.

Cross-platform collaboration between web and desktop
Collaboration and cloud features are usable from both the web and desktop versions. Collaboration requires documents to be stored on either OneDrive or SharePoint.

Weaknesses

Web versions are based on a different codebase
Although the Microsoft 365 web applications visually resemble their desktop counterparts, to our understanding they are greenfield efforts. The web versions suffer from interoperability issues with the desktop versions, prompting user complaints.

Web versions are feature-incomplete
The Microsoft 365 web applications are missing features that are present in the desktop versions. Some of these features are obscure, but many aren’t (for example, dragging images to move anchors). The web version compensates for this by offering an easy transition to the desktop version for more intensive editing work.

No on-premises option
Since Microsoft discontinued the Office Online Server, it is no longer possible to host the web version locally. Using the web version requires Microsoft cloud services.

Limited data control
Microsoft 365 allows local and on-premises document storage (SharePoint). However, using collaboration features requires communication with Microsoft cloud services, even if the document is hosted on premises.

Google Workspace

Distinguishing features

Web-native
Google Workspace is a web application. It loads quickly, and the user interface is highly responsive.

Simple, streamlined user interface
As with Microsoft 365’s web versions, Google Workspace offers a feature-limited and streamlined user experience which is optimized for simple document editing tasks.

Ubiquitous
Google Workspace is tied/bundled with Google’s other services. It is automatically available to any user who has a Gmail account. Sharing and collaboration is as easy as sending an e-mail.

Documents aren’t files
Within Google Workspace, documents exist as abstract entities in a persistent cloud. Documents are always stored on the server in Google proprietary document formats.

Disadvantages

No native desktop version
Google Workspace is designed around a persistent internet connection. The primary application is a web application hosted on Google servers. The mobile versions are hosted locally, but have artificially limited offline modes.

Feature set is extremely limited
Google Workspace is missing all but the most trivial document formatting features. Although this is sufficient for many use cases, it is not a complete office solution. In practice, Google Workspace must be supplemented with standalone Microsoft Office licenses in commercial deployments.

No on-premises option
Google Workspace is a cloud-native web application. It was designed around Google’s cloud services, and cannot be separated from them.

No data control
Google Workspace does not allow local or on-premises document storage. Documents cannot be viewed or edited without uploading them to Google’s servers. For regulatory compliance reasons, Google Workspace allows on-premises backup of cloud documents, but there is no official way to restore those backups.

Lessons

We are LibreOffice

LibreOffice is the most successful free and open source office suite. Our brand is valuable, and our user base is dedicated. While we do not have an advantage over Microsoft in this area, this is also not a weak starting position. Many users and organizations will evaluate our offering simply due to name recognition. It is therefore crucial to avoid tying our brand identity to products or technical approaches that do not show clear trajectory toward meeting the needs of users and operators.

Availability rather than interoperability

On the desktop, we have long considered Microsoft Office interoperability a key obstacle for broader LibreOffice adoption. This assumption does not apply to the cloud-enabled segment. Google Workspace has achieved a large market share despite lacking support for Microsoft Office document formats (only lossy import and export). If Google Workspace is not hindered by their Microsoft-incompatible document models based on proprietary file formats, we will not be hindered by ours based on open standards.

With cloud-enabled office suites, document exchange between users of different office suites is achieved by sharing links that can be opened in standard web browsers. This is important to support.

Same code – feature complete

By reusing the existing LibreOffice source code to drive the web version, we can avoid the compatibility issues and feature set limitations present in the major competing products. A feature-limited user experience is then a choice we can allow users to make, rather than forcing it on users due to implementation strategy.

Streamlined web experience available

Both major competitors treat their web versions as a secondary workflow, to be supplemented with a complete desktop office suite. Their user interfaces are optimized for quick viewing and editing, either on a secondary device or while quickly browsing files stored in a cloud storage application. We should consider also displaying such a streamlined user interface, at least by default; both major competitors collect user telemetry, so it is reasonable to suppose their decision was evidence-based.

Cross-platform collaboration between web and desktop

This is a key differentiator for Microsoft 365. We should provide the same capabilities. All cloud-based features should be equally usable from the desktop version as the web version.

Responsive user interface

Users can interact with Microsoft 365 and Google Workspace documents without blocking on client-server communication. Editing is smooth, and has a near-desktop feel. We should aim to provide a similar user experience.

On-premises hosting – no privileged cloud provider

Neither major competitor offers on-premises options for hosting or cloud services. This is an area where we can distinguish ourselves, but it is also a challenge. By privileging their own cloud services, Microsoft 365 and Google Workspace can simplify distribution and make cloud features available to users regardless of technical expertise.

In order to close this capability gap, we should design toward a world of many small clouds. We should encourage the proliferation of LibreOffice server components by designing them to be easy and inexpensive to host. Our client-server architecture should be designed to respect the limited computational and bandwidth resources of small cloud operators, and we should perform all expensive computations on the client side.

The desktop application should be designed with the assumption that users will adopt multiple cloud providers for different purposes, including on an ad hoc basis for one-time document collaboration.

Development Plan

Overview

Developing a web and cloud product is a major undertaking. In order to minimize project risk, this development plan is based around decomposing the project into multiple independent initiatives. Each initiative will have separate milestones and deliverables. We must complete all initiatives in order to have a competitive cloud strategy, but each initiative is an independent useful feature.

Responsive user interface

LibreOffice already offers multiple user interface styles. This initiative will expand on that prior work to offer a new optional user interface mode which is optimized for web and touch-based devices. The user interface should scale appropriately based on window dimensions, and should make uncommon actions possible, if not easy.
Specific user interface design and evaluation will be conducted as part of this initiative. This work should include closer studies of our major competitors.
Once the responsive user interface implementation is complete, it will be used as the default configuration for both the web and mobile distributions.

Web distribution using WebAssembly

We already have a working prototype of LibreOffice built for web browsers, which uses Qt and WebAssembly. This prototype is still in a rough state, but it demonstrates it is possible to create a version of LibreOffice for web which does not require large-scale duplication of effort or resource-intensive server components.

This initiative will build upon this WebAssembly prototype. Since the WebAssembly prototype already works, initial efforts in this area will mostly focus on polish and packaging, in order to create a minimally viable web-deployable version of LibreOffice.

Mobile distributions based on desktop version

This initiative will build upon ongoing research efforts to standardize on the Qt 6 VCL backend. The initial focus will be creating some minimally functioning builds of the desktop version of LibreOffice for Android and iOS emulators. Once working, these versions can be incrementally improved.

Document server and integration with desktop version

LibreOffice already supports a variety of remote file services. This initiative will build upon that prior work to introduce an easy-to-host LibreOffice first-party document server. This initiative will also include creating a more streamlined user experience for interacting with these servers.

This initiative will include research to identify best practices and any open standards we can adopt. The document server should be designed in a manner that can be easily extended or incorporated into other services.

Client-server collaborative editing

This initiative will study and incrementally implement client-server collaborative editing in the LibreOffice desktop version. For development purposes, we will initially use direct TCP/IP connections between LibreOffice instances. Eventually, the document server will be modified to coordinate collaboration and act as a proxy between clients.
There are outstanding proposals to develop peer-to-peer collaboration, in addition to adopting other distributed networking and file sharing technologies. That is an excellent vision for LibreOffice. However, that vision touches on many active research areas in computer science. At this time, it is not entirely clear how we should best approach executing on those proposals.

In order to reduce total project risk, this proposal suggests first implementing collaboration using a client-server network architecture, with a single authoritative state.
Support for client-server collaboration is not exclusive of peer-to-peer collaboration. The software changes we make to support client-server collaboration are also necessary for peer-to-peer collaboration. By making these changes separate of the hard peer-to-peer research problems, we will reduce the risk of a future peer-to-peer project and make it more attractive for development.

[1] Microsoft Office Online Server was discontinued in October 2025.

UPDATE: We have opened a discussion here: https://community.documentfoundation.org/t/web-and-mobile-development-strategy-proposal/13729

A number of journalists read last week’s piece as an attack on Microsoft. We want to explain what they walked past.

Whenever we address the contrast between ODF and OOXML, some people perceive it as a campaign against a company. It is not. We are trying to do something far more useful: to make the structural problem with the standard document format clear to those who have to live with it: public officials, educators, and above all, individual citizens.

All these people find themselves facing a problem they did not create, but which affects them daily, and of which they are often the unwitting victims, every time they create a document or receive one.

The least we can do – and in fact we have been doing it for twenty years, though until now almost no one has listened – is to explain, clearly and without drama, how the problem arose, why it persists, and why ODF is the only way out. It is an educational and selfless goal – we do not sell software, so we have no commercial interest to protect – and not an attack on a company.

The problem concerns the current document landscape, based almost exclusively on a proprietary format controlled by a single company, and what we could have had instead: a standard format controlled by an independent community of stakeholders.

Microsoft features in this story because of the rational-monopolist behaviour it has exhibited since 2006, during and after the standardization of the proprietary OOXML format: first promising the standard and then doing everything possible to ensure it was first ignored and then forgotten, quietly but with extreme determination. All of this to protect a market share now worth over $30 billion, which would have been at risk of erosion if the document format had been genuinely standardized: migration to any other office suite would then have been free of cost and complexity.

Today, most organizations – public agencies, supranational bodies, companies – and most individual users face a problem that, had everyone listened to independent experts between 2006 and 2008, would never have existed. The international standards system and national governments allowed a single vendor – rather than the community of developers, systems analysts and standards scholars who raised objections – to set the terms under which documents would be archived. That vendor chose its own proprietary format.

The problem, in other words, was created by institutions – ISO, national standards bodies, public officials and ultimately politicians – who approached the choice of format for public documents in a completely uncritical manner. They trusted the process despite repeated and legitimate protests about its transparency, and never thought to perform a simple file analysis that would, in a few minutes, have raised more than a few doubts. The industry then followed the vendor’s lead, for convenience, because it expanded the business – without weighing the medium- and long-term consequences for institutions and individual users. What is troubling is that even a segment of the open-source industry went with the flow, and continues to do so, as shown by the fact that today only two open-source office suites – LibreOffice and Collabora Office – use ODF as their native file format.

If between 2006 and 2008 everyone had done their part, today there would be a single open, multi-vendor interoperability standard for office documents – our ODF – governed neutrally and implemented by all. Everyone would have benefited, because document exchange based on a true standard is completely transparent and independent of operating system and application software. Microsoft could have kept its own internal proprietary format as a mere implementation detail, invisible to users, because documents would have flowed seamlessly through the standard. An ideal world that never became reality.

Instead, the accelerated standardization of OOXML through ISO in 2008, against all technical objections, produced the OOXML Transitional format we use today: a temporary compatibility mode, explicitly defined as a bridge to be crossed once and then dismantled. It was not dismantled. It became the only variant used, at every level, by the majority of office suites. Today the vast majority of office documents worldwide – including the public documents of public institutions and of governments everywhere – are saved in a format that its own designers had declared provisional.

Even OOXML Strict would not solve the problem. Microsoft has never promoted it – part, as we have explained, of an understandable strategy – and none of those who were supposed to oversee the process ever requested or verified its implementation by the deadlines promised at standardization, from 2010 onward. But the deeper point is this: Strict is simply a different variant of the same single-vendor format. A standard is not open because its specification has been published. It is open when it is developed through a transparent process that no single company can control, and maintained by an independent community of users and implementers. Replacing Transitional with Strict changes the variant but leaves governance – which is what determines sovereignty – exactly where it was.

So when we advocate for ODF, we are not criticizing anything. We are trying to clarify a problem that was artificially created, and to ask why a problem that was artificially created is treated by most stakeholders – organizations, governments, companies and individuals – as an established fact of nature.

Attention to digital sovereignty is growing, even if resistance remains strong, because awareness of this issue – which should never have arisen in the first place – is still virtually nonexistent, not only among users but among industry professionals themselves.

We continue to believe ODF can regain the role it should have had after 2006, when it was approved – rightly – as an ISO standard, because it had every characteristic of an open standard. The Deutschland Stack restores that role to ODF, and we hope the German government’s decision will not remain isolated.

Any other choice is a choice of dependence on a single vendor

Digital sovereignty begins with the document format. Everything else – server location, hosting jurisdiction, procurement clauses – is downstream of this single decision. If the format is standard and open, the user controls the document. If the format is proprietary the vendor controls it, even when the file sits on the user’s own hard drive.

This is why LibreOffice, and its derivatives such as Collabora Office and Online, are today the only legitimate choice for governments, supranational bodies, businesses and organisations that want to protect the digital freedom of their users. Only software based on the LibreOffice source code – the LibreOffice Technology – uses ODF as its native document format. Every document saved, stored, retained and exchanged in ODF remains the exclusive property of its author, and remains so over the years.

ODF – Open Document Format, as the name says – was designed and developed in accordance with the characteristics of a true open standard: clearly documented, transparently developed by an independent body, properly versioned, built on existing standards, and stored in XML files that any user can read.

None of this applies to OOXML. The name is itself an oxymoron: XML stands for eXtended Markup Language, which is open by definition, but OOXML’s syntax is so complex that it is unreadable even to advanced users. The format was deliberately designed to become a sophisticated lock-in tool at a moment when Microsoft’s other strategies had already been uncovered and analysed.

The Transitional/Strict bait-and-switch

OOXML was approved as an ISO standard through a process that was an affront to transparency, ethics, common sense and respect for users. The format is documented in a way that discourages consultation – over 7,500 pages – and is developed by Microsoft behind closed doors in Redmond.

It is not versioned. It uses no independent standards. On the contrary, it relies on proprietary Microsoft formats wherever possible, in some cases formats that Microsoft itself had deprecated because the market rejected them. It is not even compatible with the Gregorian calendar. The XML schemas are nearly absurd in their complexity.

The bait-and-switch worked like this: “I swear it will be Transitional until 2010, very proprietary and very little of a standard, and after that only Strict, not very proprietary and very much a standard.”

The catch: Strict never materialised in practice. For years it lingered as a last-resort option that no one was meant to use, and it has now disappeared from the Save As options altogether. The standardised version of OOXML – the one ISO was told would become the real format – no longer exists as a user choice. Only Transitional remains.

A pity, because we would have had a laugh with Strict’s bugs. Excel has a thing for getting dates wrong (the (in)famous 1900 leap-year bug, inherited from Lotus 1-2-3 and never fixed), and when Excel gets dates wrong, no other software does it worse.

The political consequences

All of this is hard to grasp by looking at what happens on screen, because the document seems entirely harmless in its apparent simplicity. And yet all of it has been documented in detail since OOXML was first introduced, by independent experts who should have been heard, both by ISO and by those working in advanced technology.

Instead, ISO bought the Transitional/Strict story. And once ISO believed it, governments and politicians believed it too, rushing to adopt OOXML as a document format for fear that Bill Gates and Steve Ballmer might take offence and act accordingly.

In doing so, they placed citizens’ private data in Microsoft’s hands and reinforced a monopoly that was already evident before OOXML’s arrival, and that has become increasingly difficult to dismantle ever since.

The Microsoft ecosystem played its part in all this, and partner companies – SAP foremost among them – have always done everything in their power to push their users toward OOXML for data exchange, openly obstructing the use of the standard ODF format. An uneven struggle, by design.

Worse still, with just a few exceptions, even those who by virtue of their expertise should have recognised OOXML as the cornerstone of Microsoft’s new lock-in strategy fell for it. Some still write today: “we have to accept it, OOXML is an ISO standard.” This is not a serious position.

It is a deference with no rational basis.

Microsoft’s monopoly position is not founded on technological superiority but on the strategic foresight of Bill Gates and the lobbying machinery that flowed from it, deployed well ahead of its time.

The same deference has had consequences in the scientific community as well.

The HUGO Gene Nomenclature Committee was forced in 2020 to rename dozens of human genes – including SEPT1 and MARCH1 – because Excel kept silently converting their symbols to dates. Rather than going to Microsoft and demanding a bug fix, scientists preferred to throw years of established nomenclature down the drain to avoid upsetting Redmond. A revealing precedent.

Supporting ODF is not choosing ODF

There is a distinction that needs to be made plainly, because it is too often blurred, sometimes inadvertently, sometimes by design. Supporting a format is not the same as choosing it.

An office suite that saves OOXML by default is not supporting digital sovereignty, independently from the level of ODF support. It is an OOXML suite with an ODF import/export filter, which inherits all the OOXML based lock-in mechanisms: proprietary schemas, vendor-controlled evolution, hidden binary fragments, format-level dependencies on Microsoft’s roadmap.

Digital sovereignty lives at the native-format layer. Support describes what a piece of software can read. Native format describes what it is. The native format determines the legal and technical character of every document the user creates.

A commitment to “improve ODF support” is not a commitment to digital sovereignty. It is a commitment to keep ODF as a guest in someone else’s house.
This distinction matters for any project, coalition, or procurement decision that claims a digital sovereignty objective. The meaningful question is never whether ODF is supported – it almost always is, at some level – but whether ODF is the native format, chosen and committed to as such.

If the answer is anything other than yes, the sovereignty claim is provisional at best.

What digital sovereignty actually requires

The only viable path to digital sovereignty today is to use ODF as the native document format, and OOXML as the interoperability format for exchange with users who – out of lack of information, or pure convenience – continue to use the proprietary format, and share ownership of their own files with the vendor.

Anything else is false digital sovereignty. Control over a document and over the information it contains depends first on the format and only afterwards on the location of the server.

Standard, open format: the user is in control. Proprietary format: the vendor is in control, even if the document sits on a PC on the user’s desk.

This should be self-evident to anyone working in open source software, because it follows directly from its principles.

A proprietary document respects neither Freedom 1 (the freedom to study and modify) nor Freedom 3 (the freedom to improve and redistribute), as it is not not documented in a way which makes the source code readable and it is not developed through a transparent process.

The decision to adopt OOXML as the native format runs counter to the interests of governments, supranational bodies, organisations of every kind and enterprises. But above all, it runs counter to the interests of users as it exploits their lack of information rather than investing in their education and in their digital sovereignty.

The choice of native format is not a technical detail to be deferred or finessed. It is the choice. Any project that treats it as something less is not supporting digital sovereignty. Full stop.

Most people, including many competent software developers, think of a digital document the way they think of a sheet of paper: an inert object that holds words and pictures, indifferent to the tool used to open it. This intuition is wrong, and the consequences of getting it wrong shape everything from vendor lock-in to cybersecurity to the long-term readability of public records.

A digital document is not paper. It is a piece of software.

The HTML parallel

The clearest way to see this is to think about a web page. When you visit a website, your browser receives a file – an HTML document – and executes it. It parses the markup, applies styling rules, runs embedded scripts, fetches additional resources, and assembles the result into something you can read. The page you see on screen is not a static image transmitted from the server, it is the output of a small program that your browser ran on your behalf.

Nobody disputes that a web browser is software. Yet the HTML file it consumes is also, in a meaningful sense, software: a set of instructions describing what should happen when the file is opened. Change the instructions, and the rendered page changes. Withhold the specification of how the instructions should be interpreted, and only the party holding the specification can guarantee a faithful rendering.

It is worth remembering that the openness of HTML did not happen by accident, and was nearly lost. In the early 2000s, Internet Explorer 6 commanded around ninety per cent of the browser market, and Microsoft used that dominance to push proprietary extensions to HTML, CSS, and the document model: non-standard tags, behaviours, and filters that worked only in their browser.

Web developers, desperate to reach users, began coding both to Internet Explorer and to the standard, carrying the cost of that double work themselves, while the vendor reaped the benefit of lock-in either way. The open web did not fragment, but only because developers absorbed the cost of holding it together. Had they stopped, HTML would have quietly become whatever Microsoft shipped next.

It took a sustained effort by the W3C, by competing browsers such as Firefox, and by the community of standards-conscious developers to pull the web back onto open ground. Had that effort failed, HTML today would not be a shared language, but a Microsoft product. The web survived because the standard was defended. Document formats have not always been so lucky.

An office document – a DOCX, an ODT, a PPTX, a PDF – works exactly the same way. It is a structured file containing instructions: this text in this font at this size, this image embedded here, this table laid out this way, this field recalculated automatically, this macro executed on opening. When you “open” the document, an application reads those instructions and runs them. The page you see on screen is the output of a program – the office suite – executing the instructions contained in the document.

The document is the code. The office suite is the interpreter. Together they are a software system, and the user is the one running it, usually without realising.

Why this matters: lock-in is a software property

Once you see a document as software, the question of file formats becomes the question of programming languages. A proprietary file format is a programming language whose specification is owned, controlled, and modifiable at will by a single vendor. The “programs” written in that language – your contracts, your invoices, your books, your public administration archives – can only be reliably executed by software that vendor authorises.

This is the structural mechanism of lock-in. It is not a side effect of user habit or training cost. It is the direct consequence of writing your documents in a language whose grammar belongs to someone else. The moment the vendor changes the grammar – and proprietary formats change constantly, at least with each new product release, but often even more frequently – your existing documents may render differently, lose features, or stop opening altogether. You do not own the language in which your own records are written.

Open standards such as ODF exist precisely to break this dependency. ODF is a publicly specified, independently maintained format whose grammar belongs to no single vendor. Any developer can build a faithful interpreter. Your documents, written in an open language, remain readable regardless of what any single company decides.

Why this matters: attack surface is a software property

The second consequence is security. Software has vulnerabilities, paper does not. The moment we admit that a document is software, the long catalogue of OOXML-related security advisories becomes unsurprising, and inevitable, indeed.

Office document formats are ferociously complex. OOXML in particular runs to thousands of pages of specification, with macro languages, embedded OLE objects, external references, conditional formatting logic, and a substantial layer of binary legacy compatibility. Each of these is a way in for an attacker. A document that arrives by email and “just opens” can run hidden code, download malicious content from the internet, exploit weaknesses in how the file is read, and from there take control of the computer itself. The pattern recurs year after year, vulnerability after vulnerability, because the document is doing what software does: running.

A simpler, more rigorously specified format is harder to weaponise. This is not a guarantee – any sufficiently expressive format has risks – but the principle holds: complexity is the friend of the attacker, and proprietary complexity, never fully documented to outside parties, is the best friend of all.

Why this matters: freedom is a software property

If a digital document is software, then the framework we apply to software ethics applies to documents. The Free Software Foundation defines four freedoms: the freedom to use the program for any purpose, to study and modify it, to redistribute copies, and to distribute modified versions. The second and the fourth – Freedom 1 and Freedom 3 – require access to the source.

A document in a proprietary format violates these freedoms in exactly the way proprietary software does. You cannot fully study how it will be interpreted, because the specification of the format is either secret, partial, or subject to unilateral change. You cannot reliably build or share modified tools to interpret it, because the format’s owner retains the right to declare your interpreter non-conformant. The “source code” of the document – the full and stable specification of what its instructions mean – is not in your hands.

This is not a metaphor. It is the same dependency, structurally, that makes proprietary software unacceptable for any organisation serious about digital sovereignty. The document, as software, inherits the politics of the format it is written in.

The conclusion is unavoidable

A digital document is a small program. It runs every time it is opened. The language it is written in determines who controls it, who can attack it, and whether its readers are free.

Treating documents as paper has allowed a generation of policymakers, public administrators, and even technologists to overlook the fact that the choice of document format is a choice of software dependency, and a choice of whose grammar governs our written record. There is no neutral format, just as there is no neutral programming language. There are only formats whose specifications are open, stable, and collectively governed, and formats that are not.

We have learned, slowly and at cost, to demand openness in our software. The document is software. The demand is the same.

Berlin, 12 May 2026 – The Document Foundation announces the release of LibreOffice 25.8.7, the final maintenance release of the LibreOffice 25.8 family, available for download at www.libreoffice.org/download [1]. Users of LibreOffice 25.8.x should update to LibreOffice 26.2.x as LibreOffice 25.8’s end of life will be on June 12, and after that date the software will not receive additional security updates.

LibreOffice 25.8.7 is based on LibreOffice Technology, which enables the development of desktop, mobile and cloud versions – either from TDF or from the ecosystem – that fully supports the two document format standards: the open ODF or Open Document Format (ODT, ODS and ODP), and the closed and proprietary Microsoft OOXML (DOCX, XLSX and PPTX).

Products based on LibreOffice Technology are available for all major desktop operating systems (Windows, macOS, Linux and ChromeOS), mobile platforms (Android and iOS) and the cloud.

For enterprise-class deployments, TDF recommends a LibreOffice Enterprise optimized version, with dedicated value-added features and other benefits such as SLAs and security patch backports for three to five years. Additional details at: www.libreoffice.org/download/libreoffice-in-business/.

English manuals for the LibreOffice 25.8 family are available for download at books.libreoffice.org/en/. End users can get first-level technical support from volunteers on the user mailing lists and the Ask LibreOffice website: ask.libreoffice.org.

LibreOffice users, free software advocates and community members can support The Document Foundation and the LibreOffice project by making a donation: www.libreoffice.org/donate.

[1] Fixes in RC1: wiki.documentfoundation.org/Releases/25.8.7/RC1. Fixes in RC2: wiki.documentfoundation.org/Releases/25.8.7/RC2. Fixes in RC3: wiki.documentfoundation.org/Releases/25.8.7/RC3.

Berlin, 8 May 2026 – Twenty years ago this week, on 3 May 2006, the Open Document Format cleared its Draft International Standard ballot at ISO/IEC JTC 1/SC 34 with unanimous approval. On 30 November 2006 it was published as ISO/IEC 26300. Two decades later, ODF remains what it was on the day of its ratification: the only open, vendor-neutral, freely implementable international standard for office documents in existence.

Everything else on the market is a vendor format with a standards number attached.

That distinction was contested in 2006. It is not contestable in 2026. The competing format pushed through ISO in 2008 – under a fast-track process whose abuses are now part of the documentary record of standards governance – has since splintered into a Strict variant almost no implementation actually uses and a Transitional variant that preserves, by design, the undocumented behaviours of a single vendor’s legacy products. A standard that exists to encode one company’s bugs is not a standard. It is a moat with a certificate.

ODF has no Transitional mode. It has no undocumented behaviours. It has no vendor whose commercial roadmap can quietly rewrite what conformance means. The specification is publicly available at no cost from ISO and from OASIS. The schemas are auditable. The implementations are multiple, independent, and free. This is not advocacy language. It is the working definition of a standard, and ODF is the only office-document format that meets it.

The political weather has finally caught up with the technical reality. Germany’s federal administration has mandated ODF through the Deutschland-Stack. The European Commission’s own services are under sustained pressure – including from this Foundation – to align procurement with the open-standards commitments the Commission itself has signed. Brazil has legislated open formats into its educational system through Lei 15.211/2025. The pattern is the same on every continent where public bodies have stopped to ask the only question that matters: in what format does a society keep its own records, and who decides when that format changes?

For twenty years, the answer to the second question – for any administration that chose ODF – has been: we do. For any administration that chose the alternative, the answer has been: the vendor does, and the administration will be informed.

“ODF is the document format of a public that has decided not to outsource its memory,” said Florian Effenberger, Executive Director of The Document Foundation. “The governments now mandating ODF are not making a technical choice. They are reclaiming a sovereignty they should never have surrendered.”

The implementation landscape reflects the same divide. LibreOffice, developed by The Document Foundation and a global community of contributors, uses ODF as its native format and is the reference implementation of the standard. Collabora Online extends ODF support to enterprise and cloud deployments. Together they constitute the working core of the ODF ecosystem. Other office suites – including those that market themselves with the vocabulary of openness while defaulting to a competitor’s vendor format – are not part of that ecosystem and should not be confused with it.

The Document Foundation will mark the twentieth anniversary across 2026 with a programme of publications, policy briefs, and community events. The LibreOffice Conference will dedicate a full track to ODF, coordinated with the OASIS Technical Committee, which is currently advancing version 1.4 of the specification. Material on the history, the structural design, and the policy implications of ODF will be published throughout the year on the TDF blog.

A standard is worth what it still does after the people who wrote it have moved on. ODF is read, written, and trusted by software none of its original authors imagined, on hardware none of them could have specified, in jurisdictions none of them lobbied. It has aged the way public infrastructure is supposed to age: quietly, reliably, and in everyone’s hands.

That is the anniversary worth marking. Not the certificate from 2006, but the twenty years of evidence since: evidence that the open-standards bet was the right one, that the alternative was the trap its critics warned it would be, and that the governments now choosing ODF are not innovating. They are catching up.