Der souveräne Arbeitsplatz – Begleitbeitrag zu Teil 2: Dokumente

Teil 2 hat erklärt, was in Deutschland beschlossen wurde und wie man die ODF-Pflicht umsetzt. Dieser Beitrag geht eine Ebene tiefer: Warum ist ODF technisch der sauberere Standard – und warum ist die Microsoft-Spezifikation so viel umfangreicher?

Inhalt

1. Zwei Container, dieselbe Grundidee
2. Die Größenfrage: 6.546 gegen 867 Seiten
3. Warum OOXML so groß ist: Die Last der Vergangenheit
4. Warum ODF schlank bleibt: nicht neu erfinden, sondern wiederverwenden
5. Fairness gehört dazu: Wo das Größenargument hinkt
6. Der Standardisierungskrieg: Wie OOXML zur ISO-Norm wurde
7. „Standard” heißt nicht automatisch „interoperabel”
8. 2026: Der Formatstreit kehrt zurück – diesmal im eigenen Lager
9. Deutschland macht ODF zur Pflicht – mit klaren Grenzen
10. Was das für die DACH-Praxis bedeutet
11. Fazit

Im Mai 2006 nahmen ISO und IEC ein Dateiformat an, das damals wie ein technisches Randthema wirkte und heute hochpolitisch ist: das Open Document Format (ODF). Zwanzig Jahre später hat das Format einen Status erreicht, den ihm in den hitzigen „Format-Kriegen” der 2000er-Jahre kaum jemand zugetraut hätte. Ab dem 1. Januar 2027 ist ODF in Deutschland der verbindliche Standard, wenn Verwaltungen untereinander bearbeitbare Dokumente austauschen. Und im Deutschland-Stack, dem Rahmenwerk für die gesamte Verwaltungs-IT, stehen seit März 2026 genau zwei Dokumentformate: ODF und PDF/UA. Microsofts OOXML taucht dort nicht auf.

Ein Jubiläumsartikel von heise/iX hat das ISO-Datum zum Anlass genommen, an die Ursprünge zu erinnern. Ich möchte hier eine Frage vertiefen, die dort nur angerissen wird und die mir in Beratungsprojekten immer wieder begegnet: Warum ist die Microsoft-Spezifikation eigentlich so gewaltig viel umfangreicher als die ODF-Spezifikation – und was sagt das über die Qualität der beiden Standards aus?

Vorab, damit die Richtung klar ist: Größe allein ist kein Qualitätsurteil. Aber wodurch eine Spezifikation groß wird, verrät sehr viel über ihre Konstruktionsprinzipien. Genau das schauen wir uns an.

Zwei Container, dieselbe Grundidee

Technisch sind sich ODF (.odt, .ods, .odp) und OOXML (.docx, .xlsx, .pptx) auf den ersten Blick erstaunlich ähnlich. Beide sind im Kern ein ZIP-Archiv, das mehrere XML-Dateien und eingebettete Ressourcen bündelt.

Bei ODF lässt sich das schön nachvollziehen: Benennt man eine .odt-Datei in .zip um, öffnet sie jedes gewöhnliche Packprogramm. Innen liegen sauber getrennt die content.xml (der eigentliche Inhalt), die styles.xml (die Formatdefinitionen), die meta.xml (Metadaten) und die settings.xml (anwendungsspezifische Einstellungen). Inhalt und Darstellung sind also getrennt – ein Prinzip, das man aus der Webwelt als Trennung von HTML und CSS kennt.

Microsoft hat dieses Container-Prinzip später für DOCX & Co. übernommen; auch dort steckt unter der Haube ein ZIP-Paket mit XML-Strömen (in OOXML „Parts” genannt, organisiert über die Open Packaging Conventions). Der entscheidende Unterschied liegt also nicht in der Grundarchitektur. Er liegt in der Frage, wie offen, wie konsistent und wie implementierbar die jeweilige Spezifikation tatsächlich ist. Und genau hier beginnt die Geschichte mit den Seitenzahlen.

Die Größenfrage: 6.546 gegen 867 Seiten

Die nackten Zahlen sind eindrücklich. Die OOXML-Spezifikation, die Microsoft 2006/2007 als ECMA-376 ins ISO-Schnellverfahren brachte, umfasste 6.546 Seiten. Die ODF-Spezifikation kam für denselben Zweck mit 867 Seiten aus – diese Gegenüberstellung machte Google im Streit der 2000er-Jahre öffentlich.

Wichtig für die Einordnung: Beide Zahlen beziehen sich auf die damaligen Fassungen. Seither sind beide Standards gewachsen – ODF zum Beispiel um die eigene Formelsprache OpenFormula (ab Version 1.2) und um zahlreiche Ergänzungen bis zur aktuellen Version 1.4. Am Größenverhältnis ändert das wenig, und vor allem nichts an der Frage, woher der Umfang kommt.

Beide Standards beschreiben Textverarbeitung, Tabellenkalkulation und Präsentation. Beide decken Formeln, Grafik, Metadaten und Auszeichnung ab. Wie kann das eine Dokument dann rund siebenmal so dick sein wie das andere? Die Antwort liegt in zwei gegensätzlichen Designentscheidungen.

Warum OOXML so groß ist: Die Last der Vergangenheit

OOXML wurde nicht „auf der grünen Wiese” entworfen. Es ist die XML-Übersetzung der über zwei Jahrzehnte gewachsenen binären Microsoft-Formate (.doc, .xls, .ppt). Das oberste Ziel war nicht ein eleganter, neutraler Standard, sondern die möglichst verlustfreie Abbildung von Milliarden bestehender Office-Dokumente. Diese Designpriorität bläht die Spezifikation auf gleich mehrere Arten auf.

1. Kompatibilitäts-Schalter für längst vergessene Programme

Das berüchtigtste Beispiel sind die sogenannten compatibility settings – eine lange Liste von Schaltern, die das Verhalten historischer Software nachahmen sollen. Eine kleine, unvollständige Auswahl der Element-Namen:

• autoSpaceLikeWord95 – Zeichenabstände wie in Word 95 setzen
• lineWrapLikeWord6 – Zeilenumbruch nach dem Algorithmus von Word 6.0
• footnoteLayoutLikeWW8 – Fußnoten-Layout wie in Word 97/2000
• shapeLayoutLikeWW8 – Objektpositionierung wie in Word 2000
• truncateFontHeightsLikeWP6 – Schrifthöhen wie in WordPerfect 6.x berechnen
• useWord97LineBreakRules – ostasiatischer Zeilenumbruch wie in Word 97
• mwSmallCaps – Kapitälchen wie in Word 5.x für Macintosh

Das eigentliche Problem ist nicht die schiere Zahl dieser Schalter, sondern was hinter ihnen steht. Die Spezifikation beschreibt das geforderte Verhalten oft gar nicht. Sie sagt im Wesentlichen: „Mach es so, wie Word 6.0 es gemacht hat.” Wer eine konkurrierende Software bauen will, müsste also das undokumentierte Verhalten teils jahrzehntealter, längst eingestellter Programme nachbauen. Ein offener Standard verweist hier auf proprietäres, nicht öffentlich dokumentiertes Alt-Verhalten – ein Konstruktionsfehler, der im Normungsprozess heftig kritisiert wurde. (Immerhin wurde im Zuge der ISO-Einsprüche Erläuterungstext ergänzt, und die Schalter wurden in den „Transitional”-Teil der Norm verschoben – dazu gleich mehr.)

2. Das Rad neu erfinden statt bestehende Standards nutzen

OOXML bringt für viele Aufgaben eigene Mechanismen mit, statt etablierte Standards einzubinden. Für Vektorgrafik nutzt es DrawingML (und das nur für Altlasten gedachte VML) statt des W3C-Standards SVG. Für Formeln verwendet es ein eigenes „Office MathML” (OMML), das nicht deckungsgleich mit dem W3C-MathML ist. Für eingebettete Objekte verweist die erste Edition auf Windows Metafiles – ein Format mit fester Bindung an Windows.

Hinzu kommt eine bemerkenswerte Inkonsistenz im Inneren: Es gibt in OOXML drei verschiedene Syntaxen, um etwa Farbe und Ausrichtung von Text festzulegen – je nachdem, ob es sich um ein Text-, Tabellen- oder Präsentationsdokument handelt. ODF-Mitentwickler Rob Weir (IBM) brachte seinen Unmut darüber auf die Formel: „What is the engineering justification for this horror?” Jede dieser Sonderlösungen muss vollständig spezifiziert werden – und kostet Seiten.

3. „Transitional” gegen „Strict” – und der Haken dabei

Es gibt OOXML in zwei Geschmacksrichtungen: Strict (ohne die Altlasten) und Transitional (mit allen Kompatibilitäts-Krücken). Der entscheidende Punkt für die Praxis: Microsoft Office speichert standardmäßig im Transitional-Profil – und hat das nie anders getan. Strict lässt sich in einigen Desktop-Versionen gezielt auswählen, in der Browser-Variante von Microsoft 365 aber nicht.

Wer in einer Ausschreibung „ISO/IEC 29500” fordert und dabei an das saubere Strict-Profil denkt, bekommt von realen Office-Dokumenten also genau das nicht – sondern die Variante mit dem ganzen historischen Ballast, für die es bis heute keinen Abkündigungsfahrplan gibt. Die Document Foundation hat es im Juni 2026 so zusammengefasst: Die ISO-Nummer in einer Ausschreibung garantiert weder Interoperabilität noch Herstellerneutralität. Bis hin zu Kuriositäten wie dem Excel-Schaltjahrfehler von 1900, den das Transitional-Format bis heute konserviert.

Warum ODF schlank bleibt: nicht neu erfinden, sondern wiederverwenden

ODF verfolgt das entgegengesetzte Prinzip. Es wurde von Anfang an als hersteller- und plattformneutrales Format entworfen und stützt sich, wo immer möglich, auf bereits etablierte offene Standards, statt eigene Lösungen zu erfinden. Konkret greift ODF unter anderem auf XHTML/HTML, SVG für Vektorgrafik, XSL-FO für die Textformatierung, MathML für Formeln, SMIL für Multimedia/Animation, XLink für Verknüpfungen, XForms für Formulare und Dublin Core für Metadaten zurück.

Dieser Ansatz „nicht das Rad neu erfinden” hat zwei Folgen. Erstens bleibt die Spezifikation schlank – etablierte Standards müssen nicht erneut von Grund auf beschrieben werden, ein Verweis genügt. Zweitens schafft er ein neutrales Spielfeld: Kein Hersteller ist gegenüber einem anderen bevorteilt, weil das Format auf seine speziellen Eigenheiten optimiert wäre. Und weil ODF dieselben Vokabulare konsistent verwendet (etwa XSL-FO durchgängig für Styling), ist es nicht nur kürzer, sondern auch leichter korrekt zu implementieren.

Dass dieses Modell trägt, zeigt die jüngste Version: Im Dezember 2025 hat OASIS ODF 1.4 als Standard verabschiedet – nach vier Jahren Arbeit, mit Beiträgen von Collabora, The Document Foundation, IBM, Nokia, KDE und Microsoft. Schwerpunkte sind Barrierefreiheit, bessere Kompatibilität bei Tabellen, Listen und Textrichtungen sowie Detailverbesserungen in allen drei Dokumenttypen. Die vollständige Abwärtskompatibilität zu ODF 1.3 bleibt erhalten.

Fairness gehört dazu: Wo das Größenargument hinkt

So überzeugend die 6.546-gegen-867-Erzählung klingt – ein paar ehrliche Einwände gehören dazu, sonst wird daraus Polemik.

Nicht jede zusätzliche Seite ist Ballast. Ein Teil des OOXML-Umfangs ist schlicht Gründlichkeit. Microsoft widmet allein den Tabellen-Formeln und -Funktionen über 300 Seiten. ODF 1.0 hatte für denselben Bereich nur eine Handvoll Seiten – zu wenig, um darauf eine Tabellenkalkulation aufzubauen. Diese Lücke war eine echte ODF-Schwäche und wurde erst später mit der OpenFormula-Spezifikation in ODF 1.2 geschlossen. Wer also nur Seiten zählt, vergleicht stellenweise Äpfel mit Birnen.

„Zu lang zum Lesen” ist kein technisches Argument. Dass 6.000 Seiten in einem beschleunigten Normungsverfahren kaum seriös zu prüfen sind, ist ein prozessualer Einwand – kein Beleg für technische Minderwertigkeit.

Microsoft ist nicht nur Gegenspieler. Microsoft arbeitet seit Jahren im ODF-Technischen Komitee mit, hat an ODF 1.4 mitgewirkt und dokumentiert in einer eigenen Spezifikation, wie Office ODF 1.4 umsetzt. Wer Microsoft pauschal als ODF-Verhinderer darstellt, liegt 2026 falsch. Der Kritikpunkt ist ein anderer: ODF unterstützen ist nicht dasselbe wie ODF als Standard voreinstellen – und Office speichert ab Werk weiterhin im eigenen Format.

Proprietäre Formate haben eine Daseinsberechtigung. Wer ein offenes Format als Pflicht festschreibt, bindet Hersteller an dessen Funktionsumfang. Neue Features lassen sich dann nicht mehr im Alleingang einführen. Komplexe Word-Dokumente verlieren beim Speichern als ODF mitunter Elemente – eingebettete Objekte, bestimmte Makros, manche Verzeichnis- oder Formelkonstrukte. Interoperabilität hat also ihren Preis, und der fällt am Übergang zwischen den Welten an.

Die faire Bilanz lautet trotzdem: Der strukturelle Größenunterschied entsteht überwiegend dort, wo OOXML proprietäres Alt-Verhalten und Sonderlösungen mitschleppt, die ODF durch Wiederverwendung offener Standards vermeidet. Genau das – nicht die bloße Seitenzahl – macht ODF zum saubereren Standard.

Der Standardisierungskrieg: Wie OOXML zur ISO-Norm wurde

Der Umfang war auch politisch brisant. Die Chronologie verdeutlicht, warum:

• 2002: Beginn der ODF-Standardisierung beim Industriekonsortium OASIS.
• Mai 2005: OASIS verabschiedet ODF 1.0.
• Mai/November 2006: ISO und IEC nehmen ODF an; Veröffentlichung als ISO/IEC 26300.
• Dezember 2006: Microsofts Format wird als ECMA-376 verabschiedet und kurz darauf im ISO-Schnellverfahren (Fast Track) als DIS 29500 eingereicht.
• September 2007: Im ersten ISO-Votum verfehlt OOXML die nötige Mehrheit. Es gehen über 3.500 Kommentare nationaler Gremien ein.
• Februar 2008: Auf dem Ballot Resolution Meeting in Genf werden die Einsprüche abgearbeitet.
• April 2008: OOXML erhält im zweiten Anlauf die nötige Zustimmung.
• November 2008: OOXML wird – in geänderter Fassung – als ISO/IEC 29500 veröffentlicht.
• 2015 / 2021: ODF 1.2 wird ISO-Norm; OASIS verabschiedet ODF 1.3.
• Dezember 2025: OASIS verabschiedet ODF 1.4.

Begleitet wurde der OOXML-Prozess von massiver Kritik. Es gab Berichte über Unregelmäßigkeiten bei nationalen Abstimmungen; der FFII warf Microsoft vor, Normungsgremien gezielt mit Mitgliedern zu „fluten”. In Norwegen zerlegte sich das nationale Normungsgremium über dem Streit nahezu selbst. Dass am Ende zwei ISO-Standards für denselben Zweck existierten, war für viele schon der eigentliche Sündenfall – Normung soll Wildwuchs reduzieren, nicht verdoppeln.

„Standard” heißt nicht automatisch „interoperabel”

Hier liegt der vielleicht wichtigste Punkt für die Praxis. Dass OOXML eine ISO-Nummer trägt, bedeutet nicht, dass Microsoft-Dokumente sauber zwischen verschiedenen Programmen – oder auch nur zwischen verschiedenen Office-Versionen – austauschbar wären. Die LibreOffice-Entwickler kritisieren seit Jahren genau das: Microsoft bezeichnet OOXML gern als „Standard”, dokumentiert aber nicht vollständig, wie die eigenen Anwendungen das Format tatsächlich nutzen. Reale Office-Dateien sind nicht Strict-konform. Der „Standard”, den man in einer Beschaffung im Kopf hat, ist also oft nicht der, den die Dateien wirklich verwenden.

ODF dreht diese Logik um: Wenn alle Beteiligten dasselbe offene Format nutzen, dessen Spezifikation jeder lesen und implementieren kann, spielt es keine Rolle mehr, welche Software dahintersteht. Ein proprietäres Format ist wie ein verschlossener Umschlag, für den nur ein Hersteller den Schlüssel verkauft; ein offenes Format ist der lesbare Brief selbst.

2026: Der Formatstreit kehrt zurück – diesmal im eigenen Lager

Wie aktuell diese Frage ist, hat sich in diesem Jahr an unerwarteter Stelle gezeigt: nicht bei Microsoft, sondern bei den europäischen Alternativen.

Am 9. Juni 2026 startete Euro-Office, eine browserbasierte Office-Suite, die ein Konsortium um IONOS und Nextcloud als souveräne Alternative zu Microsoft 365 positioniert. Technisch basiert sie auf einem Fork von ONLYOFFICE – und speichert neue Dokumente standardmäßig im OOXML-Format. Die Document Foundation reagierte rund um den Start mit einem offenen Brief und scharfer Kritik: Eine Suite, die Souveränität verspricht, aber Microsofts Format zum Standard macht, verlagere zwar den Speicherort der Daten, nicht aber die Kontrolle über das Format. Nextcloud hält dagegen, man teile die Einschätzung, dass proprietäre Formate ein ernsthaftes Hindernis für digitale Souveränität seien; die ODF-Unterstützung werde ausgebaut, langfristig solle ODF das bevorzugte Format werden.

Ein ähnliches Bild bei Nextcloud Office (auf Basis von Collabora): Auch hier ist OOXML für neue Dateien voreingestellt. Ein Änderungsvorschlag, ODF wieder zum Standard zu machen, wurde nicht übernommen. Die Begründung der Entwickler ist nachvollziehbar und ehrlich: Viele Nutzer stoßen beim Austausch mit Microsoft-Anwendern auf Probleme und machen dafür die Software verantwortlich – OOXML sei deshalb eine „pragmatische Entscheidung für jetzt”, keine grundsätzliche Abkehr von ODF.

Ich halte beide Positionen für verständlich – und genau deshalb ist der Fall so lehrreich. Er zeigt, was dieser ganze Artikel im Kleinen beschreibt: Das Format, das voreingestellt ist, wird zum Format, in dem die Welt schreibt. Unterstützen ist nicht Voreinstellen. Und europäische Server allein machen noch keinen souveränen Arbeitsplatz, solange die Dokumente darauf in einem Format entstehen, dessen Weiterentwicklung ein einzelner US-Hersteller steuert. Die gute Nachricht: In Nextcloud Office lässt sich der Standard mit einem Haken in den Administrationseinstellungen auf ODF umstellen. Wer Souveränität ernst meint, sollte das tun.

Deutschland macht ODF zur Pflicht – mit klaren Grenzen

Was in Deutschland genau beschlossen wurde, habe ich in Teil 2 der Serie ausführlich sortiert. Hier deshalb nur das Wesentliche, weil darüber erstaunlich viel Ungenaues kursiert:

• Verbindlich ist der FIT-Standard „Open Document Format”. Er gilt ab dem 1. Januar 2027 für den Austausch bearbeitbarer Dokumente zwischen Verwaltungen. Welches Format eine Behörde intern verwendet, regelt er nicht.
• Der Deutschland-Stack (Beschluss des IT-Planungsrats vom 18. März 2026) nennt ODF und PDF/UA als Dokumentformate für die gesamte Verwaltungs-IT, mit Zielhorizont 2028. Formuliert ist das als Ziel, das „anzustreben” ist – Sanktionen sieht der Beschluss nicht vor. OOXML steht nicht auf der Liste, ein ausdrückliches Verbot ist es aber nicht.

Der Rückenwind kommt aus der Praxis. In Schleswig-Holstein waren bis Ende 2025 knapp 80 Prozent der Arbeitsplätze in der Landesverwaltung auf LibreOffice umgestellt; einer einmaligen Investition von rund 9 Millionen Euro stehen nach Angaben des Landes jährliche Lizenzeinsparungen von über 15 Millionen Euro gegenüber. Auf Bundesebene betreibt das Zentrum für digitale Souveränität (ZenDiS) die Plattform openDesk mit browserbasiertem ODF-Editing; nach aktuellen Angaben nutzen sie rund 100.000 Arbeitsplätze in der Verwaltung.

Treiber ist nicht Technik-Romantik, sondern digitale Souveränität. Der US-amerikanische CLOUD Act verpflichtet US-Konzerne, Daten auf behördliche Anforderung herauszugeben – unabhängig vom Serverstandort. Für Verwaltungen, die jahrzehntelang lesbare, herstellerunabhängige Dokumente vorhalten müssen, ist Formathoheit damit eine Frage der Daseinsvorsorge. Deutschland steht dabei nicht allein: Auch Dänemark, Österreich, die Niederlande und Frankreich treiben den Umstieg auf offene Standards und lokale Alternativen voran. Und in der Schweiz hat die Bundeskanzlei im September 2026 ein Programm für einen digital souveränen Arbeitsplatz gestartet, mit einer Pilotphase ab Ende 2027.

Was das für die DACH-Praxis bedeutet

Für Unternehmen und Selbstständige im DACH-Raum heißt das konkret: Wer regelmäßig editierbare Dokumente mit deutschen Behörden austauscht – Angebote, Berichte, Anträge, Vorlagen –, sollte sich mit .odt und PDF/UA vertraut machen. PDFs bleiben für Endfassungen das Mittel der Wahl; für bearbeitbare Dateien wird ODF an der Schnittstelle zur öffentlichen Hand zunehmend zum Standard.

Die Hürde ist niedrig. Microsoft Word kann ODF lesen und schreiben, inzwischen auch in Version 1.4, und auf Wunsch als Standardformat speichern – zentral steuerbar per Gruppenrichtlinie oder Intune. LibreOffice und Collabora arbeiten ohnehin nativ mit ODF. Und wer eine europäische Cloud-Suite einführt, sollte vorab prüfen, welches Format dort ab Werk voreingestellt ist – und es bewusst festlegen, statt es dem Zufall zu überlassen.

Fazit

Die mehr als 6.000 Seiten der OOXML-Spezifikation sind kein Zeichen von Stärke, sondern überwiegend das Protokoll einer Wette auf die Vergangenheit: möglichst alles abbilden, was Microsoft-Software je getan hat, inklusive ihrer undokumentierten Eigenheiten. Die damals 867 Seiten von ODF sind das Ergebnis einer anderen Wette – auf bestehende offene Standards, auf Konsistenz und auf Neutralität.

Nach Spezifikation und Standardisierung ist ODF damit tatsächlich das sauberere, durchdachtere Format. Das war 2006 ein technisches Detail, über das vor allem Fachleute stritten. 2026 ist daraus eine strategische Weichenstellung geworden – und, wie der Streit um Euro-Office zeigt, eine Frage, die sich jeder Anbieter und jede Organisation selbst stellen muss: nicht ob man ODF unterstützt, sondern was man voreinstellt. Zwanzig Jahre nach der ISO-Abstimmung steht ODF damit nicht als nostalgisches Nischenformat da, sondern als das, wozu es immer gedacht war: als gemeinsame, offene und dauerhaft lesbare Grundlage – egal, welche Software man morgen einsetzt.

Zurück zu Teil 2 der Serie: Deutschlands Umstieg auf das Open Document Format · Zum Serienauftakt: Der souveräne Arbeitsplatz – Bausteine statt Big-Tech-Bundle

Quellen und weiterführende Literatur

• Moritz Förster: Am Ende der Sieger: Das Open Document Format ist der Standard. heise online / iX, Mai 2026 – https://www.heise.de/hintergrund/Am-Ende-der-Sieger-Das-Open-Document-Format-ist-der-Standard-11287440.html
• Google: Stellungnahme zu OOXML (6.546 vs. 867 Seiten) – https://www.csun.edu/~hcmth008/odf/google_ooxml.pdf
• Wictor Wilén: Does the size matter? (2007) – Gegenstimme zum reinen Größenargument – https://wictorwilen.se/blog/does-the-size-matter
• Wikipedia: Office Open XML file formats und Comparison of Office Open XML and OpenDocument – zu Kompatibilitäts-Elementen, DrawingML/VML, OMML und Standardisierungskritik – https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_and_OpenDocument
• The Document Foundation: A Standard in Name Only: What OOXML Transitional Tells Us About Format Sovereignty (02.06.2026) – https://blog.documentfoundation.org/blog/2026/06/02/a-standard-in-name-only/
• The Document Foundation: Euro-Office, open standards, and native ODF (11.06.2026) – https://blog.documentfoundation.org/blog/2026/06/11/euro-office-open-standards-and-native-odf/
• OASIS: OASIS Approves Open Document Format (ODF) V1.4 Standard (03.12.2025) – https://www.oasis-open.org/?p=13307
• Microsoft: [MS-OODF14] Office Implementation Information for ODF 1.4 Standards Support – https://learn.microsoft.com/en-us/openspecs/office_standards/ms-oodf14/ad5a09c6-609d-47b3-bc56-7ab49a8d4f35
• Netzwoche: Europäische Open-Source-Alternative „Euro-Office” erntet Kritik (12.06.2026) – https://www.netzwoche.ch/news/2026-06-12/europaeische-open-source-alternative-euro-office-erntet-kritik
• Nextcloud Office (GitHub): Diskussion zum Standardformat, Pull Request #5516 – https://github.com/nextcloud/richdocuments/pull/5516
• Standardkatalog des Bundes: FIT-Standard „Open Document Format (ODF)” – https://docs.gov.de/fit-standards/odf/
• IT-Planungsrat: Beschluss B-2026/03-IT (Deutschland-Stack) – https://www.it-planungsrat.de/beschluss/b-2026-03-it
• heise online: Goodbye, Microsoft: Schleswig-Holstein relies on Open Source and saves millions (Dezember 2025) – https://heise.de/-11105459
• Born City: openDesk: ZenDiS öffnet Partnerprogramm erstmals für private IT-Dienstleister (23.09.2026) – https://borncity.com/news/opendesk-zendis-oeffnet-partnerprogramm-erstmals-fuer-private-it-dienstleister/

Stand: 14. Oktober 2026. Inhaltliche Aussagen wurden aus den genannten öffentlich zugänglichen Quellen zusammengetragen und in eigenen Worten zusammengefasst. Beschlusslagen und Produktentscheidungen können sich ändern.