Recent Posts

Web and Mobile Development Strategy Proposal

ODF vs OOXML, an issue that should never have existed

New Web and Mobile Strategy for LibreOffice

LibreOffice Native Language Projects – TDF Annual Report 2025

How your donations help the LibreOffice project and community

There is no digital sovereignty without ODF

Web and Mobile Development Strategy Proposal

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.

ODF vs OOXML, an issue that should never have existed

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.

New Web and Mobile Strategy for LibreOffice

New Web and Mobile Strategy for LibreOffice

LibreOffice is a desktop application, and we will continue making it. But we have constant requests for web and mobile versions, so here is our updated plan. These are minutes from the TDF Team and Board of Directors meetings on web and mobile strategy for LibreOffice:

Who was present

Team: Michael Weghorn, Jonathan Clark, Sophie Gautier, Neil Roberts, Mike Saunders, Guilhem Moulin, Heiko Tietze, Ilmari Lauhakangas, Dan Williams, Xisco Fauli, Christian Lohmaier, Vissarion Fysikopoulos, Juan José Gonzalez, Olivier Hallot, Florian Effenberger, Hossein Nourikah

Board: Eliane Domingos, Mike Saunders, Paolo Vecchi, Simon Phipps, Sophie Gautier

Summary

The meetings, which took place April 20, April 22 and May 19, focused on discussing LibreOffice and TDF strategies for the evolving development landscape and the future of LibreOffice across all platforms – desktop, mobile, and cloud. Team roles were reviewed, and new assignments were proposed.

Status of the current foundation team activities

Since 2020, the development of LibreOffice within the foundation focused almost uniquely on the desktop version of LibreOffice (and to a lesser extent, the Android viewer app) and that part will continue unchanged. Therefore the foundation will continue to deliver two major LibreOffice releases per year.

Engineering Steering Committee (ESC)

The current ESC members and activities remain unchanged, and weekly meetings continue with reports on activities, releases, topics and project management. The meeting, as always, is open to the development community.

Community support

No changes in vision for community support. Regional events and special projects remains as they are, and require proper and timely project submission and available budget. Google Summer of Code and Outreachy will continue as before. The LibreOffice Conference 2026 is planned and will take place in Pordenone, northern Italy.

Marketing and communications

Marketing and communications will adapt to the current situation of the foundation and LibreOffice . More communication of team activities and product development is needed, as well as improving the use of social networks for mass communication. Unification of the several different blogs is under consideration.

Challenges ahead

The foundation is challenged to address the following areas:

  • Develop an online and mobile version of the suite. The challenge is to select the technology that fulfill both end-user and server side management
  • Innovate in collaboration such as peer-to-peer document editing
  • Continue to produce two releases per year of the desktop and Android viewer versions
  • Improve the user interface and usability of LibreOffice
  • Keep the quality and security of the office suite
  • Develop new features and improve current features
  • Cherry-pick relevant features and improvements from other software producers
  • Full support of the Open Document Format (ODF)
  • Produce adequate documentation for development processes and the current and new products
  • Be an active participant of the major open source communities and government initiatives for FOSS and nations’ sovereignty
  • Preserve donation inflow and pursue corporate or government donations through development projects

New assignments of the team

It was suggested that the team be distributed in two parts, with proper interaction between the groups. Additional headcounts, as well as external contracts are considered to fulfil the mission. New community developers will be assigned to tasks upon demand.

Of critical importance, the suite security and CVE’s management were assigned to Christian Lohmaier (Release engineer) and Xisco Fauli (Quality Control). Coverity and OSS-Fuzz services are assigned to Xisco Fauli. These new missions require additional manpower, and provisions for hiring an additional QA specialist is needed.

The team will select valuable technology and code under FOSS licenses, and from companies using LibreOffice Technology.

Mobile, cloud and peer-to-peer development

Mobile and cloud development management is assigned to Jonathan Clark (leader), with support from Dan Williams, Michael Weghorn and Neil Roberts. The planning and priority goals established are based on Jonathan Clark’s “Web and Mobile Development Strategy Proposal” for the remainder of 2026, and include:

  • WebAssembly (WASM) Optimization: Enhancing and polishing our functional prototype based on Qt 6 and WebAssembly. This technological route will run the application robustly and natively directly inside the user’s browser, without overloading hosting servers.
  • Accelerating the mobile project: The goal for 2026 involves technical advancement in the graphical user interface (GUI) code and testing builds on Android and iOS emulators, with advisory support from Dan Williams for iOS-specific topics.
  • Smart collaborative editing: We will initiate practical collaborative editing tests using a stable client-server architecture (via direct TCP/IP connections), paving the way before advancing to peer-to-peer (P2P) network research.

Conclusion

The Document Foundation is challenged to evolve and expand LibreOffice to other computing platforms, and include collaboration editing. This requires changes in the current team activities, mission and organization. The Board and the team are fully committed to addressing these challenges and reporting to the public the development and achievements obtained. Freedom has never been so valuable for the LibreOffice community.

Discuss our plan and strategy on our forum here

LibreOffice Native Language Projects – TDF Annual Report 2025

TDF Annual Report 2025 banner

LibreOffice is available in over 120 languages, thanks to the work of localisation communities around the world. We asked them to summarise their work in 2025 – here’s what they had to say…

Czech

The Czech community maintained an active presence both online and in-person. Their localisation efforts remained strong, keeping the UI fully translated and the Help files at 95% completion. The team also stayed connected with their user base through the Czech Ask LibreOffice site along, with social media presence across X, Facebook, Instagram and Mastodon.

There was also outreach at events. The team hosted dedicated LibreOffice booths at InstallFest in April and LinuxDays in October, both held in Prague. Documentation also saw significant updates, with the publication of the Getting Started Guide (24.8), the Calc Guide (25.2), and the Draw Guide (25.8).

LibreOffice booth at LinuxDays 2025 in Prague

Danish

The Danish community focused on multimedia education and consistent localisation in 2025. There was the launch of the @libreofficeskolen (“LibreOffice School”) YouTube channel. This initiative provides the Danish-speaking public with a series of instructional videos designed to lower the barrier to entry for new users. Alongside this output, the community kept the UI and Help files fully translated at 100%, and ensured that LibreOffice promotional videos were accessible via localised subtitles.

Dutch

Beyond maintaining the local website and providing assistance via the Ask LibreOffice website and mailing lists, the Dutch-speaking community worked on many documentation updates.

Beginning in January with the Calc Guide for 24.8, the community then published a steady stream of translated manuals for version 25.2, including the Writer, Impress, Math, and Getting Started Guides. This effort then lead to the release of the updated 25.2 Calc Guide in July. On the localisation front, the Dutch team continued their work on Weblate, successfully maintaining 100% translation coverage for both the User Interface (UI) and the Help system, following upstream changes.

Finnish

The Finnish community focused on steady and ongoing translation efforts. The team prioritised localisation of the UI, with secondary work continuing on the Help system. To ensure the long-term sustainability of these efforts, the community has been proactive in outreach, utilising the vapaaehtoistyo.fi online platform to recruit new volunteers.

French

On the technical front, the French-speaking team maintained 100% translation coverage for both the UI and Help systems across all versions of LibreOffice. Their localisation work extended to the new Hugo-based website, release notes, and the Extensions wiki page. Significant progress was also made on the translation of Calc functions on the wiki and the subtitling of promotional videos.

Outreach was a major topic in 2025, with the community representing LibreOffice at events like Capitole du Libre in Toulouse, and Open Source Experience in Paris. The team also worked on academic ties, coordinating with UBO University to involve translation students in user guide writing. Beyond documentation and QA, the French team supported users through the Ask LibreOffice site and published various articles on LinuxFR. In addition, there were REGEX tutorials for civil servants and introductory presentations at public media libraries.

German

Throughout the year, the German-speaking community wrote blog posts (and translated others from the English-language blog), maintained its social media activity on Mastodon, and worked on user interface translations. Community members also attended local events on behalf of the LibreOffice project, such as the Augsburger Linux-Infotag 2025 and Digitaltag 2025 in Duisburg.

LibreOffice booth at the Augsburger Linux-Infotag 2025

Irish

The Irish-speaking community made significant steps in 2025 to bring the suite to native speakers. Currently, the UI and website translations are nearing 100%, with the LibreOffice 26.2 user interface already reaching a 96% completion rate. The team’s primary focus is now on finalising these remaining strings and resolving technical checks.

Italian

The Italian-speaking community maintained 100% translation status for the UI and Help files across all active versions of the suite. The team helped with localising the project’s new Hugo-based website and kept the Italian-speaking public informed by translating all release notes and press releases. Current efforts are focused on the ongoing translation of Calc functions on the wiki and a comprehensive revision of various wiki pages.

In 2025, the Associazione LibreItalia organised a full-day LibreItalia conference in Gradisca d’Isonzo, following the adoption of a regional law mandating the use of free open source software in Friuli Venezia Giulia, an eastern Italian region bordering Slovenia. The politician who signed the law provided an overview of the approval process.

The event was organised by Marco Marega, a long-standing member of LibreItalia who is active in the localisation team and other areas of the project. Several members of the Pordenone LUG attended the conference and initiated a discussion about organising the 2026 LibreOffice Conference in their city. This discussion then evolved into an official proposal.

Japanese

The Japanese community had a busy year in terms of events. There was the LibreOffice Asia Conference 2025 in Tokyo, a two-day event that brought together 70 attendees. Outreach extended internationally as Japanese members traveled to COSCUP 2025 in Taiwan to deliver three talks and strengthen ties with the Taiwanese community.

The community also organised:

  • Online Hackfests: Held 46 times via Jitsi and YouTube Live
  • Online Study Parties: Three sessions dedicated to user knowledge sharing
  • LibreOffice Days: Monthly offline meetups in Osaka, co-hosted with the Open Data Mokumoku-kai
  • Open Source Conferences (OSC): Booths and hackfests at seven locations across Japan, from Hokkaido to Fukuoka

On the documentation front, the team published the Writer Guide for LibreOffice 25.2 in Japanese. Localisation efforts currently stand at 91% for the UI and 46% for Help. The team also remained responsive to end users, answering nearly 50 new questions on Ask LibreOffice, publishing 20 blog articles, and maintaining a steady presence on X, Facebook and Bluesky.

LibreOffice Asia Conference 2025 logo

Kazakh

Starting in late 2025, the community launched a refresh of its translation efforts, achieving 100% UI completeness in time for the LibreOffice 26.2 release. This work extended to the localisation of the official website and the activation of the Help master branch, preparing for future documentation projects.

To improve consistency across other open source projects, the team is currently developing a unified Kazakh glossary derived from various localisation projects. Furthermore, the community has begun testing the use of AI-assisted translations, reporting high-quality results to improve their workflows in 2026.

Tagalog

The Tagalog community made steps forward in localisation, maintaining the user interface and Help files at a high completion rate of 98–99% across all versions. The team continued to integrate Deep Language Modeling to automate accuracy verification. While the community experiences a natural ebb and flow of contributors, there is growing interest in expanding support to regional dialects, such as Ilocano.

The team also wishes to extend a special note of gratitude to the dedicated group of US-based translation helpers whose contributions were vital to success in 2025.

TDF says: many thanks to all native-language projects for their work in 2025! Of course, this is just a selection of their activities, based on communities that reported their activities, but there are many more too.

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or make a donation. Thank you!

How your donations help the LibreOffice project and community

LibreOffice is free thanks to your donations. Here’s how your support helps us to improve the software and grow the community that makes it 😊 (Note: this video is also available on PeerTube.)

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

There is no digital sovereignty without ODF

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.

Press Releases

The Document Foundation announces LibreOffice 25.8.7

Berlin, 12 May 2026 - The Document Foundation announces the release of LibreOffice 25.8.7, the final maintenance release of the…

Open Document Format

ODF vs OOXML, an issue that should never have existed

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