Let’s put an end to the speculation

Ideally, we would have preferred to avoid this post. However, the articles and comments published in response to Collabora’s and Michael Meeks’ biased posts compel us to provide this background information on the events that led to the current situation.

Unfortunately, we have to start from the very beginning, but we’ll try to keep it brief. The launch of the LibreOffice project and The Document Foundation was handled with great enthusiasm by the founding group. They were driven by a noble goal, but also by a bit of healthy recklessness. After all, it was impossible to imagine what would happen after September 28, 2010, the date of the announcement.

At the time, nobody could imagine that the companies that had supported OpenOffice.org until then would create a project to kill LibreOffice. Also, if the project were to be successful, it would require resources greater than those available, and above all, a deep management experience.

Fortunately, the project grew quite rapidly. However, the founders’ different backgrounds and opinions were at the same time the reason for some bold decisions – many of which right – as well as a few mistakes, which are the root cause of some of the current problems:

  • granting free use of the LibreOffice brand only to companies in the ecosystem, to allow them to sell the software in Microsoft and Apple’s online stores;
  • awarding contracts for the development of LibreOffice – new features, fixing “legacy” bugs, etc. – to companies whose representatives were on the foundation’s Board of Directors, and who were active throughout the procurement process.

Both of these decisions were found to be incorrect for reasons relating to the non-profit law, to which The Document Foundation must adhere. They violated the law itself. When this fact was brought to the attention of the Board of Directors by the foundation’s legal counsels, the companies that had benefited from these errors sought to maintain the status quo rather than finding a solution. At the time – from the end of 2021 to the middle of 2022 – this could have been achieved swiftly and with minimal difficulty.

This attitude increased tensions within the BoD, adding to pre-existing frictions that began in 2020 when the majority of the new board decided to terminate the plan to transfer many of TDF’s tasks and assets to a parallel organisation called TDC. Several issues that the current board had to solve stemmed from elements of that project that had been partially executed.

The origins of TDC are controversial. One reason given for setting up the parallel organisation was the “alleged inefficiency” of the TDF team, which was expressed by some of the directors. Unfortunately, instead of addressing the supposed problem with a reorganization or some training, the BoD decided to react by creating a new problem: a parallel structure with a supposedly “highly efficient” team that would highlight the alleged inefficiency of the TDF team.

TDC was presented at the LibreOffice Conference in Almería in 2019 without prior notice, raising concerns within the team and the community. This was partly because the parallel organisation’s project envisaged leveraging TDF’s financial resources as startup funds. This attempt resulted in permanent damage to relations between the project’s components, and especially between certain BoD members and the team.

After years of discussions marked by accusations and finger-pointing, during which no real progress was made in resolving the legal issues, the authorities requested an audit whose results confirmed that resolving the issues was absolutely necessary to avoid losing non-profit status, with unforeseen consequences.

Unfortunately, the presence of company representatives on the Board of Directors (BoD), who were elected by employees of those same companies that are also TDF members, caused further delays to finding a solution, which has not yet been reached.

Fortunately, the introduction of restrictive measures – such as the decision to forfeit TDF membership status of Collabora employees – and the freezing of tenders, alongside the introduction of a robust procurement policy for development, has resulted in a positive outcome for the third audit. At least, the BoD has demonstrated a willingness to break the deadlock that has persisted since 2022.

The board also reviewed governance issues from the past and set clear rules to minimise the risk of them recurring in future. These rules are set out in the Code of Ethics and Fiduciary Duties, the updated Conflict of Interest Policy and the Community Bylaws.

Of course, if we could rewind the course of history, some of the choices made since 2010 would hopefully be different and no one would repeat the mistakes or the wrong behaviours of the past.

As we said at the beginning, we would gladly have done without this post, but it was necessary to set the record straight and avoid speculation.

TDF has been preparing for some time for Collabora’s announcement, by hiring developers and exploring new partnership opportunities to support a growing interest in LibreOffice on the desktop, still a viable option for many deployments, the cloud and mobile, and in ODF as the preferred document format for governments worldwide.

Thanks to the growing importance of free and open source software, as well as open standards for document formats, the concepts that we have been advocating for over twenty years and have finally reached political institutions and users, The Document Foundation and the LibreOffice project are well positioned for the future.

Document formats: a mystery to many

Euro-Office’s announcement – which sees IONOS, Nextcloud and other companies coming together to create a European alternative to office productivity software – has predictably sparked a wave of comments. Most of these focus on the issue of licensing: is the code open source? Who controls the repository? What are the conditions for forking, modifying or implementing it?

While these are all valid questions, they fail to address the most important issue. The fact that almost no one is asking the question that matters tells us something significant about how the debate on digital sovereignty has been framed and who benefits from that framing.

A licence tells you who owns the software, while the format tells you who owns the data

A licence can be renegotiated, modified or updated. The history of FLOSS is full of projects that have changed governance models, divided communities, or changed course under new management. Licence terms are important, but they operate at the level of the software artefact.

The native document format operates at a completely different level. It is the encoding level of every document produced, archived, and exchanged by institutions that adopt the software. It is the invisible structure of administrative memory within which public documents exist for years, or even generations. It is the infrastructure.

If Euro-Office is supplied with OOXML as the default native format – even if it is wrapped in an open licence, hosted on European servers or governed by a European legal entity – every document drafted by public administrations, schools and institutions will be written in a format designed around the behaviour of a single vendor’s application.

OOXML is governed by a specification that is so complex and internally inconsistent that it compromises interoperability. As if that were not enough, it is optimised for backward compatibility with Microsoft Office rather than for seamless exchange between systems.

The licensing issue asks: who controls the code? The format issue asks: who controls the data? These are not equivalent situations. The latter has long-term implications for public archives, administrative continuity, and the practical significance of vendor independence.

For thirty years, the FLOSS and digital rights communities have been working on licences based on the fundamental principle that a licence equals freedom. This work has produced enormous value, but it has also created an unintentional blind spot.

Microsoft has spent decades conducting one of the most effective user education campaigns in the history of the software industry. However, what it has taught is dependency. Consequently, a generation of users, administrators, developers and even FLOSS advocates has grown up treating OOXML documents as the natural unit of document exchange — just like water flowing from a tap. OOXML files are not perceived as a lock-in mechanism, but as normal documents.

This is an incredible strategic achievement. Microsoft has managed to transform a proprietary file format, which was designed to replicate the behaviour of its own applications rather than enable transparent content exchange, into an interoperability standard.

Compatibility with the OOXML format is not viewed as a courtesy to the monopoly holder; rather, it has become a feature that alternative software must provide to prove its legitimacy. Lock-in has been transformed into an advantage: users are not trapped in Microsoft’s format; they are simply using the format that everyone else uses.

The FOSS community, which should be particularly vigilant about such dynamics, has often uncritically accepted Microsoft’s approach. Indeed, when evaluating an alternative productivity suite, the first question is often about the ability to open OOXML files rather than about the native format and whether it enables interoperability. Unfortunately, the alternative is judged according to criteria subtly dictated by Microsoft.

Consequently, format policy is treated as a secondary technical issue rather than the major political issue it really is. Meanwhile, Microsoft has pursued a precise and successful strategy of securing OOXML certification as an ISO standard to define it as ‘open’, while ensuring that licensing issues take precedence over format issues.

The result is that “supporting ODF” has become a box to tick rather than a specific commitment. This explains why all office suites today claim to support ODF. The practical implications of this support – such as whether ODF is the native or default format, or the format in which documents are created and stored without user intervention – are rarely considered, let alone addressed.

The test that matters

Euro-Office presents itself as a genuine European alternative: an infrastructure project for digital sovereignty. This claim deserves to be put to the test in terms of whether institutions will manage to free themselves from Microsoft lock-in, or if they will simply reproduce it under a different banner.

The test is simple and admits only one answer: ODF will be the native format of Euro-Office; the format in which documents are created, stored, and exchanged by default without user configuration or technical intervention.

Not: Euro-Office supports ODF because, in a nominal sense, everything supports ODF. Users can save in ODF format because this is a compatibility feature, not a commitment to true digital sovereignty.

If the answer is yes, then Euro-Office represents a significant structural break with the dominant proprietary format. However, if the answer implies “compatibility”, “user choice”, “transition paths” or “broad format support”, then Euro-Office is, regardless of the licence, a server migration that leaves Microsoft’s lock-in on data unchanged.

Digital sovereignty is not achieved by changing who hosts the software, but by changing the format in which data is encoded. European institutions, public administrations, and civil society organisations considering Euro-Office deserve a direct and immediate answer to this question before making any further commitments.

ODF has to be native, default, and by design.

Since its foundation, the Document Foundation has supported ODF as an open standard for document exchange. ODF (ISO/IEC 26300) is the only document format standard designed from the outset to ensure interoperability, long-term preservation, and total vendor independence.

Euro-Office: sovereign in name only, or in reality too?

The announcement of the Euro-Office is welcome news. The coalition is credible, the governance is sound and the timing is perfect. Europe needs office software, and The Document Foundation is delighted to see such significant players allocating resources to make it happen.

However, we have a question. It is not meant to be hostile, but it is the only question that matters.

What is the native document format of Euro-Office?

The press release promises full compatibility with Microsoft formats. We are well aware of the logic behind migration: organisations moving away from Microsoft need to be certain that their documents will survive the transition. But “full compatibility with Microsoft formats” is certainly not a definition of sovereignty, but rather the definition of a different kind of dependency.

OOXML is a format designed, controlled and managed solely by Microsoft. Building a European office suite prioritising compatibility with OOXML means ensuring that the European document infrastructure remains subordinate to architectural decisions made in Redmond. The hosting moves to Europe, but the lock-in remains in Redmond.

The alternative exists, is mature and is a law in several European jurisdictions. ODF, the Open Document Format, is an ISO standard developed through an open and transparent process, which is not controlled or managed by a company. The German Deutschland-Stack has made it mandatory, and the EU Commission has approved it. It is not the LibreOffice format, but a European public good.

The Euro-Office press release does not mention ODF even once.

We are not asking Euro-Office to abandon support for Microsoft’s proprietary format. LibreOffice itself reads and writes OOXML: compatibility is a necessity for users, not an ideological concession. We are asking whether ODF will be the native format, the one in which documents are created, archived and exchanged between European public administrations.

This distinction is fundamental, and the time to define the native document format is now, before the architecture is finalised and the implementations take place. If necessary, we are here to help with the deployment of the ODF standard as native document format.

The coalition has the credibility and resources to build something truly innovative. We hope it will use them to build a project of sovereignty and not merely a tool for server migration, flying a European flag but with a lock-in firmly rooted in Redmond.

The Document Foundation is a non-profit foundation and the home of LibreOffice, the world’s leading open-source office suite. LibreOffice implements ODF as its native format and supports a wide range of document formats, including the import and export of OOXML.

Open Letter to European Citizens

The door to digital sovereignty is open, please come in

For decades, a community of developers, activists, researchers and public officials has quietly worked on the idea that free and open-source software based on open standards is not only the best technical choice, but also the only one compatible with democratic governance.

We have created the necessary tools, overseen migrations and provided user training. We have also drafted policy documents and presented them to committees.

We have documented the consequences of public documents being readable only by software developed in a single country, managed by a single company and subject to the laws of a different jurisdiction, as well as the commercial decisions of a board of directors.

The French gendarmerie, the Austrian Ministry of Defence and the German state of Schleswig-Holstein – to name but a few examples – have taken action, alongside regions, provinces and cities across Europe.

We have always been here, and not with a product to sell, but with the knowledge, patience and sincere conviction that public institutions belong to the public, and that this also applies to their digital infrastructure.

Sometimes we were listened to, but far more often we were merely tolerated, at best with a smile that seemed to say: “I know, but what can I do about this?”

And now, suddenly, the situation has changed, and not because the arguments have changed – there was no need for that – nor because the technology has changed, as it was already excellent.

The situation has changed because the geopolitical balance has shifted, and the dependence that once seemed a convenience now appears for what it has always been: a structural vulnerability.

We are glad that this moment has arrived, and we like to think that this clarity – which the evidence never managed to achieve – is also down to us, and not just the geopolitical crisis.

But we ask European citizens, and through them those who govern European countries, to understand one extremely important thing: the door to digital sovereignty does not open simply by choosing different software, but by understanding what sovereignty actually entails.

It requires open document formats, not as a preference, but as a legal and technical guarantee that a document produced today will be readable in thirty years’ time, by any compliant application, without the permission of any company. The format is not a detail, but the foundation.

It requires open fonts, because a document displayed differently on different systems is not an interoperable document, regardless of the standard it claims to follow. The display layer is just as important as the data layer.

It requires continuity of expertise: the people and institutions that have carried out this work, often without recognition and sometimes without resources, are not a lobby to be managed but a valuable repository of knowledge to be engaged.

It requires honesty about what “open” means. A coalition that speaks of digital sovereignty but chooses as its default document format one designed to replicate the behaviour of proprietary software is not building sovereignty but a new dependency under a different banner.

We have been here for years, and we will still be here for years to come.

The FLOSS ecosystem did not need a geopolitical crisis to believe in open standards. We have always believed in them, because they are right—technically, legally, and democratically.

Now that Europe is ready, we have just one request: listen to us carefully, unlike what you have done in the past. The lesson is not simply “use free and open-source software”. The lesson is: understand why it is important, and understand it thoroughly.

The tools exist, the knowledge exists, and above all, the community exists.

What happens next will depend solely on you: Europe’s digital sovereignty could become a genuine architectural commitment or remain yet another rebranding of dependency.

We hope, and would like to be sure, that you choose the first option.

Over the coming weeks, four articles will explore these topics in depth: the architecture of document formats, the hidden politics of font rendering, lessons learned from real-world migration experiences, and what a credible European policy on open standards would actually look like. We invite you to read them.

Say hello to Neil Roberts, new LibreOffice developer focusing on scripting support

Photo of Neil Roberts

The Document Foundation, the non-profit entity behind LibreOffice, has a new developer in its team. Neil Roberts started work this month and will initially focus on LibreOffice’s scripting support. Let’s hear from him…

Tell us a bit about yourself!

I’m from the UK but I escaped to France after the Brexit vote and I’ve been living here in Lyon ever since. I got into programming when I was little, mostly by programming in BASIC on an Amstrad CPC. At the time I thought it was cool that you could sometimes see the source code in BASIC of software that you bought on cassette tape. Later my older brother got me into Linux and I loved that you could see the source code of absolutely everything. I’ve been a big fan ever since, and I always have some programming side project on the go.

I started my career at a small open source consultancy working on Clutter – which at the time was a project meant to bring revolutionary animated user interfaces inspired by the iPhone into the GNOME space. It is still used inside GNOME Shell today. Eventually that small consultancy got acquired by Intel where I moved onto working on the graphics drivers in Mesa.

I got into LibreOffice development last year after I was trying to help proof-read my wife’s master’s thesis and I ran into a small user interface bug. I made a patch to fix it and it gave me the opportunity to interact with the amazing LibreOffice community. I was very pleasantly surprised with the warm welcome and the encouragement to continue making more contributions. I have been hooked on it ever since.

Aside from tech, I like to ride my bike around the city and complain about cars. I usually have a knitting project with me at all times for when I want to relax. I’m also quite active in the Esperanto community.

What’s your new role at TDF, and what will you be working on?

I am in the scripting role, which means I will be helping to make life easier for people writing macros and extensions using the UNO API with any of the supported languages such as Python, JavaScript, Basic, C++ etc. Aside from BASIC, which has a very nice built-in editor and debugger, I think it’s still quite awkward to develop macros in the other languages – so I think one of the main tasks would be to improve the UI and user experience when writing in Python.

How can all users of LibreOffice help you in this work?

I think that filing bugs in Bugzilla to report issues that people are having with macro and extension development would be really helpful, including wish-list ideas of things that would be nice to have. I am very happy to discuss ideas on Bugzilla, the mailing list or in the Telegram group.

Otherwise, code contributions are very welcome of course. I hope to be able to give back the same warm welcome with code review and mentorship that I received when I made my first contribution.

Thanks Neil, and welcome on board!

ODF is the future, OOXML is the past

Whenever a user, a government, a school or a business chooses the format in which to store and exchange its digital documents, it is not merely making a technical decision, but is placing a bet on the kind of digital infrastructure on which it will depend in the future.

In this sense, ODF and OOXML are not two equivalent options on the same shelf, but two radically different solutions: one geared towards a future of openness, interoperability and digital sovereignty, and the other towards a past of defending a vendor’s dominant market position through user lock-in.

ODF: designed to be open and transparent

Open Document Format was conceived from the outset to be an open standard. It was designed and developed by the community under the auspices of OASIS, and subsequently ratified by ISO, to be implemented by anyone, on any platform, without royalties, without hidden dependencies and without the permission of any single company.

These are not trivial technical details, but a statement of political and economic strategy embedded within the format itself.

ODF is based on a clean XML schema, easy to read even by non-technical users and reusable. Colour naming follows standard web conventions, and its architecture reuses components from widely adopted open standards. The format was designed to work within an open and transparent infrastructure, not against it.

When a public administration archives a document in ODF format, it can be certain that any future government, any future open-source or proprietary application, and any future platform will be able to read, manage, process and transform that document, because the format specifications are publicly available, and are clear, complete and free from restrictions.

In this sense, the commitment to ODF is a forward-looking one, because it is in line with the evolution of technologies and infrastructure based on open-source software, and with the European agenda on digital sovereignty.

OOXML: designed to preserve the past

OOXML, or Office Open XML, was not designed for interoperability, but to do something very specific: to encode Microsoft Office’s binary formats in XML in such a way as to allow Microsoft to claim compliance with the standard without relinquishing control over users through lock-in.

This origin story is not ancient history, but dates back to the period between 2006 – purely by coincidence, the year the ODF format was approved by ISO – and 2008, the year of the farcical event known as the Ballot Resolution Meeting which led to the approval of OOXML by ISO, and is written into all versions of the specification.

OOXML Transitional, the variant that virtually all Microsoft Office documents use in practice, and the only one available today, is explicitly defined as a compatibility layer with legacy binary formats (the now-forgotten DOC, XLS and PPT, which were nothing more than the saving of working memory to disk), and contains thousands of undocumented elements, format-specific exceptions, and references to legacy Microsoft systems that no third party can fully replicate.

The specification itself acknowledges that Transitional documents may contain elements whose behaviour is ‘legacy’ and whose correct display requires knowledge of Microsoft’s proprietary systems. In short: to implement OOXML Transitional correctly, one must decode thirty years of Microsoft Office history, something that no one except Microsoft can do, and no one ever will.

In this sense, the choice of OOXML is not a gamble but a backward-looking choice, because the format is only open in appearance – but it takes very little, just a bit of goodwill, to realise that it is completely closed – and was designed to be a lock-in mechanism.

Two completely different standardisation paths

OOXML’s path to ISO ratification is a catalogue of everything that should never happen during a standardisation process, starting with the Fast Track method. One comment was: “It will be truly sad if ISO lowers its standards so far that it will accept this monstrosity”.

Another comment, from a member of the ISO Technical Committee that approved OOXML, sums up the format’s problems: “The trouble with OOXML is not just that the document itself is monstrously huge. The current OOXML format has a number of technical problems which have been listed in detail elsewhere. Another problem is that the specification itself is not written as a standard, but more as the sort of technical documentation you’d expect to find for a commercial product. This will cause serious interoperability problems in practice, and since interoperability is the whole point of a standard, that’s not acceptable”.

The market has confirmed what the standardisation process had sought to conceal: OOXML Transitional never delivered the interoperability it promised, and this is confirmed by content loss, rendering differences and various other incompatibilities between Microsoft Office’s implementation and those of third parties, which are persistent and still documented today. A true standard should be perfectly reproducible by following its specification, and should not require reverse engineering or trial-and-error approaches.

ODF, by contrast, has followed the standard ISO standardisation process, and for this reason it is the format recommended by the EU Interoperability Framework, by the German Deutschland-Stack – which mandates it alongside PDF/UA at all levels of public administration – and by a growing number of national frameworks, which have independently concluded that true interoperability requires a genuinely open standard, one that meets the definition of a standard such as ODF.

ODF is “forward-looking”

A forward-looking format is one that reduces future dependency, not one that reinforces it. It is a format that can be used without requiring knowledge of a single vendor’s proprietary technologies. It is a format that a public administration can confidently hand over to its citizens, its archives and its successors.

ODF meets these criteria. Its architecture is transparent, its schemas are clean and its governance is genuinely open. Its various implementations demonstrate every day that it can be implemented fully and faithfully by projects that are very different from one another, not because they have reverse-engineered it but because the specifications are complete and easily understandable.

A “backward-looking” format, by contrast, is one that ties the future to the commercial strategies of a single vendor. In this sense, OOXML Transitional is an archaeological artefact that preserves the past at the expense of the future. Organisations that adopt it as a standard are betting – or perhaps merely hoping – that Microsoft’s roadmap, Microsoft’s pricing and Microsoft’s platform choices will remain unchanged indefinitely.

It is a risk that no government, business or institution – or indeed any individual concerned about the long-term integrity of their data – should feel comfortable taking.

The problem with “alternatives” that aren’t really alternatives

The OOXML-based lock-in has a second, more subtle dimension – and one that is far more dangerous for users – which deserves to be explained: the role of software that presents itself as an alternative to Microsoft Office, but which uses OOXML as its default native format.

This is a biased technical choice. When an office suite, whether proprietary or “nominally” open source, sets OOXML as the default format for documents, it does not offer a way out of the Microsoft ecosystem, but actually reinforces it. Every OOXML file created by a non-Microsoft application is a file that validates OOXML as a standard, which feeds into Microsoft’s narrative on interoperability and makes migration away from the Microsoft format stack marginally more difficult.

The real alternatives—applications that take interoperability and open standards seriously—use ODF as the default and treat OOXML as a compatibility layer for import/export, not as a native format. The distinction is important: it is the difference between supporting the ecosystem of open formats and entrusting one’s format strategy to Microsoft’s legacy architecture, whilst calling it openness.

Germany has chosen

The German mandate on the Deutschland-Stack is the clearest signal in recent times of the direction European policy is taking. By mandating ODF at all federal, state and municipal levels, Germany has institutionalised what advocates have been saying for at least twenty years: that open standards are a prerequisite for digital sovereignty, not an optional preference.

The mandate is not against Microsoft, but in favour of sovereignty, because it asserts that government documents belong to the state, and not to a single vendor. Citizens’ data must remain readable forever, and cannot in any way be subject to a software licence. Therefore, the document format must allow public administrations to make an independent choice, and to migrate without the format itself posing an obstacle.

The path forward is clear

ODF is the format of digital sovereignty, and of an open, transparent and interoperable public infrastructure. It was designed for a future in which no single vendor can control the documentary level of civilisation.

OOXML is a format closely tied to Microsoft’s corporate history, translated into XML and ratified amid controversy. It was designed to ensure that the future remains compatible with Microsoft’s past, dramatically reducing freedom of choice for governments, organisations, businesses and individuals, and limiting ownership of their documents.