Foto: genesis_3g by Pixabay, C00
Auf den ersten Blick scheint eine Untersuchung, die sich auf 17 Befragungen stützt, nicht gerade aussagekräftig zu sein. Die Intensität der Interviews gleicht das aber aus. Denn zunächst waren Fragebögen zur schriftlichen Beantwortung verschickt worden, der tiefgründigere Telefoninterviews folgten. Die ganze Aktion hatte das schwedische Projekt LIM-IT gestartet, an dem Unternehmen und eine Universität beteiligt sind. Gezielt befragt wurde Teilnehmer aus den acht Open Source-Projekten Apache, CloudStack und Solr, Bouncy Castle, Contiki-NG, Leshan, MariaDB, OpenStack sowie Papyrus. Das IEEE hat den ausführlichen Bericht als Open Access-Artikel veröffentlicht.
Neun der Befragten kamen aus Softwareunternehmen, acht aus Firmen mit anderen Geschäftszielen. Wie zu erwarten fällt das Engagement der Beteiligten in Open Source-Projekten höchst unterschiedlich aus. Dies korrespondiert in der Regel mit der Arbeitszeit, in der Angestellte für die Projekte arbeiten. Von Seiten der Entwickler sind berufliche Qualifikation und Aufstiegschancen wichtige Motive, die auch in außerberuflicher Mehrarbeit ihren Niederschlag finden können.
Das mit Abstand wichtigste Motiv der Arbeitgeber besteht darin, eine Software so weiter zu entwickeln, dass sie sich möglichst bald für strategische Unternehmensinteressen, für Produkte oder Services nutzen lässt. Dabei konnte der Anlass darin bestehen, dass es keine vergleichbare Lösung gab oder eine Open Source-Software (OSS) um wichtige Eigenschaften zu erweitern war. Grundsätzlich stößt ein Projekt, deren bisherige Arbeiten einen bestimmten Reifegrad bereits erreicht haben, auf höheres Interesse als „junge“. Wichtig kann dabei auch das Umfeld oder ein Oberprojekt in einem Bereich sein.
Ein Beispiel dafür ist OpenStack. Dieses Projekt starteten vor allem große IT-Unternehmen, um Amazons Public Cloud-Ambitionen etwas entgegenzusetzen und eigene Marktchancen zu verbessern. Diese schufen innerhalb kürzester Zeit vier elementare Basismodule für Private Clouds. Ab diesem Moment der Grundsteinlegung wurde OpenStack für andere Firmen und für ursprünglich nicht bedachte Einsatzziele und IT-Umgebungen interessant. Es entstanden neue OpenStack-Projekte. Das zunächst überraschendste davon war „Ironic“, was als Cloud auf dedizierter Hardware ein Widerspruch zu sein scheint, dessen Ressourcenzuordnung ein wichtiger Aspekt unter anderem zur Sicherung gewünschten Datendurchsatzes und für die Security ist. Ironic ist seit gut zwei Jahren das am schnellsten wachsende OpenStack-Teilprojekt.
Die Tiefe der Beteiligung ist ganz unterschiedlich und kann sich im Lauf der Zeit ändern. Das reicht zunächst von der Projektinitiierung über dessen Leitung bis zur Dokumentation bis hin zu Bugfixes. Projektleitung ist der ehrenvollste Job, aus Firmensicht aber auch einer, der am meisten Arbeitszeit kostet. Allerdings ist zu bedenken, dass selbst die Behebung von Fehlern kein Ende absehen lässt, denn Neuerungen in anderen Teilen eines Projekts können Korrekturen in den eigenen Beiträgen erforderlich machen.
Damit wird zugleich deutlich, dass sich Widersprüche zwischen den beteiligten Unternehmen und dem OSS-Projekt entwickeln können. Deren Ursache liegt weniger in der fatalen Annahme, man könne in jedem Fall eigene Interessen im Projekt durchsetzen. Vielmehr entstehen Probleme aus Defiziten in der langfristigen Kommunikation zwischen dem Projekt und engagierten Firmen. Die lassen sich nur beheben, wenn die Unternehmen ein Interesse an der Langlebigkeit eines Produkts haben. Das scheint selbstverständlich zu sein, ist es aber nicht, weil Firmeninteressen sich ständig verlagern. Außerdem gibt es personelle Fluktuation, so dass ständig neues Wissen aufgebaut werden muss – was am besten über Bugfixing geht. Als Alternative kommt die Zusammenarbeit mit anderen Firmen, auch Freiberuflern oder programmierende Consultants, in Betracht.
Zusammenfassend ist zu erkennen, dass Unternehmen zwar vor allem wegen kurzfristiger ökonomischer Interessen in ein OSS-Projekt einsteigen, aber nur erfolgreich sind, wenn sie bald eine längerfristige Perspektive ihres Engagements entwickeln. Die Idee, man könne Open Source-Projekte mal schnell eben und mit bescheidenem Einsatz auf die eigenen Ziele umbiegen, ist zum Scheitern verurteilt. Open Source braucht langen Atem – und mehr als Luft.
*Ludger Schmitz ist freiberuflicher Journalist in Kelheim.
