The fight over Euro-Office is really a fight over Europe’s documents

The Document Foundation’s attack on Euro-Office is not a routine open-source quarrel. It is a warning that Europe may be about to dress a familiar dependency in sovereign language. One day before Euro-Office’s scheduled public availability, the foundation behind LibreOffice disputed the project’s claim to be the “first European open-source office suite” and criticized what it says is Euro-Office’s choice to use Microsoft’s OOXML formats as the default. That dispute cuts into the core of the product’s promise. A European office suite does not become sovereign only because its code repository, hosting partners, and marketing language are European. It also has to decide who controls the documents it creates.

The timing made the criticism sharper. Euro-Office had been framed by its backers as a new European answer to Microsoft 365 and Google Workspace, with Nextcloud, IONOS, Eurostack, XWiki, OpenProject, Soverin, Abilian and BTactic among the companies attached to the initiative. Linuxiac reported on June 8, 2026, that The Document Foundation challenged the project before its public launch and argued that the claim overlooked OpenOffice.org and LibreOffice’s long European history.

Euro-Office’s own public materials describe a web-based collaborative office component built from an open-source fork of ONLYOFFICE, designed to integrate into platforms such as Nextcloud and to work with Microsoft and OpenDocument formats. Its GitHub organization calls the project “sovereign” and emphasizes open development, collaboration, and support for DOCX, PPTX, XLSX, PDF, ODT, ODS, ODP and TXT.

The Foundation’s answer is blunt: sovereignty built on Microsoft’s default file formats remains constrained by Microsoft’s document universe. In its June 8 open letter, The Document Foundation said Euro-Office was being marketed as the first open-source office suite developed in Europe, a framing it rejected by pointing to OpenOffice.org’s European roots and LibreOffice’s 2010 launch. It also argued that defaulting to OOXML aligns Euro-Office with the very lock-in pattern European digital-sovereignty projects usually claim to resist.

The dispute lands before the launch window

Euro-Office was not attacked after a failed rollout, a broken release, or a poor compatibility test. The criticism arrived before most users had a chance to form an opinion about the product. That matters because the argument is less about software quality on day one and more about what Euro-Office is trying to represent.

Nextcloud said in late May that Euro-Office’s first stable version would be ready for production on GitHub from June 9, 2026, alongside the Nextcloud Hub 26 Spring launch. It positioned the software as a collaborative editor for documents, spreadsheets, and presentations, available as an alternative to Collabora under Nextcloud Office and later through partner offerings such as IONOS Managed Nextcloud and XWiki.

That release framing put Euro-Office in a symbolic place before it had earned a product reputation. It was not introduced as just another online editor. It was introduced as a European sovereignty project in a market dominated by two American cloud productivity stacks and shaped by long-running public-sector discomfort with dependency on non-European providers.

The Document Foundation seized on that symbolism. Its criticism was not written like a bug report. It read like a challenge to legitimacy. The Foundation argued that a project using Microsoft’s file format family as the default cannot claim to be solving Europe’s office-suite dependency unless it gives equal or greater weight to ODF, the OpenDocument Format. The dispute is therefore about default power: which format receives the first save, the cleanest workflow, the best testing budget, the strongest user expectation, and the deepest institutional habit.

The launch-window timing also served a tactical purpose. Once a product enters procurement conversations, the public story hardens. Buyers start copying phrases from press releases into internal notes. Partners repeat positioning lines. Analysts place the project inside a category. If the phrase “first European open-source office suite” became attached to Euro-Office without challenge, the Foundation risked watching decades of European open-office history disappear from the current discussion.

This is the underappreciated part of the controversy. It is not only a dispute over credit. It is a fight over the archive of European open-source office work: StarOffice, OpenOffice.org, LibreOffice, Collabora Online, and public-sector ODF migration efforts. A new project can still be useful. It can still be needed. It can still earn adoption. But it cannot rewrite the origin story without drawing a response from the organizations that carried the older work.

Euro-Office has a real opening. The European market wants cloud-native collaboration that respects local law, data location, auditability, public procurement rules, and open-source governance. Microsoft 365 and Google Workspace are difficult to replace because they combine documents, identity, storage, mail, chat, meetings, admin tooling, and mobile access into products that users already know. Europe’s open-source ecosystem has pieces of that stack, but buyers often face integration work, feature gaps, and migration risk.

That is why a Nextcloud-centered online office effort matters. It could give European providers another integrated piece in a sovereign workplace stack. But the Foundation’s warning shows the standard by which such a project will be judged. The bar is not “less dependent than Microsoft 365.” The bar is whether the stack reduces dependency at the document layer, where decades of institutional memory live.

A European launch with a contested origin story

The phrase “first European open-source office suite” was always likely to provoke a reaction. Europe’s office-suite history did not begin with Euro-Office. It runs through German software company Star Division, Sun Microsystems’ acquisition of StarOffice, the creation of OpenOffice.org, the later LibreOffice fork, and the work of contributors who kept open document productivity tools alive through corporate ownership changes and community splits.

The Document Foundation’s open letter makes that history central. It says the first European open-source office suite was OpenOffice.org, which emerged from StarOffice’s source code, and that LibreOffice followed in 2010 after contributors created an independent foundation. LibreOffice’s own historical documentation records that Sun released StarOffice source code in October 2000, that OpenOffice.org 1.0 arrived in April 2002, and that The Document Foundation announced LibreOffice in September 2010 before releasing LibreOffice 3.3 in January 2011.

That history is not trivia. It shapes trust. Public administrations, universities, archives, courts, ministries, and regulated companies do not buy office suites only as applications. They buy them as long-lived document infrastructure. A claim about being “first” in that world signals institutional inheritance. It tells buyers that the project is not only new software but the beginning of a European category.

Euro-Office’s supporters may argue that the phrase refers to a different category: a modern European open-source collaborative suite built for the cloud, not a desktop office suite in the OpenOffice.org or LibreOffice tradition. That interpretation is plausible. Euro-Office is not simply trying to replicate LibreOffice Writer, Calc and Impress on the desktop. It is an online editor designed to sit inside groupware and collaboration platforms.

The problem is that marketing language often collapses such distinctions. “First European open-source office suite” reads broadly. Without qualification, it erases earlier projects that fit the phrase in ordinary language. If Euro-Office means “first European open-source web-based collaborative office suite based on this partner coalition,” it needs to say so. If it means “first European open-source office suite,” the claim is historically weak.

The launch partners also complicate the story. Euro-Office is backed by a visible European cloud and collaboration coalition, including Nextcloud and IONOS, with other open-source and hosting companies attached. Nextcloud’s March announcement described the initiative as a response to a gap in the market: a need for an online office suite that combines Microsoft format compatibility, a familiar user experience, and European digital sovereignty.

That framing explains the project’s choices. Euro-Office wants to lower the friction for users who live in DOCX, XLSX and PPTX files. It wants to integrate with platforms that already need a browser-based editor. It wants to be familiar enough that organizations can test it without training every employee from zero. Those are rational product goals.

The Foundation is asking a different question: familiar to whom, and at what cost? If familiar means “Microsoft-like workflows and Microsoft formats first,” Euro-Office risks making itself easier to adopt while weakening its sovereignty claim. If familiar means “collaborative editing with open governance and format choice,” the project has more room to argue that compatibility is a bridge rather than a surrender.

Origin stories matter most when the technical story is still unsettled. Euro-Office has not yet built a long record of deployments, governance practice, security response, format fidelity, or migration support. Its early reputation therefore depends heavily on the story its backers tell. The Foundation’s intervention forces that story to become more precise.

The first European office suite claim meets StarOffice, OpenOffice.org and LibreOffice

OpenOffice.org did not appear out of nowhere. Its roots go back to StarOffice, created by Star Division in Germany and later acquired by Sun Microsystems. Sun’s October 2000 release made the StarOffice source code available through OpenOffice.org, a project hosted with Collab.Net and licensed under open-source terms.

That decision shaped the next two decades of open-source office software. OpenOffice.org became the base from which LibreOffice later emerged. LibreOffice’s timeline records the 2010 formation of The Document Foundation, the LibreOffice fork, the 2011 release of LibreOffice 3.3, and Oracle’s later decision to stop OpenOffice.org development and contribute trademarks and code to the Apache Software Foundation.

Euro-Office does not need to diminish that history to make its own case. Its case is different enough. It is built for collaborative editing inside cloud platforms, not as a classic desktop office suite first. It is also emerging at a moment when European governments and companies are more openly discussing digital sovereignty, cloud dependency, procurement autonomy, and control over public data.

The problem is that “first” claims are rarely read narrowly by the audience that matters. Public-sector buyers, journalists, analysts, and search engines tend to compress them. A broad first claim becomes a headline. A headline becomes a category label. A category label becomes a procurement assumption. The Foundation’s response is an attempt to stop that compression.

The more accurate claim would be narrower and stronger: Euro-Office is a new European open-source online office initiative, backed by a coalition of European cloud and collaboration providers, built from a fork of ONLYOFFICE and aimed at sovereign workplace deployments. That sentence does not take anything away from the project. It makes the project legible without rewriting the past.

The historical distinction also protects the credibility of the European open-source community. LibreOffice, Collabora and Apache OpenOffice users have long argued that Europe already has serious open-source office technology. Some of it runs on desktops. Some of it runs in browsers. Some of it is used in governments and public bodies. Some of it struggles against the sheer market weight of Microsoft Office. But it exists.

When a new coalition claims novelty too broadly, older maintainers hear more than marketing enthusiasm. They hear a risk that public memory will be reset at the very moment European open-source software is gaining policy attention. That is why the Foundation’s criticism carries a defensive tone. It is not trying to deny Euro-Office’s existence. It is defending the lineage that makes any European office-sovereignty conversation possible.

This lineage also affects technical judgement. LibreOffice’s long history with ODF, Microsoft format filters, migration projects, and desktop deployments gives The Document Foundation practical authority in the file-format debate. It has lived the cost of compatibility claims. It knows that “supports DOCX” and “preserves a complex DOCX across years of round trips” are not the same sentence.

Euro-Office’s backers may come from a cloud-first angle, but they are entering a domain shaped by old documents, old templates, old macros, old habits, old legal requirements, and old migration failures. That is why the past cannot be brushed aside. Office software is never only new code. It is a negotiation with everything an institution has already written.

The Foundation’s complaint goes beyond credit

The easiest reading of the dispute is that The Document Foundation was annoyed about the “first” label. That reading is incomplete. The deeper objection is that Euro-Office, as described by TDF, risks confusing European sourcing with European sovereignty.

In its open letter, the Foundation said the project’s choice to use OOXML by default binds users to a Microsoft-controlled format ecosystem. It described OOXML as a format associated with content lock-in and argued that ODF is the format aligned with document freedom and vendor independence.

That language is strong, but the underlying concern is practical. A default document format is not just a saving option. It shapes interoperability, archival policy, staff habits, template design, training material, support contracts, application testing, document exchange, and the future cost of switching. Once an institution’s new documents are created in a default format, that choice spreads silently through every department.

This is especially true for public administrations. A ministry can announce an open-source migration while still producing millions of documents in a format family associated with the dominant proprietary office suite. It can host its files in a local cloud, use open-source editors, and sign a European provider contract, while still leaving the document structure aligned with Microsoft Office’s compatibility universe.

That is the Foundation’s main warning. Euro-Office may reduce one form of dependency while preserving another. Hosting moves from global cloud to European infrastructure. Code moves from closed SaaS to inspectable repositories. Procurement moves from a multinational vendor to a local ecosystem. But if the documents themselves remain optimized for Microsoft’s formats, the deepest dependency survives.

The Foundation has been making this argument in stages. In April 2026, it challenged Euro-Office’s sovereign branding by asking whether ODF would be the native format and warning that full compatibility with Microsoft formats is not the same as sovereignty. In late May, it sharpened the argument by contrasting ODF and OOXML, saying the document-format landscape remains distorted by Microsoft’s market position and by the history of OOXML standardization.

This does not mean Euro-Office should ignore Microsoft formats. That would be commercially naïve. Most organizations exchange DOCX, XLSX and PPTX files every day. A tool that cannot handle those formats will be dismissed before procurement teams even reach the sovereignty discussion. Compatibility is not optional.

The question is whether compatibility becomes the migration path or the product center. Euro-Office appears to be betting that Microsoft format compatibility is the practical entry point for adoption. The Foundation is warning that an entry point can become a cage. Both views contain a piece of the truth. The difficulty is designing a product and a policy model that keeps the bridge from becoming the destination.

The native format question sits at the center

A native format is the format an application treats as its home. It is the format that receives the most stable internal assumptions, the cleanest round trips, the first testing attention, and the least conversion stress. Users rarely think about it. Administrators often notice it only when documents break.

For an office suite, the native format question is not decorative. It answers a governance question: who gets to define the shape of institutional knowledge? If a school system, ministry, hospital network or court produces documents every day, the file format becomes part of its public infrastructure. It affects whether records remain readable, editable and migratable without asking permission from a single vendor’s product roadmap.

ODF was built for this argument. OASIS describes OpenDocument Format 1.3 as an open XML-based document file format for text documents, spreadsheets, charts, graphics and presentations. ISO/IEC 26300 is the international standard for ODF, with the ISO page describing its schema for office documents and its status as a reviewed standard.

OOXML has a different history. ECMA-376 defines Office Open XML vocabularies and packaging requirements, and ISO/IEC 29500 standardizes the format family associated with Microsoft Office document types. Microsoft’s documentation presents Office Open XML as an open international standard based on ZIP and XML.

The technical debate does not end with the word “standard.” Standards differ in governance history, implementation complexity, product dependency, legacy baggage, and real-world fidelity. The Foundation’s position is that OOXML, despite formal standardization, remains structurally tied to Microsoft Office’s legacy and market dominance. Its critique of OOXML points to the format’s volume, legacy dependencies, Transitional variant and implementation burdens, while arguing that ODF is the better vendor-neutral default for public documents.

Euro-Office’s supporters might answer that users demand DOCX, XLSX and PPTX because those files dominate daily work. They would be right. Many organizations that say they want open standards still live inside Microsoft document exchange. For them, the first test of an alternative suite is brutally simple: does the existing file open correctly, does the layout survive, does track changes behave, does the spreadsheet calculate, and does the recipient complain?

That reality does not erase the sovereignty question. It makes the product design harder. A credible European office suite needs strong Microsoft compatibility and a native format strategy that moves institutions toward ODF where records, public templates, internal documents and archive policies allow it. Compatibility should reduce switching pain. It should not freeze the market’s old dependency into the new product’s defaults.

The hardest part is not explaining this to open-source advocates. It is explaining it to users who do not care about formats until a document breaks. Euro-Office will need an interface and admin policy model that makes format choices understandable without turning every save dialog into a standards seminar. The default must carry the policy, because most users will not.

ODF carries the sovereignty argument better than branding

The OpenDocument Format has a simple strategic role in this debate. It gives European institutions a document format whose governance is not anchored in one dominant office vendor’s product history. That does not make ODF perfect. It does not make every implementation identical. It does not remove the need for interoperability work. But it gives the sovereignty argument a technical base that slogans cannot provide.

The Foundation’s support for ODF is tied to this base. LibreOffice uses ODF as its native format. Collabora Online, built from the LibreOffice technology stack, also sits in that ecosystem. Collabora describes its online product as based on LibreOffice technology and says it works with The Document Foundation while contributing to LibreOffice development.

That relationship matters because ODF is not only a standard on paper. It has a large open-source implementation lineage behind it. LibreOffice, Collabora and related projects have spent years improving import and export filters, document layout, spreadsheet functions, interoperability and standards support. That work is slow and often invisible. It is also the reason public-sector migrations can move beyond press releases.

Euro-Office, by contrast, is emerging from a fork of ONLYOFFICE, a suite long known for strong Microsoft format compatibility. That gives it a real adoption advantage in organizations where DOCX fidelity is a gatekeeper. But it also means the project’s center of gravity begins near the Microsoft-format world rather than the ODF-native world.

The right question is not whether Euro-Office supports ODF at all. Its public GitHub page lists ODT, ODS and ODP among supported formats. The question is whether ODF is treated as a first-class home format, a migration target, a policy default, and a tested production path for collaborative editing. A supported format and a native format are not the same thing.

For sovereignty, the difference between “we open ODF” and “we create, test, save and govern through ODF by default” is the difference between compatibility and control. Public bodies need the second if they want format policy to outlive a vendor contract.

ODF also has a semantic advantage in public policy. It is easy to explain: an open document standard for office files, designed for vendor-independent use. OOXML requires a more complicated explanation: an international standard derived from Microsoft Office formats, formally documented but tied in practice to Microsoft’s product behavior, legacy compatibility and market position. That does not make OOXML unusable. It makes it harder to present as the default foundation for sovereignty.

Euro-Office could still place ODF at the center. Nextcloud’s late-May post said ODF formats were “high on the agenda” for the next phase after the first stable release. That is a useful signal, but it also supports the Foundation’s concern. If ODF is next-phase work rather than launch-center work, then the sovereignty story starts with a gap.

OOXML is both a standard and a market dependency

The OOXML debate often becomes too crude. Critics describe it as proprietary lock-in. Defenders answer that it is an ISO and ECMA standard. Both statements point at real features of the format’s story, but neither resolves the adoption problem.

OOXML is standardized. ECMA-376 defines Office Open XML vocabularies and packaging. ISO/IEC 29500 defines the format family used for word-processing documents, spreadsheets and presentations associated with Microsoft Office. Microsoft also publishes extensive developer documentation for Open XML and presents it as an open standard.

At the same time, the format’s practical authority is not evenly distributed. The strongest reference implementation is Microsoft Office. The market expectation around DOCX, XLSX and PPTX is set by Microsoft Office behavior. When another suite renders a document differently from Microsoft Word, most users treat the alternative suite as wrong even when the question is more complex.

That is the dependency The Document Foundation is pointing to. A format can be standardized and still function as a market-control layer when one vendor’s product defines user expectations, edge cases, templates, macros, layout quirks, and compatibility tests. In office software, “standard” does not automatically mean “neutral in practice.”

This is especially visible in spreadsheets and presentations. A simple text document may move across suites with little trouble. A large spreadsheet with formulas, pivot tables, charts, conditional formatting, macros and linked data is a different object. A presentation with embedded media, custom fonts, animations and layout-sensitive elements has more ways to fail. Users do not judge those failures by reading standards documents. They judge them by opening the file before a meeting.

Euro-Office’s bet on Microsoft compatibility therefore has a strong product rationale. It lowers immediate resistance. It speaks to users who cannot afford broken documents. It helps European providers compete with Microsoft 365 and Google Workspace at the level of daily workflow rather than abstract sovereignty.

The Foundation’s counterargument is that this logic has trapped alternatives for years. Every open-source office suite must chase Microsoft compatibility because the market is already locked. If a new European project declares that chase to be its default state, it normalizes the trap instead of loosening it.

A better framing is possible. Euro-Office could say: we treat Microsoft formats as a migration and interoperability requirement, while treating ODF as the default for sovereign records and new internal documents where policy permits. That would acknowledge user reality without letting Microsoft’s document universe become the project’s institutional home.

The key is honesty. If Euro-Office is Microsoft-compatible first, it should say so. If it is sovereign-format-first, it should demonstrate that through defaults, tests, documentation, admin controls and partner policies. If it is trying to be both, it needs to show how conflicts are resolved when a user, administrator or public archive has to choose.

Compatibility is necessary, but defaults shape power

Euro-Office’s strongest defense is also the reason the Foundation is alarmed. The project targets the format users already rely on. That is how most migrations begin. Organizations do not switch from Microsoft Office by pretending DOCX files will vanish. They test alternatives against the files they have.

A European provider trying to win public-sector contracts must support Microsoft formats well. Without that, the first pilot becomes a gallery of broken layouts and angry departments. Even the most sovereignty-minded CIO has to answer to employees who need to edit documents now, not after a three-year standards education project.

But compatibility is not neutral once it becomes the default. A default defines what the product considers normal. It influences documentation, training, support, sales demos, test suites, feature priorities, and ecosystem expectations. A format default is policy hidden inside a product choice.

Most users do not choose formats deliberately. They click save. They use the file type preselected by the application. They send what the system gives them. If the default is DOCX, the institution creates more DOCX. If the default is ODT, it creates more ODT. Over time, that simple behavior becomes document culture.

This is why The Document Foundation’s criticism is sharper than a preference dispute. If Euro-Office defaults to OOXML, as TDF says, then even organizations that adopt it for open-source or European-sovereignty reasons may continue producing documents in Microsoft’s format family by habit. That may be acceptable for external exchange. It is harder to justify for internal records, public templates, interdepartmental documents, and long-term archives.

The challenge is that defaults cannot be decided by ideology alone. A default that breaks too many workflows will be overridden by users or rejected by procurement teams. A default that prioritizes compatibility at all costs weakens the sovereignty claim. The right design likely requires policy-aware defaults, not a single universal choice.

For example, an organization might set ODF as the default for internal documents, require PDF/A or PDF for final published records, and allow OOXML for external exchange with partners who demand it. A public administration might pair ODF defaults with conversion guidance, template cleanup, staff training, and a clear exception process. A company might let departments choose based on collaboration patterns but require open formats for archived material.

Euro-Office needs these policy controls if it wants to avoid being judged only by its base default. It also needs clear language. “Works with Microsoft Office files” is not the same claim as “uses Microsoft Office files as the default.” The former is a feature. The latter is a strategic decision.

A useful European office suite must meet users where they are. It must also move institutions away from the dependencies they say they want to reduce. That tension will not disappear. It has to be managed in the product.

Euro-Office is not a desktop suite in the old sense

The comparison with LibreOffice is necessary, but it can also mislead. Euro-Office is not trying to be LibreOffice with a new badge. Its public materials describe an online office component for collaborative editing, integrated into larger platforms. That places it closer to the web-office layer inside Nextcloud than to the classic desktop suite model.

This distinction matters for product judgment. Desktop suites and web editors face different constraints. A desktop suite can prioritize rich local editing, complex document handling, offline access, and deep operating-system integration. A browser-based collaborative editor must prioritize simultaneous editing, server integration, sharing, permissions, latency, conflict handling, and compatibility with cloud storage workflows.

The European market needs both. LibreOffice remains one of the strongest open-source desktop office suites. Collabora Online brings LibreOffice-based editing into browser and server deployments. Euro-Office is aiming at a similar cloud-collaboration problem but from a different code base and partner coalition.

The Document Foundation’s history challenge is not invalidated by this difference. The broad “first European open-source office suite” phrase still overreaches. But the product category is not identical. Euro-Office’s value will be judged less by whether it can replace LibreOffice on a laptop and more by whether it can serve as a credible collaborative editor inside sovereign cloud platforms.

That is why Nextcloud is central. Nextcloud is already a familiar name in European open-source cloud discussions. It offers file sync, sharing, groupware and collaboration features that organizations can run through local providers or self-hosted infrastructure. An integrated editor strengthens the platform’s claim to be a workplace stack rather than only a file platform.

Euro-Office’s choice of base also reflects this goal. ONLYOFFICE has been widely used as a web-based editor in collaborative environments and is known for Microsoft format fidelity. Forking it gives Euro-Office an immediate code base for the browser editing layer. But that choice carries baggage: licensing dispute, branding dispute, governance questions, and a format center of gravity closer to Microsoft compatibility.

A desktop suite can survive with a clear identity around ODF and strong import/export filters. A web editor competing for modern workplace contracts must also handle real-time collaboration smoothly. That requirement changes the trade-off. Public bodies will not accept ideological purity if the editor performs poorly in everyday group work. They also should not accept smooth collaboration if it leaves public documents dependent on another vendor’s format logic.

The category difference therefore raises the standard rather than lowering it. Euro-Office has to be cloud-native, collaborative, open-source, European, legally clean, interoperable, secure, governed, and format-conscious. Each claim touches the others. Weakness in any one area gives rivals and critics a clean opening.

Nextcloud’s integration strategy changes the stakes

Nextcloud’s role gives Euro-Office reach. A standalone editor can make a principled argument and still struggle to get users. A document editor integrated into a widely known open-source collaboration platform can enter actual deployments faster. That is why the Euro-Office dispute matters beyond one product page.

Nextcloud’s May announcement said Euro-Office would be available as an alternative to Collabora under Nextcloud Office, with additional availability through IONOS and other partners. This turns a format debate into a deployment debate. Administrators may soon see Euro-Office not as an abstract initiative but as an option inside the stack they already evaluate.

That kind of placement influences adoption. If a European organization is already testing Nextcloud for sovereign file collaboration, an integrated editor becomes attractive. Procurement teams prefer fewer moving parts. Users prefer one interface. IT teams prefer one support path. Vendors prefer bundled offerings. Integration gives Euro-Office a route around the hardest part of open-source adoption: being noticed at all.

It also makes defaults more consequential. A default inside a widely deployed platform can spread faster than a default inside a niche application. If Euro-Office becomes an editor choice in Nextcloud ecosystems and defaults to OOXML, the format behavior of that editor could shape document creation across many European deployments. If it supports ODF but treats it as secondary, ODF may remain an archival talking point rather than daily practice.

Nextcloud’s own communications leave room for evolution. The May post said the first stable release would focus on stability and security, and that later work would include desktop, mobile and integration, while placing ODF formats high on the agenda. That phrasing suggests the project may not consider its format story finished at launch.

The Foundation’s intervention can be read as pressure to move that work from “agenda” to “identity.” For a public-facing sovereignty project, ODF cannot be an afterthought. It must be part of the launch promise or a dated roadmap with testable milestones.

Nextcloud also has to manage partner tension. Collabora has been a major open-source office option in Nextcloud contexts. Euro-Office creates a new route, potentially competing with or displacing established LibreOffice-based online editing. That is not inherently bad. Competition can improve software. But when the new option is framed as the European sovereignty answer, older European open-source office actors will ask why their work is being treated as insufficient or invisible.

The risk for Nextcloud is reputational rather than only technical. If Euro-Office is seen as a pragmatic compatibility fork, it will be judged by product quality. If it is seen as a sovereignty banner that sidesteps ODF and historical credit, it will face a more ideological audit from the same community whose trust European providers often rely on.

The fork from ONLYOFFICE adds legal and governance pressure

Euro-Office’s dispute with The Document Foundation is not its only early conflict. The project also inherited controversy from its technical base. Euro-Office is built from an open-source fork of ONLYOFFICE, and ONLYOFFICE publicly accused the initiative of violating licensing terms and intellectual property rules shortly after the project was announced.

ONLYOFFICE said in March 2026 that the Euro-Office initiative violated licensing terms and intellectual property law, arguing that its license required preservation of ONLYOFFICE branding, logo and attribution in derivative versions. Linuxiac later summarized the dispute as a clash over whether extra branding and credit obligations around an AGPLv3 codebase were enforceable, noting that Euro-Office disputed the additional terms and that no lawsuit had been filed at that point.

Nextcloud answered with a legal and open-source argument of its own. It said Euro-Office had reviewed ONLYOFFICE’s terms, kept valid warranty disclaimers, and rejected logo-retention requirements that it considered conflicting with the absence of trademark rights and incompatible with AGPL freedoms. Nextcloud also said the Free Software Foundation had confirmed its position.

The Free Software Foundation’s broader April 2026 post did not adjudicate the full dispute in the way a court would. It explained that GNU GPL and AGPL terms cannot be used to remove software freedom through extra license restrictions, while acknowledging that (A)GPLv3 permits certain additional terms under defined conditions. The official AGPLv3 text remains the relevant license baseline for network software that must provide corresponding source code to users interacting with modified versions over a network.

For Euro-Office, this dispute matters because sovereignty projects rely on trust before feature maturity. Buyers will ask three questions. Is the code legally safe to deploy? Is the governance structure credible? Are the maintainers able to handle upstream conflict without leaving users stranded?

A fork can be justified. Open-source licenses permit forks under their terms. Forks are sometimes the only way to continue development when governance, business strategy, code transparency or community trust breaks down. LibreOffice itself exists because contributors forked from OpenOffice.org under a new foundation. Forking is not a scandal by default.

But a sovereignty project based on a contentious fork must work harder to prove discipline. It needs transparent legal review, clean source availability, clear trademark separation, public contribution rules, security processes, and a governance model that does not depend on informal partner goodwill. Euro-Office’s GitHub page says governance is still being set up and that an interim “who codes, decides” model applies while members coordinate through GitHub.

That may be acceptable at the start of a small project. It is thin for software positioned as a European public-sector alternative to Microsoft 365 and Google Workspace. The higher the sovereignty claim, the lower the tolerance for improvised governance.

A coalition can give reach, but it cannot replace institutions

Euro-Office’s partner list is one of its strengths. A single small vendor trying to challenge the office layer would look underpowered. A coalition with cloud, collaboration, hosting and open-source companies gives the project market visibility and deployment channels. Nextcloud’s March announcement presented the effort as a joint industry initiative with named European partners and a plan for a stable summer release.

Coalitions are useful at launch. They bring engineering, hosting, product integration, communications, procurement relationships and credibility. They also help buyers believe a project will not disappear after one grant cycle or one company’s strategic pivot.

But coalitions are not the same as institutions. An office suite needs governance that survives disagreement. It needs release rules, security response paths, format-policy decisions, accessibility commitments, localization processes, long-term maintenance funding, and a way to decide whose priorities win when partners disagree.

LibreOffice’s history shows why. The Document Foundation was created because community contributors wanted an independent body to protect the project beyond one corporate owner. Its history page says the foundation was announced in September 2010 by OpenOffice.org contributors who wanted an independent, meritocratic organization for LibreOffice and a way to protect community and user investment.

Euro-Office does not yet have an equivalent institutional identity. Its GitHub page states that governance is being created and that members currently coordinate development work through a project board. That openness is better than secrecy, but it also confirms that the project is early.

The public-sector market will not judge governance as a side issue. A ministry choosing an office layer asks whether updates will arrive, security bugs will be handled, disputes will be resolved, source code will remain available, and contributors will be treated fairly. Those are not sentimental open-source concerns. They are procurement risk controls.

European digital sovereignty needs institutions, not only European vendors. A project can be hosted in Europe and still depend on fragile governance. It can be open source and still be controlled by a narrow group. It can be backed by known companies and still leave users uncertain about long-term stewardship.

Euro-Office has time to build those structures. The early fight with The Document Foundation should push it toward clearer governance faster. If it wants to claim a place beside or above older European office projects, it needs a stewardship model that buyers, contributors and rivals can inspect.

The competing claims in the Euro-Office dispute

Competing claims in the Euro-Office dispute

This table compresses the main conflict, but it also shows why the argument cannot be solved with one slogan. Euro-Office is trying to win adoption through practical compatibility, while The Document Foundation is asking whether that compatibility becomes a new dependency.

Europe’s open-source policy mood is turning favorable

The Euro-Office controversy is unfolding during a favorable policy moment for open source in Europe. That does not mean Euro-Office will win. It means the category is no longer marginal.

The European Commission’s Open Source Strategy 2026 places open source within a broader technology-sovereignty agenda. The Commission says the strategy promotes European open alternatives to non-EU proprietary solutions, supports open digital ecosystems, and connects open source to control, interoperability and reduced lock-in in public administrations.

This policy language gives projects like Euro-Office a stronger market story. For years, open-source office suites were often pitched through cost, freedom, local control or ideological commitment. The current European framing adds strategic autonomy, cloud dependency, data control, procurement resilience and public-sector interoperability. That is a stronger political package.

The Commission’s earlier open-source software strategy also promoted sharing, reuse and strategic use of open source across the institution, including the creation of an open-source programme office and work on code distribution and security. This matters because public administrations tend to follow language from central European policy when writing national strategies, tenders and digital transformation plans.

Open source also has measurable economic relevance. A Commission-backed study on open-source software and hardware reported that European companies invested around €1 billion in open source in 2018 and estimated an economic impact in the tens of billions of euros. A related policy summary said a 10 percent increase in open-source contributions could generate GDP effects and additional ICT startup activity, while public procurement of open source can reduce total cost of ownership and avoid lock-in.

Euro-Office is therefore entering a market where its message resonates. European governments want alternatives. Providers want product bundles that can compete with American suites. Policymakers want examples of open-source industrial capacity. Users want tools that do not feel like a punishment for choosing sovereignty.

That favorable mood can also make claims sloppy. When “sovereignty” becomes a selling word, projects may use it before they have done the hard work. The Document Foundation’s critique acts as a discipline mechanism. It says: if Europe is serious about open-source sovereignty, then the document format, governance model and historical record must be part of the standard.

The policy opportunity is real, but it will not forgive weak architecture. European software projects win lasting trust when they turn sovereignty language into concrete guarantees: open formats, auditable code, contributor governance, documented security, accessible interfaces, migration support and honest compatibility limits.

Public procurement will care about auditability before slogans

Public procurement teams do not buy identity. They buy risk reduction, service continuity, legal safety, support, security, compliance, cost control and political defensibility. Euro-Office’s sovereignty pitch may get it into the room. The procurement file will ask harder questions.

A serious tender will examine license terms, source availability, data-processing arrangements, accessibility, export formats, authentication integration, audit logs, backup, disaster recovery, support levels, incident response, patch cadence, localization, training, migration assistance, and long-term records management. Document formats sit inside that list, not outside it.

If Euro-Office defaults to OOXML, procurement teams in administrations with open-standard policies will need to know whether they can set ODF as the default. They will need to know whether ODF support covers collaborative editing, comments, tracked changes, spreadsheets, presentations and templates. They will need to know whether ODF files survive round trips across Euro-Office, LibreOffice and Collabora.

If Euro-Office claims Microsoft compatibility, buyers will ask what that means. Does it preserve complex tables, footnotes, styles, comments, track changes, embedded objects, spreadsheet formulas, pivot tables, charts, conditional formatting, macros and presentation animations? Which features are unsupported? Where are the tests? Which formats are used internally during editing? What happens when multiple users edit the same DOCX?

Procurement language rewards specificity. “Sovereign office suite” is not specific enough. “ODF as configurable default, Microsoft format import/export, published compatibility matrix, AGPL source availability, documented security process and EU-based support terms” is closer to a buyer’s checklist.

Euro-Office’s backers have a practical advantage here. Nextcloud and IONOS already understand enterprise and public-sector buying. Their involvement means the project is more likely to be packaged with support, hosting and integration offers rather than left as a community repository. But that also raises expectations. A coalition pitching to institutions must produce institutional-grade answers.

The license dispute with ONLYOFFICE may appear abstract to ordinary users. Procurement teams will not treat it as abstract. Any claim of license uncertainty can delay adoption. Even if Euro-Office’s legal position is sound, the project needs clean documentation explaining how the code is licensed, what was removed or retained, how trademark obligations are handled, and why customers are safe to deploy it.

Governance will also enter procurement. An informal project board may be fine in the first release, but a ministry may prefer a foundation, association, consortium agreement or other durable structure. Buyers need to know who is accountable when a security flaw is found, a critical feature breaks, or partners disagree about the roadmap.

The Document Foundation’s criticism therefore creates pressure Euro-Office should welcome if it is serious. It forces the project to answer questions that public buyers will ask anyway.

Germany’s ODF signal matters beyond Germany

Germany has become one of the most closely watched European markets for digital-sovereignty efforts because its public sector has been explicit about open standards, sovereign cloud infrastructure and reducing vendor dependency. The country’s document-format choices therefore matter beyond national borders.

Interoperable Europe reported that Germany confirmed a goal of standardizing the OpenDocument Format by 2027, with state administrations expected to support ODF gradually from January 1, 2027 and evaluation planned in 2028. That is exactly the kind of policy signal that turns ODF from an open-source preference into a procurement factor.

Euro-Office cannot ignore this. If German public administrations are moving toward ODF support as a standardization goal, a European office suite positioned for sovereignty needs a convincing ODF story. It does not have to reject Microsoft formats. It does have to show that ODF can be a first-class default where administrations require it.

Germany’s direction also affects neighboring markets. Public-sector IT strategies are copied, adapted and cited across Europe. If one large member state treats ODF as a standardization target, other administrations can refer to that move when writing their own requirements. Vendors then adapt to the requirement, because the market starts asking for it.

This is where Euro-Office’s timing becomes delicate. It arrives at a moment when European policy interest in open source is rising and German standardization signals favor ODF. Yet the Foundation says Euro-Office defaults to OOXML. That contrast gives critics an easy line: Europe’s new sovereign office suite should not arrive with the old Microsoft format habit as its default.

The counterargument is that Germany’s public-sector goals and Europe’s general market reality are not identical. Many organizations still need Microsoft compatibility to function. Vendors cannot sell a product that fails at existing DOCX workflows. A transitional default may be defended as practical.

But transition must have a direction. Without a stated destination, transitional choices become permanent. If Euro-Office wants to serve German and wider European public buyers, it should publish a clear format policy: which use cases should default to ODF, which require OOXML compatibility, what admin settings exist, what conversion quality has been tested, and how the roadmap will improve ODF collaborative editing.

Such a policy would not silence every critic. It would turn a symbolic dispute into an operational plan. That is what public administrations need.

LibreOffice’s role is institutional memory, not nostalgia

LibreOffice is sometimes treated as the old guard in office-suite debates: respected, familiar, occasionally unfashionable, and tied to desktop productivity in a cloud-collaboration age. That reading misses its institutional role. LibreOffice carries the memory of what document independence actually costs.

The project has lived through corporate ownership changes, community governance battles, standards fights, migration campaigns, import-export filter work, public-sector deployments, and the relentless reality that Microsoft Office remains the reference point for most users. That history gives The Document Foundation a specific kind of authority. It does not know everything about modern cloud collaboration. It does know the document-format trap.

LibreOffice’s commitment to ODF is not ornamental. It is central to the project’s identity. Its community has argued for years that public documents should not depend on the file formats or behavioral quirks of one vendor’s office suite. That argument can sound old only because the market has failed to solve it.

Euro-Office’s emergence puts LibreOffice in a difficult position. On one hand, a European open-source collaborative office project could expand the market for alternatives. On the other hand, if that project positions itself as the new sovereign answer while leaning on OOXML defaults and broad first claims, it threatens to marginalize the older work that made open office software credible.

The Foundation’s response should not be read as fear of competition alone. It is also a demand that the new project respect the technical and political lessons of the old one. LibreOffice’s lesson is that open-source code without open document control leaves the user only half-free.

This lesson matters more in a cloud setting. Desktop users can sometimes install another application and open their files locally. Cloud users depend on server-side editors, integration layers, account systems, sharing permissions and hosting contracts. If the format layer remains tied to Microsoft expectations, cloud migration may reduce one dependency while making another less visible.

LibreOffice’s challenge is that users also expect modern collaboration. The Foundation cannot win the argument by saying history is enough. It must show that ODF-native tools can meet real collaboration needs. Collabora Online is part of that answer, but Euro-Office’s arrival suggests the market still sees room for another editor, especially one promising familiar Microsoft-format handling.

The most productive outcome would not be a purity contest. It would be a European office ecosystem in which LibreOffice, Collabora, Euro-Office and related projects improve interoperability, publish tests, clarify format defaults, and compete without pretending the format question has been solved. That outcome requires restraint from all sides. It also requires Euro-Office to stop treating historical and format criticism as a branding nuisance.

Collabora sits awkwardly in the middle of the argument

Collabora is the quiet pressure point in this dispute. It is a European company, it builds Collabora Online from the LibreOffice technology stack, and it already offers a browser-based office path for organizations that want open-source document collaboration. That makes the “first European open-source office suite” claim even more sensitive.

Collabora’s own materials state that Collabora Online is based on LibreOffice technology, that the company works with The Document Foundation, and that it is a major contributor to LibreOffice development and browser-based LibreOffice technology. In other words, the category Euro-Office wants to occupy is not empty.

Nextcloud’s May post said Euro-Office would be available as an alternative to Collabora under Nextcloud Office. That wording is polite, but the market implication is sharp. A new editor option inside Nextcloud affects Collabora’s position in deployments where it has been one of the established choices.

Competition inside open source is not unusual. Forks, alternatives and rival implementations often improve products. But this case carries extra tension because the new option is being packaged through sovereignty language and Microsoft compatibility. Collabora sits closer to the LibreOffice and ODF tradition. Euro-Office sits closer to the ONLYOFFICE and Microsoft-format compatibility tradition. Nextcloud is placing both under its broader collaboration umbrella.

For buyers, this may be positive. They can compare editors based on document fidelity, ODF handling, collaborative editing, performance, licensing, accessibility, support and governance. For the open-source community, it raises a political question: which technical lineage gets recognized as the European office-sovereignty path?

Collabora’s existence weakens any broad claim that Euro-Office is Europe’s first open-source office suite. It also raises the bar for Euro-Office’s ODF and governance story, because a LibreOffice-based online alternative already exists.

Euro-Office can still differentiate itself. It can claim stronger Microsoft format fidelity, a different collaboration model, a broader partner coalition, or tighter integration with certain platforms. It can serve users who struggled with other editors. It can bring new investment into the office layer. Those are valid reasons to exist.

But it should not present its existence as though Europe lacked open-source office efforts before it. Doing so turns potential allies into critics. A more mature message would position Euro-Office as another piece in Europe’s office-software ecosystem, not the first credible European answer.

That distinction matters for long-term cooperation. Open-source office software has more than enough external competition. Microsoft and Google dominate the productivity market. If European alternatives waste attention on avoidable claims, they lose time that should be spent on compatibility tests, ODF improvements, accessibility, security reviews and migration tooling.

Microsoft compatibility remains the adoption trap

Every serious open-source office project eventually meets the same wall: Microsoft compatibility. It is not enough to support open standards. Users expect their old files to work, their partners’ files to open, and their outgoing documents to look acceptable in Microsoft Office.

This expectation has practical roots. Businesses exchange contracts as DOCX files. Universities distribute templates in DOCX. Finance departments rely on XLSX workbooks. Public bodies receive external submissions in Microsoft formats. Presentations circulate as PPTX files. Users may never have chosen Microsoft formats as a policy matter. They inherited them through the market.

Euro-Office’s emphasis on Microsoft compatibility is therefore understandable. It addresses the fear that kills many migrations before they start. A user who opens a document and sees broken layout does not care about vendor neutrality. A department head who loses a spreadsheet formula does not care about open-source philosophy. A public servant whose presentation fails before a meeting will blame the alternative tool.

But this adoption trap is exactly why defaults matter. If a new tool says, “We will work well with your Microsoft files,” it reduces migration pain. If it says, “We will keep making Microsoft-format files by default,” it may reduce the incentive to leave the Microsoft-centered document ecosystem. Compatibility is the ladder out of lock-in only when it points toward a different default.

This is not an easy product decision. An ODF-first default could create friction in organizations that exchange documents heavily with Microsoft Office users. A DOCX-first default could undermine sovereignty goals. A user-choice default could result in chaos, with no institutional policy at all.

The answer is likely administrative control. Euro-Office should let organizations define format policy by deployment, group, folder, document type or use case. Internal collaboration spaces could default to ODF. External client spaces could allow OOXML. Official records could export to PDF/A or another archival format. Templates could be cleaned and migrated over time. Warning dialogs could explain when users are leaving the preferred format.

The product also needs clear conversion rules. If a user creates an ODT file and saves as DOCX, what features may change? If a DOCX is edited collaboratively and then saved back, what elements are preserved? If tracked changes cross suites, what happens? Users do not need a standards lecture, but administrators need a compatibility matrix.

The adoption trap cannot be solved by pretending it is not a trap. Euro-Office’s strongest market feature may be its biggest strategic risk. That makes format policy the product’s most sensitive design area.

The document layer is where sovereignty either becomes real or decorative

Digital sovereignty is often discussed through data centers, cloud contracts, jurisdiction, encryption, and provider nationality. Those topics matter. But for office software, the document layer is where users encounter sovereignty every day.

A document is a container for public decisions, business contracts, legal arguments, budgets, research notes, school material, meeting minutes, HR policies, procurement files and institutional memory. If that container depends on one vendor’s product behavior, the institution’s autonomy is limited even if the file sits on a European server.

This is the point The Document Foundation keeps pressing. European hosting does not by itself free the user from document lock-in. Open-source code does not by itself guarantee format independence. A sovereign stack must control the layers where data is created, not only where it is stored.

A sovereign office suite must answer three document-layer questions: who defines the format, who can implement it faithfully, and who can keep the document usable when the original vendor relationship ends. ODF gives a cleaner answer than OOXML because it is not rooted in Microsoft Office as the market reference. OOXML has formal standard status but remains socially and commercially attached to Microsoft Office behavior.

This does not make the sovereignty test binary. Institutions will keep receiving Microsoft-format files. Many will keep sending them. Some workflows will remain tied to Microsoft formats for years. The real test is whether new internal document creation starts moving toward open, vendor-neutral defaults.

Euro-Office’s design could support that transition. It could combine strong Microsoft import/export with ODF-native creation. It could provide admin templates that recommend ODF for internal collaboration. It could publish test documents showing ODF fidelity across Euro-Office, LibreOffice and Collabora. It could help organizations migrate template libraries. It could make ODF collaboration smooth enough that users do not experience it as a downgrade.

The danger is that the product uses sovereignty as a cloud-hosting story while treating file formats as a compatibility inconvenience. If that happens, Euro-Office will be sovereign at the infrastructure layer and dependent at the content layer. That may still be better than fully proprietary cloud dependence, but it is not the same as document independence.

The distinction will matter for regulators and public records managers. Long-lived documents need predictable readability. Governments cannot treat office files as disposable workflow artifacts. They become evidence, archives and public memory. Format governance is therefore not a specialist obsession. It is part of democratic record-keeping.

Standards language can hide implementation reality

Standards are necessary, but they are not magic. A file format can be formally standardized and still produce interoperability problems. A standard can be open and still be hard to implement. A vendor can claim compliance while relying on behaviors that only its own product handles well.

The OOXML debate is full of this friction. Supporters point to ECMA and ISO standardization. Critics point to the format’s complexity, legacy dependencies and Microsoft’s practical control through Office behavior. Both sides use the word “standard,” but they mean different things.

For a public-sector buyer, the operational question is simpler: can multiple independent implementations create, edit and preserve documents without unacceptable loss? If yes, the standard works in practice. If no, formal status has limited value.

ODF has an advantage because its design goal and implementation community are aligned around vendor independence. LibreOffice and Collabora treat ODF as native. That does not make every ODF document perfect across every tool. But it means the format is not merely an export target. It is the format the ecosystem is built to inhabit.

OOXML is different. It is widely used because Microsoft Office is widely used. It is standardized because Microsoft’s document formats became too important to remain undocumented at the same level. It is supported by many tools because the market demands it. But the center of gravity remains Microsoft Office.

The practical question for Euro-Office is not “does OOXML have a standard number?” It is “does making OOXML the default deepen the user’s dependence on Microsoft Office behavior?” The Foundation believes it does. Euro-Office has to prove that its choice is only a bridge, or change the choice.

Implementation reality also affects ODF. If Euro-Office lists ODF support but handles it weakly compared with DOCX, users will learn quickly. They will avoid ODF, even if administrators prefer it. If ODF collaboration lacks features, runs slower, or breaks formatting, the default debate becomes theoretical. The project must invest in ODF quality if it wants to claim neutrality.

The most credible route is measurable testing. Euro-Office should publish a compatibility matrix for ODF and OOXML, include known limitations, and invite independent verification. It should show test suites, sample files, bug-tracking categories and roadmap commitments. A sovereign project gains trust when it exposes its weak points and fixes them.

Marketing cannot substitute for this work. Standards language should reduce uncertainty, not hide it.

The licensing dispute tests the project’s open-source discipline

The ONLYOFFICE dispute is more than legal noise. It tests whether Euro-Office can handle open-source obligations with the rigor expected from a project seeking public-sector trust.

The GNU Affero General Public License is designed for network software. The Free Software Foundation released AGPLv3 in 2007 as a license based on GPLv3 with an added requirement around source availability for users who interact with modified software over a network. That feature is especially relevant to web-based editors and cloud software.

Euro-Office’s base on an AGPLv3-licensed codebase means users and competitors will scrutinize source publication, notices, modifications, build reproducibility, trademark use and additional terms. ONLYOFFICE’s public complaint shows how quickly such scrutiny can become a reputational issue.

Euro-Office’s backers have argued that certain ONLYOFFICE requirements amount to additional restrictions or impossible trademark conditions. Nextcloud’s response leaned on the principle that open-source freedoms cannot be removed through conflicting license demands. The FSF’s April post supports the general point that (A)GPL terms cannot be used to take software freedom away through extra license restrictions, though the full legal facts of a particular dispute depend on the exact terms and conduct.

For buyers, the legal theory is only one layer. They need confidence that the project will not be disrupted by injunctions, rebranding battles or code removal demands. They also need clarity on whether Euro-Office’s fork is cleanly separable from ONLYOFFICE trademarks and whether all source corresponding to deployed versions is available.

The project should publish a plain-English license compliance dossier. It should list the upstream code base, license version, notices retained, trademarks removed, branding decisions, source availability process, build instructions, third-party dependencies and legal review status. That would not settle every possible dispute, but it would reduce uncertainty.

The open-source community often treats licensing hygiene as internal housekeeping. In sovereign public infrastructure, it becomes part of the trust package. A project that asks governments to rely on it must show that its legal foundations are boring. Boring is good here. Boring means deployable.

Euro-Office’s early conflict with ONLYOFFICE may prove survivable. Forks are allowed when licenses allow them. But the dispute weakens the project’s ability to ask users for trust while its governance and format policy are still forming. The path forward is more transparency, not louder branding.

Governance claims need maintainers, money and conflict rules

Open-source governance is easy to praise and hard to build. A repository, license and partner logo wall do not create a durable project. They create the starting conditions. The real governance test comes when maintainers disagree, security issues appear, enterprise customers demand features, volunteers ask for influence, and partners want different roadmaps.

Euro-Office’s GitHub page says governance is being set up and describes an interim model where those who contribute code take decisions, with consensus among project members where possible. That may reflect the honest early state of the project. It is also a weak long-term answer for a product positioned as a European office-sovereignty layer.

The governance questions are concrete. Who can become a member? Who has commit rights? Who decides format defaults? Who approves releases? Who handles security embargoes? Who owns trademarks? Who controls the website? Who pays maintainers? How are conflicts between Nextcloud, IONOS and smaller contributors handled? What happens if a major partner leaves? Can a public administration influence the roadmap? Are decisions documented?

The Document Foundation exists partly to answer those questions for LibreOffice. It gives the project an independent legal and institutional home. That does not make LibreOffice perfect, but it gives users a clearer steward. Euro-Office does not yet appear to have that level of structure.

A sovereignty project without durable governance asks users to trust a coalition mood. That is not enough for long-lived public documents.

Money also matters. Office suites are expensive to maintain. Compatibility work is endless. Browser collaboration is difficult. Security work requires experienced engineers. Localization, accessibility and documentation need ongoing labor. A project can begin with partner enthusiasm but still struggle if funding is not predictable.

Euro-Office’s backers should publish a maintenance model. It does not need to reveal every commercial detail, but it should explain how core development is funded, how community contributions are reviewed, how security issues are handled, and how long-term support versions will work. Buyers need this information before they can treat the project as infrastructure.

Governance is also where the ODF dispute should be resolved. If format policy is decided by the partners most focused on Microsoft compatibility, critics will remain skeptical. If the project creates a standards and interoperability working group with ODF expertise, public test suites and external participation, it can begin to rebuild trust.

The project’s future depends less on whether it can win a press-cycle argument and more on whether it can become boringly reliable. Governance is how that happens.

Security will decide whether the launch earns trust

Security is often invoked in sovereignty discussions, but office software gives it a special edge. Documents carry untrusted content. They arrive from outside parties. They may include macros, embedded objects, links, images, metadata, comments, tracked changes and hidden data. A collaborative online editor sits near storage, identity and sharing systems. That makes it part of the attack surface.

Nextcloud’s May post said the first stable Euro-Office release would prioritize stability and security. That is the right launch priority. It also needs proof. Public-sector buyers will ask how vulnerabilities are reported, triaged, patched and disclosed. They will ask whether the code can be built independently, whether dependencies are tracked, and whether security advisories are published.

A forked code base adds complexity. Euro-Office inherits some upstream architecture and bugs from ONLYOFFICE while taking responsibility for its own changes. If it diverges quickly, backporting fixes may become harder. If it stays close, it remains dependent on understanding upstream changes. Either way, security maintenance requires discipline.

The security claim of an open-source office suite is not “anyone can inspect the code.” The claim is credible only when someone is clearly responsible for inspection, response and repair.

For a web-based editor, administrators also need deployment guidance. Which services run? Which ports are exposed? How is document conversion isolated? How are temporary files handled? How are sessions secured? How are permissions enforced between the editor and the storage platform? What logs are created? What metadata is retained? How does the system behave under multi-tenant hosting?

These questions affect the sovereignty story. European hosting means little if the application layer is poorly isolated or hard to audit. Open-source licensing means little if deployments rely on opaque binaries, undocumented build steps or unclear dependency chains. Euro-Office’s GitHub page criticizes its upstream partly for binary blobs, obfuscated code and transparency concerns. That criticism raises the standard for Euro-Office itself. It must be cleaner than what it criticizes.

Security also intersects with document formats. Complex file formats create parsing risks. Compatibility with Microsoft formats expands the number of structures the editor must handle. Strong OOXML support is useful, but it increases the amount of format-handling code that must be tested. ODF support needs the same care.

A trustworthy Euro-Office release should publish security documentation early, not after the first public incident. It should invite independent review and make its build and dependency process clear. In sovereignty software, auditability is not a bonus feature. It is part of the product.

The format defaults and institutional consequences

Format defaults and institutional consequences

The table shows why a single format answer rarely fits every workflow. A credible sovereign office deployment needs policy-based defaults: ODF where the institution controls the document, OOXML where exchange demands it, and stable publication formats for final records.

Migration reality favors hybrid format policies

A clean break from Microsoft formats is attractive on paper and rare in practice. Institutions have document archives, external partners, templates, forms, macros, spreadsheets, and staff habits built over years. A migration that ignores that inheritance will fail.

Hybrid policies are more realistic. They start by classifying document workflows. Internal drafts, committee minutes, policy documents, templates and editable records may move to ODF. External submissions and partner exchanges may remain in DOCX or XLSX during a transition. Published records may use PDF or archival formats. Complex spreadsheets may require special review before migration.

Euro-Office could support this reality well if it gives administrators granular controls. Instead of one global default, deployments could define defaults by workspace, file library, department or document type. Users working in an internal policy folder could create ODT files by default. Users collaborating with external vendors could create DOCX files. Administrators could set warnings or conversion prompts based on policy.

This approach also avoids a false debate between purity and practicality. ODF-first advocates are right that new controlled documents should not default to Microsoft formats. Compatibility advocates are right that organizations cannot stop receiving Microsoft files overnight. The migration question is not whether OOXML disappears on day one. It is whether its use begins shrinking in the places the institution controls.

Hybrid policy requires documentation. Staff need to know which format to use for which purpose. Templates need to be cleaned and recreated. Records managers need to define archival rules. IT teams need to monitor format distribution. Support desks need answers for conversion problems. Legal departments need confidence that official versions are preserved.

Open-source office migrations often fail because they treat software installation as the migration. The harder work is document governance. Euro-Office’s partners should build migration kits around this fact. A sovereign office suite should ship not only code but policy templates, training notes, compatibility matrices and format decision trees.

The format transition also needs metrics. An administration can track the percentage of new internal documents created in ODF, the number of external OOXML exchanges, the conversion error rate, the number of legacy templates migrated, and the departments still dependent on Microsoft-only features. Without metrics, sovereignty remains a statement.

Euro-Office’s current controversy could become a useful catalyst if it pushes the project toward these tools. Instead of arguing only about the default, it could show how serious deployments should move from Microsoft-format dependence to open-standard control.

Public-sector users need editable documents, not symbolic software

Public-sector employees are not test subjects for ideology. They need tools that work. A clerk drafting a letter, a teacher preparing material, a lawyer reviewing comments, a policy officer editing a briefing, or a finance team maintaining a spreadsheet should not be forced into poor software because it carries the right political label.

This is why Euro-Office’s compatibility pitch should not be dismissed. Users need familiar workflows and reliable document handling. If an open-source office suite cannot handle common files, the migration will be blamed on open source itself. That damages the wider ecosystem.

The Foundation’s warning should be read with this reality in mind. It is not enough to say ODF is better for sovereignty. ODF-based workflows must be good enough that employees can do their jobs. LibreOffice and Collabora have carried much of that burden, but web collaboration remains an area where users compare alternatives directly with Microsoft 365 and Google Workspace.

Euro-Office enters because the market still wants better answers. Users expect simultaneous editing, comments, sharing, track changes, presence indicators, responsive performance and easy document opening from the browser. The old model of emailing files back and forth is no longer acceptable in many organizations. A sovereign office stack must match enough of that behavior to feel usable.

Symbolic software fails when it makes daily work worse. Sovereign software earns trust when users stop thinking about the politics because the workflow holds.

That does not mean every feature of Microsoft 365 must be copied. European alternatives can make different product choices. But they must be honest about missing features and strong where public buyers care most: reliability, privacy, auditability, interoperability, accessibility, localization and support.

Editable documents are the center. If users create ODF files but cannot collaborate smoothly, they will revert to Microsoft formats or Microsoft tools. If they create DOCX files smoothly but remain tied to Microsoft behavior, the sovereignty claim weakens. If they cannot trust conversion, they will keep old licenses as a safety net.

The product must earn confidence through boring daily success: open the file, edit it, save it, share it, reopen it, export it, archive it, and recover it years later. That is a harder standard than a launch announcement.

Euro-Office’s first public test is therefore not only whether the code runs. It is whether real users can build work habits around it without feeling they have joined a political experiment.

Sovereignty cannot be delegated to hosting alone

European hosting is a necessary part of sovereign cloud strategy. It addresses jurisdiction, procurement, support, data location and provider accountability. But office-suite sovereignty cannot stop at the data center door.

A document platform has several dependency layers. There is the infrastructure layer, where servers run. There is the application layer, where editing and collaboration happen. There is the identity and access layer, where permissions are enforced. There is the format layer, where content is structured. There is the governance layer, where future changes are decided. Weakness in any layer limits control.

Euro-Office’s public story is strongest at the infrastructure and ecosystem layers. European partners, open-source code and integration with platforms such as Nextcloud give it a credible place in sovereign cloud discussions. The Foundation is attacking the format layer. The ONLYOFFICE dispute raises questions about the code and license layer. Governance remains early.

A sovereign workplace stack is only as independent as its least controlled critical layer. If documents are tied to Microsoft formats, if code governance is unsettled, or if legal questions linger, European hosting cannot carry the entire claim.

This distinction matters because “sovereign cloud” is becoming a crowded label. Providers use it to mean local data centers, local legal entity, EU jurisdiction, encryption, open source, portability, auditability, or some mix of these. Buyers need to ask which layer is actually sovereign. Euro-Office’s dispute is a case study in why.

For office software, the most durable sovereignty comes from the combination of open code, open formats, independent governance, local deployability, support competition, and migration paths. A project does not need to be perfect on day one, but it needs a credible roadmap and honest labels.

Euro-Office could become a useful part of this stack if it treats sovereignty as a layered promise. It can say: our infrastructure partners are European; our code is open; our governance is being formalized; our Microsoft compatibility supports transition; our roadmap moves ODF into a first-class default position; our security processes are public. That would be a defensible staged claim.

What it should avoid is a simplified story in which European origin solves everything. That story invites exactly the kind of criticism The Document Foundation delivered.

The European cloud agenda raises expectations

The Euro-Office launch also sits inside a wider European cloud-policy agenda. The European Commission has been pushing secure, interoperable and sustainable cloud and edge infrastructure, with targets around business cloud adoption and edge nodes by 2030. Its June 2026 Cloud and AI Development Act proposal aims to expand European data center capacity and meet AI and cloud needs by 2035.

That agenda gives software projects a bigger stage. A sovereign office suite is not only an application; it is part of a European workplace cloud stack that might include storage, identity, mail, calendar, chat, video, project management, knowledge bases, and document editing. Euro-Office’s partners come from several of those adjacent areas.

The strategic question is whether Europe can assemble an integrated productivity stack without simply replicating the dependency patterns of the dominant American suites. That requires more than local hosting. It requires open APIs, open formats, portable data, interoperable identity, transparent governance and viable commercial support.

Euro-Office addresses one of the hardest layers because office documents remain the daily interface of organizational work. A cloud strategy without editable document independence is incomplete. Users may store files in a European cloud while editing them in Microsoft Office. They may collaborate in a local platform while sending every final draft as DOCX. They may adopt open-source storage and still keep Microsoft licenses because the document layer is not trusted.

The European cloud agenda turns document editing from an application choice into infrastructure policy. That raises the pressure on Euro-Office to be clear about formats, governance and compatibility.

The Commission’s open-source strategy also emphasizes open alternatives to non-EU proprietary solutions and reduced lock-in. Euro-Office’s pitch fits that language, but TDF’s criticism shows how easily a project can use policy language while leaving a lock-in vector untouched.

This is not unique to Euro-Office. Many sovereignty projects face the same tension. A cloud provider may reduce dependency on one hyperscaler but rely on proprietary control panels. A secure communication product may use open protocols but closed clients. An AI stack may use European servers but depend on foreign model providers. Sovereignty is not a label. It is a stack of choices.

Euro-Office’s format choice is one of those choices. It will affect whether the project becomes a genuine European office layer or a local wrapper around familiar document dependence.

Search visibility will be shaped by trust, not only keywords

Euro-Office is entering the public conversation through a dispute. That has search consequences. The phrase “Euro-Office” will now be associated not only with “European office suite” and “sovereign office” but also with The Document Foundation, LibreOffice, OOXML, ODF, ONLYOFFICE, licensing, Nextcloud, IONOS and document lock-in.

For a new software project, early search intent matters. Users will search whether Euro-Office is open source, whether it is based on ONLYOFFICE, whether it supports ODF, whether it is legal, whether it is a Microsoft 365 alternative, whether Nextcloud uses it, and whether LibreOffice supports or opposes it. The project’s public documentation needs to answer these questions directly.

A vague site will lose the narrative to critics and news coverage. A strong site will publish precise pages: licensing, governance, format support, ODF roadmap, Microsoft compatibility, security, contributor rules, partner responsibilities and migration guidance. These pages are not only documentation. They are trust assets for search engines, journalists, procurement teams and AI answer systems.

The best SEO strategy for Euro-Office is not louder sovereignty wording. It is source-backed clarity. Search systems reward pages that answer real questions with specific, verifiable information. Public buyers reward the same behavior.

The Document Foundation already has strong topical authority around LibreOffice, ODF and document standards. Its criticism will likely rank for related searches. Linuxiac’s report adds an independent technology-news layer. ONLYOFFICE’s licensing complaint adds another search cluster. Euro-Office cannot assume its launch announcement will define the project alone.

This is especially true because the dispute touches evergreen terms: ODF vs OOXML, open-source office suite, European digital sovereignty, ONLYOFFICE fork, Nextcloud Office, Microsoft 365 alternative. These terms will stay relevant after the launch day passes.

Euro-Office’s backers should treat the criticism as a documentation backlog. Every unanswered claim should become a public page or issue. Does Euro-Office default to OOXML? If yes, why, and can admins change it? What is the ODF timeline? Which standard versions are targeted? What compatibility tests exist? Who governs the project? What license compliance review was done? Which binaries are included? Who handles security?

Answering these questions will not eliminate criticism, but it will move the project from messaging conflict to evidence. That is where trust is built.

The Microsoft 365 alternative label sets a high bar

Euro-Office has been positioned as an alternative to Microsoft 365 and Google Workspace, but that label is bigger than an editor. Microsoft 365 is not only Word, Excel and PowerPoint. It is identity, storage, mail, calendar, Teams, SharePoint, compliance tooling, endpoint integration, admin controls, security features, mobile apps, automation, templates and support.

Euro-Office is one part of a wider stack. It needs Nextcloud and partner services around it to make the Microsoft 365 alternative claim credible. A document editor alone cannot replace Microsoft 365. A sovereign workplace suite must cover enough adjacent workflows that users do not keep returning to Microsoft for the missing pieces.

This distinction protects Euro-Office from unfair expectations, but it also constrains its marketing. If the project is presented as the office component inside a broader European collaboration stack, the claim is more realistic. If it is presented as a direct Microsoft 365 replacement, users will compare it against a huge bundle and find gaps.

The fair test is whether Euro-Office strengthens European open-source workplace stacks enough to reduce dependence on Microsoft 365 in specific deployments. That is more precise than saying it replaces Microsoft 365.

Google Workspace is a different comparison. It is cloud-native, browser-first and collaborative by design. Euro-Office’s web orientation puts it closer to that model than LibreOffice’s desktop default. But Google’s strength lies in smooth collaboration and integration across services. Euro-Office must therefore prove performance and reliability in simultaneous editing, not only file-format support.

Microsoft 365 remains the bigger document-format reference because of DOCX, XLSX and PPTX. Google Workspace often exports and imports Microsoft formats because the wider world expects them. That shows how deeply Microsoft’s formats shape even competing cloud suites. Euro-Office’s OOXML default, if confirmed as TDF says, would place it within that same gravity field.

The path to a credible alternative is incremental. Euro-Office must first be a trusted editor option inside Nextcloud and partner platforms. Then it must prove document fidelity, ODF maturity, collaboration quality and security. Then it must support migration programs for real institutions. Only then can the broader stack compete credibly with the dominant suites.

The “alternative” label attracts attention. It also invites harsh comparison. Euro-Office should use it carefully.

User familiarity is a double-edged product goal

Nextcloud’s March announcement described Euro-Office as addressing a need for Microsoft format compatibility, a familiar user experience and digital sovereignty. Those three goals do not always fit neatly together.

User familiarity lowers resistance. If buttons, menus, collaboration behavior and file types resemble what people already know, training costs drop. Employees are less likely to reject the tool before trying it. Departments can run pilots without turning every workflow into a migration workshop.

But familiarity can preserve the old mental model. If an office suite looks like Microsoft Office, saves like Microsoft Office, and speaks first in Microsoft formats, users may not learn the difference between compatibility and independence. They may treat Euro-Office as a cheaper or local imitation rather than a different governance model for documents.

A sovereign user experience should be familiar enough to work and different enough to teach better defaults. That is a subtle design challenge. The product cannot punish users with unfamiliarity. It also cannot hide the format policy so deeply that users keep reproducing old dependencies.

Good interface design can help. The save dialog can explain organization defaults without lectures. Admin policies can preselect ODF where appropriate. Templates can be provided in open formats. Export options can make external DOCX exchange easy but visibly separate from the internal master file. Warnings can appear only when a user is about to lose features or violate policy.

Documentation matters too. Many users do not know what ODF or OOXML means. They see file extensions. Euro-Office can explain the difference in plain language: ODF is the organization’s preferred editable format for internal work; Microsoft formats are used when exchange with external partners requires them. That kind of wording turns standards policy into daily guidance.

The danger is copying Microsoft’s format-first assumptions because they are familiar. Familiarity is a product tactic, not a sovereignty principle. Euro-Office should borrow what helps users work, not what keeps them locked into the old ecosystem.

ODF support needs tests that ordinary buyers can understand

ODF support cannot remain a checkbox. If Euro-Office wants to answer The Document Foundation credibly, it needs visible evidence. That evidence should be readable by ordinary administrators, not only standards experts.

A useful ODF test program would include sample text documents, spreadsheets and presentations. It would cover comments, tracked changes, styles, tables, headers, footers, footnotes, images, charts, formulas, conditional formatting and collaborative editing. It would show how files behave across Euro-Office, LibreOffice and Collabora. It would list known limitations.

This is not glamorous work, but it is decisive. Public buyers need to know whether ODT is safe for policy drafts, whether ODS is safe for budget sheets, whether ODP is safe for presentations, and where conversion may cause trouble. Without this information, they will default to the format their users already trust, which often means Microsoft formats.

The ODF argument becomes persuasive when it is backed by working files, not only standards references.

Euro-Office should also define which ODF version it targets and how it handles extensions. OASIS approved ODF 1.3 in 2020, and ISO’s ODF standardization history gives public buyers a standards reference. But standards references alone do not tell users whether their documents will survive editing.

A public compatibility dashboard would help. It could separate core support, partial support and unsupported features. It could show recent fixes and test coverage. It could allow community submissions of problematic documents after sanitization. It could link bugs to roadmap items.

The same should exist for OOXML. A project that claims Microsoft compatibility should expose its limits. Users deserve honesty before they move workflows. A compatibility matrix is not an admission of weakness; it is a sign of maturity.

The Document Foundation’s criticism gives Euro-Office a chance to build the best public format-support documentation in the European office market. That would turn a reputational problem into an asset. It would also pressure other projects to improve their own transparency.

The ONLYOFFICE fork gives Euro-Office speed and baggage

Forking ONLYOFFICE gives Euro-Office a head start. Building a browser-based collaborative office editor from scratch would be slow, expensive and risky. Starting from an existing AGPL code base means the project can focus on governance, integration, branding, ODF work, sovereignty positioning and partner deployment.

The GitHub page says Euro-Office is based on ONLYOFFICE’s open-source AGPL codebase and explains the fork through concerns about collaboration, transparency, code comments, binary elements, product decisions and the origin of the company behind ONLYOFFICE. Those are Euro-Office’s claims, not a court finding. Still, they show why the fork is part of the project’s identity.

Speed matters. The European market does not want a ten-year promise. Public bodies and companies need alternatives now, especially as cloud-sovereignty debates become procurement decisions. A fork can compress development time.

Baggage also matters. Forks inherit architectural decisions, code quality, security assumptions, licensing history and community perceptions. A fork that begins with a public dispute must earn trust from both open-source developers and enterprise buyers. It cannot rely on the upstream project’s reputation while rejecting upstream governance.

Euro-Office’s technical inheritance is both its launch advantage and its credibility burden.

The fork also influences format strategy. ONLYOFFICE’s market reputation has long been tied to strong Microsoft format compatibility. That may explain why Euro-Office appears comfortable placing OOXML near the center. But a European sovereignty fork should not merely localize an existing compatibility-first model. It should examine which assumptions need to change.

If Euro-Office keeps the strengths of the base while shifting governance, transparency and format policy, the fork could be justified. If it mainly rebrands an OOXML-centered editor with European partners, critics will keep pressing.

The project’s public repository should make divergence visible. Which upstream components remain? Which have been removed? Which binaries were replaced? Which comments were translated? Which build steps are reproducible? Which format-handling areas are being rewritten? Transparency turns fork baggage into evidence of stewardship.

Forking is only the first act. Maintaining is the test.

The dispute exposes a split inside European open source

The Euro-Office conflict is also a cultural split. One side prioritizes practical adoption against Microsoft 365 and Google Workspace. The other prioritizes open standards and long-term document independence. Both sides claim to serve European sovereignty. They disagree about the path.

The adoption camp sees the market as it is. Users live in Microsoft formats. Organizations need cloud collaboration. Buyers expect familiar interfaces. A product that insists on pure open-format workflows before users are ready may lose before it starts. From this view, strong OOXML support is the price of entry, not a betrayal.

The standards camp sees the market trap. If every alternative centers Microsoft formats because users expect them, the format monopoly never weakens. Europe ends up paying different providers while still structuring its documents around Microsoft’s universe. From this view, OOXML defaults are not pragmatism. They are surrender at the most durable layer.

Both camps are responding to real failure modes. Open-source products fail when they ignore user workflow. Sovereignty projects fail when they preserve the dependency they claim to escape.

The split is not new. It has shaped office-suite debates for decades. What is new is the policy environment. European governments are now more receptive to digital-sovereignty arguments, and open source is part of official strategy. That raises the cost of internal fragmentation. If European projects fight publicly without producing clearer standards, dominant vendors benefit.

The way out is not rhetorical unity. It is clearer product commitments. Euro-Office can state its migration philosophy, set ODF milestones, publish compatibility tests, and create governance seats for standards expertise. The Document Foundation can push hard on format principles while acknowledging the real need for high-fidelity Microsoft import/export and browser collaboration.

A mature European office ecosystem would treat ODF as the preferred sovereign default, OOXML as a necessary compatibility channel, and user workflow as the adoption battleground. It would not pretend these priorities never conflict. It would design for the conflict.

The current dispute is uncomfortable, but it may be useful if it forces that design work into public view.

Europe’s office layer needs less theatre and more discipline

The phrase “sovereign office suite” is attractive because it compresses a complex ambition into three words. It also invites theatre. A launch event can look like progress. A partner list can look like industrial strength. A GitHub repository can look like openness. A format-support line can look like interoperability.

Office software does not reward theatre for long. It rewards discipline. Users open documents. Administrators read logs. Security teams scan dependencies. Lawyers review licenses. Records managers inspect formats. Translators find missing strings. Accessibility teams test screen readers. Finance teams test spreadsheets. The work exposes weak claims quickly.

Euro-Office has enough substance to deserve attention. It has visible partners, a known technical base, a real market need and a timely sovereignty narrative. It also has enough unresolved issues to deserve scrutiny. The Foundation’s criticism is not a reason to dismiss it. It is a reason to demand proof.

A serious European office project should welcome hard questions before launch rather than after public bodies depend on it.

The same standard applies to its critics. The Document Foundation’s argument is strongest when it stays concrete: history, native format, ODF, OOXML, lock-in, default behavior. It weakens if it becomes a general rejection of any project that prioritizes Microsoft compatibility. Users need compatibility. Sovereignty must be built through migration, not denial.

The best outcome would be boring and productive. Euro-Office corrects or narrows its “first” claim. It publishes a format policy. It makes ODF a first-class admin default and roadmap item with dates. It documents license compliance. It formalizes governance. It publishes compatibility tests. The Foundation continues to press for ODF while engaging on practical interoperability. Buyers get clearer choices.

That outcome is possible. It requires the project to treat criticism as infrastructure work, not as reputational sabotage.

The next milestone is the default, not the announcement

Launch dates create headlines. Defaults create habits. Euro-Office’s June 9 availability may introduce the product to more users, but the most consequential milestone will be the format behavior those users meet when they create a document.

If the first save is OOXML, TDF’s criticism will remain central. If administrators can switch defaults to ODF easily, the debate changes. If ODF support is weak, the option will look symbolic. If ODF support is strong and documented, Euro-Office gains a credible sovereignty answer.

The product should make the default visible in public documentation. A simple page titled around document formats could state the default behavior, available admin controls, ODF roadmap, Microsoft compatibility scope, export options and known limitations. It should use exact file extensions and standard names. It should avoid vague phrases like “full compatibility” unless backed by tests.

The default is the product’s silent constitution. It tells users what the suite believes a normal document should be.

Euro-Office’s backers may be tempted to defer the format debate until after adoption. That would be a mistake. Once users create documents at scale, changing defaults becomes harder. Templates multiply. Training material is written. Support habits form. Departments resist disruption. The launch period is the right moment to set direction.

The Foundation’s criticism gives Euro-Office cover to make a stronger choice. If the project moves ODF forward quickly, it can say the community challenge improved the roadmap. If it does not, critics will say the sovereignty language was shallow.

A public milestone could help: ODF-first admin mode by a defined date, with full collaborative editing tests for ODT, ODS and ODP; compatibility reports across LibreOffice and Collabora; migration documentation for public administrations; and a clear exception path for Microsoft-format exchange. That would not be perfect, but it would be measurable.

The product that wins trust will be the one whose defaults align with its promises.

The right answer is not anti-Microsoft purity

The Euro-Office dispute can easily be misread as a demand that European software reject Microsoft formats entirely. That would be impractical and, in many organizations, damaging. Public bodies and companies must exchange documents with the world as it exists.

A court may receive DOCX filings. A small business may send XLSX price sheets. A university may use DOCX templates for grant applications. A ministry may collaborate with contractors who use Microsoft Office. A sovereign office suite that cannot handle those files well will force users back to Microsoft.

The Foundation’s strongest argument is not that OOXML should never be used. It is that OOXML should not be the default foundation for new sovereign documents. That is a different claim. It leaves room for import, export and external collaboration while asking the institution to choose ODF where it controls the workflow.

The practical policy is not “ban OOXML.” It is “stop creating avoidable dependency through default OOXML use.”

Euro-Office should embrace this distinction. It can advertise strong Microsoft compatibility without making Microsoft formats the institutional home. It can support users who need DOCX while nudging internal work toward ODT. It can make export easy without making export formats the master copy. It can treat OOXML as a bridge to external ecosystems and ODF as the domestic format of sovereign collaboration.

This framing would also reduce unnecessary conflict with users. Many employees resent format debates because they sound like ideology imposed on daily work. A policy that respects their exchange needs while quietly improving internal defaults is more likely to succeed.

The hard cases will remain. Complex spreadsheets may stay in XLSX longer. Macro-heavy workflows may need redesign. PowerPoint-heavy departments may resist ODP. External collaboration may require Microsoft formats. No serious migration plan should pretend otherwise.

The point is direction. Each new internal document created in ODF reduces future dependency. Each template migrated to ODF lowers switching cost. Each workflow that uses ODF natively makes the next migration easier. Euro-Office can be part of that direction if it chooses.

Open standards need product love, not only policy support

ODF has the policy argument. But policy alone will not win users. Open standards need products that make them pleasant, reliable and boring. If ODF workflows feel second-class, users will not adopt them willingly.

This is where the European office ecosystem must be honest. Many users judge documents by layout fidelity, speed, collaboration features, comments, track changes and spreadsheet behavior. They rarely care which standard is more vendor-neutral. If the open format creates visible friction, the policy case loses influence.

Euro-Office could make a contribution here if it invests seriously in ODF user experience. Because it is web-based, it can shape how collaborative ODF editing feels in the browser. It can improve presence, comments, simultaneous editing, autosave and sharing for ODT, ODS and ODP. It can integrate ODF templates into Nextcloud spaces. It can make ODF the path of least resistance for internal collaboration.

Open standards win when users do not feel punished for choosing them.

This requires engineering resources. It also requires design choices. A product can technically support ODF while placing most polish around DOCX workflows. Users will notice. Support teams will notice. Critics will notice.

The project’s roadmap should therefore name ODF features, not only ODF support. Collaborative tracked changes in ODT. Spreadsheet formula compatibility in ODS. Presentation layout stability in ODP. Template management. Round-trip tests with LibreOffice. Accessibility checks. Performance benchmarks. These are the details that turn a standard into a daily tool.

The Foundation and Collabora could also contribute to a broader ecosystem approach. Cross-project test suites would help all vendors. Shared bug categories around ODF interoperability would reduce fragmentation. Public-sector pilot reports could show which workflows migrate cleanly and which need work.

European sovereignty will not be achieved by one suite alone. It needs a culture where open formats receive the same product attention proprietary formats receive from dominant vendors. Euro-Office’s controversy reveals that need.

Branding must respect the community it wants to serve

Open-source communities are unusually sensitive to credit because credit is part of the economy. Contributors give code, testing, translation, documentation, bug reports and institutional knowledge. When a new project enters with sweeping claims, older contributors hear a signal about whether their work will be acknowledged.

Euro-Office’s “first” framing ran into this sensitivity. The Foundation’s response was predictable because the claim touched historical legitimacy. OpenOffice.org and LibreOffice are not obscure side projects. They are central to the open-source office story. A European project that overlooks them looks careless at best and opportunistic at worst.

Branding is not only external marketing. It is how a project positions itself to potential contributors. Developers who worked on LibreOffice, Collabora or related standards efforts may hesitate to engage with a project that appears to minimize their lineage. Publicly correcting the claim would be a cheap way to reduce friction.

Respecting history does not weaken Euro-Office. It makes its own claim more credible. A project that says “we build on Europe’s long open-office tradition while targeting modern collaborative workflows” sounds more mature than one implying the tradition did not exist.

The same applies to the ONLYOFFICE fork. Euro-Office can criticize upstream governance and transparency while still being exact about what it inherited. Forks should be honest about debts. They can explain why a fork was needed, what was changed, and what remains from the original project. That honesty makes the fork stronger.

Open-source branding should be precise because the community will check it. If claims are overstated, critics will find them. If source code is missing, critics will ask. If format defaults contradict slogans, critics will test. That scrutiny is not an enemy of sovereignty. It is one of the reasons open source can be trusted.

Euro-Office’s supporters should treat community criticism as part of the launch environment. The project is asking to serve organizations that care about independence. It should expect those organizations and their advocates to examine every independence claim closely.

The public record problem is bigger than office suites

The format dispute has a public-record dimension that deserves more attention. Governments do not merely collaborate on documents. They create records that may need to survive for decades. Laws, budgets, decisions, meeting minutes, procurement files, court materials and citizen communications become part of institutional memory.

A file format choice made for short-term convenience can create long-term archival cost. If records are stored in formats whose faithful rendering depends on a dominant vendor’s application, future access becomes less certain. Even when specifications exist, complex files may rely on product behavior, fonts, macros, embedded objects or layout assumptions that are hard to reproduce.

ODF’s appeal is strongest here. It gives administrations a vendor-neutral editable format for documents they control. PDF or PDF/A may be used for final fixed records, but editable source files still matter when documents must be updated, translated, reused or audited.

Public records should not depend on a single vendor’s office behavior for their future meaning. That is the archival heart of the ODF argument.

Euro-Office’s web-collaboration design introduces another records question: where do document histories live? Collaborative tools often store versions, comments, suggestions and metadata. Public-sector deployments need policies for retaining or deleting that information. A sovereign office suite should document how it handles version history, comments, authorship metadata, change tracking and exports.

This is also where ODF and OOXML are not only technical choices but records-management choices. Which format preserves comments best? Which handles tracked changes across tools? Which can be validated? Which is accepted by national archives or public-sector guidelines? Which is easiest to migrate in bulk? These questions determine long-term cost.

Euro-Office’s early documents should speak to records managers, not only IT administrators. If the project wants public-sector credibility, it should publish guidance for official records, internal drafts, external exchange and archival exports. It should align with national and European open-standard policies where possible.

The Foundation’s criticism points toward this wider concern. A format default is not a small preference when the documents become public memory.

Business buyers will ask a different version of the same question

The Euro-Office debate is not only about governments. Businesses also care about dependency, cost, data control, compliance and interoperability. They may not use the language of ODF policy, but they face the same document risks.

A company that stores contracts, proposals, board decks, HR policies, financial models and technical documentation in proprietary-default formats depends on the tools that handle those formats best. If licensing prices change, vendor terms shift, cloud features are bundled differently, or data-governance rules tighten, switching becomes expensive.

Euro-Office’s Microsoft compatibility will appeal to businesses because it reduces disruption. A company does not want to tell clients it cannot open their files. It also may not care whether ODF is the default for all internal work. But it should care about avoiding unnecessary lock-in where it controls the process.

For business buyers, ODF is not ideology. It is exit cost reduction. The more internal editable documents are stored in vendor-neutral formats, the easier it becomes to change tools, negotiate contracts and preserve records.

Businesses also need governance clarity. A company adopting Euro-Office through a provider will ask who supports it, who patches it, what happens if the fork dispute escalates, whether the editor integrates with identity systems, whether mobile access exists, and whether data stays inside agreed jurisdictions.

The format policy may be less formal than in government, but it still affects daily work. Legal departments may require DOCX for external contract exchange. Internal knowledge bases may prefer ODF or platform-native formats. Finance teams may resist spreadsheet migration. Marketing teams may need presentation fidelity. A practical deployment will segment workflows.

Euro-Office could package business guidance around these realities. It could offer recommended policies for professional services, regulated sectors, small businesses and public contractors. It could show where ODF makes sense and where Microsoft formats remain practical.

The business case for Euro-Office will not be won by purity. It will be won by reducing dependency without making work harder. The same product design that answers The Document Foundation can also improve the commercial pitch.

The role of PDF should not be confused with editable freedom

Many organizations respond to format debates by saying final documents are published as PDF. That solves only part of the problem. PDF is useful for fixed presentation, distribution and archiving. It is not a replacement for editable source documents.

A public administration may publish a law, guide or report as PDF, but the editable version still exists somewhere. It may need revision, translation, accessibility remediation, reuse or legal review. If that editable source lives in a Microsoft-centered format by default, the institution remains dependent at the working-document layer.

Euro-Office’s supported formats include PDF alongside ODT, ODS, ODP and Microsoft formats. That breadth is useful. But the project should be clear about format roles. PDF for final distribution. ODF for editable sovereign records where possible. OOXML for exchange where required. TXT for plain text where appropriate. Mixing these roles creates confusion.

PDF is a publication format in many workflows, not the sovereign master file. Treating it as the answer to document independence leaves the editable layer unresolved.

This distinction matters for accessibility as well. Documents often need accessible structure before PDF export. If the source document is poorly structured, the PDF may inherit problems. A good office suite should support styles, headings, alt text, metadata and accessible export paths. Format choices affect that pipeline.

Public bodies also need version control. The PDF sent to citizens may be final, but drafts and source files need retention rules. Collaborative editors create comments and change histories that may themselves be records. Format policy must cover the whole lifecycle, not only final publication.

Euro-Office could strengthen its public-sector story by publishing lifecycle guidance: draft, review, approval, publication, archive. Each stage can have recommended formats and controls. That would turn the abstract ODF vs OOXML debate into operational governance.

The market will punish vague compatibility claims

“Compatible with Microsoft Office” is one of the most dangerous phrases in office software. It is necessary for marketing and often impossible to guarantee in the way users imagine. A file format family as complex as OOXML produces endless edge cases.

Euro-Office should avoid absolute compatibility language unless it is carefully scoped. Users will test it with the worst documents in their archive: old templates, heavily edited contracts, spreadsheets with strange formulas, presentations built around custom fonts, documents with nested tables and comments, files saved across multiple Office versions. Any failure will be treated as evidence against the product.

This is not unfair. It is how migration pilots work. The organization selects representative documents and sees what breaks. If too much breaks, the pilot dies.

Trustworthy compatibility language names limits before users discover them. It says which features are supported, partially supported or unsupported. It explains where layout differences may appear. It recommends safer workflows. It gives administrators tools to test their own document sets.

The same applies to ODF. If Euro-Office wants ODF credibility, it should not merely say it supports ODT, ODS and ODP. It should show which features work and where parity with DOCX workflows is still under development.

Public compatibility testing would also make the product easier to compare with LibreOffice and Collabora. Buyers could see which tool fits which workflow. The European ecosystem would become more transparent. Projects might compete on evidence instead of claims.

Euro-Office’s first stable release does not need perfect compatibility. No suite has that. It needs honest compatibility. The Foundation’s criticism creates pressure for that honesty around formats. The ONLYOFFICE fork dispute creates pressure for honesty around code origin and license. The sovereignty claim creates pressure for honesty around governance.

Vague claims may help launch messaging. They hurt procurement and long-term trust.

The dispute could improve Euro-Office if it changes the roadmap

Not every public criticism damages a project. Some criticism arrives early enough to improve design. The Foundation’s open letter came before Euro-Office’s public availability. That gives the project a chance to respond through changes rather than only statements.

The most useful response would be specific. First, clarify the “first European open-source office suite” claim. Second, publish the exact default format behavior. Third, provide ODF admin controls or a dated plan for them. Fourth, explain the ODF roadmap in feature terms. Fifth, publish license compliance documentation. Sixth, formalize governance. Seventh, release public compatibility tests.

A defensive response that repeats “we are sovereign” will not solve the problem. The criticism is about mechanisms. It needs mechanism-level answers.

Euro-Office can turn the dispute into credibility if it treats each criticism as a public deliverable.

This would also help Nextcloud and IONOS. Large partners do not benefit from ambiguity. Their customers will ask the same questions after reading the Linuxiac report, TDF letter or ONLYOFFICE complaint. Clear public answers reduce sales friction.

The Foundation’s role would then shift. It could continue to argue for ODF, but it would have concrete milestones to evaluate. If Euro-Office delivers ODF-first admin policy and strong ODF collaborative editing, the debate becomes more productive. If it does not, criticism will intensify.

The broader open-source community should want this outcome. Europe needs more viable open-source workplace tools, not fewer. But it needs them to be honest, interoperable and aligned with open standards. A flawed but responsive Euro-Office is more useful than a project that collapses under early criticism or ignores it.

The launch should be the start of evidence, not the end of argument.

A credible Euro-Office path still exists

The current dispute does not doom Euro-Office. It identifies the conditions under which the project can become credible. Those conditions are demanding but reachable.

The project should narrow its historical claim. It can acknowledge OpenOffice.org, LibreOffice and Collabora while explaining its own focus on modern web collaboration and European infrastructure. That would remove an avoidable fight.

It should treat ODF as a first-class policy target. That means more than file support. It means ODF defaults where appropriate, ODF collaborative editing, ODF test suites, ODF templates, ODF migration guides, and ODF interoperability with LibreOffice and Collabora.

It should keep strong Microsoft compatibility while framing it as an exchange and migration feature. Users need DOCX, XLSX and PPTX. The project should serve that need without making Microsoft formats the unquestioned home of new sovereign documents.

It should settle or clearly document the ONLYOFFICE licensing issue. The project does not need every critic to agree, but it needs buyers to understand the legal basis for deployment.

It should formalize governance. A project seeking public-sector trust needs more than an interim contributor model. It needs rules, roles, security processes, decision records and a long-term maintenance plan.

It should publish evidence. Compatibility matrices, security documentation, build instructions, roadmap dates, test files and known limitations will do more for trust than slogans.

Euro-Office’s path is to become less grand in language and more serious in proof. That is not a downgrade. It is how infrastructure projects mature.

The demand for a European collaborative office layer is real. Microsoft 365 and Google Workspace will not be displaced by speeches. They will be challenged only by tools that work, integrate, migrate documents safely and reduce dependency over time. Euro-Office could be one of those tools if it chooses discipline now.

The Foundation’s critique should be uncomfortable for the project’s backers. It should also be useful.

The Foundation also has to meet the cloud-collaboration test

The Document Foundation is right to defend ODF and history. But the wider LibreOffice ecosystem must also face the user-experience expectations that drive interest in Euro-Office.

Many organizations want browser-first collaboration. They want multiple users editing the same file without downloads. They want document editing inside shared workspaces. They want easy sharing, comments, versioning and mobile access. The desktop suite model alone does not satisfy those workflows.

Collabora Online provides a LibreOffice-based answer, but the existence of Euro-Office shows that some providers and buyers still see gaps or want different trade-offs. The Foundation’s argument is stronger when the ODF-native ecosystem demonstrates that it can match modern collaboration needs.

ODF advocacy wins more users when paired with excellent collaborative software. Standards arguments are necessary, but product experience determines whether staff accept the change.

The LibreOffice ecosystem has a deep advantage in document standards and open-source legitimacy. It also has to keep improving web performance, integration, mobile workflows and usability. If Euro-Office pressures that ecosystem to improve, users benefit.

The danger is a split where one camp owns open standards and another owns practical collaboration. Europe needs both in the same products or at least in interoperable products that share a format direction. A buyer should not have to choose between ODF-first governance and acceptable browser collaboration.

The Foundation’s challenge to Euro-Office should therefore be read as both critique and reminder. It reminds new projects not to repeat old lock-in patterns. It also reminds older projects that users will choose tools that fit current workflows.

The healthiest outcome is competitive pressure around ODF-native collaboration. If Euro-Office improves ODF support because of the dispute, and LibreOffice-based tools continue improving cloud collaboration, Europe gets a stronger office ecosystem.

The public launch is only the beginning of the audit

Once Euro-Office becomes available, scrutiny will move from claims to behavior. Users will test the code. Administrators will inspect packages. Developers will read repositories. Competitors will examine licenses. Standards advocates will create ODF files and see what happens. Microsoft-format-heavy users will open complex DOCX, XLSX and PPTX files. Security researchers may look for weaknesses.

That audit will be public because the project is open source and politically framed. Every weakness may become a blog post, issue, thread or procurement concern. This is not unfair. A project claiming to support European digital sovereignty should expect inspection.

Euro-Office’s best defense is fast, transparent response. Fix bugs in public. Document limitations. Accept patches. Explain decisions. Publish release notes that mention format changes. Create a security page. Make governance visible. Thank critics when they find real problems.

Open source earns trust through visible correction. A flawless launch is unlikely; a disciplined response is possible.

The same applies to the format default dispute. If users confirm that OOXML is the default, the project should not hide behind general compatibility language. It should explain why, show how to change it, and state whether ODF-first defaults are planned. If the claim is inaccurate or incomplete, it should correct the record with exact behavior.

Public launch also tests partner alignment. Do Nextcloud, IONOS and other partners describe the product the same way? Do they give the same format guidance? Do they acknowledge ODF? Do they describe the licensing position consistently? Mixed messaging would deepen mistrust.

Euro-Office should coordinate a public knowledge base before the dispute defines it. The questions are already known. The answers should be ready.

Europe should avoid replacing one monoculture with another

The deepest lesson of the Euro-Office fight is that Europe should not seek a single office monoculture, even an open-source one. Monocultures create dependency. The healthier goal is an interoperable ecosystem built around open standards, portable data and competing implementations.

ODF is central because it allows multiple suites to create and edit documents without one vendor owning the reference behavior. LibreOffice, Collabora, Euro-Office and other tools should compete on implementation, workflow, support and integration while sharing a commitment to vendor-independent formats for documents institutions control.

Microsoft formats will remain part of exchange. That reality should be managed, not denied. But Europe’s long-term objective should be reducing the number of workflows where Microsoft formats are unavoidable.

Sovereignty is stronger when users can move between tools without moving their documents through a vendor-controlled gate.

This ecosystem view also reduces the stakes of one project. Euro-Office does not have to be the sole European office answer. LibreOffice does not have to solve every cloud workflow alone. Collabora does not have to carry the entire web-editor burden. Projects can specialize if formats and governance remain open enough.

The risk is that market pressure pushes all alternatives toward Microsoft-format mimicry because that is where immediate adoption lies. If every product takes that route, Europe ends up with many interfaces and one underlying dependency. That is the outcome the Foundation is warning against.

Avoiding it requires procurement policy. Public bodies should ask for ODF support and ODF defaults where appropriate. They should fund interoperability testing. They should accept transitional Microsoft compatibility while setting targets for open-format creation. They should avoid tenders that accidentally require Microsoft behavior by demanding exact compatibility with proprietary features.

Software projects follow market incentives. If buyers reward ODF-first deployments, vendors will invest in them. If buyers only ask whether DOCX works, vendors will chase DOCX forever.

The dispute clarifies the real meaning of office sovereignty

Euro-Office has made one thing clear before its public test: the word sovereignty is now contested at the office layer. It is no longer enough to say a product is European, open source or cloud-ready. Critics will ask what happens to the document itself.

The Document Foundation’s criticism may seem harsh because it arrived before users could judge the product. But the point of the criticism was to shape the terms of judgement. A sovereign office suite must be judged by history, native format, governance, license clarity, interoperability, security and migration path. The launch announcement is only one data point.

Euro-Office’s supporters are right that Europe needs practical alternatives to Microsoft 365 and Google Workspace. They are right that Microsoft format compatibility is needed for adoption. They are right that cloud collaboration matters. They are right that a European partner coalition can give open-source workplace software a stronger market route.

The Foundation is right that OpenOffice.org, LibreOffice and Collabora cannot be written out of the story. It is right that ODF belongs at the center of document sovereignty. It is right that OOXML defaults deserve scrutiny. It is right that compatibility with Microsoft formats should not be confused with escape from Microsoft dependency.

The strongest Euro-Office would combine both truths: pragmatic compatibility for today’s files and ODF-centered control for tomorrow’s documents.

That is the standard the project now faces. It can still meet it. But it must show the work.

Reader questions on Euro-Office, ODF and Europe’s document-sovereignty fight

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

The Document Foundation Slams Euro-Office Before Public Launch
Linuxiac report on The Document Foundation’s criticism of Euro-Office, including the disputed “first European open-source office suite” claim and the OOXML default issue.

An open letter to office suite users, just before the Euro-Office announcement
The Document Foundation’s June 8, 2026 open letter challenging Euro-Office’s positioning and warning against OOXML-centered document lock-in.

Euro-Office general availability set for June 9
Nextcloud announcement describing Euro-Office’s planned June 9, 2026 availability, integration plans and next development priorities.

Industry initiative launches Euro-Office as true sovereign office suite
Nextcloud press release announcing the European coalition behind Euro-Office and its positioning as a sovereign office alternative.

Euro-Office GitHub organization
Public Euro-Office GitHub page describing the project’s goals, supported formats, contributors, technical base and interim governance notes.

ONLYOFFICE flags license violations in Euro-Office project by Nextcloud and IONOS
ONLYOFFICE statement alleging license and intellectual-property violations in the Euro-Office fork.

Euro-Office license compliance and what open source means
Nextcloud’s response to the ONLYOFFICE licensing dispute and its explanation of the project’s open-source compliance position.

You cannot use the GNU AGPL to take software freedom away
Free Software Foundation analysis of AGPL-related licensing principles and limits on using additional terms to restrict software freedom.

GNU Affero General Public License version 3
Official GNU AGPLv3 license text, relevant to network software and source-code availability obligations.

Free Software Foundation releases GNU Affero General Public License version 3
FSF announcement describing the release and purpose of AGPLv3.

Open Document Format for Office Applications version 1.3
OASIS page for ODF 1.3, the open XML-based document format standard for office documents.

ISO IEC 26300-1 OpenDocument format
ISO page for the OpenDocument Format standard used for editable office documents.

ECMA-376 Office Open XML file formats
ECMA International standard page defining Office Open XML vocabularies and packaging requirements.

ISO IEC 29500-1 Office Open XML file formats
ISO page for the Office Open XML standard covering word-processing documents, spreadsheets and presentations.

Open XML SDK documentation
Microsoft documentation describing Office Open XML as an international standard based on ZIP and XML technologies.

Why OOXML is not a standard format for office documents
The Document Foundation’s critique of OOXML’s standardization history, complexity and relationship to Microsoft Office behavior.

ODF vs OOXML an issue that should never have existed
The Document Foundation’s explanation of its ODF-first position and its criticism of OOXML as a default document format.

Euro Office sovereign in name but what about the native document format
The Document Foundation’s earlier critique asking whether Euro-Office would use ODF as its native format.

LibreOffice open source and standard document format history
LibreOffice documentation summarizing the StarOffice, OpenOffice.org and LibreOffice historical timeline.

The Document Foundation history
Official history of The Document Foundation and its creation around LibreOffice in 2010.

LibreOffice timeline
LibreOffice timeline covering OpenOffice.org, The Document Foundation, LibreOffice releases and related project history.

Sun Microsystems contributes StarOffice source code to OpenOffice.org
OpenOffice.org press release on Sun’s release of StarOffice source code and the creation of the OpenOffice.org project.

Collabora Online based on LibreOffice technology
Collabora page explaining its use of the LibreOffice technology stack and relationship to LibreOffice development.

European Commission open source strategy
European Commission strategy page linking open source to technology sovereignty, interoperability and reduced lock-in.

European Commission open source software strategy
European Commission page describing its open-source software strategy, reuse goals and institutional open-source actions.

Study about the impact of open source software and hardware on technological independence, competitiveness and innovation in the EU economy
European Commission study page on the economic and technological role of open-source software and hardware in Europe.

Cloud computing and Europe’s digital strategy
European Commission page on cloud and edge infrastructure, interoperability, sovereignty and related European policy goals.