67% – laut der 2016 von Blackduck Software und North Bridge veröffentlichen „Future of Open Source“-Umfrage ist dies der Prozentsatz der befragten Unternehmen, die ihre Mitarbeiter ermutigen sich an Open-Source-Projekten aktiv zu beteiligen. Ein Drittel der befragten Unternehmen beschäftigen Mitarbeiter, die ihre Arbeitszeit ausschließlich in Open-Source-Projekte investieren.

Die Gründe sich an OSS-Projekten zu beteiligen sind vielfältig. Konkrete Zahlen nennt die bereits angesprochene Umfrage: 67% beteiligen sich, um Bugs und Probleme zu beheben. 59% beteiligen sich in der Hoffnung auf einen Wettbewerbsvorteil.

Open-Source-Projekte wurden in der Vergangenheit gern als Hobbyprojekte, in denen sich Enthusiasten tummeln, dargestellt. Glaubt man Wikipedia, ist die Community diesem Stadium längst entwachsen – Finanzierungsmöglichkeiten reichen von Venture-Kapital, öffentlichen Förderungen über Consulting und Dual-Licensing weiter bis zu Open-Core-Modellen. Das soll nicht darüber hinwegtäuschen, dass auch große Projekte wie OpenBSD in der nahen Vergangenheit Finanzierungsprobleme hatten.

Was sind Gründe, warum sich Unternehmen in Form von Entwicklungszeit an OSS-Projekten beteiligen?

Recruiting und Employer Branding

Einen Anteil haben oft die Themen Recuriting, Hiring, Employer Branding: Da OSS seit langem ein großer Trend und Technologietreiber ist, bedeutet es für potenzielle Bewerber einen deutlichen Vorteil, Zeit für die Mitarbeit an Projekten zu haben und gegebenenfalls in bereits etablierten OSS-Netzwerken aktiv bleiben zu können.

Aber auch über den Recruitment-Prozess hinaus ergeben sich Vorteile, wenn Mitarbeiter in Open-Source-Projekten aktiv sind: Durch die Interaktion über die eigenen Team- und Unternehmensgrenzen hinaus ergeben sich unzählige Chancen neue Kenntnisse zu gewinnen, die dem eigenen Team und damit letztlich dem eigenen Arbeitgeber zugute kommen.

Der Weg zurück zum Upstream

Geht es darum, Patches upstream (also beim ursprünglichen Projekt) einzureichen statt sie nur intern zu pflegen oder auch nur in der eigenen Github-Organisation zu veröffentlichen, so sind drei große Vorteile zu sehen: Jeder Patch, der vom Upstream-Projekt angenommen wurde, ist ein Patch weniger, den ich bei neuen Releases des Elternprojektes weiterpflegen muss. Im Idealfall wird so mein Anwendungsfall beim ursprünglichen Projekt bei Refactorings und sonstigen Umstrukturierungen mit berücksichtigt. Auf diese Weise amortisiert sich der erhöhte Aufwand, den es kostet, eine Änderung Upstream einzupflegen sehr schnell: Für alle weiteren Aktualisierungen und Releases wird der Anpassungs- und Entwicklungsaufwand vom ursprünglichen Projekt übernommen. Letztlich durchläuft der Patch so eine zusätzliche QA-Phase: Die Entwickler des ursprünglichen Projektes können am besten abschätzen wie sich Codeänderungen hinsichtlich Seiteneffekten und Bugs auswirken.

An dieser Stelle gleich eine Warnung: Bereits bei der Auswahl der intern einzusetzenden Open-Source-Software läßt sich mit einer bewussten Auswahl der Projekte das Risiko von Folgekosten vermeiden: Will man nicht Gefahr laufen irgendwann selbst den Aufwand für die Weiterpflege des Projektes übernehmen zu müssen, lohnt es sich verschiedene Aspekte der einzusetzenden Open-Source-Software vorher abzugleichen: Ist das Entwicklerteam des Open-Source-Projektes in der Lage dieses auch über den eigenen Softwarelebenszyklus hinaus weiter zu betreuen? Sind sie hinsichtlich Finanzierung abgesichert und genügend breit aufgestellt? Ist das Projekt überhaupt noch aktiv oder werden Bug-Reports, Patches und Pull-Requests schon seit längerem ignoriert?

Selbst veröffentlichen – SaaS und OSS

Geht es darum selbst Software zu veröffentlichen, stellen sich unterschiedliche Aspekte als Motivation dar:

Bei SaaS-Unternehmen können unter freien Lizenzen angebotene Projekte, die die Integration der eigenen Services vereinfachen, ein niederschwelliges Angebot sein, den Service kennenzulernen und gegebenenfalls weitere Angebote einzukaufen. Ein Beispiel sind die von Europace veröffentlichten API-spezifischen Projekte: Einen gültigen Zugang zur Europace-Plattform vorausgesetzt, ermöglichen sie es für diverse Programmiersprachen Konnektoren zu generieren, mit deren Hilfe man auf die Plattform-APIs aufsetzend höherwertige Services entwickeln kann.

Auf diese Weise generieren externe Partner nicht nur Traffic auf Europace, sobald neue Vertragsabschlüsse zustande kommen, generieren sie auch an Europace gehende Provisionen.

Sind die Nutzer, die mit der eigenen API angesprochen werden sollen, selbst Entwickler, kann eine Open-Source-Lizenz sowohl Alleinstellungsmerkmal als auch zusätzliches Argument und Akzeptanzkriterium für den eigenen Service sein. Dies nicht nur weil Open Source cool ist, sondern auch weil die Transparenz, die verfügbarer Quellcode schafft, die Nutzung selbst bei guter Dokumentation stark vereinfacht. Für den Anbieter wiederum bietet sich der Vorteil von potentiell spezifischen Bug-Reports, die einfacher zu bearbeiten sind. Ein Grund hierfür ist: mehr Wissen über die interne Arbeitsweise von Services führt meist zu einem besseren Verständnis dessen was gegebenfalls schief läuft.

Im Idealfall kann ein offen geführtes Projekt auch von seinen Nutzern angepasst werden. Auf diese Weise bekommen Personen Mitgestaltungsmöglichkeiten sowohl in Form von Änderungen am Quellcode als auch während Design und Priorisierung von Features, die sonst nur über klassisches Requirementsengineering in das Projekt einfließen.

Über sich selbst hinauswachsen

Eine andere Motivation kann die Umsetzung komplexer Projekte sein: Kommt man mit den eigenen Teams an Grenzen – dann können OSS-Projekte eine gute Basis sein, über Unternehmensgrenzen hinweg ohne komplexe Kollaborationsverträge gemeinsam Werte zu schaffen, die größer sind als das was einzelne Teilnehmer leisten könnten. Dies hat sich in der Vergangenheit zum Beispiel schön bei vielen Apache™-Projekten gezeigt: Apache™ Hadoop® basiert in der Idee auf den in zwei wissenschaftlichen Publikationen veröffentlichten Architekten zur verteilten Datenanalyse von Google. Geboren als kleines Modul von Apache nutch™, wurden einige seiner Entwickler von Yahoo eingestellt, um die Technologie weiter zu entwickeln. Um weiterhin die Synergieeffekte der Community hinter Hadoop® nutzen zu können, verblieb der Hauptentwicklungszweig öffentlich. Das Resultat ist trotz Reibungsverluste aufgrund des vergleichsweise großen und diversen Teams eine Technologie, die sehr schnell wachsen konnte und mehr Anwendungsfälle abdeckt als einer der Technologiepartner allein hätte umsetzen können.

Märkte und Standards verändern

Die dritte Motivation, Zeit (und damit letztlich finanzielle Mittel) in Open-Source-Projekte zu investieren, liegt in der Disruption existierender Märkte: Die transparente Zusammenarbeit unterschiedlichster Player mit Wissen im Bereich Information-Retrieval hat dazu geführt, dass Apache Lucene™ (gemeinsam mit Apache Solr™, sowie etwas später Elasticsearch®) in der Lage waren, Projekte zu unterstützen, die vorher nur mit kostenintensiven, proprietären Technologien umgesetzt werden konnten. Auf diese Weise hat sich im Verlauf weniger Monate und Jahre der Marktanteil der einzelnen Suchlösungen deutlich verschoben.

In eine ähnliche Richtung geht die Argumentation, wenn der Motivator nicht nur darin besteht, den eigenen Marktanteil zu erhöhen sondern potentiell gar einen Standard (oder Industriestandard) weiter verbreiten zu verbreiten: Sind Implementierungen dieses Standards unter freien Lizenzen verfügbar, ist es wahrscheinlicher, dass diese von Entwicklern und Nutzern weiterverbreitet werden.

Elasticsearch is a trademark of Elasticsearch BV, registered in the U.S. and in other countries. Apache, Apache Lucene, Apache Hadoop, Hadoop, Apache nutch and Apache Solr are trademarks of the Apache Software Foundation in the United States and/or other countries.