"Du bist nicht dein Code!"

3 Gründe, warum Open-Source-Projekte auf Enterprise-Ebene scheitern

Jan Weddehage

© Shutterstock / Gustavo Frazao

Das Scheitern von ambitionierten Open-Source-Projekten, in die viel Zeit und persönliches Engagement fließen, wird oft von Entwicklern als persönliche Niederlage gewertet. Allerdings hängt das Ende vielversprechender Projekte in der Regel nicht mit individuellem Unvermögen zusammen. Es zeigt vielmehr, wie die Open-Source-Welt funktioniert. Entwickler müssen daher – auch wenn es schwerfällt – lernen, sich von lieb gewonnen Codebausteinen zu verabschieden.

In der Open-Source-Entwicklung arbeiten Entwickler zusammen an einer gemeinsamen Infrastruktur. Jeder Developer, der über ein ausreichendes Know-How verfügt, kann auf diese Weise seine eigenen Ideen zur Lösung häufiger Probleme einbringen, sie mit anderen teilen, und seine Belohnung in Form von Peer-Reviews einholen.

Die gemeinsame Infrastruktur lebt demzufolge vom individuellen Einfallsreichtum ihrer Unterstützer. Allerdings gehören einem die eigenen Ideen nicht mehr alleine, wenn sie einmal der Open-Source-Community zugänglich gemacht wurden. Deshalb sollte das Scheitern eines anfangs erfolgreichen Projekts nicht als persönliche Niederlage eingestuft werden.

Prototype – vom Best Practice zum Anti-Pattern

In einem Essaybeitrag schildert der Softwareentwickler Sam Stephenson seinen Leidensweg beim Aufstieg und Fall des vom ihm entworfenen JavaScript-Frameworks „Prototype“. In 2005 erblickte die Library zur Entwicklung moderner Web-Applikationen das Licht der Welt und wurde schnell vom quelloffenen Web-Application-Framework „Ruby on Rails“ als favorisiertes JavaScript-Framework auserkoren. Nur wenig später trieb Prototype die Webseiten namenhafter Unternehmen wie Apple und der New York Times an.

Trotz des Erfolgs wurde zunehmend ersichtlich, dass die Idee hinter Prototype nicht mehr zeitgemäß war. Browser-Anbieter reagierten mit der Implementierung von APIs, die oftmals in Konflikt mit dem Framework von Stephenson lagen, auf die JavaScript-Renaissance. Es zeichnete sich ab, dass die Entwicklergemeinschaft in Zukunft eher auf kleine, eigenständige und modulare Libraries als auf monolithische Frameworks setzen würde.

Stephenson erlebte den Produktlebenszyklus von Prototype als Entwicklung vom Best Practice zum Anti-Pattern. Manche Stimmen behaupteten sogar, dass das Framework mit das Schlimmste war, was dem Web zustoßen konnte. Da die kritischen Blogbeiträge sich wie offene Angriffe auf die eigenen Wertvorstellungen anfühlten, war es Stephenson zufolge schwer, den Misserfolg von Prototype nicht als persönliches Scheitern einzustufen.

Geholfen hat ihm letztlich eine realistische und rationale Einschätzung der gesamten Situation. Trotz seiner fehlerhaften Grundlage war Prototype einer Vielzahl von Developern dennoch in wichtigen Angelegenheiten hilfreich. Allerdings war es an der Zeit, die Entwicklung eine Stufe weiterzutreiben – denn auch von dieser Dynamik lebt die Open-Source-Entwicklung.

In der Open-Source-Welt geht es also nicht bloß darum, seine eigene Ideen einzubringen. Als Entwickler muss man ebenfalls in der Lage sein, sich von Codebausteinen zu distanzieren, wenn sie sich als unhaltbar erweisen oder andere Projekte die gleichen Aufgaben besser lösen. Um die Open-Source-Entwicklung voranzutreiben, ist es notwendig, über fehlerhaften Code offen zu sprechen. Ein solches Vorgehen sollte nicht als Angriff auf das eigene Ego gewertet werden; diese Einsicht spiegelt sich gleichermaßen in Stephensons Fazit wider: „Du bist nicht dein Code!“.

Warum Open-Source-Projekte auf Enterprise-Ebene scheitern können

In der Open-Source-Welt ist die Kritik an und das Scheitern von Projekten also nicht gleichzusetzen mit persönlichem Misserfolg. Alternative Lösungsansätze, die das gleiche Problem behandeln, sind deswegen nicht als feindliche Übernahmen zu bewerten. Sie sind schlicht das Ergebnis eines regenerativen Prozesses, der durch den endlosen Wunsch nach einer Verbesserung des Status Quo angetrieben wird.

In vielerlei Hinsicht können insbesondere Unternehmen von dieser Dynamik profitieren, die aus diesem Grund häufig firmeninterne Codebausteine der Open-Source-Community zur Verfügung stellen. Wenn ein solches Projekt scheitert, ist wiederum zu beobachten, dass dies nicht auf persönliches Unvermögen zurückgeführt wird; vielmehr ist das Scheitern das Resultat einer rationalen Kosten-Nutzen-Analyse. Igor Perisic führt in seinem Artikel “LinkedIn: How to Be a ‘Good Citizen’ When Open Source Projects End” gleich drei Gründe an, weshalb Konzerne ihre Investition in Open-Source-Projekte einstellen.

1. Ein Projekt bringt keinen Mehrwert mehr

Open-Source-Projekte werden oft eingestellt, weil sie nicht genügend Mehrwert abwerfen. Das kann bedeuten, dass die eingesetzte Software nicht mehr die gewünschten Ergebnisse liefert, oder der erhoffte Schub durch die Beteiligung der Open-Source-Community ausbleibt. Es kann aber auch heißen, dass mittlerweile andere quelloffene oder kommerzielle Alternativen bereitstehen, die die zu erfüllenden Aufgaben besser erledigen. Darüber hinaus kann der Fall eintreten, dass aufgrund veränderter Unternehmensziele die benötigen Entwickler und Ressourcen anderweitig eingesetzt werden müssen.

2. Der Funktionsumfang wird zu groß

Erfolgreiche Open-Source-Projekte können Unternehmen im Laufe der Zeit wortwörtlich über den Kopf wachsen. Viele Konzerne stellen ihre Investitionen ein, da Plattformen oder Applikationen ihren anfänglichen Funktionsumfang überschreiten und daher nicht mehr in das firmeninterne Ökosystem integriert werden können. Die Formulierung eindeutiger Projektziele sowie eine direkte Kommunikation mit Community-Mitgliedern kann helfen, solchen Entwicklungen vorzubeugen. Zwar können solche „Mutationen“ für die betroffenen Konzerne nachteilig sein; sie wirken sich aber äußerst förderlich auf die allgemeine Entwicklung eines Projekts aus.

3. Neue Bug-Fixes und Patches werden durch die Community nicht angenommen

Trotz Investitionen und Entwicklungsanstrengungen ist häufig zu beobachten, dass wichtige Bugfixes und Patches nicht schnell genug von der Open-Source-Community angenommen werden. Das ist für Unternehmen insbesondere dann nachteilig, wenn die betroffene Software in Core-Bereichen verwendet wird und aktiv in der Produktionsumgebung zum Einsatz kommt. Es kostet eine Menge Zeit und Ressourcen, die daraus entstehenden Unstimmigkeiten und Diskrepanzen aufzufangen. Ein erprobtes Mittel in solchen Situationen ist die Aufteilung eines Projekts. Sollte aber auch das nicht helfen, und der Ressourcenaufwand weiterhin unverhältnismäßig anwachsen, ist es sehr wahrscheinlich, dass das gesamte Vorhaben aufgegeben wird.

Aufmacherbild: Hand with marker writing: Open Source via Shutterstock / Urheberrecht: Gustavo Frazao

Geschrieben von
Jan Weddehage
Jan Weddehage
Jan Weddehage studiert an der Goethe Universität Frankfurt am Main und arbeitet seit März 2015 als Werkstudent bei Software & Support. Kontakt: jan[at]janweddehage.de
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: