Open Source im Unternehmen: Vorteile, Kosten und Grenzen

Die Frage „Setzen wir auf Open Source?“ wird in Unternehmen fast immer als Kostenfrage gestellt und deshalb fast immer falsch beantwortet. Der Grund ist buchhalterisch: Die Lizenzzeile eines Angebots ist sichtbar, die Betriebszeile nicht. Wer beide Seiten vergleicht, stellt fest, dass offene Software selten billiger ist. Sie ist anders finanziert. Sie verschiebt Ausgaben von wiederkehrenden Nutzungsrechten hin zu Kompetenz, Integration und Betriebsverantwortung im eigenen Haus.

Die kurze Antwort lautet deshalb: Der belastbare Vorteil offener Software liegt nicht im Preis, sondern in vier Eigenschaften, die man nachprüfen kann. Der Quelltext ist ein Auditgegenstand und keine Herstellerzusage. Die Lizenz koppelt die Kosten nicht an die Zahl der Nutzer, Kerne oder Mandanten. Der Zeitpunkt eines Upgrades bleibt eine eigene Entscheidung. Und der Dienstleister ist austauschbar, weil das Artefakt bleibt. Dafür übernimmt das Unternehmen Verantwortung, die sonst ein Vertrag getragen hätte: Patch-Entscheidungen, Integrationsarbeit, Wissensaufbau und die Wartung über Jahre. Wer diese Rollen nicht besetzt, kauft kein Sparpotenzial, sondern ein Risiko.

Dieser Artikel zieht eine nüchterne Bilanz. Er benennt die tatsächlichen wirtschaftlichen Effekte, stellt die Kostenarten beider Modelle in einer Tabelle gegenüber, definiert Total Cost of Ownership für diesen Kontext, liefert konkrete Prüfkriterien für die Gesundheit eines Projekts – und beschreibt drei Situationen, in denen offene Software die schlechtere Wahl ist.

Der eigentliche Vorteil: vier Eigenschaften, die sich prüfen lassen

Prüfbarkeit: Quelltext als Auditgegenstand statt Vertrauensvorschuss

Bei proprietärer Software ist die Aussage „diese Komponente enthält keine unerwünschte Datenabflussfunktion“ eine Zusage des Herstellers. Bei offener Software ist sie eine Eigenschaft des Artefakts, die man selbst oder durch Dritte belegen kann. Das ist kein moralischer Punkt, sondern ein prozessualer: Ein Audit kann den Quelltext lesen, ein Build lässt sich gegen die veröffentlichten Quellen prüfen, und Abhängigkeiten lassen sich vollständig auflisten statt schätzen.

# Welche Version läuft, woher kommt sie, was hängt daran?
dpkg -l nginx
apt-get source "nginx=$(dpkg-query -f '${Version}' -W nginx)"   # Quellpaket zur installierten Version
apt-cache rdepends --installed libssl3

# Herkunft eines Upstream-Artefakts vor dem Deployment belegen
sha256sum -c nginx-1.28.0.tar.gz.sha256
gpg --verify nginx-1.28.0.tar.gz.asc nginx-1.28.0.tar.gz

Genau diese Prüfbarkeit wird zunehmend regulatorisch relevant. Der europäische Cyber Resilience Act verlangt von Herstellern digitaler Produkte unter anderem eine belastbare Aussage über enthaltene Komponenten und ein Verfahren für Schwachstellenbehandlung. Eine Stückliste in Formaten wie CycloneDX ist für offene Abhängigkeitsbäume maschinell erzeugbar; für eine geschlossene Binärkomponente bleibt sie eine Frage an den Lieferanten. Wie diese Kette praktisch abgesichert wird, behandelt der Artikel zur Absicherung der Software Supply Chain.

Verhandlungsposition: Wechselkosten werden zur Kennzahl

Der interessante Punkt ist nicht, ob man den Anbieter wechseln möchte, sondern was ein Wechsel kosten würde. Diese Zahl bestimmt jede Vertragsverhandlung, unabhängig davon, ob sie jemals fällig wird. Bei offenen Formaten, offenen Protokollen und einer Datenbank, deren Dump-Format dokumentiert ist, ist der Ausstieg ein Migrationsprojekt mit schätzbarem Aufwand. Bei einem proprietären Datenmodell, das nur die Anwendung selbst lesen kann, ist er ein Neubau.

Die strukturellen Ursachen von Abhängigkeit und die Gegenmaßnahmen sind in Vendor Lock-in vermeiden ausführlich beschrieben.

Kein Nutzerlizenz-Deckel: Skalierung ohne Preisstufe

Per-Seat-, Per-Core- und Per-Mandant-Modelle koppeln die Softwarekosten an den eigenen Erfolg. Jede neue Abteilung, jede zusätzliche Umgebung und jede Testinstanz erzeugt eine Vertragsposition. Bei PostgreSQL 17 oder einem Linux-Cluster ändert sich mit der fünfzigsten oder fünftausendsten Nutzerin nichts an der Lizenz – die Kosten steigen mit Hardware, Betrieb und Datenvolumen, also mit messbaren technischen Größen. Das ist nicht „kostenlos“, sondern anders skalierend, und der Unterschied ist planbarer.

Praktisch relevant wird das vor allem bei Nebenumgebungen. Wer für jede Integrationsstufe eine Lizenz braucht, testet weniger, als er sollte.

Betriebshoheit: Zeitpunkt und Umfang von Änderungen bleiben intern

Ein Hersteller kann eine Version für abgekündigt erklären, eine Funktion entfernen oder ein Preismodell umstellen. Bei offener Software lässt sich eine Versionslinie im Zweifel selbst weiterpflegen: Sicherheitspatches zurückportieren, ein Fork für eine Übergangszeit betreiben, ein Upgrade auf ein Quartal legen, in dem es organisatorisch passt. Diese Option ist real, aber nicht gratis – sie verlangt Menschen, die den Code lesen können. Genau deshalb gehört sie in die Kostenrechnung und nicht in die Vorteilsliste.

Ökosystem: Standardwissen statt Produktwissen

Kenntnisse in Linux, PostgreSQL, Kubernetes 1.33 oder Docker 28.x sind am Arbeitsmarkt verfügbar und in der Dokumentation öffentlich nachlesbar. Wissen über ein proprietäres Produkt ist an dessen Verbreitung und an Schulungsangebote des Herstellers gebunden. Über einen Zeitraum von fünf Jahren ist das ein handfester Unterschied bei Einarbeitungszeit und Personalrisiko.

Was offene Software tatsächlich kostet

Total Cost of Ownership (TCO)

Die Summe aller Kosten einer Softwareentscheidung über ihren Lebenszyklus: Beschaffung und Lizenzen, Integration in bestehende Systeme, Betrieb und Monitoring, Sicherheitspflege und Updates, Kompetenzaufbau und Personalbindung, Ausfallfolgen sowie die Kosten eines späteren Ausstiegs. Bei offener Software entfällt der Lizenzposten oder wird zu einem Supportvertrag. Alle übrigen Posten verschwinden nicht – sie wechseln nur die Kostenstelle und werden dort selten von Anfang an sauber geführt.

Betriebsverantwortung: der Posten, der am häufigsten fehlt

Wer keinen Wartungsvertrag kauft, übernimmt die Zusage selbst. Das lässt sich in Fragen zerlegen, die eine Kalkulation beantworten muss: Wer bewertet eine neu veröffentlichte Schwachstelle in einer Abhängigkeit, und innerhalb welcher Frist? Wer rollt das Update aus, und wann wurde zuletzt ein Restore aus dem Backup tatsächlich durchgeführt? Wer wird nachts geweckt, und wer vertritt diese Person im Urlaub? Diese Fragen entscheiden mehr über die Gesamtkosten als jede Lizenzzeile.

Der Aufwand sinkt erheblich, wenn Updates nicht gesammelt, sondern kontinuierlich und automatisiert bewertet werden.

# .github/workflows/dependencies.yml — Abhängigkeiten sichtbar halten
name: dependencies
on:
  schedule:
    - cron: '0 5 * * 1'
  workflow_dispatch:
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Stückliste erzeugen
        run: syft dir:. -o cyclonedx-json=sbom.json
      - name: Bekannte Schwachstellen bewerten
        run: grype sbom:sbom.json --fail-on high
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Der Unterschied zwischen einem wöchentlichen kleinen Update und einem Sprung über zwei Hauptversionen nach 18 Monaten Stillstand ist der Unterschied zwischen Wartung und Projekt. Für Betriebsthemen dieser Art – Härtung, Patch-Fenster, Monitoring – ist Linux-Infrastruktur der passende Einstieg.

Integrationsaufwand: die Kosten liegen an den Rändern

Offene Komponenten sind selten fertige Suiten. Sie sind gute Bausteine mit klaren Schnittstellen, und der Aufwand entsteht dort, wo diese Bausteine auf die eigene Organisation treffen: Single Sign-on, Rollen- und Mandantenmodell, Berechtigungsableitung, Reporting, Archivierung, Schnittstellen zu ERP oder DMS. Das Protokoll ist dabei fast nie das Problem – OIDC ist dokumentiert und getestet. Das Problem ist die Abbildung der eigenen Aufbauorganisation auf Gruppen und Ansprüche.

{
  "iss": "https://sso.example.internal/realms/intern",
  "aud": "reporting-service",
  "sub": "a7c1f0e2-4d3b-4c8a-9f11-0b6d2e5a9c34",
  "groups": ["fin-controlling", "fin-controlling-lesend"],
  "email_verified": true,
  "exp": 1787000000
}

Ein Token wie dieses ist trivial zu erzeugen. Die Frage, wer im Unternehmen entscheidet, dass Gruppe fin-controlling-lesend genau zwei Berichte sehen darf und wie diese Zuordnung bei einer Umstrukturierung nachgeführt wird, ist Projektarbeit. Diese Arbeit fällt bei proprietären Produkten ebenfalls an, wird dort aber häufig in ein Beratungspaket eingepreist und deshalb bei einem Vergleich mitgezählt – während man sie auf der offenen Seite gern vergisst.

Kompetenzaufbau: das Wissen ist der eigentliche Vertrag

Bei offener Software ersetzt internes Wissen einen Teil des Supportvertrags. Das ist eine Investition mit langer Amortisation und einem eigenen Risiko: Wenn dieses Wissen an einer einzelnen Person hängt, ist die Abhängigkeit nicht kleiner geworden, sondern nur schlechter dokumentiert.

Kostenarten: Lizenzmodell vs. offenes Modell

Kostenart	Proprietäres Lizenzmodell	Offenes Modell
Nutzungsrecht	Wiederkehrend, vertraglich fixiert	Entfällt; Lizenz erlaubt Nutzung dauerhaft
Skalierung	An Nutzer, Kerne, Mandanten oder Umgebungen gekoppelt	An Hardware, Datenvolumen und Betrieb gekoppelt
Support	Im Vertrag enthalten, Reaktionszeiten zugesichert	Optionaler Dienstleistervertrag oder intern getragen
Patch-Entscheidung	Hersteller bestimmt Zeitpunkt und Inhalt	Eigene Entscheidung, eigene Verantwortung
Integration	Projektaufwand, oft als Beratungspaket eingepreist	Projektaufwand, intern oder extern zu planen
Auditierbarkeit	Herstellerzusagen, Zertifikate, Fragebögen	Quelltext, Stückliste, reproduzierbarer Build
Kompetenzaufbau	Produktschulungen, herstellergebunden	Standardwissen, am Markt breiter verfügbar
Compliance-Nachweis	Vom Hersteller geliefert, Umfang verhandelbar	Selbst zu erzeugen, dafür vollständig einsehbar
Ende des Lebenszyklus	Vom Hersteller gesetzt, Upgrade-Zwang möglich	Eigene Weiterpflege möglich, aber mit eigenem Aufwand
Ausstieg	Abhängig von Exportfähigkeit und Datenmodell	Migrationsprojekt mit schätzbarem Aufwand

Die Tabelle zeigt das Muster: Kein Posten verschwindet, mehrere wechseln die Seite. Offene Software tauscht vertraglich zugesicherte Leistung gegen eigene Handlungsfähigkeit. Das ist für Organisationen mit technischer Substanz ein gutes Geschäft und für Organisationen ohne eine schlechte Idee.

Wo offene Software die schlechtere Wahl ist

Nischenfachlichkeit ohne tragende Community

Für eng spezialisierte Fachdomänen – Laborinformationssysteme, Tarifrechnung, branchenspezifische Abrechnungslogik – existiert häufig kein offenes Projekt mit belastbarer Entwicklergemeinschaft. Ein Repository mit drei Commits im letzten Jahr ist kein Ökosystem, sondern eine Altlast in Wartestellung. Diese Prüfung sollte messbar erfolgen, nicht nach Gefühl.

# Bus-Faktor, Aktivität und Release-Kadenz grob abschätzen
git clone --filter=blob:none https://github.com/example/projekt.git && cd projekt
git shortlog -sne --since='24 months ago' | head -20   # Wer trägt tatsächlich?
git log --since='12 months ago' --oneline | wc -l      # Änderungsvolumen
git tag --sort=-creatordate | head -10                 # Abstand der Releases

# Automatisierte Bewertung von Projekt-Hygiene
scorecard --repo=github.com/example/projekt

Aussagekräftig sind vor allem: mehr als eine Person mit substanziellem Anteil, regelmäßige Releases über mindestens zwei Jahre, eine dokumentierte Sicherheitsmeldeadresse und Reaktionszeiten auf Issues, die nicht in Monaten gemessen werden.

Regulatorische Zertifizierungspflicht

Wo ein Nachweis an ein Produkt mit benanntem Hersteller gebunden ist – Medizinprodukte, funktionale Sicherheit nach IEC 61508 oder ISO 26262, Luftfahrtsoftware – hilft die Verfügbarkeit des Quelltexts allein nicht. Gefordert ist eine Zertifizierung samt Haftungsträger. Es gibt zertifizierte Varianten offener Systeme, etwa kommerziell gepflegte Linux-Distributionen mit Safety-Paketen. Deren Preis liegt dann in der Größenordnung proprietärer Lizenzen, und das ist sachlich richtig: Bezahlt wird nicht der Code, sondern der Nachweis.

Fehlendes internes Know-how ohne Plan, es aufzubauen

Der klarste Ausschlussgrund ist organisatorisch. Wenn niemand im Haus eine Datenbank betreiben kann, niemand ein Backup-Restore verantwortet und kein Budget für Aufbau oder externe Betriebsunterstützung vorgesehen ist, dann ist die offene Variante die teurere – nur mit zeitversetzter Rechnung. Die Kosten erscheinen dann nicht als Lizenz, sondern als Ausfall.

Wie eine Entscheidung belastbar wird

Lizenzfragen gehören dabei früh geprüft, nicht am Ende: Eine Copyleft-Lizenz wie die GPLv3 ist im internen Betrieb unproblematisch, verlangt aber bei der Weitergabe eines abgeleiteten Werks die Offenlegung des entsprechenden Quelltexts. Die eindeutigen Kennungen der SPDX License List machen diese Prüfung automatisierbar. Wie sich daraus eine dokumentierte Linie für das gesamte Unternehmen entwickeln lässt, beschreibt der Artikel zur Open-Source-Strategie. Wenn Sie diese Bewertung nicht allein führen möchten, ist Open-Source-Beratung genau dafür gedacht; unsere grundsätzliche Haltung zu offenen Technologien steht unter Open Source.

Fazit

Offene Software ist keine Sparmaßnahme und kein Bekenntnis, sondern eine Verlagerung von Verantwortung. Sie liefert Prüfbarkeit, eine bessere Verhandlungsposition, entkoppelte Skalierung und Hoheit über den eigenen Änderungstakt – und verlangt dafür Betriebskompetenz, Integrationsarbeit und eine benannte Zuständigkeit für Wartung. Wer diese Posten ehrlich kalkuliert, kommt in vielen Fällen zu einer offenen Basis mit gekauften Spezialkomponenten. Wo Zertifizierungspflichten gelten oder eine Community fehlt, ist ein Produkt mit Haftungsträger die sachlich richtige Wahl. Die schlechteste Variante ist in beide Richtungen dieselbe: eine Entscheidung, die nur die sichtbaren Kosten vergleicht.