The Document Foundation, the non-profit behind LibreOffice, lobbed a fresh criticism at Microsoft on July 17, 2026, accusing the company of using its Office Open XML formats as a strategic tool to lock customers into the Microsoft 365 ecosystem. In a post titled “How proprietary formats have become Microsoft’s main tool for lock-in,” the foundation argued that subtle incompatibilities in DOCX, XLSX, and PPTX files force users back to Office, even when alternative software can technically open them. The claim lands as Microsoft’s own support documentation quietly acknowledges the same interoperability gaps—without using the term “lock-in.” For Windows users and the IT professionals who support them, the renewed debate isn’t just ideological noise; it’s a practical trigger to reexamine which file formats belong where in their workflows.

The Latest Salvo: What TDF Said—and What Microsoft Already Knew

The Document Foundation’s July post zeroes in on a reality many Office users ignore: that a file opening successfully in another application doesn’t guarantee faithful rendering, editable stability, or feature parity. “If a DOCX, XLSX, or PPTX file opens elsewhere but returns with shifted formatting, altered behavior, or reduced usability, users will predictably return to Microsoft Office,” the post states. This practical dependency, TDF argues, is the lock-in. It’s a sharper claim than previous broadsides because it sidesteps the “OOXML is proprietary” slogan and instead focuses on the friction users actually experience.

Microsoft’s own documentation for Word, Excel, and PowerPoint directly supports that concern—without naming it as lock-in. When you try to save an Office document as an OpenDocument (.odt, .ods, .odp) file, a warning appears: “Some formatting, content, or usability might be affected when you save this file in the OpenDocument format.” The company explains that applications implement features differently, so a converted file may be readable but not operationally identical. That’s a careful admission that OOXML-to-ODF round tripping isn’t lossless—something TDF’s community developers have stressed for years.

The real news here isn’t that the format wars are back; it’s that the two adversaries agree on the underlying problem. Interoperability failure hangs on document complexity, not just file extensions. A simple memo might survive a conversion intact, while a quarterly sales workbook with Power Query connections or a branded presentation with custom slide masters will almost certainly degrade. The question for Windows teams is no longer “which format is open?” but “which format preserves the specific behavior my workflow demands?”

What This Means for Your Workflow, Based on Your Role

The practical impact splits along typical Windows user profiles:

Home and small-office users who primarily create documents for their own use and rarely share editable files outside the Microsoft ecosystem can safely stick with DOCX, XLSX, and PPTX. The default formats deliver the richest feature set and smoothest collaboration if everyone in your circle uses Microsoft 365. Converting to ODF offers no meaningful benefit unless you’re actively transitioning to LibreOffice or another ODF-native suite.

Power users and cross-platform collaborators—writers swapping chapters with a Linux-using editor, researchers sharing data across tools, volunteers in open-source communities—should keep working copies in the native format of their primary application and save distribution copies in a format both sides can validate. For many, that means final drafts go out as ODF, not OOXML. But the crucial step is testing, not assuming. Open the ODF in the receiving application, check for missing content, formatting drift, and broken functionality before calling it done.

IT administrators and compliance officers face the toughest call. If your organization uses Microsoft 365 for daily collaboration, a blanket mandate to switch to ODF is likely to create more problems than it solves—disrupting active documents, rework, and user frustration. Yet a pure-OOXML policy chains long-term records to Microsoft’s application behavior indefinitely. The better path is a format policy keyed to document state and purpose, not a winner-takes-all decree.

The Long Road to Format Gridlock

To understand why this debate won’t disappear, a little history helps. Microsoft introduced the Office Open XML formats with Office 2007, later pushing them through a contentious ISO/IEC standardization process that produced two conformance classes: Transitional (the default, for legacy compatibility) and Strict (a cleaner subset). Meanwhile, the OpenDocument Format, backed by OASIS and then ISO/IEC, became the native format of OpenOffice and LibreOffice. For nearly two decades, the two standards have coexisted with on-and-off accusations of vendor lock-in.

The current flashpoint isn’t new. The Document Foundation has been building its case for years, most recently in a May 2025 comparison blog post that laid out seven areas where ODF benefits users: control, interoperability, transparency, long-term access, public-sector compliance, cost, and community-driven innovation. That post coincided with the build-up to ODF’s 10th anniversary as an ISO standard in May 2026—a milestone TDF has used to amplify its message. What makes the July 2026 attack different is its contextual timing: as governments from the UK to Taiwan continue to mandate ODF for public records, the pressure on organizations to justify their default OOXML choice grows.

Microsoft hasn’t stood still, either. Office 365/Microsoft 365 has added robust ODF 1.3 support, and the company participates in OASIS technical committees. But the fundamental architecture division persists: OOXML is defined by what Microsoft’s applications do, while ODF is defined by a published standard implemented by multiple independent codebases. That makes OOXML more feature-complete in Office, and ODF more consistent across non-Microsoft suites.

Your Next Steps: A Practical Format Strategy for Windows Environments

Windows administrators and power users can cut through the rhetoric with a tested, document-lifecycle approach. The goal isn’t to prove one format superior; it’s to assign each document the format that best serves its current purpose and future accessibility.

1. Classify your documents by collaboration intensity and retention need. Broadly, documents fall into three buckets:
- Active collaboration using advanced Office features: Keep these in DOCX, XLSX, or PPTX. Examples: monthly financial models with Power Query, co-authored proposals with tracked changes, multimedia presentations.
- Editable records that must outlive any single vendor’s application: Convert to ODF. Examples: internal policies, procedure manuals, public-facing reports required by regulation.
- Final, fixed-layout versions for distribution or archiving: Save as PDF/A. Examples: approved contracts, annual reports, archival submissions.

2. Test with real files, not just blank templates. Don’t rely on a “supports ODT” checkbox. Pick 10–20 representative documents from each bucket, including those with tables, text boxes, custom styles, and embedded objects. Open, edit, save, and reopen them in both Microsoft 365 and the target application (LibreOffice, OnlyOffice, etc.). Record any differences—not just catastrophic data loss, but also formatting shifts, formula errors, or broken cross-references.

3. Document conversion ownership. In mixed-suite environments, someone must be accountable for verifying conversions. If the accounting team exports an .xlsx policy workbook to .ods for a regulator, who opens that ODS file in LibreOffice and confirms it’s correct before submission? Build this step into your SOPs.

4. Avoid round-trip editing across suites without validation. The most dangerous scenario is a document that bounces between Word and an ODF editor multiple times. Each conversion can introduce subtle drift. If cross-suite editing is unavoidable, set a rule: at the end of each editing cycle, the file must be opened in the original application and visually scanned for anomalies.

5. Start with low-risk documents. Pick a handful of internal memos or meeting notes to pilot an ODF workflow. Gain confidence before migrating a department’s entire procedure catalog.

6. Leverage Microsoft’s own guidance. The company recommends that when collaborating between Word and other applications, users minimize formatting while drafting and check the final converted file carefully. That’s effectively an admission that conversion is a workflow stage, not a one-click operation. Treat it as such.

7. Designate an authoritative master for each record. A policy may require both a DOCX working copy and an ODF record copy, but someone must decide which is the source of truth. Don’t let users silently maintain parallel versions.

Where We Go from Here

The format debate will continue because software ecosystems evolve asymmetrically. Microsoft updates Office 365 monthly, LibreOffice releases semiannually, and PDF/A evolves at the pace of ISO committees. The gap between what DOCX can express and what ODF can faithfully reproduce may widen or narrow, but it won’t vanish.

What can change is the rigor with which Windows organizations manage their documents. TDF’s lock-in accusation is useful insofar as it forces a conversation most shops avoid until a migration deadline looms. Microsoft’s compatibility warning is equally useful as a reminder that file-level interoperability isn’t spreadsheet-level truth. Used together, they suggest a clear near-term play: inventory your high-stakes documents, test their behavior across your real toolchain, and write a format policy that reflects what actually happens when you hit “save as.” That’s a lot less exciting than a format war, but it’s the only way to win.