Die Schattenseiten des Siegeszugs

Schöne neue Open-Source-Welt?

Michael Thomas

© Shutterstock.com/2jenn

Ausgefeilten Tools, Kollaborationsplattformen und Versionsverwaltungssystemen sei Dank ist die Arbeit an quelloffenen Projekten so leicht wie nie. Gleichzeitig erfreut sich quelloffene Software bei Privatnutzern (z. B. Open Office) und Unternehmen gleichermaßen großer Beliebtheit. Schöne neue Open-Source-Welt also? Nicht unbedingt: Die Ex-Startup-Gründerin und Bloggerin Nadia Eghbal zeichnet das Bild einer Post-Open-Source-Welt, die ihre ganz eigenen Probleme in sich birgt.

Wo wir waren …

In den 1970er und 80er Jahren war Open Source noch ein Nischenphänomen: Die Beschäftigung mit quelloffener Software war quasi ein politischer Akt; man stemmte sich gegen die Vorstellung von Software als bloßer (hochpreisiger) Ware. Aufgrund der technischen Beschränkungen der Zeit (keine zuverlässigen Kommunikationskanäle, keine standardisierten Entwicklertools) gestaltete sich die Mitarbeit an entsprechenden Projekten alles andere als leicht.

In den 1990ern wurde Open Source nicht zuletzt dank des LAMP(Linux, Apache, MySQL, PHP)-Stacks deutlich populärer, der 1999 aus der Taufe gehobene Filehosting-Dienst SourceFourge mauserte sich zu einem Standard für Open-Source-Entwickler (Verwaltung, Bugtracking etc.).

Somit fehlte nur noch ein passendes Versionsverwaltungssystem (VCS), dass 2005 in Form des von Linus Torvalds geschaffenen Git die Bühne betrat. 2008 sah sich SourceForge schließlich der Konkurrenz zweier neuer Kollaborationsplattformen, namentlich GitHub und Bitbucket, ausgesetzt. Bitbucket unterstützte nur das VCS Mercurial, GitHub hingegen ausschließlich Git. GitHub und Git machten im Konkurrenzkampf schlussendlich das Rennen: Noch 2010 war SVN mit 60 % der verwalteten Softwareprojekte der unangefochtene Platzhirsch, Git hatte nur 11 % der Projekte unter sich. Heute sind die Anteile zwischen SVN und Git fast ausgeglichen, während Mercurial mit gerade einmal 2 % weit abgeschlagen ist. GitHub ist mit mehr als 12 Millionen Usern der größte Dienst seiner Art.

Mit der ebenfalls im Jahr 2008 gegründeten Frage-und-Antwort-Plattform Stack Overflow stand Open-Source-Entwicklern erstmals eine Art von Rundum-Paket zur Verfügung.

… wo wir sind …

Vor diesem „historischen“ Hintergrund bezeichnet Eghbal den seit etwa 2010 bestehenden Status quo als die „goldene Ära“ von Open Source: Es ist so leicht wie nie, sich an quelloffenen Projekten zu beteiligen; viele nutzen die gleichen Tools und zahlreiche Projekte teilen sich die selbe Plattform. Oder anders ausgedrückt: Die in der Frühzeit von Open Source zu hohen Einstiegshürden wurden fast komplett niedergerissen. Dieser Umstand spiegelt sich direkt in der Zahl der quelloffenen Projekte wider: 2011 waren rund 2 Millionen Repositorys auf GitHub zu finden, heute sind es über 31 Millionen.

Derartige Zahlen wecken natürlich auch Begehrlichkeiten: In den 1980er Jahren noch von ihnen belächelt, ist quelloffene Software mittlerweile ein bevorzugtes Ziel von Risikokapitalgebern. So schätzt Joe McCann, CEO von NodeSource, die im Jahr 2014 in Open-Source-Unternehmen à la Red Hat investierten Gelder auf satte 2,4 Milliarden US-Dollar.

Man könnte also sagen, dass Open Source im Mainstream angekommen ist, ja vielmehr, sich von der ehemaligen Alternative zum Standard entwickelt hat.

… und wohin die Reise geht

Doch es ist nicht alles eitel Sonnenschein in der schönen neuen Open-Source-Welt. Vielmehr bewegen wir uns Eghbal unerbittlich auf eine Post-Open-Source-Welt zu, die dank des exorbitanten Bedeutungszuwachses quelloffener Software ihre ganz eigenen Herausforderungen bereithält. Zu diese zählt Eghbal insbesondere:

1) Höhere Arbeitsbelastung auf weniger Schultern

Da die Zugangsbarrieren so niedrig sind, kommt es zu einer stetigen Anzahl von Personen, die einmal und danach nie wieder etwas zum Projekt beitragen, bzw. lediglich ein Ticket öffnen oder Anforderungen stellen. Bei GitHub besteht das Problem Eghbal zufolge vor allem darin, dass es sich bei der Plattform paradoxerweise um eine proprietäre Lösung handelt. Leider werden die von GitHub-Nutzern bereits seit Jahren verlangten Features nicht umgesetzt, was vor kurzem zu einer entsprechenden Petition führte.
Zahlreiche (auch prominente) Entwickler (wie Linus Torvalds) lehnen GitHub ab. Zudem ist eine zu starke Zentralisierung vor dem Hintergrund dräuender Szenarien wie beispielsweise Hackerangriffen oder Datenverlust durchaus nicht unproblematisch.

2) Zu viele Projekte, zu wenig Support

Durch die schiere Masse an quelloffenen Projekten wird es immer schwerer, nachhaltige Communities aufzubauen, die diese auch pflegen könnten. Dem exponentiellen Wachstum der Anzahl der Projekte steht ein – vergleichsweise – moderater Anstieg der aktiv tätigen Programmierer gegenüber: Robert C. Martin geht in einer Schätzung von einer Verdoppelung der Programmierer alle 5 Jahre aus (weltweit); das amerikanische Bureau of Labor Statistics prognostiziert (für die USA) 17 % mehr Stellen für Softwareentwickler bis zum Jahr 2024. Die Schere zwischen der Anzahl der Projekte und derer, die sich um Entwicklung und Support kümmern können, geht also potentiell immer weiter auseinander.

3) Der Code steht nicht über dem Gesetz

In den letzten Jahren wurde Eghbal zufolge klar ersichtlich, dass rechtlichen Fragen zunehmende Bedeutung beigemessen wird. 2013 standen nur 15 % der Projekte auf GitHub unter einer der zahlreichen Open-Source-Lizenzen, mittlerweile werden Nutzern bei der Erstellung eines Projekts Lizenzen vorgeschlagen. Es gibt sogar einen kurzen Guide, der über die verschiedenen Varianten aufklärt.

Auch Stack Overflow sah sich mit den rechtlichen Fragen der Post-Open-Source-Welt konfrontiert: Zur Zeit stehen sämtliche Inhalte der Plattform noch unter CC-BY-SA-Lizenz. Das Problem: Diese verlangt, dass der Urheber sowie die betreffende Lizenz angegeben werden. Rein technisch betrachtet müsste man also, wenn man die Code-Revision eines anderen von Stack Overflow übernimmt, den Code mit einem entsprechenden Kommentar versehen. Zudem würde der Code potentiell unter eine andere Lizenz fallen als das eigentliche Projekt. Unter anderem aus diesen Gründen verbieten manche Unternehmen ihren Mitarbeitern, auf Stack Overflow Fragen zu stellen. Stack Overflow erwägt zur Zeit allerdings, zu der freizügigeren MIT-Lizenz zu wechseln.

4) Fragmentierung

Trotz einiger gegenläufiger Bestrebungen leidet die Softwareentwicklung unter einer zunehmenden Fragmentierung, wofür zumindest im Open-Source-Bereich erneut die niedrigen Einstiegshürden mit in die Haftung genommen werden können: Es ist extrem leicht, ein neues Projekt zu beginnen, weshalb viele Entwickler lieber etwas eigenes schaffen, anstatt sich an einem bestehenden Projekt zu beteiligen. Die Folge: Statt einer handvoll Projekte mit einer großen und aktiven Community existieren heute zehntausende, zum Teil winzige, Projekte, die sich in ihrer Funktionalität fast wie ein Ei dem anderen gleichen und um die sich kaum jemand kümmert. Ein früherer Vorteil von Open-Source-Projekten, nämlich ihre auf großen und aktiven Communities fußende Resilienz, scheint sich also vermehrt ins Gegenteil zu verkehren.

Vor diesem Hintergrund fällt Eghbals Fazit zwiegespalten aus. Zwar haben LAMP-Stack, GitHub, Stack Overflow und Co. Open Source derart erfolgreich zum Durchbruch verholfen, dass manch einer den Unterschied zu „normaler“ Software überhaupt nicht mehr wahrnimmt. Andererseits gab die Open-Source-Revolution den Startschuss für neue Probleme, die einer Lösung harren. Ob es sich bei der von Eghbal beschriebenen Post-Open-Source-Welt also um eine wirklich „schöne neue Welt“ handeln wird, bleibt abzuwarten.

Aufmacherbild: holding future in sky von shutterstock.com / Urheberrecht: 2jenn

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: