The past, present and future of office suites

Summary

The office suite market is large, profitable and growing, and this attracts new entrants: low-cost clones, open-core products and, more recently, suites built largely with artificial intelligence. Most of them compete on price and on native support for OOXML, a format whose evolution remains in practice under Microsoft’s control.

When features can be reproduced cheaply, what distinguishes a suite is who governs the document format and the software, and therefore who controls the content. This is the question of digital sovereignty, and its outcome will depend partly on political decisions, and partly on software features.

The 1980s and 1990s

The office suite sector emerged in the 1980s and developed in the 1990s, when Microsoft Office established itself as the leading product, with a market share of over 90% according to Microsoft unofficial statements at their events.

Some may remember the main competitors: Lotus SmartSuite, WordPerfect Office and StarOffice, the ancestor of OpenOffice and LibreOffice. Fewer will recall Anywhere Office, Ability Office, Pro PC Suite 2001 and ThinkFree Office. Ability Office still exists, and ThinkFree Office is now called Hancom Office.

By the end of the century Microsoft Office dominated the sector, while all other products had a barely noticeable market share or had disappeared altogether.

The sector has always been lucrative: the products meet a universal need, while development and sales costs are low relative to volumes, so margins are potentially extremely high. For this reason all the major software vendors tried to enter the market, and the first clones emerged, competing solely on price.

Market presence, however, was just one of the factors contributing to success. Other factors were bundling with the Windows operating system, lock-in through document formats and pricing.

The two decades between 2000 and 2020

Sun Microsystems, which had acquired StarOffice, released its source code in 2000, and OpenOffice.org 1.0 followed in 2002: the first FOSS suite to reach a mass audience. Version 1.0 offered only a glimpse of the suite’s potential, and version 1.1 was usable but still limited. Only version 2.0, released in 2005, made OpenOffice a genuine competitor to the market leader.

For several years the rivalry between the proprietary suite and the FOSS suite played out on two fronts: large migration projects and document formats.

At the time, migrations seemed to signal an irreversible trend, but this proved an illusion. Microsoft deployed all its commercial muscles and started to talk to politicians. Since 2012, the company has been one of the biggest spenders on lobbying in Brussels (based on data from Corporate Europe Observatory and Lobby Facts).

The battle over file formats was most prominent between 2006, when ODF was standardised by ISO/IEC, and 2008, when the proprietary OOXML format was standardised through a process we have already described in a previous blog post and will not revisit here.

In 2010, following Oracle’s acquisition of Sun, the community created The Document Foundation and LibreOffice. In 2011, Oracle was effectively forced to donate the OpenOffice.org source code to the Apache Software Foundation in order to honour a contract – due to expire in 2014 – that IBM had signed with Sun Microsystems, and which allowed it to use the OpenOffice.org source code whilst disregarding the open-source licence.

The format battle then faded into the background, as IBM decided to abandon the ODF advocacy project at OASIS to use the money to fund the development of Apache OpenOffice and fight the growth of LibreOffice. It resurfaced in 2024 with the concept of digital sovereignty and the announcement of several large scale migrations to open source software, such as the German province of Schleswig-Holstein and the Austrian Army.

Between 2010 and 2020 the sector also evolved with the arrival of cloud-based suites, which started a new battle for market share between Microsoft and Google. Given the sector’s renewed growth, a new generation of clones emerged: programs that are almost always limited in functionality, copy the market leader and compete on licence cost.

Some of these clones, in order to disguise their commercial operation, release a basic version under an open-source licence, often modified so as to prevent forking. Such a licence no longer meets the Open Source Definition, and the product is in practice freeware, while the full-featured version is sold separately (the “open core” model).

Naturally, these programs support the OOXML format natively, because they aim at a low-cost replacement, not at migration, that is, a paradigm shift that would give users full control over the software and its content.

By digital sovereignty we mean the ability of a user or institution to control its documents and software: to open documents with any implementation, to fork the code, and to choose where data is hosted and who operates the service.

OOXML is formally an ISO standard, but its reference implementation remain with Microsoft. As long as this is the case, Microsoft retains control over the content: the user saves money, but sacrifices digital sovereignty.

The current situation

The reason for the renewed interest in the office suite market lies in the size of the market itself, which is worth tens of billions of dollars and therefore whets the appetite of software companies. Even a 1% market share is worth a very significant sum, sufficient to justify the investment.

As a reference point, we use public data from the “Office Productivity Software Market Report 2026” by Business Research Company, a US-based market analysis firm. The office productivity software market reached $50.73 billion in 2025 and is expected to grow to $81.83 billion by 2030, at a CAGR (compound annual growth rate) of 10.1%.

We add some figures relating to Microsoft and Google.

Microsoft 365 Commercial generated $102 billion in fiscal year 2026, an increase of 16%. Paid licences for Microsoft 365 Copilot exceeded 30 million by the end of June 2026, which on analyst estimates is about 6 to 7% of the paid commercial user base.

Google Workspace is estimated to have over 3 billion users and over 11 million paying customers. The user figure includes free Gmail accounts, so it is not comparable to Microsoft’s paid subscriptions.
Technographic data from 6sense, another US-based market research firm, attributes 50.34% of the office productivity category to Google Workspace and 45.46% to Microsoft 365 (figures are based on corporate domains). Measured in corporate licences and revenue, Microsoft is clearly in the lead.

According to 6sense, 64% of organisations use both suites. This figure is only indicative, but it points to an increasingly widespread overlap between office suites, which is not limited to Microsoft 365 and Google Workspace. For LibreOffice, based on hands-on experience with large organizations, we estimate that 50% of users also use another office suite, depending on their needs.

We are therefore talking about a market of enormous economic value, and these figures refer almost exclusively to licences, not to the ecosystem. If we include value added consultancy services, which are a necessary component of every implementation in public bodies and companies, the total is likely to be significantly higher.

Analysts do not provide precise data on this, so we rely on a rough estimate based on experience: value-added services are worth about 25% of the value of licences. On the analysts’ forecast, the 2030 market would then be worth about $102 billion ($81.83 billion plus 25%). One percentage point of market share is therefore worth $1 billion a year to a commercial vendor.

This figure does not accrue to free software, but it explains the incentive for new entrants. It also explains the emergence of a new type of office suite: so-called “clones” developed largely with artificial intelligence.
At present we remain extremely cautious about the use of artificial intelligence in software development, but we recognise that views differ, and we are monitoring the evolution of these applications closely.

The strategic consequence does not depend on that debate: if the cost of reproducing a feature set collapses, features stop being the main barrier to entry. What remains is the governance of the format and of the code, the strength of the community, and the long-term maintenance of the software.

A glimpse into the future of office suites

Over the last twenty years we have read contradictory forecasts: the total disappearance of the sector, or only of the desktop suite, and the opposite, a strong growth driven by announcements of new operating systems, software paradigms or hardware platforms.

One thing is certain: the office suite market has gone through periods of slight contraction, probably normal fluctuations, but overall it has grown, and in our opinion it will continue growing for the foreseeable future.

Today, the installed base consists of around 2 billion desktop and laptop computers, based on active devices reported by manufacturers, plus devices that nobody counts because they are second- or third-hand, found mainly in poorer countries that are overlooked by technology usage statistics.

The integration of AI assistants into the suites adds a further dimension. With more than 30 million paid Copilot seats, Microsoft has shown that there is a market for it.

Overall, this is an extremely interesting potential market, where there is room for all types of office suites, desktop and cloud-based, and for all development strategies. On the other hand, success is not just related to number of users as there are market dynamics which depend on political decisions that go beyond the value of the software itself.

However, the location where documents are processed – whether locally or in a provider’s cloud – and the ability of artificial intelligence tools to read and write in open formats remain issues linked to the question of sovereignty. We have already expressed our views on these matters in several blog posts: nothing should interfere with the user’s right to decide on their own content.

LibreOffice will continue to be a key player. Downloads and donations grew substantially in 2026 (as of 31 October, downloads +26% and donations +44 in term of numbers), which reflects a steady improvement in the quality of the software and in the reputation of the project.

The practical conclusion is that LibreOffice and ODF compete on a different axis from the clones: not feature parity at a lower price, but open governance of the format and of the code.

FOSDEM: FOSS Office DevRoom Call for Papers

LibreOffice at FOSDEM

We are inviting proposals for talks about “FOSS Office Software and Suites“.

Office productivity software is one of the oldest and most interesting FOSS categories packed with developer interest. It is also an area where lots of new solutions are arriving with new desktop, web-based and mobile editors, as well as new underlying libraries and filters appearing. These bring lots of opportunities for meeting up and cross-fertilization of ideas, and innovation as well as code sharing between separate FOSS communities and companies that can rarely come together.

The FOSS Office devroom brings these projects together in one place. It is open to developers, contributors, integrators, and users of any FOSS office suite or component. Competing projects and document toolkits are explicitly welcome, as the aim is to provide an overview of the entire sector and identify common problems which cannot be solved alone.

We invite talks on topics such as:

– Architecture, performance, algorithms, data-structures;
– Network protocols for real-time collaboration;
– Import and export filters, interoperability, and document rendering fidelity;
– Accessibility, localisation, typography and support for complex scripts;
– Technical challenges of enterprise Office deployments
– AI-assisted features and how to integrate them while preserving user control and privacy;
– Security, code quality, hardening and sandboxing challenges;

Talks should be technical, and mention bits, bytes, data-structures and algorithms. Product pitches and business presentations will not be accepted in this room. The devroom is co-organised by people from a handful of different FOSS Office projects to ensure a balanced selection of talks. Talks will be 15/20 minutes maximum, to fit as many as possible in the limited time slots.

TALK SUBMISSIONS

To submit a talk, please visit the FOSDEM 2027 Pretalx website: fosdem.org/submit. Please select “FOSS Office” as the *track* and ensure you include all the requested information when submitting a proposal: the title of the talk, a short abstract (one / two paragraphs), and some information about yourself (name, bio and photo). Please do remember that your profile might be already stored in Pretalx.

If you already have a Pretalx account from previous years, please reuse it. Create an account if, and only if, you don’t have one from a previous year. If you have issues with Pretalx, please contact italo at documentfoundation.org for help.

All presentations will be recorded and streamed. Sending your proposal implies giving permission to be recorded.

For accepted talks, speakers will receive an email to confirm that the proposal has been accepted. They may expect additional emails with more instructions, for instance to confirm their travel schedule.

CONTACTS

Italo Vignoli: italo at documentfoundation dot org
Jos Portvliet: jos dot poortvliet at nextcloud dot com
Michael Meeks: michael dot meeks at collabora dot com

IMPORTANT DATES TO REMEMBER

Submission Deadline: 30 November 2026 (23:59 UTC)
Acceptance Notifications: 4 December 2026
Final Schedule Announcement: 7 December 2026
Devroom: 30 January 2027 (from 10:30, just half day)

Welcome Tamás Zolnai, new LibreOffice Online developer

Photo of Tamás Zolnai

Tell us a bit about yourself!

I’m a software engineer from Hungary. I’ve been working in software engineering for more than a decade, with a background in both computer science and psychology.

I’ve been a long-time contributor to LibreOffice, mainly working on Writer and Impress, and I’ve also contributed to Collabora Online as part of the Collabora team. Throughout my career, I’ve always placed a strong emphasis on the quality of my work and on building things properly, even when that sometimes meant pushing back against management priorities.

Outside of software development, my current project is setting up my own camper van, intending to eventually explore Europe with it. I’m looking forward to combining some travel with my work on open source projects.

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

My new role at The Document Foundation is to participate in building LibreOffice Online. We are basically trying to create a Google Drive or Google Docs-like solution on top of LibreOffice as a document editor, and bring LibreOffice into the cloud. Currently, I’m doing some research into existing cloud infrastructures to identify best practices and avoid the same problems that other projects have encountered during the lifetime of their cloud implementations.

More details about the development strategy can be found in this post.

How can users of LibreOffice help you in this work?

Well, we’re still in the design phase, so there isn’t much room for involvement at this point. At some point, once we have the initial versions LibreOffice Online, feedback would be very much appreciated. We will post updates here on the blog.

LibreOffice 26.8 and interoperability: preserving what cannot yet be read

LibreOffice 26.8 adds basic support for importing and exporting a range of chart types that Microsoft Office includes in OOXML files: box-and-whisker, funnel, Pareto, radial, treemap and waterfall charts. LibreOffice is unable to display or edit these charts, but it does recognise them, informs the user that the chart type is not yet supported, preserves the underlying definition unchanged, and rewrites it when the file is saved.

At first glance, this appears to be an admission of incompleteness, whereas it is actually an example of what implementing a proprietary format entails when the aim is interoperability – for the benefit of users, rather than a commercial strategy that treats users as mere tools.

What happened

Microsoft added these chart types to Office from 2016 onwards, storing them in a namespace generally referred to as ‘chartex’. The namespace is not part of the ISO/IEC 29500 text approved as an international standard, but is documented separately in Microsoft’s extension documentation.

This is entirely legal and perfectly normal commercial behaviour: a vendor improves its product and the file format evolves accordingly. The consequence, however, is that the format in everyday use is no longer the one that was standardised. The ISO number continues to be cited in tender documents and policy documents, but the files being exchanged are different.

For any implementer other than the vendor, this creates a permanent state of delay. This is not a one-off gap to be bridged with sufficient effort, but a structural delay, as the specifications are in the hands of a vendor that does not publish its release schedule, with priorities defined according to commercial criteria.

Three possible responses

An office suite that encounters a chart it does not recognise has three options:

  1. It can reject the file. This is an honest but pointless solution: the user is left with a document they cannot open and concludes that the software does not work.
  2. It can discard what it does not understand. The file opens, the chart disappears, and the user only realises this when the document is forwarded to a colleague and the chart is no longer present. This is the most damaging outcome, as the loss occurs silently and the blame falls on whoever opened the file last.
  3. They can retain what they are unable to display. The user is informed that this type of chart is not supported, so they see a placeholder rather than a blank space, and the underlying definition remains intact when the document is transferred from one application to another. The document is restored in full when returned to the source application.

LibreOffice 26.8 adopts the third option, the only one of the three that respects the fact that the document belongs to the user rather than to the software – or, indeed, to the company that develops the software.

Unfortunately, there is a limitation, and this is an exception. Charts with regional maps contain extensive geographical information that LibreOffice is unable to preserve. The chart type survives the import-export cycle, but very little of its content remains intact.

Why this is important beyond charts

The Chartex case is of limited scope. The model, however, is not.

All organisations whose documents are written in a format controlled by a single vendor accept a dependency they are unable to manage, because the specifications may change without notice, with the addition of features that are only understood by a single implementation.

Nothing untoward needs to happen for the organisation’s archives to become progressively more difficult to read by all other software.

The Open Document Format is not immune to change, but it changes differently. Revisions are proposed, discussed and approved by a technical committee at OASIS, whose work is public, and are published as version specifications that anyone is free to implement.

An implementer wishing to support ODF 1.4 can read the ODF 1.4 specification and put it into practice. This is the only difference, and it is sufficient.

The bidirectional preservation of unsupported features is what distinguishes a responsible implementation under current conditions, but it does not constitute an improvement on those conditions. LibreOffice is the only office suite to adopt this approach, in order to protect users and the content within their documents.

Yes, no AI is now a feature

One of the comments on the announcement of LibreOffice 26.8 was a simple question: “So, no AI is now a feature?”

LibreOffice does not reject artificial intelligence out of hand, but an office suite used by tens of millions of people – in schools, hospitals, public bodies, law firms and thousands of other organisations – will not add a feature to its default configuration until that feature can be delivered under the conditions defined by the project in accordance with its principles.

User-controlled execution. The user must be able to choose where inference takes place: on the local computer, on an infrastructure directly controlled by the user, or on a service chosen independently by the user. A default setting that silently redirects to a single provider is not a choice.

No content may leave the computer without authorisation. The content of documents is a user’s asset and, in many implementations, is also legally protected material: medical records, case files, tender documents and student data. Transmission must be the result of a user’s decision and not behaviour carried out in the background by the application.

No telemetry of any kind. LibreOffice does not collect usage data, and this must also apply to AI features.

No dependence on a single provider. An integration that only works with a single company’s API is a lock-in mechanism, regardless of how it is described in the release notes. Interfaces should be open and implementable by multiple backends.

No compromises on format. Generated content must be in ODF format, just like any other content, and must retain its structure, styles and semantics. An assistant that generates documents in a proprietary format perpetuates content lock-in.

Entirely optional. It must be installable, removable, and absent from the user interface for those who do not wish to use it, including administrators deploying the software across thousands of workstations who, due to company policy, do not authorise its use.

Where we stand today

In light of this list, there is no integration that meets all the requirements and that could be deployed, enabled by default, and supported throughout the entire lifecycle of a release. This is an assessment of the current state of the technology and the solutions based on it, and not a judgement on the value of the sector.

In the meantime, users who wish to use AI features can install one of the available extensions, which can be found either on the LibreOffice extensions website or distributed independently. Most connect to a locally running model via Ollama, LM Studio or another OpenAI-compatible endpoint, which means the document never leaves the computer.

These are third-party extensions at various stages of maturity, developed and maintained by their respective authors rather than by The Document Foundation. Users and administrators should assess them as they would any third-party component, checking whether a cloud endpoint is configured and what the provider does with the data it receives. The extension mechanism offers AI functionality to those who want it, without any consequences for all other users.

Why our motivations are different

The reason our position differs from that of the dominant suites has almost nothing to do with the technology.

For a company that sells subscriptions, an AI assistant justifies a price increase and strengthens the case for keeping all documents within its own infrastructure. The functionality and the business model reinforce each other, so integration is not only attractive but almost mandatory.

The Document Foundation is a not-for-profit organisation. There are no subscription tiers to protect, no upsells, no data to monetise. This does not make us wiser than others, but it means we can take the time needed to decide whether something is genuinely useful for our users, as we are not driven by quarterly results.

What lies ahead

The criteria we have listed do not amount to a definitive rejection. The AI sector is evolving rapidly; on-premises inference is becoming manageable on standard hardware; and open models are improving much faster than most of us had anticipated. Should an approach emerge that meets all the conditions, we will evaluate it very carefully.

Until then, there will be no AI of any kind in the default installation; extensions will be available for those who wish to integrate AI features, and we will closely monitor where the technology is actually heading.

CISA Publishes Open Source Security Guidance: Verifiability Is the Difference

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