Verhalten von Unternehmen im Open Source Entwicklungsprozess

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Quellcodeverzeichnis

Symbolverzeichnis

Abkürzungsverzeichnis

1. Einleitung

2. Open Source Software - Definition und Literaturüberblick
2.1. Allgemeine Abgrenzung von Open Source Software
2.2. Lizenzmodelle in der Open Source Entwicklung
2.3. Die Open Source Community
2.4. Warum in einer Open Source Community entwickelt wird
2.4.1. Sozialwissenschaftliche Betrachtung
2.4.2. Betriebswirtschaftliche Betrachtung
2.4.3. Volkswirtschaftliche Betrachtung . .
2.5. Zielsetzung der Arbeit

3. Das spieltheoretische Modell
3.1. Modellannahmen
3.2. Das Grundmodell
3.3. Erweiterung auf mehrere Perioden
3.4. Die Modulartität von Software

4. Auswertung der Simulation
4.1. Szenario - tmax =M
4.2. Szenario - tmax = M − 1
4.3. Szenario - tmax = M
4.4. Szenario - tmax = M + 2
4.5. Szenario - tmax = 10 · M

5. Interpretation der Simulationsergebnisse

6. Zusammenfassung und Ausblick

A. Anhang
A.1. Abbildungen
A.2. Formeln
A.3. Dokumentation Simulationsprogramm
A.3.1. Die Klasse GameTree
A.3.2. Die Klasse Node
A.3.3. Die Klasse makeWSF
A.3.4. Plotten der Schaubilder
A.3.5. Erstellen von Simulationsreihen

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Tabellenverzeichnis

3.1. Auszahlungsmatrix für einen einperiodigen Spielbaum

3.2. Allgemeine Auszahlungsmatrix

3.3. Wahrscheinlichkeiten der Handlungsalternativen

3.4. Einperiodiges Beispiel mit w=1.500, r=30.000, i=5%

3.5. Auszahlungsmatrix für Periode t im mehrperiodigen Spiel

3.6. Auszahlungsmatrix Periode 2

3.7. Auszahlungsmatrix Periode 1

3.8. Beispiel - Auszahlungsmatrix für Knoten 0-2

3.9. Auszahlungsmatrix Typ 1

3.10. Auszahlungsmatrix Typ 2

3.11. Auszahlungsmatrix Typ 3

3.12. Auszahlungsmatrix der Periode tmax − 2

Symbolverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Zu Beginn der 90er Jahre beschloss ein junger Programmierer aus Finnland, ein klei- nes Programm zu schreiben, um sich von zu Hause in den Computer seiner Uni- verstität einwählen zu können. Um sich mit anderen Interessierten über den Aufbau des Programms auszutauschen, veröffentlichte er den Programmcode im Internet. Zu diesem Zeitpunkt konnte Linus Torvalds nicht ahnen, dass er mit diesen Code- zeilen das bisher größte bestehende Open Source Projekt anstieß. Aus dem kleinen Programm wurde in kurzer Zeit das lauffähige Betriebssystem Linux (Torvalds und Diamond, 2001). Die Idee, Softwarecode zu Zwecken des Feedbacks und der Erwei- terung durch andere der Öffentlichkeit zur Verfügung zu stellen, war zwar nicht neu und dennoch motivierte der Gedanke, ein offenes Betriebssystem zu entwickeln, tau- sende begeisterte Programmierer, sich an dem Projekt zu beteiligen. 15 Jahre später ist die Entwicklung von Programmen, deren Quellcode frei zugänglich ist, aus der Softwarelandschaft nicht mehr wegzudenken. War vor einigen Jahren diese Art der Programme vorwiegend im Bereich der Entwickler zu finden, so stellen heute auch Anwenderprogramme wie Browser, Bildbearbeitungs- oder Bürosoftware einen we- sentlichen Teil der Open Source Software dar. Wachsende Marktanteile und steigende Anwenderfreundlichkeit machen Open Source Produkte auch für Laien immer at- traktiver. Diese Konkurrenz bekommen auch Hersteller kommerzieller Software zu spüren, was die Prozesse der Softwareentwicklung stark verändert. So rückt nicht nur die Betrachtung volkswirtschaftlicher Aspekte der Open Source Software in den Fokus der Wissenschaft, sondern verstärkt auch betriebswirtschaftliche Überlegun- gen der offenen Entwicklung. Zahlreiche Unternehmen beteiligen sich bereits an der Entwicklung in Communities. Einen der größten Distributoren mit der Linuxvari- ante OpenSuse stellt heute der Softwarehersteller Novell dar. Doch welche Motive haben Unternehmen, Entwicklung und Marketing zu finanzieren, um eine Software kostenfrei im Internet anzubieten? Ebenso kann man eine steigende Anzahl von Un- ternehmen verzeichnen, die Open Source Software zur täglichen Bewältigung ihres Kerngeschäfts einsetzen. Welche Anreize bestehen somit für ein Unternehmen, sich bei der Wahl einer Softwarelösung für ein Open Source Produkt zu entscheiden und sich zudem an dessen Weiterentwicklung zu beteiligen?

Um diesen Fragestellungen nachzugehen, soll in der vorliegenden Arbeit ein Modell entwickelt werden, welches über das Verhalten eines rational agierenden Teilnehmers in einer Open Source Community Aufschluss geben kann. Dabei soll der Fokus auf einer Betrachtung von Unternehmen liegen, die vor der Entscheidung stehen, sich an der Entwicklung einer Open Source Software zu beteiligen. Zunächst sollen die wesentlichen Einflussfaktoren und deren Wirkungszusammenhänge definiert werden. Basierend auf spieltheoretischen Überlegungen erfolgt die Erstellung des Modells in mehreren Schritten. Ziel dieser Arbeit ist es, Aufschluss über die Fragen der Entwicklungsbeteiligung von Unternehmen und der Fertigstellung von Software in einer Open Source Community zu geben.

2. Open Source Software - Definition und Literaturüberblick

Das folgende Kapitel soll zunächst einmal einen Überblick über den Begriff der Open Source Software und die dazu gängige Literatur geben. Im ersten Abschnitt wird konkreter auf die Abgrenzung der Open Source Software eingegangen. Im weiteren Verlauf werden die Aspekte der Lizenzgestaltung und der Open Source Community näher betrachtet. Anschließend wird die Fragestellung beleuchtet, warum eine Entwicklung in einer Open Source Community stattfindet.

2.1. Allgemeine Abgrenzung von Open Source Software

Wie der Name bereits zum Ausdruck bringt, handelt es sich bei Open Source Softwa- re (OSS) um Software, deren Quellcode offen gelegt wird. Eine solche Offenlegung steht im Gegensatz zu der Verbreitung kommerzieller Software, die in der Regel nur in Form eines Binärcodes verkauft wird. Dies hat zur Folge, dass Nutzer einer sol- chen Software keinen Einblick in die Struktur des zu Grunde liegenden Quellcodes haben und diesen somit auch nicht verändern können. Ganz anders verhält es sich bei offener Software. Hier kann sich ein kundiger Nutzer anhand des Quellcodes ein umfangreiches Bild der Funktionsweise machen und diese, falls gewünscht, an seine individuellen Bedürfnisse anpassen. Die ursprünglich definierten Eigenschaften ei- ner, heute als Open Source bezeichnete, Software, gehen auf den Beginn der offenen Entwicklung zurück. 1983 wurde von Richard Stallman, der zu diesem Zeitpunkt für das Artificial Intelligence Laboratory des MIT arbeitete, die Free Software Founda- tion (FSF) gegründet. Diese Organisation beschäftigt sich seit ihrer Gründung nach eigener Aussage mit dem Erhalt, dem Schutz und der Verbreitung „freier Software“, wobei der Begriff „frei“ in diesem Zusammenhang keineswegs im Sinne von kosten- frei interpretiert werden kann. Eine Vision der FSF war eine Welt, in der es nur freie Software gibt. Da die Basis jeder Softwarenutzung ein Betriebssystem darstellt, wur- de 1984 das erste Projekt freier Softwareentwicklung ins Leben gerufen. Es handelte sich dabei um das GNU Projekt, welches die Entwicklung eines UNIX-ähnlichen Be- triebssystems zum Ziel hatte. Um dem Begriff „freier Software“ einen Rahmen zu geben, legte die Free Software Foundation vier Grundsätze fest, die eine „freie“ Soft- ware erfüllen muss (Free Software Foundation, 2006).

- Die Freiheit, das Programm für jeden Zweck zu benutzen (Freiheit 0).
- Die Freiheit, zu verstehen, wie das Programm funktioniert und wie man es für seine Ansprüche anpassen kann (Freiheit 1). Der Zugang zum Quellcode ist dafür Voraussetzung.
- Die Freiheit, Kopien weiterzuverbreiten, so dass man seinem Nächsten weiter- helfen kann (Freiheit 2).
- Die Freiheit, das Programm zu verbessern und die Verbesserungen der Öffent- lichkeit zur Verfügung zu stellen, damit die ganze Gemeinschaft davon profi- tieren kann (Freiheit 3). Der Zugang zum Quellcode ist dafür Voraussetzung.

Die ursprüngliche Definition der „freien Software“ wurde 1998 im Rahmen eines Treffens langjähriger Programmierer der „freien Software“-Szene aufgegriffen. Den Auslöser dieser Zusammenkunft stellte die Ankündigung des Unternehmens Netsca- pe dar, den Quellcode ihres Browsers zu veröffentlichen, und die damit verbundene Kontaktaufnahme zu Softwareentwickler Eric Raymond. Um Herstellern kommerzi- eller Software in offensiverer Weise gegenüber treten zu können, suchte die Gruppe eine aussagekräftige Bezeichnung für Software, deren Quellcode frei zugänglich ist. Der Begriff der Open Source Software wurde geboren. Parallel dazu fand die Grün- dung der Open Source Initiative (OSI) statt, die heute hauptsächlich den Beteiligten Eric Raymond, Bruce Perens und Tim O’Reilly zugeschrieben wird. Der Begriff der Open Source Software distanzierte sich von dem der „freien Software“, um Fehlin- terpretationen einer kostenfreien Bereitstellung entgegen zu wirken. Zur genauen Definition, welche Eigenschaften eine Open Source Software erfüllen sollte, wurde als Regelwerk die „Open Source Definition (OSD)“ geschaffen. Sie enthält zehn An- forderungen, die eine Lizenz für offene Software erfüllen muss, um als Open Source Lizenz zertifiziert zu werden (Open Source Initiative, 2006). Grundlegend unterschei- den sich die Definitionen von „freier Software“ und Open Source Software nur mar- ginal. Der Unterschied ist hauptsächlich im Eigenverständnis und der Auslegung der Begriffe begründet und soll hier nicht weiter ausgeführt werden (von Hippel, 2005, Seiten 98-99). In dieser Arbeit soll der Begriff Open Source einheitlich für freie und offene Software verwendet werden, da eine Differenzierung für die hier betrachteten Zusammenhänge nicht relevant ist. Wesentliche Abgrenzungsmerkmale der Open Source Software von kommerziellen Produkten stellen die Offenlegung des Quell- codes, die Kostenfreiheit der Softwarelizenz und das Verbot jeglicher Beschränkung der Nutzung in Verbindung mit anderer Soft- oder Hardware dar. Im Gegensatz dazu existieren Softwarealternativen wie Shareware, bei der unbeschränkt oder zeitlich li- mitiert der Binärcode der Software kostenfrei zur Verfügung gestellt wird, oder auch public domain Software, deren Quellcode keinerlei Restriktionen untersteht (Lerner und Tirole, 2000). Die verschiedenen Softwarearten unterscheiden sich jedoch nicht nur in der Form ihrer Bereitstellung, sondern auch bezüglich des Nutzerkreises, der die Software einsetzt. Dabei ist ein starkes Gefälle zwischen Spezialsoftware und An- wendersoftware zu verzeichnen. Ist der Marktanteil kommerzieller Software im Be- reich der Anwendersoftware noch sehr hoch, so veröffentlichte der Internetstatistiker Netcraft für den Apache Webserver im Oktober 2006 einen Marktanteil von 61,44%. Eine verstärkte Verbreitung von Open Source Produkten findet aufgrund steigender Benutzerfreundlichkeit, durch beispielsweise vereinfachte Nutzung dank intuitiv be- dienbarer GUIs, auch im Bereich der Anwendersoftware statt. Als Beispiele lassen sich hier erfolgreiche Projekte wie den Browser Firefox (2006) oder das im Bereich der Bürosoftware angesiedelte OpenOffice.org (2006) anführen.

2.2. Lizenzmodelle in der Open Source Entwicklung

Im Laufe der Weiterentwicklung der Open Source Bewegung haben sich, neben den Definitionen freier und offener Software, sowohl weitere Anforderungsmodelle wie auch eine Vielzahl unterschiedlicher Lizenzen ergeben. Neben den als klassisch be- zeichneten Lizenzen wie General Public License (GPL), Lesser General Public Licen- se (LGPL) und der BSD-Lizenz, haben sich zahlreiche „neue“ Lizenzen entwickelt. Oftmals gestalten große Open Source Projekte ihre Lizenzen entsprechend den Vor- stellungen der Initiatoren und verwenden hierfür die vorgegebenen Standards der OSD. Durch die erfolgreiche Verbreitung des Browsers Firefox wurde die hierfür ge- nutzte Lizenz Mozilla Public License (MPL) bekannt und fand auch über das Mo- zilla Projekt hinaus Anwendung. So nutzte Sun für die Lizenzierung von OpenSola- ris die MPL als Grundlage ihrer eigenen Lizenz COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) (Sun Microsystems, 2006). Obwohl sich die ein- zelnen Lizenzen in ihrer Ausgestaltung stark unterscheiden können, stimmen sie in den grundlegenden Punkten meist überein, um so den Anforderungen mindestens einer Zertifizierungsrichtlinie zu genügen. So entsteht für Anwender und Entwick- ler ein klares Bild hinsichtlich der Möglichkeiten und Grenzen einer Software. Eine grundsätzliche Unterscheidung kann man bei Lizenzen im Bereich von Restriktionen bei der Weiterverarbeitung machen. Lerner und Tirole (2002) haben eine Einteilung in die folgenden drei Klassen nicht restriktiv (bspw. BSD-Lizenz), restriktiv (bspw. LGPL) und sehr restriktiv (bspw. GPL) vorgenommen. So gehört die GPL zu den so genannten „viralen“ Softwarelizenzen. Diese enthalten Klauseln, dass jegliche Ver- öffentlichung, die unter Verwendung eines GPL-lizenzierten Quellcodes geschieht, wieder unter der GPL-Lizenz veröffentlicht werden muss. Diese Restriktion sorgt da- für, dass der Grad der Freiheiten bei der Weiterverarbeitung des Quellcodes nicht verändert wird. Ebenso verhindert eine solche Bestimmung die Verarbeitung des Co- des in kommerzieller Software und damit das Ausnutzen freier Entwickler für das Erstellen kommerzieller Softwarelösungen (Lerner und Tirole, 2002).

2.3. Die Open Source Community

Die Unterschiede in der Entwicklung zwischen kommerzieller und Open Source Soft- ware könnten nicht größer sein. Die Bestrebung der Hersteller kommerzieller Softwa- re war immer, Nutzern ein möglichst fehlerfreies und komplettes Produkt auf dem Markt anzubieten. Der Quellcode stellt dabei meist ein Betriebsgeheimnis dar, was einen Wettbewerbsvorteil gegenüber der Konkurrenz sichern soll. Torvalds sagte ein- mal von sich selbst „I’m basically a very lazy person who likes to get credit from things other people actually do“ (Raymond, 1999). Nach diesem Satz handelte Tor- valds nach der Entwicklung des Linux-Kerns und veröffentlichte Anfang der 90er Jahre seine bisherigen Ergebnisse. Seine Vorgehensweise bei der Entwicklung sah ei- ne möglichst frühe und häufige Veröffentlichung des Programms vor, um die große Anzahl interessierter Entwickler zu nutzen, die sowohl Fehler im Quellcode schnell aufdecken konnten als auch Verbesserungen ihrerseits durchführten. Diese Art der Entwicklung wurde später von Eric Raymond als „bazaar style“ bezeichnet und stellt den Gegensatz zur Entwicklung einer „Kathedrale“ dar, womit Raymond eine Soft- ware bezeichnete, die möglichst im gewünschten Endzustand veröffentlicht wird. In seinem Buch „The Cathedral and the Bazaar“ beschreibt Raymond anschaulich die Entstehung der heute am meisten genutzten Form der Softwareentwicklung im Be- reich der OSS, welche heute als Community bezeichnet wird. Eine Community stel- len zunächst alle Entwickler dar, die sich an einem OSS-Projekt beteiligen und dank der Kommunikation über das Internet über die gesamte Welt verteilt sein können. Die Struktur einer Community ist in der Regel nicht hierarchisch, was keine Existenz direkter Weisungsbefugnisse oder Entscheidungskompetenzen bedeutet. Aus organi- satorischen Gründen werden die Mitglieder in Gruppen unterteilt. Jeder Gruppe fällt eine bestimmte Rolle zu, die jedoch lediglich zur Vereinfachung von Prozessen dient und gleichzeitig den sozialen Status innerhalb der Community zeigt (Ye und Kishida, 2003, Seite 420). Aufgrund der modularen Struktur der Software ist es einer Vielzahl an Entwicklern möglich, gleichzeitig und unabhängig das bisher bestehende Projekt zu erweitern, Fehler zu beseitigen und den Code zu verbessern. Uneingeschränkt ist die Entwicklung von OSS innerhalb einer Community jedoch nicht. Die Beobachtun- gen von Raymond (1999) zeigen, dass der Kern einer Software bereits vorhanden sein muss, um diesen erfolgreich in einer Community zu veröffentlichen und weiterent- wickeln zu lassen. Welche Gründe einen Entwickler animieren, sich an einem Open Source Projekt zu beteiligen wird in zahlreichen Studien untersucht, was im Folgen- den aufgezeigt werden soll.

2.4. Warum in einer Open Source Community entwickelt wird

Die zunehmende Entwicklung von Open Source Software in Communities beschäf- tigt die unterschiedlichsten Bereiche der Wissenschaft. Speziell die Frage, warum überhaupt eine Entwicklung in Open Source Communities stattfindet, wird in einer Vielzahl von Studien aufgegriffen. Um einen Überblick über die Entwicklung in Open Source Communities zu geben, wird diese Fragestellung nun aus sozialwissenschaft- licher, betriebswirtschaftlicher und volkswirtschaftlicher Sicht näher betrachtet.

2.4.1. Sozialwissenschaftliche Betrachtung

Die Mehrzahl der in Communities tätigen Entwickler üben diese Tätigkeit auf frei- williger Basis aus und nutzen dafür ihre Freizeit. Jeder Entwickler, der sich ohne mo- netären Ausgleich eines Arbeitgebers engagiert, investiert die Opportunitätskosten der aufgewendeten Zeit für diese Tätigkeit (Lakhani und von Hippel, 2000). In ei- ner Studie zeigen Hertel et al. (2003) anhand des Modells der Teilnahme an sozialen Bewegungen (in Anlehnung an Klandermans (1997)) und einer eigenen Erweiterung des VIST-Modells, zur Beschreibung der Motivation von Individuen in Teams, wel- che Motive Entwickler haben, sich an Open Source Projekten zu beteiligen. In der Untersuchung werden zwei maßgebliche Gründe für eine Beteiligung an einem Open Source Projekt definiert. Zum einen werden Entwickler durch intrinsische Motivation (Spaß an der Programmierung) und die Herausforderung, bestehende Software für eigene Bedürfnisse anzupassen, angetrieben. Zum anderen spornt der Wettbewerb mit anderen Entwicklern oder anderen Softwareprojekten zur Aktivität an. Abgelei- tet aus dem Wettbewerb untereinander erfahren Entwickler bei erfolgreicher Betei- ligung an Open Source Projekten eine Steigerung ihres Ansehens. An diesem Punkt setzt auch die Annahme indirekter monetärer Anreize an, indem ein gesteigertes An- sehen als Entwickler mit einer möglichen besseren Bezahlung im Beruf verknüpft wird (Ljungberg, 2000; Lerner und Tirole, 2002). Roberts et al. (2006) definieren diese Art von Motivation als klassisch extrinsisch, wobei explizit auf eine mögliche Inter- nalisierung hingewiesen wird, durch die ein Akteur den Grad der Motivation selbst beeinflussen kann. Anerkennung für die geleistete Arbeit erfährt ein Entwickler bei- spielsweise durch die mögliche Veränderung seiner sozialen Stellung innerhalb der Community. Dies geschieht durch die Eingruppierung in eine soziale Gruppe, die durch ihren Status zwar keine Rechte besitzt, sich aber von anderen Gruppen in- nerhalb der Community abheben kann (von Hippel und von Krogh, 2003). Einen weiteren entscheidenden Aspekt der Beteiligung stellt das Gefühl der Gruppenzu- gehörigkeit dar. Ein Entwickler, der eine innovative Idee umsetzen möchte, findet innerhalb der Community Unterstützer für sein Vorhaben, die ihn entweder direkt oder durch ihre persönlichen Kontakte innerhalb und außerhalb der Community in seiner Tätigkeit bestärken (Franke und Shah, 2003, 164). Über das Motiv des Altruis- mus als Grund der Beteiligung herrscht in der gängigen Literatur eine recht eindeu- tige Meinung. Lerner und Tirole (2000, 2001) begründen ihre Zweifel am Altruismus als treibende Kraft mit einem Vergleich der (Open Source) Softwareentwicklung mit anderen Industriezweigen. Raymond (1999) entkräftet den Ansatz des Altruismus dadurch, dass er den Begriff selbst in Frage stellt. Seiner Meinung nach stellt jede Form von Altruismus gleichzeitig eine Befriedigung des Selbstwertgefühls des Han- delnden dar, was mehr auf ein berechnendes Motiv und weniger auf Selbstlosigkeit schließen lässt. Einen Teil der Softwareentwickler in Communities stellen Personen dar, die sich im Rahmen ihres Berufs an der Entwicklung beteiligen. Hierbei liegt die Entscheidung bei den Unternehmen, Mitarbeiter während der Arbeitszeit für eine Entwicklungstätigkeit in einem Open Source Projekt frei zu stellen.

2.4.2. Betriebswirtschaftliche Betrachtung

Welche Gründe aus betriebswirtschaftlicher Sicht für eine Beteiligung an einem Open Source Projekt sprechen, wird von Lerner und Tirole (2001) aufgegriffen. Durch ein gezieltes Angebot von Komplementärleistungen wie Dokumentationen, Support oder Installationsservice kann aus der weiterhin kostenfrei erhältlichen Software dennoch ein monetärer Nutzen gezogen werden. Aber auch das Schaffen von Kompatibili- tät zu kommerzieller Software oder Hardware des Unternehmens kann den Anreiz einer Entwicklungstätigkeit steigern (von Hippel und von Krogh, 2003; Lerner und Tirole, 2004). So bieten einige Unternehmen gezielt kommerzielle Produkte an, die speziell für die Nutzung in Verbindung mit bestimmten Open Source Produkten ent- wickelt wurden. Auf diese Weise stockt beispielsweise Novell die kostenfreie Linux- distribution OpenSuse auf eine kostenpflichtige Enterpriseversion auf. Da OpenSuse jedoch unter der GPL veröffentlicht wird, muss lediglich der kommerzielle Teil der Enterpriseversion bezahlt werden. Einen weiteren wichtigen Aspekt stellt der Bera- tungsbedarf der Unternehmen dar, die Open Source Produkte einsetzen. Da Dienst- leistungen wie Installationen und Schulungen von einer Community nicht angeboten werden können (Fitzgerald, 2006), haben Unternehmen, wie beispielsweise IBM, den Bereich der OSS als wesentlichen Teil in das Angebot der Unternehmensberatung aufgenommen. Die so entstehende Notwendigkeit guter Produktkenntnis fördert die Bereitschaft, sich an der Entwicklung zu beteiligen (Lerner und Tirole, 2004). Auf vie- le Unternehmen, die sich an der Entwicklung von OSS beteiligen, trifft zudem die Motivation zu, die selbst genutzte OSS zu verbessern und dabei auch von der Ar- beit anderer profitieren zu können (von Hippel und von Krogh, 2003; Gambardella und Hall, 2005). In einer aktuellen Studie untersuchen Baldwin und Clark (2006) die Einflüsse der Codestruktur einer OSS auf den Anreiz der Beteiligung am Projekt. Mit Hilfe eines spieltheoretischen Ansatzes verdeutlichten sie die Auswirkungen unter- schiedlicher Modularität einer Software und die damit zusammenspielende Größe des Option Value. Der Option Value wird dabei als Vorteil angesehen, den eine mög- liche Adaption einer neuen Codearchitektur verursacht. Eine höhere Modularität ei- ner OSS steigert den Option Value und somit auch die Attraktivität eines Projekts für Entwickler. Wie Bessen (2005) in seinen Ausführungen zeigt, gibt es einen wei- teren nachvollziehbaren Grund für Unternehmen, sich für die Entwicklung von OSS zu interessieren. Bessen sieht die OSS dann als sinnvollen Ersatz für eine kommer- zielle Lösungen, wenn diese die komplexen Bedürfnisse der Nutzer nicht erfüllen kann. Begründet wird diese Aussage anhand der Argumentation, dass der Hersteller eines kommerziellen Produkts, aufgrund der komplexen Struktur von Software, gar nicht in der Lage sein kann, alle benötigten Funktionalitäten und Schnittstellen zur Verfügung zu stellen, die ein größeres Unternehmen benötigt. Eine Anpassung an in- dividuelle Bedürfnisse gestaltet sich jedoch bei OSS wesentlich einfacher. Aus diesem Grund kann man OSS als zusätzliche Alternative in der Fragestellung „make-or-buy“ betrachten.

2.4.3. Volkswirtschaftliche Betrachtung

Bei der Betrachtung der Eigenschaften von Open Source Software zeigt sich eine weitgehende Übereinstimmung mit den Merkmalen eines öffentlichen Gutes. Die Zu- sammenhänge der Bereitstellung öffentlicher Güter durch Privatpersonen wurden in zahlreichen Untersuchungen unter anderem von Chamberlin (1974), Bliss und Nale- buff (1984) und Bergstrom et al. (1986) analysiert. Diese Werke als Grundlage, veröf- fentlichte Johnson (2002) eine Studie über die private Bereitstellung eines öffentlichen Gutes am speziellen Beispiel der Open Source Software. Johnson legt das Hauptau- genmerk seiner Betrachtung auf die Effekte einer Größenänderung der Community und vergleicht diese mit demselben Szenario für kommerzielle Software. Die Ergeb- nisse seiner Untersuchung decken sich im Wesentlichen mit den Aussagen von Bliss und Nalebuff (1984). Diese kamen zu dem Schluss, dass derjenige Entwickler das öffentliche Gut zur Verfügung stellt, der vermutet, die geringsten Kosten der Bereit- stellung zu haben. Eine Erhöhung der Mitgliederzahl erhöht die Wahrscheinlichkeit, dass ein anderer Akteur niedrigere Kosten hat und somit eine höhere Chance be- steht, sich selbst als „Free Rider“ verhalten zu können. Eine schnellere Bereitstellung aufgrund einer steigenden Anzahl von Entwickler kann jedoch nicht angenommen werden, da die Akteure in der Annahme, es könnte ein Entwickler mit niedrigeren Kosten existieren, länger warten. Ökonomisch betrachtet führt der Eintritt eines jeden neuen Entwicklers zu einer Steigerung des individuellen erwarteten Nutzens der üb- rigen Entwickler und wirkt sich insgesamt wohlfahrtssteigernd aus.

OSS befindet sich in einem ständigen Prozess der Neu- und Weiterentwicklung. Wird durch Lizenzen wie der GPL eine Veröffentlichung von Innovationen erzwungen, so geschehen diese in der Regel auch im Fall weniger restriktiver Lizenzen. Eric von Hippel und Georg von Krogh gestalteten aus den bestehenden Modellen der „pri- vaten Investition“ und des „kollektiven Handelns“ unter der Bezeichnung „Private- Collective Innovation Model“ ein Modell zur Beschreibung von Innovationsprozes- sen in Open Source Communities. Das Modell zeigt, dass die Annahmen der zugrun- de gelegten Modelle, wie beispielsweise die Entlohnung innovativer Arbeit bei der Bereitstellung öffentlicher Güter, auch in einer Open Source Community zutreffend sind. Auch wenn diese meist nicht die Form einer monetären Entlohnung haben (von Hippel und von Krogh, 2003). Eine Parallele zu Innovationsprozessen der Wissenschaft zieht Albert (2006) in einer aktuellen Studie. Er verfolgt einen Ansatz, in dem der Nutzen einer Innovation durch den Grad der Reputationssteigerung ausgedrückt wird. Dieser steigt, je häufiger die Innovation in späteren Perioden als Basis für erneute Innovationen verwendet wird.

2.5. Zielsetzung der Arbeit

Bisherige Untersuchungen der Softwareentwicklung in Open Source Communities geben über ein breites Spektrum an Fragestellungen, sowohl sozialwissenschaftli- cher als auch volks- und betriebswirtschaftlicher Natur, Aufschluss. In vielen dieser Bereiche haben diverse Studien bereits sehr konkrete Ergebnisse geliefert. Wurden im volkswirtschaftlichen Bereich vergleichsweise viele Betrachtungen durchgeführt, so lässt das Feld der Beteiligung von Unternehmen auf betriebswirtschaftlicher Ebe- ne noch einige Fragen ungeklärt. Aufbauend auf den Aussagen von Bessen, kann man davon ausgehen, dass der Einsatz von OSS in Unternehmen zukünftig an Be- deutung gewinnen wird. In der gängigen Literatur findet sich jedoch keine Betrach- tung, die genauer darauf eingeht, ob oder in welchem Umfang sich Unternehmen für die Entwicklung in einer Community entscheiden. Um über das Verhalten von Unternehmen in Open Source Communites konkrete Aussagen treffen zu können, wird in dieser Arbeit ein Modell entwickelt, das über den Umfang der Beteiligung eines Unternehmens in einer Open Source Community Aufschluss geben kann. Zu diesem Zweck wird im Folgenden der Prozess der Softwareentwicklung innerhalb einer Community in einem spieltheoretischen Modell abgebildet. Das entstehende Modell soll dabei eine zeitlich flexible Struktur besitzen und so in der Lage sein, Ent- wicklungsprozesse mit unterschiedlichen Laufzeiten darzustellen. Wie Baldwin und Clark (2006) in ihrer Arbeit gezeigt haben, spielt die Architektur einer Software ei- ne wesentliche Rolle für deren Eignung, in einer Community entwickelt zu werden. In Anlehnung an die Ergebnisse der beiden Autoren soll die Abbildung der Struk- tur einer Software auch bei der Erstellung dieses Modells Anwendung finden. Ziel des Modells ist es, die ausschlaggebenden Faktoren für eine Entwicklungstätigkeit in der Community zu identifizieren, deren Zusammenhänge und die Wirkungsweise zu erläutern, sowie eine Aussage über die Wahrscheinlichkeit der Fertigstellung einer Open Source Software treffen zu können.

3. Das spieltheoretische Modell

Die Erstellung des spieltheoretischen Modells soll im Folgenden in mehreren Schrit- ten erfolgen. Im ersten Schritt findet die Aufstellung eines Grundmodells statt, wel- ches die grundlegenden spieltheoretischen Zusammenhänge beschreiben soll. In zwei Erweiterungen wird das Grundmodell angepasst, bis alle gewünschten Anforderun- gen abgebildet werden.

3.1. Modellannahmen

Zunächst werden für die Entwicklung des Modells die allgemeinen Annahmen ge- troffen, die in allen Schritten unverändert Bestand haben. Im Anschluss daran wer- den zusätzliche Annahmen getroffen, welche je Erweiterung angepasst und ergänzt werden.

Allgemeine Annahmen

Zur Betrachtung der Abläufe in einem spieltheoretischen Modell ist es notwendig, die beteiligten Spieler zu identifizieren. Diese entsprechen zwei Unternehmen und werden im Modell als Akteure bezeichnet. Die Beschränkung auf zwei Akteure wird vorgenommen, um das Modell nicht zu komplex werden zu lassen.

A 1. Betrachtet wird eine existierende Open Source Software, welche von zwei Ak- teuren (j, −j) sowohl entwickelt als auch eingesetzt wird.

Da keines der Unternehmen zu einer Entwicklung innerhalb der Community verpflichtet ist, entsteht ein Spiel, dessen Ausgang von der Entscheidung der beiden beteiligten Akteure abhängt. Die Möglichkeit der Absprache ist für die Unternehmen nicht gegeben, was bedeutet, dass keines der Unternehmen zum Entscheidungszeitpunkt Kenntnis über die Entscheidung des Anderen hat. Aus diesem Grund kann folgende Annahme getroffen werden.

A 2. Beide Akteure j besitzen dieselben Handlungsalternativen sjk ∈ S, mit den Aus- prägungen k = 1 (entwickeln) und k = 2 (nicht entwickeln). Diese werden in der Strategiemenge S zusammengefasst. Den Akteuren ist zum Entschei- dungszeitpunkt nicht bekannt, welche der Handlungsalternativen der Andere gewählt hat (Zustand imperfekter Information).

Sowohl eine Beteiligung als auch eine Nichtbeteiligung an der Open Source Entwick- lung verursachen den Akteuren Auszahlungen. Diese Auszahlungen hängen nicht nur von der eigenen Entscheidung, sondern auch von der Wahl des zweiten Beteilig- ten ab. Beide Akteure streben ein möglichst niedriges Niveau der Auszahlungen an. Als Maß des Nutzens, den die Akteure haben, kann daher die entstehende Auszah- lung herangezogen werden.

A 3. Der Nutzen uj(sjk, s−jk) einer Kombination von Handlungsalternativen wird durch den Barwert der verursachten Auszahlungen AZjI(sjk,s−jk) · δt ausge-

drückt, wobei δt = it dem Zinssatz i > 0 ist. Der Gesamtnutzen Uj eines (1+i)tm Entscheidungspfades wird durch die Summe aller abgezinsten Zahlungen des Pfades PVjI =∑t AZjI(sjk,s−jk) · δt repräsentiert.

In der Realität ist die Existenz identischer Unternehmen sehr unwahrscheinlich. In der Regel bestehen bei einem Vergleich beispielsweise Unterschiede im organisato- rischen Aufbau oder der Größe der Unternehmen. Um die Komplexität des Modells einzuschränken, werden die hier betrachteten Unternehmen hinsichtlich ihrer Aus- zahlungen und ihres Kalkulationszinssatzes als identisch angenommen. Zudem wird davon ausgegangen, dass die Unternehmen eine neutrale Einstellung bezüglich der Sicherheit einer Auszahlung haben. Die Abbildung dieser Anforderungen führt für das Modell zu folgenden Annahmen.

A 4. Die beteiligten Akteure kennen sowohl ihre eigenen als auch die Auszahlungen des zweiten Akteurs (vollkommene Information).

A 5. Die Akteure verhalten sich bei der Wahl einer Handlungsalternative risikoneu- tral und besitzen keine Risikopräferenzen.

Für die genutzte Software steht eine Weiterentwicklung an, die für den reibungslosen Einsatz der Software von erheblicher Bedeutung ist. Da das Modell nicht ausschließ- lich auf die Betrachtung einer Erweiterung ausgelegt sein soll, wird diese im Modell als Software bezeichnet. Die Annahme der Erweiterung erfolgt aufgrund der Feststel- lung von Raymond (1999), dass eine Software nur dann sinnvoll in einer Community entwickelt werden kann, wenn die Voraussetzung eines bereits entwickelten Kerns gegeben ist. Welche Art von Software im Modell entwickelt wird, ist unerheblich, da es sich in keinem Fall um die initiale Entwicklung eines Softwarekerns handelt.

Solange die Software nicht zur Verfügung steht, ergeben sich für die Akteure Auszahlungen, welche die Aufrechterhaltung des laufenden Betriebs sichern.

A 6. Für jede Periode, in der die Weiterentwicklung noch nicht fertig gestellt ist, entstehen den Akteuren Auszahlungen in Höhe von w > 0. Die entwickelte Software wird nach Fertigstellung sofort frei zur Verfügung gestellt und kann unmittelbar bei beiden Akteuren eingesetzt werden.

Häufig tritt der Fall ein, dass Unternehmen in ihrer IT-Projektplanung ein Zeitfenster einrichten, in dem ein bestimmtes Projekt abgeschlossen sein muss. Für die hier betrachteten Unternehmen wird ebenfalls angenommen, dass die Kapazitäten, die für eine mögliche Beteiligung an der OSS-Entwicklung zur Verfügung stehen, nicht unbeschränkt frei gehalten werden können. Die Akteure besitzen einen Zeitpunkt, ab dem sie keine weitere Möglichkeit haben, sich an einer Entwicklung in der Community zu beteiligen. Aufgrund der Annahme identischer Akteure gibt es für das gesamte Spiel nur einen solchen Zeitpunkt.

A 7. Der Zeitpunkt tmax bezeichnet den spätesten Zeitpunkt, an dem die Software entwickelt sein muss und stellt zudem die maximale Anzahl der Betrachtungs- perioden dar.

Wie im vorhergehenden Kapitel disktutiert, gibt es eine Vielzahl unterschiedlicher Softwarelizenzen. In diesem Modell wird davon ausgegangen, dass die bereits eingesetzte Software unter einer restriktiven Softwarelizenz, wie bspw. der GPL, veröffentlicht wurde, welche die Entwickler dazu zwingt, im Falle einer Weiterentwicklung, diese unmittelbar veröffentlichen zu müssen.

A 8. Die entwickelte Software wird nach Fertigstellung umgehend veröffentlicht und kann unmittelbar von beiden Akteuren eingesetzt werden.

Da sich die Akteure in einer Spielsituation befinden, ist eine Fertigstellung der Software nicht gewährleistet. In diesem Fall müssen beide Unternehmen das bestehende Problem anderweitig lösen. Da eine weitere Entwicklung ausgeschlossen ist, bleibt nur der Kauf einer kommerziellen Lösung.

A 9. Falls die Software bis zum Zeitpunkt tmax nicht vollständig entwickelt ist, fallen jedem Akteur zusätzliche Auszahlungen in Höhe von r > 0 an.

Weitere Annahmen

Zur Aufstellung des Grundmodells werden die allgemeinen Annahmen um die Folgenden erweitert. Diese zusätzlichen Annahmen finden nur für den aktuellen Entwicklungsschritt des Modells Anwendung und werden im Verlauf der Arbeit an die jeweiligen Erweiterungen angepasst.

Beide Akteure sind mit ihrer Entscheidung in der Lage, Einfluss auf den Ausgang des Spiels zu nehmen. Je nachdem welche Kombination von Handlungsalternativen entsteht, verändert sich die Auszahlungshöhe, die ein Akteur zu tragen hat. Alle rele- vanten Auszahlungen, die direkt mit der Entscheidung für eine Entwicklung verbun- den sind, werden unter dem Begriff der Entwicklungsauszahlung zusammengefasst.

A 10. Die relevanten Auszahlungen für die Entwicklung sind konstant und betragen e > 0 pro Entwicklungsperiode.

Die Entscheidung beider Akteure, sich an der Entwicklung zu beteiligen, erlaubt ihnen aufgrund von Synergien einen Teil der Auszahlungen einzusparen.

A 11. Beide Akteure haben die Information, dass sich bei einer Beteiligung beider an der Entwicklung die jeweiligen Entwicklungsauszahlungen e um bis zu 50 % verringern können. Dies wird durch e · x mit x ∈ [0, 5; 1] ausgedrückt.

A 12. Jeder der Akteure benötigt für die Fertigstellung der Software eine Periode.

3.2. Das Grundmodell

Das Grundmodell dient dazu die Zusammenhänge der Entwicklung in einer Open Source Community spieltheoretisch darzustellen. Um die Grundzüge des Spiels zu erläutern, wird die maximale Entwicklungsdauer zunächst auf eine Periode festge- setzt. So ergibt sich für tmax = 1 eine einperiodige Betrachtung, wie sie in Abbil- dung 3.1 dargestellt ist. Die Darstellung des Spiels in einer Baumstruktur wird als extensive Form bezeichnet. Hierbei werden alle Kombinationen von Handlungsal- ternativen als Pfade dargestellt, die jeweils in einem Knoten enden. Es werden im Laufe der Modellerstellung mehrere Variablen definiert, die einen einheitlichen Index besitzen. Der Index I stellt den gewählten Pfad dar, der durch die Kombination zwei- er Handlungsalternativen beschrieben wird und eine Länge von n ∈ [1, tmax ] hat. Aus Vereinfachungsgründen werden für die Indizierung die Kombinationen (sjk, s−jk) durch Zahlen gemäß Abbildung 3.1 ersetzt. Jede Periode eines Spiels besitzt demnach vier mögliche Pfade, die jeweils in einem Knoten h ∈ (1, 4) enden. Der Knoten zu Beginn der Betrachtung wird mit 0 gekennzeichnet. Im Index werden zwei Knoten durch ein „-“ voneinander getrennt(¹ ).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Einperiodige Betrachtung

Beide Akteure sehen sich der Situation gegenüber, sich entweder für oder gegen eine Entwicklung entscheiden zu müssen. Die Wahl einer solchen Handlungsalternative wird in der Spieltheorie als „reine Strategie“ bezeichnet. Laut Annahme 4 kennen beide Akteure ihre eigenen Auszahlungen sowie die Auszahlungen des Anderen. Im Fall der gemeinsamen Entwicklung können beide Akteure sicher sein, dass sie die Software nach Ende der Entwicklungszeit von einer Periode sofort einsetzen kön- nen und dabei nur den x-ten Teil der alleinigen Entwicklungsauszahlungen inves- tiert haben. Nach einer Periode besteht für keinen der beiden Akteure eine weitere Möglichkeit, die Software zu entwickeln.Es werden sich beide Akteure in der Spiel- situation bemühen, ihren Nutzen uj(sjk, s−jk) zu maximieren. Laut Annahme 3 auf Seite 14 geschieht dies durch die Minimierung der Gesamtauszahlungen. In einem Spiel mit zwei Akteuren hängt die Höhe der Auszahlungen in der Regel von der Wahl beider Beteiligten ab. Verursacht eine Handlungsalternative sjk ein Nutzenni- veau uj(sjk), welches, unabhängig von der Wahl des Akteurs −j, immer höher ist als das bei Wahl der anderen Handlungsalternative, so bezeichnet man die Wahl dieser Handlungsalternative als dominante Strategie. Die zweite mögliche Handlungsalter- native wird hingegen als dominierte Handlungsalternative bezeichnet. Für das in Ab- bildung 3.1 dargestellte Spiel würde dies bedeuten, dass die Auszahlungen eines Teil- baumes immer kleiner sind (dominante Handlungsalternative) als die Auszahlungen des Anderen (dominierte Handlungsalternative). Existiert keine dominante Strategie, so müssen die Akteure für die optimale Wahl ihrer Handlungsalternative Vermutun- gen über die Wahl des Anderen anstellen. Aufgrund dieser Vermutungen wird die Handlungsalternative s∗jk gewählt,welchedieniedrigstenAuszahlungenverspricht und als beste Antwort gj(s∗−jk) = s∗ jk aufdievermeintlichgewählteHandlungsal- ternative s−jk des Akteurs −j bezeichnet wird. Für die beste Antwort gilt, dass das erreichte Nutzenniveau immer höher ist als bei Wahl einer anderen Handlungsalter- native, was bedeutet, dass uj(s∗jk) > uj(sjk) zutreffen muss. Wie hier deutlich wird, ist die Wahl einer dominanten Strategie, falls vorhanden, immer die beste Antwort auf jede gewählte Handlungsalternative des Anderen. Wählen beide Akteure jeweils die beste Antwort auf die vermutete Wahl des Anderen und sind die verursachten Auszahlungen immer niedriger als bei Wahl einer anderen Handlungsalternative, so entsteht ein Nashgleichgewicht. Formal bedeutet dies, dass die von der Handlungs- alternative s∗jk verursachtenAuszahlungenAZI(sjk) niedriger sind als die Auszah- lungen aller anderen Handlungsalternativen. Der Vergleich des Nutzenniveaus muss sich bei Existenz eines Nashgleichgewichts entsprechend der Formel 3.1 verhalten (Fudenberg und Tirole, 1995, Seite 13).

Abbildung in dieser Leseprobe nicht enthalten

Im Nashgleichgewicht stellen die optimalen Handlungsalternativen wechselseitig bes- te Antworten auf die optimale Strategie des Anderen dar, s∗jk = gj(s∗ −jk).Umden angenommenen Fall auf die Existenz eines Nashgleichgewichts zu überprüfen, wird für das Spiel, das bisher in der extensiven Form betrachtet wurde, nun die Normal- form gewählt. Hierbei werden die Auszahlungen, wie in Tabelle 3.1 dargestellt, in einer Matrix abgebildet. Daraus ergibt sich beide Akteure eine minimale Auszahlung im Fall einer Entwicklungstätigkeit des Anderen, bei eigener Nichtentwicklung. Wie in der Auszahlungsmatrix in Tabelle 3.1 ersichtlich, hängt die Existenz einer domi- nanten Strategie vom Verhältnis der Parameter e und r ab. Für den Fall e > r ergibt sich die dominante Strategie, immer die Handlungsalternative sj2 zu wählen. Für den umgekehrten Fall von e < r existiert keine dominante Strategie. Bei Existenz einer dominanten Strategie entsteht das Nashgleichgewicht eindeutig für die Kombination der Handlungsalternativen (sj2, s−j2) . Falls keine dominante Strategie identifiziert werden kann, ergibt sich ein Nashgleichgewicht sowohl bei (sj2, s−j1) als auch bei (sj1, s−j2), was bei Betrachtung reiner Strategien keine eindeutige Aussage über den Verlauf des Spiels zulässt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Auszahlungsmatrix für einen einperiodigen Spielbaum

Um dennoch eine eindeutige Lösung herbeizuführen, findet das Konzept gemischter Strategien Anwendung. Gemischte Strategien stellen die Wahrscheinlichkeitsvertei- lung über die Menge aller Handlungsalternativen sjk der reinen Strategien eines Ak- teurs j dar. Die Verwendung gemischter Strategien führt zu einer Konvexifizierung der Strategiemenge, was das Entstehen eines eindeutigen Gleichgewichts zur Folge hat (Holler und Illing, 1996; Harsanyi et al., 1988). Für den Einsatz gemischter Strate- gien muss zunächst die Wahrscheinlichkeitsverteilung bestimmt werden, die auf die reinen Strategien angewandt werden soll. Zur Bestimmung des Nashgleichgewichts bei Verwendung gemischter Strategien müssen die Bedingungen für Nashgleichge- wichte gemäß Formel 3.1 weiterhin gelten. Daher muss die Wahrscheinlichkeitsver- teilung sicherstellen, dass auf die Strategie des zweiten Akteurs immer die beste Ant- wort gewählt wird. Dies trifft zu, wenn sich der Akteur durch die Wahl einer an- deren Handlungsalternative nicht verbessern könnte, was wiederum dann der Fall ist, wenn alle Handlungsalternativen dasselbe Nutzenniveau erzeugen. Damit muss uj(sj1) = uj(sj2) gelten, was bedeutet, dass der Akteur zwischen den Handlungsalter- nativen indifferent ist. Um diese Bedingung zu erfüllen, müssen die erwarteten Aus- zahlungen der beiden Handlungsalternativen gleich hoch sein. Welche Auszahlung bei Wahl einer Handlungsalternative jedoch realisiert wird, hängt maßgeblich von der Wahl des zweiten Akteurs ab. Um eine Aussage über die Verteilung des Akteurs j treffen zu können, sind für diesen die Auszahlungen des Akteurs −j maßgeblich, da diese direkten Einfluss auf dessen Strategie haben. Die Auszahlungen des Akteurs −j werden deshalb gegenüber gestellt und mit dem Parameter λjI gewichtet(Fudenberg und Tirole,¹⁹⁹⁵ ; Gintis,²⁰⁰⁰ ; Harsanyi et al.,¹⁹⁸⁸ ). Aus diesem Zusammenhang lässt sich der Parameter λjI ableiten.GemäßAnnahme² stehendenAkteurennurzwei Handlungsalternativen zur Verfügung, was eine eindeutige Zuordnung von λjI zur Handlungsalternative sj1 (entwickeln) sowie der Gegenwahrscheinlichkeit (1 − λjI) zur Handlungsalternative sj2 (nicht entwickeln) ermöglicht. λjI wirddaherfürden weiteren Gebrauch auch als Entwicklungswahrscheinlichkeit bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.2: Allgemeine Auszahlungsmatrix

Aufgrund der Annahme zweier identischer Akteure, welche dieselben Auszahlun- gen besitzen, müssen folglich auch die Entwicklungswahrscheinlichkeiten der bei- den übereinstimmen, λj =λ−j. Tabelle 3.2 stellt die Auszahlungsmatrix der Akteure in allgemeiner Form dar. Anhand der Auszahlungsmatrix in Tabelle 3.2 kann in Anlehnung an Fudenberg und Tirole (1995, Seite 19f) sowie Gintis (2000, Seite 56ff) zur Berechnung von λjI desAkteursjFormel 3.2 aufgestelltwerden.

Abbildung in dieser Leseprobe nicht enthalten

Wendet man die allgemeine Formel für λjI aufdasinAbbildung 3.1 aufSeite¹⁷ dargestellte Spiel an, so erhält man λjI = r−er−e+e·x.WieanhanddieserFormeldeut- lich wird, ist λjI nichtuneingeschränktberechenbar.EinegenauereBetrachtungzeigt, dass Formel 3.2 nur dann für die Berechnung von λjI herangezogenwerdenkann, wenn kein Zustand dominanter Strategien vorliegt. Dies bedeutet für die Bestim- mung des Parameters λjI,dassjedeSpielsituationzuerstaufdieExistenzdominanter Strategien überprüft werden muss, bevor λjI berechnetwerdenkann.Betrachtetman das Konzept der gemischten Strategien näher, so kann man ableiten, dass die Zu- stände dominanter Strategien einen Spezialfall der gemischten Strategien darstellen. Dominiert eine Handlungsalternative eindeutig alle weiteren, so wird mit Sicherheit die dominante Handlungsalternative gewählt. Für den Fall, dass sj1 die dominante Handlungsalternative darstellt, kann man bei Anwendung gemischter Strategien die Wahrscheinlichkeitsverteilung über die Handlungsalternativen (sj1,sj2) mit (1,0) be- schreiben. Durch dieses Vorgehen ist die Anwendung gemischter Strategien uneinge- schränkt möglich. Zur Bestimmung des Wertes für λjI wirddieExistenzdominanter Strategien mit Hilfe eines Axiomensystems identifiziert. Dafür werden die folgenden drei Axiome verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Axiom A dient der Überprüfung, ob ein Akteur in einer Auszahlungsmatrix unabhängig von seiner eigenen Entscheidung dieselben Auszahlungen erhält. Erfüllt eine Matrix das Axiom A so besteht vollkommene Indifferenz.

Abbildung in dieser Leseprobe nicht enthalten

Axiom B dient der Überprüfung, ob die Wahl der Handlungsalternative sj1 eine dominante Strategie darstellt.

Abbildung in dieser Leseprobe nicht enthalten

Axiom C dient der Überprüfung, ob die Wahl der Handlungsalternative sj2 eine dominante Strategie darstellt.

Die Erfüllung von Axiom A stellt einen Ausnahmefall dar, der in der Spieltheorie für gewöhnlich nicht auftritt. In diesem Modell soll der Spezialfall aufgrund der fol- genden Überlegung in die Anwendung gemischter Strategien integriert werden. Er- füllt eine Auszahlungsmatrix das Axiom A so sind beide Akteure vollkommen in- different in ihrer Entscheidung. Für eine Auszahlungsmatrix dieser Art lassen sich insgesamt vier Nashgleichgewichte identifizieren. Die Berechnung eines Gleichge- wichts bei Anwendung gemischter Strategien ist aus mathematischen Gründen nicht möglich. Durch die Indifferenz existiert auch keine dominante Strategie. Ein Akteur wählt also vollkommen zufällig eine reine Strategie, da alle Handlungsalternativen gleich gut sind. Dieses Verhalten kann bei Anwendung gemischter Strategien durch eine Entwicklungswahrscheinlichkeit von 0,5 ausgedrückt werden, da hierbei beide Handlungsalternativen mit derselben Wahrscheinlichkeit gewählt werden.

Abbildung in dieser Leseprobe nicht enthalten

Die Berechnung von λjI mitHilfevonFormel³.³ ermöglichtes,einenSpielbaumein- heitlich mit gemischten Strategien behandeln zu können. So wird bei der weiteren Betrachtung immer von der Anwendung gemischter Strategien ausgegangen, wobei das Auftreten dominanter Strategien als Spezialfall mit Hilfe obiger Formel abgebil- det wird.

Die Anwendung gemischter Strategien ist nicht frei von Kritik. Eine zentrale Frage- stellung ist dabei häufig, ob ein Akteur in einem Spiel die gemischten Strategien als geeignetes Mittel zur Entscheidungsfindung ansieht (Holler und Illing,¹⁹⁹⁶, Seite ⁶⁹ ). Der Kritikpunkt bezieht sich vor allem auf die Anwendung eines Zufallsmecha- nismus zur Bestimmung der zu wählenden Handlungsalternative. Im hier betrachte- ten Modell wird angenommen, dass es sich um zwei vollkommen rational agieren- de Akteure handelt, die sich laut Annahme³ auf Seite¹⁴ nur aufgrund der entste- henden Nutzenwerte entscheiden. Somit spielen emotionale Aspekte einer Entschei- dung, wie beispielsweise die persönliche Befriedigung bei erfolgreicher Beteiligung an der Entwicklung, ein gesteigertes Ansehen oder etwa eine Auswahl des Softwa- reprojekts nach persönlichen Präferenzen, keine Rolle. Wie die bisherige Betrachtung gezeigt hat, ist die Anwendung gemischter Strategien eine plausible und sinnvolle Möglichkeit, aufgrund rationalen Verhaltens ein eindeutiges Nashgleichgewicht her- beizuführen. Auch wenn die Anwendung anderer Strategien denkbar wäre, soll in dieser Arbeit zugunsten der komplexen Betrachtung des Spiels auf den Vergleich un- terschiedlicher Strategien verzichtet werden.

Die Berechnung der Entwicklungswahrscheinlichkeiten lässt nun eine Aussage über das Erreichen der einzelnen Pfade und die damit verbundenen Auszahlungen zu. Die Wahrscheinlichkeit, eine bestimmte Kombination von Handlungsalternativen zu er- reichen, ergibt sich, wie in Tabelle 3.3 dargestellt, als Produkt der Wahrscheinlichkei- ten, mit denen die Akteure die entsprechende Handlungsalternative wählen. Zur Ver- deutlichung des Zustandekommens der Wahrscheinlichkeit, eine bestimmte Kombi- nation von Handlungsalternativen zu erreichen, wurde in Tabelle 3.3 nochmals auf die ursprüngliche Notation je einer Entwicklungswahrscheinlichkeit pro Akteur zu- rückgegriffen. Unter gegebenen Annahmen gilt weiterhin, dass λj = λ−j ist. Für die weiteren Betrachtungen der Arbeit bezeichnet λjI deshalbdieEntwicklungswahrscheinlichkeit der Akteure j und −j.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.3: Wahrscheinlichkeiten der Handlungsalternativen

Anhand der Variablen λjI kannnuneineAussageüberdieWahlderzurVerfügung stehenden Handlungsalternativen getroffen werden. Die Entwicklungswahrschein- lichkeit gibt jedoch keinen Aufschluss darüber, mit welcher Wahrscheinlichkeit die Software tatsächlich fertig gestellt wird. Diese Information stellt für die Akteure eine wesentliche Aussage über das Spiel dar. Aus diesem Grund wird die bisherige Be- trachtung um eine aggregiertere Sicht erweitert, indem die Größe ΨI eingeführt wird. Diese gibt über die Fragestellung Aufschluss, wie hoch die Wahrscheinlichkeit ist, dass die Software unter gegebenen Parametern tatsächlich fertig gestellt wird. Hier- für werden die Eintrittswahrscheinlichkeiten der Kombinationen von Handlungsal- ternativen, in denen die Software entwickelt wird, aufsummiert und können als Ge- samtenwicklungswahrscheinlichkeit der Software bezeichnet werden. Unter Zuhil- fenahme von Tabelle 3.3 kann für die Berechnung von ΨI die folgende Gleichung aufgestellt werden(2).

Abbildung in dieser Leseprobe nicht enthalten

da aufgrund der Annahme von zwei identischen Akteuren λjI =λ−jI gilt, ergibt sich ΨI = 2 · λjI −λI2 .

Da ΨI lediglich eine Aussage über die Fertigstellung, nicht aber über das dabei ent- stehende Nutzenniveau eines Akteurs trifft, wird die Betrachtung um diese Infor- mation erweitert. Anhand der gegebenen Wahrscheinlichkeiten und der Auszahlun- gen pro Kombination von Handlungsalternativen lässt sich der erwartete Barwert E(PV)jI leichtberechnen.DieserergibtsichausderabgezinstenSummederentste- henden Auszahlungen der unterschiedlichen Kombinationen von Handlungsalterna- tiven. Dabei werden die jeweiligen Auszahlungen mit der entsprechenden Eintritts- wahrscheinlichkeit der Kombination von Handlungsalternativen gewichtet.

Abbildung in dieser Leseprobe nicht enthalten

Beispielberechnung

Zur Verdeutlichung der Zusammenhänge soll an dieser Stelle für das Grundmodell eine kurze Beispielberechnung durchgeführt werden. Tabelle 3.4 zeigt die Ergebnis- variablen λj⁰,Ψ0 undE(PV)0 füreineVariationderEntwicklungsauszahlunge,so- wie der Ersparnis bei gemeinsamer Entwicklung x. Die übrigen Parameter werden mit r = 30.000, i = 5% und w = 1.500 als konstant angenommen. Das Verhältnis der Parameter zueinander wurde für dieses Beispiel so gewählt, dass keine Existenz dominanter Strategien auftritt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.4: Einperiodiges Beispiel mit w=1.500, r=30.000, i=5%

Anhand dieser Ergebnisse kann man erkennen, dass sich sowohl eine Veränderung der Entwicklungsauszahlungen als auch die Höhe der Ersparnis direkt auswirken. Mit steigenden Entwicklungsauszahlungen sinkt die Bereitschaft der Entwicklung. Auch eine Abnahme der Ersparnis bei gemeinsamer Entwicklung lässt die Entwick- lungsbereitschaft eines Akteurs sinken. Interessant ist der Zusammenhang zwischen den Entwicklungsauszahlungen und der möglichen Ersparnis bei gemeinsamer Ent- wicklung der Akteure. Aus der Tabelle wird deutlich, dass die Ersparnis lediglich einen zusätzlichen Anreiz zur Entwicklung darstellt. Selbst bei einer Ersparnis von null (x = 1), ist der Akteur, je nach Höhe der Entwicklungsauszahlungen, in hohem Maße bereit, sich an der Entwicklung zu beteiligen. Ausschlaggebend für die Beteili- gung an der Entwicklung ist also das Verhältnis von e zu r. Die Gesamtentwicklungs- wahrscheinlichkeit verändert sich durch die direkte Abhängigkeit von λj⁰ ähnlichwie die Entwicklungswahrscheinlichkeit. Die Entwicklungswahrscheinlichkeit sinkt line- ar mit steigendem e aufgrund des Zusammenhangs[Abbildung in dieser Leseprobe nicht enthalten].DerZusammen- hang zwischen Ψ0 und der Höhe der Entwicklungsauszahlung lässt sich als[Abbildung in dieser Leseprobe nicht enthalten]ausdrücken, was auf einen konkaven Verlauf hinweist. Bei steigenden Entwicklungsauszahlungen sinkt die Gesamtentwicklungswahrscheinlichkeit demnach langsamer als die Entwicklungswahrscheinlichkeit.

Anhand des Grundmodells ist es nun möglich, den Grad der Beteiligung eines Ak- teurs an der Entwicklung in der Community in Form der Entwicklungswahrschein- lichkeit zu betrachten, eine Aussage über die Fertigstellung der Software zu treffen und die Höhe der zu erwartenden Auszahlungen zu bestimmen. Das abschließende Beispiel hat gezeigt, wie sich die Entwicklungswahrscheinlichkeit, die Gesamtent- wicklungswahrscheinlichkeit und der erwartete Barwert bezüglich einer Verände- rung der Entwicklungsauszahlungen und der Ersparnis bei gemeinsamer Entwick- lung verhalten. Unabhängig von der zeitlichen Definition einer Periode ist die An- nahme, ein Akteur hätte nur einmal die Möglichkeit, sich für oder gegen eine Ent- wicklung zu entscheiden, sehr realitätsfremd. Aus diesem Grund soll das Grundmo- dell im nächsten Schritt auf eine Betrachtung mehrerer Perioden ausgeweitet werden, wobei für die Entwicklung der Software weiterhin nur eine Periode benötigt wird.

3.3. Erweiterung auf mehrere Perioden

Zur Erweiterung des Grundmodells wird die Anzahl der maximal zulässigen Entwicklungsperioden nun auf einen Wert größer 1 gesetzt (tmax > 1). So entsteht ein Spiel über mehrere Perioden. Den wesentlichen Unterschied zum einperiodigen Spiel stellt die Möglichkeit dar, sich in einer Periode gegen eine Entwicklung zu entscheiden und dennoch die Chance auf alleinige Fertigstellung der Software zu haben. Diese veränderte Spielsituation beeinflusst die Wahl der Handlungsalternative in der ersten Periode. Wie der Abbildung 3.2 entnommen werden kann, wird die Betrachtung nach einer Periode nur dann fortgeführt, wenn die Kombination (sj2, s−j2) erreicht wird und die Software somit nicht entwickelt wurde. Für gewöhnlich wird ein solches Spiel in der Literatur als wiederholtes Spiel bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Mehrperiodiges Spiel mit tmax = 2

In diesem Modell findet zwar eine Anlehnung an die Vorgehensweise von Gossner (1994), sowie Fudenberg und Tirole (1995) statt, von der Annahme identischer Spiel- situationen in jeder Stufe (Periode) des Spiels wird jedoch Abstand genommen. In einem wiederholten Spiel wird davon ausgegangen, dass jede Periode dieselbe Aus- zahlungsmatrix besitzt. Die Gesamtauszahlungen eines Akteurs werden als gewich- tetes Mittel der Auszahlungen jeder Periode definiert (Fudenberg und Tirole, 1995, Seiten 110-113, 145-146). Laut Annahme 9 auf Seite 15 fallen die Auszahlungen r im betrachteten Modell nur dann an, wenn bis zum Erreichen der Periode tmax keine Fertigstellung der Software stattgefunden hat. Für Perioden, die vor tmax − 1 liegen, bedeutet dies, dass sich die bisherige Auszahlungsmatrix ändert. Wird nun die Kom- bination (sj2, s−j2) erreicht, so fällt eine Auszahlung von w an. Im Fall der gemischten Strategien führt diese Annahme jedoch zu einem falschen Ergebnis, da die Entschei- dung gegen eine Entwicklung die sichere Auszahlung von w < e + w suggeriert. Da- bei wird nicht berücksichtigt, dass diese Entscheidung eine Weiterführung des Spiels zur Folge hat und unter Umständen eine Auszahlung von [Abbildung in dieser Leseprobe nicht enthalten]· δtmax getragen werden muss. Um die Folgen der Entscheidung jedoch korrekt abzu- bilden, müssen bei der Berechnung von[Abbildung in dieser Leseprobe nicht enthalten]dieAuszahlungenderFolgeperiodenbe- rücksichtigt werden. Aus diesem Grund wird die Auszahlungsmatrix in Fällen, in denen die Betrachtung nicht beendet ist um den erwarteten Barwert der Auszahlun- gen der Folgeperiode ergänzt. Die Berechnung von λj⁰ erfolgtdahermitHilfeeiner rekursiven Berechnung des Spielbaums. Bei diesem Vorgehen wird zum Zeitpunkt tmax begonnen und periodenweise für jeden Teilbaum sowohl λjI alsauchdererwar- tete Barwert der Auszahlungen berechnet. Für eine Betrachtung zum Zeitpunkt t mit, t < tmax − 1, führt dies zu einer Auszahlungsmatrix wie in Tabelle 3.5 dargestellt. Falls beide Akteure die Handlungsalternative sj2 (nicht entwickeln) wählen, so wird die Betrachtung eine weitere Periode fortgeführt und die erwarteten Auszahlungen werden in die Berechnung der Wahrscheinlichkeitsverteilung der gemischten Strate- gien mit einbezogen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.5: Auszahlungsmatrix für Periode t im mehrperiodigen Spiel

In der letzten Betrachtungsperiode, tmax − 1 bis tmax, ist der verbleibende Teilbaum identisch zur einperiodigen Betrachtung des Grundmodells. Die Auszahlungsmatrix zum Zeitpunkt tmax − 1 wird als Endmatrix bezeichnet, da keiner der darin dargestell- ten Knoten eine weitere Auszahlungsmatrix aufweist. Die neu entstandene Möglich- keit des Wartens verändert die Entscheidung der Akteure in der ersten Periode. Auf- grund der Rekursion werden in der ersten Auszahlungsmatrix mögliche zukünftige Entscheidungen bereits abgebildet. Daher hängt die Wahl der Handlungsalternative in der ersten Periode auch von den möglichen Entscheidungen der Folgeperioden ab. Dieser Zusammenhang kann dazu führen, dass bei einer hohen Entwicklungs- wahrscheinlichkeit in der letzten Periode eine äußerst niedrige Entwicklungswahr- scheinlichkeit in der ersten Periode entsteht. Analog zur Berechnung von λjI muss auch das Bestimmen der Gesamtentwicklungswahrscheinlichkeit eines Spiels ΨI im mehrperiodigen Modell angepasst werden. Abbildung 3.3 zeigt anhand eines ein-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Berechnung der Gesamtentwicklungswahrscheinlichkeit im mehrpe- riodigen Modell

fachen Spielbaumes mit einer maximalen Entwicklungsdauer von 2 Perioden, wie sich die Gesamtentwicklungswahrscheinlichkeit im Fall mehrperiodiger Spiele be- rechnen lässt. Zur Berechnung der Gesamtentwicklungswahrscheinlichkeit einer Pe- riode werden die Wahrscheinlichkeiten, einen Pfad zu erreichen, in dem die Softwa- re fertig gestellt wird, aufsummiert. Pfade, die aufgrund der Nichtfertigstellung der Software in einen weiteren Teilbaum führen, werden nun um die berechnete Gesamt- entwicklungswahrscheinlichkeit der Folgeperiode ergänzt. Zur Verdeutlihung die- ses Vorgehen soll Abbildung 3.3 dienen.

[...]

---

(¹ ) Bspw. wird eine Variable zum Zeitpunkt t = 1 bei Erreichen der Kombination von Handlungsalterna- tive (sj1, s−j2) mit dem Index I = 0 − 2 versehen.