We are pleased to announce the release of the latest Getting Started Guide, updated for LibreOffice 26.2!

The Documentation Team is proud to present this new edition, designed to help users with an introductory guide of LibreOffice, covering all aspects of the best open source free office suite, from word processing to databases as well as settings and configuration common to all modules.

Writer (word processing)
Calc (spreadsheets)
Impress (presentations)
Draw (vector graphics)
Math (formula editor)
Base (database management)

This guide is part of our growing collection of documentation — lovingly written, edited, and reviewed by a global team of dedicated volunteers who are passionate about open-source software and digital freedom.

The 26.2 update was coordinated by Dione Maddern, with valuable contributions from Peter Schofield and Olivier Hallot. A huge thanks to everyone involved!

Ready to dive in? Download the guide for free from the LibreOffice Bookshelf Project.

This is part of the Annual Report 2025 from The Document Foundation, the non-profit that coordinates the LibreOffice project and community. More will be posted soon…

Releases of the Year

LibreOffice’s release plan works on a time-based release schedule, with major updates every six months (typically in February and August). So in other words, there are two new versions of LibreOffice per year. Many other FOSS projects adopt a similar time-based approach, and since 2024, LibreOffice has used a “year.month” versioning scheme – so LibreOffice 25.2, for instance, was released in the second month (February) of 2025. This versioning scheme helps users to see how old (or new) their currently installed version of LibreOffice is.

In addition to the major upgrades, there were monthly smaller “point” releases, mainly fixing bugs, compatibility issues and security vulnerabilities.

Major Feature Highlights

LibreOffice 25.2 was released on February 6. It introduced the ability to read and write ODF version 1.4, alongside numerous interoperability improvements with proprietary OOXML documents. It became possible to automatically sign documents after defining a default certificate. Additionally, Windows 7 and 8/8.1 were designated as deprecated platforms, with support scheduled to be removed in version 25.8, and extensions and features relying on Python ceased to work on Windows 7.

In LibreOffice Writer 25.2, improvements were made to Track Changes management to better handle a large number of changes in long documents. Comments were tracked in the Navigator when the focus was moved into them, while resizing the area containing comments showed a visual guide. Options were added to set a default zoom level for opening documents, which overrode the level stored within the documents themselves. It also became possible to delete all content of a specific content type, excluding headings, via the Navigator.

In LibreOffice Calc 25.2, a “Handle Duplicate Records” dialog was added to select or remove duplicate records. Both the Function Wizard dialog and the Functions Sidebar deck received improvements to searching and user experience. Solver models could be saved into spreadsheets, and the Solver became able to provide a sensitivity analysis report. New sheet protection options were also added relating to Pivot Tables, Pivot Charts, and AutoFilters.

Furthermore, many improvements were made to all Impress templates, which received visible elements, such as the font colour being set to black, in Master Notes and Handout. Objects could be centred on the Impress slide or Draw page in a single step, and the automatic repeating of slides could be activated in windowed mode. Finally, overflowing text in presenter notes was no longer cut off when printing.

Meanwhile, LibreOffice 25.8 was released on August 20. It brought new performance and features to the suite. In the User Interface, the Welcome/What’s New dialog began offering access to the user interface picker and appearance options, which allowed new users to leverage LibreOffice’s flexible UI and personalise the look and feel according to their preferences. The release also provided better interoperability with Microsoft Office files, offering more accurate handling of DOCX, XLSX, and PPTX files with fewer formatting issues, thanks to changes such as:

• A complete overhaul of word hyphenation and spacing
• Font management in Impress updated to be compatible with PowerPoint files
• The addition of new functions in Calc: CHOOSECOLS, CHOOSEROWS, DROP, EXPAND, HSTACK, TAKE, TEXTAFTER, TEXTBEFORE, TEXTSPLIT, TOCOL, TOROW, VSTACK, WRAPCOLS, and WRAPROWS

There were, of course, other important new features, such as the ability to export to the PDF 2.0 format, and several new ScriptForge library services.

Performance

Throughout 2025, the LibreOffice community continued to work on improved performance in the suite. In LibreOffice 25.2, the speed of font previews in Calc was greatly improved. Additionally, the speed of saving from XLS to ODS was greatly improved after the impact of increasing the supported number of columns to 16k, and saving ODS files with large merged ranges became faster. Spreadsheets with lots of conditional formatting opened and saved much faster, while spreadsheets with lots of comments also saved much faster. Finally, the speed of loading XLS files was greatly improved after the impact of increasing the supported number of columns to 16k.

In LibreOffice 25.8, performance was upgraded so that everything ran faster, from startup to scrolling through large documents, with significant speed improvements delivered on less powerful machines. In benchmark tests, Writer and Calc opened files up to 30% faster. Optimised memory management allowed for smoother operation on virtual desktops and thin clients.

Quality Assurance

For every release, the LibreOffice Quality Assurance community produced Alpha, Beta and Release Candidate versions, giving users the chance to test the software (and report bugs) well in advance of the final release. Throughout the years, thousands of bugs were confirmed, triaged and resolved. The QA team wrote monthly reports about its activity on the QA blog.

Accessibility

In LibreOffice 25.2, the Accessibility Sidebar featured improved warning and error levels, along with a new option to ignore specific warnings. Additionally, user interface elements were updated to report an accessible identifier that can be utilised by assistive technologies.

Platform-specific enhancements included on Windows, where accessibility was automatically enabled whenever a tool querids information on the accessibility level, and accessible relations were now correctly reported. Meanwhile, on Linux, the positions of UI elements, including those on Wayland, were accurately reported on the accessibility level.

LibreOffice 25.8 added an accessibility check for links and references in header/footer. Menus in the File ▸ Templates ▸ Manage Templates dialog became screen reader accessible on Windows. Support for the IAccessible2 “text-indent” attribute was added, which could be used by assistive technology like screen readers to report the indent of a paragraph’s first line. Additionally, the table design view in Base no longer became unresponsive when a screen reader was active on Windows. Finally, comboboxes and other controls inside toolbars were also represented in the accessibility tree of the application.

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

LibreOffice is the free, private, open source office suite – and successor to OpenOffice. It’s made by a worldwide community, and you can be part of it! Boost your skillset, learn new people, and have fun – find out what you can do for LibreOffice.

(This video is also available on PeerTube.)

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

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

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

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

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

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

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

Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more…

• We started May by announcing the new LibreOffice website. Our previous website was looking rather old and becoming difficult to maintain, so the team at TDF – with help of the wider LibreOffice community – has been working on a redesign, based on newer technology.

• We reported back from the Augsburger Linux-Infotag, an event is all about Linux and free and open source software (FOSS) in south Germany, where the LibreOffice community was present.

• Throughout May, we continued our regular article series about the Open Document Format (ODF): Thank you, on behalf of ODF, Twenty Years On, ODF Is Still the Only Open Standard for Office Documents, and the Only One Governments Can Trust, and ODF vs OOXML, an issue that should never have existed.

• Then we announced projects selected for LibreOffice in the Google Summer of Code 2026, including: OpenType MATH; Improve word processor test coverage; and JPEG XL import support.

• In the middle of the month, we announced LibreOffice 25.8.7, the final maintenance release of the LibreOffice 25.8 family. From here we will focus on maintaining the 26.2 branch, and are preparing for 26.8, our next major release (due in August).

• The vast majority of income to The Document Foundation, the non-profit behind the LibreOffice project and community, is from donations from end users. We made a new video explaining how donations are used to support the community that makes the software.

• Next, we started posting sections from TDF’s Annual Report 2025, starting with Native Language Projects. A huge thanks to the hundreds of people who make LibreOffice available is so many languages around the world!

• Then we announced our 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 we’re looking into what we can do. We already have a more detailed proposal from the TDF team.

Like what we do? Support LibreOffice with a donation – or join our community and help to make LibreOffice even better! Also keep in touch – follow us on Mastodon, Bluesky, Reddit and Facebook.

Love LibreOffice? Got experience with infrastructure and system administration? We are The Document Foundation (TDF), the non-profit entity behind LibreOffice. We’re passionate about free software, the open source culture and about bringing new people with fresh ideas into our project.

To assist the LibreOffice community with its work, we are looking for a full-time (remote) Infrastructure and System Administrator, to start as soon as possible.

Here’s what you’ll do

• System orchestration and OS management: Orchestrate, deploy, and maintain all internal and external systems, specifically standard and customised Linux operating systems, with the majority of machines running Debian GNU/Linux. We currently run SaltStack, but proposals for different ways to handle config management and deployment are welcome.
• Virtualisation and storage infrastructure: Manage virtualisation platforms and hypervisors (KVM/QEMU). Experience with GlusterFS (for the backup system) is a plus, but not mandatory.
• Database, cloud, and App Administration: Administer database servers such as MariaDB and PostgreSQL, cloud storage repositories (such as Nextcloud), web applications, email services, and developer tooling.
• Network and hardware maintenance: Maintain core physical and cloud network infrastructure, including routers, switches, and NAS storage, amongst them devices from MikroTik.
• Security and network access: Oversee firewalls, intrusion detection, antivirus, IP reputation, global mirror systems, and secure VPNs for users and machines.
• Identity and access management: Deploy and manage single sign-on (SSO) solutions, directory services, domain names, DNS zones, and SSL certificates (PKI).
• Ensure stable operations and monitoring: Together with teammates and volunteers, ensure stable infrastructure availability, manage log analysis, handle emergencies, and coordinate with external providers during outages.
• Patch management: Execute timely deployments of security and software updates within scheduled maintenance windows.
• Team coordination and documentation: Lead and coordinate the infrastructure team, volunteer contributors, and third-party vendors, while keeping technical documentation up to date.
• Data protection and disaster recovery: Implement backup and point-in-time disaster recovery solutions, and manage infrastructure-related GDPR compliance in cooperation with privacy officers.

What we want from you

• Very good sysadmin and infra maintenance skills on Linux
• Good team-playing abilities
• Speaking and writing English

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to members of TDF. Not being a member does not exclude any applicants from consideration.

Join us!

All jobs at The Document Foundation are remote jobs, where you can work from your home office or a co-working space. The work time during the day is flexible, apart from a few fixed meetings. The role is offered as full-time (ideally 40 hours per week). While we prefer full-time for the role, part-time applications, or proposals to grow the hours over time, will be considered. Candidates that are resident in Germany will be employed directly by TDF. Otherwise, external payroll services will be used if available in the candidate’s country of residence.

Are you interested? Get in touch!

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, gender, disability, religion/belief, sexual orientation or age. Don’t be afraid to be different, and stay true to yourself. We like you that way!

We’re looking forward to receiving your application, including information about you (your resume), when you are available for the job, and of course your financial expectations. Please provide details about your experience and send us an e-mail to sysadmin@documentfoundation.org no later than July 6, 2026 (end of day, Berlin time). If you haven’t received feedback by August 3, 2026, your application could not be considered.

Also note: we only accept applications from the applicant, and not from any intermediary. We do not accept agency resumes. Please do not forward resumes to any recruiting alias or employee.

Dear office suite users,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This has consequences that go well beyond a technicality.

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

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

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

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

For public administrations, this matters in three specific ways.

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

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

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

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

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

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

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

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

LibreOffice is made by hundreds of people around the world, working on code, documentation, QA, translations, marketing, infrastructure and much more. Coordinating the project’s activities is the team at The Document Foundation, the non-profit behind LibreOffice. Let’s see what the team members do:

1. Christian Lohmaier, Release Engineer

Christian’s typical tasks include taking care of the continuous integration system (both the automation server and the build machines), managing the LibreOffice release process, handling app store updates with all the paperwork that entails, managing the technical side of language translations not only for LibreOffice, but for any translatable system we have and making sure our integration with payment platforms works smoothly. He has also been involved in creating and maintaining websites and web services.

Christian’s work is influencing the developer experience as well. In the past, LibreOffice’s Windows development setup was somewhat messy. After Christian introduced automation into the setup process with the help of WinGet scripts, there has been much less need for troubleshooting.

2. Dan Williams, Developer

Dan was involved in the Mac port back in the 2000s when LibreOffice was still called OpenOffice.org. For some months now he has been working for TDF on user interface and macOS tasks. He has done corrections to the handling of system UI themes, implemented support for special macOS keyboard shortcuts and macOS-specific menu items, fixed database links going missing from .ods files, and fixed an issue with printing notes from Impress presentations on macOS. His ongoing work includes experimenting with Qt UI on macOS and reworking the code for Notebookbar.

3. Florian Effenberger, Executive Director

Florian is one of the founders of TDF, and its Executive Director since 2014. He manages our worldwide team of 18 people, and deals with a variety of tasks in accounting, financials, taxes, budget, payroll, annual audit, banking, legal topics, employment and HR. He supports the board and the membership committee and onboards those new in office. He regularly gives presentations at events, is active in the German community and has written extensively about the tasks he is involved on our forum.

4. Guilhem Moulin, Infrastructure & Services

Guilhem is managing our servers and the approximately twenty web services needed every day by LibreOffice users and contributors. Major updates to the operating systems and the web applications require careful studying of what needs to be taken into account to ensure everything keeps operating smoothly. Often this goes into the level of studying individual code changes. Compatibility breakage has to be mitigated or at least communicated.

5. Heiko Tietze, UX Architect

Heiko is collaborating with user experience design volunteers in planning improvements to LibreOffice. Not being content with planning, he then goes and implements the proposals, either by himself or with help from others. Heiko always denies being a C++ developer yet inexplicably has over 700 LibreOffice code changes in his name. He has mentored in over a dozen Google Summer of Code (GSoC) and Outreachy projects, for example in the reworking of Table Styles and UI theming. Being an active mentor means that he is doing code reviews for new developers all year round as well as inventing new easy tasks.

A recent large-scale project of his is implementing vertical tabs in dialogs.

6. Hossein Nourikhah, Developer Community Architect

Over a hundred developers get their start in LibreOffice code every year. Facing seven million lines of code can be intimidating, so we have a tradition of providing a selection of tasks we call “easy hacks“. Hossein is tending to this catalogue of beginner tasks and reviewing the submitted code changes. Whenever a new developer has issues with setting up a development environment, he jumps in to help. He is also writing developer documentation on the TDF wiki and publishing blog posts about development.

He has mentored GSoC projects such as cross platform bindings for .NET and Python code auto-completion. His recent contributions include initial support for Qt 6 UI on Windows together with Michael Weghorn, based on earlier work by Jan-Marek Glogowski.

7. Ilmari Lauhakangas, Development Marketing

Ilmari is bringing in new contributors to quality assurance, design, C++ development and documentation. In a typical year he teaches nearly 200 people about getting involved in LibreOffice. He is also triaging (and sometimes fixing) bugs, doing web development, maintaining the wiki, doing code reviews and managing internship programs.

8. Italo Vignoli, Marketing & PR

Italo Vignoli is a founding member of The Document Foundation and the LibreOffice project, the Chairman Emeritus of Associazione LibreItalia, an Ambassador of Software Heritage, and a proud member of Free Software Foundation Europe (FSFE). He is a past board member of Open Source Initiative (OSI). Italo co-leads LibreOffice marketing, PR and media relations, co-chairs the LibreOffice Certification Program, and is a spokesman for the project. He also handles advocacy and marketing activities for the Open Document Format ISO standard.

9. Jonathan Clark, Developer

For the past two years Jonathan has been working on LibreOffice features in the categories of right-to-left scripts, complex text layout and Chinese-Japanese-Korean. In addition to numerous quality of life improvements, he has implemented support for Start/End paragraph alignment while making it the default instead of Left/Right, and made the CJK text grid compatible with Microsoft Word. On the mentoring side he is constantly reviewing code submissions from newcomers and was involved in the BASIC IDE object browser GSoC project.

Jonathan is currently looking into fundamental improvements in the LibreOffice user interface.

10. Juan José González, Web Technology Engineer

As mentioned earlier, TDF hosts a rather large number of web applications, some of them created from scratch. These custom web services include the Extensions and Templates site and the Crash Report site. Juan José has been heavily involved in redesigning and maintaining these two sites. He has also worked on sites for various LibreOffice conferences, improved our localisation tooling and created tools to combat spam in our forums.

11. Michael Weghorn, Developer

TDF wants LibreOffice to be easy to use for visually impaired people, and three years ago Michael was hired to make sure we always deliver accessible software. LibreOffice has lots of variety in its content types and user interface widgets. This means that we are sometimes testing the limits of accessibility APIs, which are also different per operating system. To ensure optimal results in LibreOffice accessibility, Michael is working with developers of toolkits such as GTK and Qt, and with developers of screen-reader applications such as Orca and NVDA.

At the moment Michael is working to bring LibreOffice’s Qt user interface support to the next level and seeing how it works on Windows.

12. Mike Saunders, Marketing and Community Coordinator

Mike is a long-time Linux and free software journalist, and joined the team in 2016 to work in the areas of marketing and community outreach. He helps to maintain the LibreOffice social media channels, interacting with users to encourage them to join the project and contribute. He also interviews community members, writes blog posts, works on videos and podcasts, and organises events.

13. Neil Roberts, Developer

Neil joined the team a couple of months ago to improve the scripting and API side of LibreOffice. He has implemented a new approach for Lua UNO API bindings, added QuickJS-based JavaScript bindings together with Stephan Bergmann and made it possible to create and edit Python macros via the Macro Organizer dialog.

Neil will also be collaborating with Michael Weghorn on user interface renovation projects.

14. Olivier Hallot, Documentation Coordinator

Olivier started contributing back in the OpenOffice.org days in 2001 as part of the Brazilian community and is one of the founding members of TDF. For ten years he has been leading the documentation effort for LibreOffice. The documentation team maintains several guide books, a huge collection of help articles, wiki pages and even tooltip texts seen within LibreOffice itself. Olivier has opinions on writing good release notes and is not shy to share them!

Olivier is also fixing UI issues and making sure everything works with regards to localisation.

15. Sophie Gautier, Foundation Coordinator

Sophie has been in the LibreOffice project since the beginning (and in OpenOffice.org before that), and helps with TDF administration tasks, such as organising meetings and managing the travel refund tool. In addition, she helps to organise the yearly LibreOffice Conference, and works with the localisation communities to make LibreOffice available in as many languages as possible.

16. Stephan, Administrative Assistant

Stephan helps with administrative tasks for the foundation, such as meeting minutes, accounting reports, donation queries, travel bookings, travel expense reimbursements, ordering equipment, issuing donation receipts, payment processing, and translations.

17. Vissarion Fysikopoulos, Developer

Having started about a month ago, Vissarion will focus on taking Base to the next level. The current development plan includes finishing the new Report Builder, polishing Firebird support and adding support for SQLite.

18. Xisco Faulí, QA Engineer

Xisco did a Google Summer of Code project for LibreOffice in 2011 and joined the TDF team in 2016 to work on QA (quality assurance). At first he was triaging bugs, but gradually moved to writing automated tests. By now he has added thousands of tests. He keeps LibreOffice’s hundred external dependencies up to date, fixes critical bugs, improves graphics support, helps with the release process, is involved in reviewing security reports and handles the crash report system alongside other automated systems related to guarding the quality of the software. He also mentors GSoC projects.

As mentioned, the team is just a small part of the overall LibreOffice community. Everyone is welcome to find out what you can do for LibreOffice – to learn new skills, meet new people, and be part of a project making software used by millions of people around the world!

Executive Summary

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

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

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

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

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

Market Analysis

Consumers

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

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

Service Providers

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

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

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

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

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

Competitors

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

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

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

Microsoft 365

Distinguishing features

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

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

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

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

Weaknesses

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

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

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

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

Google Workspace

Distinguishing features

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

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

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

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

Disadvantages

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

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

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

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

Lessons

We are LibreOffice

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

Availability rather than interoperability

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

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

Same code – feature complete

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

Streamlined web experience available

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

Cross-platform collaboration between web and desktop

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

Responsive user interface

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

On-premises hosting – no privileged cloud provider

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

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

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

Development Plan

Overview

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

Responsive user interface

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

Web distribution using WebAssembly

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

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

Mobile distributions based on desktop version

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

Document server and integration with desktop version

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

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

Client-server collaborative editing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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).

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.

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.

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!

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.)

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

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

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

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

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

The Transitional/Strict bait-and-switch

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

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

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

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

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

The political consequences

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

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

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

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

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

It is a deference with no rational basis.

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

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

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

Supporting ODF is not choosing ODF

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

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

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

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

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

What digital sovereignty actually requires

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

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

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

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

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

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

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

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

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

The HTML parallel

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

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

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

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

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

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

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

Why this matters: lock-in is a software property

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

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

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

Why this matters: attack surface is a software property

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

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

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

Why this matters: freedom is a software property

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

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

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

The conclusion is unavoidable

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

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

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

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

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

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

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

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

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

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

The LibreOffice Google Summer of Code projects have been selected for 2026.

• Aya Jamal – OpenType MATH: this project aims to add support for OpenType fonts that contain a MATH table. Data from the MATH table will be used to layout math formulas.
• Manish Bera – Improve word processor test coverage: Writer is the most complex application in LibreOffice. The tests written in the scope of this project will make for a better developer experience. One aim is to restart the automated generation of LCOV test coverage reports.
• Jesus Solis – JPEG XL import support: while JPEG XL has only recently started to be adopted by web browsers, it is already used in fields such as medical imaging, professional photography, PDF & EPUB authoring and handling geospatial and archival data. Having support for it in LibreOffice would therefore make for a smoother experience for the users who rely on the format.

Good luck to the contributors – we appreciate their work on these important features and improvements! And thanks to our mentors for assisting them: Khaled Hosny (Alif Type); Jonathan Clark and Xisco Faulí (TDF).

Between August 17 and 24, contributors will submit their code, project summaries, and final evaluations of their mentors. Find out more about the timeline here, and check out more details about the projects on this page.

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

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

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

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

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

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

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

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

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

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

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