It has become a commonplace to describe the Microsoft 365 Ribbon as the finest office interface available — the most polished to look at and the most ergonomic to use. The claim is repeated so often that it tends to pass unexamined. It deserves examining, because hidden inside it is an assumption that quietly does most of the work: the idea that there exists a single best interface at all.

A competent design — for one kind of user

Let us begin by granting what is true. The Ribbon is a capable piece of design. It was built to help an occasional or intermediate user discover features by browsing rather than by memorising, and for that user it does its job well. Saying so is not a concession wrung out reluctantly; it is simply accurate, and any honest discussion should start there.

But “well-designed for a particular user” is not the same thing as “best interface,” and treating the two as equivalent is where the reasoning slips. An interface optimised for one persona is, by construction, less suited to the others: the power user who works from the keyboard and resents losing vertical screen space, the migrating user carrying twenty years of muscle memory, the user who depends on assistive technology, the user on a small or low-resolution display. A single fixed layout cannot be best for all of them at once. It can only be best for some, at the expense of the rest.

Ergonomics is a trade-off, not a verdict

The same applies to the ergonomic claim, only more sharply, because ergonomics is something one measures rather than asserts. The research on interface efficiency is consistent on one point: how well an interface performs depends on the task, its frequency, and the expertise of the person doing it. Discoverability and raw throughput pull in opposite directions. An interface that makes features easy to find for a newcomer is rarely the one that lets an expert move fastest, and the reverse is equally true.

So the Ribbon makes a trade. It spends vertical screen space and a measure of expert speed to buy browsability for the less frequent user. That is a perfectly reasonable bargain — for the people it was struck on behalf of. Calling it “the best ergonomics,” though, simply declines to name what was given up to get there. There is no free lunch in interface design; there is only a choice about who pays.

The real question: who decides?

This brings us to the point that actually matters. When a product ships a single interface, it has made the ergonomic decision on the user’s behalf and removed it from their hands. The trade-off still exists — it has merely been settled by someone else, once, for everyone.

LibreOffice takes the opposite path. It offers the traditional menu-and-toolbar layout, the Tabbed interface, Tabbed Compact, the Groupedbar, a Sidebar, and a Single Toolbar mode, and it lets each user choose the one that fits their work, their hardware, and their …

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 …

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 …

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 …

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 …

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 …

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 …

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.

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 …