Der mitgelieferte Office-Unterbau: Was Nextclouds Community Document Server leistet – und wo er an Grenzen stößt

Wer eine Nextcloud betreibt, kennt diesen Moment: Der Speicher läuft, die Synchronisation klappt, die Freigaben greifen – und dann will jemand eine .docx-Datei öffnen und darin schreiben. Im Browser, ohne sie vorher herunterzuladen und lokal in einem Office-Paket zu bearbeiten. Spätestens an dieser Stelle entscheidet sich, ob eine selbst gehostete Cloud im Alltag ernsthaft mit Microsoft 365 oder Google Workspace konkurrieren kann oder ob sie ein guter Dateitresor bleibt. Nextcloud hat für dieses Problem mehrere Antworten, und eine davon trägt den betont nüchternen Namen Community Document Server.

Ein Dokumentenserver, der einfach mitkommt

Die Idee hinter dem Community Document Server ist so simpel wie verlockend. Statt eine zusätzliche Maschine, einen Container-Stack oder gar ein Kubernetes-Cluster für die Dokumentenbearbeitung aufzusetzen, installiert man eine App. Zwei Klicks im App-Store, ein Bestätigungsdialog – fertig. Der Dokumentenserver läuft dann auf derselben Instanz wie die Nextcloud selbst, teilt sich das Betriebssystem, die CPU und den Arbeitsspeicher mit dem Webserver und der Datenbank. Für Heimanwender, Vereine, kleine Büros und alle, die eine Testumgebung aufsetzen wollen, ist das ein enorm niedrigschwelliger Einstieg in kollaboratives Editieren.

Technisch steckt dahinter kein Eigenbau von Nextcloud. Der Community Document Server ist eine gebündelte Variante des ONLYOFFICE Document Server, jener Node.js-basierten Anwendung, die Dokumente im Browser rendert, Formeln berechnet, Präsentationen darstellt und mehrere Cursor gleichzeitig über ein Dokument wandern lässt. Nextcloud liefert die Binärdateien mit, startet sie beim ersten Aufruf und verbindet sie über eine Standardschnittstelle mit der eigenen Dateiverwaltung. Der Anwender sieht davon nichts außer einem Editor, der sich in die gewohnte Oberfläche einfügt.

So weit die Theorie. In der Praxis ist dieser Weg bequem, aber nicht kostenlos – nicht im monetären Sinn, wohl aber in Sachen Skalierbarkeit, Wartung und Betriebsrisiko. Wer heute eine Nextcloud plant, sollte die Entscheidung für oder gegen den mitgelieferten Dokumentenserver bewusst treffen und nicht einfach die erstbeste App aktivieren. Der folgende Text versucht, die Landschaft sortieren zu helfen.

Ein kurzer Rückblick: Von Collabora zu ONLYOFFICE und zurück

Die Geschichte der Dokumentenbearbeitung in Nextcloud ist eine Geschichte wechselnder Partnerschaften. Über viele Jahre war Collabora Online die naheliegende Wahl. Collabora wiederum nutzt im Kern LibreOffice, eingedampft auf einen Webservice, der über die WOPI-Schnittstelle mit der Cloud spricht. Die Integration war lange die offizielle Empfehlung, technisch ausgereift und in vielen Unternehmensumgebungen erprobt.

Anfang 2020 änderte sich das Bild. Nextcloud stellte mit Version 18 den Hub-Gedanken in den Vordergrund und brachte eine Office-Integration auf Basis von ONLYOFFICE mit. Der entscheidende Unterschied zur damals üblichen Collabora-Anbindung: Der Dokumentenserver musste nicht mehr separat betrieben werden. Er kam als App mit, eben als Community Document Server. Das war für viele Administratoren der Moment, in dem Browser-Office in einer selbst gehosteten Cloud endlich als realistisch erschien. Kein Docker, kein zweiter Hostname, kein Zertifikatszirkus – zumindest nicht auf den ersten Blick.

Parallel dazu pflegte die Community eine zweite Variante desselben Grundgedankens: die App „Collabora Online – Built-in CODE Server“. Sie tut im Prinzip dasselbe, nur eben mit LibreOffice im Unterbau. Zwei integrierte Dokumentenserver, zwei Büro-Suiten, ein gemeinsames Protokoll. Wer damals eine Nextcloud aufsetzte, stand plötzlich vor einer Wahl, die vorher keine war.

Interessant ist, wie sich das Blatt in den Folgejahren drehte. Nextcloud benannte die Office-Integration in „Nextcloud Office“ um und rückte wieder Collabora in den Mittelpunkt. Der ONLYOFFICE-Zweig wurde zwar nicht abgekündigt, aber seine Weiterentwicklung verlief zunehmend unauffällig. Neue Hauptversionen von Nextcloud wurden teils erst mit Verzögerung unterstützt, und in Foren mehrten sich Berichte über hängende Prozesse, fehlende Updates und rätselhafte Fehlermeldungen. Wer heute nach dem Community Document Server sucht, findet entsprechend viele Beiträge, die zwischen „läuft bei mir problemlos“ und „habe ich aufgegeben“ schwanken. Das ist kein gutes Zeichen für ein Stück Infrastruktur, das im Zweifel die tägliche Arbeit einer ganzen Organisation trägt.

Wie das Zusammenspiel technisch funktioniert

Um die Grenzen des Community Document Servers zu verstehen, hilft ein Blick auf die Mechanik. Das verbindende Element heißt WOPI, ausgeschrieben Web Application Open Platform Interface. Dieses Protokoll hat Microsoft ursprünglich für Office Online und SharePoint definiert, und es hat sich als eine Art Lingua franca der Browser-Office-Welt durchgesetzt. Collabora spricht es, ONLYOFFICE spricht es, und Nextcloud spricht es ebenfalls.

Die Rollenverteilung ist dabei etwas kontraintuitiv. Der WOPI-Host ist der Speicher – also die Nextcloud. Sie verwaltet die Dateien, kennt die Berechtigungen und weiß, wer auf welche Datei zugreifen darf. Der WOPI-Client ist der Dokumentenserver. Er fragt über eine definierte Schnittstelle an: Worum handelt es sich bei dieser Datei, wie groß ist sie, darf ich sie schreiben, gibt es eine Sperre? Danach holt er den Inhalt ab, bearbeitet ihn, schreibt Änderungen zurück und aktualisiert bei Bedarf die Sperre. Alles läuft über HTTPS, alles läuft tokenbasiert, und die Tokens sind kurzlebig.

Diese Architektur hat eine wichtige Konsequenz: Der Dokumentenserver muss die Nextcloud selbst erreichen können. Nicht der Browser, sondern die serverseitige Komponente baut eine Verbindung zur Cloud auf, um das Dokument zu laden und zu speichern. Läuft der Dokumentenserver auf derselben Maschine, scheint das trivial. Ist er es aber nicht – etwa weil ein Reverse Proxy im Spiel ist, die Nextcloud intern über HTTP erreichbar ist und von außen über HTTPS – dann entstehen genau jene Fehlerbilder, die Administratoren zur Verzweiflung treiben. Der Editor öffnet sich, bleibt weiß, und im Log steht eine nichtssagende Zeitüberschreitung.

Beim Community Document Server fallen Host und Client zusammen. Das ist der eigentliche Trick dieser Lösung und gleichzeitig ihre größte Einschränkung. Es gibt nur eine Instanz, nur einen Satz Tokens, nur einen Punkt, an dem alles hängt. Für ein kleines Team ist das elegant. Für alles darüber hinaus wird es zum Nadelöhr.

Installation: schnell, aber nicht beliebig

Die Installation selbst ist unspektakulär. Im App-Store aktiviert man den Community Document Server, dazu die passende Integrations-App für die Oberfläche, und konfiguriert gegebenenfalls die Adresse, unter der der Dienst erreichbar sein soll. Beim ersten Aufruf eines kompatiblen Dokuments startet die Anwendung ihren Node-Prozess, lädt Schriftarten, initialisiert den Cache und öffnet den Editor. Das dauert beim ersten Mal spürbar länger als später; das ist kein Fehler, sondern schlicht die Initialisierung.

Die Voraussetzungen sind allerdings enger, als man vermuten möchte. Der mitgelieferte Dienst läuft ausschließlich auf 64-Bit-Linux und benötigt eine glibc-basierte Distribution. Auf Alpine-Linux-Containern, wie sie im Docker-Umfeld beliebt sind, funktioniert er nicht, weil dort musl libc zum Einsatz kommt. Auf ARM-Plattformen – und damit auf dem weitverbreiteten Raspberry Pi oder auf vielen kleinen NAS-Systemen – läuft die gebündelte Variante nach unserer Kenntnis ebenfalls nicht. Node.js muss man dagegen nicht separat installieren; die Laufzeitumgebung ist im App-Paket enthalten.

Damit kommt ein Aspekt ins Spiel, den man nicht unterschätzen sollte: Mit der Aktivierung dieser App landen fremde Binärdateien im Nextcloud-Verzeichnis. Sie werden über den App-Store aktualisiert, also nach einem Rhythmus, den der Hersteller der App vorgibt, nicht der Administrator. In Umgebungen mit strengen Patch-Prozessen ist das ein Diskussionsthema. Wer seinen Server nur mit Paketen aus der distributionsseitigen Versionsverwaltung bestückt, wird hier hellhörig – zu Recht.

Was der Community Document Server tatsächlich kann

Die Funktionalität im Alltag ist besser als ihr Ruf. Textdokumente, Tabellen und Präsentationen lassen sich im Browser öffnen und bearbeiten. Mehrere Personen können gleichzeitig in derselben Datei arbeiten, mit farblich getrennten Cursorn und Namen an den Einfügemarken. Kommentare, Änderungsverfolgung und Formelauswertung sind vorhanden, ebenso der Export nach PDF. Präsentationen laufen im Vollbild, Tabellen verarbeiten eine respektable Auswahl an Funktionen.

Die Anbindung an die Nextcloud ist eng. Jede Speicherung erzeugt eine neue Version im Dateiversionssystem, was sich in der Praxis als erstaunlich nützlich erweist – nicht nur als Sicherheitsnetz, sondern als eine Art unfreiwilliges Protokoll der Entstehungsgeschichte eines Dokuments. Freigaben und Berechtigungen gelten weiter, wer nur lesen darf, sieht den Editor im Lesemodus. Vorlagen lassen sich in einem definierten Ordner ablegen und erscheinen dann im Dialog „Neue Datei“. Die Funktion „Secure View“, mit der sich Wasserzeichen einblenden und Downloads unterbinden lassen, wird von der Integration ebenfalls unterstützt.

Auch an die Dateisperre ist gedacht. Wer eine Datei im Browser geöffnet hat, blockiert sie für konkurrierende Schreibzugriffe über den Desktop-Client. Das klingt selbstverständlich, ist es aber nicht: Ohne saubere Sperrlogik entstehen genau jene Konfliktdateien mit kryptischen Namensanhängseln, die Nutzer misstrauisch gegenüber Cloud-Speichern machen.

Wo die Grenzen verlaufen

Die Einschränkungen des Community Document Servers liegen weniger in dem, was er tut, als in dem, was er nicht tut. Die wichtigste: Er skaliert nicht. Es gibt pro Nextcloud genau eine Instanz. Keine Lastverteilung, kein zweiter Knoten, keine horizontale Erweiterung. Wenn zwanzig Personen gleichzeitig an umfangreichen Tabellen arbeiten, arbeitet ein einziger Node-Prozess auf einer Maschine, die parallel noch Webserver, Datenbank, Cache und alles andere bedient.

Damit zusammen hängt ein betriebliches Risiko, das man kennen sollte. Der Dokumentenserver läuft unter demselben Benutzerkonto wie der Webserver. Ein Absturz oder eine Speichererschöpfung trifft nicht ein isoliertes System, sondern potenziell die ganze Instanz. Wer schon einmal erlebt hat, wie ein einzelner hängender Konvertierungsvorgang eine PHP-FPM-Prozessgruppe blockiert und damit die gesamte Cloud zum Stillstand bringt, weiß, warum getrennte Ressourcengrenzen kein Luxus sind.

Hinzu kommen lizenz- und produktseitige Beschränkungen. Die Community-Edition von ONLYOFFICE Docs ist auf einen überschaubaren Kreis gleichzeitiger Verbindungen ausgelegt – die genaue Grenze liegt im zweistelligen Bereich und hat sich über die Jahre verschoben. Das ist kein technischer Defekt, sondern eine bewusste Setzung des Herstellers. Wer sie überschreitet, wird es früher oder später merken. Ebenso fehlen Funktionen, die die kommerzielle Ausgabe bietet: Schnittstellen für Automatisierung und Dokumentengenerierung, Serienbriefe, Plug-in-Unterstützung, teils auch Feinheiten bei der Formatierungstreue.

Ein weiterer Punkt betrifft die mobile Nutzung. Die Integration fühlt sich auf dem Desktop-Client und im Browser wohl, die Bearbeitung auf Smartphone oder Tablet war dagegen nie wirklich rund. Wer von Beschäftigten erwartet, unterwegs schnell eine Freigabe zu kommentieren oder ein Angebot anzupassen, sollte diesen Aspekt vorab prüfen und nicht auf Zusagen aus einem Werbeprospekt vertrauen.

Nicht zuletzt: Die Wartungsgeschichte. Eine App, die unregelmäßig aktualisiert wird, ist in einer Produktivumgebung ein Problem. Sicherheitslücken in eingebetteten Komponenten werden nicht dadurch kleiner, dass sie in einem Nextcloud-Verzeichnis liegen. Wer den Community Document Server weiter betreibt, sollte die Versionshinweise der App im Blick behalten und einen Plan B in der Schublade haben.

Die Alternativen im Vergleich

Wer heute eine Nextcloud mit Dokumentenbearbeitung ausstatten will, hat im Wesentlichen drei Wege – plus den vierten, es ganz zu lassen und die Dateien lokal zu bearbeiten.

Der erste Weg ist der integrierte Collabora-Server, ebenfalls als App verfügbar, oft als „Built-in CODE Server“ bezeichnet. Er verfolgt dieselbe Philosophie wie der Community Document Server, setzt aber auf LibreOffice und wird von den Nextcloud-Maintainern sichtbar stärker gepflegt. Er hat dieselben architektonischen Einschränkungen – eine Instanz, x86_64, keine Skalierung – und ist damit ebenfalls eher für kleine Installationen gedacht. Für viele kleinere Selbsthoster ist er inzwischen die naheliegendere Wahl, schlicht weil die Updatekette verlässlicher wirkt.

Der zweite Weg ist ein eigenständiger Dokumentenserver, egal ob Collabora Online oder ONLYOFFICE Docs, betrieben als Container oder auf einer eigenen virtuellen Maschine. Das ist mehr Arbeit bei der Einrichtung, dafür bekommt man klare Ressourcengrenzen, unabhängige Updates, Lastverteilung und – bei ONLYOFFICE – auch die mobilen Apps, die ein echtes Bearbeiten auf dem Tablet erlauben. In dieser Konstellation ist der Dokumentenserver ein eigenes System mit eigenen Backups, eigenem Monitoring und eigener Firewall-Regel. Genau das ist der Punkt: Man trennt Verantwortlichkeiten, statt sie zu vermischen.

Der dritte Weg führt über die All-in-One-Installation von Nextcloud, die eine ganze Instanz als Container-Verbund ausliefert und den Dokumentenserver gleich mitbringt. Wer ohnehin mit Docker arbeitet und sich nicht in die Tiefen von PHP-FPM und Datenbanktuning begeben will, findet dort einen vergleichsweise bequemen Kompromiss – mit dem Nebeneffekt, dass Updates zentral gesteuert werden.

Und der vierte Weg? Dateien einfach herunterladen und lokal bearbeiten. Das klingt rückständig, ist aber für manche Umgebung die ehrlichste Lösung. Nicht jede Organisation braucht gleichzeitiges Editieren. Wer vor allem archiviert und verteilt, spart sich mit dieser Entscheidung eine Menge Betriebsaufwand.

Der Betrieb in der Praxis: Reverse Proxy, Zertifikate, Zeitüberschreitungen

Die häufigste Fehlerquelle bei der Dokumentenbearbeitung in Nextcloud ist nicht der Dokumentenserver selbst, sondern die Netzwerkkonfiguration davor. Sobald ein Reverse Proxy im Spiel ist – und das ist er fast immer –, muss Nextcloud wissen, wie es von außen gesehen wird. Die Parameter heißen overwrite.cli.url, overwritehost, overwriteprotocol und trusted_proxies. Sie sind nicht optional, sondern Voraussetzung dafür, dass die WOPI-Aufrufe auf eine erreichbare Adresse zeigen.

Besonders tückisch ist die Kombination aus TLS-Terminierung und internem HTTP. Wenn Nextcloud selbst glaubt, über HTTP erreichbar zu sein, generiert es WOPI-URLs mit http:// – und der Dokumentenserver, der diese URLs aufruft, scheitert entweder an einer Weiterleitung oder an einem Zertifikatsfehler. Das Fehlerbild ist wenig hilfreich: Der Editor bleibt leer, im Browser erscheint bestenfalls ein generischer Hinweis, und in den Logs findet sich eine Zeile, die nach Netzwerkproblem aussieht, aber ein Konfigurationsproblem ist.

Ebenso unterschätzt werden Zeitüberschreitungen. Das Öffnen eines großen Dokuments dauert beim ersten Zugriff länger, weil der Dokumentenserver die Datei konvertiert, Schriften lädt und Caches füllt. Sind die Timeouts im Proxy zu knapp bemessen, bricht der Vorgang ab und der Nutzer sieht eine Fehlermeldung, die nichts über die eigentliche Ursache verrät. Wer hier auf Standardwerte vertraut, wird früher oder später Besuch von genervten Anwendern bekommen. Ein Blick in die Konfiguration des Proxys lohnt sich also, bevor der erste Beschwerde-E-Mail eintrifft.

Nicht zuletzt die Firewall. Der Dokumentenserver lauscht intern auf einem Port, der von außen nichts zu suchen hat. Wer ihn versehentlich mitveröffentlicht, öffnet eine Angriffsfläche, die weder nötig noch sinnvoll ist. Die Kommunikation läuft über die Nextcloud; alles andere ist ein Konfigurationsfehler.

Wenn es klemmt: eine kleine Fehlerkunde

Die Fehlerbilder in diesem Umfeld sind überschaubar, ihre Ursachen leider nicht immer. Ein paar Muster haben sich über die Jahre herauskristallisiert.

• Editor öffnet sich, bleibt aber leer. Meist ein Erreichbarkeitsproblem: Der Dokumentenserver kann die WOPI-URL der Nextcloud nicht auflösen oder das Zertifikat nicht validieren. Zuerst die Adresse aus der Konfiguration vom Server aus mit einem curl-Aufruf testen, dann die Proxy-Parameter prüfen.
• „Dokument konnte nicht geladen werden“ beim Speichern. Oft eine Zeitüberschreitung oder ein Rechteproblem im Datenverzeichnis. Prüfen, ob der Webserverbenutzer Schreibzugriff auf die App-Daten hat.
• Plötzlich fehlende Schriften, verschobene Layouts. Der Schriftcache ist beschädigt oder unvollständig. Ein Neustart des Dienstes hilft häufig, ein Blick auf die installierten Systemschriften schadet nie.
• Der Dienst startet nach einem Update nicht mehr. Klassiker nach einem Sprung auf eine neue Nextcloud-Hauptversion. Hier hilft nur, die Kompatibilitätsmatrix zu prüfen und gegebenenfalls die App zu deaktivieren, bis eine passende Version vorliegt.
• Alles läuft, aber langsam. Meist ein Ressourcenproblem. Arbeitsspeicher, CPU oder beides sind am Anschlag. Ein Blick auf die Prozessliste während einer Konvertierung ist aufschlussreicher als jedes Monitoring-Diagramm.

Generell gilt: Die Logs der Nextcloud geben bei WOPI-Problemen oft nur die halbe Wahrheit preis. Wer die Ursache wirklich finden will, muss die serverseitige Perspektive einnehmen und die Aufrufe nachvollziehen, die der Dokumentenserver gegen die Cloud richtet. Das ist mühsam, aber es ist der einzige Weg, der nicht im Rätselraten endet.

Sicherheit und Datenschutz: das starke Argument

Die vielleicht wichtigste Eigenschaft dieser ganzen Konstruktion ist eine, die leicht übersehen wird: Die Dokumente verlassen das eigene System nicht. Kein Bytes gehen an einen Cloud-Anbieter, keine Verträge zur Auftragsverarbeitung mit einem Dritten, keine unklare Datenhaltung in irgendeiner Region. Für Organisationen mit strengen Vorgaben – öffentliche Verwaltung, Gesundheitswesen, Anwaltskanzleien, Forschungseinrichtungen – ist das kein Nebenaspekt, sondern der eigentliche Grund für den Betrieb einer eigenen Cloud.

Die technischen Schutzmechanismen sind solide, soweit sie reichen. WOPI-Tokens sind kurzlebig und an eine konkrete Datei sowie einen konkreten Nutzer gebunden. Die Kommunikation läuft verschlüsselt, sofern die Konfiguration stimmt. Der Dokumentenserver erhält keinen direkten Zugriff auf die Datenbank, sondern ausschließlich über die definierten Schnittstellen.

Kritisch zu betrachten ist dagegen die gemeinsame Vertrauensgrenze. Läuft der Dokumentenserver auf derselben Maschine wie die Nextcloud und unter demselben Benutzerkonto, dann ist eine Schwachstelle in einer der beiden Komponenten potenziell eine Schwachstelle für beide. Bei einer getrennten Installation gelten andere Regeln: Ein kompromittierter Dokumentenserver sieht dann nur die Dateien, die er über Tokens anfordern kann, und nicht das gesamte Datenverzeichnis.

Ein zweiter Punkt betrifft die Nachhausetelefonie. Manche Builds von Dokumentenservern prüfen beim Start auf Aktualisierungen und kontaktieren dafür Server des Herstellers. Das lässt sich abschalten, sollte aber bewusst geschehen und dokumentiert werden – spätestens dann, wenn jemand aus der IT-Sicherheit nach den ausgehenden Verbindungen eines Servers fragt, der eigentlich nur intern arbeiten sollte.

Ressourcen und Performance: was man einplanen sollte

Wer den Community Document Server produktiv einsetzen will, sollte realistisch rechnen. Ein Dokumentenserver ist keine leichte Anwendung. Er bringt eine eigene Laufzeitumgebung mit, hält Schriftarten im Speicher, verwaltet Caches und konvertiert Dokumente zwischen Formaten. Im Leerlauf genügt ihm einige hundert Megabyte Arbeitsspeicher. Sobald mehrere Personen gleichzeitig arbeiten oder ein umfangreiches Dokument geöffnet wird, steigt der Bedarf schnell in Richtung eines Gigabytes und darüber hinaus.

Die CPU-Last ist ungleichmäßig. Das bloße Bearbeiten eines Textdokuments ist vergleichsweise billig. Teuer werden die Momente, in denen konvertiert wird: beim ersten Öffnen, beim Export nach PDF, beim Wechsel des Dateiformats. Diese Vorgänge sind kurz, aber intensiv, und sie treffen eine Maschine, die gleichzeitig Webserveranfragen bedient. Auf einer virtuellen Maschine mit zwei Kernen und vier Gigabyte Speicher, auf der ohnehin schon Datenbank, Cache und Webserver laufen, ist das eine enge Kiste.

Daraus folgt eine Faustregel, die sich in der Praxis bewährt hat: Für eine Handvoll gleichzeitiger Bearbeiter genügt der integrierte Weg. Sobald regelmäßig mehr als eine kleine Gruppe parallel arbeitet, ist ein eigener Dokumentenserver die vernünftigere Investition – nicht wegen der Lizenzkosten, sondern wegen der Betriebsruhe. Ein eigener Container auf einem zweiten Host lässt sich neu starten, ohne dass die Cloud wackelt. Diese Trennung ist ihren Preis wert.

Unabhängig davon lohnt es sich, die Grundlagen der Nextcloud-Performance nicht zu vernachlässigen: ein ordentlicher Datenbankserver statt SQLite, ein In-Memory-Cache, aktiviertes Opcode-Caching, ausreichend dimensionierte PHP-FPM-Worker und eine Datenbank, deren Standardeinstellungen nicht aus dem Jahr 2010 stammen. Ein langsamer Unterbau macht jeden Dokumentenserver langsam – unabhängig davon, welchen man wählt.

Alltagstauglichkeit: wo die Integration wirklich hilft

Jenseits der Technik entscheidet sich der Nutzen im täglichen Gebrauch. Und hier hat die enge Verzahnung mit der Nextcloud klare Vorteile. Dokumente werden nicht mehr hin- und hergeschickt, sondern es gibt genau eine Datei, an der alle arbeiten. Das klingt banal, beseitigt aber eines der hartnäckigsten Probleme verteilter Zusammenarbeit: die Frage, welche Version denn nun die aktuelle ist.

Praktisch sind die Vorlagen. Legt man im dafür vorgesehenen Ordner eine Datei ab, erscheint sie beim Anlegen neuer Dokumente als Auswahl. Für Organisationen mit wiederkehrenden Schriftstücken – Angebote, Protokolle, Berichte – spart das erstaunlich viel Zeit und sorgt nebenbei für einheitliches Erscheinungsbild.

Auch die Kommentarfunktion und die Änderungsverfolgung sind im Alltag wertvoller, als man zunächst annimmt. Gerade in Redaktions- und Abstimmungsprozessen ersetzt das manche E-Mail-Schleife. Und die automatische Versionierung erlaubt es, einen Bearbeitungsstand zurückzuholen, ohne dass jemand vorher ein Backup gezogen hat.

Grenzen zeigen sich bei föderierten Freigaben. Sobald Dokumente über Instanzgrenzen hinweg geteilt werden, wird es mit der gemeinsamen Bearbeitung kompliziert bis unmöglich, weil die Token- und Rechteketten nicht sauber über die Grenze laufen. Wer stark auf Föderation setzt, sollte das vorher austesten. Auch bei eingebundenen externen Speichern lohnt ein Test: Der Dokumentenserver greift über die Nextcloud auf die Dateien zu, was in der Regel funktioniert, aber gelegentlich an Rechtefragen scheitert.

Eine Entscheidungshilfe statt eines Glaubenskriegs

Am Ende läuft alles auf eine nüchterne Frage hinaus: Wie viele Menschen arbeiten wie oft und wie gleichzeitig an Dokumenten in dieser Cloud?

Für eine Familie, einen Verein, eine kleine Kanzlei mit drei Arbeitsplätzen oder eine private Testinstanz ist der integrierte Weg vollkommen ausreichend. Er spart Zeit bei der Einrichtung, verursacht keine zusätzlichen Kosten und erfüllt den Zweck. Wer dort auf den Community Document Server setzt und gelegentlich einen Neustart einplant, wird in vielen Fällen zufrieden sein. Ehrlicherweise muss man aber ergänzen, dass unter den integrierten Varianten derzeit der Collabora-Zweig die verlässlichere Wahl zu sein scheint.

Für alles, was produktiv einen Arbeitsalltag tragen soll – mit zweistelligen Nutzerzahlen, mit Anforderungen an Verfügbarkeit, mit Menschen, die sich auf das System verlassen – führt an einem eigenständig betriebenen Dokumentenserver kaum ein Weg vorbei. Der Aufwand für einen Container, ein Zertifikat und ein paar Zeilen in der Proxy-Konfiguration ist überschaubar. Er ist deutlich kleiner als der Aufwand, den eine wackelige Integration im Störungsfall erzeugt.

Interessant ist der größere Zusammenhang. Der Community Document Server war der Versuch, eine komplexe Aufgabe in einer App zu verstecken. Das hat funktioniert, solange die Aufgabe klein war. Mit wachsender Nutzung kehrt die Komplexität zurück – nur diesmal an einer Stelle, an der man sie kaum noch kontrollieren kann, weil sie untrennbar mit der Cloud selbst verwoben ist. Gute Infrastruktur zeichnet sich nicht dadurch aus, dass sie Komplexität verbirgt, sondern dadurch, dass sie Komplexität an den richtigen Stellen sichtbar und damit beherrschbar macht.

Wer eine Nextcloud neu aufsetzt, sollte sich also nicht von der Bequemlichkeit einer einzigen App leiten lassen, sondern von der Frage, wie das System in zwei Jahren aussehen soll. Die Antwort darauf entscheidet, ob der Dokumentenserver mitwächst oder ob er irgendwann zu jenem Bauteil wird, das man stillschweigend umgeht, weil niemand mehr weiß, warum es eigentlich klemmt.