Digitale Souveränität ist mehr als der Speicherort deiner Daten

Mathias hat mit dem Unterschied zwischen Datensouveränität und Governance angefangen. Wenn Regierungen und Unternehmen über Souveränität sprechen, meinen sie meistens Datensouveränität: Deine Daten liegen auf Servern im eigenen Land. Das können auch proprietäre Anbieter problemlos bieten. Sie sagen dir, du sollst ihre Server nutzen, und versprechen, dass du deine Daten jederzeit wieder herausbekommst.

Was dabei untergeht, ist die Governance. Wer kontrolliert die Software, wer darf sie ändern, und was passiert, wenn jemand außerhalb deines Landes die Regeln ändert? Die Daten mögen dir gehören, aber solange sie bei einem Anbieter liegen, hast du nicht die Kontrolle darüber. Eine politische Entscheidung anderswo — und das müssen nicht die USA sein — kann dir den Zugang zu einem System abschneiden, das deine Daten technisch gesehen im eigenen Land speichert.

Mathias hat außerdem darauf hingewiesen, dass Open Source dir nicht nur die Freiheit gibt, Software zu nutzen. Du kannst sie auch lernen. Wenn du Open Source einsetzt, landet das Know-how bei den Leuten, die die Software nutzen und betreiben, verteilt über ein Land, die EU oder die ganze Welt, statt bei einem einzigen Anbieter zu verbleiben. Dieses verteilte Wissen kann proprietäre Software nicht bieten, und Open-Source-Communitys nutzen es viel zu selten als Argument.

In TYPO3-Projekten sehen wir das genauso. Wenn ein Kunde fragt, warum TYPO3 eine souveräne Wahl ist, zeige ich nicht auf ein Feature. Ich zeige auf die Governance-Struktur, den Release-Zyklus und die vielen Leute, die das System kennen. Nichts davon gehört einer einzelnen Firma, und nichts davon kann jemand verkaufen.

Fabian Stein von punkt.de hat die pragmatische Seite vertreten. Bei Nutzung von proprietärer Software kann. man datensouverän bleiben, indem man die Daten täglich separat sichert. Wäre die Plattform morgen weg, hätte man immer noch das, worauf es ankommt.

Für ihn war Souveränität früher eine Ja-oder-Nein-Frage und ist inzwischen eine Skala. Manchmal ist das proprietäre Tool einfach besser, und dann ist die ehrliche Empfehlung an den Kunden, es zu nutzen, solange es eine Exit-Strategie mit bekannten Kosten und bekanntem Zeitrahmen gibt. Ein Monat und ein fünfstelliges Budget für den Umstieg sind ein vertretbares Risiko. Ein Migrationsprojekt, das ein Jahr dauert, hingegen nicht.

Dem stimme ich zu. Eine Exit-Strategie mit echtem Preisschild ist mehr wert als eine Grundsatzentscheidung, die niemand durchhalten kann. Ich würde nur ergänzen, dass eine Exit-Strategie selbst eine Governance-Frage ist. Regelmäßige Exporte, dokumentierte Datenstrukturen und Repositorys, die der Kunde jederzeit klonen kann, sind genau das, was Mathias mit der Kontrolle über die gesamte Lösung gemeint hat. Die beiden Positionen lagen näher beieinander, als es zuerst klang.

Danach ging es um Agenturen und um unsere eigenen Entscheidungen.

Vor etwa zehn Jahren haben wir bei b13 entschieden, nur noch mit einem CMS zu arbeiten. Wir hatten ein zweites System ausprobiert, weil ein Kunde uns dazu gedrängt hatte, und es hat nicht funktioniert. Um in einem anderen System auf dasselbe Niveau zu kommen, braucht es viel Zeit und viel Ausprobieren, und dieses Ausprobieren wollten wir nicht in Kundenprojekten machen. Dazu kommt ein zweites Problem: Wenn die kleinen Projekte auf dem neuen System laufen und die großen Kunden auf dem alten bleiben, landen die kleinen Projekte immer auf dem zweiten Platz. Und am Ende wollte bei uns im Team ohnehin niemand mit einem anderen System arbeiten.

Fabians Agentur hat den umgekehrten Weg gewählt. Sie nimmt regelmäßig neue Technologien dazu, und nach seiner Erfahrung ist ein guter Entwickler nach vier oder fünf Wochen weit genug in einem neuen Stack, um „three pages ahead of the client in the book“ zu sein, also dem Kunden drei Schritte voraus. Mit KI geht das laut Fabian noch schneller, das Lernen neuer Software ist also nicht mehr der Engpass.

Was KI angeht, hat er recht. Wir sehen das auch bei b13: Unsere Projektmanager bauen inzwischen mit KI kleine Backend-Module, für die wir vor einem Jahr noch einen Entwickler gebraucht hätten. Aber jemand muss prüfen, was dabei herauskommt: Hält es sich an die Best Practices von TYPO3? Passt es zum Rest der Codebasis im Projekt? Ist es sicher? Für diese Reviews braucht es jemanden, der das System gut kennt. Wenn in deinem Team niemand dieses Wissen hat, schreibt die KI trotzdem Code, aber niemand kann beurteilen, ob er in drei Jahren noch hält.

Für uns war Fokus deshalb nie eine Frage des Geldes. Wir sind bei einem System geblieben, weil wir nur so für die Qualität dessen geradestehen können, was wir liefern. KI macht den Einstieg in ein neues System günstiger, aber für das, was du damit baust, bist du trotzdem verantwortlich.

Dann hat Mathias gefragt: Wenn es richtig einfach würde, von TYPO3 wegzugehen, wäre das dann das Ende von TYPO3?

Ich glaube nicht. Unsere Kunden bleiben nicht wegen TYPO3 bei uns. Sie bleiben wegen der Zusammenarbeit, weil wir ihr Geschäft verstehen und weil wir seit Jahren zusammenarbeiten. Wenn das nicht mehr funktioniert, sollen sie wechseln können, und TYPO3 macht das möglich. Das ist einer der Gründe, warum wir es empfehlen: Unsere Kunden sind nicht von uns abhängig. Es gibt ein großes Ökosystem an TYPO3-Agenturen, und jeder Kunde kann sein Projekt zu einer davon mitnehmen.

Nach unserer Erfahrung gehen Kunden selten wegen der Software. Wenn einer von TYPO3 weg wechselt, dann meistens, weil das Unternehmen gekauft wurde und der neue Eigentümer ein anderes System nutzt. Und der Umstieg ist nicht so schwer, wie viele denken. Strukturierte Inhalte lassen sich migrieren. Mit KI kannst du eine Website auch ausgehend vom Live-Frontend in einem anderen System nachbauen. Das ist manchmal der bessere Weg als ein Datenbank-Export voller Inhalte, die seit Jahren nicht mehr online sind. Wir haben das selbst gemacht, als wir größere WordPress-Websites nach TYPO3 umgezogen haben.

Immer mehr unserer größeren Kunden wollen dasselbe wie staatliche Stellen: ein Open-Source-System, Zugang zum Code und Leute in der eigenen Organisation, die verstehen, wie das System funktioniert. Bei einigen von ihnen arbeiten wir direkt mit dem IT-Team zusammen und zeigen ihm, wie es kleinere Änderungen selbst umsetzt. Manche stellen eigene Merge Requests, und wir reviewen sie.

So arbeiten wir schon lange, und wir haben das nie als eigene Leistung gesehen. Als ich Mathias zugehört habe, ist mir klar geworden, dass es genau das ist, was er als fehlendes Stück der Souveränität beschrieben hat: Know-how dort aufbauen, wo das System genutzt wird. Wir haben bisher nur selten öffentlich darüber gesprochen.

Natürlich gibt es dabei eine Sorge. Wenn ich mein Wissen weitergebe, braucht mich der Kunde vielleicht nicht mehr. Fabian hat erzählt, dass einer ihrer Kunden die Arbeit vor Kurzem ins eigene Haus geholt hat, weil er jetzt vier oder fünf Leute hat, die das selbst können, und er sieht das als gutes Ergebnis. Ich sehe das genauso, und ich glaube nicht, dass die Agentur dadurch überflüssig wird.

Wir haben erlebt, was mit internen Teams passiert, die jahrelang an ihren eigenen Systemen arbeiten. Sie sehen immer nur ihr eigenes Projekt. Sie stoßen nicht auf andere Systeme, andere Probleme oder andere Lösungswege, und mit der Zeit setzt die Art, wie sie ihre Website pflegen, Rost an. Vorgehensweisen, die vor fünf Jahren in Ordnung waren, bleiben bestehen, lange nachdem es bessere gibt. Eine Agentur, die an vielen TYPO3-Projekten arbeitet, bringt diesen Blick von außen wieder hinein. Auch wenn ein Kunde ein eigenes Team aufbaut, gibt es also einen guten Grund, weiter mit einer Agentur zu arbeiten: Wir helfen den internen Entwicklern, auf dem aktuellen Stand zu bleiben.

Das verändert auch, wie wir mit neuen Kunden über Souveränität sprechen. Wir sagen immer: Wir wollen wissen, was du willst, und dann herausfinden, was du brauchst. Souveränität gehört oft in die zweite Gruppe. Jeder braucht sie, aber nicht jeder weiß das schon.

Zum Schluss hat Mathias alle am Tisch gefragt, was die CMS-Communitys besser machen könnten. Meine Antwort war konkret: Ich wünsche mir, dass die TYPO3 Association aufzeigt, wie ein Unternehmen oder eine öffentliche Einrichtung mit Hilfe von TYPO3-Partnern ein eigenes TYPO3-Know-how aufbauen kann. Nicht nur eine Liste von Agenturen, sondern einen Weg, TYPO3 so gut kennenzulernen, dass man es selbst in der Hand hat. Diesen Weg gibt es heute schon, aber nur wenige wissen davon.

Mathias hat mit einem Punkt abgeschlossen, dem ich voll zustimme: Souveränität funktioniert nur, wenn Kunden, Agenturen und CMS-Communitys sich gegenseitig unterstützen und wenn wir aufhören, sie als Alles-oder-nichts zu behandeln. Volle digitale Souveränität ist für die meisten Organisationen nicht realistisch, aber die meisten können ihr ein gutes Stück näherkommen, als sie es heute sind.

• Daten im eigenen Land zu halten ist notwendig, aber das schwächste Argument für Souveränität, denn das können proprietäre Anbieter auch.
• Governance und Know-how vor Ort kann nur Open Source bieten, und darüber sollten wir mehr reden.
• Eine Exit-Strategie mit echtem Preisschild ist besser als Dogma.
• KI senkt die Kosten für den Einstieg in ein neues System. Für das, was du baust, bist du trotzdem verantwortlich.
• Wissenstransfer bedroht das Agenturmodell nicht. Er ist Teil der Souveränität.