CONSULTING · 06 / 06
Technologieentscheidungen halten länger als die Projekte, in denen sie getroffen werden. Wir bewerten offene Software entlang messbarer Kriterien: fachliche Anforderungen, Gesundheit des Projekts, Lizenzverträglichkeit, Betriebskosten über mehrere Jahre und die Frage, wie ein Ausstieg praktisch aussähe. Das Ergebnis ist eine dokumentierte Entscheidung, die auch nach einem Personalwechsel noch nachvollziehbar bleibt.
Ausgangslage
Ausgewählt wird häufig entlang der Sichtbarkeit: Was viele Sterne, Konferenzvorträge und Tutorials hat, wirkt sicher. Zwei Jahre später zeigt sich das Gegenteil – das letzte Release liegt vierzehn Monate zurück, ein einzelner Maintainer beantwortet Issues sporadisch, und eine gemeldete Schwachstelle steht seit Wochen unbeantwortet im Tracker. Popularität misst Aufmerksamkeit, nicht die Zusage, ein System über Jahre zu pflegen.
Lizenzfragen tauchen zu spät auf, meist im Due-Diligence-Prozess oder kurz vor einem Release. Dann steckt eine AGPL-3.0-Komponente in einem Dienst, der über das Netz angeboten wird, oder eine ursprünglich unter Apache-2.0 eingeführte Datenbank ist inzwischen auf eine Quellcode-verfügbare Lizenz umgestellt. Ohne Stückliste weiß niemand, welche transitiven Abhängigkeiten überhaupt mitgeliefert werden und welche Pflichten daran hängen.
Kostenvergleiche verkürzen sich auf den Lizenzpreis. „Kostenlos“ ignoriert Patch-Fenster, Wiederherstellungstests, Monitoring, Schulung und die Zeit, die ein Team braucht, um eine Komponente wirklich zu beherrschen. Umgekehrt bleibt bei proprietären Produkten unbewertet, was eine Preiserhöhung, ein Wechsel des Lizenzmodells oder eine Produkteinstellung tatsächlich kosten würde – gerade dann, wenn Daten nur über eine herstellereigene Schnittstelle erreichbar sind.
Und es fehlt eine Regel, wer entscheiden darf. Jedes Team wählt eigenständig, im Ergebnis laufen drei Message-Broker, zwei Observability-Stacks und vier Build-Werkzeuge parallel. Die Betriebskompetenz verteilt sich dünn über viele Systeme, jede zusätzliche Komponente vergrößert die Angriffsfläche, und die Rechtsabteilung bremst am Ende Entscheidungen, an denen sie vorher nicht beteiligt war.
Vorgehen
Am Anfang stehen Anforderungen, keine Produktnamen: Datenvolumen, Latenzbudget, Konsistenz- und Verfügbarkeitsziele, Betriebsmodell, Größe und Erfahrung des Teams, regulatorischer Rahmen. Daraus entsteht eine gewichtete Bewertungsmatrix – jedes Kriterium mit Gewicht, jede Option mit Begründung. Die Entscheidung wandert als Architecture Decision Record ins Repository, samt der verworfenen Alternativen und der Bedingungen, unter denen sie neu zu prüfen ist.
Projektgesundheit messen wir an prüfbaren Signalen: Release-Kadenz und Versionierungsdisziplin, Verteilung der Commits über Autoren und Organisationen, wie sie git shortlog -sn --since=12.months sichtbar macht, Reaktionszeit auf Sicherheitsmeldungen, Qualität einer SECURITY.md, CVE-Historie, Testabdeckung und CI-Reife. Erklärte Wartungszeiträume sind planbare Größen – ein Debian-Release wird inklusive LTS etwa fünf Jahre gepflegt, ein PostgreSQL-Hauptrelease fünf Jahre ab Erscheinen. Auch die Governance zählt: Stiftung oder Einzelanbieter, DCO oder CLA, wer Release-Rechte hält.
Lizenzen prüfen wir auf Verträglichkeit, nicht nur auf ihren Namen. Jede Komponente erhält einen SPDX-Identifikator, die Stückliste entsteht automatisiert als SBOM im CycloneDX- oder SPDX-Format und wird in der Pipeline gegen Schwachstellendaten abgeglichen. Entscheidend ist die Reichweite des Copyleft: GPL-2.0 gegenüber LGPL gegenüber AGPL, statisches oder dynamisches Einbinden, Weitergabe als Paket oder Betrieb als Dienst. Daraus folgen sehr unterschiedliche Pflichten – und bei Einzelanbieter-Projekten mit CLA zusätzlich das Risiko einer späteren Relizenzierung.
Kosten rechnen wir über drei bis fünf Jahre: Betrieb, Support, Patch-Aufwand, Migration und Schulung gegen Lizenz- und Abhängigkeitskosten. Der Exit wird nicht behauptet, sondern durchgespielt – Export der Daten, Import in die Alternative, Vergleich der Ergebnisse. Offene Formate, dokumentierte Protokolle und mindestens eine zweite unabhängige Implementierung sind belastbarere Argumente als jede Zusicherung im Vertrag.
Leistungsumfang
01
02
03
04
05
06
07
Einsatzfälle
Ein Projekt stellt von einer OSI-anerkannten Lizenz auf ein Quellcode-verfügbares Modell um. Zu klären ist, ob der entstandene Fork trägt, was ein Wechsel kostet und wie lange die bisherige Version sicher betreibbar bleibt.
Mehrere Teams haben unabhängig voneinander Broker, Datenbanken und Observability-Werkzeuge eingeführt. Gesucht ist ein Zielbild mit begründeter Ablösereihenfolge statt einer reinen Bestandsaufnahme.
Vor der Migration steht die Frage, ob eine offene Alternative die fachlichen Anforderungen wirklich trägt. Wir prüfen das im Testaufbau mit produktionsnahen Daten, bevor Budget gebunden wird.
Engineering, Einkauf und Recht brauchen einen gemeinsamen Prozess: welche Lizenzen ohne Rückfrage erlaubt sind, wer im Zweifel entscheidet und wie eigene Beiträge nach außen freigegeben werden.
Ergebnis
Ablauf
Fragen
Wir sehen uns Release-Kadenz und Versionierungsdisziplin an, die Verteilung der Commits über Autoren und Organisationen, die Reaktionszeit auf Sicherheitsmeldungen und das Governance-Modell. Ein Projekt mit Stiftungsträger, mehreren unabhängigen Beitragenden und dokumentiertem Sicherheitsprozess ist tragfähiger als eines mit hoher Sichtbarkeit und einem einzelnen Maintainer. Diese Signale sind öffentlich prüfbar; Sternzahlen sagen darüber nichts aus.
Das hängt davon ab, wie Sie ausliefern. Die GPL-Pflichten greifen bei Weitergabe des Programms: Lizenztext, Hinweis auf Änderungen und ein Angebot des zugehörigen Quellcodes. Die AGPL erweitert das auf den Betrieb als Netzdienst, also auch ohne Auslieferung von Binärpaketen. Wir klären je Komponente die Art der Einbindung und den Vertriebsweg und leiten daraus ab, was zulässig ist und welche Pflichten entstehen.
Nicht automatisch. Lizenzkosten entfallen, Betriebskosten nicht: Patch-Fenster, Wiederherstellungstests, Monitoring, Schulung und Personalrisiko bleiben. Der Unterschied liegt weniger im Preis als in der Kontrolle – Sie können selbst patchen, selbst betreiben und bekommen die Bedingungen nicht einseitig geändert. Wir rechnen beide Varianten über drei bis fünf Jahre mit offengelegten Annahmen, damit die Zahl überprüfbar bleibt.
Das ist ein reales Risiko, und es gibt Präzedenzfälle: nach Lizenzwechseln sind OpenSearch, Valkey und OpenTofu als Forks entstanden und werden weiter gepflegt. Ob ein Fork trägt, hängt an der Breite der Beitragenden, an reproduzierbaren Bauprozessen und an offenen Datenformaten. Genau das bewerten wir vor der Einführung – und halten fest, welches Ereignis eine Neubewertung auslöst.
Eine Bewertungsmatrix mit gewichteten Kriterien, ein Architecture Decision Record je Entscheidung, eine Lizenz- und SBOM-Übersicht des betroffenen Bestands und, wo sinnvoll, ein lauffähiger Evaluationsaufbau. Alles liegt in Ihrem Repository und ist ohne uns weiter verwendbar. Die Umsetzung können Ihre Teams selbst übernehmen, oder wir begleiten sie.
Verwandte Leistungen
01 / 06
OPEN SOURCE
03 / 06
ARCHITECTURE
04 / 06
SYSTEMS
Fachartikel dazu
Eine Open-Source-Strategie regelt verbindlich, welche Fremdkomponenten hereinkommen, was veröffentlicht wird und wer entscheidet. Aufbau, Rollen, Einführung.
Lock-in ist ein Preis, kein Denkfehler. Wie Sie Daten-, API-, Betriebs- und Vertragsbindung erkennen, Exit-Kosten beziffern und Portabilität wirklich testen.
Was offene Software wirtschaftlich bringt, welche Kosten sie nur verschiebt statt streicht und wann proprietär die bessere Wahl bleibt.
Kontakt
Beschreiben Sie kurz Ihr System und die offene Frage. Wir antworten mit einer fachlichen Einschätzung – ohne Vertriebsschleife.