The history of the standardisation process of the proprietary OOXML format

All the posts we have dedicated to the OOXML format – and many of those we will dedicate to it in future – analyse the reasons why it is a proprietary format despite having been approved by ISO as a standard, open format. However, they do not address the reasons behind or the details of the standardisation process.

This is a gap we hope to fill with this post, which summarises the events that took place between the standardisation of the ODF format – a standard and open format – and the standardisation process for OOXML, as well as the process itself, which was completely broken in every respect, from methodology to procedure.

Microsoft had begun work on an XML-based document format around the year 2000, with the aim of modernising the obsolete DOC, XLS and PPT formats, which were simply the serialisation (writing) of memory content to disc, and as such were no longer in line with the evolution of Microsoft Office.

The aim was certainly not to develop a standard format, not least because the echo of Bill Gates’ internal memo – “allowing Office documents to be rendered very well by other people’s browsers is one of the most destructive things we could do to the company; we have to make sure that Office documents depend on proprietary capabilities” (slightly abridged version of the original memo) – had not yet died down.

Consequently, during the ODF standardisation process, Microsoft had stated that it would not support the ODF standard format, as it was not in its own interests.

In early 2006, however, the Commonwealth of Massachusetts – one of the historic states of the confederation – announced that it would adopt ODF for all public documents, so that they would be independent of software from a single vendor.

This decision provoked a reaction from Microsoft, which could not tolerate the fact that a US state was adopting a standard, open format developed outside its control, which benefited users rather than its own commercial interests.

The story of the ISO/IEC 29500 “standard”

The battle over the ISO/IEC 29500 “standard” – the ISO standardisation of Microsoft’s Office Open XML format between 2006 and 2008 – is a perfect example of a broken standardisation process.

It is not an exceptional case, but it has been thoroughly documented and offers important food for thought for all those who continue to maintain that the OOXML format is a standard.

The story began in December 2006, when Ecma International – whose Technical Committee 45, responsible for the project, at the time was chaired by two Microsoft employees – submitted the OOXML specification to the ISO/IEC JTC1 (Joint Technical Committee) of ISO/IEC for adoption as an international standard under the “fast-track” procedure, designed for tried-and-tested specifications requiring only administrative ratification.

The decision to submit a 6,000-page specification – one of the longest ever submitted to ISO – via a process designed for short and fairly well-established documents had a decisive impact on the nature of the review to which the standard was subjected.

In September 2007, the proposal was rejected by ISO members due to votes against it or substantial technical objections to its approval. Brazil raised more than sixty technical objections regarding the use of non-standard date formats and inadequate language support. India contested the incompatibility with the ISO ODF standard. France proposed splitting the specification into a “clean” core and a compatibility layer for pre-existing systems. Norway submitted twelve specific technical observations.

These concerns were not mere complaints but went to the heart of the matter: namely, whether the OOXML format specifications could meet the fundamental requirements of an international standard.

Issues at national standardisation committees

What followed this vote was the subject of appeals by numerous national standardisation bodies. In many countries, there were widely documented reports of serious irregularities in the composition and conduct of the national technical committees.

In Portugal, new members appeared, the majority of whom were identified as Microsoft business partners. In Italy, the number of members rose from 5 to over 80 in just a few months, and among them were one law firm and a PR agency working for Microsoft on topics that had no connection whatsoever with the document formats, and several Microsoft business partners.

In Norway, the committee chair resigned in protest.

Martin Bryan, coordinator of the ISO working group, stated publicly that the influx of these new members, whose sole interest was to speed up the OOXML approval process, had caused several important procedural votes to fail.

Microsoft sent an official letter to the Spanish national body claiming that the Andalusian regional government supported OOXML, a claim which was promptly denied by the Andalusian government itself, which also lodged a complaint.

As interested observers of the process, and as members of various national standardisation bodies, we can add that all this stemmed from the head-to-head competition between Microsoft and IBM, which at the time were focused solely on competing with one another on the basis of their financial strength and completely ignored the interests of users – a situation that is now penalising us at every level.

Had the two companies invested the same energy in developing a cross-platform standard format, building on what had already been approved – namely ODF – and improving those parts where it was not yet fully developed, instead of filling the committees with “relatives and friends”, we would be in a completely different situation today, and we would not have to fight for our digital sovereignty.

The Ballot Resolution Meeting in Geneva

In February 2008, the Ballot Resolution Meeting (BRM) was convened in Geneva, during which representatives of national bodies were expected to examine the thousands of proposed amendments to the 6,000-page document in just one week. An unachievable goal.

Many national bodies reported that they had been unable to examine the actual text on which they were supposed to vote, as the final version of the specification had not been submitted. The BRM coordinator, Dr Alex Brown, subsequently stated publicly that failing to make the final text available to national bodies during the appeal period had been irresponsible.

The standard was approved in April 2008, narrowly meeting the required threshold. Appeals lodged by South Africa, Brazil, Venezuela, India and other countries against procedural irregularities were rejected by the ISO Technical Committee. A post-approval analysis revealed that, during the BRM, Microsoft employees and “partners” outnumbered representatives from every other organisation by a ratio of approximately ten to one.

The OOXML format today

Microsoft launched Office 2010, implementing not the approved “Strict” variant of ISO 29500, but the earlier “Transitional” variant rejected by ISO in the September 2007 vote, which had been deemed unsuitable for use in new documents. Alex Brown, the BRM coordinator who had overseen the approval, publicly accused Microsoft of acting in bad faith.

The “Transitional” variant of the OOXML format is the one used by all users of Microsoft Office and Microsoft 365, as well as by clones of the two suites such as OnlyOffice, WPS Office and Euro-Office. The “Strict” variant has disappeared from discussions and is the last – and most obscure – option in the format menu.

The responsibilities of standardisation bodies

The case of the ISO 29500 standard demonstrates that standardisation processes, however well designed, can be manipulated by companies with sufficient resources and motivation.

The fast-track procedure was abused. The composition of the national committee was manipulated. The procedural rules were interpreted in such a way as to favour the proposer. The sheer volume of the specification made a genuine technical review by independent experts practically impossible within the available timeframe.

Following approval, a variant of the standard different from the one approved was implemented, without any consequences. Indeed, we can legitimately argue that the advantages the company derived from this failure to comply with the standard were actually rewarded by the market, and were not sanctioned by any authority at any level.

The conditions that allowed ISO 29500 to develop as it did – the concentration of resources, the decisive influence of commercial strategies and objectives, and the asymmetry in investment between large and small companies – were not addressed by the reform of the JTC1 “fast-track” procedure following the OOXML scandal.

Standards bodies are, nominally, neutral arbiters – forums where conflicting interests negotiate shared solutions – but in practice their neutrality is always contested and never guaranteed.

The companies that invest most heavily in the standardisation process – sending more representatives to meetings, funding the secretariats, and having the resources to comment exhaustively on every draft – are also those that exert the greatest influence over the processes.

This does not mean that standardisation bodies are subject to pressure or corrupt, as most operate with a sincere commitment to their mission.

It does, however, mean that the conditions underpinning good standards are not automatic, but require the active participation of various stakeholders – governments, civil society organisations and the academic community – whose interests are not aligned with those of commercial companies, as well as a set of rules that prevent any single company from dominating the process.

Above all, they require a culture within the standards community that takes the principles of reusability, transparency and genuine interoperability seriously as values, and not merely as rhetorical, superficial commitments, which conceal specific commercial strategies.

The Politics of Standards

Standards are technical documents drafted by engineers and discussed in committees before being implemented in code. However, to discuss them only in technical terms would be to overlook an essential aspect of their nature and function.

In fact, standards are also – and above all – political tools because they define market players, determine the direction of development, and establish the interests served by the ecosystem. In other words, they underpin the market’s power relations.

What a standard does

A standard is a coordination mechanism that allows multiple independent parties, such as software developers, hardware manufacturers, content creators, governments and businesses, to collaborate without having to negotiate the terms of their interaction every time.

Like a language, a standard enables communication with everyone who speaks it. It is an immensely valuable promise of universal communication, which is why standards are so important in computing, where the network effects of compatibility multiply rapidly.

However, a standard also defines the conditions for participation.

A simple, transparent standard based on widely available knowledge can be implemented by multiple parties without creating inequality.

In contrast, a complex, deliberately obscure standard that requires specific expertise can only be implemented correctly by those who defined it, creating inequality.

Therefore, the complexity of a standard acts as a barrier, determining who can access the market and the balance of power within it.

Open ecosystems

An open ecosystem does not depend on a document containing the specifications of the standard, but rather on any stakeholder’s ability to implement the standard fully and correctly in accordance with the specifications, without resorting to undocumented behaviour or reverse engineering.

This requires the specifications to be written clearly, to allow for only one interpretation, and for the standard not to depend on behaviours defined by the reference implementation, which would make the latter a mandatory dependency. It also requires the standard to be stable enough to prevent compliant implementations from becoming obsolete due to silent revisions.

When all these conditions are met, the standard can be implemented by anyone, even those who played no part in its creation. Universities, small businesses, open-source communities, government agencies, and individual developers can all produce compliant software.

Competition is possible based on the quality of the implementation rather than proximity to the standard’s authors or reverse engineering. The standard provides a foundation upon which anyone can build.

Closed ecosystems

While the closure of an ecosystem through a standard may be accidental, it is usually intentional and based on a series of fairly easy-to-list mechanisms.

The first mechanism is unnecessary complexity. When a standard defines its own solutions to problems that already have valid, widely implemented solutions, it forces other players to reinvent the wheel. Every proprietary subsystem is a new element that increases costs and often artificially limits compatibility.

The second mechanism is underdetermination. When specifications are ambiguous or limited, different implementations produce different results. When a document is displayed slightly differently, users always blame the second application rather than the format. This is an extremely insidious form of lock-in.

The third mechanism is extensibility. If the specifications permit the addition of proprietary extensions, the document is technically compliant with the standard, but only one programme can display it correctly. In this case, the standard merely covers a proprietary system.

In addition to these three mechanisms, there is direct or indirect influence over standardisation bodies. Direct influence occurs when the vendor can influence the standardisation process itself, shaping the compliance requirements to match the behaviour of their own application. Indirect influence occurs when the vendor can influence other members through factors external to the standardisation process.

The stakes beyond software

The consequences of open and closed standards affect more than just software developers.

For example, a government that archives its documents in a format that can only be handled correctly by a specific piece of software is, in effect, dependent on the vendor that developed it. This means that the long-term preservation of public documents is subject to the commercial decisions of a private company.

Cultural institutions, such as libraries, archives and museums, face the same problem over longer timescales. An open, standardised format is more likely to remain readable over time than a proprietary format whose continued support depends on the strategic priorities of a single supplier.

For developing economies and public-interest organisations with limited resources, open standards provide a vital infrastructure that ensures equal access.

Reading the technical as political

When evaluating a standard, technical details become political.

Using #RRGGBB for colours rather than a proprietary system is not an aesthetic choice; it affects who can implement the format and who benefits from the ecosystem it creates.

Adopting the ISO 8601 standard for dates rather than a serial system inherited from a single piece of proprietary software based on a fifty-year-old bug is choosing interoperability over continuity with a proprietary past.

These choices add up.

A standard that consistently aligns with open and established practices rather than proprietary reinvention on the basis of multiple decisions of this kind is fundamentally different from a proprietary format that constantly does the opposite, even though both produce documents that appear identical on screen and both bear the label ‘open standard’. This label means very little.

What matters is whether independent implementers can develop fully compliant software and whether the ecosystem is genuinely accessible to all who wish to participate. Ultimately, the standard must serve the interests of users rather than the company that defined it.

These are political issues which deserve to be discussed as such.

LibreOffice comes to the rescue of Microsoft Publisher users

Yesterday, MS Publisher users joined the millions of users who have been abandoned – or forced into a completely unjustified update – by Microsoft over the years, alongside those using Office LTSC 2021 and Office 2021. Consequently, anyone who has purchased a Microsoft 365 subscription will no longer be able to open their PUB files.

For millions of schools, parishes, associations, small businesses and local authorities, this is a major problem. For over thirty years, they have been producing newsletters, leaflets, programmes, posters and calendars using Publisher. From today, these documents are in a proprietary format, the only fully compatible application for which has been abandoned by the very company that created it.

What Microsoft suggests

Microsoft suggests converting PUB files to PDF format for viewing and printing, and to DOCX format for editing. In reality, neither of these represents a solution to the problem.

PDF preserves the layout but is not designed to be edited. DOCX can be edited, but Word is not a page-layout tool, so complex files lose their formatting during conversion.

In both cases, users are asked to transfer content from one vendor-controlled proprietary format to another vendor-controlled proprietary format – which is, in fact, the same vendor. This is because documents are regarded as a by-product of the application, rather than as information belonging to those who created them.

For Microsoft, therefore, it is perfectly normal for access to content to disappear along with the application. This is a fact that should raise more than a few questions, but it seems to go unnoticed, to the extent that many Microsoft users claim this problem does not affect them.

The free software community has solved the problem

Publisher’s PUB format is not an open standard, so the developers working on the Document Liberation Project have reverse-engineered it and created the libmspub library, which is used by LibreOffice and Scribus to import Publisher files. This is to enable MS Publisher users to continue reading their own documents regardless of Microsoft’s decisions.

This means it is possible to open PUB files using free software and save them in the OpenDocument Format (ODF), the only standard, open format for office documents, which is not dependent on any single application or company. Alternatively, they can be opened with Scribus, which is open-source desktop publishing software, but does not use a standard document format.

LibreOffice Draw is the quickest way to open, view, edit and manage Publisher documents, and although it is not a desktop publishing application, it can be used for small multi-page documents, such as newsletters, or for single-page documents of any format.

A lesson to bear in mind

MS Publisher is not the first Microsoft application to disappear from the market, and it certainly won’t be the last. Each time, users are faced with the same question: who controls access to my documents? If the format is proprietary, the answer is: the vendor. If the format is standard and open, such as ODF, the answer is: the user.

If you are responsible for documents in a public sector organisation, a school or an association, now is the time to check whether your file format is proprietary and dependent on a single vendor’s application, so that you can plan the transition to an open standard format whilst it is still possible to open them.

The LibreOffice community is here to help you.

LibreOffice 26.8 and interoperability: preserving what cannot yet be read

LibreOffice 26.8 adds basic support for importing and exporting a range of chart types that Microsoft Office includes in OOXML files: box-and-whisker, funnel, Pareto, radial, treemap and waterfall charts. LibreOffice is unable to display or edit these charts, but it does recognise them, informs the user that the chart type is not yet supported, preserves the underlying definition unchanged, and rewrites it when the file is saved.

At first glance, this appears to be an admission of incompleteness, whereas it is actually an example of what implementing a proprietary format entails when the aim is interoperability – for the benefit of users, rather than a commercial strategy that treats users as mere tools.

What happened

Microsoft added these chart types to Office from 2016 onwards, storing them in a namespace generally referred to as ‘chartex’. The namespace is not part of the ISO/IEC 29500 text approved as an international standard, but is documented separately in Microsoft’s extension documentation.

This is entirely legal and perfectly normal commercial behaviour: a vendor improves its product and the file format evolves accordingly. The consequence, however, is that the format in everyday use is no longer the one that was standardised. The ISO number continues to be cited in tender documents and policy documents, but the files being exchanged are different.

For any implementer other than the vendor, this creates a permanent state of delay. This is not a one-off gap to be bridged with sufficient effort, but a structural delay, as the specifications are in the hands of a vendor that does not publish its release schedule, with priorities defined according to commercial criteria.

Three possible responses

An office suite that encounters a chart it does not recognise has three options:

  1. It can reject the file. This is an honest but pointless solution: the user is left with a document they cannot open and concludes that the software does not work.
  2. It can discard what it does not understand. The file opens, the chart disappears, and the user only realises this when the document is forwarded to a colleague and the chart is no longer present. This is the most damaging outcome, as the loss occurs silently and the blame falls on whoever opened the file last.
  3. They can retain what they are unable to display. The user is informed that this type of chart is not supported, so they see a placeholder rather than a blank space, and the underlying definition remains intact when the document is transferred from one application to another. The document is restored in full when returned to the source application.

LibreOffice 26.8 adopts the third option, the only one of the three that respects the fact that the document belongs to the user rather than to the software – or, indeed, to the company that develops the software.

Unfortunately, there is a limitation, and this is an exception. Charts with regional maps contain extensive geographical information that LibreOffice is unable to preserve. The chart type survives the import-export cycle, but very little of its content remains intact.

Why this is important beyond charts

The Chartex case is of limited scope. The model, however, is not.

All organisations whose documents are written in a format controlled by a single vendor accept a dependency they are unable to manage, because the specifications may change without notice, with the addition of features that are only understood by a single implementation.

Nothing untoward needs to happen for the organisation’s archives to become progressively more difficult to read by all other software.

The Open Document Format is not immune to change, but it changes differently. Revisions are proposed, discussed and approved by a technical committee at OASIS, whose work is public, and are published as version specifications that anyone is free to implement.

An implementer wishing to support ODF 1.4 can read the ODF 1.4 specification and put it into practice. This is the only difference, and it is sufficient.

The bidirectional preservation of unsupported features is what distinguishes a responsible implementation under current conditions, but it does not constitute an improvement on those conditions. LibreOffice is the only office suite to adopt this approach, in order to protect users and the content within their documents.

Why Digital Sovereignty Requires an Open Document Platform — and What That Actually Means

When governments and organisations talk about “digital sovereignty,” they usually mean one thing in practice: the ability to choose, control, and if necessary replace the software they depend on — without asking permission from a vendor.

It sounds simple. It rarely is.

Document software sits at the centre of almost every organisation’s operations. Contracts, reports, budgets, policy documents, public communications: they all live in files. And for decades, the format of those files — and therefore the tools required to open, edit, and share them — has been controlled by a single commercial entity. That is not sovereignty. That is dependency with a friendly interface.

LibreOffice Technology exists to make genuine sovereignty possible. Not as a promise, and not as a political statement — but as a technical architecture that removes the dependency by design.

This post explains what LibreOffice Technology actually is, why it is categorically different from a “free alternative to Microsoft Office,” and why it is the only open platform capable of supporting software that is fully compatible with the demands of digital sovereignty. It also reviews what several months of deployments, policy decisions, and one very public debate over what “sovereign” actually means have confirmed about that architecture since we first started making this argument.

Beyond the Application: LibreOffice Technology as a Platform

Most people who encounter LibreOffice encounter it as an application — a word processor, a spreadsheet editor, a presentation tool. That is a reasonable introduction, but it misses what makes LibreOffice Technology significant.

LibreOffice Technology is the underlying platform on which LibreOffice — and a growing number of other products — is built. It is a modular, open-source software framework for creating document applications. It includes rendering engines, import/export filters for dozens of file formats, scripting infrastructure, accessibility layers, and interfaces for integration with operating systems, cloud environments, and enterprise software stacks.

Think of it the way you might think of a general-purpose operating system kernel: the kernel itself is not what users interact with directly, but it is what makes everything else possible — and it is what determines whether the system is genuinely open or merely open-looking.

LibreOffice Technology is governed by The Document Foundation (TDF), a non-profit foundation incorporated under German law. Its source code is publicly available, its governance is transparent, and its development is carried out by a global community of contributors from dozens of countries and organisations — including Collabora, allotropia, Red Hat, and many others.

No single company controls it. No acquisition can change its licence. No pricing decision by a distant board can determine whether your organisation can keep using it next year.

That is what a platform for digital sovereignty looks like.

Open Standards Are Not Optional: The Role of ODF

Sovereignty over software is meaningless if the data is not equally free.

A document format is not just a technical specification. It is a commitment about who can read your files in ten years, which tools can process them today, and whether you are locked into a particular vendor’s upgrade cycle to maintain access to your own information.

LibreOffice Technology is built around the Open Document Format (ODF), an ISO/IEC international standard (ISO/IEC 26300) developed through an open, multi-stakeholder process. ODF defines how text, spreadsheets, presentations, and other document types are stored — in a way that any conforming application can read and write, regardless of who made it or on what platform it runs.

This matters in ways that are easy to underestimate. When a public administration stores its records in ODF, it is not dependent on any vendor to access those records in the future. When a hospital uses ODF for patient documents, it can switch tools without migrating data. When a ministry publishes a policy document in ODF, any citizen with any compliant application — on any operating system — can open it.

Contrast this with proprietary formats that, despite occasional published specifications, remain under the effective control of the companies that defined them. “Open enough” is not the same as open. Earlier this month, we set out a first version of what separates the two: a thirteen-criterion definition of what a genuinely open document format requires, from public specification and royalty-free implementation through to independent governance. That short version is only the opening statement — we originated this framework, and a fuller, more rigorous edition is in development, applying all thirteen criteria in detail to ODF, OOXML Strict, and OOXML Transitional in turn.

LibreOffice Technology’s commitment to ODF is not a preference. It is an architectural principle. The platform is designed around the assumption that the data belongs to the user, not to the software.

The Platform Others Build On

One of the clearest indicators that LibreOffice Technology is a genuine platform — not just a standalone application dressed up in platform language — is the ecosystem of products built on top of it.

Collabora Online, a cloud-native document editing solution deployed by enterprises, governments, and cloud providers across Europe and beyond, is built on LibreOffice Technology. Collabora’s 2025 merger with allotropia — whose engineering team brought deep WebAssembly and vertical-application expertise into the same organisation — is itself an example of how the ecosystem consolidates and grows without ever touching the underlying platform’s governance. Other commercial and community products remain in active development by organisations that have chosen LibreOffice Technology precisely because it provides a stable, open foundation they can build on without acquiring permission from or paying royalties to a gatekeeper.

This ecosystem diversity is itself a form of sovereignty insurance. If one vendor stops supporting a product built on LibreOffice Technology, the platform continues. If a government or organisation builds custom tooling on top of LibreOffice Technology, it owns that investment. If the community of contributors shifts, the codebase remains — licensed under the Mozilla Public License 2.0, which ensures it can never be made proprietary.

A sovereign digital infrastructure is not one built on a single vendor’s promises. It is one built on a platform that multiple independent actors develop, maintain, and depend on. LibreOffice Technology is that platform.

The Euro-Office Test Case: Why Compatibility Is Not Sovereignty

No event tested this argument more directly than the emergence of Euro-Office, the European coalition initiative that surfaced this spring under the digital sovereignty banner.

Our first reaction, when the initiative made its opening announcement, was blunt about the architecture: a European suite built around full compatibility with Microsoft’s OOXML formats does not escape dependency, it relocates it. The hosting moves to Europe. The format — and the vendor who controls its evolution — does not.

Euro-Office’s formal pre-announcement in June moved the conversation forward. It leaned much further into a commitment to open standards, and we welcomed that shift while correcting one detail then circulating in the press: LibreOffice, developed under this Foundation for a decade and a half by a global — and substantially European — community, was never absent from the field Euro-Office proposes to enter. We also set out, plainly, the one destination consistent with the sovereignty the coalition invokes: ODF as its native document format, not merely a supported one.

The distinction is not a technicality. As we laid out in A Standard in Name Only, the version of OOXML every proprietary vendor ships by default is the Transitional conformance class — built to preserve decades of undocumented legacy behaviour from Microsoft Office versions of the 1990s, not the cleaner Strict variant an independent implementer could actually build to. An office suite that treats OOXML Transitional as its working format, however European its servers, is building on a specification only one vendor has ever fully implemented. What Euro-Office does next will show whether the coalition takes the final step from sovereign hosting to sovereign format.

Where Sovereignty Is Not an Abstraction: Real Deployments

Digital sovereignty is sometimes discussed as though it were a future aspiration. For a growing number of organisations, it is a present operational reality — and this year produced the clearest evidence of that yet.

In March, Germany’s Federal Ministry for Digital and State Modernisation folded ODF, alongside PDF/UA, into the Deutschland-Stack, the technical framework that will govern digital infrastructure across every level of German public administration. OOXML did not make the list. “This is not a recommendation or a preference, it is a mandate,” said Florian Effenberger, TDF’s Executive Director, at the time — and as we argued in the days that followed, it is a decision the rest of Europe, and every digital policy advisor reading it, should be studying closely.

Germany is not alone. The Italian Ministry of Defence has spent several years migrating well over 100,000 workstations to LibreOffice under its LibreDifesa programme, reducing dependency on proprietary desktop software and building direct control over its document infrastructure. The French Gendarmerie nationale has pursued the same goal at comparable scale over two decades, moving the substantial majority of its computing estate to open-source software as part of a deliberate strategy to reduce vendor lock-in. And in August, in a two–part interview with the Austrian Bundesheer, we heard directly from the team that has moved 16,000 workstations off Microsoft Office: the decision traced back to a 2020 review of what guarantees existed for running office software without a cloud connection at all. The City of Munich’s long-running open-source initiative — despite its complex political history — remains the clearest illustration that sovereign document infrastructure is both technically achievable and organisationally demanding, at scale, inside a large public administration.

These are not proofs-of-concept. They are operational deployments in organisations for which the ability to control their own software stack is not an ideological preference but a security and continuity requirement.

They also illustrate something important: the question is no longer whether LibreOffice Technology can support enterprise-scale sovereign deployments, or whether governments will choose ODF when the choice is put to them plainly. Germany has already answered both. The question now is how quickly the rest of Europe follows.

Why “No Single Vendor Can Pull the Plug” Matters More Than Ever

In 2011, Oracle donated the OpenOffice.org codebase to the Apache Software Foundation and largely stepped back from development. The product that had been the leading open-source office suite effectively stalled. Development slowed, releases became infrequent, and the community migrated — mostly to LibreOffice, which had been founded in 2010 precisely to create a more independent governance structure.

This episode is instructive. A product can be open-source and still be effectively controlled by a single corporate actor. When that actor’s priorities change, the product suffers.

Much of what we have published this year has been an attempt to make that risk structural rather than anecdotal. The invisible architecture of lock-in traces how dependency on a document’s format cascades into dependency on the rendering engine that displays it and, beneath that, the fonts that give it its final shape — three technical layers, each one obscuring the one beneath it. The Calendar and the Invoice extends the same argument to two layers that are not technical at all: the migration deadline a vendor sets, and the subscription price it charges. Five layers, and what unites all of them is a single absence — the user has no exit.

The Document Foundation was designed with this risk explicitly in mind. TDF’s statutes prevent any single company or individual from controlling the foundation. Its governance model distributes decision-making across an elected board, a membership body, and an engineering steering committee. The LibreOffice Technology codebase cannot be re-licensed, sold, or restricted by any single party.

This is not an accident of history. It is an architectural decision about governance — as important to digital sovereignty as any technical specification.

What Sovereignty Requires of a Platform

Digital sovereignty is not a binary condition, and it is not the same thing as self-sufficiency. As we argued in July, it is not about owning everything — no institution, and certainly no continent, is going to reimplement the entire computing stack from silicon upward. It is about ensuring that nothing essential can be taken away. Different organisations will weigh that differently, but a platform that genuinely enables it must satisfy several non-negotiable criteria:

Open source with a robust licence. The code must be inspectable, modifiable, and redistributable. Not just available — auditable and forkable by any qualified party.

Open standards at the data layer. File formats must be governed by independent standards bodies, not by the platform vendor.

Independent governance. No single commercial entity should be able to make decisions — about licensing, pricing, feature development, or platform direction — that override the interests of the broader community of users and contributors.

An active, diverse contributor base. Sovereignty requires resilience. A platform maintained by a single company is a single point of failure.

Ecosystem depth. Sovereignty at the document layer requires that the platform be capable of supporting the full range of an organisation’s document needs — not just basic editing, but integration with enterprise systems, accessibility compliance, multi-language support, and cloud deployment.

LibreOffice Technology satisfies all of these criteria. We are not aware of another document software platform that does.

Sovereignty Starts Here: The Story So Far

When we first sketched out this argument, we framed it as the opening of a campaign. Several months on — with the Euro-Office debate still very much alive, Germany’s Deutschland-Stack mandate now a matter of public record, and the US CISA’s own guidance on open-source verifiability landing squarely in the same argument — it makes more sense to call it what it has become: an ongoing, evidence-led case, not a one-off pitch.

If you want the fuller version, the pieces above trace most of the argument in detail: what digital sovereignty actually means and doesn’t mean; the layered architecture of lock-in and its non-technical extensions; what separates a genuinely open format from one that merely claims the label; the Euro-Office exchange in both its instalments; and, most concretely, the Austrian Bundesheer’s own account of why and how it moved 16,000 desktops off Microsoft Office. Together with the Deutschland-Stack decision, they are the evidence behind everything argued in this piece.

We are not finished. There are interoperability failures we haven’t yet written about, further national deployments to document as they happen, and — with LibreOffice 26.8 due for release on 26 August — a platform that keeps giving us more to report on. Watch this space for what comes next.

If you are a journalist or analyst covering digital sovereignty, open source, or public-sector technology, we would like to talk. If you are an organisation considering or using LibreOffice Technology and would like to share your experience, we would welcome the conversation. Reach out to our communications team at media@documentfoundation.org.

Digital sovereignty requires infrastructure that is genuinely open. That infrastructure exists. It is called LibreOffice Technology, and — as the months since we first wrote that line have gone on to show — this really is where the story starts.

The Document Foundation is the non-profit organisation behind LibreOffice. It is independent, non-commercial, and governed by its membership community. LibreOffice Technology is the open platform on which LibreOffice and a growing ecosystem of document applications are built.

Tags: digital sovereignty, LibreOffice Technology, open document format, ODF, open source, The Document Foundation, public sector IT, vendor lock-in, document software, Euro-Office, Deutschland-Stack

Further Reading on This Blog

The posts behind the argument above, in the order they were published:

External Resources

The characteristics of a truly open document standard format

A truly open document format requires free public availability, royalty-free standards, and no usage restrictions.

Organizations like the Open Knowledge Foundation and the European Union use several core rules to guarantee long-term data access, system independence, and freedom from single-vendor control.

Core Openness Criteria

  • Public Specification: The complete format rules are published and easy for anyone to access.
  • Royalty-Free: Patents or licensing fees cannot block developers from building compatible software.
  • No Discrimination: Anyone can use the format for any purpose without needing special permission.
  • Independent Control: A transparent, non-profit standards body manages future updates.

Recognized Frameworks

  • The Open Definition: Specifies exact legal and technical terms for open works.
  • European Interoperability Framework (EIF): Requires governments to use truly open formats for public documents.

Comparison of ODF and OOXML

When evaluated against the strict criteria for open formats, Open Document Format (ODF) and Office Open XML (OOXML) take fundamentally different approaches.

While both are recognized as official ISO standards, ODF fully satisfies the open standard criteria by design, whereas OOXML features structural and legal complexities that often limit true open implementation.

Comparison Table

Criterion

Open Document Format (ODF)

Office Open XML (OOXML)

Public Specification

Fully Transparent. Concise, streamlined specifications built using a simplified RelaxNG XML schema

Highly Complex. Over 6,000 pages of specifications containing fragmented legacy behaviors.

Royalty-Free Status

Unconditional. Managed under standard royalty-free parameters for universal software design.

Conditional. Covered under a non-revocable patent promise rather than a traditional license.

No Discrimination

Complete. Equal implementation across open-source and proprietary suites.

Functional Barriers. Biased toward Windows-centric legacy and platform-specific behaviors.

Independent Control

Vendor-Neutral. Managed entirely by OASIS

Vendor-Influenced. Maintained via ISO, but the structural core remains tightly bound to Microsoft.

Key Openness Differences

Public Specification & Transparency

  • ODF: Conceived from the beginning to be a modern, clean XML specification. “ODF is the only openly available standard, published fully in a document that is freely available and easy to comprehend”, as noted by GranneBlog: https://blog.granneman.com/2009/02/06/odf-compared-constrasted-with-ooxml/
  • OOXML: Designed primarily to map Microsoft Office’s old binary data into XML. It is split into Strict and Transitional variants. “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.”, as noted by the TDF Blog: https://blog.documentfoundation.org/blog/2026/06/02/a-standard-in-name-only/

Legal & Intellectual Property Rules

  • ODF: Utilizes a standard open-source framework. Anyone can implement ODF in a project without fearing intellectual property or patent litigation.
  • OOXML: Relies on the Microsoft Open Specification Promise (OSP): https://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise. The OSP is a unilateral covenant not to sue, but it only covers developers to the extent that they precisely mirror the specification. Any implementation-defined deviations or edge cases may leave developers legally unprotected.

Technical Discrimination & System Control

  • ODF: Avoids hardware-specific dependencies, ensuring that independent applications (like LibreOffice or Apache OpenOffice) can render the data uniformly.
  • OOXML: Contains platform-specific elements tied closely to the Windows OS ecosystem. Because Microsoft Office has traditionally produced Transitional OOXML by default, third-party platforms encounter massive conversion obstacles when interpreting legacy binary elements or proprietary formatting definitions embedded within the file structure.

INTERESTING REFERENCE: the Italian definition

The document Linee guida su acquisizione e riuso di software per le pubbliche amministrazioni (Guidelines on the procurement and reuse of software for public administrations), published by AgID in 2021, define an open format in the glossary as follows (translated from Italian):

Open (data) format. This is a public, versioned data format that is comprehensively documented and has no implementation constraints. An open format is one recognised by a standardisation body and maintained collaboratively by several organisations that provide competing implementations, through a transparent process. The format must remain consistent with the declared version.

The guidelines are not an interpretive gloss issued alongside the statute. They are adopted in implementation of articles 68 and 69 of the Codice dell’Amministrazione Digitale, under express delegations contained in the statute itself. They also supersede the earlier AgID circular 63/2013 on the same comparative assessment.

The definition of formato aperto (open format) is therefore not a recommendation that happens to be well drafted. It is the operative legal definition for Italian public administration, and it acquires that force through the statute rather than in spite of it.