Offener Code allein hält keinen Betrieb am Laufen

Warum eine Open Source Software in der Community Edition ein Microsoft 365 nicht automatisch digital souverän ersetzt

Ich bin ein überzeugter Befürworter digitaler Souveränität. Europa muss seine Abhängigkeit von den großen US-Technologiekonzernen verringern – gerade beim digitalen Arbeitsplatz. E-Mail, Kalender, Dateien, Dokumente, Chat und Videokonferenzen sind längst keine Hilfsmittel mehr. Sie gehören zur geschäftskritischen Infrastruktur eines Unternehmens oder einer Behörde.

Deshalb ist es gut, dass inzwischen leistungsfähige Alternativen aus Deutschland und Europa existieren. Nextcloud Hub überzeugt durch Offenheit, ein großes Ökosystem und weitreichende Kontrolle. openDesk verfolgt einen konsequenten Open-Source-Komplettansatz für die öffentliche Verwaltung. EGroupware verbindet klassische Groupware mit einem modernen Online-Office. OpenCloud ist vor allem für Filesharing und Dokumentenkollaboration interessant.

Daneben stehen proprietär entwickelte Plattformen wie Stackfield und xworks.365. Stackfield konzentriert sich auf sichere Projektarbeit und Teamkommunikation. xworks.365 bietet einen integrierten und vollständig betriebenen digitalen Arbeitsplatz, der auch white-label-fähig ist.

Alle diese Angebote können einen Beitrag zu mehr digitaler Souveränität leisten. Trotzdem wird in der Debatte häufig eine problematische Abkürzung genommen: Open Source wird mit digitaler Souveränität gleichgesetzt. Ich halte das für einen großen Fehler.

Eine Community Edition ist noch kein belastbarer Plattformbetrieb

Der Heise-Beitrag „openDesk: Für wen ist die Community-Version überhaupt gedacht?" beschreibt das Problem sehr anschaulich. openDesk bündelt zahlreiche etablierte Open-Source-Komponenten zu einem digitalen Arbeitsplatz. Die Community Edition kann selbst installiert und betrieben werden. Für Erprobungen, Machbarkeitsstudien oder technisch versierte kleinere Einheiten ist das ein sinnvoller Einstieg.

Im geschäftskritischen Produktivbetrieb zeigt sich jedoch, was gegenüber der Enterprise Edition fehlt: priorisierte Sicherheitspatches, zentrale Administrationswerkzeuge, zusätzliche Cluster- und Hochverfügbarkeitsfunktionen, integrierte Betriebswerkzeuge und verbindlicher Support. Hinzu kommt eine anspruchsvolle Kubernetes-Infrastruktur, die beherrscht, überwacht und rund um die Uhr abgesichert werden muss.

Das ist kein spezielles Problem von openDesk. Auch bei anderen Open-Source-Plattformen liegen längere Wartungszeiträume, Enterprise-QA, Hochverfügbarkeit, zentrale Administration oder garantierte Reaktionszeiten häufig in kommerziellen Angeboten. Die Community Edition stellt Software bereit. Den zuverlässigen Service daraus muss der Betreiber selbst bauen.

Und genau hier liegt der Denkfehler vieler Ausschreibungen: Einsehbarer Quellcode garantiert weder Verfügbarkeit noch Wiederanlauf. Ein Repository übernimmt keine Rufbereitschaft, testet kein Restore und spielt keinen kritischen Patch ohne Unterbrechung ein. Es koordiniert auch nicht automatisch die Releasezyklen mehrerer Komponenten.

Open Source schafft Transparenz und kann Abhängigkeiten reduzieren. Business Continuity entsteht jedoch erst durch Architektur, Prozesse, Automatisierung, Erfahrung und eine klar zugeordnete Verantwortung.

Selbstbetrieb ist nicht automatisch Selbstbestimmung

Wer eine Community Edition produktiv einsetzt, übernimmt die Verantwortung für das Gesamtsystem: Plattformarchitektur, Datenbanken, Speicher, Netzwerk, Monitoring, Backups+Restore, Hochverfügbarkeit, Patchmanagement, Identitäten, Berechtigungen, Sicherheitsvorfälle und Notfallbetrieb.

Bei einer einzelnen Anwendung mag das überschaubar sein. Bei einer Kollaborationsplattform aus mehreren Produkten vervielfacht sich der Aufwand. Jede Komponente besitzt eigene Abhängigkeiten, Releasezyklen und Betriebsanforderungen. Ein Komponenten-Update kann technisch erfolgreich sein und trotzdem eine Schnittstelle, das Single Sign-on oder einen übergreifenden Prozess beeinträchtigen.

Natürlich können große Organisationen oder öffentliche IT-Dienstleister dafür ein eigenes Plattformteam aufbauen. Bei einer hinreichend großen Nutzerzahl und bereits vorhandener Kompetenz kann das strategisch sinnvoll sein. Doch dazu braucht es weit mehr als einige Administratoren. Erforderlich sind DevOps, Softwareentwicklung, Qualitätssicherung, Security, Datenbank- und Storage-Know-how, Support, dokumentierte Vertretungen und eine belastbare Bereitschaftsorganisation.

Wer diese Fähigkeiten nicht dauerhaft vorhalten kann, wird durch Eigenbetrieb nicht souveräner. Er ersetzt die Abhängigkeit von einem Hersteller durch die Abhängigkeit von wenigen Spezialisten, selbst geschriebenen Skripten oder einem externen Integrator.

Auch ein Managed Service löst das Grundproblem nicht vollständig

Häufig wird deshalb ein Dienstleister mit dem Betrieb der Open-Source-Plattform beauftragt. Das ist professioneller als ein unterschätzter Eigenbetrieb, beseitigt aber eine strukturelle Schwäche nicht: Produktentwicklung und Betriebsverantwortung bleiben getrennt.

Der Managed-Service-Anbieter kann überwachen, skalieren und Störungen bearbeiten. Bei einem Fehler in der Software, einer kritischen Wechselwirkung zwischen Komponenten oder einem fehlenden Enterprise-Feature ist er jedoch auf mehrere Hersteller und Communities angewiesen. Er kann Patches testen und verteilen, aber nicht in jedem Fall selbst kurzfristig entwickeln. Bei einer komplexen Plattform entstehen damit zusätzliche Abstimmungswege – gerade dann, wenn Zeit der entscheidende Faktor ist.

Ein Plattformbetreiber mit eigenem Produkt besitzt hier einen wesentlichen Vorteil. Entwicklung, Betrieb, Monitoring, Support und Release-Management liegen in einer Hand. Erkennt der Betrieb ein Problem, kann es unmittelbar in die Produktentwicklung zurückgespielt werden. Ein Fix kann entwickelt, automatisiert getestet und kontrolliert ausgerollt werden. Erkenntnisse aus Lastspitzen, Sicherheitsereignissen oder dem Nutzerverhalten fließen direkt in Architektur und Roadmap ein.

Diese enge Rückkopplung macht eine Plattform nicht automatisch fehlerfrei. Sie verkürzt aber Verantwortungs- und Reaktionsketten. Für Business Continuity ist das entscheidend.

Skalierung bedeutet mehr als viele Benutzerkonten

Ob eine Plattform zehn-, hunderttausend oder noch mehr Nutzer bedienen kann, entscheidet sich nicht allein an der Software. Entscheidend ist, ob der gesamte Betrieb für diese Größenordnung entworfen wurde: redundante Infrastruktur, automatisches Failover, rollierende Updates, Kapazitätssteuerung, getestete Wiederherstellung und eine Organisation, die Störungen jederzeit beherrscht.

Gerade bei großen Nutzerzahlen spielt ein spezialisierter Plattformbetreiber seine Stärke aus. Er betreibt nicht für jeden Kunden eine individuell zusammengesetzte Installation, sondern entwickelt und optimiert ein wiederholbares Gesamtprodukt. Verbesserungen, Automatisierungen und Fehlerkorrekturen wirken für die gesamte Plattform. Die Kosten für hoch spezialisierte Teams verteilen sich über viele Kunden und Nutzer.

Damit kann eine herstellerbetriebene Plattform auch in Umgebungen mit Zehntausenden oder Hunderttausenden Anwendern wirtschaftlicher, agiler und belastbarer sein als der Eigenbetrieb oder ein individuell beauftragter Managed Service. Voraussetzung bleiben natürlich eine nachgewiesene skalierbare Architektur, belastbare Service Levels, transparente Sicherheitsprozesse und ein realistisches Exit-Konzept.

Was digitale Souveränität wirklich verlangt

Digitale Souveränität bedeutet nicht, alles selbst zu betreiben. Sie bedeutet, Abhängigkeiten bewusst auszuwählen, zu kontrollieren und bei Bedarf beenden zu können. Dazu gehören offene Standards und Schnittstellen, vollständige Exportmöglichkeiten, verlässliche Datenlokation, transparente Unterauftragnehmer, nachvollziehbare Sicherheits- und Patchprozesse sowie vertraglich geregelte Unterstützung beim Wechsel.

Diese Kriterien müssen für Open-Source- und proprietäre Angebote gleichermaßen gelten. Eine Community Edition ist nicht allein deshalb souverän, weil ihr Code offenliegt. Und eine proprietäre Plattform ist nicht allein deshalb unsouverän, weil ihr Quellcode nicht veröffentlicht wird.

Die richtige Frage lautet daher nicht: Ist die Software Open Source? Sie lautet: Welches Produkt- und Betriebsmodell gewährleistet langfristig Handlungsfähigkeit, Sicherheit, Wirtschaftlichkeit und Business Continuity?

Mein Fazit: Das Zeug muss funktionieren

Community Editions von Nextcloud, openDesk, EGroupware und OpenCloud sind wertvoll. Sie schaffen Transparenz, ermöglichen Erprobung und können für Organisationen mit einem eigenen, hoch qualifizierten Plattformteam eine sinnvolle Basis sein. Als Ersatz von Microsoft 365 im Produktiveinsatz gerade in kleinen Teams führen sie jedoch in die falsche Richtung.

Im Unternehmensalltag zählt nicht allein, ob Quellcode überprüfbar ist. Entscheidend ist, ob E-Mail, Dateien, Kommunikation und Zusammenarbeit auch während eines Updates, einer Lastspitze oder eines Sicherheitsvorfalls verlässlich verfügbar bleiben. Mitarbeiter erwarten zu Recht, dass ihr digitaler Arbeitsplatz funktioniert.

Für viele Anwendungsfälle sind Stackfield und xworks.365 deshalb die bessere Alternative. Beide folgen dem Modell eines verantworteten Gesamtprodukts: Spezialisierte Teams entwickeln die Plattform weiter und betreiben sie zugleich. Diese Einheit schafft kurze Wege, schnelle Releases und eine hohe Reaktionsfähigkeit. Das ist nicht nur bei einigen Hundert oder Tausend Arbeitsplätzen relevant, sondern gerade auch in Umgebungen mit Zehntausenden oder Hunderttausenden Nutzern.

Transparenzhinweis: Ich bin Geschäftsführer der mediaBEAM GmbH, die xworks.365 entwickelt und betreibt. Meine Bewertung ist daher von unserer eigenen Erfahrung geprägt. Gerade diese Erfahrung zeigt mir täglich, wie viel Architektur, Automatisierung und organisatorische Disziplin hinter einem hochverfügbaren Plattformbetrieb stehen.

Öffentliche Auftraggeber und Unternehmen sollten deshalb nicht länger reflexartig eine bestimmte Lizenzform verlangen. Sie sollten das Ergebnis ausschreiben: digitale Souveränität, offene Schnittstellen, Exit-Fähigkeit, Sicherheit, Skalierbarkeit und nachgewiesene Business Continuity.

Denn am Ende wollen die Nutzer keine ideologische Debatte über Lizenzmodelle führen. Sie wollen arbeiten. Schlicht gesagt: Das Zeug muss funktionieren.