Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1. Einleitung
1.1. Motivation und Zielsetzung
1.2. Aufbau der Arbeit
2. Das Gut Software
2.1. Ökonomische Eigenschaften von Software
2.1.1. Software als Netzwerkgut
2.1.2. Software als Informationsgut
2.1.3. Software als komplexes Gut
2.1.4. Software als digitales Gut
2.1.5. Software als Gut ohne Rivalität im Konsum
2.2. Open Source Software
2.2.1. Motive der beteiligten Entwickler
2.2.2. OSS- vs. CSS- Lizenzen
2.2.2.1. Offene OSS-Lizenzen
2.2.2.2. Virale OSS-Lizenzen
2.2.2.3. CSS-Lizenzen
2.2.2.4. Resümee zu den Lizenzmodellen
2.3. (Intellectual) Property Rights und Softwareproduktion
3. Governance von Open Source Software Projekten
3.1. OSS-Governance und Projektlebenszyklus
3.1.1. Die Einführungsphase
3.1.2. Die Wachstumsphase
3.1.3. Die Reifephase
3.1.4. Die Rückgangsphase (mit oder ohne Wiederaufleben)
3.1.5. Erkenntnisse aus der Lebenszyklusbetrachtung
3.1.6. Einführung von Governance-Instrumenten in OSS-Projekten - eine Gradwanderung
3.2. OSS-Governance und Institutionenökonomik
3.2.1. OSS-Governance und Transaktionskosten
3.2.2. Institutionelle Arrangements zur OSS-Governance
3.2.2.1. Prinzip der Offenheit
3.2.2.2. Interne Governance
3.2.2.2.1. Modularität in Programmarchitektur und Projektorganisation
3.2.2.2.2. Hierarchie nach Leistung
3.2.2.2.3. Passive Kontrollrechte
3.2.2.2.4. Standardisierte Kommunikationsmechanismen
3.2.2.2.5. Standardisierte Koordinationsmechanismen
3.2.2.2.6. Instrumente zur Sicherung intrinsischer und Förderung extrinsischer Motive
3.2.2.3. Externe Governance
3.2.3. Zusammenfassung zur Governance von OSS-Projekten
4. Institutionenökonomische Erkenntnisse
5. Fazit und Ausblick
Literaturverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 - Top-10-Verteilung der verwendeten Lizenzen für OSS registriert bei SourceForge.net (Stand: 25.01.2008)
Abbildung 2 - Trade-off zwischen Wohlfahrtsverlusten durch externe Effekte und Transaktionskosten
Abbildung 3 - Lebenszykluskonzept
Abbildung 4 - OSS und CSS im Trade-off zwischen Wohlfahrtsverlusten durch externe Effekte und Transaktionskosten
Tabelle 1 - Güterarten nach Ausschließbarkeit und Rivalität: eigene Darstellung
Tabelle 2 - Softwarelizenzen und Übertragung von (I)PR
Tabelle 3 - Organisationsund Koordinationsformen
Tabelle 4 - charakteristische Eigenschaften der Projektphasen
Die zunehmende Etablierung von Open Source Software (OSS)1 im Softwaremarkt hat dazu geführt, dass nicht nur das private und öffentliche, sondern auch das wissenschaftliche Interesse an OSS-Projekten zugenommen hat. Neben dem Betriebssystem Linux stellen zunehmend auch viele weitere OSS-Anwendungen, wie z.B. der Webbrowser Mozilla/Firefox oder der Apache Webserver ernstzunehmende Konkurrenz für ihre Mitstreiter aus dem Bereich der Closed Source Software (CSS) dar. Diese Entwicklung zeigt, dass sich mit OSS-Projekten eine alternative Organisationsform zur Erstellung komplexer Software herausgebildet hat. Der Erfolg von OSS-Projekten hängt dabei stark davon ab, inwieweit die Communities in der Lage sind, ihre Zusammenarbeit effizient zu koordinieren.
“Open Source Software can sometimes defeat proprietary software. However this is far from being always true. It relies on the efficiency of its organization. […] In what extent then are open source software communities able to organize themselves, to self-organize […]?” (Dalle/Jullien, 2002, S. 14)
Die Motive der OSS-Entwickler wurden in zahlreichen Studien bereits ausgiebig untersucht und diskutiert. Verhaltensweisen von Individuen ergeben sich jedoch aus dem Zusammenspiel von Motiven mit den durch Institutionen bestimmten Anreizstrukturen. Entsprechend erscheint eine Untersuchung der institutionellen Arrangements von OSS-Projekten sinnvoll.
Ziel dieser Arbeit ist es daher, sich anzuschauen welche institutionellen Arrangements zur Governance von OSS-Projekten eingesetzt werden. Aus institutionenökonomischer Sicht ist es vor allem interessant, die Effizienz verschiedener institutioneller Arrangements ökonomisch zu bewerten. In diesem Zusammenhang spezialisiert sich der vorliegende Beitrag auf die Frage, inwieweit die zwei verschiedenen Governance-Strukturen (CSS-Unternehmen vs. OSS-Projekt) effiziente Lösungen des Teamproduktionsproblems darstellen.
Die Arbeit wendet also Aspekte der Neuen Institutionenökonomik, speziell der (Intellectual-) Propery-Rights-Theorie und Transaktionskostentheorie, auf die Governance der Softwareproduktion an.
Wenn man ökonomische Aspekte von CSS und OSS betrachten möchte, ist es sinnvoll, sich zunächst das Gut Software etwas genauer anzuschauen. Zu diesem Zweck wird in dem folgenden Kapitel 2 auf ökonomische Eigenschaften und Lizenzmodelle von Software eingegangen. Das anschließende Kapitel 3 beschäftigt sich ausführlich mit der Governance von OSS- Projekten, bevor in Kapitel 4 die institutionenökonmischen Erkenntnisse diskutiert werden. Mit einem Fazit und kurzem Ausblick auf zukünftig interessante Forschungsfelder, bildet Kapitel 5 den Abschluss der Arbeit.
Der Begriff Software bezeichnet allgemein alle nicht physischen Funktionsbestandteile eines Computers, also neben Computerprogrammen auch die von den Programmen verarbeiteten Daten (vgl. Küchlin/Weber, 2005, S. 15f.). In Abgrenzung zu den Daten wird Software jedoch auch häufig mit dem Begriff Programm gleichgesetzt und als „Liste von Anweisungen zur Verarbeitung von Daten“ (Gröhn, 1999, S. 4) definiert. Der vorliegende Beitrag sieht die letztgenannte Abgrenzung als sinnvoll an und folgt daher dieser Begriffserklärung.
Der Produktionsvorgang von Software bedingt, dass Programme prinzipiell in zwei verschiedenen Formen vorliegen. Entwickelt wird Software indem Programmierer logisch strukturierte Befehle und Anweisungen in einer so genannten Programmiersprache schreiben. Ergebnis dieses Programmiervorganges ist Software in Form des so genannten Quellcodes. Dieser Quellcode - oft auch als Programmcode, Quelltext oder Source Code bezeichnet - stellt die für den Menschen lesbare Form von Software dar. Vorrausetzung zum Verständnis des Quelltextes ist die Kenntnis der jeweiligen Programmiersprache. Um das Programm für den Rechner ausführbar zu machen, muss der Quellcode durch einen so genannten Kompiliervorgang in eine maschinenlesbare Form umgewandelt werden. Als Ergebnis dieses Umwandlungsvorganges liegt die Software dann auch in Gestalt des Binärcodes vor. Im semantischen Sinne ist dieser Binärcode vom Menschen nicht lesbar. Rückschlüsse vom Binärcode auf das zugrunde liegende Programmierprinzip sind nicht oder nur sehr schwer möglich (vgl. Kooths et al., 2003, S. 16ff.; Hansen/Neumann, 2001, S. 155f.; von Engelhardt, 2006, S.1).
Daher wird im vorliegenden Beitrag unterstellt, dass die Funktion und die einzelnen Programmierschritte nur anhand des Quellcodes nachvollzogen werden können.
Ausgehend von den zwei Formen in denen Programme vorliegen, wird in der Regel zwischen zwei Arten der Bereitstellung von Software unterschieden, die auf verschiedenen eigentumsbzw. verwertungsrechtlichen Kriterien und/oder Produktionsweisen basieren. Man spricht in diesem Zusammenhang von proprietärer (Closed Source) und offener (Open Source) Software. In der Literatur kursieren noch weitere Bezeichnungen und Unterteilungen, wie z.B. nichtkommerzielle Open Source Software, Free-/Shareware, kommerzielle Open Source Software und kommerzielle/proprietäre Software (vgl. Berlecon Research, 2002, S. 11). Da die Unterscheidung hauptsächlich anhand der Offenlegung des Quellcodes erfolgt, wird die stark stilisierte und typisierte Trennung zwischen Closed Source Software und Open Source Software für diese Arbeit als sinnvoll erachtet. Im Folgenden wird für Closed Source Software die Abkürzung CSS, und für Open Source Software die Abkürzung OSS, verwendet.
- OSS ist grundlegend durch eine Offenlegung des Quellcodes und damit auch der zugrunde liegenden programmiertechnischen Leistung gekennzeichnet. Das OSS- Modell erlaubt es Software zu benutzen, zu kopieren, zu verändern und in veränderter oder unveränderter Form weiterzugeben (vgl. ausführlich die Open Source Definition der Open Source Initiative, 2006). Kommerzielle Verwertung von OSS erfolgt über so genannte OSS-Distributionen. Eine OSS-Distribution ist ein aufeinander abgestimmtes Paket von mehreren OSS-Programmen. Dieses spezifische Paket wird in der Regel durch Supportleistungen, Handbücher und kleinere Hilfsprogramme ergänzt. Die verschiedenen kommerziellen OSS-Distributionen haben oft gemeinsame Schnittmengen bezüglich der beinhalteten OSS. Trotz dieser Konkurrenzsituation beteiligen sich, die im Wettbewerb stehenden, OSS-Distributoren oft mit eigenen Entwicklungsbeiträgen an denselben OSS-Projekten. Vergleichbar mit Forschungskooperationen wird so eine Art „cost-sharing“ betrieben (vgl. Pasche/von Engelhardt, 2006, S. 105; von Engelhardt, 2006, S. 14).
- Bei CSS hingegen wird der vom Menschen lesbare Quellcode nicht offengelegt, d.h. die Software wird ausschließlich in der maschinenlesbaren Form des Binärcodes vertrieben. Durch diese Konstruktion wird eine gewisse Ausschließbarkeit von der Nutzung erreicht. Das Ausschlussprinzip wird in der Regel durch eine Kombination aus
technischem und juristischem Kopierschutz umgesetzt. Im CSS-Modell wird also nur die Funktion des Softwareproduktes und nicht das zugrunde liegende Wissen verkauft. Das Recht zur Nutzung der Software wird in der Regel über den Kauf einer proprietären Lizenz erworben (vgl. Pasche/von Engelhardt, 2004, S. 8; von Engelhardt, 2006, S. 2).
Das Gut Software weist eine Reihe von ökonomisch relevanten Eigenschaften auf (vgl. ausführlich von Engelhardt, 2006; Mundhenke, 2005). An dieser Stelle soll nur auf die, für die vorliegende Arbeit relevanten Eigenschaften näher eingegangen werden.
Software wird als Netzwerkgut bezeichnet (vgl. Pasche/von Engelhardt, 2006, S. 102), da es bei Verwendung desselben Programms durch verschiedene Personen zu so genannten Netzwerkeffekten bzw. Netzwerkexternalitäten kommt, die sich aus Vorteilen des Erfahrungsund Datenaustausches ergeben. Netzwerkgüter sind also dadurch charakterisiert, dass der Nutzen für jeden einzelnen Konsumenten steigt, je mehr Leute das Produkt nutzen (vgl. Katz/Shapiro, 1985, S. 424). Anders ausgedrückt kann man sagen, dass sich der Nutzen eines Netzwerkgutes aus der Summe von Basisoder Stand-Alone-Nutzen und Netzwerknutzen (vgl. Blankart/Knieps, 1992, S. 79) ergibt. Es gibt Netzwerkgüter die einen Basisnutzen von Null haben, beispielsweise ein Telefon oder eine Faxgerät2. Bei Software die lediglich zur Kommunikation dient kann der Basisnutzen ebenfalls Null sein (z.B. Instant-Messaging-Programme), in der Regel kann man bei Software jedoch von einem positiven Basisnutzen ausgehen (z.B. Office- Anwendungen).
Diese direkten Netzwerkeffekte ergeben sich unmittelbar aus der Netzwerk-Eigenschaft von Software, d.h. dadurch, dass der Nutzen für jeden einzelnen Anwender mit der Verbreitung des Gutes steigt. Sie beruhen im Wesentlichen auf Vorteilen im Zusammenhang mit dem vereinfachten Austausch von Daten (vgl. von Engelhardt, 2006, S. 3f.).
Darüber hinaus treten indirekte Netzwerkeffekte auf, die sich überwiegend aus dem Angebot an Komplementärprodukten und möglichem Wissensaustausch ergeben. Die Bedeutung von Komplementärprodukten lässt sich am Beispiel eines Betriebssystems gut verdeutlichen. So ist der potentielle Nutzen eines Betriebssystems umso größer, je mehr kompatible Anwendungssoftware zur Verfügung steht bzw. zu erwarten ist. Positive externe Effekte des Wissensaustausches äußern sich dadurch, dass mit der Nutzeranzahl einer Software auch die Wahrscheinlichkeit steigt, relativ leicht jemanden zu finden, mit dem man sich über Probleme und Lösungsansätze austauschen kann (vgl. von Engelhardt, 2006, S. 5).
In Märkten mit (indirekten) Netzwerkeffekten ist Standardisierung aufgrund der Relevanz von Kompatibilität in der Regel wohlfahrtsmaximierend. Jedoch findet der Markt nicht immer zu Standardisierung, oder anders ausgedrückt, die optimale Netzwerkgröße wird nicht in allen Fällen erreicht (vgl. Pasche/von Engelhardt, 2004, S. 4).
Zudem kann es aufgrund von nachfrageseitigen Pfadabhängigkeiten und Lock-In-Effekten dazu kommen, dass sich ein möglicherweise inferiorer Standard durchsetzt (vgl. Gröhn, 1999,
S. 39ff.). Im CSS-Modell können Dateiformate und Schnittstellen als proprietäre Standards verstanden werden, was dazu führt, dass Standardisierung gleichzeitig auch eine Monopolisierung des Marktes zugunsten des führenden Softwareanbieters impliziert (vgl. Pasche/von Engelhardt, 2004, S. 5). Offene Standards könnten helfen, die monopolisierte Marktmacht einzelner Anbieter zu verhindern, indem Wechselkosten gesenkt, und somit Wahlmöglichkeiten der Konsumenten erhöht werden (vgl. Kuhlmann, 2004, S. 245f.).
Jede Software stellt ein logisches Konstrukt aus geschriebenen Algorithmen und Anweisungen (vgl. von Engelhardt, 2006, S. 7) dar, welches die Funktion der Software bestimmt. Algorithmen und Handlungsanweisungen werden - in Abgrenzung zum Begriff des Wissens - der Kategorie Informationen zugeordnet (vgl. Dosi, 1996, S. 84). Damit gehört Software zur Gruppe der Informationsgüter. Beim wirtschaftlichen Handel mit Informationsgütern tritt das so genannte Informationsparadoxon auf. Nach Arrow (1971) liegt das Problem beim Handel von Informationen darin, dass
“[…] its value for the purchaser is not known until he has the information, but then he has in effect acquired it without costs”. (Arrow, 1971, S. 148)
Dieses Problem wird als Paradoxon bezeichnet, da die Transaktionspartner bei der Aushandlung des Wertes einer Information in die paradoxe Situation geraten, dass der Anbieter die Information offenbaren muss, um mit dem Interessenten einen Kaufvertrag abschließen zu können. Mit der Offenlegung der Information entfällt für den Nachfrager jedoch der Grund die Information zu kaufen, da er die Information bereits hat (vgl. Picot/Reichwald, 1991, S. 259f.).
Informationen werden daher in der Regel vor dem Kauf nicht oder nur unzureichend offengelegt. Somit stellt der Kauf von Informationen immer eine Entscheidung unter Unsicherheit dar. Das Informationsparadoxon kann als Erklärung herangezogen werden, warum CSS lediglich in Form des Binärcodes vertrieben wird. Wäre der Quellcode offengelegt, würde kein oder nur ein sehr geringer Anreiz bestehen einen Preis für die Software zu bezahlen. Da bei OSS genau das der Fall ist, existiert für OSS an sich auch kein Markt, sondern nur für komplementäre Güter und Dienstleistungen. Die Kombination aus OSS und komplementären Leistungen ist daher Grundlage der meisten kommerziellen OSS-Distributionen (vgl. von Engelhardt, 2006, S. 7f.).
Die vorangegangen Ausführungen haben deutlich gemacht, dass Software die Eigenschaften eines Informationsgutes aufweist. Dennoch existiert bei Software ein entscheidender Unterschied zu anderen Informationsgütern. Dieser liegt darin, dass ein durchschnittlicher Softwarekonsument nicht an der zugrunde liegenden Information - im Sinne von Algorithmen - interessiert ist, sondern ausschließlich an der daraus resultierenden Funktion (vgl. von Engelhardt, 2007, S. 8). Beispielsweise ist für den Großteil der Nutzer von Programmen zur Wiedergabe von Audiooder Videodateien nur von Bedeutung, dass die Software den Film oder den Musiktitel abspielt. Die zugrunde liegenden Algorithmen, welche die Funktion dieser Software ermöglichen, sind für den durchschnittlichen Programmanwender jedoch uninteressant.
Das erklärt, warum Software im Vergleich zu anderen Informationsgütern für den Konsumenten auch dann einen Nutzen stiftet, wenn die Information nach dem Kauf nicht offengelegt wird (vgl. von Engelhardt, 2006, S. 9).
Von einigen Trivialfällen abgesehen, wie beispielsweise einem simplen Texteditor, sind die meisten Softwareanwendungen sehr komplex aufgebaut. Das Gesamtsystem besteht aus Wenn-Dann-Abfolgen, logischen Schleifen, Entweder-Oder-Schaltungen etc. Aufgrund der Komplexität wird es als unmöglich erachtet, eine völlig fehlerfreie Software zu programmieren (vgl. von Engelhardt, 2006, S. 14).
Dieser komplexe, fehleranfällige Aufbau von Software hat zur Folge, dass ein erheblicher Anteil der Arbeitsleistung in der Fehlersuche und Fehlerbeseitigung liegt. Da viele Fehler erst während der Benutzung der Software bekannt werden, ist eine kontinuierliche Wartung und Pflege von Nöten (vgl. Franck/Jungwirth, 2002, S. 125). Laut Raymond (2000, S. 4) machen die Kosten für Wartung und Pflege bei CSS rund 75% der gesamten Produktionskosten aus. Software stellt somit ein Gut dar, das in einem nicht-endgültigen Zustand ausgeliefert, und anschließend laufend durch komplementäre Updates und Patches verbessert wird (vgl. von Engelhardt, 2006, S. 15).
Aufgrund dieser Komplexität und Fehlerhaftigkeit von Software, kann es vor allem für Benutzer sehr hilfreich sein, wenn die Möglichkeit einer schnellen und einfachen Kontaktaufnahme zum verantwortlichen Programmierer gegeben ist. Ein modularer Programmaufbau in Verbindung mit entsprechender Modularität in der Organisation (vgl. Langlois, 2002, S. 26ff.) kann in diesem Zusammenhang eine wichtige Vorraussetzung sein.
Laut Quah (2003, S. 29) weist Software die Eigenschaften eines digitalen Gutes auf. Ein wichtiges Merkmal digitaler Güter ist die Möglichkeit zur Rekombination.
”Digital goods are recombinant. By this I mean they are cumulative and emergent new digital goods that arise from merging antecedents have features absent from the original, parent digital goods.“ (Quah, 2003, S. 19)
Rekombinierbarkeit bedeutet also, dass bereits geschriebene Programmelemente in andere, neue Software integriert werden können. Ein einfaches Beispiel bietet die kontinuierliche Weiterentwicklung von Software. Eine neue Programmversion ist in der Regel eine Rekombination aus altem und neuem Quellcode. Darüber hinaus können aber auch Quellcode- Komponenten aus verschiedenen Programmen kombiniert, und mit neuem Quellcode ergänzt werden, um ein neues Programm zu entwickeln.
Zu diesem Zweck existieren ganze Bibliotheken aus Programmelementen (vgl. Gröhn, 1999, S. 5), die ein solches komponentenbasiertes Softwareengineering erleichtern. Bei der Softwareproduktion kann also auf Verbundvorteile zurückgegriffen werden. Das heißt, verschiedene Software kann auf denselben Quellcode-Bausteine basieren, ohne dass es zu einer Rivalität in der Nutzung der Quellcode-Komponenten kommt (vgl. Pasche/von Engelhardt, 2004, S. 6; von Engelhardt, 2006, S. 11f.).
Tabelle 1 zeigt eine Einteilung ökonomischer Güter nach den Kriterien Rivalität im Konsum und Ausschließbarkeit vom Konsum.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1 - Güterarten nach Ausschließbarkeit und Rivalität: eigene Darstellung
Eine einmal erstellte Software kann aufgrund ihrer digitalen Natur, ohne Qualitätsverluste zu Grenzkosten von nahezu Null, unendlich oft reproduziert werden (vgl. Shapiro/Varian, 1999, S. 3ff.).
Diese Eigenschaft macht einmal erstellte Software zu einem nicht-knappen Gut, d.h. es tritt keine Rivalität im Konsum auf. Dies lässt sich dadurch verdeutlichen, dass die Verwendung einer Software durch einen Benutzer nicht durch die Verwendung der gleichen Software (in Form einer Kopie) durch einen anderen Nutzer eingeschränkt wird (vgl. Pasche/von Engelhardt, 2004, S. 6). Man kann sogar noch weiter gehen und sagen, dass Software wegen der angesprochenen direkten Netzwerkeffekte, eine Art Anti-Rivalität im Konsum aufweist und somit auch als anti-knappes Gut verstanden werden kann (vgl. Weber, 2004, S. 153ff.; von Engelhardt, 2007, S. 10). Der Wert eines Softwareproduktes für jeden Einzelnen steigt also mit der Anzahl der Nutzer, die diese Software ebenfalls benutzen (vgl. Liebowitz/Margolis, 1994, S. 139f.).
Aufgrund der nicht vorhandenen Rivalität im Konsum kann es nicht zu dem für Allmendegü- ter bekannten Übernutzungsproblem kommen, welches auch als „Tragödie der Allmende“ (Hardin, 1968) bezeichnet wird.
Mit Bezug auf Tabelle 1 kann Software also nur ein öffentliches Gut oder ein Club-Gut sein, in Abhängigkeit davon ob Ausschließbarkeit gegeben ist oder nicht. Genau an diesem Punkt unterscheiden sich die beiden Modelle CSS und OSS. Im klassischen CSS-Produktionsmodell wird Software als Club-Gut bereitgestellt. Das Ausschlussprinzip wird im CSS-Modell durch proprietäre Lizenzen, d.h. durch exklusive (Intellectual) Property Rights (IPR) am Quellcode, sichergestellt (vgl. Pasche/von Engelhardt, 2004, S. 7). Man könnte also sagen, dass das in seiner Natur nicht-knappe Gut Software, im CSS-Modell durch eine Kombination aus technischem und rechtlichem Kopierschutz künstlich verknappt wird.
Im OSS-Modell hingegen wird darauf verzichtet. Durch OSS-Lizenzen, d.h. durch inklusive (Intellectual) Property Rights am Quellcode, wird das Ausschlussprinzip aufgehoben. OSS ist also durch Nichtrivalität im Konsum und Nicht-Ausschließbarkeit vom Konsum gekennzeichnet. Somit weißt OSS Eigenschaften eines öffentlichen Gutes auf (vgl. Pasche/von Engelhardt, 2004, S. 6f.; Gehring, 2006a, S. 62f.).
Bei fehlender Ausschließbarkeit tritt bekanntermaßen das so genannte Trittbrettfahrerproblem auf. Trittbrettfahrerverhalten führt bei öffentlichen Gütern tendenziell zu Unterversorgung (vgl. Richter/Furubotn, 1999, S. 107f.). Im Fall von Software würde dies also bedeuten, dass Programmierer keinen oder einen nur sehr geringen Anreiz zur Produktion von Software haben, wenn sie keine exklusiven (Intellectual) Property Rights an dem von ihnen entwickelten Quellcode erhalten. Die Beteiligung an OSS-Entwicklung stellt somit nach ökonomischer Theorie ein irrationales Verhalten dar, weshalb OSS oft auch als Phänomen bezeichnet wird.
Mit der zuvor beschriebenen theoretischen Erkenntnis im Hinterkopf, ist es interessant sich das Phänomen OSS etwas genauer anzuschauen. Nachfolgend wird daher erst kurz auf die Motive der beteiligten Entwickler eingegangen, anschließend erfolgt eine Abgrenzung von CSS- und OSS-Lizenzen anhand der Übertragung von (Intellectual) Property Rights.
Der Umstand, dass weltweit Millionen von Menschen bereit sind, freiwillig teilweise erheblichen Aufwand aufbringen, um Software zu entwickeln an der sie keine exklusiven Rechte erhalten, hat eine Reihe von Studien (vgl. z.B. Lakhani/Wolf, 2005; Lerner/Tirole, 2002; Franck et al., 2005) hervorgerufen, die sich mit den Motiven von OSS-Entwicklern auseinandersetzen. Lerner und Tirole (2002) - eine der meist zitierten Arbeiten in diesem Zusammenhang - formulieren die oft diskutierte Frage wie folgt:
“Why should thousands of top-notch programmers contribute freely to the provision of a public good?” (Lerner/Tirole, 2002, S. 198)
Die Untersuchungen zeigen, dass man die Motive der Beitragenden nicht verallgemeinern kann. Die individuellen Gründe für die Beteiligung an einem OSS-Projekt sind sehr unterschiedlich und können sowohl intrinsischer als auch extrinsischer Natur sein. Beispiele häufig genannter Motiven reichen von ideologischer Einstellung (Anti-MS), Altruismus, Reziprozität, Spaß am Programmieren, Lerneffekten, Reputationserwerb für den CSS-Markt und Eigenbedarf bis hin zu direkten monetären Anreizen (Vertrieb von komplementären Gütern und Dienstleistungen). Die Reihenfolge der aufgezählten Motive ist hier bewusst gewählt, da sie die tendenzielle Richtung von absolut intrinsischen zu absolut extrinsischen Motivationskalkülen widerspiegelt. Oben wurde angesprochen, dass die Beteiligung an OSS-Projekten aus Sicht der (I)PR-Theorie ein irrationales Verhalten darstellt (vgl. Abschnitt 2.1.4.). Betrachtet man die empirisch belegten Motivationskalküle kann man jedoch anmerken, dass die individuellen Gründe zur Partizipation durchaus rationale Entscheidungen in Bezug auf Opportunitätskostenüberlegungen darstellen. Dies gilt sowohl für intrinsisch als auch extrinsisch geprägte Motive, was nachfolgend an zwei Beispielen verdeutlicht werden soll. Für einen Menschen, der Programmieren als Spaß oder Hobby ansieht (intrinsische Motivation), stellt die Entscheidung sich in seiner Freizeit an einem OSS-Projekt zu beteiligen durchaus eine rationale Entscheidung dar. Wenn sich die Verantwortlichen einer OSS-Distribution an der Entwicklung von OSS beteiligen, zu der sie komplementäre Produkte und Dienstleistungen anbieten (extrinsische Motivation), handeln sie auch nicht irrational.
Seit der Etablierung der Open Source Definition (OSD)3 durch die Open Source Initiative (OSI) im Jahr 1998, wurde eine breite Masse an Lizenzen4 entwickelt, die die Bedingungen der OSD erfüllen. Um einen Überblick über den Stellenwert der verschiedenen OSS-Lizenzen zu bekommen, hat sich der Autor der vorliegenden Arbeit angeschaut, von wievielen OSS- Projekten die einzelnen Lizenzen verwendet werden. Als Datenbasis für die Analyse diente die Internet-Plattform SourceForge.net. Nach eigenen Angaben stellt SourceForge.net die weltweit größte Plattform dar, auf der OSS-Projekte gelistet sind (vgl. http://sourceforge.net/). Für die Erstellung der Verteilungsübersicht wurden die gelisteten Projekte nach Lizenzen sortiert. Anschließend wurde die Anzahl der Projekte je Lizenz ins Verhältnis zur Gesamtanzahl der gelisteten Projekte gesetzt. Die Ergebnisse sind in Abbildung 1 graphisch dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 - Top-10-Verteilung der verwendeten Lizenzen für OSS registriert bei SourceForge.net (Stand: 25.01.2008)
Die Verteilungsgraphik zeigt, dass die schon lange existierenden, GNU General Public License (GPL), Lesser General Public License (LGPL) und die Berkeley Software Distribution (BSD) License am häufigsten verwendet werden. Wie zu sehen ist, verwenden über 80% aller OSS-Projekte eine der drei Lizenzen.
De Laat hat im Jahr 2005 eine ähnliche Analyse vorgenommen und war dabei zu einem vergleichbaren Ergebnis gekommen. Er hatte zu diesem Zweck neben SourceForge.net noch Daten von der Plattform Freshmeat.net5 erhoben, die wiederum zu einem analogen Ergebnis geführt hatten (vgl. de Laat, 2005, S. 1520f.). Aufgrund der starken Verbreitung werden die GPL und die BSD nachfolgend als Standardbeispiele - zur Abgrenzung von CSS- und OSS- Lizenzen anhand des (I)PR-Ansatzes - herangezogen.
Der (I)PR-Ansatz basiert auf den vier Verfügungsrechten des römischen Rechts. Die einzelnen Rechte dabei sind: ein materielles oder immaterielles Gut zu benutzen (usus), sich den Ertrag aus der Nutzung anzueignen (usus fructus), die Form eines Gutes zu verändern (abusus) und die Weitergabe des Gutes an Dritte (alienation right) (vgl. Fischer, 1994, S. 316; Cezanne/Mayer, 1998, S. 1346).
Softwarelizenzen definieren welche Rechte an die Lizenznehmer übertragen werden. Um OSS und CSS unterscheiden zu können soll nachfolgend gezeigt werden, bei welchen Lizenzen welche Rechte weitergegeben werden.
Bei OSS-Lizenzen werden grundlegend alle vier Rechte an der Software an den Lizenznehmer übertragen. Nur das Weitergaberecht kann an bestimmte lizenzspezifische Bedingungen geknüpft sein und stellt somit das entscheidende Kriterium bei der Differenzierung verschiedner OSS-Lizenzen dar (vgl. Widmer/Bähler, 2006, S. 168). Zur genaueren Analyse des Transfers von (I)PR bei OSS-Lizenzen wird die in der Literatur häufig verwendete Einteilung in offene und virale Lizenzen (vgl. Hawkins, 2004, S. 108; Jaeger/Metzger, 2006, S.VIIIf.) herangezogen, um die unterschiedlichen Bedingungen bei der Weitergabe verdeutlichen zu können.
Eine der bekanntesten offenen Lizenzen ist die Berkeley Software Distribution (BSD) License der Universität Berkeley. Bei Weitergabe der Software an Dritte wird man verpflichtet, einen von der Universität Berkeley definierten Lizenztext beizufügen, der den Haftungsausschluss der ursprünglichen Entwickler für jegliche Schäden garantiert. Des Weiteren müssen Copyrightvermerke erfolgen, um die Nachvollziehbarkeit der beteiligten Entwickler zu gewährleisten. Der Lizenztext beinhaltet jedoch nicht, dass vom Originalprogramm abgeleitete Werke auch im Quelltext weitergegeben werden müssen. Somit besteht die Möglichkeit, weiterentwickelte Werke oder einzelne Teile mit anderer Software zu kombinieren und diese dann unter einer anderen, frei wählbaren Lizenz zu verbreiten. Nur der Haftungsausschluss und der Copyrightvermerk müssen gewährleistet bleiben (vgl. Widmer/Bähler, 2005, S. 169f.).
Als Paradebeispiel für virale Lizenzen gilt die von Richard Stallman und Eben Moglen entwickelte GNU General Puplic License (GPL). Stallman hatte das Ziel, dass freie Software auch immer freie Software bleiben soll. Dies wird erreicht, indem die GPL dem Nutzer die Pflicht auferlegt, abgeleitete Werke ebenfalls unter der GPL zu lizenzieren. Das üblicherweise beschränkende Copyright wird verwendet, um eine Art „Copyleft“ zu konstruieren (vgl. Widmer/Bähler, 2005, S. 170).
Die GPL wird, wegen ihres viruellen Charakters und der daraus folgenden Inkompatibilität mit allen anderen Lizenzen, von Vielen kritisiert.
Bei CSS-Lizenzen werden nicht alle Rechte an den Lizenznehmer übertragen. Wird eine CSS- Lizenz erworben, erhält der Lizenznehmer in der Regel das Recht die Software zu benutzen (usus) und ein sozusagen eingeschränktes Recht, sich den Ertrag aus der Nutzung (usus fructus) anzueignen (vgl. von Engelhardt, 2007, S. 17). Eingeschränkt bedeutet in diesem Zusammenhang, dass der Lizenznehmer sich nur den Ertrag aus der Verwendung der Software aneignen darf, z.B. dadurch, dass die Software seine Arbeit erleichtert und somit einen gewissen Ertrag in Form von eingespartem Aufwand liefert. Man darf sich jedoch keinen Ertrag aneignen, indem man die Software in veränderter oder unveränderter Form weitergibt.
Die Erkenntnisse aus der vorangegangen Betrachtung im Zusammenhang mit der Übertragung von (I)PR bei den verschiedenen Softwarelizenzen lassen sich wie in Tabelle 2 zusammenfassen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2 - Softwarelizenzen und Übertragung von (I)PR: eigene Darstellung (in Anlehnung an von Engelhardt, 2007, S. 17)
In den beiden Lizenzmodellen CSS und OSS (offene & virale Lizenzen) werden also unterschiedliche Bündel von Verfügungsrechten übertragen. Bei CSS und OSS wird also unterschiedlich mit geistigem Eigentum am Quellcode umgegangen. Während der Quelltext im CSS-Modell exklusives geistiges Eigentum des Unternehmens bleibt, wird er im OSS-Modell allen Lizenznehmern zugänglich gemacht, stellt somit inklusives geistiges Eigentum bzw. Gemeineigentum dar.
Die ökonomische Sinnhaftigkeit von geistigem Eigentum (IPR) an digitalen Informationsgü- tern wurde in den vergangenen Jahren immer häufiger in Frage gestellt (vgl. z.B. Quah, 2003; Boldrin/Levin; Eissler; 2004; 2002; Romer, 2002; Ciro, 2005).
Die traditionelle Property Rights Theorie besagt, dass exklusives (privates) Eigentum an knappen Ressourcen dafür sorgt, dass ein effizienter Umgang mit knappen Ressourcen erfolgt. Kritiker argumentieren, dass exklusives geistiges Eigentum an digitalen Informationsgütern nicht zwingend für dessen effiziente Verwendung ist, da aufgrund fehlender Knappheit keine Rivalität im Konsum gegeben ist (vgl. Quah, S. 25f.; Eissler, 2004; S. 19ff.).
Die beiden Lizenzmodelle - CSS vs. OSS - stehen in starker Korrelation zu den zugrunde liegenden Produktionsweisen. Fast alle Softwareanwendungen sind so komplex, dass ihre Produktion nicht durch einen einzelnen Entwickler erfolgen kann. Die Entwicklung des gesamten Quellcodes einer Software erfolgt also in Teamproduktion.
CSS wird dabei klassischerweise in einem kapitalistischen Unternehmen produziert. Das Eigentum an einem kapitalistischen Unternehmen ist nach Alchian/Demsetz (1972, S. 783) durch den Besitz der folgenden Rechte definiert:
- das Recht, das Verhalten der Einsatzfaktoren zu beobachten,
- das Recht, die Zusammensetzung von Teams zu verändern,
- das Recht, sich entstandene Gewinne anzueignen, bzw. die Pflicht, Verluste zu tragen,
- das Recht, alle diese Rechte zu veräußern und den Liquidationserlös einzunehmen.
Neuere Verfügungsrechtsansätze des Unternehmens (vgl. Eggertsson, 1990; Hart/Moore, 1990) unterteilen diese Rechte noch einmal in Kontroll- (Punkt 1 und 2) und Residualrechte (Punkt 3 und 4). Im Fall von CSS ist der Eigentümer des Unternehmens grundsätzlich exklusiver Eigentümer aller vier genannten Rechte. In der Praxis werden die Kontrollrechte und teilweise auch ein gewisses Gewinnmitnahmerecht (erfolgsabhängige Entlohnung) zur Produktionssteuerung an Manager und/oder Projektleiter übertragen. Die konkrete Ausgestaltung dieser Property-Rights-Arrangements kann variieren und äußert sich in der verwendeten internen Organisationsstruktur.
Eine Implementierung und Erhaltung von internen Organisationsstrukturen - Einliniensystem, Stabliniensystem, Mehrliniensystem oder Matrixsystem - dient der optimierten Steuerung und Kontrolle der Produktionsfaktoren, ist gleichzeitig aber auch mit Transaktionskosten verbunden (vgl. Picot/Dietl/Franck, 2005, S. 235ff.).
Bei OSS erhält jeder Lizenznehmer alle vier Rechte am Quellcode, was dazu führt, dass es keinen exklusiven Eigentümer gibt. Somit ist es theoretisch auch nicht möglich die Rechte exakt zu separieren und einzelne Rechte an bestimmte Personen zu übertragen. Die Steuerung der Produktion von CSS vs. OSS erfolgt also durch unterschiedliche Property-Rights- Arrangements. In diesem Zusammenhang ist es aus institutionenökonomischer Sicht wichtig, die alternativen Property-Rights-Arrangements ökonomisch zu beurteilen.
Zu diesem Zweck nutzt die Property-Rights-Theorie ein kombiniertes Bewertungskriterium aus Wohlfahrtsverlusten durch externe Effekte und Transaktionskosten, die zu deren Vermeidung aufzuwenden sind (vgl. Picot/Dietl/Franck, 2005, S. 47). Abbildung 2 zeigt eine graphische Modellierung des kombinierten Bewertungssystems.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2 - Trade-off zwischen Wohlfahrtsverlusten durch externe Effekte und Transaktionskosten: eigene Darstellung in Anlehnung an Picot/Dietl/Franck, 2005, S. 50
„Von mehreren Property-Rights-Strukturen ist diejenige vorzuziehen, bei der die Summe aus Transaktionskosten und den durch externe Effekte hervorgerufenen Wohlfahrtsverlusten minimiert wird.“ (Picot/Dietl/Franck, 2005, S. 49)
Externe Effekte treten in Situationen auf, wo die wirtschaftliche Situation von Personen durch die Konsumoder Produktionstätigkeit einer anderen Person beeinflusst wird (vgl. Richer/Furubotn, 1999, S. 101; Picot/Dietl/Franck, 2005, S. 47).
Von negativen externen Effekten spricht man immer dann, wenn die entstehenden sozialen Kosten höher sind als die privaten Kosten des Handelnden. Als Standardbeispiel wird in diesem Zusammenhang häufig die Luftverschmutzung durch einen Industriebetrieb genannt, wodurch umliegende Anwohner negativ beeinträchtigt werden (vgl. Picot/Dietl/Franck, 2005, S. 48; Erlei/Leschke/Sauerland, 1999, S. 281). Drückebergerei (Shirking) bei der Teamproduktion stellt auch einen negativen Effekt dar, da die Vorteile eines verminderten Arbeitseinsatzes dem Drückeberger in voller Höhe zukommen, die Nachteile in Form von verringertem Gesamtoutput dagegen von allen Teammitgliedern verantwortet werden müssen.
„Institutionelle Lösungen (Verträge, organisatorische Regeln) für die Probleme der Teamproduktion sind sowohl an den Wohlfahrtszuwächsen durch Entschärfung der Shirking-Externalität als auch an den dafür in Kauf zu nehmenden Transaktionskosten zu messen.“ (Picot/Dietl/Franck, 2005, S. 51)
Mit Bezug auf externe Effekte hat Demsetz (1967) schon die These aufgestellt, dass geeignete Property-Rights-Zuordnungen helfen können unerwünschte externe Effekte zu internalisieren. Zur Verdeutlichung seiner These beschrieb er die heute bekannte Geschichte über die Einführung von privaten Eigentumsrechten unter den Montagnais-Indianern von Labrador zu Beginn des 18. Jahrhunderts (vgl. Erlei/Leschke/Sauerland, 1999, S. 272f.).
Die Property-Rights-Theorie besagt also, dass die Internalisierung externer Effekte umso besser funktioniert, je vollständiger Property Rights auf Akteure zugeordnet sind. Die optimale Ausgestaltung von Property-Rights-Arrangements ist jedoch mit Transaktionskosten der Definition, Übertragung und Durchsetzung von Property Rights verbunden. Die Teamproduktion stellt eine spezielle Situation dar, in der die perfekte Zuordnung von Property Rights auf handelnde Akteure prohibitive Transaktionskosten hervorruft (vgl. Picot/Dietl/Franck, 2005, S. 50f.).
„Wird die Internalisierung externer Effekte durch Transaktionskosten erkauft, die die Wohlfahrtsgewinne übersteigen, dann ist der entsprechende Vertrag bzw. die entsprechende organisatorische Regelung ineffizient.“
(Picot/Dietl/Franck, 2005, S. 49)
In Bezug auf das Teamproduktionsproblem von Software könnte man also sagen, dass der negative externe Effekt der Drückebergerei (Shirking) im CSS-Modell internalisiert wird, indem eine Governance-Struktur (Zuordnung von Property Rights) implementiert wird, die aktive Weisung und Kontrolle (Monitoring) ermöglicht.
Monitoring ist die am weitesten verbreitete Methode zur Lösung des Teamproduktionsproblems. Zu diesem Zweck überträgt der Eigentümer des Unternehmens gewisse Entscheidungsund Kontrollrechte auf ausgewählte Teammitglieder. Diese spezialisieren sich auf die Überwachung des Produktionsprozesses und sollen das Team vor individuellem Drückebergertum schützen (vgl. Picot/Dietl/Franck, 2005, S. 55).
Mit dieser Möglichkeit der Lösung des Teamproduktionsproblems im Hinterkopf stellt sich nun die Frage, wie die Softwareproduktion in einem OSS-Projekt kontrolliert und gesteuert wird. Die Tatsache, dass der Quellcode im OSS-Modell Gemeineigentum darstellt, verhindert die Möglichkeit zu aktiver Kontrolle und Weisung (Monitoring), da die Property Rights im OSS-Modell nicht separat übertragen werden können. CSS-Unternehmen und OSS-Projekte sind also unterschiedliche Property-Rights-Arrangements - oder anders ausgedrückt institutionelle Lösungen - zur Lösung des Teamproduktionsproblems bei der Entwicklung komplexer Software. Daher ist es interessant sich näher anzuschauen inwieweit gewisse Governance- Strukturen in OSS-Projekten existieren und welche Steuerungsmechanismen zur freiwillig arbeitsteiligen Produktion eingesetzt werden. Anschließend muss ökonomisch bewertet werden, welche institutionelle Lösung die Summe aus Transaktionskosten und Wohlfahrtsverlusten durch externe Effekte minimiert.
Es existiert keine eindeutige deutsche Übersetzung für den Begriff Governance, im Gegenteil der Ausdruck hat sich auch im deutschen Sprachraum etabliert. Ganz allgemein kann man unter Governance die Steuerungsund Regelungssysteme einer Organisationsform verstehen. Williamson (1981) definiert Governance-Strukturen als
„…the explicit or implicit contractual framework within which a transaction is located (markets, firms and mixed modes)”. (Williamson, 1981, S. 1544)
In diesem Sinne sind die traditionellen Organisationsformen (Markt, Unternehmen, Netzwerk), in denen Handlungen durch eine oder mehrere Koordinationsformen (Wettbewerb, Hierarchie, Kooperation) gesteuert werden, Ausgestaltungen verschiedener Governance- Strukturen. Die bekannten Organisationsund Koordinationsformen lassen sich wie in Tabelle 3 zusammenfassen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3 - Organisationsund Koordinationsformen: eigene Darstellung (in Anlehnung an Kavai/Schmid, 2004, S. 253)
Häufig werden die untereinander stehenden Formen von Organisation und Koordination gleichgesetzt. Es hat sich jedoch gezeigt, dass in allen drei Organisationsformen die Koordinationselemente Wettbewerb, Hierarchie und Kooperation angewendet werden, wobei die zugehörige Koordinationsform immer eine dominante Rolle einnimmt (vgl. Bradach/Eccles, 1991; Kavai/Schmid, 2004).
In der OSS-Literatur haben sich verschiedene Erklärungsansätze und Bezeichnungen bezüglich der Governance-Strukturen von OSS-Projekten entwickelt.
Raymond (1998a) sowie Demil/Lecocq (2006) bezeichnen die Organisation von OSS- Projekten als „Bazaar-Governance“. Garzarelli (2003) argumentiert, dass OSS-Projekte besondere organisatorische Eigenschaften aufweisen, welche „…can be explained by combining the recently developed organizational theory of professions with the classic one of clubs” (Garzarelli, 2003, S.II). „Community managed projects“ (O’Mahoney, 2003, 2005, 2007),
„virtual organisation“ (Gallivan, 2001) oder auch „user-to-user-assistence“ (Lakhani/von Hippel, 2000, von Hippel/von Krogh, 2003) sind weitere Beispiele der zahlreich existierenden Bezeichnungen für die OSS-Projektorganisation. Ein weit verbreiteter und anerkannter Ansatz ist die Interpretation eines OSS-Projektes als Netzwerkorganisation (vgl. Powell, 1996; Benkler, 2002; Brand/Schmid, 2005; Iannacci/Mitleton-Kelly, 2005).
Die gesamte OSS-Bewegung wird wiederum als ein Netzwerk aus Netzwerken (vgl. Gehring, 2006b, S. 285) verstanden, was als typisches Merkmal einer Informationsgesellschaft gilt (vgl. u.a. Castells, 2001; Tuomi, 2002).
Eine empirische Untersuchung bezüglich der Koordination in einer solchen Netzwerkorganisation liefert die Fallstudie von Brand/Schmid (2005), in der das OSS-Projekt KDE6 analysiert wurde. Die Autoren bezeichnen OSS-Projekte als virtuelle Arbeitsnetze, d.h. als eine Unterform der Netzwerkorganisation. Ergebnis ihrer Studie ist ein komplementäres Verhältnis der drei Koordinationsformen mit unterschiedlich starker Ausprägung in den einzelnen Projektschritten.
„Als vorsichtige allgemeine Schlussfolgerung lässt sich aus der Fallstudie festhalten, dass bei der Arbeitsverteilung Kooperation dominiert, die Hierarchie eine eher geringe Rolle spielt. Bei der Leistungserstellung überwiegt zwar die Kooperation, doch bestehen auch hierarchische Elemente. Bei der Arbeitszusammenführung aufgrund der Kontrollnotwendigkeiten der Vereinheitlichung der Software und dem Projektzusammenhalt spielt die Hierarchie eine wesentliche Rolle, bei etwas geringerer, aber vorhandener Bedeutung auch der Kooperation. Wettbewerb hat eine geringe Bedeutung und wirkt sich eher auf die Motivation aus.“
(Brand/Schmid, 2005, S. 20)
Die kurze Einführung in die grundlegenden Organisationsformen, sowie das Praxisbeispiel haben gezeigt, dass OSS-Projekte die größten Gemeinsamkeiten mit der Netzwerkorganisation aufweisen.
Im Vergleich zu anderen Aspekten rund um das Thema Open Source Software, welches nun schon seit fast drei Jahrzehnten diskutiert wird, hat das Teilgebiet der OSS-Governance erst in den letzten Jahren regeres wissenschaftliches Interesse geweckt (vgl. Schweik/Semenov, 2003, S. 7).
Eine einheitliche Definition speziell von OSS-Governance hat sich in diesem Zusammenhang noch nicht herausgebildet (vgl. Markus, 2007, S. 152).
Nach Williamson (1991) konstituiert sich jede Organisationsform aus Verträgen. Märkte basieren in der Regel auf klassischem Vertragsrecht, Unternehmen stellen ein Geflecht aus Unternehmensverfassung und Arbeitsverträgen dar. Die Organisationsformen repräsentieren verschiedene Verhältnisse von Kontrollund Anreizmechanismen. Der Markt steht für ein hohes Anreizlevel und geringe Kontrolle. Eine unternehmerische Hierarchie spiegelt genau das Gegenteil wider, d.h. ein hohes Maß an Kontrolle bei geringerer Anreizsetzung. Die Form der Netzwerkorganisation, welche die Eigenschaften von OSS-Projekten am besten widerspiegelt, hat als Hybridform zwischen Markt und Hierarchie mittlere Ausprägungen dieser beiden Faktoren (vgl. Williamson, 1991, S. 271ff.).
Weiß (2007) argumentiert, dass der Erfolg von OSS-Projekten auf ein geniales Verhältnis von Anreizsetzung und Kontrolle zurückzuführen ist. Nach seiner Ansicht spielt der Peer-Review- Mechanismus dabei die entscheidende Rolle, da dadurch eine leistungsorientierte (meritokratische) Hierarchie entsteht (vgl. Weiß, 2007, S. 14).
Stellt sich die Frage, auf welcher Grundlage, welchem Vertragsmechanismus, welchen Normen die netzwerkartige Organisation von OSS-Projekten basiert. Die Ansicht des vorliegenden Beitrages ist, dass durch OSS-Lizenzen ein relativ offener, unspezifischer Vertrag geschlossen wird, der die Grundlage dieser Organisationsform bildet. Studien, die sich mit OSS- Governance beschäftigen, haben dies bislang nicht explizit diskutiert. Stattdessen existieren die verschiedensten Ansätze bezüglich der Mechanismen, die die Koordination in OSS- Projekten regeln. Die folgende Auflistung soll einen kurzen Überblick über die in der Literatur genannten Mechanismen geben:
- Steuerung durch Peer-Review-Mechanismen bezüglich des erstellten Quellcodes (vgl. Lee/Cole, 2003; Weiß, 2007)
- Steuerung durch extrinsische Anreiz zu Reputationserwerb in Verbindung mit Signaling-Möglichkeiten (vgl. Krogh et al., 2003; Lerner/Tirole, 2002)
- Steuerung durch „Flaming“ als Sanktionsmittel (vgl. Osterloh et al., 2004)
- Steuerung durch Beeinflussung intrinsischer und extrinsischer Motivation der Beteiligten (vgl. Lattemann/Stieglitz, 2006)
- Steuerung durch Anerkennung von gemeinsamen Werten und Einstellungen, sowie durch natürlichen Autorität des Projektinitiators (vgl. Morner, 2002)
- Steuerung durch stigmergische7 Selbstorganisation (vgl. Heylighen, 2007)
- Steuerung durch institutionelle Mechanismen, wie OSS-Lizenzen (vgl. de Laat, 2005; Gehring, 2006a) oder durch die Gründung von gemeinnützigen Stiftungen (vgl. O’Mahoney, 2007, de Laat, 2007b).
Eine Gruppe von Autoren um Paul B. de Laat hat sich in jüngster Vergangenheit explizit dem Thema OSS-Governance gewidmet (vgl. de Laat, 2007a; de Laat, 2007b; Markus, 2007; O´Mahoney, 2007; Hertel, 2007; Jørgensen, 2007).
Markus, einer der genannten Autoren, hat aufgrund des Fehlens einer allgemein anerkannten Definition von OSS-Governance folgenden Definitionsvorschlag vorgestellt, der als angemessen erachtet und deshalb auch für die vorliegende Arbeit übernommen wird.
„[…] OSS governance can be defined as the means of achieving the direction, control, and coordination of wholly or partially autonomous individuals and organizations on behalf of an OSS development project to which they jointly contribute.” (Markus, 2007, S. 152)
In der Regel wird für die Entwicklung jeder OSS ein konkretes Projekt gegründet. Im Folgenden wird daher nicht mehr zwischen den Bezeichnungen OSS-Produkt und OSS-Projekt unterschieden, sondern der Begriff OSS-Projekt als Synonym für die Entwicklung eines bestimmten OSS-Produktes verwendet.
Studien haben gezeigt, dass OSS-Projekte einem gewissen Projektlebenszyklus unterliegen (vgl. Schweik/Semenov, 2003; Wynn, 2003; Lattemann/Stieglitz, 2005).
Jede Projektlebenszyklusphase weist dabei spezifische Merkmale auf, hinsichtlich Projektstruktur, primärem Fokus, Motivation der Beteiligten, Grad der Arbeitsteilung bzw. - spezialisierung, sowie Koordination der Mitglieder. Deshalb ist für erfolgreiche Produktentwicklung eine dynamische Anpassung der Governance in OSS-Projekten erforderlich (vgl. Lattemann/Stieglitz, 2005, S. 195f.).
Mit fortschreitendem Projektlebenszyklus wird es sukzessive wichtiger hierarchieähnliche Strukturen zu implementieren, um ein angemessenes Maß an Kontrolle und Koordination über die verschiedenen Organisationseinheiten gewährleisten zu können (vgl. Achtenhagen et al., 2003, S. 456).
Die Bestimmung einer Produktlebenszyklusphase erfolgt in konventionellen Unternehmen meist anhand von Größen wie Verkaufsbzw. Umsatzzahlen. Lebenszykluskonzepte bieten verschiedene Phaseneinteilungen und -benennungen an. Für den klassischen progressivdegressiv-regressiven Verlauf werden in der Literatur zwischen drei und fünf Phasen genannt (vgl. Haupt, 1999, S. 23; Höft, 1992, S. 17ff.).
Nach Schweik/Semenov (2003, S. 26) existieren für OSS-Projekte die folgenden Alternativen zur Identifikation der Lebenszyklusphasen:
- Anzahl der Downloads
- Jährlicher Zuwachs des Marktanteils
- Jährlicher Zuwachs der Mitgliederzahlen
- Anwenderzufriedenheit
- Funktionsumfang im Vergleich zu Konkurrenzprodukten.
Als repräsentativer, im Vergleich zu den anderen Alternativen verhältnismäßig gut messbarer Indikator, wird die Anzahl an Downloads angesehen (vgl. Lattemann/Stieglitz, 2005, S. 195; Wynn, 2003, S. 286).
Zur Erklärung der Entwicklung von OSS-Projekten ist ein Vier-Phasen-Schema angemessen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3 - Lebenszykluskonzept: eigene Darstellung in Anlehnung an Wynn, 2003, S. 286
Wie Abbildung 3 zeigt, lässt sich der Lebenszyklus eines OSS-Projektes also in die folgenden Phasen unterteilen:
1. Einführung
2. Wachstum
3. Reife
4. Rückgang (mit oder ohne Wiederaufleben).
Nachfolgend werden die vier Phasen eines OSS-Projektes genauer charakterisiert.
Die Initiative zur Gründung eines OSS-Projektes geht meist von einem persönlichen oder berufsbezogenen Bedarf nach einer Softwareanwendung aus, der vom bestehenden Markt nicht oder nur unzulänglich bedient werden kann. Schweik und Semenov (2003) zeigen empirisch, dass die meisten Projekte von einer Einzelperson oder einer sehr kleinen Personengruppe initiiert werden. Als Paradebeispiel fungiert in diesem Zusammenhang die Gründung des Linux-Kernel-Projektes, bei dem sich der finnische Student Linus Torvalds das Ziel setzte, ein freies unixähnliches Betriebssystem zu entwickeln. Die Motivation der Beteiligten in dieser ersten Projektphase - also der/des Projektgründer(s) - wird als überwiegend intrinsischer Natur angesehen. Bei der Gründung durch mehrere so genannte Kernentwickler geht man davon aus, dass sich zunächst eine informelle Projektstruktur entwickelt, wobei jedes Mitglied ein sehr breites Aufgabenspektrum zu bewältigen hat. Vertrauen und Konsens sind die wichtigsten Koordinationsinstrumente in dieser Phase. Falls sich in der Gruppe ein so genannter Leader etabliert, hat dieser dennoch nicht das exklusive Recht, den anderen Projektbeteiligten konkrete Arbeitsaufgaben vorzuschreiben. Der Leader kann nur versuchen, die Arbeitsbemühungen der anderen Teammitglieder in die richtige Richtung zu lenken. Man spricht in diesem Zusammenhang davon, dass die Rolle des Leaders lediglich Koordination erleichtern soll, eine direkte Weisungsbefugnis existiert hingegen nicht. Als wichtigste Aufgaben in dieser Projektphase gelten:
- die Erstellung einer funktionsfähigen ersten Version der Software,
- die Implementierung eines modularen Projektdesigns, um rein technisch betrachtet optimale Vorraussetzungen für die parallele Arbeit vieler Entwickler zu schaffen,
- sowie die Verbreitung der Idee bzw. der Vision des Projektes, um viele Entwickler für das Projekt zu begeistern (z.B. durch eine Projektregistrierung bei SourceForge.net).
Die beschriebenen Aspekte werden als essentielle Grundbausteine für eine erfolgreiche Weiterentwicklung von OSS-Projekten angesehen (vgl. Schweik/Semenov, 2003, S. 4f.; Wynn, 2003, S. 286f.; Lattemann/Stieglitz, 2005, S. 195).
Bei erfolgreicher Gestaltung der Projektgründung durch die Kernentwickler, wie im vorigen Abschnitt beschrieben, kommt es zum Projektwachstum. Es ist anzunehmen, dass Programmdownloads in dieser Projektphase überwiegend durch Personen erfolgen, die gute Programmierkenntnisse aufweisen. Somit sind diese neuen Community-Mitglieder nicht vorwiegend als reine Programmnutzer sondern eher als zusätzliche Entwickler anzusehen. Mit steigender Anzahl der Mitglieder geht auch ein zunehmender Bedarf an formalen, administrativen Koordinations- und Kommunikationsmöglichkeiten einher. Zu den wichtigsten Aufgaben in dieser Projektphase zählen daher:
- die Schaffung geeigneter Kommunikationsmechanismen, wie z.B. Community- Mailinglisten und Diskussionsforen,
- die Implementierung eines guten Versionsmanagementsystems8,
- sowie effektives Anwerben weiterer Projektmitglieder.
Die OSS-Anwendung an sich, ist in dieser Phase geprägt von der Herausgabe überarbeiteter Versionen (releases), Korrekturen/Erweiterungen (patches) und ausgiebiger Fehlerbehebung (bug-fixing). Ansteigende Projektgröße und -komplexität bieten den Mitgliedern die Möglichkeit, sich zunehmend entsprechend ihrer Interessen und Fähigkeiten auf bestimmte Aufgaben zu spezialisieren. Dadurch etablieren sich verschiedene Rollen innerhalb der Community, wie Schnittstellen-Designer, Code-Tester, Release-Manager, Support-Manager, Dokumentations-Manager und Bug-Fixer. Trotz der sich entwickelnden Struktur bleibt die Projektkontrolle überwiegend bei den Kernentwicklern und damit relativ zentral. Die Kernentwickler übertragen nur weniger bedeutende Funktionsbereiche an andere Community-Mitglieder (vgl. Schweik/Semenov, 2003, S. 6; Wynn, 2003, S. 287; Lattemann/Stieglitz, 2005, S. 195).
Man spricht von der Reifephase, wenn davon ausgegangen wird, dass ein Maximum an beteiligten Entwicklern und Nutzern erreicht ist. Unter dieser breiten Masse von Personen, die das Programm heruntergeladen haben, befindet sich nun auch ein gewachsener Anteil an reinen Nutzern. Des Weiteren wird angenommen, dass neben intrinsischer Motivation zunehmend extrinsische Motivationskalküle eine wichtigere Rolle spielen. Das liegt vielleicht auch darin begründet, dass durch die gewachsene Bekanntheit des Projektes, die im OSS-Projekt erworbene Reputation als Signaling-Instrument auf dem CSS-Markt genutzt werden kann. Die Kernentwickler verbringen in dieser Projektphase einen großen Teil ihrer Zeit mit nichtprogrammierbezogenen Aufgaben, wie der Etablierung von community-internen Grundsätzen und Regeln, sowie der Bewertung von entwickeltem Quellcode in Kombination mit der Entscheidung über dessen Aufnahme in die offizielle Programmversion. Dies führt wiederum dazu, dass zunehmend Kontrollund Entscheidungsrechte auf ausgewählte Community- Mitglieder übertragen werden. Als zentrales Ziel der Kernentwickler zu diesem Zeitpunkt wird die Aufrechterhaltung des Projektes angesehen. In diesem Sinne müssen sie bei der Entwicklung formaler Grundsätze und Regeln darauf achten, Bedingungen zu schaffen, die die Interessen der gesamten Community wahren. Es wird betont, dass die Beibehaltung gewisser ethischer Grundsätze der offenen Softwareentwicklung in diesem Zusammenhang ein essentielles Kriterium darstellt. Man nimmt darüber hinaus an, dass die Umsetzung dieser Aufgaben den langfristigen Projekterfolg maßgeblich beeinflusst (vgl. Wynn, 2003, S. 287; Lattemann/Stieglitz, 2005, S. 196).
Die Phase des Rückgangs ist gekennzeichnet durch rückläufige Nutzerund Entwicklerzahlen. Die möglichen Gründe für die rückläufige Entwicklung sind vielfältig. Es kann durch Abwanderung eines führenden Projektmitgliedes, beispielsweise des Projektgründers, dazu kommen, dass das Vertrauen oder Interesse in das Projekt verloren geht und sich infolge dessen weitere Mitglieder aus der Community zurückziehen. Für reine Nutzer wird das Argument genannt, dass sie auf ein konkurrierendes Produkt umsteigen, welches ihre Ansprüche besser befriedigt. Beteiligte Entwickler ziehen sich eventuell auch aus dem Projekt zurück, weil sie sich in einem anderen Projekt engagieren wollen. Streit mit anderen Entwicklern oder Unzufriedenheit mit Entwicklungen innerhalb der Community sind weitere Gründe für die mögliche Entscheidung, sich aus dem Projekt zurückzuziehen. Der primäre Fokus der verbleibenden Community-Mitglieder liegt dann in der Pflege und Aufrechterhaltung der bestehenden Programmversion. In manchen Fällen gelingt es jedoch auch das Projekt wieder aufleben zu lassen. In diesen Fällen spricht man davon, dass die Projekte in eine erneute Wachstumsoder Reifephase eintreten, abhängig vom Ausmaß des Wiederauflebens (vgl. Wynn, 2003, S. 288; Lattemann/Stieglitz, 2005, S. 196).
Die Betrachtung der einzelnen Projektphasen hat gezeigt, dass sich die Organisation in OSS- Projekten im Verlauf des Lebenszyklus verändert. Im Anfangsstadium des Projektes ist die Organisation von informeller Koordination, direkter 1:1-Kommunikation und Vertrauen als Kontrollinstrument geprägt. Mit zunehmendem Projektwachstum erfolgt der Aufbau mehr oder weniger formeller Strukturen in Verbindung mit einer Aufgabenspezialisierung der Community-Mitglieder. Die Projektgründer werden oft zu Leitfiguren mit administrativen Managementaufgaben.
[...]
1 Es wird hier der Begriff Open Source Software (OSS) als Kennzeichnung aller Free-/Open Source Software Projekte benutzt, da sich diese Umschreibung für die zwei Richtungen „Open Source Software“ und „Free Software“ in der einschlägigen Literatur durchzusetzen scheint.
2 Von einer möglichen Kopierfunktion des Faxgerätes wird an dieser Stelle abgesehen.
3 Die Kernpunkte der OSD können unter http://www.opensource.org/docs/osd eingesehen werden.
4 Unter http://www.opensource.org/licenses ist eine Auflistung der „Open Source Initiative Approved“ Lizenzen zu finden.
5 Freshmeat.net gehört neben SourceForge.net zu den bekanntesten Indizees für OSS-Projekte.
6 KDE (K Desktop Environment) ist neben GNOME die bekannteste graphische Benutzeroberfläche für Linux und andere Unix-Derivate.
7 Ein Prozess wird als stigmergisch bezeichnet, wenn eine von einem Agenten begonnene Arbeit ein Zeichen hinterlässt, der andere Agenten dazu anregt, diese Arbeit fortzusetzen (vgl. Heylighen, 2007, S. 174).
8 Das bekannteste Versionsmanagementsystem ist das „Concurrent Versions System“ (CVS). CVS ist ebenfalls Open Source Software und wird z.B. auch zum Versionsmanagement bei SourceForge.net verwendet (vgl. ausführlich Fogel/Bar, 2003).
