Was kostet es, Open-Source-Governance intern aufzubauen?
Sie haben eine SBOM erstellt. Darin stehen 800 Open-Source-Projekte. Für jedes einzelne sind Sie nach DORA, NIS2 oder CRA verantwortlich - für Schwachstellen, Patches, Dokumentation und Governance. Die naheliegende Frage lautet: Können wir das selbst machen?
Die ehrliche Antwort: Wahrscheinlich nicht.
Die Dimensionen des Problems #
800 Projekte klingen zunächst nach einer überschaubaren Zahl. Doch hinter dieser Zahl verbirgt sich eine Komplexität, die sich intern kaum abbilden lässt:
- 15 und mehr Programmiersprachen. Ihre SBOM enthält nicht nur Java und Python. Sie enthält C, C++, Rust, Go, Perl, Shell, Lua, Ruby und weitere. Für jede Sprache brauchen Sie Entwickler, die den Code nicht nur lesen, sondern verstehen, bewerten und bei Bedarf patchen können.
- Heterogene Stacks und Plattformen. Linux-Kernel, PHP, nginx, curl, LibreOffice, OpenSSL, zlib - die Projekte in Ihrer Lieferkette spannen sich über Betriebssysteme, Webserver, Kryptographie-Bibliotheken, Bildverarbeitung und dutzende weitere Domänen. Kein einzelner Entwickler beherrscht all das.
- Hunderte Maintainer und Communities. Jedes Projekt hat eigene Prozesse, eigene Kommunikationskanäle, eigene Release-Zyklen. Wer einen Patch upstream bringen will, muss die jeweilige Community kennen und deren Regeln befolgen.
- Keine SLAs, keine Verträge. Es gibt keinen Ansprechpartner, den Sie anrufen können. Es gibt keine zugesicherten Reaktionszeiten. Es gibt keine Eskalationsstufe.
Die Personalfrage #
In einer Kundendiskussion zur NIS2-Umsetzung wurde die Frage gestellt: Wie viele Vollzeitstellen bräuchte man, um 800 Open-Source-Projekte intern zu betreuen?
Eine erste Schätzung kam auf 5 bis 7 FTE. Bei näherer Betrachtung wurde klar: Selbst diese Zahl ist nicht realistisch. Denn die Frage ist nicht, wie viele Personen Sie brauchen, sondern ob Sie die nötige Expertise überhaupt finden und halten können.
Sie bräuchten:
- Entwickler mit Erfahrung in 15 und mehr Programmiersprachen, verschiedenen Stacks, Spezialgebieten und Plattformen
- Kenntnisse in unterschiedlichen Release-Prozessen und Hosting-Plattformen: Manche Projekte werden auf GitHub entwickelt, andere auf GitLab, Bitbucket, SourceForge oder ausschließlich über Mailing-Listen
- Spezialisten für Kryptographie, Betriebssysteme, Netzwerkprotokolle, Compiler
- Personen mit aktiven Beziehungen zu den jeweiligen Upstream-Communities
- Security-Analysten, die Silent Fixes erkennen - also Sicherheitskorrekturen, die ohne CVE-Registrierung eingespielt werden
- Dokumentationsspezialisten für auditfähige Compliance-Nachweise
Dazu kommt: Projekte können in anderen gesprochenen Sprachen kommunizieren. Die Contribution-Richtlinien unterscheiden sich von Projekt zu Projekt erheblich. Manche erwarten signierte Commits, andere verlangen ein bestimmtes Commit-Message-Format, wieder andere fordern Tests in einem spezifischen Framework. Die genaue Kenntnis der Projekt-Gepflogenheiten - wie werden Entscheidungen getroffen, wer hat welche Rolle, welche Kommunikationskanäle sind relevant - muss mühsam erarbeitet werden. Und die Akzeptanz durch die bestehenden Maintainer entsteht nicht über Nacht, sondern durch kontinuierliche, qualitativ hochwertige Beiträge über einen längeren Zeitraum.
Diese Kombination aus Breite und Tiefe lässt sich intern nicht realistisch aufbauen. Nicht weil das Budget fehlt, sondern weil die Menschen mit dieser Expertise anderswo arbeiten - oft als genau die Maintainer, die Sie bräuchten.
Die versteckten Kosten #
Selbst wenn Sie ein Team aufbauen könnten, kommen weitere Kosten hinzu, die in der Personalplanung oft fehlen:
- Einarbeitungszeit in hunderte verschiedene Projekte und deren Code-Basis
- Laufende Beobachtung von Mailing-Listen, Issue-Trackern und Commit-Historien
- Aufbau und Pflege von Test-Infrastruktur für unterschiedliche Plattformen
- Dokumentation jeder Maßnahme in auditfähiger Form
- Redundanz: Was passiert, wenn Ihr einziger C-Experte kündigt?
Was bedeutet das für Sie? #
Die Frage ist nicht, ob Sie es sich leisten können, Open-Source-Governance extern zu vergeben. Die Frage ist, ob Sie die Expertise überhaupt intern aufbauen können. In den meisten Fällen ist die Antwort nein - nicht aus Unvermögen, sondern weil die Aufgabe eine Breite erfordert, die kein einzelnes Unternehmen sinnvoll vorhalten kann.
OTTRIA bündelt genau diese Expertise: ein Netzwerk von Spezialisten, die in den relevanten Sprachen, Stacks und Communities arbeiten. Statt ein internes Team aufzubauen, das Sie nicht finden werden, erhalten Sie Zugang zu einer Organisation, die bereits im Ökosystem verankert ist.
Weiterlesen #
Sie möchten wissen, was OTTRIA konkret für Ihre SBOM leisten kann? Vereinbaren Sie ein Erstgespräch.