Offener Quellcode ist der Anfang der Prüfung
Eine Organisation ersetzt eine proprietäre Anwendung durch Open Source. Der Quellcode ist verfügbar, doch Updates beherrscht nur ein Dienstleister. Die Installation enthält zahlreiche nicht dokumentierte Anpassungen, und ein Export lässt wichtige Beziehungen zwischen Datensätzen aus. Die Lizenzentscheidung hat damit einen Handlungsspielraum eröffnet, der im Alltag noch nicht nutzbar ist.
Digitale Souveränität erfordert die Fähigkeit, eine Lösung zu verstehen, weiterzuentwickeln, zu betreiben und bei Bedarf zu ersetzen. Open Source kann dafür eine wichtige Grundlage bilden. Ob die Organisation diese Möglichkeiten tatsächlich wahrnehmen kann, hängt auch von Architektur, Fähigkeiten und Betriebsorganisation ab.
Für die Auswahl sollte deshalb ein nachvollziehbares Gesamtbild entstehen. Funktionsumfang und Lizenzkosten allein reichen nicht aus. Entscheidend sind ebenso Pflegeaufwand, Sicherheit, Integrationsfähigkeit, verfügbare Unterstützung und der Umgang mit einem möglichen Projektende.
1. Projektpflege und Sicherheitsprozesse bewerten
Prüfen Sie, ob das Projekt aktiv und nachvollziehbar gepflegt wird. Gibt es einen erklärten Veröffentlichungsprozess, dokumentierte unterstützte Versionen und einen Weg, Sicherheitsprobleme vertraulich zu melden? Werden Fehler und Änderungsanfragen erkennbar bearbeitet? Einzelne Kennzahlen wie die Anzahl der Sterne eines Repositorys beantworten diese Fragen nicht.
Der OpenSSF-Leitfaden zur Bewertung von Open-Source-Software bietet dafür konkrete Prüfpunkte, unter anderem zu Wartung und Sicherheitspraktiken. Solche Kriterien helfen bei der strukturierten Auswahl; ein positives Ergebnis ersetzt jedoch keine Prüfung der eigenen Installation und ihres Einsatzzwecks.
Untersuchen Sie außerdem die kritischen Abhängigkeiten der Lösung. Eine gepflegte Hauptanwendung kann Komponenten enthalten, deren Wartung ausläuft. Ein Komponentenverzeichnis erleichtert die Zuordnung gemeldeter Schwachstellen zu den eingesetzten Versionen. Entscheiden Sie, wer neue Meldungen bewertet, Aktualisierungen vorbereitet und notwendige Schutzmaßnahmen koordiniert.
Bewerten Sie die Folgen eines Wartungsendes. Gibt es alternative Partner oder ein internes Team, das die Pflege übernehmen könnte? Ein eigener Fork ist technisch möglich, aber mit dauerhafter Entwicklungs- und Sicherheitsverantwortung verbunden. Diese Option sollte mit Personalbedarf und Kosten beschrieben werden.
2. Anpassungen so gestalten, dass Updates möglich bleiben
Viele Abhängigkeiten entstehen erst nach der Einführung. Änderungen direkt im Kern der Anwendung können jede neue Version zu einem aufwendigen Abgleich machen. Bevorzugen Sie, soweit fachlich geeignet, dokumentierte Erweiterungspunkte und Konfiguration. Führen Sie eigene Anpassungen in einer überschaubaren, versionierten Form mit zugehörigen fachlichen Tests.
Klären Sie, welche Erweiterungen in das ursprüngliche Projekt zurückfließen können und wer dafür zuständig ist. Eine Übernahme durch das Projekt ist nicht garantiert. Solange sie aussteht, bleibt die Organisation für ihre Variante verantwortlich und muss Sicherheitskorrekturen gegebenenfalls selbst übertragen.
Eine Updateprobe gehört deshalb in die Auswahl. Installieren Sie eine realistische Konfiguration, nehmen Sie eine typische Anpassung vor und führen Sie einen Versionswechsel durch. Dokumentieren Sie notwendige Handgriffe und Inkompatibilitäten. Dadurch wird aus einer allgemeinen Aussage zur Wartbarkeit ein konkreter Befund.
3. Nutzungsrechte, Wissen und Betriebszugang zusammenbringen
Prüfen Sie für den vorgesehenen Einsatz, welche Bedingungen die Software und ihre Abhängigkeiten mitbringen. Dabei können Veränderungen, Weitergabe, Netzwerkbereitstellung und zusätzliche kommerzielle Komponenten unterschiedlich zu bewerten sein. Lassen Sie offene Lizenzfragen anhand der tatsächlich eingesetzten Bestandteile durch die zuständigen Fachleute klären.
Erfassen Sie insbesondere Funktionen, die nur mit gesonderten Erweiterungen oder Verträgen verfügbar sind. Eine offene Basisversion sagt wenig darüber aus, ob benötigte Betriebsfunktionen vollständig enthalten sind. In den Kostenvergleich gehören daher auch Support, Integration, Schulung, Testumgebungen und laufende Aktualisierung.
Sichern Sie parallel das praktische Wissen. Die eigene Organisation sollte Architektur und Verantwortungsgrenzen beurteilen können, selbst wenn ein Partner den Betrieb übernimmt. Benötigt werden zugängliche Installationsunterlagen, Konfigurationen, dokumentierte Datenmodelle und ein geregelter Zugriff auf administrative Funktionen. Zugangsdaten werden geschützt verwaltet und bei einem Wechsel kontrolliert übertragen oder ersetzt.
4. Wechselmöglichkeiten mit einem konkreten Szenario testen
Ein illustratives Beispiel ist eine offene Plattform für die interne Wissensablage. Sie erfüllt die fachlichen Anforderungen und nutzt ein verbreitetes Datenbanksystem. Dennoch liegen Anhänge in einem gesonderten Speicher, Rollen in einer Erweiterung und Verknüpfungen zwischen Dokumenten in einem anwendungsspezifischen Format.
Ein Wechseltest umfasst deshalb mehr als einen Datenbankexport. Ein repräsentativer Bestand wird mit Dokumenten, Anhängen, Verknüpfungen und ausgewählten Berechtigungen übertragen. Ein zweites Team setzt die Plattform aus den Unterlagen neu auf und prüft, ob Inhalte auffindbar und sinnvoll weiterverwendbar sind. Auch eine fachlich andere Ziellösung kann zusätzliche Transformationen erfordern.
Die Ergebnisse werden in einem Übergabeplan festgehalten. Welche Informationen lassen sich direkt übernehmen? Welche Funktionen müssten ersetzt werden? Welche Hilfe wird vom bisherigen Partner benötigt? So wird sichtbar, ob ein Wechsel organisatorisch und wirtschaftlich machbar wäre.
Open Source und Managed Services können dabei zusammenpassen. Ein externer Betreiber kann Fähigkeiten bereitstellen, die intern fehlen. Souveränität entsteht dann durch klare Verantwortlichkeit, nachvollziehbare Leistungen und eine realistische Möglichkeit, den Betrieb mit einem anderen Partner fortzusetzen.
Eine belastbare Auswahlentscheidung treffen
- Fachliche Eignung: Die notwendigen Aufgaben werden mit einer realistischen Konfiguration geprüft.
- Pflege: Unterstützte Versionen, Sicherheitsmeldungen und kritische Abhängigkeiten sind bekannt.
- Wartbarkeit: Ein Update mit typischen Anpassungen wurde nachvollziehbar erprobt.
- Betriebsfähigkeit: Unterlagen und Fähigkeiten reichen aus, damit ein alternatives qualifiziertes Team übernehmen kann.
- Wechsel: Datenübernahme, Ersatzfunktionen und verbleibender Aufwand sind dokumentiert.
Gewichten Sie diese Kriterien nach der Bedeutung der Anwendung. Ein kleines Hilfswerkzeug benötigt eine andere Untersuchungstiefe als ein zentrales Fachverfahren. Die Entscheidung sollte dennoch immer erkennen lassen, welche Abhängigkeiten akzeptiert werden, wer sie verantwortet und wann sie erneut überprüft werden. So wird Offenheit zu einem praktisch nutzbaren Handlungsspielraum.