LibreOffice is a worldwide project made up of hundreds of people: volunteers, developers at ecosystem companies, and the 18-person team at The Document Foundation (the non-profit entity that coordinates the project and community). So, what has the team been working on recently? Here’s a quick summary:

Release Engineering

• Tagged, built, and distributed LibreOffice 26.8.0 Release Candidate 2
• Enabled MAR updates for cross-updates from 25.8.7 and 26.2.4 to 26.2.5
• Reviewed patches
• Tested new Windows build bots in production
• Investigated and fixed incorrect permissions in daily Debian packages

Scripting

• Investigated an extension developer’s issue exporting BASIC macros as an extension
• Identified a debug-build assertion that does not appear to affect release builds
• Added a UI test to help prevent future regressions in macro export

Code and Accessibility

• Discussed proposed accessibility improvements on the LibreOffice accessibility mailing list
• Analyzed and fixed tdf#172831: customized NotebookBar tab names were not localised after upgrading
• Released LibreOffice Viewer for Android 26.2.5 on Google Play, F-Droid, and the Meta Horizon Store
• Discussed tdf#172885, a LibreOffice-specific Qt theme/style. Explored an upstream Qt stylesheet-environment-variable approach, then implemented LibreOffice command-line support for setting the stylesheet
• Posted and reworked the macOS-specific parts of the Qt VCL work
  • Reworked the changes in response to comments, then merged them
• Worked on generalising macOS scaling patch
• Made the Reset button dialog action ID well-known across the codebase

QA

• Announced LibreOffice 26.8 RC1 availability for testing
• Upgraded external libraries:
  • NSS to 3.126
  • libffi to 3.7.1
• Improved automated tests:
  • Factored common code from CppunitTest_sc_swarmsolvertest
  • Added ARRAYTOTEXT function tests as FunctionsTest
• Fixed crashes and warnings:
  • Fixed a null-pointer dereference warning in Writer
  • Fixed a crash in ThemeExport::write
  • Fixed a crash in OutMarkdown_SwTableNode
• Tested and commented on Qt6 style and theming work for tdf#172885
• Completed hiring tasks and code reviews
• Investigated regressions involving CJK font names and the CJK bullets gallery
• Fixed two build/SDK issues:
  • Fixed a build issue with Visual Studio 2026 18.7.0
  • Fixed missing cross-platform .NET binding files in the SDK (tdf#165585)
• Continued work toward resolving headless Windows/fontconfig build issues required for Qt6 on Windows

Mentoring

• Reviewed six substantial patch submissions
• Completed GSoC mentor tasks

Design

• Triaged Bugzilla tickets
• Participated in the weekly UX and ESC meetings
• Published extensions and managed comments
• Supported community growth through the @libodesign social media account
• Completed several design reviews
• Prepared the Base survey
• Contributed patches:
  • tdf#115805: corrected increments in numbering dialogs
  • tdf#172739: harmonized NotebookBar tab order

Documentation

• Updated online Help with fixes for Master, 26.2, and 25.8
• Updated Help pages through bug triage, contributor patch reviews, fixes, and housekeeping
• Contributed Help improvements, including:
  • Adjusted left margins for paragraphs in tables
  • Refactored the AutoCorrect Options page
  • Updated documentation for “To page” anchoring
  • Added “Page Break” to Find & Replace attributes
  • Reverted removal of “Page Style” from Find & Replace attributes
  • Muted localisation processing in selected Python and BASIC code lines
• Supported ongoing community updates to the Guides
• Helped newcomers
• Worked on the Bookshelf project, including sanitising the Impress Guide

Marketing

• Announced and promoted new TDF members and the new marketing position
• Maintained social media activity, updates, and responses
• Coordinated conference logistics and prepared the first conference-program draft
• Drafted sections of the TDF Annual Report 2025
• Updated journalists’ mailing lists and database
• Published blog posts about ODF and maintained the blog
• Monitored donations, downloads, media clippings, and download-support requests
• Managed budget-related activities
• Worked on preparations for LibreOffice 26.8 release

So that’s what the team is working on – and this is all thanks to your donations, which help to pay the team members. But as mentioned, this is just a small part of the LibreOffice project activity – the biggest work is being done by hundreds of other people around the world. Thanks to all of you

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

It sounds simple. It rarely is.

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

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

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

Beyond the Application: LibreOffice Technology as a Platform

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

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

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

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

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

That is what a platform for digital sovereignty looks like.

Open Standards Are Not Optional: The Role of ODF

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

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

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

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

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

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

The Platform Others Build On

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

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

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

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

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

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

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

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

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

Where Sovereignty Is Not an Abstraction: Real Deployments

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

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

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

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

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

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

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

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

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

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

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

What Sovereignty Requires of a Platform

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

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

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

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

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

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

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

Sovereignty Starts Here: The Story So Far

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

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

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

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

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

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

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

Further Reading on This Blog

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

• Dear Europe: Germany has shown the way forward — March 2026
• Euro-Office: sovereign in name only, or in reality too? — April 2026
• A Standard in Name Only: What OOXML Transitional Tells Us About Format Sovereignty — June 2026
• Euro-Office, open standards, and native ODF — June 2026
• The Invisible Architecture of Lock-In: the Layering of Dependencies — June 2026
• The Non-Technical Dependency Layers: the Calendar and the Invoice — July 2026
• What Is Digital Sovereignty — July 2026
• CISA Publishes Open Source Security Guidance: Verifiability Is the Difference — August 2026
• The Characteristics of a Truly Open Document Standard Format — August 2026
• Why and How the Austrian Military Moved to LibreOffice (Part 1) — August 2026
• Why and How the Austrian Military Moved to LibreOffice (Part 2) — August 2026

External Resources

• ISO/IEC 26300:2006 — Open Document Format for Office Applications, the official ISO standard page for ODF.
• Public Money? Public Code!, the Free Software Foundation Europe’s campaign for public code as the default for publicly funded software.
• European Interoperability Framework, the European Commission’s guidance on interoperable digital public services.
• Deutschland-Stack, the German federal government’s official site for its sovereign digital infrastructure programme.

Tell us a bit about yourself!

I’m Aleksi, and I live in Oulu, northern Finland. I graduated this spring with a bachelor’s degree in business information technology, and before that I did a vocational degree in software development. Work-wise, my background is in software engineering: I worked on a secure Android smartphone, mostly fixing operating system bugs.

Outside of that, I’m into retro computing: old machines, old phones, and the software that ran on them. There is a lot to learn from software written back when it could only be shipped on physical media. Every time I sit down with a piece of old software, I notice a detail I want to try building myself: an interesting design decision that makes the UI stand out, or a feature that makes me wonder how on earth it was done.

I also like to hang out at my local hacklab and volunteer at gaming festivals. And of course, I like to work on LibreOffice too. What makes LibreOffice interesting to me is that its codebase has a long history. Reading the code and going through the commits allows me to look back in time and see how the software has evolved over the years.

What are you working on in the LibreOffice project right now?

I’m currently working on smaller code fixes. I pick up bugs from Bugzilla, try to reproduce them, and ultimately submit a patch that fixes the issue. In a codebase the size of LibreOffice one can’t just aimlessly duct tape a solution and hope it works. One has to understand the root cause to be able to look in the right place and understand the effect that the change has on the bigger picture.

Coming from a background of debugging Android, I quite enjoy that part of the work. Also, everyone in the community is genuinely great to work with. Code reviews in particular taught me a lot, when a more experienced developer pointed out something that I’d never have spotted myself.

Why did you choose to become a member of The Document Foundation?

Becoming a member felt like a way of saying that I’m in this for the long term rather than just passing through. Before I started contributing, I was a bit scared of putting code out under my own name. I felt like my code wouldn’t be good enough, and that I could only contribute to open source after decades of development experience.

Boy, was I wrong. Going through the issues thoroughly (the community likes to leave hints in Bugzilla comments), understanding the problem, and submitting the best patch I could manage turned out to be enough. Having a mentor and the community’s support on IRC, where I could ask questions whenever I needed to, helped a lot too.

Anything else you plan to do in the future?

I’m planning to move from smaller fixes towards more interesting bugs (our Bugzilla doesn’t contain any hard issues, only interesting ones). I’m also looking forward to working with other teams. I’ve been interested in quality assurance and documentation lately, so picking up small tasks in those areas to build up knowledge for larger work sounds like fun to me.

What does LibreOffice really need?

This is a tough question. At least in Finland, LibreOffice needs to be offered as a real option in schools. That also means we need more people who know it well enough to teach it.

On a lighter note, we recently watched the Excel World Championships at the hacklab. I’m not sure it’s what LibreOffice actually needs, but it would be great to see people who are seriously proficient with Calc solving problems and competing. In its simplest form, it could be a community competition to see who solves the most brain teasers.

For the past few months, we’ve been developing all kinds of features for the future GIMP 3.4 release. We noticed recently that our changelog was getting quite long - a good problem to have!

While there’s been a lot going on internally, it’s been a while since we made a public progress report. So we want to share details on some of the new features and UX improvements that’ll be available in the first development release, GIMP 3.3.2. This won’t be an exhaustive list (we have to save at least some news for the release itself!) but hopefully it will give you some insight into the current direction and progress of GIMP’s development.

New Project File Format¶

The big focus for maintainer Jehan recently has been developing a new project file format for GIMP.

XCF has been GIMP’s primary project format since 1997, and it has served many users well. Over time however, we’ve observed more and more limitations of the binary XCF format. Among other issues, it does not easily support very large or complex projects, such as the multi-page and animation features currently planned for GIMP 3.6.

The new project file format will follow a more common “zipped XML” structure. While the technical details are still being designed and implemented, this change will allow for faster saving since we’ll only need to update parts of the file instead of the whole thing each time. It will also set the stage for much desired features such as auto-saving, which will now be much more feasible.

That said, XCF is not going away! Backwards compatibility is important to us, and we will continue to support loading XCFs in all future versions of GIMP. (For instance, we’re quite proud that a XCF file made by a small company for their logo in 1998 still renders the same way in the latest version of GIMP)

However, going forward we will only add support for saving/loading new features in the new project file format once it is finalized.

MyPaint Brush: Spectral Blending¶

During GIMP 3.2’s development, we upgraded to a newer version of the MyPaint brush engine. While this brought new brushes and canvas interactions to the MyPaint Brush Tool, one feature that was left out was Spectral Blending.

Spectral Blending simulates the effects of blending physical pigments in digital art. For example, blending yellow and blue will produce a green color instead of darker yellow, and blending red and yellow will create an orange mix.

Fortunately, new contributor Cassidie Grogan picked up the slack and implemented this feature. There is now a Spectral Blending checkbox in the MyPaint Brush Tool Options. If checked, the new blending method is used. You can control the strength of the blending with the Pigment slider.

In addition, maintainer Michael Natterer improved the MyPaint Brush preview code to display at their full size instead of 48x48 pixels. This fixes an issue where the previews appeared blurry on larger screens.

Non-Destructive Editing¶

Alx Sa has continued making updates to our non-destructive filter code. To list a few:

You can now apply filters non-destructively to Layer masks! To go along with this, the filter popover has been redesigned by Reju to show the active filters for both the layer and its mask, so you can interact with both on the same screen.

The Gradient Tool can now be used non-destructively! If you check Editable Gradient in the Tool Options, the gradient you create will be added to the filter stack like any other effect. You can toggle its visibility, rearrange its position in the filter stack and delete it. You can also edit the gradient, which will switch back to the Gradient Tool to let you make further changes.

Filters without dialogs (such as Invert) can now be applied non-destructively on non-raster layers such as layer groups and link, text, and vector layers.

PSD Support Improvements¶

Normally we list all file format updates in a combined section, but there has been so much work done on PSD support (and by so many people) that we wanted to highlight it in more detail.

First, new contributor Frank Teklote has been busy improving our compatibility with PSDs. His big project for this release was creating a PSD metadata export procedure for TIFFs and JPEGs. This complements our existing PSD metadata import procedure, meaning that if you import a JPEG with paths or a TIFF with layers (or create one in GIMP), that information can now be retained in the exported image.

Another great thing about Frank’s work is that as we continue to improve our PSD compatibility, the TIFF and JPEG export features will automatically get those updates too!

Related to that, Jacob Boerema has implemented PSD Descriptor import support. Most of our current PSD support has been based on the public Adobe specification. This document was last updated in 2019 however, and modern PSDs use a relatively undocumented text format called Descriptors to store many features.

Now that GIMP can read descriptors, we’ve begun drastically improving our PSD import support. To list just a few updates: text layers are now editable, a number of adjustment layers and modern layer styles appear as their GEGL equivalents, and solid color shapes are imported as vector layers. This is an active area of development, including by two of our GSoC students Akascape and Waris Maqbool. We hope this work will make it easier for GIMP users to interact with existing PSD projects!

Native File Chooser Dialogs¶

We have always used the file chooser dialog provided by the GTK GUI library for people to find, load, and save files in GIMP. While the file chooser does the job, it often works differently than the “native” file chooser on non-GNOME platforms like Windows, macOS, and KDE. Additionally there have been some changes to the UI of this dialog in GTK3, which has inspired some strong feedback in our issue tracker!

Therefore, Alx Sa has begun porting GIMP’s file choosers to the “native” option provided in GTK3. This means that when you open or save a file, you will see your platform’s standard file chooser dialog instead of the GTK dialog (unless your platform uses that already, in which case there will be no change!)

Many of the simple dialogs have already been converted. Those with more complex additional features will require some workflow redesigns, which we’re still developing.

User Experience and Interface Updates¶

A lot of new and existing contributors have submitted improvements to GIMP’s user interface and its user experience. We wanted to highlight their efforts, and encourage you all to continue sharing your feedback on our design issue tracker.

Designer Denis Rangelov has been hard at work updating GIMP’s UI icons. He recreated our layer lock icons to create a more consistent look.

He also took on the monumental task of converting all 78 of our cursor icons to SVG, which will allow us to scale them for higher resolution displays without losing quality!

Original Raster Cursor	Denis’s Vector Cursor

There have been reported performance issues when drawing or zooming into the canvas when the canvas view was rotated. New contributor woot000 diagnosed the problem and created a fix. Now the “checkerboard” transparency pattern no longer rotates when the canvas does, which significantly boosts performance when painting or editing. They also fixed a related issue where the checkerboard pattern would disappear when zooming into the canvas past a certain point.

Gabriele Barbero implemented a redesign of the Search Action UI which was designed by Denis Rangelov. The new layout makes the associated shortcut key more visible, and is more consistent with the menu layouts.

Bruno Lopes has been working to fix issues with pop-up dialog displays on macOS. Since traditionally we have fewer macOS developers compared to other platforms, we’re really happy to see improvements for these users!

New contributor Andreas Vukman improved our Pattern dock display. Now smaller patterns tile to fill the available space, creating a consistent preview for all patterns instead of having some patterns display with odd amounts of padding. We think it makes the dock look much nicer!

Richard Gitschlag has updated the on-canvas text editor to allow selections when you Shift+Click in the text. It should now work similar to what you can do in a word processor like LibreOffice.

In previous versions of GIMP, you imported or exported metadata from the Metadata Editor by selecting an option in a dropdown. Ahmed E. Yassin has made this process more intuitive (and more consistent with the rest of GIMP’s UI) by replacing the dropdown with two buttons instead.

Ondřej Míchal reviewed several portions of GIMP’s UI and replaced many instances of the Spin Entry widget with Spin Scale. The Spin Entry widget is difficult to use when the width is shrunk, so this change improves usability in many areas of the UI.

Assorted Changes and Fixes¶

Our four GSoC interns have been continuing their work since the midpoint update. Recently, Waris Maqbool‘s Sharpen filter was merged into GEGL, so it’ll be available in the next GEGL release.

New contributor Dimitriy Ryazantcev has submitted several patches for improving our Windows ICO/CUR/ANI support. They’ve already fixed the rendering for certain 32bit ICO formats and made our loading and preview algorithms better match the Windows specification.

Estecka has fixed a rendering issue when applying NDE filters on passthrough layer groups, which made the image look different depending on whether the group had child layers or not.

New contributor Petr Vorel fixed a bug where pressing Alt+0 did not open the tenth most recent image in your history.

Lloyd Konneker, our main Script-fu contributor, fixed a regression in third party scripts where the number range for certain parameters wasn’t shown in the GUI.

Jacob Boerema and Alx Sa have responded to and patched a number of security reports about potential flaws in some of our image plug-ins.

What’s Next¶

There’s more in-progress work that we look forward to sharing with you all soon!

There is not an official 3.3.2 development release yet, as several roadmap items are still in-progress. If you’re feeling really adventurous and just can’t wait, you can try our “nightly” builds. Instructions are under the Automatic Development Builds header.

In the meantime, we are planning to release GIMP 3.2.6 in the coming weeks. It is a stable release so it won’t include many of the new features described here. However, it will have a number of important bug fixes and small improvements. We’ll discuss these more in the 3.2.6 release news post!

The LibreOffice Conference 2026 will take place in Pordenone, Italy, from September 10 – 12. And now the schedule is online, with:

• 8 conference tracks
• 64 sessions
• 49 speakers

Click here to view the schedule

This is the second part of our interview with the Bundesheer (see here for the first).

At the LibreOffice Conference 2025, you showcased the new LibreOffice features sponsored by the Austrian Armed Forces. How did that come about?

From the very beginning, we clearly recognised the need to further develop LibreOffice. Before finalising our plans, we also examined how we could continue to develop the product. Ultimately, we issued a Europe-wide, open call for proposals to secure both support and development capacity for LibreOffice. The way we selected the product enhancements stemmed in part from this preliminary study, because we had identified specific import capabilities and compatibility requirements.

That’s one major aspect: improving interoperability in line with our needs. The other focus was on improving LibreOffice based on ongoing user feedback and feedback regarding collaboration with external organizations. One example of this was the “Notes” bar in Impress. In the past, users had to edit notes in a separate notes view.

We were told very early on that users wanted to be able to do this directly within the slide editing view. This is a very well-known enhancement that we sponsored, which – I think – works very well. In addition, there are many other details, such as scrolling through presentations with the mouse wheel. Previously, you had to keep switching back and forth to the slide overview view to scroll. Now all of this is possible right from within the slide, which simply makes it easier to use and also increases acceptance because users expect it.

I could list many more extensions. We’re not the only ones contributing a great deal to LibreOffice – we see ourselves as part of the community, and we’re happy when the community uses our contributions and when others contribute their own, which we’re of course very happy to use as well. That’s what makes the project so attractive and successful.

Features and improvements in LibreOffice, sponsored by the Austrian Military (this is a slide from a presentation at the LibreOffice Conference 2025)

Have you also developed external extensions?

We’ve developed extensions for internal use, but there are also several publicly available extensions. One of them integrates our own help page, since we provide targeted help within our internal systems.

On a much larger scale, there’s an extension hosted on GitHub that covers military-tactical symbols. It’s available as open source software, so anyone can use it. This is actually an extension that, although it’s still in “release candidate” status, already works well. The extension is, of course, also suitable for collaboration with other armies. Its functionality is unique. To my knowledge, it’s not available anywhere else.

Do you also use the Open Document Format internally?

Yes – one of the advantages of LibreOffice is that the format is ISO-standardised and truly open. You get the best functionality in LibreOffice when you use ODF. We use ODF throughout. It’s clear that our external partners don’t do this to the same extent. This is where LibreOffice benefits from its ability to handle (read and edit) Office Open XML (OOXML) documents as well.

LibreOffice doesn’t have a built-in email client. How did you handle this issue during the migration?

The Austrian Armed Forces protect the Austrian population; to make this possible, we need, for example, systems that function independently of external parties. We have a large number of systems based on open source solutions and many solutions that are platform-independent. This includes the email system.

Therefore, we didn’t have to replace Outlook or Microsoft Exchange.

At the LibreOffice Conference, you emphasised that the migration was never about saving on licensing costs. The migration was driven by other reasons, correct?

The switch to LibreOffice in the Austrian Armed Forces stems from the necessity that we must be able to function even when nothing else is working. In other words, we cannot rely on public infrastructure. We cannot rely on our data being processed in another data center.

Therefore, the top priority in this transition – unlike 20 years ago, when people very often considered switching to a free office suite or Linux in the workplace for cost reasons – was digital sovereignty.

As for the costs: It was clear to us from the start that we would have to invest in the product in order to gain the additional functionality we needed and to improve interoperability.

Would you like to say a few words about the foundation – that is, The Document Foundation?

Why did we choose LibreOffice in the first place – after all, there are alternative products? LibreOffice isn’t the only solution. First, LibreOffice uses ODF, the open and standardised file format. That’s very important. Second, LibreOffice is truly fully open source software – it’s not a product that just has an open source “core.” There’s no risk of having to pay for variable enterprise features.

And the fact that this is the case is very closely tied to the foundation of LibreOffice, namely The Document Foundation. The way this open source project is implemented and anchored through the foundation – that’s an important guarantee and a key factor in its reliability for us.

Another point is that there is an ecosystem. There are several companies that offer the services we need. Using open source doesn’t just mean using free software – for us, it means we need maintenance, support, the ability to further develop the software, addressing security vulnerabilities, and secure software deployment. All of this comes with a very mature software product that is constantly being developed. That was a key factor in our decision.

What advice would you give to others who are also planning to switch to LibreOffice and open source?

First: There’s a vast amount of information available within the community. It’s important to familiarise yourself with the product. How does LibreOffice work? How does Bugzilla work? Where can I find issues that might not be working but are of interest to me? Where can I find roadmaps for new features, release notes, and so on?

Second: It’s absolutely crucial to properly prepare and fund the resources for a project like this. IT managers have gotten used to rolling out new Office versions without much effort.

However, switching from one office suite to another is actually a massive migration project. This should not be underestimated. It’s not just a matter of installing the software; it requires change management, people to provide support, test the software, and work on new features. It requires the support of service providers. All of this must be prepared in advance. And that’s what sets it apart from previous new office suite releases. You’ll need a project team for this – migration isn’t something you can just do on the side. So, you’ll need proper project organisation and agile change management. How can I provide my users with the necessary knowledge based on their needs? What communication channels do I have to keep my users informed and stay in touch with them?

We – the Austrian Armed Forces – have already received many inquiries about the transition, and we have shared our experiences with numerous organisations. We would be delighted to help build a LibreOffice community for government and enterprise organisations in order to accelerate the collaborative development of LibreOffice.

To that end, I invite you to contact us at libreoffice@bmlv.gv.at.

Hi everyone,

Before we begin, let me thank all our donors and sponsors. Many thanks to all of you for the help you’re providing us!

We’ve got new HWE ISOs this month and some really exciting news. As always, please be aware that the features and improvements mentioned in this blog are a work in progress and that this is a preview of what’s to come and what’s planned for the next release of Linux Mint.

HWE ISOs

A new set of HWE ISOs is available for Linux Mint 22.3 with kernel 7.0.

For more information on HWE, or to download these ISOs: https://www.linuxmint.com/hwe.php

Environment Variables

The System Administration tool received a new page dedicated to environment variables.

Variables defined on this page are set system-wide for all user sessions (graphical and/or console).

Kernel Management

Kernel management was removed from the Update Manager and re-implemented within the System Administration tool.

This new implementation supports both Linux Mint and LMDE. It focuses on kernel series rather than individual kernels.

Kernel management is very simple: You decide which series you want to track and how many older kernels you want to keep. You then receive kernel updates for your tracked series in the Update Manager, and older kernels are automatically removed by the system on a weekly basis.

If you need to free up space immediately, cleanups can be triggered manually.

You can also click on the History button to see which kernels were removed and when.

If you install a kernel from an unknown or custom series, the tool will list its series and give you the ability to mark it as tracked.

In the screenshot below, we installed an OEM and a Real Time kernel.

When you track a known series, the tool installs its meta-packages and ensures you receive updates for that series. In the case of a custom series, the tool doesn’t know how to do that and warns you that it is your responsibility to do so.

If a series is not tracked, all of its installed kernels get automatically removed during the next cleanup. Unless… you protect them.

You can click the “View all kernels” button to install, remove, or protect individual kernels.

When a kernel is marked as “protected”, it becomes immune to kernel cleanups and never gets deleted.

Keyboard Layouts and IM

Cinnamon received support for Fcitx5 with full Wayland/X11 parity.

With Fcitx5 selected in the Input Methods settings, Cinnamon no longer launches ibus-daemon, but uses a different internal handler instead. It lets you define a single layout and delegates everything else to Fcitx.

Cinnamon also features a new keyboard layout viewer.

This viewer replaces the gnome-kbd viewer, which was discontinued.

Other improvements

Interacting with the panel when working with fullscreen windows feels much more natural than before. You can click other components of the panel, close the menu, open other applets, etc.

Sponsorships:

Linux Mint is proudly sponsored by:

Gold Sponsors: Silver Sponsors:

Bronze Sponsors:

Donations in June:

A total of $14,761 were raised thanks to the generous contributions of 419 donors:

$580 (7th donation), Natalya S.
$464 (2nd donation), Michael S.
$300 (35th donation), John Mc aka “Land Research Project“
$300 (9th donation), André Inácio
$290, DJ
$250 (5th donation), Benjamin M.
$232, Dr. S. T.
$232, Götz K.
$145, Libre à Quimperlé
$128, Martin B.
$120 (8th donation), Michael P.
$116 (21st donation), Jiří B.
$116 (14th donation), Hans-Georg Thien
$116 (9th donation), Walter K.
$116, Jan K.
$116, Jan S.
$116, Martin D.
$116, OuestWare
$116, Richard L.
$116, Silvia S.
$116, Thomas E.
$116, Wolfgang H.
$100 (8th donation), William C.
$100 (3rd donation), abrames
$100 (3rd donation), Dale K.
$100 (3rd donation), Gilbert B.
$100 (3rd donation), Mark S.
$100, Adam S.
$100, Dan B.
$100, Edward R. K.
$100, Isaac K.
$100, Michael S.
$100, Services Multiples R.
$87 (2nd donation), Florian S.
$81, Benjamin S.
$75, Javier S.
$70 (6th donation), Vincent F.
$70 (3rd donation), ZS
$70, Simon H.
$58 (18th donation), Roland H.
$58 (17th donation), Jyrki A.
$58 (12th donation), Karl H.
$58 (7th donation), Gerald H.
$58 (5th donation), Karl-heinz P.
$58, Alexander H.
$58, Anton R.
$58, Bernd C.
$58, Daniel B.
$58, gilles Delaguette aka “gillou”
$58, Günter A.
$58, John P.
$58, Kai N.
$58, Levente D.
$58, Martin K.
$58, Michael T. B.
$58, Michel O.
$58, Nick V.
$58, Ralf E.
$58, Ralf S.
$58, Rene W.
$58, Rolando
$58, Rupert W.
$58, Ruth S.
$58, Sanny S.
$58, Stefan I.
$58, Thomas B.
$58, William A.
$58, William F.
$58, Yeun H. T.
$52, Jeffery M.
$51, John A.
$50 (21st donation), Mothy
$50 (17th donation), Anthony C. aka “Ciak”
$50 (11th donation), Peter L. aka “Pedro“
$50 (8th donation), Gerard S.
$50 (7th donation), Tim A.
$50 (6th donation), Leonhard R.
$50 (5th donation), Robert L.
$50 (3rd donation), Soeren
$50 (2nd donation), James M.
$50 (2nd donation), Jason E.
$50 (2nd donation), Johnny R. D.
$50 (2nd donation), peter T.
$50 (2nd donation), Timothy J I.
$50, Algie M.
$50, ANDREW M.
$50, Austin R.
$50, Caleb S.
$50, Dustin P.
$50, edward K. aka “edthefair”
$50, Gohér L.
$50, Joshua E.
$50, Lionel L.
$50, Maciej S.
$50, Marco M.
$50, Mark W.
$50, MOHD A. A. H.
$50, Richard A.
$50, Rolando G.
$50, Ruiping L.
$50, Samuel G.
$50, Shay C.
$50, vitalii V.
$50, Vitalox.co.uk
$50, Wayne L.
$50, WILSON N. S.
$50, Øyvind L.
$46, José R. B. U.
$46, Maik S.
$45, James R.
$41, M.J. D.
$40 (10th donation), Orlando O.
$40 (2nd donation), Jonathan L.
$40, Grant L. S.
$40, Joseph D.
$37, siobhan M.
$36, Shawn D.
$35 (3rd donation), Renee M.
$35, achim M.
$35, David B.
$35, Donald B.
$35, Fazekas F.
$35, GARRY J. W.
$35, Helmut E.
$35, P J. C.
$35, Russell R.
$35, Simon H.
$35, Teo S.
$35, Tobias K.
$35, vincent R.
$31 (6th donation), David B.
$31, Johannes W.
$30 (8th donation), Doug S.
$30, David S.
$30, Jan V. D.
$30, MR G. S.
$30, Terence R.
$29 (2nd donation), Askeldaja
$29 (2nd donation), Kerry H.
$29, Andrea P.
$29, Andrew G.
$29, Michael Koch
$29, Mr T. A.
$29, Warren B.
$28 (4th donation), Toon V.
$27, Benjamin B.
$25 (64th donation), Linux Mint Sverige
$25 (19th donation), Donna B.
$25 (17th donation), John N.
$25 (6th donation), Oleksandr N.
$25 (2nd donation), Roger M.
$25, John H.
$25, Ong L. Z.
$25, ROBERT A. B.
$23 (119th donation), Johann J.
$23 (78th donation), Bryan F.
$23 (72nd donation), Peter E.
$23 (39th donation), Stefan W.
$23 (34th donation), Benjamin W. aka “UncleBens”
$23 (32nd donation), Marek S.
$23 (14th donation), Frank W.
$23 (8th donation), Tapani H.
$23 (6th donation), Robert J.
$23 (4th donation), Guillaume P.
$23 (4th donation), Jeff H.
$23 (4th donation), Pedro A.
$23 (3rd donation), Adam B. aka “Neomodus”
$23 (3rd donation), Benjamin L.
$23 (3rd donation), Gehova L.
$23 (3rd donation), Systemutvikler R. S.
$23 (3rd donation), Thomas H.
$23 (2nd donation), Henrik M.
$23 (2nd donation), Ian K.
$23 (2nd donation), Michel S.
$23 (2nd donation), Norbert E.
$23 (2nd donation), Pascal T.
$23 (2nd donation), Peter V. R.
$23 (2nd donation), Z A. Z. A.
$23, aka “Dealer Dahl”
$23, Andreas S.
$23, Anonymous
$23, Dan M.
$23, Frédéric B.
$23, Heinz-Jürgen F.
$23, Helmut M.
$23, Henning G.
$23, Henrik H.
$23, J.P. G.
$23, Jochen H.
$23, johan B. aka “Woody”
$23, Johannes A.
$23, John M. S.
$23, Klaus P.
$23, Marcus B.
$23, Martin E.
$23, martine P.
$23, Michael N.
$23, michael P.
$23, Mr L. W.
$23, Nurbol K.
$23, Paolo R.
$23, Randy Lahey
$23, Riccardo B.
$23, Ronald H.
$23, Sebastian B.
$23, Sonja S.
$23, staffan O.
$23, Thomas B.
$23, Tobias E.
$23, WILFRIED H.
$23, Wolfgang M. S.
$21 (6th donation), James H.
$20 (53rd donation), John D.
$20 (31st donation), Denis D.
$20 (16th donation), Michel S.
$20 (12th donation), Randall W.
$20 (9th donation), Leela A.
$20 (9th donation), Ricardo M.
$20 (7th donation), Michael G.
$20 (5th donation), Gary S.
$20 (5th donation), Nathan B. aka “Diginate “
$20 (3rd donation), Theodore K.
$20 (2nd donation), Dmytro Z.
$20 (2nd donation), Jerome P.
$20 (2nd donation), Richard L. S.
$20 (2nd donation), Stephen B.
$20 (2nd donation), Terrence C.
$20, Aaron A.
$20, any N.
$20, Brian P.
$20, Bryan J.
$20, David S.
$20, Elijah W.
$20, Elizabeth H.
$20, Gervase G.
$20, GLEATON’S
$20, HYUNGU H.
$20, James M.
$20, Jay G.
$20, Jim B.
$20, Martin J.
$20, Michael B.
$20, Paul B.
$20, Randi J. R.
$20, Revd. Barry Keal aka “G4HDU“
$20, Richard J.
$20, RICHMOND D.
$20, Robert H.
$20, Ron H.
$20, Samuel K.
$20, Steve T.
$20, The Best Buy
$20, Thomas F. aka “Tom”
$17 (93rd donation), Andreas S.
$17 (8th donation), Tristan V.
$17 (5th donation), Tomasz S.
$17, Álvaro V.
$17, Michal L.
$15 (9th donation), mitch K.
$15 (4th donation), Snorre L.
$15 (2nd donation), Justin C.
$15, Josephine
$13 (19th donation), Alessandro S.
$12 (56th donation), Francois-R L.
$12 (51st donation), Thomas Rehm
$12 (50th donation), Tugaleres.com
$12 (30th donation), Adian K.
$12 (24th donation), Slobodan Vrkacevic
$12 (22nd donation), Eskild T
$12 (18th donation), Abe Z.
$12 (17th donation), Artem Ignatyev aka “ZaZooBred”
$12 (17th donation), Tomi P.
$12 (12th donation), Intralogistiker
$12 (8th donation), Rainer B.
$12 (7th donation), J M. H. C.
$12 (6th donation), Claudio A.
$12 (6th donation), Stefan B.
$12 (5th donation), Lyuben R.
$12 (5th donation), Olivier R.
$12 (5th donation), ronald H.
$12 (4th donation), Bartomiej T.
$12 (4th donation), Matthias K.
$12 (4th donation), Renaud A.
$12 (3rd donation), Arne A
$12 (3rd donation), Donald B.
$12 (3rd donation), FrankFRL
$12 (3rd donation), Raul Z.
$12 (2nd donation), Brian C.
$12 (2nd donation), Frank F.
$12 (2nd donation), Marc L.
$12 (2nd donation), MorpurgoMedia.nl aka “Morpurgo Media“
$12 (2nd donation), Nektarios T.
$12 (2nd donation), Ricardo O.
$12 (2nd donation), Sebastian M.
$12, –
$12, Antonio A. M.
$12, Antonio S.
$12, Bernhard R.
$12, Bettina B.
$12, Bogdan D.
$12, Christian B.
$12, Christoph A.
$12, Claes C.
$12, David P. B.
$12, Esteve L. G.
$12, Eugen W.
$12, Fidel V.
$12, FLORIAN K.
$12, Giobatta L.
$12, Helmut S.
$12, Henning S.
$12, Igor C.
$12, Jan O.
$12, Jesse D. A. R. D. S. J.
$12, Joe S.
$12, John D.
$12, Kalin S.
$12, Karel J.
$12, Klaus D. N.
$12, Koski M. K. aka “Wintageman“
$12, Lauris S.
$12, Mark C.
$12, Markus B.
$12, martin G.
$12, Michael D.
$12, Neil G.
$12, Noel A.
$12, Ralph A. W.
$12, Renzo M.
$12, Ruben O. K.
$12, Steffen H.
$12, Sven S.
$12, Tamás R. V.
$12, Thomas L.
$12, tj J.
$12, Wolfram S.
$11, Jozef T.
$10 (123rd donation), Thomas C.
$10 (65th donation), Philip Woodward
$10 (43rd donation), Sami Mannila
$10 (19th donation), Thevirtua
$10 (14th donation), Mariusz B.
$10 (9th donation), Korora Solutions
$10 (9th donation), Steven L.
$10 (6th donation), S Russo
$10 (6th donation), Selwyn A.
$10 (5th donation), makeup
$10 (4th donation), Earl R.
$10 (4th donation), notariat
$10 (3rd donation), narghilea
$10 (3rd donation), Richard W.
$10 (2nd donation), Daniel R.
$10 (2nd donation), Jacek B.
$10 (2nd donation), Metehan K.
$10 (2nd donation), Timothy C.
$10 (2nd donation), VPRECA
$10 (2nd donation), William P.
$10, B P.
$10, Brody McDonald
$10, Cesar R. B.
$10, Craig D.
$10, Dean D.
$10, Hector G. G.
$10, Michael S.
$10, NEWT L. H.
$10, Roger L.
$10, Seth A.
$10, Szilvia D.
$10, Timoth O.
$10, Vasilis A.
$10, Victor M. aka “Bull”
$10, William R.
$177 from 45 smaller donations

If you want to help Linux Mint with a donation, please visit https://www.linuxmint.com/donors.php

Patrons:

Linux Mint is proudly supported by 2,353 patrons, for a sum of $5,318 per month.

To become a Linux Mint patron, please visit https://www.patreon.com/linux_mint

Many government departments around the world are moving away from vendor lock-in by tech giants, and switching to free and open source software like LibreOffice. This helps with privacy, security, and digital sovereignty. One such example is the Austrian Military (Bundesheer), which has moved 16,000 PCs from Microsoft Office to LibreOffice. We talked to them, to find out why and how they did it…

When did all of this start? When were the first decisions made?

It began in 2020, with the trend toward running software increasingly in the cloud and less on-premises on devices within companies. At that time, we examined what guarantees existed for running software – specifically Microsoft Office – directly in the workplace without any cloud connection. So the review and preparation began in 2020.

In late 2022 and early 2023, the decision was made to switch to LibreOffice. The goals were to ensure that data never leaves the company and that the office applications can be used without external dependencies.

Who made the decision?

The decision was structured in such a way that our “corporate leadership” – that is, the Federal Ministry of Defence – could decide, based on the information compiled regarding future software development and cloud dependencies, that we would switch to LibreOffice.

It was actually decided by the Federal Minister’s cabinet and the relevant departments – so at the very top.

Did you create a “timeline” at the beginning – something like “Y should happen by X” and so on?

After we received the assignment, we carried out the planning to determine how the transition could take place and what needed to happen. The plan included, from an early stage, that we would guide our users to LibreOffice in a timely manner, partly by installing LibreOffice at the user’s request. That is, we made it available, and the users who wanted it could have it installed.

We saw very high adoption rates – not 100%, but about half.

Half of 16,000?

Yes. And the next step we planned was to make its use mandatory, because it’s crucial not only to announce that something new is coming but also to require its use so that people have to start working with the tool early on. Of course, switching from an Office suite that’s been used in the company for over 30 years to a completely new product – even if it looks similar but behaves differently – requires practice.

That’s why we specifically made the use of LibreOffice mandatory in selected services. And we did this as early as 2023, so that users could get familiar with it well in advance. This gave users time to tailor the transition to their own needs and prepare for it, and we didn’t just flip the switch all at once with a “big bang.” The change was announced over the course of several years.

Finally, in December 2024, the use of LibreOffice became mandatory for internal collaboration. This meant we actually provided several years of preparation time to make this transition as smooth as possible.

(Photo credits: Bundesheer Fotos, CC BY-NC-SA 2.0)

So many people switched to LibreOffice voluntarily from the start, without being forced to. Was there a lot of resistance? Did you customise the user interface?

The 8,000 users mentioned installed the product to see what was coming. That doesn’t mean that all 8,000 of them immediately started using LibreOffice. But it was a good indicator for us to gauge the mood. If 200 people install it, that’s different from when there are so many.

Early on, before we mandated its use, we provided extensive e-learning modules and videos – including what we call “fast tracks” for the individual modules. With these, it was possible to learn the most important changes for Writer, Calc, Impress, and Base within 15 minutes, so users wouldn’t fall into the typical pitfalls. Anyone who invests those 15 minutes will find it much easier to use the software.

We gave users the opportunity to prepare and view these courses and videos on their own at a time of their choosing.

Another important point: We’ve learned that we need to quickly address individual users’ questions – such as those regarding unfamiliar workarounds or missing features – for the benefit of the broader community.

That’s why we specifically looked for suitable communication channels, and we then agreed to publish a so-called “Tip of the Week” about once a week on a very specific, clearly defined topic. And this “Tip of the Week” appears every Monday on the intranet with a current topic. That means anyone who opens their browser on Monday will see the “Tip of the Week.”

It explains topics we covered the previous week. When we release a new version, there’s a “Tip of the Week” featuring the latest features. When we roll out new functions and enhancements – some of which are sponsored by the Austrian Armed Forces – we highlight them in the “Tip of the Week.”

But we also cover usability topics – for example, how to enable the menu bar even when the tabbed interface is selected. How to use presentations across multiple screens, and so on and so forth. We’ve been doing these “Tips of the Week” for two years now, and they’ve been very well received. It’s a great communication tool for us.

Next week we’ll post Part 2 of the interview, looking at the features and improvements in LibreOffice that the Austrian Military sponsored, and tips for future migrations. Stay tuned…

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

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

Core Openness Criteria

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

Recognized Frameworks

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

Comparison of ODF and OOXML

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

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

Comparison Table

Key Openness Differences

Public Specification & Transparency

• ODF: Conceived from the beginning to be a modern, clean XML specification. “ODF is the only openly available standard, published fully in a document that is freely available and easy to comprehend”, as noted by GranneBlog: https://blog.granneman.com/2009/02/06/odf-compared-constrasted-with-ooxml/
• OOXML: Designed primarily to map Microsoft Office’s old binary data into XML. It is split into Strict and Transitional variants. “Transitional is everything else: a vast catalogue of compatibility features, deprecated elements, platform-specific behaviours, and references to undocumented quirks of Microsoft Office versions from the 1990s.”, as noted by the TDF Blog: https://blog.documentfoundation.org/blog/2026/06/02/a-standard-in-name-only/

Legal & Intellectual Property Rules

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

Technical Discrimination & System Control

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

INTERESTING REFERENCE: the Italian definition

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

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

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

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

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 had one update in July: LibreOffice 26.2.5, the fifth maintenance update to the LibreOffice 26.2 branch.

• We also said a big welcome to our new TDF members! Members – more formally known as the “Board of Trustees” – are a crucial part of The Document Foundation, the non-profit entity behind LibreOffice. They are people from across the globe who contribute time, effort and skills, whether on a voluntary or paid basis.

• Then there was another section from the TDF Annual Report 2025, Policy and Digital Sovereignty. This section looks at Germany’s IT Planning Council committing to ODF, the approval of ODF 1.4, and public migrations to LibreOffice.

• On a similar topic, we posted how proprietary formats have become Microsoft’s main tool for lock-in.

• Back to the software itself: we posted the LibreOffice State of the Project (July 2025 – June 2026), based on data from July 1, 2025, to June 30, 2026, extracted from the LibreOffice dashboard and the Matomo repository. This is full of statistics describing the health of the project and the community.

• An additional section from TDF’s Annual Report 2025 was the foundation’s financials and budget.

• Meanwhile, the small team at TDF is expanding, with a job offer for a new Marketing and Communication Professional. Applications are open until the end of August.

• Finally, we wrapped up the month discussing Microsoft’s end-of-life of Office 2021, and how LibreOffice stays yours for a lifetime. And on a similar topic, we looked at why OOXML-based suites handle ODF badly.

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.

🚀 Features

• Added button for renaming tags (#1173) by @EmaYYellow in #1173
• Added audio player for media attachments (#1172) by @deprov447 in #1172

🐛 Bug Fixes & Minor Changes

• Format dates with device preferred 12/24-hour clock (#1183) by @arpitagarwal1301 in #1183
• Honored custom tab preference in notifications (#1182) by @arpitagarwal1301 in #1182
• Fixed crash introduced by audio player feature by @spacecowboy in commit

🌐 Translations

• Updated translations from Hosted Weblate (#1174) by @weblate in #1174
• Updated German translation using Weblate in commit
• Updated Serbian translation using Weblate by @eevan78 in commit
• Updated Ukrainian translation using Weblate by @andm18 in #1186

❤️ New Contributors

• @deprov447 made their first contribution in #1172
• @EmaYYellow made their first contribution in #1173
• @arpitagarwal1301 made their first contribution in #1182

On 30 July 2026, the United States Cybersecurity and Infrastructure Security Agency published Open Source Software: Security Principles and Practices, a 31-page guidance document for federal civilian agencies. It is available at no cost and marked TLP:CLEAR, meaning it may be shared without restriction.

The document is addressed to US federal agencies, and it fulfils obligations under two executive orders on federal cybersecurity. It covers four areas: using open source solutions, contributing to open source projects, producing open source software, and evaluating open source artificial intelligence models. The observations below concern the first three.

Its analytical content is not jurisdiction-specific, and public administrations elsewhere — including in Europe — will find that it articulates, in the vocabulary of risk management, several positions that the open source community has been arguing for two decades.

What the guidance actually says

The central claim is more precise than the headlines suggest. CISA does not assert that open source software is more secure than proprietary software. It states that OSS is “no more or less risky than other software,” and locates the difference elsewhere: with open source, an organisation can assess code quality and security directly, rather than relying solely on vendor assurances.

This is a claim about verifiability, not about defect rates. It is also the more defensible claim, and the more consequential one for procurement. An agency evaluating proprietary software is evaluating a vendor’s statement about its own product. An agency evaluating open source software is evaluating the product.

The guidance draws the corollary explicitly. Among the benefits it lists for federal agencies is reduced vendor lock-in: open standards and modifiable code, CISA writes, protect agencies from “proprietary dependency traps.” A national cybersecurity authority has placed lock-in inside a security document rather than a competition-policy one. That is a meaningful shift in where this argument is permitted to live.

The C4 Framework

The most practically useful part of the guidance is Appendix A, which sets out the C4 Framework for assessing whether an open source project is trustworthy. Its premise is that, because contributors may be pseudonymous and are bound by no delivery obligation, trustworthiness cannot be assessed from who produced the software. It must be assessed from how the software was produced — which open source development makes visible in a way that closed development does not.

C4 groups the evidence into four categories:

• Codebase — commit recency, known vulnerabilities, dependency currency.
• Community — number of maintainers, institutional structure, whether the project sits within a foundation.
• Conduct — whether there is a vulnerability disclosure policy, whether code review is required, whether maintainers merge their own commits, the licence, the code of conduct.
• Configuration — whether defaults are secure, and what hardening the software supports.

The framework is applied in five steps: identify measurable criteria, determine risk tolerance and weight the criteria, collect observations (with automated tooling where available), evaluate against each criterion, and compare the result to the tolerance.

We would encourage public administrations to apply this framework to LibreOffice. Every category can be answered from public evidence: a continuous commit history since 2010, a published security policy and disclosure process, mandatory peer review, an OSI-approved licence, a documented code of conduct, and a governance structure — The Document Foundation, a German Stiftung with an elected Board of Directors — that is a matter of public record rather than of assertion.

We would encourage administrations to apply the same framework to every candidate solution, including proprietary ones, and to note which questions can be answered and which cannot.

Contributing, and the support question

The guidance also addresses a question that public administrations regularly raise about open source adoption: who is responsible for fixes. CISA’s answer is that no single entity is obliged to provide them, and that agencies should therefore plan accordingly — assigning internal staff, contracting third parties, or both — while following two principles in dealing with upstream projects: collaborate rather than demand, and push fixes upstream.

This is a fair description of how the LibreOffice ecosystem works. Support, long-term maintenance, and custom development are provided by certified developers and certified migration professionals, whose contributions return to the shared codebase and benefit every other deployment. The guidance is right that this requires organisations to plan for it. It is also right that the resulting improvements are shared rather than captured.

CISA further notes that where a project becomes unmaintained, an organisation may as a last resort take over a fork. This option has no equivalent in proprietary software, where end of support arrives on the supplier’s schedule and offers no remedy at all.

A note on scope

The document does not name any product. CISA states explicitly that it does not endorse commercial entities, products, or services, and nothing in the guidance should be read as an assessment of any particular software. What it provides is a set of criteria. The observation that LibreOffice satisfies them is ours, and rests on evidence that anyone may check.

Open Source Software: Security Principles and Practices is available from CISA: https://www.cisa.gov/resources-tools/resources/open-source-software-security-principles-and-practices

CISA’s announcement: https://www.cisa.gov/news-events/news/cisa-guide-helps-federal-agencies-securely-and-effectively-use-open-source-software

LibreOffice extensions are optional, third-party addons for the suite, that add extra functionality. Bora Yarkın has been working on a new extension for LibreOffice Impress, so let’s hear from him about it…

Tell us about it!

The extension lets you control a LibreOffice Impress presentation from your phone or any other device with a modern web browser.

When you start the remote, LibreOffice displays a QR code. Scan it with your phone and the presentation starts from the first slide. The phone interface then shows the current slide, presenter notes, elapsed time and navigation controls.

I tried to make the process as simple as possible: no separate mobile application and no manual pairing codes.

The remote can be opened from the Slide Show menu in LibreOffice’s top application menu bar—the menu alongside File, Edit, View and the other main menus.

This should not be confused with the Slide Show tab inside LibreOffice’s Tabbed user interface. LibreOffice’s UNO extension API does not currently let me add commands to that built-in tab. When using the Tabbed interface, the remote commands are therefore available under the Extensions tab instead.

The extension currently provides several connection modes:

• Local network: The phone connects directly to the computer running LibreOffice through its local IPv4 address. This is the main mode and the one I have tested most thoroughly.
• Direct IPv6: Works similarly, but uses an IPv6 connection. It is still marked experimental because my home internet connection is currently the only IPv6 network I can properly test with.
• Relay server: A small Python service that can be hosted on Linux or Windows. It is useful when the phone and computer are on different networks or when direct connections are blocked by carrier-grade NAT, firewalls or other network restrictions. It also supports multiple connections, so an organisation can host one relay server on its own infrastructure.
• LocalTunnel: An experimental fallback that creates an outbound connection through the LocalTunnel service. I consider this a last-resort option when the other connection methods are unavailable.

The compatible relay-server package is bundled with the extension. It can be downloaded or extracted directly from the Remote Settings window by selecting “Get Relay Server”. The package includes the required documentation and setup instructions.

To install the extension, download the .oxt file from the LibreOffice Extensions website or GitHub and open it with LibreOffice. It can also be installed manually through Tools > Extensions. After installation, restart LibreOffice if requested.

The extension includes translations for more than 100 languages and automatically follows LibreOffice’s interface language. English and Turkish are the two languages I have personally checked. Many of the other translations were created with ChatGPT, so I cannot guarantee their quality and would be very grateful for corrections from native speakers.

Why did you create it, and what was the process like?

The original inspiration came from Apple Keynote.

When Keynote is installed on both a Mac and an iPhone, the phone can be used to control the presentation while also displaying presenter notes. That feature completely changed the way I give presentations.

Over time, my slides became more professional and less text-heavy. Instead of putting everything on the slide, I started using the presenter notes almost like a teleprompter, with the text I actually planned to say. This helped move the audience’s attention away from reading the screen and back towards me.

That workflow worked perfectly for a long time, but I never really liked Keynote itself. I could not get used to its interface, and Apple’s decision to introduce paid features was the final reason for me to start looking for an alternative.

There were already several possible solutions, but none of them really worked for me.

LibreOffice previously had its own Impress Remote mobile application, but it has not been maintained for a long time and is no longer practical on many current devices and systems.

Browser-based presentation platforms can offer remote-control features, but I did not want my main presentation workflow to depend on an online service. They also do not offer the same flexibility as a full desktop office suite.

Microsoft Office was another possible option, but I am not a fan of Microsoft’s current direction, particularly the increasing integration of Copilot throughout its products.

OnlyOffice Desktop Editors is a good alternative and I used it for a while, but I encountered several bugs and eventually needed features it did not provide.

That brought me to LibreOffice, which I now find more useful and capable than the other office suites I tried. The only thing missing was the remote-presenter experience I had become dependent on with Keynote.

So I decided to build it myself.

I work mainly in IT and I am familiar with programming, but I would not describe myself as an advanced software developer. Before starting this project, I knew almost nothing about LibreOffice’s UNO API.

I began with ChatGPT. I defined the architecture, features, user interface and constraints myself—including requirements such as localisation being mandatory—and used AI to help me understand UNO and implement the code. The result turned out much better than I expected.

The extension was originally only a personal project. The first version was very basic; the web interface did not even have a back button. I had no intention of publishing it. Once it started working reliably, however, I realised that other LibreOffice users might want the same experience. I decided to take the project more seriously and turn it into a complete extension rather than something that only worked on my own computer.

That meant adding a more polished phone interface, connection settings, QR-code generation, IPv6 support, the relay server, LocalTunnel support, localisation, documentation, error handling and packaging.

Publishing it on the LibreOffice Extensions website was much easier than I expected. I created an account, created the project page, entered the information, uploaded the package and submitted it. After roughly a day of review, the extension was available publicly.

How can people help with testing and further development?

The source code and issue tracker are available on GitHub. The repository includes templates for bug reports, feature requests and pull requests.

My main development and testing setup is macOS with an iPhone. I have also tested the extension on Windows and Linux, but those tests were performed under less-than-ideal conditions, including virtual machines, Remote Desktop sessions and a headless Windows Server installation.

Because of that, testing on real Windows and Linux desktop systems would be especially useful.

The areas where community help would be most valuable are:

• Testing different LibreOffice versions
• Testing Windows, Linux and different macOS versions
• Testing Android devices and different mobile browsers
• Testing IPv6 connections between genuinely separate networks
• Testing the relay server in real-world and organisational environments
• Testing unusual firewall, VPN, NAT and carrier network configurations
• Reviewing and correcting translations
• Improving the documentation
• Reporting bugs and suggesting features
• Contributing fixes through pull requests

The local IPv4 mode has been tested extensively across different local networks, internet providers and VPN configurations. The IPv6, relay-server and LocalTunnel modes need broader community testing before I would consider them fully proven.

When reporting a connection problem, including the operating system, LibreOffice version, browser, phone type, selected connection mode and basic network configuration would help enormously.

The project started because I wanted this functionality for myself. Now I would like to make it reliable enough that other LibreOffice users and organisations can confidently use it for their own presentations.

Today we’re talking to Karl-Heinz Gruner, who has been supporting the LibreOffice community at events in Germany and recently became a member of The Document Foundation, the non-profit behind the suite:

Tell us a bit about yourself!

I live in Middle Franconia, near Nuremberg. In my spare time, I enjoy riding my motorbike, even though I haven’t been getting out on rides as much as I’d like at the moment. I find hiking in the region a great way to unwind. Being active in the fresh air brings me peace and relaxation, whilst also giving me space to come up with new ideas.

Professionally, I have worked extensively with office applications from various manufacturers – both from a user’s perspective and in the context of supporting other users. A particular focus of my involvement is my work with the local Linux User Group. There, I focus on open-source software solutions, sharing experiences and imparting practical knowledge.

For what are you using LibreOffice right now?

My personal curiosity and interest in practical IT solutions prompted me to carry out a fundamental modernisation of an association’s accounting system.

The starting point was an outdated spreadsheet program that was used to create entries, reports and statements. Initially, the idea was to migrate this solution to LibreOffice Calc, making it clearer and more future-proof.

However, during the analysis, it became clear that simply revising the existing spreadsheets would not be sufficient. Consequently, the decision was made to switch to a more up-to-date system with more comprehensive functions within the existing IT environment. A key outcome of this process is the use of a comprehensive application for administration and communication.

In addition to this, I developed a training programme for the adult education centre to focus on a specific area: the professional design of documents using forms and mail merges.

What do you plan to do in the future?

Looking to the future, I believe it is particularly important to convey information through a variety of channels. Modern software offers a wide range of functions, which many users initially find difficult to get to grips with.

It is therefore crucial to break down reservations and barriers to access. Potential users should be provided with clear information, given practical support and encouraged to try things out for themselves. Software and digital services must remain not only functional but also appealing.

For me, this means continuing to share knowledge through talks and training sessions, explaining practical applications using concrete examples, and convincing users of the benefits of open solutions.

My guiding principle is: inform, provide practical support, and spark interest.

Many thanks to Karl-Heinz for his help! All contributors to LibreOffice are welcome to become members of TDF

With July being the final month for the 1st round of the 2026 Bug Accelerator Program, we focused on a rapidly landing quality of life fixes and clearing the way for the next round of BAP work in the next 3 months. With this round of changes and fixes, Inkscape 1.5 is now in a much stronger position, with over 60% completion of the current milestones.

Mike and Sean worked through a wide range of regressions and usability problems, including both issues new to 1.5, and old issues that have existed in Inkscape for years. Some of the new changes include document tabs scrolling, text and font fixes, grid fixes (a much improved UX), startup screen improvements, various shortcut fixes, improved SVG font handling, extension management fixes, and so much more.

Frankly, with so many changes, it's hard to fully quantify just how much work has been landed this month (and really, this cycle). Many thanks go to the BAP devs and the Inkscape veterans who've been providing guidance, assistance and also fixing issues alongside the BAP devs.

We still have more to go, so testing, feedback, and even suggestions are much appreciated.

Michael Terry

• Total time tracked: 52h 8m

• In progress and open items (9h 11m):

  • #6238 1.5-dev: The preferences dialog's size is not restored when reopened - (20m)
  • #5142 Text tool's font dropdown not loading fonts until mouse hover - (42m)
  • #6253 Congested and unusable font collection labels in the new Font and Text dialog - (1h 1m)
  • #631 1.5-dev: Extension Manager: Cannot install extensions nor view details on "Orphan Extensions" - (1h 10m)
  • #6279 If nothing is selected Esc should escape the selected group (not layer!) - (1h 52m)
  • #6168 Set Inverse Mask cause the masking object to lose its path effects - (3h 14m)
  • #6334 Change image in Object Properties doesn't use native file dialog - (14m)
  • #5765 Recent files list deleted files - (38m)

• Merged 17 merge requests (2h 54m):

  • !8046 Use white for default specular color - (5m)
  • !8074 Transform page border paths for coord system - (15m)
  • !8080 Correctly return when actions do not require parameters - (0m)
  • !8081 Fix grammar of action names - (4m)
  • !8082 Address clangtidy issues - (4m)
  • !8072 Don't warn on encountering non-file URIs - (3m)
  • !8071 Fix template and template category i18n on startup screen - (10m)
  • !8070 Reword paste submenu in Edit and right-click menus - (10m)
  • !8054 Base show grids value on visibility status of grids alone - (35m)
  • !8067 Restore grid alpha on load - (1m)
  • !8063 Don't display actions which require unprovided params in shortcuts list - (16m)
  • !8064 Default to not converting `ScalarUnit` limits - (7m)
  • !8052 Add frame to startup screen close button - (22m)
  • !8051 Remove references to saving window position - (6m)
  • !8017 Remove CanvasItemDrawing from Drawing object completely - (25m)
  • !7925 Add effect runner which accepts Variant dictionary arguments - (9m)
  • !7989 Fix version information when updating a document - (2m)

• Fixed 29 issues (32h 35m):

  • #6330 SVG Font Editor does not correctly layout glyphs where the EM-size is not 1000 - (51m)
  • #5832 Converting a solid color to a gradient leaves the fill-opacity attribute unexposed - (57m)
  • #6108 Layers & Objects dialog: Keyboard navigation can no longer access lock, visibility - (3h 7m)
  • #6115 1.4.3 "Open SVG Image as separate document" doesn't work if the SVG file dropped into Inkscape doesn't have a file extension - (24m)
  • #5203 Crash on attempting to duplicate layer - (1h 38m)
  • #6150 Mouse cannot select a zero-length path with Selector Tool or with Node Tool - (1h 13m)
  • #6240 1.5-dev: Document tabs can't be scrolled and don't overflow - (5h 40m)
  • #6320 rect rx percent value misinterpreted when image is present - (1h 17m)
  • #6291 Deletion triggers unexpected Layer change with XML dialog open - (49m)
  • #6260 Layer name (label) lost when converting to group - (11m)
  • #6309 1.5-dev: HSL values saved without "%", causing colours to be displayed as black in 1.4 and other applications - (1h 36m)
  • #6271 Inkscape master: Unchecking "Hide dialogs from taskbar" doesn't work - (1h 13m)
  • #5608 Inkscape master: Panel and document tabs don't apply theme tab styles - (8m)
  • #5613 INX multiline fields not resizing in Inkscape 1.5-dev - (2m)
  • #6008 Filter Primitives Drag and Drop broken - (53m)
  • #4895 New text dialog - Filtering does not work for custom collections - (36m)
  • #6224 Font size units in the new Font and Text dialog can't be set - (1h 30m)
  • #5658 Bezier Tool: Spiro mode preview broken - (1h 11m)
  • #4906 Ctrl+scroll zoom function conflict with node tool grow selection - (4m)
  • #6102 Text alignment is not persistent for new text objects - (2h 35m)
  • #4668 CLI option --export-margin stopped working - (2h 52m)
  • #6066 Embedded Scripts not shown in Document Properties on load - (24m)
  • #5319 Image elements in inx files are rendered too small in master - (1h 13m)
  • #5580 Inkscape (master): menus fail to scroll when submenus are open - (24m)
  • #6227 "Object Properties - URL" changes on the fly are not commited - (14m)
  • #5603 main window "not responding" while "manage extensions" is open - (10m)
  • #5605 Inkscape master: cannot cycle through tabs after panel tabs improvements MR - (4m)
  • #6018 Layers panel doesn't display iconography - (9m)
  • #628 Extension Manager needs to decouple available extension polling - (1h 10m)

• Other development activity (25m):

  • Additional development work.

• Other project tasks (7h 3m):

  • Triage, testing, project discussions and chats, meetings, coordination, and related meta work.

Seán de Búrca

• Total time tracked: 55h 5m

• In progress and open items (9h 40m):

  • !8083 Allow exiting a group with Ctrl+Escape or Escape-with-no-selection - (15m)
  • !8085 Let font category pill boxes flow across multiple lines - (10m)
  • #6339 Nodes do not snap to page borders with y axis up - (25m)
  • #4321 No hotkey hints in the Node Management Tool - (10m)
  • #6283 Converting contour to path changes visual image - (35m)
  • #6292 PDF form imported has all radio buttons selected (but not in the pdf) - (1h 35m) (Investigation of root cause and poppler APIs)
  • #6200 Undo/Redo gets thrown off when removing Rotate Copies LPE - (20m)
  • #6244 Locked status makes clones uneditable too - (2h 10m)
  • #6145 1.5-dev: About Screen crashes on 6th entry - (4h)

• Merged 24 merge requests (10h 15m):

  • !8084 Fix rendering of svg fonts with non-default em widths - (10m)
  • !8079 Fix opening no-extension SVG files as separate documents - (10m)
  • !8078 When changing to a gradient or similar, drop fill/stroke opacity - (15m)
  • !8075 Fix keyboard focus in the Layer & Objects dialog - (45m)
  • !8073 Fix sorting for parent/child nodes - (15m)
  • !8056 Allow selecting a zero-length path - (15m)
  • !8061 Add dropdown menu and left/right buttons for desktop tabs - (1h 15m)
  • !8066 Fix incorrect selection after deleting object with XML Editor open - (15m)
  • !8059 Make "Dialogs are hidden in taskbar" pref only visible in X11 - (40m)
  • !8055 Fix drag and drop on filter effects dialog - (15m)
  • !8057 When clearing the font collection filter, update the font list - (15m)
  • !8050 Fix scrolling on document tabs not actually switching document - (5m)
  • !8011 Add a combined font size-and-unit widget - (1h 10m)
  • !8019 Avoid some node scroll actions conflicting with Zoom - (35m)
  • !8004 Add gap to some pen and pencil points - (30m)
  • !8002 Allow scrolling document tabs with scroll wheel - (5m)
  • !8031 Support --export-margin CLI arg again - (30m)
  • !8029 Show an error when a File->Open Recent file can't be loaded - (5m)
  • !8023 Stop text alignment from resetting as you create a text element - (25m)
  • !8030 When the document is replaced, update the list of scripts - (20m)
  • !8014 Make document and dialog tabs themable by gtk themes - (20m)
  • !8032 Fix size of <image> elements in extensions - (10m)
  • !6148 Add Group Translucency indicator and display opacity override cleanup - (55m)
  • !7999 Allow cycling through panel tabs with mouse scroll again - (35m)

• Fixed 21 issues (28h 5m):

  • #6285 Snapping to page borders with y axis up is broken - (1h 10m)
  • #6306 Blend mode dropdown in the Fill and Stroke dialog requires scrolling - (25m)
  • #6328 clangtidy CI job consistently fails on forks - (55m)
  • #5018 Tooltips for selector tool grammatically incorrect because of 'dual use' of strings - (20m)
  • #6327 Incorrectly filtering out actions with no required parameter - (10m)
  • #6286 Color selector names are being rendered incorrectly - (20m)
  • #6296 PDF Generation Warns on Hyperlink Creation in Inkscape 1.4 - (1h 5m)
  • #6246 Label for "Edit | Paste…" submenu should not end with an ellipsis (…) - (40m)
  • #5760 Inkscape master: Template names and categories do not have translations applied - (1h 10m)
  • #664 View->Page Grid checkbox unchecked with grid displayed and vice versa - (2h 50m)
  • #3297 Warnings opening Keyboard shortcuts page, and minor text suggestions - (2h 20m)
  • #6162 Ctrl+Drag for constrained translation selects instead of dragging - (3h 55m)
  • #6324 1.5-dev: Grid alpha value is not restored - (15m)
  • #6287 Scale > Width regression with 1.5-dev - (2h 25m)
  • #632 Extensions Manager crashes in Inkscape 1.5-dev - (30m)
  • #5659 LPE offset orange dot became white diamond again - (15m)
  • #6212 [Dialog: Welcome] x button undiscoverable in dark mode - (2h 10m)
  • #6270 1.5-dev: Remove/Disable the option to save window positions from preferences - (35m)
  • #6137 1.5-dev: Specular filter with no explicit color results in invisible object - (4h 35m) (Investigation of underlying cause, incl. bisect)
  • #6174 Undoing spin button changes is tedious - (1h 20m)
  • #5828 Selecting mutlitple layers with SHIFT key doesn't work - (40m)

• Other project tasks (7h 5m):

  • Bug Accelerator and project meetings - 6h 35m

  • Build environment setup and maintenance - 30m

Roland Taylor

• Total time tracked: 65h 2m

• Closed/resolved/invalidated 33 issues (2h 45m):

• Moved/migrated 57 issues (4h 31m):

• Confirmed/tested/reproduced 20 issues (3h 13m):

• Reported/created 12 new issues (1h 22m):

• Identified Feature/UX requests (6 issues) (15m):

• 24 issues marked as "Needs info/needs reproducibility"/recorded for follow-up (1h 24m):

• Linked/closed 9 duplicates (20m):

• Other issue tasks (review, labelling, triage, prioritisation, research, coordination) (13h 33m):

• Non-issue tasks (37h 39m):

  • Meetings & meeting prep - 2h 50m

  • Milestone review & follow-up - 8h 11m

  • MR follow-up/testing/building - 1h 48m

  • Admin duties (spreadsheet management, correspondence, managing assignments, reporting, and other administrative tasks) - 24h 50m

The question arises naturally for anyone who chooses the standard format over the proprietary one: why do office suites that use OOXML as their native format handle ODF in ways that range from poor to appalling?

The two most obvious answers are these: vendors have neglected the format, treating it as an afterthought, or they are quietly working to discredit the very idea of transparent interoperability, through support so bad that it demonstrates the format “does not work”.

Both answers are too simplistic. The reality is that three distinct mechanisms are at work, applying to different vendors in different proportions and ultimately converging on the same outcome.

A challenge that is not a challenge

Reading and writing ODF faithfully, in isolation, is genuinely feasible: the format is completely and openly specified, and there is no equivalent of OOXML’s notorious legacy compatibility flags, which refer to undocumented behaviours of old Microsoft products that only Microsoft can reproduce.

A competent development team is able to implement ODF correctly on the basis of the ODF specification alone.

An office suite, however, does not implement a format in isolation: it has an internal, in-memory representation of the document. Loading a document is a mapping into that representation, and saving a document is a mapping out of it.

Fidelity is greatest when the internal model is congruent with the document format. LibreOffice’s model is essentially ODF, which is why, in this context, ODF is genuinely native.

When a suite’s internal model has the shape of OOXML, ODF stops being native and becomes an external import that must be converted to and from a representation built for a different format.

Take an ODF feature that OOXML lacks: the ODP field that displays the total number of slides. The instructive part is that the information itself is not missing from a PPTX file. The package enumerates every slide, and the count is available to any program that opens it. What OOXML provides no way to express is the statement that this number is the total. There is a field for the current slide number and none for the count, and Microsoft’s own guidance is to type the figure into a text box and keep it up to date by hand, which is a precise description of not having a field at all. Every published workaround is a macro or an add-in that computes the number once and writes it out as fixed text.

So when an ODP file carrying that field is opened in an OOXML-based editor, what is lost is not the data but the instruction. The number survives. The fact that it was calculated does not, and from that moment the document no longer knows how long it is.

The reverse direction fails more quietly, and therefore worse. A slide count exported from Impress to PPTX has to be written out as fixed text, so the presentation is correct on the day it is converted and wrong the first time a slide is added or removed. A number that has stopped being calculated but still looks plausible is more damaging than a visible gap, because nothing in the document signals that it needs checking.

An ODF-based editor handles the reverse case in an entirely different way. When it encounters a feature present in one format and absent from the other, it sets the data aside rather than discarding it, and restores it when the document returns to OOXML. In LibreOffice this mechanism has a name, the grab bag, and it is a documented part of the import filters rather than an incidental behaviour.

The difference does not lie in the quality of the import filter, but in the fact that the architecture was designed to hold the meaning of the other format.

This matters, because it means that poor ODF support in OOXML-based suites is largely overdetermined before the question of motive even arises. The difficulty is not absolute, but relative to the architecture the vendor has chosen.

Three mechanisms

First: the bet on a reference format. Some suites do not consider ODF at all, because they have built their value proposition on the other format.

OnlyOffice is the clearest case, because it was built around OOXML and converts every other format into that model, so ODF is a second-class import and export format by design.

WPS Office is software created to open docx, xlsx and pptx files faithfully. Its ODF functionality derives from the add-in of Microsoft’s own OpenXML project and was integrated into the application only in May 2022, as a conversion layer written for ODF 1.1, which is to say for the 2007 revision of the standard. Fifteen years of delay were built in on the day of release.

Google Workspace is a variant of the same logic rather than an exception to it. Its internal model is neither ODF nor OOXML but a proprietary web representation, and both formats reach it through a conversion layer. For a public administration the consequence is identical: the open standard is an export target, not the substrate the software thinks in.

For these vendors, ODF was never part of the strategy. Their proposition is to open Microsoft documents in something other than Microsoft Office, and to make them look right, so poor ODF support is the direct consequence of the strategy.

Second: deliberate underinvestment. This is probably a cause that cuts across the whole office suite sector. Although ODF is easier and cheaper to implement correctly, the process still involves development, quality assurance and maintenance costs and timelines, in order to keep pace with a continuously evolving standard.

If a vendor’s users mostly exchange docx files, the marginal commercial value of excellent ODF support is close to zero, so ODF is first implemented at the minimum level and then quietly left to rot.

The perception that ODF support does not matter is itself a consequence of a single company’s market dominance, and its effect is twofold. Lock-in becomes a software feature that the market regards as entirely normal, and ODF acquires a reputation for fragility that no deliberate campaign was required to produce.

Third: deliberate disqualification. This mechanism is real, and it concerns Microsoft itself, with Service Pack 2 for Office 2007. The ODF support it shipped failed in two opposite directions at once.

When reading an ODF spreadsheet produced by another application, Excel silently stripped out the formulas and kept only the last value each cell had held, reducing the document, in Rob Weir’s assessment at the time, to a mere “table of numbers” with the calculation logic gone. When writing, Excel placed formulas in an Excel namespace that was neither the one used by OpenOffice and the other ODF applications nor the OOXML one. Applications that checked the namespace rejected the document outright; those that did not check it displayed a corrupted file showing neither the formula nor the value correctly.

This is a textbook mechanism for discrediting interoperability: meeting a format requirement with an implementation that conforms only on paper and produces visibly broken files, demonstrating to every observer that ODF does not actually work.

At the time, Microsoft argued that the ODF standard did not define spreadsheet formulas, which arrived only with ODF 1.2, and that there was therefore no reference to follow. The argument does not survive Microsoft’s own reply. Responding publicly to Weir, Microsoft’s evangelist Doug Mahugh set the two behaviours side by side: faced with the same unrecognised formula syntax, IBM Lotus Symphony preserved the formula markup, while Excel preserved the cached values. Neither application had a specification to follow. Only one had an architecture with somewhere to put what it did not understand.

It is worth noting what Excel kept. Not the formula, but its last result, which is the same reduction we saw with the slide count, in a different application. A model shaped by OOXML retains the value and loses the computation that produced it, and a document reduced to its last results is a document that has stopped being able to correct itself.

That episode is seventeen years old, and it would be easy to set it aside as history. Microsoft Office today declares support for ODF 1.4. But what improved is the nominal conformance, not the architecture. The internal model is still OOXML, and every ODF document that passes through it is still a translation.

The synthesis

Poor ODF support is not a technical verdict on the format, but the visible shape of a market organised around the dominance of a single vendor, and that shape did not come about by chance.

For European public administrations, this redefines the practical question, because the interoperability problems they encounter when they try to migrate to the open standard ODF are not caused by ODF, which is entirely ready. They are evidence that most of the available tools were designed to be native to somebody else’s format, and that the one vendor with the power to change this situation has repeatedly chosen not to.

The precarious state of ODF support in the market is not a reason to hesitate over adopting the standard, but the strongest possible reason to mandate it, and to mandate it precisely.

The question that protects a public body’s documents, and its sovereignty over them, is not whether ODF is supported, but whether that support is native, that is, whether the software’s own internal model is the open standard, or the standard is merely a foreign element inside an engine built for something else.

The document format is the substrate of administrative continuity and public memory. Choosing tools for which the open standard is native is not a preference between equivalent options, but the difference between owning your documents and renting access to them from whoever controls the format in which they are actually written.

On 13 October 2026, Microsoft ends support for Office 2021. No more security updates, no more fixes, no more assurances. The software will still launch. It will still open your files. But from that date it becomes a liability rather than an asset — and the only sanctioned path forward runs through a subscription.

This is not a bug in the model. It is the model.

Support that does not expire

LibreOffice has no end-of-support date, because there is no vendor with the power to declare one. The code is public. The development is community-driven and foundation-governed. When a release cycle closes, the next one is already available, free, to everyone — not to those who renewed.

The distinction matters more than it appears. Microsoft’s lifecycle policy is a commercial instrument: the date is chosen, not discovered. It marks the moment when continuing to use software you paid for becomes unwise, and it exists to convert perpetual licences into recurring revenue. LibreOffice cannot issue such a date because no one holds the authority to issue it.

Ownership of documents, not just access to them

A support deadline is the visible layer. Underneath it sits something more consequential: the format your documents are written in.

LibreOffice uses the OpenDocument Format (ODF), an ISO standard maintained by OASIS and implemented by multiple independent applications. The specification is public, complete, and readable. Anyone can write software that opens an ODF file correctly — today, or in forty years, using tools that have not yet been written.

OOXML, despite carrying an ISO number, is not comparable in practice. The standard that was approved and the format that Microsoft Office actually writes have diverged. Independent implementations remain approximations. This is why round-tripping a complex document between suites degrades it, and why the degradation is always the fault of the software that did not write the format in the first place.

The consequence is simple. If your archive is in OOXML, your ability to read it depends on a commercial relationship with a single company continuing indefinitely. If your archive is in ODF, it does not.

Documents are software

A modern document is not a page. It is a structured artefact: markup, style definitions, embedded objects, references to fonts, scripts, conditional logic, external data. It is executed by an application in exactly the way a program is executed by a runtime.

We accepted decades ago that critical software should not be built on formats and interfaces controlled by a single vendor. Documents have escaped that scrutiny only because they look like paper. They are not paper. The same argument that makes open standards essential for software makes them essential for the files that record contracts, medical histories, legislation, research, and institutional memory.

Costs that stop compounding

The licence saving is real but it is the least interesting part of the calculation. What changes structurally is the removal of a recurring, unilaterally repriceable line item from the budget — one that has risen repeatedly and will rise again, because the customer has no alternative to negotiate with.

Migration has costs. Training, template conversion, macro rewrites, integration work. These are one-off and quantifiable. Subscription is perpetual and is not.

Independence from the deployment model

Support deadlines are increasingly used to move users from local installation to cloud service. That transition is not neutral. It changes where documents reside, which jurisdiction governs them, who can be compelled to disclose them, and whether work is possible when connectivity is not.

LibreOffice runs locally, on Windows, macOS, GNU/Linux, and in a browser via LibreOffice Technology-based online solutions — as a choice, not as a condition of receiving updates.

What October 2026 actually asks

The deadline poses a question that the deadline itself cannot answer: should the readability of your organisation’s documents in 2046 depend on decisions made by a company in 2026?

If the answer is no, the migration is not a reaction to an end-of-support notice. It is the correction of a dependency that should never have been accepted.

Support ends on a date someone else chooses. Ownership does not end at all.

LibreOffice is developed by The Document Foundation, a non-profit organisation based in Berlin, and is available free of charge at libreoffice.org. The Document Foundation publishes a LibreOffice Migration Protocol for organisations planning a structured transition.

Image by Alexa from Pixabay

Digital sovereignty is not about owning everything, it is about ensuring that nothing essential can be taken away.

That single line settles more arguments than it first appears to, because it disqualifies the two positions that dominate the debate. One side imagines sovereignty as control. The other imagines it as choice. Both are talking about something real, and both have mistaken a part for the whole.

The control camp misreads the goal

The instinct to equate sovereignty with control is understandable. Sovereignty, in its older political sense, was control: borders, currency, the monopoly on force. So when the word migrates into the digital domain, people reach for the same picture: own the servers, hold the data, build the stack, depend on no one.

The trouble is that this picture is both impossible and beside the point.

It is impossible because no institution, and certainly no continent, is going to reimplement the entire computing stack from silicon upward. The dream of total self-sufficiency is not sovereignty, it is autarky, and autarky has failed everywhere it has been seriously attempted.

A Europe that tried to own everything would spend a generation rebuilding inferior versions of things that already work, and would be no freer at the end of it.

But the deeper problem is that control is the wrong target even when it is achievable. An institution can own the building and still be a tenant of the lock.

A public administration can run its own data centre, on its own soil, under its own staff, and still find that every document it produces is hostage to a format only one vendor fully understands. The hardware is sovereign. The institution is not. Control over the container tells you nothing about who controls the contents.

This is why the control framing quietly concedes the argument before it begins. It accepts that sovereignty is about what you hold, and so it can always be answered with “but you cannot hold all of it”, which is true, and which is why the framing loses. Sovereignty was never about the holding.

The choice camp misreads the threat

The opposite error is more fashionable and, for that reason, more dangerous.

Here the argument runs: sovereignty simply means freedom to choose. A sovereign buyer surveys the market and selects the best tool for the job, and if the best tool happens to be proprietary, so be it. To exclude proprietary software on principle, this camp says, is itself a kind of unfreedom, an ideology dressed up as independence. Real sovereignty, they insist, is vendor-neutral.

It is a seductive argument because it borrows the language of liberty. But it confuses a choice made today with a choice that remains available tomorrow, and that confusion is the whole game.

Consider what “choosing” a proprietary, closed-format platform actually buys you.

On the day of purchase, you have exercised your freedom: you compared options and picked one. But every document, every workflow, every trained habit that follows accumulates inside a system that only its owner can reproduce.

Five years later, when the licence terms change, or the price rises sharply, or a feature you depend on is discontinued, or the company is acquired and the product withdrawn, you discover that your freedom to choose has quietly expired. The market has not removed your options on paper. It has removed the ground beneath all but one of them.

This is the trap the choice framing cannot see, because it measures freedom at the moment of decision and never at the moment of exit. A choice you cannot reverse is not really a choice, it is a commitment wearing a choice’s clothes. Sovereignty has always been about the capacity to reverse, to leave, to change one’s mind, to refuse a deal that has turned bad. A buyer who cannot say no later was never sovereign to begin with.

What is actually essential

So if sovereignty is neither owning everything nor choosing freely among everything, what is left?

What is left is the thing the opening sentence points to: ensuring that nothing essential can be taken away.

The word doing the work there is essential. An institution does not need to own the cloud, it needs to be sure that if a provider vanishes tomorrow, its data does not vanish with it.

It does not need to forbid proprietary tools it needs to be sure that the things it commits to those tools – its records, its contracts, its citizens’ files – remain readable, movable, and re-creatable by someone other than the vendor who sold it the tool.

Sovereignty is not a wall around one’s possessions. It is a guarantee about one’s exits.

This is why open standards, and not ownership, are the real substance of digital sovereignty, and why open standards alone are not even enough.

A format must do two things. It must persist: it must be readable in ten years without asking permission. And it must be reimplementable: anyone, in principle, must be able to build a tool that reads and writes it, without reverse-engineering, without a licence, without the original vendor’s blessing.

Persistence without reimplementability is a museum exhibit: you can look at your data, but only one company can do anything with it. Reimplementability is what turns a surviving file into a living, portable, sovereign asset.

The shape of the mistake

The control camp and the choice camp look like opposites. One wants to build a fortress, the other wants to shop in an open market. But they make the same underlying error: they locate sovereignty in the present tense: in what you hold now, or what you select now.

Sovereignty lives in the future tense. It is the answer to a question you have not yet had to ask: when this provider fails me, what survives? If the honest answer is “everything essential, and I can take it elsewhere,” you are sovereign, whatever brands happen to sit on your desks today.

If the honest answer is “that depends on whether they let me,” then you are not sovereign, no matter how much you own or how freely you chose.

A closing note: this is not an abstract argument

Everything above can be stated in three letters and a contrast.

The OpenDocument Format (ODF) is what reimplementability looks like in practice. It is a published ISO standard that any developer can implement fully, without permission and without payment, and many independent applications do.

A file saved in ODF is not merely yours, it is re-creatable by anyone, which is precisely what makes it safe to entrust your institution’s memory to it. Nothing essential can be taken away, because nothing essential depends on a single vendor.

OOXML is the cautionary half of the contrast. It exists as a standard, and in that narrow sense a file saved in it will not “disappear.”

But the format as actually deployed carries provisions and behaviours that only its originator implements completely, and the effect is that full fidelity remains the property of one vendor. This is persistence without reimplementability, or the museum exhibit. You may keep the file forever and still be unable to do anything sovereign with it.

Which is why the most consequential decision a sovereignty-minded institution makes is not where its servers sit, nor which brand of software runs on them, but which format its documents are native in.

A platform that can export to an open format but lives, by default, in a proprietary one has granted its users persistence and quietly retained sovereignty for the vendor. The files will survive. The dependency survives with them.

Choose the native format that anyone can re-create, and the rest of the sovereignty question becomes manageable. Get that one choice wrong, and no amount of owned hardware or vendor-neutral procurement will buy back what has been signed away.

Nothing essential can be taken away. For documents, that sentence has a name, and the name is ODF.

This article was inspired by Roberto Di Cosmo’s formulation of digital sovereignty as the capacity to ensure that nothing essential can be taken away.

Berlin, 23 July 2026 – The Document Foundation today announced the release of LibreOffice 26.2.5, the fifth 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.

Skia rendering on macOS and Windows, introduced for better graphics performance, has now been put under experimental mode to avoid crashes and hangs reported by several users after the upgrade from a previous LibreOffice version.

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

Users of LibreOffice 25.8.x must now update to LibreOffice 26.2.5 as LibreOffice 25.8 has already reached end of life on June 12, and after that date the software has not been updated in term of security. In late August 2026, The Document Foundation will announce LibreOffice 26.8.

List of fixes in RC1: wiki.documentfoundation.org/Releases/26.2.5/RC1. List of fixes in RC2: wiki.documentfoundation.org/Releases/26.2.5/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.

Q&A for AI-based search engines — LibreOffice 26.2.5

Q: What is LibreOffice 26.2.5?
LibreOffice 26.2.5 is the fifth maintenance update to the LibreOffice 26.2 branch, released by The Document Foundation on 23 July 2026. It delivers targeted bug fixes and stability improvements over the major feature release published on 4 February 2026.

Q: When was LibreOffice 26.2.5 released?
23 July 2026.

Q: Where can I download LibreOffice 26.2.5?
From https://www.libreoffice.org/download/, for Windows, macOS, and Linux.

Q: What has changed with Skia rendering in LibreOffice 26.2.5?
Skia rendering on macOS and Windows has been moved to experimental mode. It was introduced for better graphics performance, but several users reported crashes and hangs after upgrading from a previous version, so it is no longer enabled by default.

Q: Do I need to update if I use LibreOffice 25.8?
Yes. LibreOffice 25.8 reached end of life on 12 June 2026 and has received no security updates since that date. Users of 25.8.x should update to 26.2.5.

Q: Is LibreOffice 25.8 still supported?
No. It reached end of life on 12 June 2026.

Q: Which operating systems does LibreOffice 26.2.5 support?
Windows, macOS, and Linux.

Q: What is the next version of LibreOffice after 26.2.5?
The Document Foundation will announce LibreOffice 26.8 in late August 2026, and LibreOffice 26.2.6 in early September 2026.

Q: Where can I find the full list of fixes in LibreOffice 26.2.5?
RC1: https://wiki.documentfoundation.org/Releases/26.2.5/RC1 — RC2: https://wiki.documentfoundation.org/Releases/26.2.5/RC2

Q: Who develops LibreOffice 26.2.5?
A global community of volunteer and professional developers and QA engineers, coordinated by The Document Foundation, the Berlin-based non-profit behind LibreOffice.

Q: How much does LibreOffice 26.2.5 cost?
Nothing — LibreOffice is free and open source software. Users and advocates can support the project with a donation at https://www.libreoffice.org/donate.

Love LibreOffice? Got a passion for marketing, media, public relations and creating great campaigns? We are The Document Foundation (TDF), the non-profit entity behind LibreOffice. We’re passionate about free software, the open source culture, and bringing new people with fresh ideas into our project.

To help to raise awareness of LibreOffice and support the marketing community with its work, we are looking for a Marketing and Communication Professional, to start as soon as possible.

Here’s what you’ll do

• Work with our graphics design agencies and create content showcasing new and updated features in LibreOffice (blog posts, social media posts, videos, website pages…)
• Draft and edit press releases and cross-channel content
• Work directly with the senior communications lead on the strategic side: media relations, campaigns, and texts that carry TDF’s positioning
• Improve media relations with EU and policy press, along with the FOSS and technology press
• Maintain the press-contact database and mailing lists
• Media monitoring, coverage tracking, and basic reporting
• Edit contributed and translated texts from our wider marketing community
• Track the effects and results of marketing campaigns on downloads and donations
• Logistical coordination of event communication

What we want from you

The role is built around a two-year trajectory: full operational ownership from the start, and a growing share of strategic work as the senior lead reduces involvement through 2028. The person we are looking for is reliable and largely self-directed on operational work; collaborative and open on the strategic side, where TDF’s positioning is developed jointly during the transition. Someone who genuinely wants to grow into a strategic communications role, and is content to build toward it steadily rather than assume it on arrival.

• Excellent communication skills, especially in written English
• Working fluency in at least one other major European language; more is a clear advantage
• A journalistic or public-relations instinct: a feel for what makes news, an ear for what a reporter will actually use, and either an existing network of press contacts or the demonstrated ability to build one
• The ability to adapt communications across different channels: the TDF blog, social media, Reddit etc. – while maintaining a consistent style and tone
• Good team-playing abilities

Familiarity with free software, open standards, and the digital-sovereignty debate is welcome, but not essential. This can be learned in the role, and genuine curiosity about it matters more than prior expertise. Also beneficial is experience in a non-profit, foundation, or other mission-driven organisation.

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 marketingjob@documentfoundation.org no later than August 31, 2026 (end of day, Berlin time). If you haven’t received feedback by September 30, 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.

Members – more formally known as the “Board of Trustees” – are a crucial part of The Document Foundation, the non-profit entity behind LibreOffice. They are people from across the globe who contribute time, effort and skills, whether on a voluntary or paid basis. Members can vote for the Board of Directors (BoD) and the Membership Committee (MC), and also nominate themselves for a position in the BoD and the MC. Oh, and they get @libreoffice.org email addresses as well!

Let’s welcome our new members:

• Aleksi Kallio
• Brandon Evangelista
• Damiano Perri
• Karl-Heinz Gruner
• Mihai Alexandru Vasiliu
• Neil Roberts
• Robert Pearson
• Rohan Singh

Glad to have you on board, and thanks for being in the project Everyone who contributes in the LibreOffice and Document Liberation projects can apply to be a member too. Join us!

We are releasing the quarterly updated State of the Project Slide Deck, based on data from July 1st, 2025, to June 30, 2026, extracted from the LibreOffice dashboard and the Matomo repository.

During the 12 months 309 developers worked on the source code, adding 11.464 new commits (Git): 238 volunteer developers (77%) provided 2.028 commits (18%); 11 developers from The Document Foundation (4%) provided 4.501 commits (39%), and 60 developers from 8 ecosystem companies (19%) provided 4.935 commits (47%).

The slide deck is also a tribute to the 20 top Git committers, the 20 top Gerrit committers, the top 20 Bugzilla issue submitters, the top 20 people answering on Discourse, and the top 20 translator on Weblate. To all of them and to all the other contributors, thank you.

Looking at donations and downloads, the trend during the first six months of 2026 confirms the positive trend started in early 2025. Donation figures refer to the number of transactions and not to their amount, which is available via the ledgers published on The Document Foundation website.

You are invited to look at the slides, and download the file to compare it with the previous slide deck published in January and April. The next slide deck which will be available in October and will cover the 12 months between October 1st, 2025, and September 30, 2026.

We have started to publish these slide decks in January 2026, to provide a transparent overview about the progress of the project through some of the most significant measures of development, downloads and donations data collected by the marketing team at TDF.

Since the release of GIMP 3.2.4, we’ve been hard at work behind the scenes. We’ve been making fixes that will be included in the upcoming 3.2.6 stable release and adding tons of new features for the first 3.4 development version.

In addition, we’ve been mentoring our four Google Summer of Code (GSoC) students as they’ve been working on their projects. Since we just completed their midpoint evaluation, we wanted to share their progress with you all!

In alphabetical order:

Akascape¶

Project Description

Akascape started off their early work for GSoC by creating a new Vibrance filter in GEGL. This filter combines the existing Hue-Chroma and Saturation filters to more selectively adjust the less saturated sections of an image without increasing others. It was released in GEGL 0.4.68, so you can use it right now in GIMP!

Their main focus has been on improving the user experience with the Keyboard Shortcuts dialog. They plan to both improve usability while also adding new features.

Akascape’s in-progress work already includes several big improvements such as a category list to quickly jump to relevant shortcuts, the ability to import and export shortcut “profiles”, and efforts to make the dialog more friendly for a future GTK4 port.

In addition, Akascape did some early work on adding more adjustment layers to our PSD import plug-in, building off in-progress work by several contributors. His work would allow for importing Vibrance, Black & White, Photo Filter, and Exposure PSD adjustment layers.

Blezecon¶

Project Description

Blezecon has taken on the task of building the online infrastructure for a GIMP Extensions platform. Originally planned as part of GIMP 3.0, the Extensions platform would allow users to download third-party themes, brushes, plug-ins, and more via a package manager directly in GIMP. The local infrastructure has been in place for several years - this GSoC project is about developing the online submission process.

Blezecon has been working in the Extension repository and making great progress. His initial work involved cleaning up and correcting issues with the initial YAML script.

He then created a comment-based approval system in the repo. This will allow community moderators to easily inspect and approve new extensions through the same interface they use for responding to issue reports and review merge requests. Blezecon next developed a scheduler script that will monitor pending extensions, and once they have received the required approvals, automatically merge them into the Extensions repository for user access.

While infrastructure work is often not as visible to end users, Blezecon’s GSoC project is an essential effort to getting the Extensions repository up and running for future releases of GIMP!

v4vansh¶

Project Description

v4vansh did some early bugfixes and improvements in GIMP beforehand. He fixed a problem where the thumbnail wouldn’t update after changing image modes, and he corrected missing information in our manual page generation.

Since the start of GSoC, he has been focused on improving text handling in GIMP. His current big project is grouping fonts by family in the text widgets. In addition to better organization (especially with the infamous Noto fonts which have hundres of variants), this patch significantly reduces lag on systems with large numbers of fonts, as v4vansh’s mentor Liam can attest. This feature is in final testing, and we hope it will be merged into the main codebase soon!

v4vansh has also begun experimenting with adding support for OpenType variable fonts. This would allow for much more sophisticated font and text work in GIMP. The initial work involves exploring both the functionality and the user interface to interact with it, and both will develop further as he continues to work with OpenType fonts.

Waris Maqbool¶

Project Description

Before GSoC began, Waris contributed some early work to GIMP. He updated our OpenEXR import code to load YUV images in color instead of in grayscale. The main focus of his project though has been with GEGL, our color processing engine.

His first project was implementing a GEGL version of the Sharpen filter. Sharpen is a simpler version of the Unsharpen Mask filter, a popular method of correcting blurry images. It was unfortunately removed from GIMP 3.0 due to it not being maintained and only working on 8 bit images. Waris has created a GEGL filter of Sharpen by doing comparisons with the 2.10 version. The recreated Sharpen filter will be non-destructive and will have an on-canvas preview, both improvements over the original.

You can see the in-progress merge request for comparison. We’re doing some final reviews for optimization, but we expect it to be ready for a future release of GEGL and GIMP.

Waris has also begun working on a new Inner Glow filter for our PSD support improvement project. While GEGL already has an inner glow feature, it was not designed to be compatible with how it looks in Photoshop. As part of his work, he is also creating a generic curve editing widget to use for editing the PSD Inner Glow’s settings.

We unfortunately had more great GSoC applicants than we were awarded available spaces. One student in particular continued contributing, so we’d like to highlight their work as well.

Harsh Verma¶

Harsh has been focusing on several different areas of GIMP. His initial proposal involved improving our unit testing suite. He is currently working to implement automated UI testing for GIMP. This is a challenging task, as interacting with the UI varies across platforms. He’s already developed several tests that work on Wayland, which you can see at his in-progress merge request.

He’s also improved our contributor infrastructure that integrating CI-Fairy into our pipeline. This feature checks to make sure contributor commits follow the proper format before merging, which makes our commit history easier to read and understand.

Harsh has also been working on more user-visible changes. He recently took on a user request to add more version information to our About dialog. This follows standard practice with other software, and makes it easier for users to find information that helps us troubleshoot problems. In addition, there’s a handy Copy feature to easily grab the information for sharing. The code and UI have gone through several revisions based on developer and designer feedback, and it will likely be merged soon!

We’ve very proud of our student’s contributions so far, both in code and in community! We’re looking forward to you all getting the chance to try out their work in future development releases of GIMP, which we hope to have more information to share soon.

In the previous article, we explored the importance of standards: how the unspoken agreements governing electrical sockets, paper sizes and file formats form the foundations of a world in which choices remain open and power is not concentrated in the hands of a single player. We concluded with a question: if open standards are so beneficial, why aren’t they universally adopted?

The answer, in the case of document formats, lies in a single page produced by Microsoft Office. Getting rid of it is harder than it seems.

A file is never just a file

When you save a document on your computer, you are choosing a format — that is, the language in which your document is written in a way that the computer can understand: the set of rules that determines how words, tables, images and formatting instructions are stored and, consequently, how they can be retrieved, shared and read in the future.

For decades, the dominant format for office documents has been that produced by Microsoft Office. Initially as binary files with extensions such as DOC and XLS, then as XML-based formats introduced with Office 2007: DOCX, XLSX and PPTX. These formats are used by hundreds of millions of people. They are the lingua franca of offices, schools, public administrations and courts around the world.

Furthermore, in significant and decisive ways, they are proprietary — meaning they belong to Microsoft, are controlled by Microsoft and serve Microsoft’s interests in ways that may not align with the interests of users.

Understanding how all this works — and why it matters far beyond mere matters of software preference — is the aim of this article.

The architecture of dependency

Proprietary formats create dependency through a mechanism that is simple in principle and extraordinarily effective in practice: they make the data contained in a document inseparable from the software used to create it.

This is not a law of physics, but a design choice.

An open format — a format whose specifications are published, freely available and implementable by any software without restrictions — stores information in such a way that any compliant application can read, write and reproduce it faithfully.

A proprietary format, by contrast, may contain undocumented features, private extensions or behaviours that only the original software implements correctly. The document may be opened by other applications, but it cannot always be reproduced faithfully.

The practical consequence is familiar to anyone who has tried to open a Microsoft Office document in another application: the formatting becomes distorted, bullet points shift, tables lose their proportions, and headings appear different.

A presentation that looked polished in PowerPoint seems slapdash in a different viewer: the content is all there, whilst the document, strictly speaking, is not.

This is “lock-in”: it is not a padlock, it is not a technical ban, it is not a contractual restriction, but a silent and persistent friction that makes any work outside the Microsoft ecosystem seem slightly off, slightly unreliable, slightly unprofessional — and ensures that the easiest route is to return to the tools that produce documents with the expected appearance.

The standard that isn’t a standard

Microsoft formats have been submitted to international standardisation bodies and approved. This has been used, time and again, to argue that concerns about “lock-in” are exaggerated — that OOXML, the Office Open XML format, is as open a standard as any other, and that the playing field is level.

The reality is considerably more complicated.

The standardisation of OOXML was one of the most contested processes in the history of ISO: national standardisation bodies reported procedural irregularities, and the votes were contested. The process has left an indelible mark on the credibility of international standards, and has resulted in a specification of extraordinary length and complexity — running to thousands of pages — which did not describe a format designed for interoperability, but rather the existing behaviour of Microsoft Office, including legacy behaviours, undocumented features and implementation details specific to Microsoft’s source code.

No other software could fully implement the format, yet it was required to do so out of respect for its users, who needed to exchange documents with Microsoft users.

The version of OOXML that was standardised — OOXML Transitional — initially co-existed with a stricter variant, OOXML Strict, which eliminated most of the problematic legacy elements, but not all. Moreover, Microsoft Office has always used OOXML Transitional as the default format, and has relegated OOXML Strict to the bottom of the options (to prevent it from being used).

The practical effect is that the format used daily by hundreds of millions of people is the one that only Microsoft’s own software implements correctly, whilst the cleaner variant — which other software could actually support — is not used, and has now even disappeared from some versions.

A standard that only one implementation fully supports is, from a functional point of view, a proprietary format with a standardisation certificate.

Lock-in, from the individual to the institution

Dependence on document formats is the main mechanism of lock-in, but it is not the only one. We discussed the layering of dependencies at length in a previous article, so we will not revisit the subject here. Levels of dependence vary depending on the importance of the documents involved and the size of the organisation producing them.

For an individual user, a document with altered layout is simply an inconvenience. For a law firm, it may mean that a contract submitted to court does not match the version in the client’s file. For a hospital, it may mean that a clinical form is printed incorrectly. For a government department, it may mean that a document appears differently depending on the software used: a silent and unintended form of unequal access to public information.

At the level of public administration, this dependency takes on a dimension that goes beyond operational efficiency. A government that archives official documents in a format controlled by a private company has, strictly speaking, delegated the custody of its institutional memory to that company. Today, documents are readable because Microsoft continues to support the format, but whether they can be read in twenty years’ time will depend on the company’s decisions, for reasons that have nothing to do with the public interest.

This is not a hypothetical risk: formats are phased out, software versions change, and features present in one version of Office may behave differently — or not work at all — in another.

The history of digital documents is littered with files that cannot be opened because the software with which they were created no longer exists or no longer works on modern systems. Proprietary formats accelerate this risk by concentrating the knowledge needed to interpret them within an organisation whose commercial interests may, at any time, diverge from the interests of those who depend on access to their own documents.

What true sovereignty requires

A truly independent document — one that displays identically on any system, in any country, for any user, regardless of the software used — requires informed choices at every stage of its creation.

At the format level, it requires an open standard such as the Open Document Format (ODF), whose specifications are published, freely implementable and managed by a body independent of any single vendor. ODF is an international ISO standard that has undergone a legitimate standardisation process and whose specifications can be fully implemented by any software that chooses to do so. LibreOffice, the leading open-source office suite, uses ODF natively. The same should apply to any other self-respecting open-source office application.

In terms of fonts, it requires open fonts, the designs of which are published under licences that allow any software to implement them and any user to install them without cost or restrictions. Open font repositories offer a wide range of high-quality options that have no proprietary dependencies.

In terms of templates and workflows, it requires institutional policies that specify open formats and open fonts as the default for all official documents — not as an aesthetic preference, but as a governance requirement, in the same way that a public administration might specify accessibility standards or data protection requirements.

At the archiving level, this requires a commitment to formats specifically designed for long-term preservation — such as PDF/A for documents intended for permanent archiving — whose specifications are public and whose readability does not depend on the commercial decisions of a single supplier.

None of this is technically complex, but it requires a conscious decision by someone with the authority to do so.

A document is never innocent

A document is an argument made visible. It is also, always, a set of dependencies made invisible.

When an institution sends a letter formatted with a proprietary font, embedded in a proprietary format, produced by proprietary software, it is not communicating information but perpetuating a dependency — in workflows, in the expectations of correspondents, in staff memory and in the implicit message to recipients — that this is precisely how documents work, that there are no alternatives, that the infrastructure of written communication belongs to someone else, and that it has always been this way.

Digital sovereignty begins with the recognition that this is a choice: the file format is a choice, the font on the page is a choice, and the software is a choice. And choices, unlike facts, can vary.

That document, which continues to be regarded as a “seemingly” innocent piece of paper, is in reality no longer a piece of paper — and hasn’t been for some time — but an executable file that is interpreted by software, and as such is no longer innocent but, in many cases, the insidious tool of lock-in.

Microsoft Office Icons: Ms Office Icon Vectors by Vecteezy
Protest against OOXML: Techrights
Innocent piece of paper: The Mazloom Law Firm, LLC

This is part of the Annual Report 2025 from The Document Foundation, the non-profit that coordinates the LibreOffice project and community.

TDF exists because of a large, dynamic global community — volunteers, ecosystem companies and committed end users who support our work with donations of both time and money. The 2025 accounts tell a clear story: a foundation that grew significantly, while keeping its finances transparent and its spending tied to its mission.

A year of strong growth in income

Total income for 2025 reached € 2,175,997, a substantial increase on the € 1,387,589 recorded in 2024. The growth came from three distinct sources, and it is worth being precise about each.

The largest share, € 1,976,825, came from donations — overwhelmingly from individual users and small businesses, mostly in Europe. This was the fifth consecutive year in which donations exceeded one million euro, and the highest figure to date. Part of this increase was organic, reflecting the continued strength of LibreOffice downloads. A further part can be attributed to a concrete change: in mid-2025 we introduced a new in-product update notification on Windows, which periodically — after every major release and selected minor ones — informs users that an update is available, presents the new features, and invites them to support the project with a donation. The effect was immediately visible as a step-up in donations from the moment it was deployed, and it is keeping donations at a higher level into 2026. We mention this openly, because transparency about *why* the numbers move is as important as the numbers themselves.

The second source was income from the sale of LibreOffice through online stores, sponsoring and related commercial activity, which together generated € 168,975. The Apple App Store (€ 118,942) and the Microsoft Store (€ 35,393) accounted for most of this. The third source was € 30,197 in income from securities held under the foundation’s asset management.

How the money was spent

Total expenditure for 2025 was € 1,457,343. The breakdown by category shows where donor money goes.

• Staff and operations remained by far the largest commitment, at € 1,091,032. This covers salaries (€ 406,736), statutory social security contributions (€ 93,244) and freelancers (€ 591,052) — the people who keep infrastructure, communication, administration and project coordination running, in order to share knowledge, support the community in its activities, and enable contributors to do their work.
• Tenders. As in 2024, no development tenders were funded in 2025. Tenders related to LibreOffice development remain on hold, and will be resumed based on the development strategy currently under discussion according to the new Procurement Policy.
• Events and community support amounted to roughly € 87,000, including the LibreOffice Conference (developer conference, € 51,184), community projects (€ 15,014) and student scholarships (€ 17,368), together with marketing initiatives. These funds support the events and local activities that hold the global community together, and help us to share knowledge around the world.
• Infrastructure and hosting came to € 51,420, covering the hosting, virtual machines, services and domains that underpin the project’s technical independence — a foundational asset we continue to prioritise.
• Legal and administrative expenses totalled roughly € 92,000, including accounting and the preparation of financial statements (€ 34,164), legal advice and counselling (€ 36,597 across project and general legal work), and insurances (€ 4,626).

Cost of fundraising. Receiving donations is not free. In 2025, payment-processing and banking fees came to roughly € 98,000 — Stripe fees of € 46,446 and bank transfer and money-transfer fees of € 51,190. These are simply the cost of doing business: they scale with the volume of donations we receive. It is worth adding that these figures do not capture the full picture, because PayPal’s currency-conversion costs are embedded in the transactions and not separately visible — though they are comparable in scale to the Stripe fees. We report this plainly so that no reader underestimates what it costs to collect the donations that fund our work.

Results and transparency

After expenses, the charitable entity closed the year with a result of € 554,476, asset management contributed € 21,263, and the commercial business operations returned a profit of € 142,916.

Transparency remains one of TDF’s defining characteristics — towards our donors, contributors, community and users. Our accounting is handled by a professional accountant, and our complete ledgers, listing all income and spending broken down by project, are published on our public wiki at https://wiki.documentfoundation.org/TDF/Ledgers, with only a few items obfuscated for privacy. As in previous years, and given the scale the foundation has reached, our books have been audited, and the Board continues to work with the authorities in Berlin to implement the improvements the audit recommended.

To everyone who contributed time, skills, resources and money in 2025: thank you. The foundation’s strength is your achievement.

Note: The expense categories above are indicative groupings drawn from the foundation’s accounts. They exclude VAT flows and certain material costs that the ledger handles separately, so the categories are not intended to reconcile arithmetically with the per-sphere annual results. The authoritative, fully itemised figures are published in the ledgers.

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

GIMP is Free and Libre Open Source Software, but none of it is possible without the people who create with and contribute to it. Our project maintainer Jehan wanted to interview the volunteers who make GIMP what it is, and share their stories so you can learn more about the awesome people behind GIMP!

Early interviews from co-maintainer Michael Natterer and Michael Schumacher were published shortly after the first Wilber Week. The remaining interviews from this event, about Simon Budig and Øyvind Kolås were published years later as a revival of the series. While these interviews are a bit old and reference outdated versions and features of GIMP, we believe they still have value and show the evolution of our community.

This next interview is the first one recorded at the 2017 Libre Graphics Meeting in Rio de Janeiro, Brazil. The subject is Nara Oliveira, co-founder of Estudio Gunga. She is a Brazilian artist and advocate who uses free software exclusively to develop professional works in many fields, including design, illustration, and animation.

This interview took place over April 21 - 23, 2017. In addition to Jehan and Nara, Simon Budig, and Aryeom Han were also involved and asked questions.

Jehan: Hello Nara. Can you introduce yourself to the people?

Nara: My name is Nara Oliveira. I am a Brazilian designer. I am from Brasília, the capital. The city name is Taguatinga. I study design and today I work with free software. I have my own company with some partners and we work in audio, video, design, and animation.

Jehan: What is the name of your company?

Nara: Gunga. Gunga is an instrument from Capoeira. We have the berimbau with the “calabash”, I think – it’s an instrument from Capoeira.

Jehan: Okay. From what we understood, you mainly use free software

Nara: Yes.

Jehan: Mainly, or only?

Nara: Only.

Jehan: And which ones in particular?

Nara: I use GIMP, Inkscape, MyPaint, sometimes Krita – I’ve tried it – Scribus, FontForge, FontMatrix, and others like everybody uses.

Jehan: Do you use Linux?

Nara: Yes, Arch Linux.

Jehan: So full free software from start to end! Okay, and why do you do this?

Nara: When I heard about free software and Linux, I was working in a cultural space. I was working with theater and with drawing, and we already have that culture of sharing things and sharing knowledge. So when I met these guys in free software, they told me about what GNU and Linux were and the philosophy – and when I heard about it I fell in love with it. Because I already think that way, and so free software is applying what I think is right onto software and onto technology. So for me it just makes sense.

So I started to use this software. In the beginning it was difficult to make the transition, but with some time I got into it.

Jehan: So you made a transition from proprietary software?

Nara: Yes, from proprietary software to Linux.

Farid: When was this?

Nara: When? Ah, let me count…

[group laughter]

I was not finished studying then, so like around 2006 or 2007 I started. I really started to use Linux and everything for working in 2008, for everything.

Jehan: So you studied design in university?

Nara: Yes, in university.

Jehan: With proprietary software?

Nara: Yes, with proprietary software only. But my university was not so focused on software. In five years of studying, we only had one class about software. And as the class went on, everyone already knows how to use it! So it’s like a class that has to be on the curriculum, but it’s not like you have to use – it’s more like conceptual.

Simon: Something I do a lot is that - I’m a software developer mainly, so I do a lot of my own tool development. Like I have a specific problem and I know there is an algorithm in my mind that I know would solve the problem (or might solve the problem), so I start implementing my own tools for very specific, very weird tasks, because I can’t do it with GIMP.

Nara: I would like to do that!

Simon: So this is what I wanted to ask – do you have programming experience? Do you have an idea of what it means to develop software?

Nara: No, but I think I have an idea – but I do not develop programs. I’ve studied a little, but it’s not like I can do something. I can see the code lines and know more or less what’s happening, but I can’t write lines by myself.

Jehan: You’ve told me that sometimes you will see some scripts and guess what it can be, and change the numbers…

Nara: Yeah, but more in insights and not in the programming itself.

Jehan: Since we’re doing this interview for gimp.org, what can you tell us about GIMP? How do you like it? How do you hate it? Tell us everything!

Nara: [Laughing] The first thing is, I like GIMP. I use it a lot. My work and style is more vector, but I use GIMP a lot and I like it.

When I made the transition to free software, until today one thing I didn’t like is that you don’t see the effects. You have do something, turn back, “Oh no!” - I have to change two, three points here, then I have to undo and do it again and come back. For me, it’s one of the things that makes the work not fluid.

I’m so happy to see GEGL on-canvas effects.

[Editor’s note: This feature was already implemented in the development version of GIMP 2.10, officially released about a year after this interview.]

Jehan: So, some other comments on GIMP?

Nara: Yeah, I really like it but, for example, I have some problems with my tablet. When I bought my first tablet, it simply didn’t work on GIMP. And I think it’s because of that, I use MyPaint. Because I have to work, and I have to work right now and the pressure doesn’t work, so what can I do with my tablet – so I found MyPaint, and I started to work with MyPaint, and it’s because of that I use it. Not because I think it’s more powerful than GIMP – it’s just because of that. At the time I liked it, and today I still use it.

[Editor’s note: GIMP 3.0 improved many issues with tablet support that were mentioned here.]

Jehan: So MyPaint is your main software?

Nara: For drawing, yeah. Because I am a designer, but I’m an illustrator too. So for illustration I use MyPaint, just for that. For small drawings, I use vectors in Inkscape, and so on.

I use GIMP more for photos, for editing, composing, correcting photos.

Jehan: Yesterday when we spoke, you had this nice example of a job you did with Scribus. Like your first job with free software, I think?

Nara: No, my first book.

Jehan: Ah, your first book, not your first job with free software. Could you tell it again, now that we’re recording?

Nara: I was called on to make a big book, like three hundred pages. There was little time to do it, like three, two weeks. I am from Brasília, and they said you have to do it here with us to get it quicker. I traveled to Bahia to do it, and when I arrived there, there were two other designers. It was funny because I worked in Scribus, one worked in Corel Draw, and the other one in InDesign. So you had three designers, three different software.

Jehan: And three different operating systems.

Nara: Yeah, and three different operating systems, and we had to do one book, the same book!

So we met each other and said “Okay, let’s do it!”. We separated the book into pages, so I would do the first one to 100, the other designer would do 101 to 200, and so on. And we together figured out how the design of the book would be, and the rules to make each part feel like the same book.

So we started, and just like that, I finished first! I was worried, because I had not used Linux for too long, and if there was something wrong in the software or in the distribution, I would not know how to fix it. One of the designers had Mac and the other had Windows and I was so worried.

But it went well and I finished first – and it was very encouraging for me. It’s just a tool you know? I can do it, he can do it, she can do it – everyone can make it, so I was very happy. Because in the beginning I was worried about everything going wrong, and that there would be problems when I saved the PDF and printed it, but it was all okay.

The book was about experiences with, we call it here “apprentice to Griô”. It’s from the French language, because it came from Africa but a country that speaks French.

It’s like an old master who teaches the people around them, the community, something – knowledge about herbs, which can be medicinal herbs, or teaches about techniques about how to construct instruments, or make music, or dancing – like masters of Brazil, of all Brazil. So it’s because of that it’s a big book!

Years later, in the north of Brazil, when the waters came and filled the houses in the city – a flood. I was seeing that on the TV there was an old lady with her flooded house beside her, everything destroyed. And she had that book in her hand. She was crying because her house was destroyed, but she had the book, and she was happy she still had the book even though she didn’t have her house anymore.

So it was a meaningful project, and it was the beginning of my using Scribus.

Jehan: Are there things sometimes you feel you are not able to do with free software? You already answered this yesterday, so I’m just asking again to hear you saying it.

Nara: When I see art – art is everything, design is everywhere – I can’t see something and think about “I can’t it do with free software”. I can do it – maybe I can’t do it because of my creativity or because I don’t think about it, but technically I can do it, you know. We have the tools to do it. We have other ways, but we have the tools I think – in my area of design.

Simon: What would interest me is, you mention that you use quite a lot of different tools, like GIMP, Inkscape, Blender, Scribus -

Nara: Blender not yet, though I started animating in the timeline. In the movie that we showed, the first one that was in 2D, I animated parts of that.

Simon: But there are a lot of different tools that you and your colleagues use. When you start a project, do you pick one of the tools and stick to it, or is more like you start using one tool then transfer the result to a different tool?

Nara: Yes, it was like each tool was like a room of a house. I live in the house, there’s a lot of rooms, and sometimes I’m in the living room, other times I’m in the bed room, other times I go to the kitchen. It’s like I have a bottle, and I take the bottle here and there.

I don’t choose the software. I plan the project, I think about it, and think “How am I going to make this?” So I will start drawing in MyPaint. But I need it to be a vector, so I save it, open in Inkscape and add a vector. But ah, I need an image in the background. So I open the image in GIMP, I work with the image there, then import into Inkscape, okay. But oh, now I have to print it. So I save what I can save in vector I save in vector, and what I can’t save, I export. And I go to GIMP, transform it and edit it, and I take everything, go to Scribus, put them together, and make a PDF. More or less like this. I’m always going back and forth between the programs.

I think it’s very complicated, but for me it’s very simple. But when I teach things like that it sounds very complicated.

Jehan: Do you have any questions, Aryeom?

Aryeom: I feel like I am in her head. I totally understand – I work the same way. Maybe later if I have any questions I’ll ask.

Nara: I learned everything by myself. So I don’t like tutorials, you know?

Aryeom: You don’t like tutorials?

Nara: Yeah, I don’t have the mind to read or watch them. I learn all by myself. I think my way of working is just my way, because I learn by myself. And sometimes I get in touch with people who use the software too, I like to watch them because people do things very different that I do, and things more easily. And sometimes I teach the software to someone, and in two weeks or three, I go to see what the people are doing. “Oh my God, I’d never think of that way!”. It’s very fun because of this.

I don’t like to do workshops because of that. I think my style of work is very crazy. But we can talk about it!

Jehan: So right now you have a big animation project. So maybe can you speak about it?

Nara: Well, Farid is the director. He writes the script. I am the art director, but I also help him with the script and doing all the storyboards. I do it in MyPaint. I was a little worried because I’ve never done a storyboard before. So I study a little, see other’s storyboards, and make it for the animation. And we are talking with people who want to work with us on the animation – and I was happy because people always say “You have a beautiful storyboard!”. I was worried about that.

I think we are, I don’t know, opening ways. Because we are not a 3D studio but we want to do 3D animation, so we have to contact on a lot of other people in Brazil and Latin America, and even in Europe. It’s been like a dream to make it. And we want to make it very fine, very good, because today if you are seeing bad 3D, then you don’t watch it. Because you have Pixar, you have Disney, you have a lot of others. I don’t think that we’ll be like Pixar, but we have to do something very good and great to be seen, you know? I think this is our goal. We want to make something very nice, very good that everyone wants to see.

We’re telling Brazilian history of Quilombo, when there was slavery. Some slaves ran away and made a tribe, a community of their own and lived there. And these communities survive until today. And some of them have a lot of different cultures. It’s like they’re isolated. And the story is about one of these communities. In Brazil the agriculture is taking the lands of these people, because they have a paper that says “We own these lands”, but actually these peoples have been there for 300, 400 years.

So we are telling the story of a girl who lived in a community like this. And they’re being pressured to go out and leave their lands. The story is a fiction, but it’s based on real facts. This is the history. It’s going to be like 10 minutes, it’s a short one, but it’s a real movie and after it’s finished, we want to continue it. Make like episodes or a long movie – it’s just like a pilot. But we need the pilot to get a bigger step.

Aryeom: I feel so moved, because our ZeMarmot project is also like this.

Nara: Here in Brazil there’s a law, I’m not quite sure, that for free television and private television, 50% of programs have to be Brazilian programs. Because it’s all foreign programs, so the government says that 50% have to be produced here in Brazil. So I have a lot of opportunities in that way for animated series.

Jehan: So you plan to distribute on TV.

Nara: Yeah.

Aryeom: Why did you choose 3D? Why not 2D?

Nara: Because we love it! We really love 3D, we’re really passionate. We started using Blender, even for 2D, but we want to go to 3D you know. We have some experiences, and we like the visuals of the movie – we actually don’t work with 3D, but we want to. A lot of people do that – I think 2D is less expensive and -

Jehan & Aryeom [in unison and laughing]: I don’t think it’s less expensive!

Nara: No? We like 3D. We want to make it – it’s so popular for the kids, for everyone. We want this movie not to go to the festivals and stay there. A lot of good films here are made this way. The very good films go to the festivals, earn their prizes, and no one’s ever seen the movie. “Oh you’ve seen that movie? No!”. It will never go to the cinemas.

We want it to have the chance to become popular, you know, a lot of people really watching it. And 3D has this affection, people really like these.

Jehan: I know you said you also appreciate Creative Common licenses and stuff like that, so is this movie going to be under such a license?

Nara: Yes, it’s going to be an open movie! You can take the characters and make another animation by yourself. If you want to take everything, the characters, the background, everything, and animate another story, you can do this.

Jehan: Which license?

Nara: We haven’t thought about it yet, but the kind of license where you can make anything.

Simon: You said 3D. I sometimes have the impression that 3D in some way is more limited in what you can do artistically compared to 2D.

Nara: Yes, it is.

Simon: So this is not a factor for you?

Nara: No. Because in 3D, it’s like you said. If you’re doing a 2D animation, I don’t know, you can do a lot of types of techniques. Like it can be black & white, it can be color, or so many types – it’s like art in stop motion. 3D is different – you have a character, and you have the scenery, and the scenery is just the scenary. You can make some tricks with lighting and shading and colors, but it stops there. It’s an artistic limitation, I agree with that.

Aryeom: In your team, no one had any experience making 3D animations?

Nara: I animate, but I know how to take the characters and make them move. But I’m not an expert. Farid knows that too and know how to make a 2D animation in Blender. But 3D is a new challenge for us.

Jehan: I think also the question was, you are a designer so you usually work in 2D. So we would expect someone who draws would want this drawing to come to life, than just doing the drawing and give it to someone else to make the actual final thing.

Nara: I have difficulties with this. I get tired of drawing very quickly. I can’t imagine myself drawing the same character more than, I don’t know, 10 times. I think I would die if I did that.

Aryeom: Haha, I’m dying!

Nara: It’s like my style. This book was difficult to me, because I had to draw the characters the same. They have to look the same every time I draw it. I don’t like that. I like to do one drawing and it’s over. They have to repeat and be the same. I like the work, but the process of doing the same thing is difficult for me.

Jehan: So you prefer to just draw something and let someone else repeat it again and again.

Nara: Yes, like the computer!

Aryeom: To make a series, an episodic drama, it’s easier to make in 3D. For long form, it’s good I think.

Jehan: Yes, for long form, but for short movies it takes longer due to preparations.

Nara: So it’s not my kind of thing.

[Nara hands out a book]

Nara: It’s by a friend of mine who wrote the story and he asked me to make the drawings. I don’t do a lot of kid stuff, but I like it. And it invites kids to draw at the end of it. It talks about what city do kids want to live in, and what city we want for ourselves. We have a lot of problems in the cities here, and I like the idea of book, to let kids dream about the city because we want that dream to come true.

Aryeom: What about Gunga’s future?

Nara: Ehh, I expect in the future that we have more people working with us. And we have more companies work with us with free software, you know. I’d like to get larger but not too larger. Because I want my life too!

Aryeom: Wise!

Nara: But I’m happy now because last year two new people joined the studio, and it’s a lot more fun to work with more people. We exchange experiences, and I think I want to grow in that way, to get a little bigger and get more partners. And work with more cinemas! It’s more difficult because it’s expensive to work with cinemas, working with animations. We like to do more for ourselves. We make a lot of productions, videos for other companies, for the government, so we’d like to do more for ourselves – like our stories, less for them, more for us.

Jehan: Okay, maybe the last question unless someone has something. Do you have any requests for GIMP developers? Other than on-canvas preview because we already have it!

Nara: I will see the new version you talked about after this.

No, I’m okay. I think I’ve used it for such a long time that I’m so adjusted to it. In the beginning I had a lot of issues – if you gave me a paper then I would fill it with “I want this, I want that! Why do I have this? I can’t believe it!”

But today it is so natural to me that I had to think about it before coming here, because I’ll be meeting people that I want to talk about it with. And I think well, there are little things I want to change in the software. But I think that I have this because I’ve been using it for so long. People are always comparing it with propriety software, and I don’t compare it anymore because it’s been such a long time since I’ve opened something like Photoshop.

So, I’ll think about it.

Jehan: But in the end it just works!_

Nara: Yeah. I’ve written some*, but not for GIMP, for Inkscape, Scribus…

[Editor’s note: Jehan misheard the word “some” here as “song”]

Jehan: Ah! A song for everyone but us?

Nara: I used an earlier version of Inkscape which had a lot of bugs. They just changed it and so I have just bugs for Inkscape. Bugs are bugs.

Jehan: Ah, it’s bugs, not a song!

Nara: Yes, for Inkscape. For Scribus, I have some issues with development.

Aryeom: So you have bugs for them, but you have requests for us. So it’s good!

Jehan: Ah, okay. I thought you’d wrote a song.

Nara: No no – I know my letters are beautiful but it’s not a song.

And I’m happy to meet you! Very happy. I don’t go to a lot of events like here in Brazil. I don’t have a lot of time to do that. And it’s like an investment to travel here because it’s very expensive and the country is too big, haha. So my involvement with free software is like in my community. On our street where we work, a lot of people use Linux because of us. It’s like a center, you know? Time to time, someone goes there, “Oh, I bought a new notebook, I want to install Linux, let’s do it together”.

I think my part in this is more local than global – in the community. I feel better like this. Real connection, offline. I’m not so close to the development here and the other artists. And most of them, they’re just show artists. They don’t really work with design, they don’t really live from this, you know? I tend to know people who live from free software. Most of them are professionals, who are really good at one software, but they don’t put food on the table with it. It’s a little different. I learn from them, but I want to know people who have real issues.

Because when you don’t work with it, you just experiment, you make your own goals. Like “I’m going to make this girl have make-up on her face”, and then you do that. When you work, another person puts a goal on you. Like, “Make this girl have a guitar”, and you have to find a way to do that. And the process when you make a goal versus when another person makes a goal you have to achieve, it’s very different when you’re working with the software. Because you have to go somewhere you’ve never went before. And it makes you use the software in a different way.

You understand what I’m saying? Because when I see the workshops, people are very good at doing something they always do. I want to see people doing very good things they’ve never done before. These things show the real potential of the software.

Jehan: And the potential of the artist.

Nara: Yes, and the potential of the artist. Because you can show me, Inkscape or GIMP is doing this new thing. But maybe I’m not going to use it just because it’s in the software. I’m only will use it if I need it. So, there are a lot of people who are experts in the tools and what the tools can do – to make it, you have to use all the tools combined. It’s different, it’s another level.

Jehan: Well, I think that’s a good interview. Thank you Nara!

Nara: Thank you!

Estudio Gunga

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

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

The public agreement

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

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

A civic act, not a technical one

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

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

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

What standards give us

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

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

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

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

When the rules become private property

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

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

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

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

The ancestor question

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

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

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

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

Hi everyone,

Many thanks to all the people who donate and sponsor our project!

Note: The improvements and features mentioned in this blog post are planned for the next version of Linux Mint, which is scheduled for Christmas this year.

Wayland

We worked really hard on Wayland and we got to the point where it feels solid and the experience is almost on par with X11. Wayland support will no longer be considered “experimental”. In the next version of Cinnamon, both X11 and Wayland will be fully supported.

Here are some of the improvements we implemented:

• Proper mapping (sizing and positioning) for new windows, applet popup menus and context menus
• Proper focus stealing prevention
• Many Wayland crash scenarios fixed in Cinnamon, muffin, cinnamon-session and Xwayland
• Improved support for multiple monitors and KVM switches
• Hardware acceleration throughout the compositor, desktop session, and both Wayland and Xwayland clients (via wl_drm, zwp_linux_dmabuf_v1 feedback v4,  hardware-accelerated GBM over EGL (for NVIDIA))
• Full HiDPI support (crisp icons, fixes in mouse cursors, and bugs specific to Chromium apps such as Slack or VSCode)
• Window Progress (this is what allows, for instance, to see nemo copy progress in the panel app button)
• Root applications (run via pkexec) run as Wayland clients (not Xwayland)
• Session fixes

Cinnamon

Cinnamon also received the following improvements:

• A cinnamon-list-windows command was introduced to make it easy to list all open windows and to quickly see their position, size, HiDPI/app/backend info.
• Muffin now rounds coordinates and dimensions for all Clutter actors. This guarantee crisp and precise rendering and fixes blur issues when applets or desktop components forget to do so themselves.
• Support for systemd’s graphical-session. This boosts Cinnamon’s compatibility with many upstream projects.

System

SSH keyring support was improved system-wide.

Fixes were implemented in the LightDM configuration. 

Support for fingerprint authentication was improved in Slick Greeter. Placing your finger on the fingerprint reader is enough to log in. You no longer need to press Enter afterwards.

Security Updates

Another severe security flaw was found this month. This time, it affects mintupdate: CVE-2026-59159.

I’d like to thank Robbie Loewen-Ross for finding this vulnerability and working with us on it.

Security updates were sent 3 weeks ago, for all affected versions, in both supported and EOL (End-of-Life) Linux Mint and LMDE releases.

Make sure you update your system.

Sponsorships:

Linux Mint is proudly sponsored by:

Gold Sponsors: Silver Sponsors:

Bronze Sponsors:

Donations in May:

A total of $19,612 were raised thanks to the generous contributions of 611 donors:

$531 (3rd donation), Joshua G. aka “Heptaveegesimal“
$500 (10th donation), Matthew P.
$500, skyace65
$405, Adriaan S.
$300, Jon H.
$265, Tommaso G.
$212 (6th donation), Natalya S.
$212, Evan W.
$200 (8th donation), Neil V.
$200 (2nd donation), Donald P.
$200 (2nd donation), Rick L. S.
$200, Michael T.
$180 (9th donation), Wolfgang S.
$174, Giovanni V.
$159 (2nd donation), Friedrich N.
$127, Steffen M.
$120 (2nd donation), Cameron E.
$116 (4th donation), TURBOKAN_TR
$116, Achim P.
$116, Irene A.
$116, Jessica F.
$116, Peter V.
$116, ROCHOY J.
$111, Free
$106 (20th donation), Jiří B.
$106 (5th donation), Johan V. D. K.
$106, Christian K.
$106, Claudius M.
$106, Dietmar G.
$100 (20th donation), James F.
$100 (16th donation), Mountain Computers, Inc aka “MTNCOMP aka GGPCTU“
$100 (6th donation), Stuart C. D.
$100 (5th donation), Philip M.
$100 (4th donation), Don W.
$100 (2nd donation), David W.
$100 (2nd donation), Henry B.
$100 (2nd donation), Michael D.
$100, Dennis L.
$100, Jonas H.
$100, Olga M.
$100, Vignesh I.
$100, William R.
$77, Samuel H.
$75 (3rd donation), Harry M.
$65, Joe K.
$60, Daniel B.
$58 (20th donation), Paul S. E. aka “Paul”
$58 (5th donation), Peter B.
$58 (4th donation), Charl C.
$58 (3rd donation), Mike A. aka “peppermint86”
$58 (2nd donation), Stefan A.
$58, Bogdan P.
$58, Enrico R.
$58, Georg W.
$58, Mattias J.
$58, Peter D.
$58, Peter H.
$58, Ralf G.
$58, Stephan M.
$58, TORD A. L. H.
$58, Urs N.
$57, Ulrich M.
$53 (26th donation), Bernard H.
$53 (19th donation), Christian G. aka “Chrissy”
$53 (11th donation), Intralogistiker
$53 (4th donation), Christian H.
$53 (4th donation), John F.
$53 (3rd donation), Daniel F.
$53 (3rd donation), Herbert Jan K.
$53 (3rd donation), Pierre V.
$53 (2nd donation), Holger S.
$53 (2nd donation), Karen P. aka “Kari”
$53 (2nd donation), Matjaz C. aka “TitoJBroz”
$53 (2nd donation), MICHAEL
$53 (2nd donation), Richard N.
$53 (2nd donation), Rico B.
$53, Alan H.
$53, Andreas H.
$53, ATP
$53, Bach T.
$53, Bas R.
$53, Frederic B.
$53, GIRAULT
$53, Janusch M.
$53, jeanmarie L.
$53, Jens G.
$53, Jonathan C.
$53, Jonathan L.
$53, JORDI F. S.
$53, Juergen K.
$53, Kreutzmann-Kirschner
$53, Lorenzo T.
$53, Lutz P.
$53, nathalie C.
$53, Okt D.
$53, Olav M. K.
$53, Robbie Reboot
$53, Tanku T.
$53, Walter B.
$50 (25th donation), Adam K.
$50 (20th donation), Mothy
$50 (16th donation), Anthony C. aka “Ciak”
$50 (11th donation), stewy
$50 (9th donation), Dean R.
$50 (9th donation), Khalid T. aka “k9750”
$50 (7th donation), aka “GM46”
$50 (5th donation), Leonhard R.
$50 (5th donation), Peter B.
$50 (5th donation), Peter S. aka “Pierre”
$50 (4th donation), Patrick T.
$50 (3rd donation), Terry H.
$50 (3rd donation), Thomas P.
$50 (2nd donation), abrames
$50 (2nd donation), Roy K.
$50 (2nd donation), Thomas O.
$50,
$50, Bernard S.
$50, Bobby B.
$50, Brian G.
$50, Carl Summers
$50, Christian W.
$50, Christophe K.
$50, Dany A.
$50, dave W.
$50, David H.
$50, David I.
$50, GARY A. T.
$50, James M.
$50, Jayden. A
$50, Juan M.
$50, Lowell I.
$50, Michael C. P.
$50, Michael D.
$50, Michael G.
$50, Mikel N.
$50, Nicolas V.
$50, Norman G. W.
$50, PATRICK M.
$50, paul H.
$50, Peter P.
$50, Porter T.
$50, Robert K.
$50, Sean F.
$50, Seth B.
$50, shade tree welder
$50, Simon G.
$50, Sriram B.
$50, Steven C.
$50, Thomas B.
$50, Thuan N.
$50, William B.
$49, sean M.
$44, nicolas V.
$42 (17th donation), Henk van C.
$42 (6th donation), Herve C.
$41 (3rd donation), Nicolas G.
$40 (35th donation), Aimee W.
$40 (2nd donation), Stephen J.
$40 (2nd donation), Theodore K.
$40, Paul S.
$39, swarfendor437 aka “swarf'”
$38, Daniel P.
$36, Kase E.
$35 (3rd donation), Kim F.
$35, MR J. M.
$35, Oliver S.
$35, Patrick S.
$31 (16th donation), Luca D.
$31 (3rd donation), Jeroen O.
$31 (2nd donation), Juan L.
$31 (2nd donation), Patrick U.
$31, Alexander S.
$31, benjamin T.
$31, Michael N.
$30 (12th donation), jowind
$30 (4th donation), Ron N. aka “TechNick”
$30, Eduardo N.
$30, Jeremy N.
$30, Joseph D. S.
$30, Michael U.
$30, William E.
$29, Silvan J.
$26 (9th donation), Jonathan. H
$26 (2nd donation), Jan B.
$26, Christian E. G.
$26, Iain J.
$26, Philipp K.
$25 (118th donation), Johann J.
$25 (63rd donation), Linux Mint Sverige
$25 (33rd donation), Ted S.
$25 (24th donation), Richard N.
$25 (18th donation), Donna B.
$25 (16th donation), John N.
$25, Christopher S.
$25, Mr M. W. W.
$25, Paul W.
$25, RICHARD B. C.
$25, wayne G.
$23 (71st donation), Peter E.
$23 (33rd donation), Benjamin W. aka “UncleBens”
$23 (13th donation), Frank W.
$23 (6th donation), Erich G.
$23 (4th donation), Antonio R.
$23 (4th donation), Reinhard R.
$23 (4th donation), Renaud B.
$23 (3rd donation), Ethan T.
$23 (3rd donation), Werner Palmen
$23 (2nd donation), Alexander S.
$23 (2nd donation), Arild S.
$23 (2nd donation), Hans R.
$23, Alain B.
$23, Diego P.
$23, Manuel H.
$23, Marco V. D. S.
$23, Mr B.
$23, saviour P.
$23, WALTER I.
$22 (6th donation), Peter Z.
$21 (77th donation), Bryan F.
$21 (38th donation), Stefan W.
$21 (32nd donation), Doriano G. M.
$21 (31st donation), Marek S.
$21 (14th donation), Gabriele Bandini aka “GiBi Gab“
$21 (9th donation), Harold H.
$21 (8th donation), Ezequiel O.
$21 (8th donation), Kai D.
$21 (7th donation), Michael B.
$21 (5th donation), Henning P.
$21 (5th donation), Rimas V.
$21 (4th donation), Jose C. aka “Revenarius”
$21 (4th donation), Stuart M. aka “UKStuart”
$21 (4th donation), Vittorio A.
$21 (3rd donation), Bartomiej T.
$21 (3rd donation), Michael K.
$21 (3rd donation), Nuno G.
$21 (2nd donation), Adam B. aka “Neomodus”
$21 (2nd donation), Drew C.
$21 (2nd donation), Frank T.
$21 (2nd donation), Joe S.
$21 (2nd donation), Jürgen N.
$21 (2nd donation), Stefano C.
$21 (2nd donation), Stephen P.
$21, Alessandro P.
$21, Alois P. R.
$21, Andrejs Z.
$21, Anibal L.
$21, Ayse B.
$21, Benedikt V.
$21, Bernd B.
$21, Berthold C.
$21, Christian H.
$21, Dominik U.
$21, Dylan B.
$21, Fiorenzo M.
$21, Frank M.
$21, FRED J. N.
$21, Hans-Peter K.
$21, Hubert S.
$21, Jacques D.
$21, Joachim K.
$21, Julian T.
$21, Lars S.
$21, Lucas B.
$21, Manfred K.
$21, marco B.
$21, Marco M.
$21, Maurizio D. R.
$21, Max K.
$21, Michael B.
$21, Michael R.
$21, O H. V.
$21, Olaf M.
$21, Peter P.
$21, Schütz C.
$21, Suffridus G.
$21, Ulf L.
$21, Walter G.
$21, Werner K.
$21, Z A. Z. A.
$20 (27th donation), Nigel B.
$20 (13th donation), Mark R.
$20 (12th donation), Lamont C.
$20 (11th donation), Randall W.
$20 (11th donation), Ron C.
$20 (10th donation), Anthony S.
$20 (8th donation), Orlando O.
$20 (7th donation), Kevin K.
$20 (7th donation), Mary H.
$20 (7th donation), Rimon K.
$20 (6th donation), Edward F.
$20 (4th donation), Carlos L.
$20 (4th donation), Chadwick C.
$20 (4th donation), Glenn S.
$20 (4th donation), Kurt K.
$20 (4th donation), Terry R.
$20 (3rd donation), Angel C.
$20 (3rd donation), John W.
$20 (3rd donation), Steven P.
$20 (3rd donation), Warner Cascante
$20 (2nd donation), Benjamin K.
$20 (2nd donation), Fred S.
$20 (2nd donation), Frederick B.
$20 (2nd donation), John A.
$20 (2nd donation), Joseph K.
$20 (2nd donation), Paul C.
$20 (2nd donation), PAUL G.
$20 (2nd donation), Robert K. aka “Nismo”
$20 (2nd donation), Sandra B.
$20 (2nd donation), Stephen M.
$20, Axel B.
$20, Carlos H.
$20, CD V.
$20, Charles M.
$20, Charles V.
$20, Daniel T.
$20, David C.
$20, Donald M.
$20, Dylan H. aka “D-Guy“
$20, Eric S.
$20, Glennon T.
$20, Harvey C.
$20, Ian U.
$20, J-Yves D.
$20, James T.
$20, James W.
$20, John H.
$20, john K.
$20, Joseph C.
$20, Joseph H.
$20, Jude C.
$20, JULIO H.
$20, Just Me
$20, Keith G.
$20, Luis R. R. F.
$20, mr J. B.
$20, NIRAV D. R.
$20, Pascal B.
$20, Sean M.
$20, TOMASZ W.
$20, Tommie B.
$20, Yuyong Z.
$17 (2nd donation), Peter W.
$17 (2nd donation), Sabrina F.
$15 (92nd donation), Andreas S.
$15 (12th donation), Joerg B.
$15 (3rd donation), Jorgen Rhode
$15, Amritpal G.
$15, Anthony K.
$15, Fred B.
$15, Michael W.
$15, Niels D.
$13, scott D.
$12 (20th donation), José G. aka “picaso”
$12 (17th donation), Abe Z.
$12 (15th donation), Gabriele I.
$12 (6th donation), Nikolay G.
$12 (5th donation), Ingo H.
$12 (3rd donation), Fabrizio P. aka “redshift72”
$12 (3rd donation), Pedro S.
$12 (2nd donation), aka “Admiral Crow”
$12 (2nd donation), Bojan M.
$12 (2nd donation), Nils W.
$12 (2nd donation), Robert M.
$12, Alexander H.
$12, Alexander S.
$12, Andreas M.
$12, Andrei T.
$12, Bartosz K.
$12, Christian P.
$12, Claus-Peter L.
$12, Gustav H.
$12, Ian K.
$12, Jasper F.
$12, Jean-Marc M.
$12, JIŘÍ B.
$12, Jörg S.
$12, José M. P. I.
$12, lothar G.
$12, Luca P.
$12, Olaf Q.
$12, PATRICK L.
$12, Patrick V.
$12, Przemysaw Z.
$12, Robert L. M.
$12, Tino Z.
$11 (28th donation), Adian K.
$11 (18th donation), Alessandro S.
$10 (122nd donation), Thomas C.
$10 (64th donation), Philip Woodward
$10 (49th donation), Tugaleres.com
$10 (28th donation), Christopher R.
$10 (23rd donation), Slobodan Vrkacevic
$10 (16th donation), Artem Ignatyev aka “ZaZooBred”
$10 (16th donation), Masaomi Y.
$10 (15th donation), Axel R.
$10 (13th donation), Mariusz B.
$10 (12th donation), Andreas G.
$10 (12th donation), Thomas R.
$10 (10th donation), Eric H.
$10 (10th donation), Tomasz K.
$10 (10th donation), Želimir S.
$10 (9th donation), Jeanmichel T.
$10 (9th donation), M.B.
$10 (8th donation), Thomas L. aka “hensys”
$10 (7th donation), Allen S.
$10 (7th donation), Cască de Copiat
$10 (7th donation), Honest Beneve Reviews
$10 (7th donation), Rainer B.
$10 (7th donation), Urszula S.
$10 (5th donation), Balazs S.
$10 (5th donation), Hubert F.
$10 (5th donation), Rainer G.
$10 (5th donation), Selwyn A.
$10 (5th donation), Stefan B.
$10 (4th donation), cască de copiat
$10 (4th donation), Lars A.
$10 (4th donation), Lyuben R.
$10 (4th donation), Piotr R. aka “_PAPCIO_”
$10 (3rd donation), Balázs V.
$10 (3rd donation), Dieter S.
$10 (3rd donation), Ken P.
$10 (3rd donation), Linda P.
$10 (3rd donation), Niklas K.
$10 (3rd donation), Pedro A.
$10 (3rd donation), Rafael B.
$10 (3rd donation), Ralph B.
$10 (3rd donation), Roger L.
$10 (2nd donation), Anders B.
$10 (2nd donation), Annet V. E.
$10 (2nd donation), Arne A
$10 (2nd donation), Claudiu-Stelian D.
$10 (2nd donation), Esa A.
$10 (2nd donation), Florian B.
$10 (2nd donation), James M.
$10 (2nd donation), Joachim K.
$10 (2nd donation), Judian G.
$10 (2nd donation), Robert M.
$10 (2nd donation), Thomas L.
$10 (2nd donation), Wilhelm H.
$10 (2nd donation), Wolfgang R.
$10, aka “Improntus”
$10, Adam S.
$10, Alain G.
$10, Alan Y.
$10, Alfredo G. G. R.
$10, Andreas S.
$10, ANDRES Y. R.
$10, Anonymous
$10, Antero K.
$10, Axel S.
$10, Ben M.
$10, Bernd F.
$10, branko S.
$10, Braz G. D. L.
$10, Carlos S.
$10, Cezary Z.
$10, Christopher H.
$10, Christopher M.
$10, Chuck Monty
$10, Daniel K.
$10, david A.
$10, David L.
$10, Deacon M.
$10, Didier A.
$10, Djordje N.
$10, Eduardo P.
$10, Edward P.
$10, Everteal
$10, Fabrice D.
$10, Filip K.
$10, Gaston N. P.
$10, GERALD F.
$10, H.
$10, Heinrich R.
$10, Herbert H.
$10, HONG J.
$10, hshin
$10, Jair H.
$10, James W.
$10, Jan K.
$10, Jean-Michel G.
$10, Johannes D.
$10, John C.
$10, Jonathan N.
$10, Juan R. T. I.
$10, Kacper B.
$10, Kaj K.
$10, Karl-Heinz L.
$10, Karthik Murali
$10, keith B.
$10, Keith T.
$10, Kelly C.
$10, Kelvin M.
$10, Klemen R.
$10, Liam O aka “locobean”
$10, Lorentz A. L.
$10, Maik G.
$10, Marc C.
$10, Maria C. M. H.
$10, Matthias H.
$10, MI N.
$10, Michael H.
$10, Mingfei G.
$10, Myriel E. R.
$10, Niels C. M. J.
$10, Oscar G. M. E.
$10, Philipp S.
$10, Qifeng S.
$10, Raul O.
$10, Richard P.
$10, Roger L.
$10, Sam G.
$10, SAMUEL K.
$10, Skalli
$10, Stavros S.
$10, Stefan H.
$10, Svenn M. N.
$10, Tatsunori O.
$10, tbnet.pl
$10, Theodore C.
$10, Thomas W.
$10, Tobias A.
$10, Vágó Z.
$10, vanhsana D.
$8 (4th donation), Marcelo A. Maito
$7 (5th donation), Jordan S.
$7, Brodie R.
$7, Dennis C. H.
$7, Lorenzo aka “Kafka”
$7, Tomasz J.
$266 from 77 smaller donations

If you want to help Linux Mint with a donation, please visit https://www.linuxmint.com/donors.php

Patrons:

Linux Mint is proudly supported by 2,326 patrons, for a sum of $5,334 per month.

To become a Linux Mint patron, please visit https://www.patreon.com/linux_mint

This is part of the Annual Report 2025 from The Document Foundation, the non-profit that coordinates the LibreOffice project and community.

Across the reporting period, the public conversation about office software and document formats shifted decisively. The justification for moving away from proprietary suites is no longer framed primarily as cost saving. It is framed as the preservation of independence — the ability of a government to act without asking permission from a foreign supplier. Several of the year’s migrations were announced with that argument stated explicitly and the cost argument set aside; the Austrian Armed Forces went so far as to say the move was not about money at all.

This reframing matters for The Document Foundation, because it moves the debate onto ground where the Foundation has argued for two decades. Digital sovereignty is the ability of nations, organisations and individuals to control their own digital destiny: to control access to their own information without depending on third parties, to make technological choices based on their own needs rather than a vendor’s commercial strategy, and to preserve that self-determination as the market consolidates. When public bodies store their documents in proprietary formats controlled by a single company, they surrender part of that sovereignty.

The year also clarified a distinction the foundation has long insisted on: sovereignty is not delivered by any single layer of the technology stack. It requires an open standard format at the base, an open source application above it, open source infrastructure for data location, and a legislative framework that defines the requirements. A law favouring open source, an open cloud, and an open suite together still leave sovereignty incomplete if the document format itself remains under one vendor’s control. The format is the foundation of the stack, and it is the layer most often overlooked.

The year’s central policy development was Germany’s formal commitment to ODF, a decision whose full weight became apparent only as it moved from principle toward binding implementation.

Germany’s IT Planning Council commits to ODF (April 2025)

In April 2025, Germany’s IT Planning Council — a seventeen-member body representing the federal government and the state governments — committed to moving public administration to the Open Document Format, with the stated aim of making ODF the standard for document exchange by 2027. The Council framed open formats and open interfaces as a necessary building block of public-sector transformation toward digital sovereignty, and commissioned its Standardization Board to implement the decision. The commitment set a clear trajectory: a federal-level decision, binding on the implementing board, with a 2027 target for ODF as the standard for document exchange. Its translation into concrete, enforceable infrastructure standards was expected to follow — and the early signs as the year closed pointed toward exactly that outcome.

• Source: TDF Community Blog, 29 April 2025
• Underlying decision (IT-Planungsrat, in German)

ODF v1.4 approved as an OASIS Standard (December 2025)

On 3 December 2025, OASIS Open approved ODF v1.4 as an OASIS Standard — the organisation’s highest level of ratification — coinciding with the twentieth anniversary of ODF’s original adoption as an OASIS Standard. The new version maintains full backward compatibility while improving accessibility support (assistive technologies, decorative-object marking), professional formatting and visual design, and features for data analysis and technical documentation. It remains an XML-based, vendor-neutral, royalty-free format. Earlier ODF versions are published as ISO/IEC 26300; the four-part v1.4 specification is available in the OASIS library.

• Source: TDF Community Blog, 3 December 2025

Twentieth anniversary of ODF standardisation

The year carried the twentieth-anniversary thread throughout: ODF’s adoption as an OASIS Standard in 2005, and its ISO/IEC standardisation on 3 May 2006. The ODF v1.4 ratification in December 2025 was deliberately timed to the OASIS anniversary. The anniversary is not merely commemorative: it underpins the argument that ODF is the only open standard for office documents with a twenty-year record governments can rely on for long-term archival access.

Open Document Format Campaign and Document Freedom Day

The Foundation ran a sustained ODF communications campaign through the year, built around a regular series of articles on the TDF blog. Rather than isolated announcements, the series formed a coherent body of work that moved from the fundamentals — what ODF is and why it matters — through technical and practical material on file types, compliance and interoperability, the differences between ODF and proprietary formats, migration guidance, and the new features of recent ODF versions, and on to the wider argument connecting open document standards to digital sovereignty. Taken together, the series gave the Foundation a standing reference resource and a consistent public voice on the format throughout the year.

Document Freedom Day was marked as a purely advocacy-driven occasion: blog posts, social media activity across the Foundation’s channels, and small local events organised by community members around the world. The emphasis was on awareness and outreach rather than on any single flagship event.

Public Administrations Migrating to LibreOffice/ODF During the Year

The following migrations were publicly reported and verifiably advanced during 2025. Status reflects what the cited primary or most reliable source actually supports. Long-standing legacy deployments are deliberately excluded; this list is reserved for movement during the year, and only entries with solid sourcing are included. Figures and completion claims should be confirmed against TDF records before publication.

Schleswig-Holstein (Germany) — confirmed, substantially advanced

By early December 2025, the northern German state reported that close to 80% of administrative workstations outside the tax administration were running LibreOffice as the binding standard, with Microsoft Office and Outlook either already uninstalled or in the process of removal, and a new-licensing rate already well below 10%. The state reported licence-cost savings already exceeding €15 million, against a one-time 2026 migration investment of €9 million. The remaining ~20% of workstations depend on specialist applications with technical ties to Microsoft formats; migration paths for these, and for the tax administration, have been defined. In parallel, the state completed the migration of more than 40,000 mailboxes (over 100 million messages and calendar items) off Exchange/Outlook to Open-Xchange and Mozilla Thunderbird, with the cutover finishing 2 October 2025.

• Schleswig-Holstein State Chancellery press release, 4 December 2025
• Source: The Register, 15 October 2025 (email migration completion)

Austrian Armed Forces / Bundesheer — confirmed, completed in 2025

The Austrian military migrated approximately 16,000 workstations across all branches from Microsoft Office to LibreOffice, with the project finalised in 2025 and Microsoft Office 2016 removed from all machines (Office 2024 LTSC retained only under special permission for legacy macro/Access cases). The Directorate 6 (ICT & Cyber) stated the primary driver was digital sovereignty and in-house data processing, explicitly not licence savings. The Bundesheer contributed more than five person-years of upstream development back to the LibreOffice project; the migration was presented at the LibreOffice Conference 2025 in Budapest.

• Source: TDF Community Blog, 30 September 2025
• Source: heise online, 18 September 2025

Denmark — Ministry of Digital Affairs — confirmed, phased, in progress

The Danish Ministry of Digital Affairs committed to replacing Microsoft 365/Office with LibreOffice, beginning July 2025 with a phased rollout (roughly half of staff in the summer, the remainder by autumn). For accuracy: earlier reporting that Denmark would abandon Windows for Linux entirely was subsequently corrected — Windows remains in use on many devices; the confirmed change is the office-suite migration. Several municipalities, including Copenhagen and Aarhus, were reported to be pursuing similar moves.

• Source: Linux Journal, mid-2025 (with the Windows correction noted)

Threats to ODF Adoption and Digital Sovereignty

The year’s gains were real, but they sit alongside structural threats. The central risk is that the open-source application migrations succeed while the open format battle is quietly lost — that lock-in survives the move by relocating from the application to the document.

Format sovereignty as the overlooked layer

An office suite that does not use ODF as its native format handles ODF files imperfectly, which re-creates interoperability problems and pushes users back toward the proprietary format “for convenience.” A government can therefore adopt an open suite and an open cloud and still fail to achieve sovereignty if its documents remain in a format controlled by a single vendor. The format is the base of the stack; without it, every layer above is compromised.

The “ISO standard format” sleight of hand

When a public administration is told its documents are stored in “an ISO standard format,” the reasonable assumption is genuine openness. OOXML Transitional does not deliver it: its stacked dependencies — format, rendering and fonts — re-encode failure at each layer. A format named as a standard while defined by its own specification as provisional is the principal rhetorical obstacle to ODF adoption, and the principal target of the Foundation’s three-strand evidence work.

Initiatives that default to OOXML under a sovereignty banner

A specific and growing risk is the European sovereignty initiative that adopts open source applications and open infrastructure while defaulting to OOXML rather than ODF as its native document format. Such an arrangement re-encodes the dependency at the format layer even as it presents independence at every other layer. This is the precise failure mode Section 4.5 describes, and it gives the Foundation’s insistence on a native open format its practical
urgency.

Political reversibility

Sovereignty gains are reversible without durable policy commitment. Munich’s LiMux reversal remains the cautionary precedent, and the year offered a live counter-signal: even as Schleswig-Holstein advanced, Bavaria was reported to be pursuing a major Microsoft 365 contract. This is why a binding federal commitment to ODF, of the kind Germany set in motion in 2025, matters: it raises the cost of reversal. But commitments depend on sustained political will to carry them into enforceable practice.

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

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

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

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

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

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

The temporal layer

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

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

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

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

The commercial layer

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

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

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

What the layers have in common

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

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

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

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

Images by Manfred Steger from Pixabay

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 by announcing LibreOffice 26.2.4, the fourth bugfix update to the current stable branch of the suite.

• Throughout the month, we continued our blog post series looking at Open Document Format (ODF), Microsoft’s OOXML, and vendor lock-in: A Standard in Name Only: What OOXML Transitional Tells Us About Format Sovereignty; Euro-Office, open standards, and native ODF; and The invisible architecture of lock-in – the layering of dependencies.

• Our marketing and design communities worked on a new video: Join the LibreOffice Community! (This video is also available on PeerTube.)

• Then we posted sections from The Document Foundation’s Annual Report for 2025: LibreOffice releases, features, QA and accessibility; LibreOffice Marketing Activities; LibreOffice Downloads and Donations in 2025; and LibreOffice Conference and External Events.

• Finally, the the documentation community announced the LibreOffice Getting Started Guide 26.2.

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.

🐛 Bug Fixes & Minor Changes

• Exposed missing strings to translations (#1168) by @himu-gupta in #1168

🌐 Translations

• Updated French translation using Weblate by @Matth7878 in commit
• Updated Latvian translation using Weblate by @Coool in commit
• Updated Portuguese (Portugal) translation using Weblate by @AntonioOliveira2 in commit
• Updated Estonian translation using Weblate in commit
• Updated Czech translation using Weblate in commit
• Updated Hungarian translation using Weblate by @summoner001 in commit
• Updated Polish translation using Weblate by @Aga-C in commit
• Updated Chinese (Simplified Han script) translation using Weblate in commit
• Updated German translation using Weblate in commit
• Updated Bosnian translation using Weblate in commit
• Updated Italian translation using Weblate by @Wiccio in commit
• Updated Dutch translation using Weblate in commit
• Updated Serbian translation using Weblate by @eevan78 in #1167

❤️ New Contributors

• @AntonioOliveira2 made their first contribution
• @himu-gupta made their first contribution in #1168

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

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

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

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

The perception of malfunction

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

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

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

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

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

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

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

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

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

Layer One: the format and its hidden features

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

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

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

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

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

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

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

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

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

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

Layer Two: rendering and its unspecified behaviour

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

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

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

These choices operate across several subsystems.

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

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

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

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

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

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

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

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

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

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

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

Layer Three: fonts and the dependency on proprietary resources

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

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

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

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

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

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

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

Why “invisible” is the key word

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

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

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

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

This is not a coincidence arising from poor design.

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

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

How policy responded, and where it failed

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

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

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

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

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

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

Knowing this pattern is a political act

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

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

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

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

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

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

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

This is part of the Annual Report 2025 from The Document Foundation, the non-profit that coordinates the LibreOffice project and community.

In 2025, The Document Foundation and the global LibreOffice community pursued a marketing and advocacy programme that combined the established work of community building and software promotion with a sharpened public argument about digital sovereignty and open document standards. The year was framed by two anchoring milestones — LibreOffice’s fifteenth anniversary and the passing of 400 million cumulative downloads — and by an increasingly explicit defence of the Open Document Format as the only open standard for office documents. What follows is a thematic overview of the major activities carried out in support of TDF and LibreOffice over the course of the year, grouped by area rather than reported month by month.

Anniversary and Adoption Milestones

Two milestones gave the year its public narrative.

In January, TDF announced that LibreOffice had surpassed 400 million cumulative downloads since 2011, with an average of 28.6 million downloads per year and an upward trend reaching over 35 million annual downloads. The announcement reaffirmed the project’s standing against the long-running narrative that the desktop office suite was destined to disappear into the cloud.

In September, the project celebrated the fifteenth anniversary of LibreOffice, launched on 28 September 2010 as a fork of OpenOffice. The anniversary was treated not merely as a software birthday but as a statement about the movement LibreOffice represents: a community of thousands of contributors and dozens of companies, localisation into more than 120 languages reaching billions of potential users, and a sustained argument for digital autonomy in an era of cloud lock-in and disappearing ownership. The communication tied the milestone directly to ODF as the guarantee of perpetual, transparent control over one’s own documents.

Advocacy: Digital Sovereignty and Open Standards

The most distinctive development of 2025 was the consolidation of marketing into a coherent advocacy campaign around digital sovereignty and open document standards.

The end of Windows 10 support, scheduled for 14 October 2025, provided the central advocacy occasion. TDF backed the international @endof10 campaign and argued that the moment was a crossroads rather than a routine product transition, positioning Linux and LibreOffice as a privacy-respecting, future-proof alternative to a forced upgrade path toward Windows 11 and Microsoft 365, with their attendant subscription costs, cloud dependency, and hardware obsolescence.

Alongside this, the foundation built a body of technical and policy-oriented material making the case for ODF as the only open standard for office documents and exposing the structural problems of OOXML. This advocacy strand reframed the project’s communication from product promotion toward a public argument about format ownership, lock-in, and institutional control of documents — an argument that resonated strongly with public-sector and policy audiences.

Conferences and Major Events

International and regional conferences remained central to the foundation’s visibility.

The annual LibreOffice Conference 2025 was the flagship gathering of contributors — developers, designers, documentation writers, translators, and marketers — and was promoted across the project’s channels in the now-established pattern of agenda, speaker, and live-update coverage. Two major regional conferences extended the programme across the world’s communities: the LibreOffice Asia Conference 2025, hosted in Japan, and the VI Latin American LibreOffice Congress, held in Havana. Both brought together contributors and users from their respective regions, generated substantial follow-up content, and reinforced the project’s presence in two of its most active geographies.

The community calendar was also rich with smaller regional events that the marketing team supported and amplified, including the LibreItalia Conference 2025, LinuxDays 2025 in Prague, the OSS Conf 2025 in Luxembourg, an event in Nepal tied to Software Freedom Day, the Augsburger Linux-Infoday, the Prague Installfest, the Univention Summit, the Linux Arena in Pordenone (Italy), and FLISoL Brasília. The project also maintained a presence at FOSDEM 2025 in Brussels at the start of the year.

Community Building and Recognition

The recurring Month of LibreOffice campaigns ran again in May and November, recognising and rewarding contributors across development, documentation, QA, localisation, and marketing through digital badges, public acknowledgement, and sticker packs and merchandise shipped to participants. The campaign continued to serve both as a celebration of existing contributors and as an on-ramp for new ones.

A significant structural development was the launch of the LibreOffice US community in November. Recognising that the United States, despite a large user base, had never developed an organised local community, TDF created dedicated communication channels (Discord, bridged to Matrix, and a Mastodon account) with the goal of supporting US-specific merchandise, marketing and advocacy materials, and meetups.

Documentation, Publications and Merchandise

The community continued to expand its published resources as a marketing and onboarding asset. New user guides were released for the 25.2 line, alongside the Calc Guide 24.8 and Czech translations of the Getting Started Guide 24.8 and the Calc Guide 25.2, reflecting the contribution of native-language communities. New LibreOffice Expert magazines for 2025–2026 were made available for schools and local communities, and a new line of LibreOffice merchandise was introduced to support events, giveaways, and fundraising.

Media, Press Relations and Social Media

TDF sustained its media relations work throughout the year, issuing press releases tied to releases, milestones, events, and public-sector adoption, and reinforcing LibreOffice’s position as a cost-effective, secure, and privacy-respecting alternative to proprietary office suites. The social media strategy continued across Mastodon, LinkedIn, and the project’s other channels, with particular emphasis on reaching decision-makers in public administration through case studies and adoption stories, and on carrying the digital-sovereignty argument to professional and policy audiences. Monthly project-and-community recaps provided a steady, aggregated record of activity across the year.

Public-Sector Adoption

Public-sector migration continued to be one of the most persuasive elements of the project’s external messaging, demonstrating LibreOffice’s viability at institutional scale and lending concrete weight to the digital-sovereignty argument that ran through the year’s advocacy. These migrations were amplified through press and social channels as evidence that open standards and open-source office software are a realistic foundation for public administration.

Conclusion

In 2025, TDF’s marketing and advocacy work matured from software promotion into a coherent public case for digital sovereignty built on open document standards. Anchored by the fifteenth anniversary and the 400-million-download milestone, sharpened by the end of Windows 10 and the defence of ODF, and sustained by conferences, community campaigns, publications, and steady media work, the year’s activities both amplified LibreOffice’s visibility and strengthened the wider argument that documents — and the institutions that depend on them — are better served by open standards and community-driven software.

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

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…

Donations

In 2025, The Document Foundation received 140,593 donation transactions, for a total of €1,807,780 net of payment processing and currency conversion charges. This represents a substantial increase over the two preceding years: donation transactions had numbered 98,361 in 2023 and 104,430 in 2024, while the corresponding amounts were €1,302,956 and €1,387,589. Transaction volume therefore grew by approximately 35% year on year, and the cleaned total rose by roughly 30%.

A note on methodology is useful here. The charts in this section report the number of donation transactions rather than the amounts received. This is deliberate: the financial figure can be established only after each transaction has been cleaned by subtracting conversion charges and processing fees, whereas the transaction count is known directly. The charts therefore describe the shape of the trend, while the euro totals given above represent the financial reality behind it.

The quarterly distribution shows that the year’s growth was strongly concentrated in its final months. The first three quarters each built modestly on the last, and the fourth quarter rose well above them. This Q4 surge has a clear explanation. The announcement of LibreOffice 25.8 in August was followed by the introduction of a new update mechanism on Windows, which presents users with a dedicated new-features page and an invitation to support the project. This combination proved markedly effective in converting attention into contributions. The growing public interest in European digital sovereignty over the course of 2025 may have provided additional, favourable context, but the measurable drivers were the release and the new update mechanism.

Downloads

LibreOffice was downloaded 44,809,742 times in 2025 from the official download page, and the year recorded the highest annual figure in the project’s history. The per-year chart shows steady growth across more than a decade; the 2019 figure is shown but should be read with caution, as automated traffic distorted the counts that year. Rather than omit it, the Foundation has chosen to publish a credible corrected number and to state openly that it cannot be fully trusted.

These download figures should be understood as a floor rather than a ceiling. Several large channels fall outside the count entirely: most Linux users obtain LibreOffice through their distributions, installations from the Microsoft Store and the Mac App Store are not recorded, and the new Windows update mechanism means that a user may download the software once and subsequently update it without generating a further download. Actual usage is therefore considerably higher than the download total alone suggests.

Viewed month by month, downloads remained consistently strong throughout the year, with 2025 ahead of both 2023 and 2024 in most months. The pattern shows no single dominant spike but rather a sustained level of demand, consistent with LibreOffice’s established position rather than a one-off event.

The update page offers a complementary perspective. It recorded 581,615,673 visits during the year — a figure that, while not deduplicated, gives a sense of the scale of the active user community. On a conservative basis, the Foundation estimates the LibreOffice user base at around 100 million, with a substantial further number of occasional users. A higher reading is also defensible: at a ratio of roughly one user for every three to four update-page visits, the active community would fall between 140 and 180 million.

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

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…

LibreOffice Conference

The LibreOffice Conference was the annual get-together of the worldwide LibreOffice community, bringing together developers, contributors, and users. The 2025 event was held in Budapest, Hungary, from September 3 to 5, and was preceded by a community session.

The main conference featured 53 sessions spread over three days. It kicked off with a welcome and housekeeping session, followed by an opening speech from Eliane Domingos from TDF’s Board of Directors, and a welcome speech from the university that hosted the event.

After that, the talks began across several different tracks, including the Open Document Format, advocacy and marketing, development and extensions, UX and design, and more. The full list of talks can be found on https://events.documentfoundation.org/libreoffice-conference-2025/schedule/. There was also a notable talk from the Austrian military (Bundesheer) about their migration to LibreOffice and the new features they funded.

The event finished on Friday with a lightning talks session, followed by the closing address and a celebration for the 15th anniversary of LibreOffice. But the conference was more than just talks: there was a community dinner as well.

Now the community is looking forward to 2026’s LibreOffice Conference. The event will take place in Pordenone, northern Italy, from September 10 to 12, and the Call for Papers is currently open.

In addition to the main LibreOffice Conference, there was the LibreOffice Asia Conference 2025, which took place in Tokyo, Japan, from December 13 – 14. Speakers and guests from around the world discussed topics specific to Asian communities, such as complex text layout (CTL) and CJK (Chinese, Japanese, Korean) language support, and marketing LibreOffice in specific countries.

There was also the sixth edition of the Latin American LibreOffice Congress, held in Habana, Cuba, from October 6 to 9. LibreOffice project activities was concentrated on the opening day, October 6, and in the special session “LibreOffice Congress and Technological Sovereignty”, on the 8th. With the remaining days available, the organisers articulated a parallel agenda of activities, with visits and strategic meetings with managers and professionals from governmental and community areas.

TDF at External Events

Throughout 2025, members of The Document Foundation and the LibreOffice community attended many other events around the world. The first big event was FOSDEM, held in Brussels in early February – the biggest meetup of free and open source software developers in Europe. As usual, the LibreOffice community was present with a stand, merchandise, stickers, flyers, clothing and more. Attendees came by to talk about the project, report issues and make suggestions.

In late April, the Augsburger Linux-Infotag 2025 event took place in southern Germany, and LibreOffice was present with a stand and merchandise. Another German event was the Univention Summit 2025: it took place on January 23 and 24 in Bremen, and the LibreOffice project was present and met with the people overseeing the migration to LibreOffice in the northern German state of Schleswig-Holstein.

Italian community members attended the Linux Arena event from April 25 – 27 in Pordenone. They had a LibreOffice stand with a 32″ monitor, showing an Impress presentation about LibreOffice on a loop. At the stand they met different interested people – some of whom they already know since they visit the fair regularly, while others they saw for the first time. There was curiosity about LibreOffice, and this time the stand personal noticed an increasing demand about AI integration and related plugins. The LibreOffice coffee/beer mats were very much appreciated by visitors to the stand.

Later in the year, Community members in Nepal tuned in to an online call and turned Software Freedom Day 2025 into a success. Birendra Open Source Club – one of the student clubs and LibreOffice project contributors in Nepal, with support from Liaison Suraj Bhattarai and other key open source clubs, hopped onto Discord on 20 September.

On October 4 and 5, the LinuxDays 2025 event took place at the Faculty of Information Technology (Czech Technical University) in Prague. It combined stands for free and open source software projects with workshops and talks, and the Czech-speaking LibreOffice community was there.

Members of the Indian LibreOffice community celebrated Document Freedom Day in Noida on 29 March. The event featured a few talks on free software such as OpenStreetMap, Prav and KDE, and also a lawyer told attendees how they manage all their clients’ data with free software and keeping their privacy in mind. LibreOffice merchandise was distributed at the sticker table.

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

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

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

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

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

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

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

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

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

🐛 Bug Fixes & Minor Changes

• Increased max article download size to 3 MB from 1 MB (#1164) by @spacecowboy in #1164
• Restored scroll position indicator in the article reader (#1165) by @mvanhorn in #1165

🌐 Translations

• Updated Tamil translation using Weblate in commit
• Updated Czech translation using Weblate in commit
• Updated Latvian translation using Weblate by @Coool in commit
• Updated Italian translation using Weblate by @Wiccio in #1159

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.

🚀 Features

• Use feed entry id as fallback link. (#1144) by @fictiontoreality in #1144
• Upgraded export format so saved articles can be imported again (#1131) by @edd255 in #1131
• Added on-device local as an option for translation (#1143) by @JaredTweed in #1143

🐛 Bug Fixes & Minor Changes

• Widget stuck in loading (#1137) by @MatthewTighe in #1137
• Corrected three sync read-status bugs (#1141) by @spacecowboy in #1141
• Resolved flaky test caused by identical generated pubDates for undated feed items (#1146) by @spacecowboy in #1146
• Corrected defaults causing AI translation appear enabled on upgrade (#1153) by @spacecowboy in #1153
• Prevented OOM crash when fetching or rendering large articles (#1154) by @spacecowboy in #1154

🚜 Refactoring

• Cleaned up sync read-status layer (#1142) by @spacecowboy in #1142

📚 Documentation

• Added logging conventions to AGENTS.md (#1148) by @spacecowboy in #1148

🌐 Translations

• Updated Chinese (Simplified Han script) translation using Weblate in commit
• Updated French translation using Weblate by @Matth7878 in commit
• Updated Czech translation using Weblate in commit
• Updated Latvian translation using Weblate by @Coool in commit
• Updated Polish translation using Weblate by @Aga-C in commit
• Updated German translation using Weblate in commit
• Updated Hungarian translation using Weblate by @summoner001 in commit
• Updated Estonian translation using Weblate in commit
• Updated Indonesian translation using Weblate by @arifpedia in commit
• Updated Serbian translation using Weblate by @eevan78 in commit
• Updated Spanish translation using Weblate in commit
• Updated Ukrainian translation using Weblate in commit

❤️ New Contributors

• @arifpedia made their first contribution
• @edd255 made their first contribution in #1131
• @fictiontoreality made their first contribution in #1144

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.

GIMP is Free and Libre Open Source Software, but none of it is possible without the people who create with and contribute to it. Our project maintainer Jehan wanted to interview the volunteers who make GIMP what it is, and share their stories so you can learn more about the awesome people behind GIMP!

Early interviews with co-maintainer Michael Natterer and Michael Schumacher were published shortly after the first Wilber Week. Unfortunately, the rest of the interviews from that event have never seen the light of day - until now!

Our previously resurfaced interview was with Simon Budig. The interview in this article is about Øyvind Kolås. He is the maintainer of GEGL and babl, the color engines of GIMP. His work was instrumental in (among many other things) the long-waited non-destructive filters implemented in GIMP 3.0!

This interview took place on February 4th, 2017. In addition to Jehan and Øyvind, Michael Schumacher, Simon Budig, and Debarshi Ray were also involved and asked questions.

Jehan: Okay, hello Pippin! So, first off, how should we call you, Pippin or Øyvind?

Øyvind: If people know how to pronounce ‘Øyvind’, that is perhaps easiest. In some contexts it is a difficult name to pronounce and I have to go by my nickname Pippin.

Jehan: Ah, and where does it come from?

Øyvind: The nickname Pippin originates from Lord of the Rings. The first time I went on IRC, must have been ‘95 or ‘96, I had to come up with a nickname for myself, and I chose the nickname of a hobbit. I used the nickname “Sméagol”.

Jehan: But you’re not very small.

Øyvind: No, but Sméagol is the hobbit in terms of Gollum, and I kind of decided that I didn’t want to have the association that came along with that hobbit. So after just one day of using that nickname I skimmed a little bit through the history of the Lord of the Rings again, and noticed that the “Pippin” hobbit might be more appropriate. He’s a hobbit that’s a little bit too curious – he throws stones in Morannon and stares into Saruman’s palantír and wonders how things work.

Jehan: So, how many times have you read Lord of the Rings?

Øyvind: Two or three times? I’ve seen the movies more than once.

Jehan: How are the movies?

Øyvind: They’re okay. They’re long!

Jehan: So, you’re the GEGL maintainer. Maybe first, let’s explain what GEGL is. For people who read the website, they may know GIMP, maybe not necessarily GEGL.

Øyvind: GEGL is a library or system where you can plug components together. You can create chains of image manipulation filters or operations. So you can first adjust the colors of an image, and then apply some sharpening to it. So you can construct those as a flow chart or similar – “First do this then do that, then do that” – so programmers can create data structures representing such chains or flows of image data, and developers can use such components to use in the chain.

Jehan: And so how did you come into this project?

Øyvind: I had been using GIMP for quite a while, and then at some point I was experimenting with writing my own video editor. And I started implementing various transform tools and operations – I implemented perspective rotation tools and similar. And while I was doing that, I was also taking a look at how GIMP was doing some such transformation tools and operations. And I realized that the perspective transform in GIMP produced not quite the results that I would like it to produce.

It had big problems with moire and aliasing when you did severe perspective transforms, for instance. So with my newly gained knowledge of making something similar myself, I sat down and tried to figure out how to improve what GIMP was doing. So I made a patch fix to add adaptive subdivision super-sampling to the transform tools.

Jehan: So it was not GEGL?

Øyvind: It was for GIMP. That’s how I got involved in the GIMP project, it was my first patch that I did there. But even that was after I had ran into many of the people from the GIMP project at a GNOME conference in Copenhagen in, I believe, 2001.

Jehan: Okay. So, how does GEGL change GIMP? What is GEGL for GIMP?

Øyvind: Well, I’m the wrong person to ask that question. I know how GEGL works. I know many of the needs of GIMP. But the person who has the greatest knowledge and detail of how GEGL makes that work and happen for GIMP is Mitch.

Jehan: We should have asked him yesterday then! Thank you. So, maybe you can still explain some of the cool features in GIMP. Like what everyone has been talking about, such as non-destructive editing, which is enabled by GEGL?

Øyvind: So this graph-based data-flow chains of operations that you can do with GEGL – most parts of GIMP have been transformed to make use of that. The core thing that is currently non-destructive editing in GIMP is the layers dialog. Other software has more capabilities there, but it’s not easy for us to know what interface to provide and present to the user to add such capabilities as drop shadows, or blurs, or color adjustments.

Jehan: It’s easy or not easy?

Øyvind: It’s easy to do it as a hack or as a proof of concept, but it’s more difficult to figure out how to do it in a way we can guarantee will be stable for many years into the future. So where we are currently, as we are close to being able to release GIMP 2.10 is that we’re doing all the layer processing that GIMP 2.8 use to do, but there’s no hacks – we’re using GEGL as the engine instead.

Jehan: So, do you use GIMP a lot?

Øyvind: Sometimes GIMP is the appropriate tool, and sometimes there’s other existing software that I use as a tool. And sometimes the tools I want or need don’t exist, and then I try to make those tools.

Jehan: You also have a background as an artist. Could you maybe speak on this?

Øyvind: From when I was a teenager, I’ve been doing both visual arts such as painting and drawing, and being interested in creating media in various forms such as videos. The only form of creative expression that I haven’t much played with is music. My original education and training was in fine arts. Only after having done that for a few years did I go back to computers and digital media, and go more the academic route in computer science.

Jehan: So you studied computer science before, then you went to art?

Øyvind: No, but I’ve been doing computer graphics since I was 14 or 15 years old. I was inspired by the demoscene community and having access to dial-up bulletin boards systems with people discussing programming techniques and languages. They contained tutorials in C and Pascal and Assembly and also involving Turbo Pascal. Demoscene-style graphics are things I’ve done since before University level age, along with experimenting with painting and traditional physical drawing media.

Jehan: So how do you see the future of GEGL and free software graphics in general? How do you see GEGL in 20 years?

Øyvind: If GIMP still exists in 20 years in some form of UI, then most probably GEGL is part of that story as well. I hope that some of the existing core processing code actually doesn’t survive! But the idea of the graph and maybe some of the operations that are hooked up to each other, I hope that continues to exist. Just like how other applications that use GEGL like video editing software, GIMP, GNOME Photos – the API and how they do that, I hope are very similar. But maybe both the CPU based processing code and the OpenCL one, will have been replaced.

Jehan: There’s something I’ve never really completely understood. If you look at the GitLab of GIMP and GEGL, they started around the same time. So why are they getting merged only recently?

Øyvind: I only know stories of this – I haven’t been around in the project since in the beginning.

Michael Schumacher: You said you’re not the best person to ask how GIMP is using GEGL. So can you tell us how you wish it was being used, or how you think it could be used more? Because I recall you making comments on IRC in that regard.

Øyvind: Well, we are close in 2.10 to a state where I am happy about how things are at the moment. It’s been a while since I was unhappy about how GIMP’s projection was driving the layer compositing code or creating a graph for compositing with GEGL – it’s been a long while since it was fixed. So when it comes to the performance of doing those things, or the performance on-canvas preview of vectors, the current problems are more in GEGL land than GIMP land.

Jehan: In GEGL?

Øyvind: Yes, it’s an architectural puzzle to figure out, before GIMP should change how it does its rendering to make use of the new capabilities in GEGL.

Jehan: So how fast can GEGL go? How fast do you think (compared to now) it can improve?

Øyvind: I think for most filters in common use for photo manipulations as well as working with multiple layers, that even on a CPU that you should have 10 frames per seconds updates on dragging layers around as well as doing color adjustment to the photos or the individual layers. I don’t see why that should be a big problem. That is what solving the mip-mapping problem should provide.

Debarshi Ray: Any plans for what you want to use for GEGL’s API documentation? It used to use kind of like GTKDoc at some point. There’s always the website, but any plans?

Øyvind: It currently displays a GObject introspection repository data directly on the website using Javascript. I kind of hope that the documentation people start working towards more documentation on GObject introspection and perhaps we align with something they do, if they do something like that.

Jehan: Do you want to see GEGL in more software, not only GIMP?

Øyvind: That would be really nice because if people then create more filters and interesting things you can do in that software, it becomes available in GIMP and also in other software.

Jehan: Actually that’s very interesting. Can you explain a little about the architecture of GEGL which makes it so that its filters can be available everywhere? How it will work in other software that integrates GEGL?

Øyvind: Well, you could imagine that for the operations you have in GIMP in terms of filters, there are many that you invoke for an image, that could be something that also you could apply as an effect in a video editor to a clip. You can animate some of the properties over time, like increasing or decreasing the blur on some background that you composite something on top of.

Michael Schumacher: What would you suggest people should do to learn about the capabilities of GEGL and how to use it, either in GIMP development or in their own software?

Øyvind: Mostly, study what already exists, and if there is anything doing something similar to what they want already, then try to tweak that to do something new.

Michael Schumacher: Do you have a suggestion on what someone can use to play around with GEGL? For instance, if someone has fairly decent experience developing software, is there some kind of best approach like “Oh, use Python”?

Øyvind: I haven’t really tried to use any of the language bindings apart from C in a long while. I can see how approaching a library framework with C can be difficult for some users. But no, I don’t know of any of these integrated languages that have a very good integration.

Simon Budig: I think that the first start would be to use the GEGL command line tool and build trees in XML or something like that.

Øyvind: I guess there’s also the data formats, the XML and JSON based data formats, as well as the data format you can fully construct on the command line just chaining operations and properties.

Debarshi Ray: Can you comment on how GEGL compares to GStreamer, since they are both graph based and you can even do some image manipulation with GStreamer like their application does? Would it be easier with GEGL?

Øyvind: GEGL is focused on rendering and creating images. GStreamer is focused on playback and streaming of video. So the things passed around between the components of the graph of GStreamer are always full frames of videos. And it has many considerations for how to deal with playback and pre-feeding data to be able to stay in continuous playback and similar. Whereas GEGL has only a concern about generating pixels for a static graph.

So the concerns involved in piecing together video codecs and the muxing of codecs and doing those things in a data flow, are different from doing just image processing with it – but kind of the core idea, which is visual programming using a graph instead of more like a human language with abstract syntax to create, is shared between GEGL and GStreamer. The data flow based approach and creating a framework for visual components and ordering.

Jehan: I have a similar question. There was an efficiency test – I think the product name was libvips – with various graphics software library, and GEGL was in the list. In the tests they said it was worse.

Øyvind: Maybe that has improved recently, I’m not sure. Both GEGL and babl have had a traditional approach to bench-marking at runtime when things are already up and running and for interactive use. Whereas those benchmarks are based on equating command-line utilities with those that also include all the overhead of start-up. That is something that has improved recently in both, particularly in babl – it keeps measurement and profiling information from previous runs around in a file on disk so it can load, so it doesn’t have to do a lot of computations the first time you do a computation of a particular kind.

But I haven’t really re-run those benchmarks lately. But a lot of the trouble involved for GEGL and babl is that they’re very generic and have many plug-ins and do loads of file system access and those things before it can do any form of processing.

Jehan: Have you tried this libvips library?

Øyvind: Yes.

Jehan: How does it compare – not efficiency wise, but API, architecture? Why would one choose GEGL over libvips?

Øyvind: That I don’t know. Depends on the capabilities of what you need it to do, GEGL is well on the way to have most traditional GIMP filters as operations. I haven’t studied the actual program APIs and how you would rig up pipelines with those APIs. I looked more at the graphical user interface of libvips – it’s an Excel spreadsheet-like approach to it, where you refer to data in a different cell. It’s one way of expressing a graph but I don’t know the actual programmatic APIs.

Jehan: So there’s different ways of expressing graphs?

Øyvind: GEGL’s API for expressing and manipulating the graphs is loosely based on the W3C’s Document Object Model and hierarchical tree structures. I have no idea if or what type of API inspirations that libvips is using.

Debarshi Ray: I have a question. GIMP has a new website, shiny and everything. Will GEGL have a new website as well?

Jehan: It has to be shiny!

Øyvind: Do you have a PNG file called “Shiny” that we can use? Or do you also have some CSS and some pages and content for the GEGL website?

Debarshi Ray: No, I have nothing.

Øyvind: I have tried for the last two or three years to make some existing GIMP and GEGL contributors excited about writing some documentation and content as part of the website. They do rebuild the website every single time they build GEGL and it ends up in the docs folder of the website. But it seems like it’s actually easier to get people to contribute code and new operations and exciting new features in GIMP and things than to get them to improve the website documentation.

And I must admit that I’d rather fix bugs and performance and features than spend too much time on the website.

Jehan: So, unless anyone has another question, we can finish…

Simon Budig: Did we talk about the Patreon?

Jehan: Oh right! So you’re trying to live off free software coding, especially GEGL. Can you try to explain it?

Øyvind: I spent a lot of time over the last ten years doing code for both GEGL and GIMP, but also many other projects. It is strange how the media exploration experiments I do in code seem to not really have much cultural worth in society. So creating software and creating tools is not something that seems to be on the culture budget of any Western European country or something that would be considered part of improving the digital literacy of the population. It’s something that’s left up to private companies to maybe create software tools – but it’s not something that you’ll find on the budget of a country, that they want to let people improve and create tools for, say, image manipulation.

Maybe that’s a horrible way to start out to explain this.

Jehan: You can start over if you want.

Øyvind: I’ve been playing with creative expression in both visual media and in code for a couple of decades. I have made music videos, I’ve made short films, I’ve made paintings and I’ve made software. And sometimes when I make software, I get paid for it because there’s other business interests behind wanting it to exist. But I consider many of the contributions I’ve made to GIMP and GEGL to be valuable contributions, and that it would be good if I could do more of that type of experiments that end up in actual software – but also freely be able to do my own research and find out how it is possible to do a certain thing with videos or images or other ways that you can combine digital media types.

I’ve been fortunate enough to have had a software development job where I made a bit of money and had a safety cushion. So I’ve been living off savings for quite a while, creating software for GIMP and other things while traveling. But lately I’ve seen that my bank account has started screaming and turning red soon. So I was wondering, maybe this Patreon thing that I’ve seen both other software projects and other types of things suggested that I could try to keep bills paid. And I decided that okay, in some sense it’s asking for money and a little bit begging to be like a street music performer and saying “I’m making this thing and if you’re enjoying it, maybe you’d like me to continue doing some of the things I’m already doing”.

And it turns out there are a couple hundred people already who would like me to continue writing code and sharing it publicly and openly. That at least sustains me roughly on the level of unemployment benefits in European countries. And I hope that this will even slightly increase – I will not have a Silicon Valley level software developer salary, but I’ll have enough money to cover my expenses.

Øyvind’s portfolio website

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!