10.12 Open Source versus Closed Source

Überblick und Motivation

Fast jedes moderne System ist eine Mischung aus Software, die Sie schrieben, Software, die Sie kauften, und Software, die Sie kostenlos nahmen. Zwei dieser drei kommen mit einer fundamentalen Wahl: ist die Software Open Source oder Closed Source? Open-Source-Software (OSS) wird unter einer Lizenz verteilt, die jedem das Recht gibt, den Quellcode, die menschenlesbaren Anweisungen, die das Programm definieren, zu nutzen, zu studieren, zu ändern, und weiterzuverteilen. Closed-Source-Software, auch proprietäre Software genannt, wird als fertiges Produkt verteilt, dessen Quellcode die Anbieterin privat hält. Sie bekommen das Recht, sie unter einer Lizenz auszuführen, aber nicht, zu inspizieren oder zu ändern, wie sie funktioniert. Eine mittlere Kategorie, Source-Available-Software, veröffentlicht die Quelle zum Lesen, schränkt aber Nutzung, Änderung, oder Weiterverteilung ein. Sie ist sichtbar, aber nicht offen nach der Standarddefinition.

Zwei Klärungen zählen, bevor Sie sie vergleichen. Erstens, “frei” ist mehrdeutig. Die Community unterscheidet frei-wie-in-Freiheit (die Freiheit zu ändern und zu teilen, manchmal “libre” geschrieben) von frei-wie-in-Preis (null Kosten, “gratis”). Open Source handelt von Freiheit, nicht notwendig Preis. Zweitens, Open-Source-Lizenzen teilen sich in zwei Familien. Freizügige Lizenzen (wie MIT, BSD, und Apache 2.0) lassen Sie fast alles tun, einschließlich den Code in ein geschlossenes Produkt einzubetten. Copyleft-Lizenzen (wie die GNU General Public License, GPL) fordern, dass abgeleitete Werke, die Sie verteilen, auch unter denselben offenen Bedingungen veröffentlicht werden, eine Reziprozitätsregel, manchmal von Kritikerinnen “viral” und von Befürworterinnen “Share-Alike” genannt.

Dieses Kapitel betrachtet die Wahl von zwei Seiten. Als Konsumentin entscheiden Sie, ob eine Open-Source- oder proprietäre Komponente übernommen wird. Als Produzentin entscheiden Sie, ob von Ihnen gebaute Software Open Source gemacht wird. Für große Unternehmen und besonders Behörden tragen beide Entscheidungen Gewicht weit über die Lizenzdatei hinaus. Sie berühren Beschaffung (Kapitel 10.3), digitale Souveränität (Kapitel 10.11), Lieferkettensicherheit (Kapitel 4.2), Interoperabilität (Kapitel 3.8), und das Bauen-oder-Kaufen-Kalkül (Kapitel 6.1).

Kernprinzipien

Lizenz, nicht Preis, definiert “offen”. Lesen Sie die Lizenz; kostenlos und Open Source sind unterschiedliche Behauptungen.
Kein Modell ist inhärent sicherer. Beide können exzellent oder fahrlässig sein; die Praktiken um den Code zählen mehr als seine Offenheit.
Offenheit ist ein Abhängigkeitsreduktionshebel. Zugang zur Quelle ist der ultimative Schutz gegen Anbieterinnenbindung.
Sie besitzen immer die operative Last. Kostenlos-zu-erwerben ist nie kostenlos-zu-betreiben; Gesamtbetriebskosten erzählen die echte Geschichte.
Differenzierer bleiben geschlossen; Commodities können öffnen. Machen Sie Open Source aus dem, was Sie nicht unterscheidet; bewachen Sie, was es tut.
Copyleft hat Konsequenzen. Verstehen Sie Reziprozitätsverpflichtungen, bevor Sie Copyleft-Code in ein Produkt einbetten, das Sie verteilen.
Eine lebendige Community ist ein Aktivposten; ein verlassenes Repository ist eine Verbindlichkeit. Beurteilen Sie das Projekt, nicht nur die Lizenz.

Empfehlungen

Eine Komponente nach dem Projekt beurteilen, nicht nur der Lizenz

Bevor Sie irgendeine Abhängigkeit übernehmen, Open Source oder proprietär, bewerten Sie ihre Gesundheit: Veröffentlichungskadenz, Anzahl und Vielfalt der Maintainerinnen, Reaktionsfähigkeit auf Sicherheitsberichte, und Breite der Übernahme. Eine Open-Source-Bibliothek mit einer Maintainerin und eine kleine proprietäre Anbieterin tragen dasselbe Bus-Faktor-Risiko (die Gefahr, dass ein Projekt kollabiert, falls eine oder wenige Schlüsselpersonen gehen). Bevorzugen Sie Komponenten mit breiter Beitragendenbasis oder einer finanziell soliden Anbieterin, und erfassen Sie die Bewertung als Teil der Due Diligence (Kapitel 10.2, 4.2).

Lizenzen als erstklassige Verpflichtung lesen und verfolgen

Pflegen Sie ein Inventar jeder Komponente und ihrer Lizenz, und setzen Sie eine Richtlinie durch, welche Lizenzfamilien für welche Nutzungen akzeptabel sind. Die kritische Unterscheidung ist Copyleft. Freizügiger Code (MIT, Apache 2.0) kann generell frei in geschlossene Produkte eingebettet werden. Starkes Copyleft (GPL) kann Sie verpflichten, Ihr eigenes verteiltes abgeleitetes Werk unter denselben Bedingungen zu veröffentlichen. Nutzen Sie automatisierte Software Composition Analysis (SCA), Werkzeuge, die Ihre Abhängigkeiten scannen, um Komponenten, Lizenzen, und bekannte Schwachstellen zu identifizieren, und generieren Sie eine Software-Stückliste (SBOM), eine formale Liste jeder Komponente in einem Produkt (Kapitel 10.3, 4.2).

Sicherheit nach Praxis beurteilen, nicht nach Offenheit

Nehmen Sie nicht an, Open Source sei sicher wegen des “viele Augen”-Arguments (Linus’ Gesetz: “bei genug Augen sind alle Fehler flach”). Und nehmen Sie nicht an, proprietärer Code sei sicher durch Sicherheit durch Verschleierung (den fehlerhaften Glauben, dass Quelle zu verstecken Fehler versteckt). Viele Augen helfen nur, wenn qualifizierte Menschen tatsächlich schauen, und viele weit genutzte Projekte sind dünn gepflegt. Beide Modelle tragen Lieferkettenrisiko: Open Source durch kompromittierte oder verlassene Abhängigkeiten, proprietär durch undurchsichtigen Code und Update-Kanäle, die Sie nicht inspizieren können. Pinnen Sie Versionen, verifizieren Sie Herkunft, scannen Sie kontinuierlich, und überwachen Sie Advisories unabhängig vom Modell (Kapitel 4.2).

Für Ausstieg und Interoperabilität entwerfen

Bevorzugen Sie Komponenten, die offene Standards und portable Datenformate sprechen, damit Sie sie später ersetzen können (Kapitel 3.8, 10.11). Mit Open Source gewinnen Sie den ultimativen Ausstieg: wenn ein Projekt stockt, können Sie es forken (Ihre eigene Kopie erschaffen und pflegen). Mit proprietärer Software, verhandeln Sie Schutzmaßnahmen im Voraus: Datenexport in offenen Formaten, dokumentierte APIs, und Quellcode-Escrow (eine rechtliche Vereinbarung, bei der die Anbieterin Quelle bei einer Dritten hinterlegt, an Sie freigegeben, falls die Anbieterin versagt). Entwerfen Sie so, dass keine einzelne Komponente, von beiderlei Art, Ihr System als Geisel halten kann.

Gesamtbetriebskosten abwägen, nicht Preisschild

Vergleichen Sie Optionen nach Gesamtbetriebskosten (TCO), den vollen Lebenszeitkosten einschließlich Erwerb, Integration, Betrieb, Unterstützung, Training, Upgrades, und schließlicher Ersetzung, statt nur Lizenzgebühren. Open Source tauscht oft Lizenzkosten gegen höhere operative und Personalkosten. Proprietäre Software tauscht oft vorhersagbare Abonnementgebühren gegen Bindung und weniger Kontrolle. Schließen Sie die Kosten des Modells selbst ein: selbstunterstützender Open Source braucht interne Fähigkeit, während proprietäre Software Anbieterinnenmanagement-Kapazität braucht.

Als Produzentin Open Source machen, was Sie nicht differenziert

Klassifizieren Sie Ihre eigene Software danach, was Ihnen Wettbewerbs- oder Missionsvorteil gibt und was undifferenzierte Sanitärtechnik ist. Halten Sie die Differenzierer proprietär. Erwägen Sie, die Commodity-Infrastruktur Open Source zu machen, wo eine Community Pflege und Verbesserung teilen kann. Für Behörden, wägen Sie “öffentliches Geld, öffentlicher Code” (das Prinzip, dass steuerfinanzierte Software standardmäßig öffentlich verfügbar sein sollte) als Treiber von Transparenz, Wiederverwendung, und Souveränität ab (Kapitel 10.5, 10.11). Wählen Sie die Lizenz absichtlich: freizügig, um Übernahme zu maximieren, Copyleft, um das Ökosystem offen zu halten.

Abwägungen: Vor- und Nachteile

Dimension	Open Source	Closed/Proprietär
Erwerbskosten	Üblicherweise null zu erwerben	Lizenz- oder Abonnementgebühr
Gesamtbetriebskosten	Kosten verschieben sich zu Betrieb und Personal	Vorhersagbarer, aber Bindungsaufpreis
Kontrolle & Anpassung	Voll: Sie können die Quelle lesen und ändern	Begrenzt auf das, was die Anbieterin freilegt
Unterstützung & Rechenschaft	Community, oder bezahlte Dritte; keine einzelne Kehle zu würgen	Vertragliche Unterstützung und eine klare rechenschaftspflichtige Partei
Sicherheitshaltung	Prüfbar; “viele Augen” wenn echt gepflegt	Anbieterinnenverwaltet; undurchsichtig; Verschleierung ist kein Schutz
Langlebigkeit/Verlassenheit	Kann geforkt werden, wenn gepflegt; kann trotzdem verkümmern	Hängt von Anbieterinnenlebensfähigkeit und Roadmap ab
Anbieterinnenbindung	Niedrig: Quelle und offene Formate ermöglichen Ausstieg	Hoch, sofern nicht durch Standards und Escrow gemindert
Ökosystem	Offene Community und Interoperabilität	Kuratiert, integriert, manchmal ummauert

Die wiederkehrende Spannung ist Kontrolle versus Bequemlichkeit und Rechenschaft. Open Source maximiert Kontrolle, Prüfbarkeit, und Freiheit von Bindung, fordert aber, dass Sie die Fähigkeit, Integration, und Unterstützung selbst liefern. Proprietäre Software liefert ein unterstütztes, integriertes, rechenschaftspflichtiges Produkt mit einem durchsetzbaren Vertrag, gibt aber Kontrolle ab und lädt Bindung ein. Die Lösung ist selten Alles-oder-Nichts. Die meisten reifen Bestände mischen Open-Source-Fundamente mit proprietären Systemen, wo Unterstützung, Rechenschaft, oder spezialisierte Fähigkeit den Tausch rechtfertigen.

Fragen zur Diskussion mit Ihrem Team

Setzen wir eine Lizenzrichtlinie mit automatisierter SCA und SBOMs in der Pipeline durch, besonders um starkes Copyleft zu fangen, bevor es ausliefert? Eine GPL-Bibliothek in ein verteiltes proprietäres Produkt einzubetten kann Sie verpflichten, Ihre eigene Quelle zu veröffentlichen, und diese Überraschung taucht üblicherweise spät auf, wenn sie teuer ist rückgängig zu machen. Pflegen Sie ein Inventar jeder Komponente und ihrer Lizenz, setzen Sie durch, welche Lizenzfamilien für welche Nutzungen akzeptabel sind, und führen Sie Software Composition Analysis automatisch aus, damit die Pipeline Verstöße blockiert statt eine Anwältin sie zur Ausliefungszeit fängt. Generieren Sie routinemäßig eine SBOM. Für einen großen oder Behördenbestand ist das auch Lieferkettenhygiene und oft eine Beschaffungsanforderung. Bringen Sie Ihr aktuelles Lizenzinventar, oder die Tatsache, dass Sie keines haben, und entscheiden Sie, wer die Richtlinie besitzt.
Bewerten wir Projektgesundheit und Bus-Faktor als Due Diligence, wenn wir eine Abhängigkeit übernehmen? Eine Open-Source-Bibliothek mit einer Maintainerin und eine kleine proprietäre Anbieterin tragen dasselbe Risiko: das Projekt kollabiert, falls eine oder wenige Schlüsselpersonen gehen. Bevor Sie irgendetwas übernehmen, bewerten Sie Veröffentlichungskadenz, die Anzahl und Vielfalt der Maintainerinnen, Reaktionsfähigkeit auf Sicherheitsberichte, und Breite der Übernahme, und erfassen Sie die Bewertung. Keines der Modelle ist standardmäßig sicherer; “viele Augen” hilft nur, wenn qualifizierte Menschen tatsächlich schauen, und viele weit genutzte Projekte sind dünn gepflegt. Bringen Sie die drei oder vier Abhängigkeiten, von denen Ihr Produkt am meisten abhängt, und fragen Sie für jede, wie viele Menschen weggehen müssten, bevor es Ihr Problem würde. Wenn Sie nicht antworten können, ist das die Bewertung, die Sie sich schulden.
Sichern wir bei proprietären Käufen Ausstiegsschutzmaßnahmen im Voraus? Proprietäre Software bietet Rechenschaft und Bequemlichkeit im Austausch für Kontrolle, und die versteckten Kosten sind Bindung: Wechselkosten, die eine Anbieterin Preise erhöhen oder Dienst degradieren lassen mit wenig Abhilfe. Verhandeln Sie die Schutzmaßnahmen vor der Unterschrift, wenn Sie noch Hebelwirkung haben: Datenexport in offenen Formaten, dokumentierte APIs, und Quellcode-Escrow, das die Quelle freigibt, falls die Anbieterin versagt. Mit Open Source ist Ihr Ausstieg die Fähigkeit zu forken; mit proprietärer Software müssen Sie den Ausstieg in den Vertrag schreiben. Bringen Sie Ihre kritischsten proprietären Systeme und fragen Sie, was tatsächlich passiert, wenn die Anbieterin den Preis verdoppelt oder untergeht. Wenn die Antwort “wir stecken fest” ist, beheben Sie den Vertrag bei Verlängerung.
Wie entscheiden wir bei der Software, die wir selbst bauen, was Open Source wird und was geschlossen bleibt, und wer hält die Autorität für diesen Ruf? Machen Sie das in eine Richtung falsch, und Sie geben genau den Code weg, der Sie differenziert; machen Sie es in die andere falsch, und Sie horten Commodity-Sanitärtechnik, deren Pflege eine Community gerne teilen würde. Die konkurrierenden Drücke sind echt: Ingenieurinnen wollen den Rekrutierungs- und Reputationsvorteil eines öffentlichen Repositorys, während Produkt und Recht sich sorgen, Rivalinnen einen Vorteil zu geben oder eine sicherheitssensitive Heuristik zu exponieren. Bringen Sie eine ehrliche Klassifikation Ihrer Systeme in missionsdifferenzierend versus undifferenzierte Infrastruktur, und benennen Sie die Person oder das Gremium, das eine Veröffentlichung abzeichnet, denn eine Ad-hoc-Entscheidung von wer auch immer das Repository pushte ist, wie Kronjuwelen lecken. Für ein großes Unternehmen ist die Frage Portfoliostrategie, und für Behörden kollidiert sie mit “öffentliches Geld, öffentlicher Code”, dem Prinzip, dass steuerfinanzierte Software standardmäßig öffentlich sein sollte, entscheiden Sie also im Voraus, welche Ausnahmen (nationale Sicherheit, Betrugserkennung, persönliche Daten) rechtfertigen, Code geschlossen zu halten.
Erfassen unsere Bauen-oder-Kaufen-Vergleiche die vollen Gesamtbetriebskosten, oder behandeln wir eine Null-Lizenzgebühr noch als Nullkosten? Der häufigste finanzielle Fehler mit Open Source ist, “kostenlos zu erwerben” als “kostenlos zu betreiben” zu lesen, dann zu entdecken, dass Integration, Betrieb, Sicherheitsreaktion, und bezahlte Unterstützung jede vermiedene Lizenz überschatten. Die Spannung ist, dass ein proprietäres Abonnement auf der Rechnung teuer aussieht, während es einen Bindungsaufpreis versteckt, und eine offene Komponente auf der Rechnung kostenlos aussieht, während sie Kosten auf Ihr eigenes Personal verschiebt. Bringen Sie ein Apfel-zu-Apfel-TCO-Modell für zwei oder drei echte Entscheidungen: Erwerb, Integration, Betrieb, Unterstützung, Training, Upgrades, Sicherheitsreaktion, und schließliche Ersetzung, über die volle Lebensdauer bepreist statt das erste Jahr. In einem Unternehmens- oder Behördenbestand, fügen Sie die Kosten des Betriebsmodells selbst hinzu, denn selbstunterstützender Open Source fordert interne Fähigkeit, die Sie rekrutieren und behalten müssen, und behandeln Sie einen Vergleich, der diese Zeilen auslässt, als Beleg, nicht Analyse.
Beurteilen wir die Sicherheit einer Komponente nach ihren Praktiken, oder stützen wir uns auf das Offenheitslabel, ob “viele Augen” oder die Geheimhaltung geschlossenen Codes? Beide Standards sind Fallen: “viele Augen” schützt Sie nur, wenn qualifizierte Menschen den Code tatsächlich überprüfen, und viele weit genutzte offene Projekte laufen auf einer erschöpften Maintainerin, während geschlossene Quelle, die sich darauf verlässt, dass Angreiferinnen sie nicht sehen, Sicherheit durch Verschleierung ist, keine Kontrolle. Die Debatte zählt, weil sie ändert, wo Sie knappen Sicherheitsaufwand ausgeben, und die ehrliche Antwort ist, dass beide Modelle Lieferkettenrisiko tragen, Open Source durch kompromittierte oder verlassene Abhängigkeiten und proprietär durch undurchsichtige Update-Kanäle, die Sie nicht inspizieren können. Bringen Sie Beleg für Ihre kritischsten Komponenten: wer sie tatsächlich überprüft, wie schnell Advisories gepatcht werden, ob Versionen gepinnt und Herkunft verifiziert wird, und ob Sie eine SBOM generieren. Für einen großen oder Behördenbestand, binden Sie das an Beschaffungs- und kontinuierliche-Scanning-Verpflichtungen, denn eine Regulatorin wird fragen, was Sie inspizierten, nicht ob die Quelle öffentlich war.

Branchenperspektive

Startup. Mit wenig Landebahn bauen Sie auf Open-Source-Fundamenten, weil Sie sich Lizenzgebühren nicht leisten können und die Freiheit wollen zu forken, falls ein Projekt stockt. Führen Sie einen Kompositionsanalyse-Scan durch, bevor Sie ausliefern, damit eine Starkes-Copyleft-Bibliothek Sie nicht still verpflichtet, Ihre eigene Quelle zu veröffentlichen, und halten Sie Ihren einen echten Differenzierer strikt geschlossen. Machen Sie ein kleines, nicht-kritisches Werkzeug Open Source, falls es Rekrutierung hilft, aber besetzen Sie keine Pflegelast, die Sie nicht tragen können.

Kleinunternehmen. Ohne internes Recht oder Plattformspezialistin, behandeln Sie die Lizenz als Risiko, das Sie nicht falsch lesen dürfen, statt ein Thema, das Sie meistern können. Bevorzugen Sie unterstützte proprietäre Werkzeuge oder kommerzielle Open-Source-Distributionen, wo eine Anbieterin Patches und Rechenschaft besitzt, denn einen Stack selbst zu unterstützen, den Sie nicht betreiben können, ist eine falsche Wirtschaftlichkeit. Wenn Sie eine kostenlose Komponente übernehmen, prüfen Sie, dass ihre Lizenz Ihre Nutzung erlaubt und dass das Projekt tatsächlich gepflegt, nicht verlassen ist.

Großunternehmen. Im Maßstab ist das Problem Konsistenz über viele Teams: eine geschriebene Lizenzrichtlinie, automatisierte Software Composition Analysis und SBOM-Generierung in jeder Pipeline, und TCO-basierte Bauen-oder-Kaufen-Entscheidungen statt Pro-Team-Gewohnheit. Verwalten Sie offene und proprietäre Software als ein Portfolio, standardisieren Sie Ausstiegsschutzmaßnahmen wie offene Formate und Quellcode-Escrow in Beschaffung, und verfolgen Sie die Gesundheit kritischer Abhängigkeiten, damit ein einzelnes verlassenes Projekt nicht zum Vorfall wird. Steuern Sie auch die Produzentinnenseite, mit einer klaren Regel, was die Organisation Open Source macht versus geschlossen hält.

Behörde. Beschaffungsregeln, Transparenzpflichten, und öffentliche Rechenschaftspflicht formen jede Wahl. Wägen Sie “öffentliches Geld, öffentlicher Code”, das Prinzip, dass steuerfinanzierte Software standardmäßig öffentlich sein sollte, um Wiederverwendung über Behörden und digitale Souveränität voranzubringen, während Sie enge Ausnahmen für sicherheitssensitiven oder persönliche-Daten-Code herausschneiden. Fordern Sie von jeder proprietären Lieferantin Datenexport in offenen Formaten und Quellcode-Escrow, damit ein Anbieterinnenversagen keinen öffentlichen Dienst stranden kann, und veröffentlichen Sie den nicht-sensitiven Quellcode, damit Bürgerinnen die Regeln prüfen können, die sie regieren.

Beispiele

Startup. Ein Startup mit drei Gründerinnen baut sein gesamtes Produkt auf Open-Source-Fundamenten (Linux, eine Open-Source-Datenbank, ein Web-Framework), weil es sich Lizenzgebühren nicht leisten kann und die Freiheit will zu forken, falls ein Projekt stockt. Vor Ausliefung führt eine Gründerin einen Kompositionsanalyse-Scan durch und fängt eine Starkes-Copyleft-Bibliothek, die sie gezwungen hätte, ihren proprietären Matching-Algorithmus zu veröffentlichen, sie tauschen sie also gegen ein freizügig lizenziertes Äquivalent. Sie halten diesen Algorithmus, ihren einzigen Differenzierer, strikt geschlossen, und machen nur ein kleines internes Protokollierungswerkzeug Open Source, um Wohlwollen aufzubauen und Ingenieurinnen anzuziehen.

Großunternehmen. Ein großer Versicherer betreibt seine Kernplattform auf Open-Source-Fundamenten: Linux, eine weit genutzte Open-Source-Datenbank, und ein Container-Orchestrator. Aber er kauft eine proprietäre versicherungsmathematische Modellierungs-Suite, denn die Fachexpertise, regulatorischen Zertifizierungen, und der Unterstützungsvertrag der Anbieterin sind die Gebühr wert, und es gibt keine vergleichbare offene Alternative. Er zahlt ein Abonnement für kommerziellen Open Source (anbieterinnenunterstützte Distributionen der offenen Komponenten), um Rechenschaft und Patches auf der Sanitärtechnik zu bekommen, während er den Preisalgorithmus, der ihn differenziert, strikt proprietär und intern hält. TCO-Analyse (Kapitel 10.10) treibt jede Wahl statt Ideologie.

Behörde. Eine nationale Steuerbehörde baut unter einer “öffentliches Geld, öffentlicher Code”-Richtlinie einen neuen Leistungsberechtigungsdienst auf Open-Source-Komponenten und offenen Standards (Kapitel 3.8), damit andere Behörden ihn wiederverwenden können und Bürgerinnen die Regeln prüfen können. Sie veröffentlicht den nicht-sensitiven Code in einem öffentlichen Repository, nur Betrugserkennungsheuristiken aus Sicherheitsgründen geschlossen haltend. Das reduziert Anbieterinnenbindung und bringt digitale Souveränität voran (Kapitel 10.11). Beschaffungsregeln (Kapitel 10.3) fordern von jeder proprietären Komponente, Datenexport in offenen Formaten und Quellcode-Escrow bereitzustellen, um Kontinuität zu garantieren, falls die Lieferantin versagt.

Geschäftsnutzen: Motivation, ROI und Gesamtbetriebskosten

Der finanzielle Reiz von Open Source, das Fehlen einer Lizenzgebühr, ist der am wenigsten verlässliche Teil des Falls, denn Erwerb ist ein kleiner Bruchteil des TCO. Die dauerhaften Renditen sind strategisch: Freiheit von Bindung (die Fähigkeit, eine Lieferantin zu wechseln oder fallen zu lassen, ohne neu zu architektieren), Prüfbarkeit für Sicherheit und Compliance, schnellere Übernahme, weil Ingenieurinnen probieren können, bevor sie sich verpflichten, und geteilte Pflege von Commodity-Code über eine ganze Branche. Die ausgleichenden Kosten sind echt. Sie müssen Integration, Betrieb, Sicherheitsreaktion, und oft bezahlte Unterstützung liefern, und ein schlecht gewähltes ungepflegtes Projekt kann mehr in Vorfällen kosten, als irgendeine Lizenz gekostet hätte.

Der Geschäftsfall proprietärer Software ist Rechenschaft und Bequemlichkeit: eine einzelne Anbieterin, verantwortlich für das Produkt, ein durchsetzbarer Unterstützungsvertrag, integrierte Features, und vorhersagbare Budgetierung. Ihre versteckten Kosten sind Bindung, die Wechselkosten, die eine Anbieterin Preise erhöhen oder Dienst degradieren lassen mit wenig Abhilfe, plus Abhängigkeit von der Solvenz und Roadmap der Anbieterin. Gängige Geschäftsmodelle verwischen die Linie: Open Core (eine offene Basis mit proprietären bezahlten Add-ons), duale Lizenzierung (derselbe Code sowohl unter einer Copyleft- als auch einer bezahlten kommerziellen Lizenz angeboten), Software as a Service (SaaS) (die Software läuft als gehosteter Dienst, den Sie mieten, wo die Quelle irrelevant sein kann, weil Sie nie das Binärprogramm besitzen), und Unterstützungs-/Abonnementmodelle, die Dienst um ansonsten kostenlosen Code herum verkaufen.

Für eine Produzentin kann der ROI, die eigene nicht-differenzierende Software Open Source zu machen, substanziell sein. Externe Beitragende reduzieren Ihre Pflegelast. Das Projekt wird zu einem Rekrutierungs- und Reputationsaktivposten. Externe Übernahme macht Ihren Standard zum De-facto-Standard. Für Behörden liefert es Transparenz und Wiederverwendung über den öffentlichen Sektor. Die strategische Regel ist einfach: machen Sie die Commodity Open Source, um ihre Kosten zu teilen und ein Ökosystem zu wachsen, und halten Sie den Differenzierer geschlossen, um den Vorteil zu schützen, der alles andere finanziert.

Anti-Muster und Fallstricke

“Kostenlos bedeutet kostenlos”: Null-Erwerbskosten als Null-TCO behandeln, dann Betrieb und Unterstützung unterfinanzieren.
Lizenzblindheit: Starkes-Copyleft-Code in ein verteiltes proprietäres Produkt einbetten und Verpflichtungen auslösen, die Sie nie planten.
Glaube an “viele Augen”: annehmen, ein offenes Projekt sei geprüft, wenn es eine überarbeitete Maintainerin und keine Sicherheitsüberprüfung hat.
Sicherheit durch Verschleierung: glauben, geschlossene Quelle sei sicher, einfach weil Angreiferinnen sie nicht lesen können.
Ideologischer Absolutismus: “alles offen” oder “alles proprietär” vorschreiben statt pro Komponente nach Verdienst und TCO zu wählen.
Herkunft ignorieren: Abhängigkeiten ohne SBOM, Versionspinning, oder Lieferkettenverifikation ziehen (Kapitel 4.2).
Die Kronjuwelen Open Source machen: genau den Code veröffentlichen, der Sie differenziert, Ihren Vorteil weggebend.
Fork-und-vergessen: ein verlassenes Projekt forken ohne die Kapazität, den Fork tatsächlich zu pflegen.

Reifegradmodell

Stufe 1 (Beginnen). Open-Source- und proprietäre Komponenten treten Ad-hoc in den Bestand ein. Lizenzen sind ungelesen, es gibt kein Inventar oder SBOM, und die Wahl zwischen Modellen wird nach Gewohnheit oder allein Preis getroffen. Verlassenheit und Lizenzrisiko tauchen erst auf, wenn etwas bricht, und jedes Team reagiert allein.

Stufe 2 (Entwickeln). Manche Teams beginnen grundlegende Praktiken: ein Komponenten- und Lizenzinventar, eine grobe Ansicht akzeptabler Lizenzen, und gelegentliche Software Composition Analysis. Bauen-oder-Kaufen- und Offen-oder-Geschlossen-Entscheidungen werden aufgeschrieben, aber die Disziplin ist fleckig und inkonsistent von einem Team zum nächsten, eine Copyleft- oder Bus-Faktor-Überraschung kann also noch durchrutschen, wo die Gewohnheit nicht Fuß fasste.

Stufe 3 (Standardisieren). Ein dokumentiertes Framework steuert sowohl Konsum als auch Produktion organisationsweit. Komponenten werden nach TCO und Projektgesundheit gewählt, Lizenzen werden automatisch in der Pipeline durchgesetzt, damit Verstöße einen Build blockieren, SBOMs werden routinemäßig generiert, und eine explizite Richtlinie erklärt, was die Organisation Open Source macht versus geschlossen hält. Ausstiegsschutzmaßnahmen wie offene Formate und Quellcode-Escrow sind Standard in Beschaffung, und jedes Team folgt denselben Regeln statt seinen eigenen.

Stufe 4 (Steuern). Das Programm wird gegen Baselines gemessen und gesteuert. Die Organisation verfolgt Kennzahlen wie SBOM-Abdeckung über Produkte, den Anteil der Abhängigkeiten, die gegen Richtlinie verstoßen, mittlere Zeit, eine offengelegte Abhängigkeitsschwachstelle zu patchen, Bus-Faktor- und Gesundheitswerte für kritische Projekte, und realisierten TCO gegen die Schätzung, die jede Wahl rechtfertigte. Schwellen lösen Aktion aus: eine Komponente, deren Pflege stockt oder deren Patch-Latenz über das Ziel driftet, wird auf Beleg zum Ersatz markiert, und Offen-oder-Geschlossen- und Bauen-oder-Kaufen-Entscheidungen werden gegen die Zahlen überprüft statt durch Gewohnheit verteidigt.

Stufe 5 (Orchestrieren). Open-Source-Strategie ist eine absichtliche Geschäftsfähigkeit, über die Organisation integriert und kontinuierlich verbessert. Die Organisation trägt zu den Projekten bei, von denen sie abhängt, und verwaltet sie manchmal, macht ihre nicht-differenzierende Software routinemäßig Open Source, und speist Abhängigkeitsgesundheit- und TCO-Daten zurück in Beschaffung, Sicherheit, und Produktplanung. Sie balanciert ihr Portfolio aus offener und proprietärer Software routinemäßig neu, sich an Verschiebungen in Kosten, Risiko, Souveränität, und strategischem Vorteil anpassend, bevor sie eine Krise erzwingen.

Diskussionsideen

Wo in Ihrem Bestand wäre der Verlust einer einzelnen Anbieterin oder Maintainerin existenziell, und was ist Ihr Ausstiegsplan?
Welche Ihrer eigenen Systeme sind Commodities, die Sie Open Source machen könnten, und welche sind echte Differenzierer zu schützen?
Behandelt Ihre Organisation “viele Augen” als echte Sicherheitskontrolle oder eine ungeprüfte Annahme?
Für Leserinnen im öffentlichen Sektor: was würde ein “öffentliches Geld, öffentlicher Code”-Standard in Ihrer nächsten Beschaffung ändern?
Wie gut erfassen Ihre TCO-Vergleiche die operativen und Unterstützungskosten, die Open Source auf Sie verschiebt?

Wichtigste Erkenntnisse

Offen vs. geschlossen wird durch die Lizenz definiert, nicht durch Preis; kennen Sie den Unterschied zwischen frei-wie-in-Freiheit und frei-wie-in-Preis, und zwischen freizügig und Copyleft.
Kein Modell ist inhärent sicherer oder günstiger. Beurteilen Sie die Praktiken des Projekts und seinen vollen TCO, nicht das Offenheitslabel.
Offenheit ist das stärkste Gegenmittel zu Bindung, Prüfbarkeit, Portabilität, und die Fähigkeit zu forken liefernd; proprietäre Software bietet Rechenschaft und Bequemlichkeit im Austausch für Kontrolle.
Entscheiden Sie pro Komponente nach Verdienst, und mischen Sie Modelle absichtlich statt nach Ideologie.
Als Produzentin, machen Sie die Commodity Open Source und halten Sie den Differenzierer geschlossen, und in Behörden, wägen Sie “öffentliches Geld, öffentlicher Code” für Transparenz, Wiederverwendung, und Souveränität ab.

Referenzen und weiterführende Literatur

Eric S. Raymond, The Cathedral and the Bazaar
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Adrian Cockcroft und andere, diverse O’Reilly-Titel über Open-Source-Strategie und -Betrieb
Free Software Foundation, The Free Software Definition (und die GNU-General-Public-License-Texte)
Open Source Initiative, The Open Source Definition und genehmigte Lizenzliste
Free Software Foundation Europe, Public Money, Public Code-Kampagnenmaterialien
Yochai Benkler, The Wealth of Networks