Ein Kommentar von Christoph Ott
CEO von LEAN-CODERS
Wer mich kennt, weiß: Ich bin der größte Open-Source-Fan im Haus. Trotzdem versuche ich hier acht Runden lang, dich davon abzubringen. Nicht, weil ich meine Meinung geändert habe, sondern weil ich jeden einzelnen Einwand kenne, den Unternehmen gegen Open Source vorbringen, und weiß, wie wenig davon einer genaueren Prüfung standhält. Los geht's.
Wenn's kracht, ist niemand verantwortlich – wen sollen wir denn verklagen?
Du hast vermutlich das Kleingedruckte im Lizenzvertrag nicht gelesen, wenn du glaubst, dass du mit einer Klage gegen deinen Softwarehersteller Erfolg haben kannst. Die Realität sieht nämlich ganz anders aus. Fast jeder EULA erklärt dir auf den ersten Seiten, dass der Hersteller für so gut wie nichts haftet. Leider ist dies vielen oft nicht bewusst und sie kaufen auf den ersten Blick einen Service und Sorgenfreiheit.
Bei Open Source kaufst du dir dieses Märchen gar nicht erst ein. Dafür bekommst du Transparenz. Du kannst dir den Support einkaufen, den du brauchst, zuverlässige Partner wählen oder selbst eingreifen. Verantwortung beim Hersteller entsteht nämlich nicht durch einen Lizenzvertrag, sondern durch Kompetenz und Verantwortungsbewusstsein.
Open-Source-Sicherheit gibt es nicht – jeder kann schließlich in den Code schauen.
Absolut. Jeder kann hineinschauen. Auch die Guten.
Das Gegenmodell heißt übrigens „Security through Obscurity“: Hoffen, dass niemand merkt, was im Keller passiert. Das funktioniert ungefähr so gut wie einen Hausschlüssel unter der Fußmatte zu verstecken und zu glauben, niemand kommt auf die Idee, dort nachzusehen.
Offener Code bedeutet nicht automatisch sichere Software. Aber er ermöglicht unabhängige Prüfungen, Audits und schnelle Korrekturen. Sicherheit entsteht durch Transparenz, nicht durch Geheimhaltung. Wäre Geheimhaltung der Garant für Sicherheit, dürfte es auch keine Sicherheitslücken bei etablierten Anwendungen geben – und wir wissen alle, dass dies nicht der Fall ist.
Ein log4j und das halbe Internet brennt – das Dependency-Risiko ist untragbar.
Genau deshalb kennt heute jeder den Namen log4j.
Die Sicherheitslücke wurde öffentlich gemacht, innerhalb von Stunden analysiert und dann – wie bei kritischen Lücken üblich – in mehreren Schritten nachgeschärft, bis sie wirklich dicht war. Nicht perfekt, aber nachvollziehbar für jeden, der hinschauen wollte.
Jetzt die Gegenfrage: Wie viele kritische Closed-Source-Komponenten laufen heute in deinem Unternehmen, von denen du nicht einmal weißt, dass sie existieren – geschweige denn, ob und wann sie je gepatcht wurden?
Das eigentliche Risiko war nie Open Source. Das Risiko war fehlendes Dependency-Management. Das betrifft jede Software – nur siehst du es bei proprietärer Software meistens erst dann, wenn der Hersteller irgendwann (vielleicht) ein Update veröffentlicht.
Das ist doch Bastel-Software von Hobby-Entwicklern.
Ja. Linux ist ein Hobbyprojekt. Kubernetes vermutlich auch. PostgreSQL, Chromium, OpenSSL, Python, Redis … alles nette Wochenendprojekte.
Ein Großteil der digitalen Welt läuft auf Open Source. Und zwar nicht trotz der Community, sondern wegen ihr. Hinter vielen Open-Source-Projekten stehen heute Unternehmen mit tausenden Entwicklern und Milliardeninvestitionen. Nicht schlecht für ein Hobby.
Es gibt keinen Support. Wen rufen wir um 3 Uhr nachts an?
Natürlich gibt es Support.
Red Hat lebt davon. Canonical lebt davon. SUSE lebt davon. Unzählige Dienstleister leben davon.
Der Unterschied ist: Du kannst dir aussuchen, wer dich unterstützt. Oder du machst es selbst. Bei proprietärer Software musst du hoffen, dass der Hersteller dein Ticket irgendwann priorisiert oder du bzw. dein Unternehmen groß und wichtig genug ist, damit dein Problem schnell behandelt wird. Open Source gibt dir Optionen statt Warteschleifen.
Kostenlos‘ gibt's nicht – die versteckten Kosten fressen dich auf.
Da stimme ich sogar zu.
Open Source ist nicht kostenlos. Gute Software kostet Zeit, Know-how und Betrieb.
Die spannende Frage lautet nur: Wofür bezahlst du? Für Innovation oder für Lizenzen? Für Weiterentwicklung oder für Vendor Lock-in? Für Entscheidungsfreiheit oder für den nächsten verpflichtenden Versionssprung?
Lizenzen sind ein juristisches Minenfeld.
Schon mal einen Enterprise-Vertrag mit 180 Seiten gelesen? Dann weißt du, wie kreativ Lizenzbedingungen formuliert werden können.
Open-Source-Lizenzen sind öffentlich, standardisiert und millionenfach geprüft. Natürlich muss man diese auch verstehen, aber sie überraschen dich selten mit Klauseln wie „Ab Version 12 kostet der Spaß jetzt das Dreifache.“
Wir hängen an der Gnade unbezahlter Freiwilliger – was, wenn das Projekt stirbt?
Gute Frage.
Dann kannst du den Code übernehmen. Einen Fork erstellen. Einen anderen Dienstleister beauftragen. Oder gemeinsam mit der Community weitermachen.
Jetzt dieselbe Frage für proprietäre Software: Was machst du, wenn dein Hersteller das Produkt einstellt? Genau.
Wusstest du, dass du ihr längst vertraust?
Wenn du bis hierhin gelesen hast: Danke für deine Geduld mit meiner Verteidigung des Bösen.
Eine Sache noch, bevor du entscheidest, ob Open Source etwas für dein Unternehmen ist. Schau kurz auf deinen eigenen Tech-Stack. Läuft irgendwo Linux? Docker? Kubernetes? Nginx? Ein Betriebssystem, ein Datenbank-Treiber, eine JavaScript-Library, die niemand im Haus je gelesen hat?
Herzlichen Glückwunsch. Du nutzt bereits Open Source. Wahrscheinlich seit Jahren, wahrscheinlich an kritischer Stelle, und wahrscheinlich, ohne dir auch nur eine dieser acht Fragen jemals gestellt zu haben.
Die eigentliche Frage war also nie, ob es so etwas wie echte Open-Source-Sicherheit überhaupt gibt. Sie war: Wusstest du, dass du ihr längst vertraust?
Wenn du bis eben noch dachtest, Open Source sei nichts für dein Unternehmen: Denk noch mal nach, und melde dich bei uns. Nicht, um dir etwas zu verkaufen. Sondern um gemeinsam ehrlich hinzuschauen, ob genau da, wo du es nicht erwartest, ein Risiko schlummert.
Kein Verkaufsgespräch, nur ein ehrlicher Blick von außen.
