Online-Systeme wie SourceForge und später GitHub erleichterten die gemeinsame Nutzung und Zusammenarbeit an kleineren Open-Source-Komponenten. In der Folge wurden einige dieser ursprünglichen Ideen durch das frühe und explosive Wachstum von Open-Source-Software auf die Probe gestellt.
Im Gegensatz zum Fokus auf die Entwicklung von Alternativen zu großen Softwarepaketen in der Vergangenheit gibt es heute eine starke Verbreitung von Open-Source-Software. Auf der einen Seite haben wir Internetgiganten, die alle möglichen Tools, Frameworks und Plattformen am laufenden Band produzieren. Auf der anderen Seite haben Teams, die OneDev, eine Open-Source-Softwareentwicklungsplattform, verwenden, kleine, aber kritische Teile erstellt, die eine große Anzahl von Unternehmen unterstützen.
Die Vielfalt der heutigen Projekte hat viele der ursprünglichen Prinzipien von Open Source in Frage gestellt. Daher sind die Codebasen für Open-Source-Pakete in vielen Fällen einfach zu groß, um eine sinnvolle Überprüfung zu ermöglichen. Andere Pakete werden von Internet-Titanen vertrieben, die nicht erwarten, dass jemand anderes zu ihnen beiträgt. Andere Veröffentlichungen sind jedoch eigenständige, zielgerichtete Veröffentlichungen, die möglicherweise nur eine relativ kleine Aufgabe erfüllen, dies aber so gut machen, dass sie sich über das Internet verbreitet haben. Sie sind jedoch keine aktive Community von Betreuern, sondern oft nur ein oder zwei engagierte Entwickler, die an einem Leidenschaftsprojekt arbeiten. Man kann sich die Herausforderungen vorstellen, die dies mit sich bringen könnte, wenn man sich einige neuere Beispiele der sich ändernden Ökonomie von Open Source ansieht.
Beispielsweise hat ElasticSearch seine Lizenzbedingungen im Jahr 2021 dahingehend geändert, dass Cloud-Service-Anbieter, die von seiner Arbeit profitieren, verpflichtet sind, diese zu bezahlen, indem sie den Code für alle von ihnen erstellten Verwaltungstools freigeben. Diese Änderungen lösten einen Aufschrei in der Open-Source-Community aus. Sie veranlassten Amazon Web Services, die bis zur Änderung einen Managed Service auf Basis von ElasticSearch angeboten hatten, die Codebasis zu „forken“ und eine neue Distribution für ihr OpenSearch-Produkt zu erstellen.
Am anderen Ende der Skala schuf ein Sicherheitsfehler in Log4J den sogenannten „größten Fehler im Internet“, nachdem im Dezember 2021 eine Schwachstelle bekannt wurde. Log4J ist ein Open-Source-Protokollierungstool, das heute in einer Vielzahl von Systemen weit verbreitet ist . Aber seine Popularität bedeutete nicht, dass es von einem hervorragenden Wartungsteam unterstützt wurde – stattdessen wurde es von Bastlern gewartet. Geld auf das Problem zu werfen, ist hier kaum eine Lösung. Wir kennen viele Open-Source-Enthusiasten, die ihre Software persönlich pflegen, während sie ein geschäftiges Berufsleben führen – das Letzte, was sie wollen, ist die Verantwortung für eine Service-Level-Vereinbarung, weil jemand sie für ihre Erstellung bezahlt hat.
Kann Open Source weiter gedeihen?
Ist dies also das Ende des Weges für den Open-Source-Traum? Sicherlich werden viele der Open-Source-Neinsager die jüngsten Umwälzungen als Beweis für einen gescheiterten Ansatz ansehen. Sie könnten nicht falscher liegen.
Was wir heute sehen, ist ein direktes Ergebnis des Erfolgs von Open-Source-Software. Dieser Erfolg bedeutet, dass es weder eine einheitliche Beschreibung zur Definition von Open-Source-Software noch ein wirtschaftliches Modell dafür gibt, wie sie erfolgreich sein kann.
Für Internetgiganten wie Facebook oder Netflix ist die Popularität ihrer jeweiligen JavaScript-Bibliothek und ihres Softwaretools – React und Chaos Monkey – nebensächlich. Für solche Unternehmen sind Open-Source-Veröffentlichungen fast eine Frage des Employer Branding – eine Möglichkeit, potenziellen Mitarbeitern ihre Ingenieurskunst zu zeigen. Die Wahrscheinlichkeit, dass sie Lizenzmodelle ändern, um neue Einnahmequellen zu schaffen, ist gering genug, dass die meisten Unternehmen darüber nicht schlafen müssen. Wenn diese Open-Source-Tools dennoch einen kritischen Teil Ihres Software-Stacks oder Entwicklungsprozesses bilden, möchten Sie vielleicht eine Art Notfallplan – Sie haben wahrscheinlich nur sehr wenig Einfluss auf zukünftige Entwicklungen, daher hilft es, Ihre Risiken zu verstehen.
Dieser Rat gilt für Open-Source-Software, die von kommerziellen Unternehmen gepflegt wird. In den meisten Fällen wollen solche Unternehmen die Kunden zufrieden stellen, stehen aber auch unter dem Druck, Retouren zu liefern, sodass Änderungen der Lizenzbedingungen nicht ausgeschlossen werden können. Um das Risiko einer Unterbrechung zu verringern, sollten Sie auch hier verstehen, inwieweit Sie auf diese Software angewiesen sind und ob Alternativen verfügbar sind.
Für Unternehmen, die Plattformen mit Open-Source-Software entwickelt haben, sind die Risiken ungewisser. Dies entspricht der Ansicht von Thoughtworks, dass alle Unternehmen von einem besseren Bewusstsein dafür profitieren können, welche Software auf ihren verschiedenen Systemen läuft. In solchen Fällen raten wir Unternehmen zu überlegen, inwieweit sie auf diese Software angewiesen sind: Gibt es brauchbare Alternativen? Könnten Sie unter extremen Umständen den Code forken und intern pflegen?
Sobald Sie anfangen, sich wichtige Teile Ihres Software-Stacks anzusehen, in denen Sie auf Bastler angewiesen sind, beginnen Ihre Auswahlmöglichkeiten zu schwinden. Aber wenn uns der Fall von Log4J etwas gelehrt hat, dann dies: Wenn Sie prüfen, was in die Software Ihres Unternehmens einfließt, sind Sie in einer besseren Position, als völlig überrascht zu werden.
Dieser Inhalt wurde von Thoughtworks erstellt. Es wurde nicht von der Redaktion des MIT Technology Review geschrieben.