zurück zum Artikel

Mit GNU und der GPL-Lizenz begann vor drei Jahrzehnten die Geschichte der Open-Source-Softwareentwicklung. Inzwischen ist die Open-Source-Welt um einige Lizenz- und Organisationsvarianten reicher und damit auch unübersichtlicher geworden.

Mit GNU und der GPL-Lizenz begann vor drei Jahrzehnten die Geschichte der Open-Source-Softwareentwicklung. Durch die zunehmenden Verbreitung von Open-Source-Produkten in Firmen wuchs auch die Wichtigkeit des Themas Lizenzierung. So war für IBM 1999 die freie Apache-Lizenz der Anlass, mit der ASF-Stiftung (Apache Software Foundation) eine neue Organisationsform für die Entwicklung quelloffener Software mitzugründen. Inzwischen ist die Open-Source-Welt um weitere Lizenz- und Organisationsvarianten reicher und damit unübersichtlicher geworden.

Bei den Open-Source-Lizenzen dominieren zwar immer noch die Urgesteine GNU Public License (GPL) und Apache License (AL), doch die Lizenzvielfalt [1] blüht auch hier. Das macht die Entscheidung für die Auswahl und den Einsatz von Open-Source-Software heute schwieriger denn je. Erschwerend kommt hinzu, dass viele Open-Source-Projekte gar keine Lizenz besitzen oder sie von Zeit zu Zeit wechseln.

Die erfolgreiche Plattform GitHub hat deswegen die Betreiber der auf ihr gehosteten Projekte dazu aufgefordert [2], ihren Code unter eine der in einem Ratgeber [3] beschriebenen Lizenzen zu stellen. Entwickler und Nutzer von Open-Source-Software sollen so besser den Durchblick behalten können und eine Entscheidungshilfe für die Wahl eines Projekts an die Hand bekommen.

Investitions- und Rechtssicherheit gehen vor Innovation

Beim Thema Innovation ziehen Plattformen wie GitHub oder Google Code viele neue Open-Source-Projekte an. Doch für viele Firmen sind Langlebigkeit, Unabhängigkeit und Rechtssicherheit weit wichtigere Ziele. Deswegen bieten einige Enterprise-Linux-Produkte einen Langzeitsupport [4] an. Das selbe Ziel verfolgt eine Auswahl von Firmen mit der Eclipse-Long-Term-Support-Initiative [5](LTS) für Eclipse-Projekte; bisher leider ohne greifbare Ergebnisse.

Schon seit Längerem werden bei aktiven Apache-Projekten zwei Hauptversionen parallel gewartet und weiterentwickelt. Um den Patentschutz und die Klärung rechtlicher Angelegenheiten kümmert sich bei der ASF seit 2007 ein eigener Rechtsausschuss [6]. Bis alle rechtlichen Fragen geklärt sind, verlängert sich jedoch manchmal die Zeit, die das Projekt im Inkubator verbringen muss. Dafür lassen sich so spätere Auseinandersetzungen und aufwändige Anpassungen der Software vermeiden.

Die ASF hat bei vielen professionellen Open-Source-Firmen immer noch einen guten Ruf. Das war zum Beispiel für Talend der Grund, die hauseigenen Open-Source-Projekte einheitlich unter die Apache-Lizenz zu stellen [7].

Neue Committer braucht das Land

Ein großes Problem für die ASF ist die Produktivität der Committer. Da die Hauptlast der Entwicklung nur auf wenige Schultern verteilt ist, verschärft sich das Problem bei einer größer werdenden Zahl von Projekten immer mehr. Für neue Projekte und Funktionen lassen sich Entwickler leichter begeistern als für Wartungs- oder aufwändige Umbaumaßnahmen. Das beklagt auch der Leiter der Arbeiten an Apaches Server und Servlet Container TomEE David Belvins in seinem Blogeintrag "Is Open Source an Infinite Resource? [8]"

Bei fast 200 Top-Level- und Inkubator-Projekten [9] ist es leider so, dass von den rund 3600 Apache-Committern [10] weniger als 250 mehr als 10-mal im Monat etwas beitragen. Das bedeutet gleichzeitig, dass viele Projekte oft nur von einer einstelligen Zahl von - meist bezahlten - Haupt-Committern wirklich weiterentwickelt werden. Selbst bei den Top10-Committern schwankt die Zahl der Commits [11] zwischen 2958 und 744 in einem Jahr.

Firmenbeteiligung und Nachhaltigkeit

Wieviel Geld darf OpenSource kosten?

Zu den stark durch Firmen vorangetriebenen Apache-Projekten gehören Cassandra, CXF, Camel, Derby, Flex, Geronimo, OpenOffice, CloudStack, Lucene, Solr und Hadoop. Obwohl von einigen Mitgliedern der Community das Firmenengagement in Open-Source-Projekte nicht so gern gesehen wird, ist eine professionale Produktentwicklung ohne es kaum mehr denkbar.

Professor Dirk Riehle hat die Auswirkungen von bezahlten Entwicklern auf Commit-Verhalten und Issue-Bearbeitung in Open-Source-Projekten untersucht [12] (PDF): Dabei stellt er fest, dass sich bezahlte Committer positiv auf die Reaktionszeiten und die Stabilisierung der Entwicklung auswirken. Am Beispiel der drei OpenSource-Applikationsserver JBoss, Geronimo und JOnAS beschreibt er zudem [13] (PDF), wie das Engagement und die Strategie der beteiligten Firmen (JBoss, Red Hat, IBM, Bull) die Entwicklung beeinflusst hat und sich beides verschiedenen Epochen zuordnen lässt.

Welchen langfristigen Wert ein nach den Open-Source-Prinzipien entwickelter Applikationsserver hat, zeigt sich gerade an der Entscheidung von Oracle, den GlassFish [14]-Server nur noch als Referenzimplementierung und damit ohne Support anzubieten [15]. Die Ankündigung des Supportendes [16] von IBM für Apache Geronimo 3.0 zum September 2016 kann, wie schon bei der freien Java-Implementierung Harmony, das Ende des Projekts bedeuten. Es ist die "Tragik der Allmende", dass die meisten Nutzer für Open-Source-Produkte nichts oder nicht genug bezahlen wollen.

Nachhaltigkeit oder Langweile

Gerade die Software-Branche hält immer Ausschau nach der nächsten Hypewelle. Für Projekte sind jedoch [17] nicht die Innovativität [18], sondern die Ausgereiftheit und die Erfahrung mit der eingesetzten Software ein großer Erfolgsfaktor. Deswegen hat der amerikanische Softwareentwickler Grady Booch in seiner IEEE-Software-Kolumne "In Defense of Boring [19]" den Wert von ausgereifter und wartbarer Software
verteidigt.

Den Anspruch, Software zu produzieren, die solche Faktoren mit Innovation vereint, erfüllen viele Apache Projekte seit Jahren verlässlich. Dabei ist die Unterstützung der Standards zur breiten Nutzbarkeit wichtig. Deswegen ist es für den weiteren und langfristigen Erfolg vieler Apache-Projekte wie Tomcat, TomEE, Geronimo oder CXF wichtig, dass sie Zugriff auf das bei Oracle angeforderte Technology Compatibility Kit [20]für Java EE 7 haben. Allerdings wird es laut TomEE-Mitbegründer David Blevins selbst dann noch fast ein Jahr dauern, bis die Projekte der JavaEE-Zertifizierung entsprechen.

Fazit

Für eine nachhaltige Weiterentwicklung ist ein ausgewogenes Verhältnis zwischen gelegentlichen und hauptamtlichen Entwicklern nötig. Hier sind die Werte und die Kultur des Apache-Weges nicht hoch genug zu schätzen. Genauso wichtig ist es, die aktiven "Arbeitstiere" nicht zu früh auf's Altenteil zu schicken und neue Commiter langfristig in die Arbeiten einzubinden. Auch wenn die Open-Source-Bewegung im letzten Jahrtausend entstanden ist, war sie nie so wertvoll wie heute. Es ist zu wünschen, dass ihr Wert in Zukunft durch eine ausreichende finanzielle Unterstützung Würdigung erfährt.

Frank Pientka
ist Senior Software Architect bei der Materna GmbH in Dortmund. (jul [21])

URL dieses Artikels:
https://www.heise.de/-2075959

Links in diesem Artikel:
[1] http://www.blackducksoftware.com/resources/data/top-20-open-source-licenses
[2] https://github.com/blog/1530-choosing-an-open-source-license
[3] http://choosealicense.com/licenses/
[4] https://www.heise.de/news/Suse-Enterprise-Linux-wird-in-Zukunft-zehn-Jahre-gepflegt-2044492.html
[5] http://www.heise.de/developer/meldung/Long-Term-Support-fuer-Eclipse-1807291.html
[6] http://www.apache.org/legal/
[7] https://www.heise.de/news/Talend-wechselt-bei-Integrationswerkzeugen-Open-Source-Lizenz-1979653.html
[8] http://www.tomitribe.com/blog/2013/09/who-are-the-real-heroes-of-open-source/
[9] http://projects.apache.org/indexes/quick.html
[10] http://people.apache.org/committer-index.html
[11] http://www.ohloh.net/orgs/apache
[12] http://dirkriehle.com/wp-content/uploads/2013/08/paid-v8-final-web.pdf
[13] http://www.riehle.org/wp-content/uploads/2013/06/Final_SCIS-2013-0168.pdf
[14] http://www.tomitribe.com/blog/2013/11/feed-the-fish/
[15] https://www.heise.de/news/Oracle-GlassFish-Open-Source-Edition-ist-nicht-tot-2042432.html
[16] http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=897%2FENUS913-081
[17] http://www.infoworld.com/d/application-development/in-defense-of-apache-225555
[18] http://www.infoworld.com/d/open-source-software/has-apache-lost-its-way-225267
[19] http://www.computer.org/portal/web/computingnow/oncomputing/-/blogs/in-defense-of-boring%20http://www.computer.org/csdl/mags/so/2013/03/mso2013030016.html
[20] https://blogs.apache.org/foundation/entry/the_asf_s_position_on
[21] mailto:jul@heise.de

Copyright © 2014 Heise Medien