Der Open-Source-Prozess (OSP) unterscheidet sich vom traditionellen, kommerziell angewandten Entwicklungsprozess. Nachfolgend werden die Besonderheiten des Open-Source-Prozesses aufgezeigt.
Abgrenzung
Es können vier verschiedene Modelle der Softwareentwicklung unterschieden werden [Perens 2007]: Die Entwicklung für den anschließenden Vertrieb, die Eigen- und Auftragsentwicklung, die kollaborative Entwicklung ohne Open-Source (OS)-Lizensierung sowie die OS-Entwicklung. Sie unterscheiden sich bezüglich der Kostenverteilung, der Risikoverteilung, der Effizienz und der Möglichkeit, andere Anwender von der Nutzung auszuschließen.
Charakteristika der Open-Source-Softwareentwicklung
Generell anerkannt sind nachfolgende Charakteristika [Mockus et al. 2002; Fitzgerald 2006]:
- Anzahl der Entwickler: Im Vergleich zu traditioneller Softwareentwicklung ist eine weitaus größere Anzahl von Entwicklern beteiligt. Zudem existiert keine klare Grenze zwischen Entwicklern und Anwendern, da die Hürden für eine Partizipation im Entwicklungsprozess sehr gering sind. Auch wenn ein großer Teil der Entwicklungsarbeit von Freiwilligen übernommen wird, gibt es dennoch den Trend zum Einsatz bezahlter Entwickler.
- Zuteilung der Arbeit: Im OSP wird die Entwicklungsarbeit nicht länger von einer definierten Instanz zugeteilt, sondern die Teilnehmer wählen ihre Arbeitspakete selbst aus.
- Architektur: In der Regel orientieren sich die Teilnehmer eines OSP nicht an einer vorgegebenen System-Architektur. Die Gestaltung der Architektur geschieht dezentral und ist oftmals häufigen Richtungswechseln unterworfen.
- Koordination: Es gibt wenig oder keine institutionalisierten traditionellen Koordinationsmechanismen, wie z.B. Projekt- und Zeitpläne, Lasten– und Pflichtenhefte u.ä.
Bedingungen, die die Koordination und Motivation von Open-Source-Entwicklung unterstützen
Über die Motivation zur Entwicklung von Open-Source-Software wird in der Literatur heftig diskutiert. Offensichtlich sind primäre Motivationsfaktoren, wie sie z.B. bei bezahlten Entwicklern vorhanden sind. Auch Teilnehmer, die mit ihrem Beitrag einen persönlichen Nutzen durch die entwickelte Software erhalten, zählen zu dieser Kategorie [Lerner, Jean 2002; Sauer 2007]. In einem Open-Source-Projekt ist es wichtig, die Variablen zu berücksichtigen, die den Erfolg des Vorhabens beeinflussen. Diese können in einen koordinierenden und einen motivierenden Bereich unterteilt werden [Picot 2008].
Zum koordinierenden Bereich gehören (vgl. [Picot 2008] S. 241 ff.):
- Eindeutige Schnittstellen zwischen den Programmteilen: Open-Source-Projekte sind, häufig durch ihre starke räumliche Trennung gekennzeichnet. Dabei wirken Programmierer von unterschiedlichen Orten der Welt aus zusammen und bilden so den Programmcode. Damit das Ziel der erfolgreichen Entwicklung des Projektes erreicht werden kann, sollten klare Schnittstellen geschaffen werden, die ein kooperatives Arbeiten erleichtern.
- Klare Regeln für die Übermittlung von Programmcode: Es gibt verschiedene Beispiele, die zeigen, dass es klare Regeln für die Übermittlung von Programmcode geben sollte. Unter anderem gab es in der Zeit von 1991 bis 1995 mehr als 15.000 Entwickler, die Codeteile zum Linux Kernel beigetragen haben [Picot 2008]. Eine solche „Flut“ an bereitgestelltem Quellcode muss auf festgelegte Art und Weise entgegengenommen werden können. Es sollte definiert werden, welche Programmiersprache einzusetzen ist und in welcher Form (z.B. als Datei) der gesendete Beitrag vorzuliegen hat.
- Innovation und Weiterentwicklung durch inkrementelle Schritte: Der inkrementelle Charakter einer Software sollte bei einem Open-Source-Projekt ebenfalls deutlich werden. In Meilensteinen kann festgelegt werden, welche zusätzlichen Funktionen und Fehlerbereinigungen bereitgestellt werden. In der Regel sind die lauffähigen Teilergebnisse bereits zur Nutzung frei gegeben, so haben die Benutzer jederzeit die Möglichkeit Feedback und neue Vorschläge zu geben, welche in späteren Releases berücksichtigt werden können.
- Weltweite Vernetzung und Kommunikation zu günstigen Preisen: Im Zeitalter des Web 2.0 sind Online Communities wie z.B. Wikis oder Foren ein guter Weg zur Koordination von großen Menschenmengen geeignet. Viele Projekte bedienen sich dieser Mittel, um Projekte leichter und effizienter koordinieren zu können. Auf eigens angelegten Wikis können die Mitglieder in ihrer Gemeinschaft günstig interagieren bzw. kooperieren. In der Regel sind diese Plattformen öffentlich zugänglich, benötigen für die Mitwirkung am Projekt jedoch oft eine Anmeldung zur Prävention von Vandalismus.
- Hohe Transparenz: An den vorherigen Punkt anschließend, ist die hohe Transparenz solcher Entwicklungsvorhaben zu nennen. Sowohl für Mitglieder als auch interessierte unbeteiligte Personen sollte der Einblick ermöglicht und der Überblick gewährleistet sein, um somit jederzeit einen eigenen Beitrag zur Fortführung des Projektes zu leisten. In Wikis werden beispielsweise alle Teile des Quellcodes offengelegt und häufig können sogar Änderungen, oder Kommentare bzw. Diskussionen verfolgt werden. Selbstdarstellung und egoistisches Verhalten wird jedoch nicht gerne gesehen.
- „Natürlich“ anerkannter Projektleiter und „Antiforking“-Norm: Es existiert ein ungeschriebenes Gesetz, welches besagt, dass der Gründer des Vorhabens automatisch als natürlicher Führer bzw. Projektleiter fungiert. Dies könnte unter anderem auf die Anerkennung seiner Idee und das Engagement zurückzuführen sein. Trotzdem existieren unterschiedliche Gründe, warum auch andere Mitglieder eine leitende Position erhalten können (wie z.B. zur besseren Koordination von Teilvorhaben). Eine weitere Norm ist es, dass sich keine Mitglieder abspalten, um auf dem bestehenden Projekt ein abtrünniges Vorhaben aufzubauen. Grund dafür ist der starke soziale Druck aller Teilnehmer, die das sogenannte „Forking“ (gabeln) verachten.
- Niedrige Eintrittsbarrieren und großer Entwicklerpool: In den meisten Projekten herrschen niedrige Eintrittsbarrieren für Interessenten, die sich beteiligen wollen. So können diese Personen auf einfache Art und Weise Mitglied werden, z.B. reicht eine Anmeldung im Wiki aus. Da alle benötigten Materialien frei zugänglich sind, ist eine Projektbeteiligung verhältnismäßig einfach. Es gibt jedoch auch Bereiche, die nicht allen Programmierern leicht zugänglich gemacht sind, um z.B. nur die fähigen Entwickler teilnehmen zu lassen. Insgesamt sind die meisten Projekte allerdings einem großen Entwicklerpool offen.
- Ausreichende Ressourcen: Ressourcen für ein privates Open-Source-Projekt sind in der Regel niedrig. Da der größte Teil der Vorhaben nicht kommerziell genutzt wird und es daher auch keine Entlohnung für die aufgewendete Zeit gibt, ergeben sich im Prinzip lediglich Opportunitätskosten. Nicht außen vor zu lassen sind aber auch die Kosten für Webserver und die nötige Hardware.
Zu den motivierenden Variablen gehören (vgl. [Picot 2008] S. 244 ff.):
- Reputationsmöglichkeit bei geschätzter Gruppe in Abhängigkeit von OSS-Beitragshöhe: Die meisten Projekte im OSS-Bereich sind so angelegt, dass jeder Entwickler ein Mitspracherecht hat und es auch wahrnehmen sollte. Je mehr funktionierenden und sinnvollen Programmcode er beiträgt, desto größer wird sein persönliches Ansehen in der Gemeinschaft. Dadurch erweitern sich auch die Möglichkeiten an anderen Projekten teilnehmen zu können.
- Spaß an der Programmierung und die Erweiterung der Fähigkeiten: Ein wichtiger Aspekt bei der Motivationsförderung ist, Spaß an der Arbeit zu haben. Alle Mitglieder sollten sich mit den Aufgaben identifizieren können und wohlwollend daran teilnehmen.
- OSI-Lizensierung führt zu verbessertem Programm und Marktchancen, die der Entwickler benötigt: Die zwei zuvor genannten motivierenden Variablen sind für viele Entwickler ein Grundbestandteil ihrer Arbeit, jedoch existieren auch weitere Faktoren, die starken Einfluss auf die Motivation haben. Durch die Offenlegung des Quellcodes versprechen sich die meisten Entwickler und auch Investoren größere Marktchancen, da der betroffene Markt wachsen kann und sich neue Möglichkeiten für komplementäre Produkte, wie z.B. Services, eröffnen. Um sicher zu gehen, dass der eigene Beitrag am Projekt nicht verschleiert wird, existieren sogenannte Maintainerlisten, in denen die mitwirkenden Personen namentlich genannt werden.
Zudem werden folgende sekundäre Motivationen unterschieden [Weber 2004; Lerner Jean 2002]
- Selbstverwirklichung: Programmieren als kreativer Vorgang, der Stil und Eleganz demonstriert und zum Ausdruck der eigenen Persönlichkeit dient.
- Aufgabe als Berufung: Wahrnehmung einer Verantwortung gegenüber der Gesellschaft ohne Orientierung an eigenen Problemen.
- Gemeinsamer Gegner: Motivation durch „Kampf“ gegen die Welt kommerzieller Software.
- Ego-Gratifikation: Förderung des eigenen Egos durch Anerkennung in der Gemeinschaft der Entwicklergemeinde.
- Karriere-Anreiz: Nutzung der Signalwirkung der Beteiligung an OS-Projekten zur Förderung der eigenen Karriere.
Eine Studie des Oak Ridge National Laboratory geht davon aus, dass eine wesentliche Motivation vieler Entwickler die Befriedigung von persönlichen Bedürfnissen sei [Stile und Cui 2010]. Die Forscher untersuchten das Verhalten von Angehörigen der Open Source Communities mit Hilfe des SourceForge Concurrent Versions System (CVS) und ermittelten, dass sich die Mehrheit der Entwickler einem einzelnen Projekt zuordnen lassen kann und sich deren Beitrag auf einen eher geringen Prozentsatz auswirkt. Dies sei ein Indiz dafür, dass persönliche Interessen im Vordergrund stehen.
Anreizmechanismen
Für die Organisation und Koordination im OSP haben sich verschiedene Mechanismen und Prinzipien etabliert. In vielen OS-Projekten existiert ein Kernteam an Entwicklern, welches den OSP steuert und über die Integration von Änderungen entscheidet [Weber 2004; Höst, Oruevic-Alagi 2010]. Für die Entscheidungsfindung reicht die Bandbreite vom hierarchischen System mit einem “Anführer” (Linux) bis hin zu basisdemokratischen Organisationsformen, bei denen über Änderungen abgestimmt wird (Apache).
Perens sieht den Vorteil von Softwareentwicklung im Rahmen eines OSP in einer höheren Effizienz der Ressourcen-Zuweisung und einer besseren Kosten- und Risikoverteilung [Perens 2007]. Aufgrund des kollaborativen Prozesses mit einer großen Zahl von Beteiligten, die in der Regel geographisch voneinander entfernt arbeiten, werden zahlreiche technische Hilfsmittel benötigt. Zu diesen Hilfsmitteln zählen z.B. Versionierungs-Software wie SVN oder CVS, InstantMessaging, VoIP und Plattformen wie SourceForge.net [DiBona 2005].
Typologie von Open-Source-Programmierern
Open Source Projekte können von unterschiedlichen Entwicklertypen vorangetrieben werden. Osterloh et al. unterscheiden hierbei fünf idealtypische Akteure [Osterloh et al. 2004]:
- Kommerzielle Unternehmen: Kommerzielle Unternehmen können auf Basis von Open Source Software unterschiedliche Business-Modelle verfolgen. Prominente Beispiele, wie z.B. Red Hat oder Alfresco, zeigen, dass Umsätze sowohl durch Support-Dienstleistungen als auch durch Schulungen und Seminare erzielt werden können. Neben diesen produktbegleitenden Dienstleistungen können allerdings auch auf den Benutzer abgestimmte Produktpakete zusammengestellt werden. So sind vorkonfigurierte Open Source Produkte möglich, die speziell für unerfahrene Einzelkunden oder Unternehmen abgestimmt sind.
- Entwickler für den Eigenbedarf: Es existieren Akteure, die eine Open Source Software auf ihre eigenen Bedürfnisse anpassen und diese Änderungen auch veröffentlichen, wenn ein für sie günstiges Kosten-Nutzen-Verhältnis besteht und sich die Weitergabe z.B. im Internet lohnt.
- Investoren in Reputation: Einige Akteure verfolgen das Ziel, ihre Reputation durch die Mitwirkung an Open Source Projekten zu erhöhen. So können sie durch die erfolgreiche Teilnahme an bestimmten Projekten z.B. ihren eigenen Marktwert steigern, um sich für neue oder besser bezahlte Jobs zu profilieren.
- Homo ludens: Die Teilnahme an Open Source Projekten ist nicht immer extrinsisch motiviert, wie es bei kommerziellen Unternehmen und Investoren in Reputation der Fall ist. Auch die intrinsische Motivation kann Auslöser für die Zuwendung zu gemeinschaftlicher Softwareentwicklung sein. Einige Akteure lassen sich dadurch typisieren, dass ein wesentlicher Beweggrund Spaß an der Programmierung ist und der Nutzen weniger ins Gewicht fällt.
- Reziproakteure: Der Reziproakteur charakterisiert sich dadurch, dass ihm das Wohl der Gemeinschaft am wichtigsten ist und er seine Hilfe bzw. seine Entwicklerfähigkeit anbietet, ohne eine konkrete Gegenleistung zu fordern.
Literatur
DiBona, Chris: Open Source and Proprietary Software Development. In: DiBona, Chris; Cooper, Danese; Stone, Mark (Hrsg.): Open Sources 2.0: the continuing evolution. Beijing et al.: O’Reilly, 2005.
Fitzgerald, Brian: The Transformation of Open Source Software. In: MIS Quarterly Vol. 30 No. 3/September 2006.
Höst, Martin; Oruevic-Alagi, Alma: A Systematic Review of Research on Open Source Software in Commercial Software Product Development. In: Proceedings of 14th International Conference on Evaluation and Assessment in Software Engineering, Keele, UK, 12 – 13 April 2010.
Lerner, Josh; Triole, Jean: Some Simple Economics of Open Source. In: The Journal of Industrial Economics, 2 (2002), Volume L, S. 197-234.
Mockus, A.; Fielding, R. T.; Herbsleb, J. D. 2002. Two case studies of open source software development: Apache and Mozilla. ACM Trans. Softw. Eng. Methodol. 11 (2002), No. 3, S. 309-346.
Osterloh, M.; Rota, S.; Kuster, B.: Open-Source-Softwareproduktion: Ein neues Innovationsmodell? In: Gehring, R.A.; Lutterbeck, B. (Hrsg.): Open Source Jahrbuch 2004: Zwischen Software und Gesellschaftsmodell. Lehmanns, 2004, S. 121-137.
Perens, Bruce: Open Source – ein aufstrebendes ökonomisches Modell. In: Lutterbeck, B.; Bärwolff, M.; Gehring, R.A. (Hrsg.), Open Source Jahrbuch 2007 – Zwischen freier Software und Gesellschaftsmodell. Lehmanns Media: Berlin, 2007.
Sauer, Robert M.: Why develop open-source software? The role of non-pecuniary benefits, monetary rewards, and open-source licence type, In: Oxford Review of Economic Policy, Vol. 23, Nr. 4, 2007, S. 605-619.
Stiles, E.; Cui, X.: Working of Collective Intelligence within Open Source Communities. In: Chai, S.; Salerno, J.; Mabry, P.: Advances in Social Computing. Springer Berlin/ Heidelberg, 2010, S. 282-289.
Weber, Steven: The success of open source. Cambridge, Mass. et al.: Harvard Univ. Press, 2004.