Home Was ist ot ? Regeln Mitglieder Maintainer Impressum FAQ/Hilfe
Open Source - 3. Open Source Software-Projekte
Maintainer: Frank Bauer, Version 1, 05.01.2002
Projekt-Typ: halboffen
Status: Archiv
(1) Bevor auf die Organisation, die DV-technische Unterstützung und den typischen Verlauf eines Open Source Software-Projekts näher eingegangen wird, sollen zunächst einige grundlegende Aspekte derartiger Projekte vorgestellt werden.
(2) Hierzu zählen ihre spezifischen Eigenschaften, die hinsichtlich der zunehmenden Verbreitung freier Software nicht unwesentliche Frage nach den Gründen für eine Teilnahme an einem solchen Projekt, Voraussetzungen für erfolgreiche OSS- Projekte, Aspekte der Qualitätssicherung sowie Vorgehensweisen zur Lösung von Entscheidungsproblemen innerhalb einer projektspezifischen Community.
(4) Trotz der nahezu unüberschaubaren Vielzahl freier Softwareprojekte und der Tatsache, dass es innerhalb der Open Source-Community so gut wie keine Reglementierungen gibt, existieren einige für derartige Softwareprojekte charakteristische Merkmale.
(5) Diese Eigenschaften unterscheiden sich teilweise wesentlich von den für Unternehmen der Softwareindustrie üblichen Charakteristika und sollen aus diesem Grund nachfolgend kurz dargestellt werden.
(6) Der Beginn eines freien Softwareprojekts basiert häufig auf dem Vorhaben, eine vorliegende Problemstellung - wie bspw. die Automatisierung alltäglicher Vorgänge - zu lösen. Da bereits existierende Software mitunter nicht den gestellten Anforderungen genügt, beginnen viele Programmierer damit, eigene Lösungen zu entwickeln in der Annahme, dass es weitere Anwender gibt, die sich für diese Problemstellung interessieren und bei der Lösung helfen können [1]. Freie Software entsteht nicht auf Anweisung eines Vorgesetzten, sondern vielmehr als Lösung für die persönlichen und alltäglichen Probleme des Initiators und verbreitet sich, weil sich das Problem als typisch für eine Vielzahl von Benutzern herausstellt [2].
(7) In Open Source-Communities arbeiten oftmals Menschen, die sich niemals persönlich getroffen haben und lediglich über das Internet miteinander kommunizieren, an einem Projekt mit [3]. Die Teilnahme an einem interessierenden Projekt ist durch das Internet nicht auf Gebäude oder Länder beschränkt, Menschen aus der ganzen Welt können sich daran beteiligen. I.d.R. ist es hierfür ausreichend, sich in eine entsprechende Mailingliste [4] einzutragen.
(8) Die Teilnahme an einem freien Softwareprojekt erfolgt nahezu ausnahmslos ohne finanzielle Anreize [5]. Teilnehmer eines derartigen Projekts können grundsätzlich jederzeit den Bereich ihrer Beteiligungselbst bestimmen [6]. Obwohl Unternehmen - wie z.B. die SuSE Linux AG - vereinzelt OSS-Entwickler einstellen und ihnen die Möglichkeit bieten, sich in Vollzeit um ihre Projekte zu kümmern [7], bestimmt die Freizeit der Teilnehmer häufig das Ausmaß ihrer Beteiligung.
(9) Die Motivationen von Menschen, sich in einem freien Softwareprojekt zu engagieren, sind individuell verschieden. Wegen der unentgeltlichen Teilnahme an einem solchen Projekt sind finanzielle Interessen jedoch auszuschließen. Aufgrund der Verschiedenartigkeit der Motivationen und der Tatsache, dass in der Open Source-Community oftmals ideologische Beweggründe vorliegen, sind hierüber keine allgemein gültigen Aussagen ableitbar [8].
(10) Motive von Projektteilnehmern - insb. von Programmierern - die in diesem Zusammenhang vereinzelt genannt werden, lassen sich jedoch überblicksartig unter den folgenden Punkten zusammenfassen [9].
(11) Das Vorhaben, ein vorliegendes Problem zu lösen, ist nicht nur häufig der Beginn eines freienSoftwareprojekts, sondern oftmals der Grund für die Teilnahme an einem bereits existierenden Projekt, welches die Lösung einer vergleichbaren Problemstellung verfolgt. Die Begeisterung, ihrem Hobby Programmieren gemeinsam mit anderen Menschen nachgehen zu können sowie die Herausforderung, ein gegebenes, oftmals technisch anspruchsvolles Problem zu lösen, sind für Softwareentwickler mitunter Motivation genug [10].
(12) Grundlage des Fortbestands freier Software ist demnach kein Vertragsverhältnis, sondern u.a. die Befriedigung und das persönliche Vergnügen der Projektteilnehmer [11].
(13) Ein oft genannter Grund für die Beteiligung an einem freien Softwareprojekt ist der Wunsch, durch aktive, zum Fortschritt des Projekts beitragende Mitarbeit Anerkennung und hohes Ansehen unter anderen Programmierern zu erreichen [12].
(14) In diesem Zusammenhang ist anzunehmen, dass sich Prestige und Anerkennung umso leichter erwerben lassen, je größer das Interesse der Öffentlichkeit und je höher der technische Anspruch eines Projekts ist [13]. Der Wert bzw. der Nutzen der von den einzelnen Beteiligten in ein Projekt investierten Zeit und Anstrengungen ist jedoch nur schwer messbar und damit kaum miteinander vergleichbar. Aus diesem Grund ist das Ausmaß der Anerkennung wesentlich vom Urteil der Community abhängig [14].
(15) Manche OSS-Entwickler sind in erster Linie daran interessiert, ihre Vorstellungen von einem Leben in freier Selbstbestimmung und von einem gemeinschaftlichen Miteinander jenseits hierarchischer Ordnungen in ihrer Arbeit umzusetzen [15].
(16) Zudem spornt nicht wenige Programmierer die Zusammenarbeit mit vielen erfahrenen Softwareentwicklern aus aller Welt an. Hierdurch kann sich ihnen die Möglichkeit bieten, ihre Programmierkenntnisse mit einem vergleichsweise geringen Aufwand durch den ständigen Austausch des Quellcodes zu verbessern [16], die Aufmerksamkeit möglicher Arbeitgeber zu gewinnen oder sogar ein eigenes Unternehmen zugründen [17].
(17) Viele Anhänger freier Software sind darum bemüht, ihre Vision von einer Welt, in der Software nicht aufgrund der Entscheidungen einiger weniger Unternehmen, sondern uneingeschränkt von jedem und zu jeder Zeit genutzt und verteilt werden darf, umzusetzen und zu verbreiten [18]. Richard M. Stallmans Überzeugung, die ihn dazu veranlasste, das GNU-Projekt zu gründen, war u.a. davon geprägt, das kooperative Wesen der damaligen Software-Sharing Communities [19] - eine offene Zusammenarbeit und den freien Austausch von Informationen zum Wohle der Gemeinschaft - zu bewahren.
(18) Schließlich fühlen sich OSS-Programmierer vereinzelt dazu verpflichtet, durch das Einbringen ihrer Kenntnisse und Fähigkeiten in Form von Beiträgen für entsprechende Projekte der Gemeinschaft einen Teil der Leistungen zurückzugeben, die sie selbst von ihr bekommen haben [20].
(19) Volker Grassmuck fasst die Motivation vieler Open Source Software-Entwickler folgendermaßen zusammen: "Statt also aus dem Besitz und seiner kommerziellen Verwendung einen Vorteil zu ziehen, übergeben die Programmiererinnen und Programmierer freier Software ihr Werk der Öffentlichkeit, auf dass es bewundert, kritisiert, benutzt und weiterentwickelt werde." Das Ergebnis "ist eine Schöpfung, die man mit anderen teilen kann." [21]
(20) Voraussetzung für die Aufrechterhaltung der Bereitschaft, ohne finanzielle Anreize in einem freien Softwareprojekt mitzuarbeiten, ist ein Schutzmechanismus, welcher verhindert, dass die gemeinsame Arbeit von vielen Freiwilligen durch Dritte ausgenutzt werden kann.
(21) Die Geschichte von UNIX ist ein Beispiel hierfür. Solange UNIX weitgehend frei genutzt und verändert werden durfte, fanden sich viele Interessierte, die zu dessen Weiterentwicklung beitrugen. Nach der Kommerzialisierung von UNIX jedoch brachten Unternehmen eine Vielzahl proprietärer Varianten hervor, welche auf dem ehemals freien und gemeinschaftlich weiterentwickelten UNIX basierten.
(22) Das damit verbundene, sich verlierende Interesse an UNIX seitens der freien Entwicklergemeinde lag nicht nur an den hohen Lizenzgebühren und den restriktiven Nutzungsbedingungen, sondern gleichermaßen an der Enttäuschung über die Privatisierung und Kommerzialisierung einer Software, an der zahllose Menschen in der ganzen Welt mitgearbeitet hatten [22].
(23) Die Open Source-Community sollte schon aus Eigeninteresse versuchen zu verhindern, dass Personen oder Unternehmen ihre eigenen, auf freier Software basierenden Weiterentwicklungen nicht mit der Gemeinschaft teilen und somit die Ressource Motivation gefährden [23]. Einen solchen Schutz kann z.B. die GPL bieten.
(24) Neben der zwingenden Notwendigkeit, den Quellcode der Software einsehen und modifizieren zu können sowie der Verfügbarkeit leistungsfähiger Kommunikationsmittel, wie sie bspw. das Internet bietet, lassen sich folgende Voraussetzungen für eine erfolgreiche, verteilte Softwareentwicklung innerhalb der Open Source-Community beobachten.
(25) Der Open Source-Community sollte ein lauffähiges und testbares Programm vorgelegt werden, um daran ansetzend Verbesserungen und Weiterentwicklungen vornehmen zu können. Die zu veröffentlichende Software muss nicht notwendigerweise besonders stabil, fehlerfrei oder gut dokumentiert sein, sie sollte jedoch bereits funktionstüchtig sein und einige wichtige Teile desjenigen Problems lösen, für das sie ursprünglich entwickelt wurde [24].
(26) Darüber hinaus kann es in diesem Zusammenhang für ein freies Softwareprojekt entscheidend sein, in seiner anfänglichen Entwicklungsphase einen kontinuierlichen Fortschritt erkennen zu lassen. Bleibt dieser Fortschritt aus besteht die Möglichkeit, dass Entwickler ihr Interesse verlieren und sich einem anderen Projekt zuwenden [25].
(27) Um eine Entwicklergemeinde aufzubauen muss man potenzielle Teilnehmer begeistern und für sein Projekt interessieren können. Der persönliche Eindruck und das Verhalten des Projektbetreuers [26] sind nicht zuletzt ausschlaggebend dafür, möglichst viele Anwender für das Projekt zu gewinnen und diese so zu motivieren, dass sie ihre Kenntnisse und Fähigkeiten in das Projekt investieren [27]. Für einen Maintainer bedeutet dies einerseits, dass er vereinzelt auch solche Vorschläge und Ergänzungen berücksichtigen sollte, die sich nicht gänzlich mit seinen Vorstellungen decken, und dass er andererseits seine Entscheidungen jederzeit sachlich und detailliert darlegt [28].
(28) Abgesehen von der nötigen Kompetenz sollte der Betreuer eines OSS-Projekts demnach über die Fähigkeit verfügen, mit Menschen umgehen und kommunizieren zu können, um eine natürliche Autorität jenseits vertraglicher Regelungen aufzubauen.
(29) Bei einem offenen Softwareprojekt, welches hauptsächlich auf der Unterstützung Freiwilliger basiert, können zweckmäßige und komfortable Möglichkeiten der Beteiligung oftmals entscheidend dafür sein, ob ein Entwickler aus der Community etwas zu diesem Projekt beitragen wird oder nicht [29].
(30) Es ist demnach anzunehmen, dass eine ansprechende und umfassende DV-technische Unterstützung [30] ein wesentliches Mittel für eine erfolgreiche Abgrenzung eines OSS-Projekts gegenüber vergleichbaren, um Unterstützung aus der Community konkurrierenden Projekten darstellen kann.
(31) Freie Softwareprojekte besitzen häufig eine modulare Struktur, welche es erlaubt, die Funktionalität der Software zu erweitern ohne Änderungen an den bereits existierenden Basisfunktionen durchführen zu müssen. Ein Maintainer kann sich somit die Kontrolle über das Kernprojekt erhalten und eine koordinierende Verantwortung darüber übernehmen - wie es bspw. Linus Torvalds mit dem Linux- Kernel praktiziert, indem er die endgültige Entscheidung über die Integration neuer Funktionalitäten trifft [31].
(32) Die Tatsache, dass viele OSS-Projekte eine derartige modulare Struktur aufweisen, beruht nicht zuletzt auf einer Entscheidung der UNIX-Entwickler. Anstelle eines komplexen, monolithischen Systems sollte UNIX aus kleinen, einfachen und effizienten Werkzeugen bestehen, welche miteinander kombiniert werden können, um komplexere Aufgaben zu lösen. Diese Strukturentscheidung wurde von freien Softwareprojekten weitgehend übernommen. Verschiedene Module können somit durch kleine, unabhängige Gruppen parallel entwickelt werden, wodurch der Aufwand an Koordination und Kommunikation begrenzt und der Projektfortschritt beschleunigtwerden kann [32].
(33) Zur Beurteilung der Qualität einer Software bzw. der Güte des Software- Entwicklungsprozesses existieren unterschiedliche Kriterien. In Tabelle 3.1.4/1 wird eine Abgrenzung verschiedener Merkmale nach dem Gegenstand ihrer primären Anwendbarkeit - entweder auf das Produkt Software oder auf den Prozess ihrer Erstellung - vorgenommen [33]. Eine solche Abgrenzung mag häufig nur schwer für ein konkretes Projekt aufrechtzuerhalten sein,jedoch trägt sie dem Umstand Rechnung, dass sich das Qualitätsmanagement sowohl unter einem technischen als auch unter einem verhaltensorientierten Aspekt betrachten lässt. Während der erstgenannte technisch-organisatorische (und wirtschaftliche) Möglichkeiten zur Gewährleistung der Softwarequalität betrifft, hat der letztgenannte Aspekt das Verhalten der Projektbeteiligten während des Entwicklungsprozesses zum Gegenstand [34]. Darüber hinaus ist anzunehmen, dass der Prozess ihrer Entwicklung einen wesentlichen Einfluss auf die Qualität der Software hat [35].
| Produkt | Prozess |
|---|---|
| Korrektheit, Zuverlässigkeit | Produktivität |
| Effizienz | Rechtzeitigkeit, Pünktlichkeit |
| Benutzerfreundlichkeit | Transparenz |
| Nachprüfbarkeit | |
| Erweiterbarkeit | |
| Wiederverwendbarkeit | |
| Portabilität | |
| Verständlichkeit | |
| Kompatibilität, Integrierbarkeit |
(35) Hinsichtlich des Open Source Software-Modells sollen nachfolgend die verschiedenen Qualitätsmerkmale bzgl. des Produkts Software unter dem Aspekt der Software-Qualitätssicherung zusammengefasst und diejenigen bzgl. des Prozesses der Softwareentwicklung einzeln untersucht werden.
(36) Das OSS-Modell unterscheidet sich in der Art und Weise der Software- Qualitätssicherung - also der Erfüllung der o.g. produktbezogenen Qualitätsmerkmale - wesentlich von der für Unternehmen der Softwareindustrie typischen Vorgehensweise. Letztere bestand in der Vergangenheit oftmals darin, vor der Veröffentlichung der nahezu fertig erstellten Software Fehlerbeschreibungen aus der Sicht des Anwenders nachzuvollziehen, die Ursachen der Fehler zu lokalisieren und die Korrekturen wiederum zu prüfen bzw. von ausgesuchten externen Testern prüfen zu lassen [36]. In Ergänzung zu einer solchen Qualitätskontrolle gegen Ende des Software-Entwicklungsprozesses wird die Qualitätssicherung in Softwareunternehmen zunehmend als integrierter und unternehmensweiter Prozess im Rahmen eines umfassenden Qualitätsmanagement-Systems verstanden [37].
(37) In der OSS-Entwicklung dagegen werden Fehler und Probleme als triviale Phänomene [38] betrachtet, die durch eine genügend große Entwicklergemeinde während des Prozesses der Softwareentwicklung schnell identifiziert und behoben werden können. Erfahrungen haben gezeigt, dass durch eine derartige "vernetzte Qualitätskontrolle [39], welche frühzeitig und entwicklungsbegleitend die Fähigkeiten und Kompetenzen vieler Anwender und Entwickler zur Qualitätssicherung nutzt, Fehlfunktionen der Software im Vergleich zu nicht- freier Software auf einem wesentlich geringeren Niveau gehalten werden können [40].
(38) Eines der stärksten Argumente für das Open Source Software-Modell ist demnach die dezentralisierte, unentwegte Überprüfung und Kritik durch andere, unabhängige Entwickler und fachkundige Anwender. Es ist anzunehmen, dass dieser Peer Review-Prozess [41] ein wesentlicher Grund für die oft erwähnte Stabilität und Qualität freier Software ist [42].
(40) Dem Open Source-Modell wird vereinzelt mangelnde Produktivität und Effizienz hinsichtlich der Reaktion auf technologische Veränderungen vorgeworfen [43]. In den Halloween-Dokumenten [44] z.B. urteilt Microsoft über die OSS-Entwicklung, dass sie nur Ideen nachahmen könne, die bereits allgemeiner Standard in der Softwareentwicklung sind. Aufgrund unzureichenden Managements sei das Erreichen neuer Fronten [45], also darüber hinausgehender Fortschritt, nahezu unmöglich [46].
(41) Aufgrund der Tatsache, dass Software in erster Linie auf Bedürfnissen und Ideen basiert [47] und das Ergebnis kreativer Tätigkeiten von i.d.R. mehreren Personen ist, liegt die Vermutung nahe, dass sich Fortschritt und Innovationen am einfachsten dann erreichen lassen wenn es gelingt, möglichst viele Menschen heranzuziehen, die zu solchen Ideen und zu kreativer Gestaltungfähig sind [48]. Wichtig erscheint in diesem Zusammenhang allein das Vermögen, diese Einsichten und Ideen zu fördern und umzusetzen. Hiervon ist jedoch sowohl die traditionelle Softwareentwicklung, wie sie in Unternehmen der Softwareindustrie üblich ist, als auch die OSS-Entwicklung betroffen. Die o.g. Kritik ist somit keineswegs eine Unzulänglichkeit der Open Source-Community, sondernvielmehr ein allgemeines Problem der Softwareentwicklung.
(42) Da freie Softwareprojekte nahezu ausnahmslos keinem Terminplan unterliegen [49], sind Rechtzeitigkeit bzw. Pünktlichkeit für derartige Projekte nur von geringer Bedeutung.
(43) Unzureichende Transparenz und Übersichtlichkeit sowie eine damit einhergehende ineffizienteSoftwareentwicklung durch eine nur lockere, weitgehend unkoordinierte Zusammenarbeit ohne festeAufgabenverteilung ist ein weiterer, oftmals vorgetragener Kritikpunkt gegenüber demOSS-Modell [50]. Hierdurch bestehe zudem eine hohe Wahrscheinlichkeit für einen sog. Code Fork [51], welcher die Entstehung mehrerer instabiler und zueinander inkompatibler Versionen einer Software fördere [52].
(44) Dem entgegen steht jedoch die Tatsache, dass sich durch die zahlreichen Möglichkeiten desInformationsaustausches Softwareentwickler und andere Interessierte jederzeit über den aktuellen Status des Projekts informieren können [53]. Darüber hinaus hat es sich innerhalb der Open Source-Community eingebürgert, bei Unklarheiten die Wünsche und Entscheidungen des Maintainers, sofern sie plausibel und entsprechend detailliert dargelegt wurden, zu respektieren [54].
(45) In der Praxis kommt diesem Vorwurf gegenüber der OSS-Entwicklung nur eine zu vernachlässigende Bedeutung zu.
(46) Allein die Tatsache, dass sich die Art und Weise der Qualitätssicherung in einem freien Softwareprojekt z.T. wesentlich von einer herkömmlichen, systematisch geplanten Vorgehensweise unterscheidet, erlaubt jedoch noch keine Aussage darüber, ob das Open Source-Modell in dieser Hinsicht der traditionellen Softwareentwicklung grundsätzlich unter- oder überlegen ist. Für beide Ansätze scheint es vielmehr entscheidend zu sein, inwieweit es ihnen gelingt, auf effiziente Weise die zur Verfügung stehenden Mittel zu nutzen sowie die sich bietenden Möglichkeiten umzusetzen. Sowohl freie als auch kommerzielle Softwareprojekte sind demnach wesentlich von den Leistungen und Beiträgen ihrer Teilnehmer abhängig.
(47) Bei einer Vielzahl zu treffender Entscheidungen stimmen die Meinungen der Mitglieder einer projektspezifischen Community nur selten überein. Aufgrund des Fehlens einer entscheidungsberechtigten Leitung werden Konflikte innerhalb eines freien Softwareprojekts i.d.R. derart gelöst, dass die Beteiligten so lange darüber diskutieren, bis ein von allen tragfähiger Kompromiss erreicht werden konnte oder bis sich eine signifikante Mehrheit für einen Vorschlag ausgesprochen hat [55].
(48) Sollte auf diese Weise dennoch keine Einigung erzielt werden können, wird entweder die endgültige Entscheidung dem Maintainer bzw. dem sogenannten Core Team [56] zugestanden oder - dem Prinzip der Seniorität folgend - zugunsten derjenigen Partei entschieden, die den bislang größten Anteil zum Fortschritt des Projekts beigetragen hat [57].
(49) Gefahr und Chance zugleich ist für ein freies Softwareprojekt dann gegeben, wenn sich die Beteiligten trotz allem nicht einigen können oder wenn es Entwickler gibt, die mit den getroffenen Entscheidungen nicht einverstanden sind. Durch den frei verfügbaren Quellcode besteht gerade in einem solchen Fall die Möglichkeit, dass ein oder mehrere Programmierer ein eigenes, auf dem bisherigen basierendes Projekt beginnen. Ein solcher Vorgang wird in der OSS-Terminologie als Code Fork bezeichnet [58].
(50) Durch die jeweils verkleinerten projektspezifischen Communities und aufgrund der Annahme, dass die Projektfortschritte nicht deckungsgleich sind, besteht die Gefahr darin, dass sich das Projekt an sich verzögert und unter Umständen nicht von der besten Entwicklung profitieren wird.
(51) Dem gegenüber bietet sich die Gelegenheit, dass ein Projekt, dessen Maintainer sich als überfordert erweist oder Vorschläge und Kritik seitens der übrigen Teilnehmer nicht berücksichtigt [59], von anderen Entwicklern übernommen und den Anregungen entsprechend fortgeführt werden kann.
(52) Welches der Teilprojekte sich letztendlich durchsetzen wird, entscheiden in erster Linie die Anwender. Ein solcher Code Fork ist somit einerseits eine der schärfsten Formen der Kritik durch die Community sowie andererseits eine faire Herausforderung für ein Projekt, seinen Betreuer und alle weiteren Beteiligten [60].
(53) Unter dem Begriff Organisation wird die Gesamtheit derjenigen Maßnahmen verstanden, welche ein soziales System arbeitsteilig strukturieren und die Aktivitäten der zum System gehörenden Menschen ordnen [61].
(54) Die Organisationsstruktur eines Unternehmens als das Ergebnis sämtlicher organisatorischer Gestaltungshandlungen resultiert gewöhnlich aus einer planvollen und systematischen Vorgehensweise der Unternehmensleitung.
(55) In freien Softwareprojekten dagegen gibt es keine Leitung, die über die Verteilung der Aufgaben entscheidet oder den zeitlichen Projektverlauf bestimmt, kein Vorgesetzter sagt den Teilnehmern, was zu tun ist. Insbesondere aufgrund einer häufig weltweiten Verteilung der Projektteilnehmer, ihrer in kaum einer Weise vorhersehbaren Beiträge sowie einer vereinzelt ablehnenden Haltung gegenüber hierarchischen Strukturen ist eine Organisation derartiger Projekte i.d.R. nur durch Kompromisse und Vereinbarungen möglich. Die besonderen Eigenschaften der Open Source-Community wirken sich offensichtlich nachteilig auf die Planbarkeit und Organisierbarkeit ihrer Softwareprojekte aus.
(56) Dennoch lassen sich in diesem Zusammenhang strukturierende Maßnahmen innerhalb der Open Source-Community beobachten. Diese Maßnahmen sollen im folgenden - unterteilt in die Aufbau- und die Ablauforganisation - aufgezeigt werden.
(57) Die Aufbauorganisation umfasst gewöhnlich die Gliederung eines Systems in Subsysteme sowie die Verteilung der (Teil-)Aufgaben auf die Systemelemente - sie betrifft somit die Bildung von Aktionseinheiten und deren Koordination [62].
(58) Neben dem einzelnen, häufig seine eigenen Interessen verfolgenden Teilnehmer als elementarer Bestandteil einer projektspezifischen Community sind in freien Softwareprojekten ab einer gewissen Komplexität weitere Subsysteme auszumachen. Diese sowie die Art und Weise der Verteilung der Aufgaben innerhalb eines solchen selbstorganisierenden Systems werden nachfolgend dargestellt.
(59) Freie Softwareprojekte sind u.a. dadurch gekennzeichnet, dass es keine feste Aufgabenverteilung gibt und die Teilnehmer ihren Wirkungskreis - begünstigt durch die Aufteilung des Projekts in kleinere Einheiten (Module) - frei wählen können. Neben der Softwareentwicklung an sich können Interessierte bspw. bei der Übersetzung in andere Sprachen oder bei der Erstellung der Dokumentation helfen [63].
(60) Um jedoch die verschiedenen Bereiche eines freien Softwareprojekts gleichermaßen abzudecken, geben die unmittelbaren Projektbetreuer mitunter Anregungen, welches Teilprojekt am dringendsten Unterstützung benötigt und versuchen zudem, Teilnehmer mit einander ergänzenden Kenntnissen und Fähigkeiten zueinanderzubringen [64].
(61) Die Bildung einer betreuenden und koordinierenden Projektleitung - welche häufig als Core Team bezeichnet wird - ist oft bei größeren Projekten zu beobachten. Diese, die Initiatoren und Kernentwickler des Projekts umfassende Gruppe macht u.a. Vorschläge hinsichtlich der weiteren Entwicklung der Software, regelt die Verwaltung des Quellcodes oder kümmert sich um Fragen der Öffentlichkeitsarbeit [65]. Darüber hinaus bemüht sich das Core Team darum, weitere Teilnehmer für das Projekt zu gewinnen, um dessen Fortbestand zu gewährleisten und ggf. einen drohenden Code Fork abzuwenden [66].
(62) Die Aufnahme in ein bestehendes Core Team gilt für die meisten Teilnehmer eines freies Softwareprojekts als Auszeichnung, sie erfolgt jedoch i.d.R. erst aufgrund fortwährender Verdienste um die Weiterentwicklung des Projekts. Neue Mitglieder können von bisherigen Mitgliedern vorgeschlagen werden [67].
(63) Bedingt durch das zunehmende Interesse der Softwareindustrie können sich für freie Softwareprojekte vereinzelt Möglichkeiten der Zusammenarbeit mit kommerziellen Unternehmen eröffnen. Um jedoch (schriftliche) Vereinbarungen mit diesen Unternehmen abschließen zu können, bedarf es i.d.R. eines institutionellen Rahmens in Form eines offiziellen Vertragspartners [68]. Bei Debian GNU/Linux ist dies z.B. die Organisation Software in the Public Interest [69], bei Apache The Apache Software Foundation [70]. Derartige Institutionen, zu denen ebenfalls die Open Source Initiative (OSI) und die FreeSoftware Foundation (FSF) zählen, sind keine gewinnorientierten Organisationen, sondern vielmehr - neben ihrer Eigenschaft als Vertragspartner für interessierte Unternehmen - ein möglicher Empfänger für Spenden und ähnliche Projektbeiträge. Mitunter nehmen sie sich auch rechtlichen, bspw. im Zusammenhang mit der Vertragsgestaltung stehenden Dingen an [71].
(64) Gegenstand der Ablauforganisation ist die Strukturierung der zu einer Aufgabenerfüllung erforderlichen Vorgänge. Dies umfasst gewöhnlich die Bildung von Arbeitsgängen, deren Zuordnung zu Aufgabenträgern und ihre zeitliche Abstimmung aufeinander [72].
(65) Bei einem freien Softwareprojekt ist jedoch - aufgrund einer verteilten, lockeren und weitgehend unkoordinierten Zusammenarbeit sowie bedingt durch die Tatsache, dass die Teilnehmer den Umfang, die Dauer und den Bereich ihrer Beteiligung grundsätzlich selbst bestimmen - nicht abzusehen, welcher Teilnehmer zu welchem Zeitpunkt welchen Beitrag für das Projekt leisten wird. Eine systematische Ablauforganisation ist demnach nahezu undurchführbar.
(66) Der folgende Abschnitt konzentriert sich aus diesem Grund auf den eigentlichen Prozess der Softwareentwicklung innerhalb der Open Source-Community. Näher betrachtet werden die jeweiligen Vorgänge in den verschiedenen Phasen der Softwareentwicklung sowie diejenigen, welche die Planung und Steuerung eines freien Softwareprojekts betreffen.
(67) Der für kommerzielle Projekte typische Verlauf der Softwareentwicklung lässt sich in die Phasen Planung, Definition, Entwurf, Implementierung, Abnahme und Einführung sowie Wartung und Pflegeeinteilen [73]. Obwohl sich einige dieser Phasen auch in freien Softwareprojekten wiederfinden, folgt dort die Softwareentwicklung in den wenigsten Fällen einer solchen klar definierten, linearen Struktur.
(68) Da es für freie Software ohnehin keinen Auftraggeber gibt, entfällt die Phase der Abnahme. Zudem liegen sowohl die Installation als auch die Inbetriebnahme derartiger Software i.d.R. in der Hand des Anwenders [74], die Einführungsphase ist demnach nicht Gegenstand des Entwicklungsprozesses freier Software. Die Aktivitäten der Wartungs- und Pflegephase - wie z.B. Fehlerbehebung, Optimierung und Erweiterung [75] - schließlich sind in OSS-Projekten ohnehin ständiger Bestandteil der Softwareentwicklung.
(69) Die noch verbleibenden Phasen lassen sich ebenfalls in freien Softwareprojekten beobachten, jedoch sind sie hier nur selten Gegenstand systematischer Planungen, wie sie in der Softwareindustrie üblich sind [76]. Nachfolgend sollen die für freie Softwareprojekte typischen Phasen der Softwareentwicklung vorgestellt werden.
(70) Am Anfang eines freien Softwareprojekts steht i.d.R. eine Idee - entweder eine Idee zur Lösung eines Problems bzw. einer störenden Unzulänglichkeit oder eine Vorstellung von einem nützlichen Programm, welches weitere Anwender interessieren könnte. Typischerweise wird diese Idee bereits so weit implementiert, dass ein hinreichend lauffähiges Programm vorliegt [77]. Dem Projektstart lassen sich demnach weitgehend die herkömmlichen Phasen der Planung und Definition sowie teilweise diejenigen des Entwurfs und der Implementierung zuordnen.
(71) Diese lauffähige und vor allem testbare Software wird anschließend der Allgemeinheit zugänglich gemacht. Hierzu gehört gewöhnlich die Einrichtung einer möglichst umfassenden DV-technischen Infrastruktur, um Interessierten eine einfache und komfortable Möglichkeit der Teilnahme zu bieten. Je mehr Anwender sich schließlich für die Software oder zumindest für die dahinter stehende Idee interessieren, desto größer ist die Wahrscheinlichkeit für einen Erfolg des Projekts [78].
(72) In seinem Essay The Cathedral and the Bazaar untersucht Eric S. Raymond die Vorgehensweisen und Mechanismen der OSS-Entwicklung [79]. Die Ergebnisse seiner Untersuchung lassen sich wie folgt zusammenfassen:
(73) Zunächst wird die Aussicht, durch aktive Mitarbeit an einem Projekt wesentlich zu dessen Fortschritt beitragen zu können, viele Anwender, die daran interessiert sind, die Funktionsweise und den Aufbau der Software zu erforschen sowie Lösungen für gefundene Probleme zu erarbeiten, für eine Teilnahme motivieren [80].
(74) Frühzeitige und häufige Veröffentlichungen [81] neuer, aktualisierter Versionen der Software, in denen die Fehlerbeschreibungen und Verbesserungen der Anwender umgesetzt wurden [82], können zudem dazu beitragen, dass durch einen regen Informationsaustausch die Anzahl der Anwender steigt und die Beteiligten ihr Interesse nicht verlieren. In diesem Zusammenhang kann ein Projekt schon bald eine Vielzahl von Entwicklern auf sich vereinen, wenn dessen Betreuer anspruchsvolle und herausfordernde Aufgaben der Community überlässt und nicht gänzlich selbst übernimmt [83].
(75) Durch Einbeziehung der Anwender als Mitentwickler und Ermunterung zur aktiven Mitarbeit [84] sowie aufgrund der Tatsache, dass unter den Anwendern viele erfahrene Programmierer sind, können schließlich Fehler schnell diagnostiziert und behoben sowie notwendige Änderungen umgehend vorgenommen werden [85].
(76) Frederick P. Brooks, Jr. [86] führt in diesem Zusammenhang aus, dass Komplexität und Umfang der Kommunikation zwischen den Teilnehmern eines Softwareprojekts quadratisch mit der Anzahl der Beteiligten steigen, der Fortschritt des Projekts an sich jedoch nur linear verläuft [87]. Raymond entgegnet dem, dass bei einem freien Softwareprojekt nur eine unwesentliche Koordination und Kommunikation der Beteiligten untereinander nötig sei mit dem Ergebnis, dass durch eine große Anzahl interessierter und talentierter Tester und Mitentwickler Debugging [88] parallelisierbar sei. Die OSS- Entwicklung sei somit weitgehend unanfällig gegenüber der von Brooks formulierten Gesetzmäßigkeit und ermögliche eine schnelle und zuverlässige Softwareentwicklung [89].
(77) Die Phasen des weiteren Softwareentwurfs und der Implementierung lassen sich demnach der Entwicklung innerhalb der Open Source-Community zuordnen.
(78) Ein freies Softwareprojekt endet typischerweise damit, dass das Projekt aus verlorenem Interesse, aus Zeitgründen oder weil es als abgeschlossen gilt, nicht mehr weiterverfolgt wird und sich niemand findet, der es aus beliebigen Gründen von den ursprünglichen Betreuern übernimmt und fortführt [90].
(79) Gegenstand der Projektplanung sind - neben den bereits in Abschnitt 3.2.1 betrachteten aufbauorganisatorischen Aspekten - im wesentlichen die Planung der Termine, der Qualität, der Ressourcen und der Kosten [91]. Im folgenden Abschnitt soll skizziert werden, ob und inwiefern derartige Aktivitäten für freie Softwareprojekte relevant sind.
(80) Üblicherweise setzen sich freie Softwareprojekte keinen Zeitplan für eine Veröffentlichung neuer, offizieller Versionen [92]. Erreicht ein Projekt einen vereinbarten Status, erfolgt i.d.R. ein sog. Code Freeze, ab dem ausschließlich Änderungen zugelassen werden, die absolut nötig sind, um Fehler zu beheben, und keinesfalls solche, die sich destabilisierend auf die Software auswirken könnten [93]. Sobald nach ausgiebigen Tests alle offensichtlichen bzw. gemeldeten Fehler behoben wurden, wird das Projekt schließlich mit einer neuen Versionsnummer offiziell freigegeben, eine systematische Terminplanung liegt jedoch nicht vor.
(81) Viele OSS-Projekte präsentieren sich und ihren Fortschritt auf einer entsprechenden Website. Häufig finden sich dort eine öffentliche Fehlerdatenbank, in die Anwender einen sog. Bug Report mit der Fehlerbeschreibung einstellen können sowie eine öffentliche ToDo-Liste, die einen Überblick über zukünftige Entwicklungen und notwendige Erweiterungen liefert. Anwender können hier jederzeit Vorschläge für Ergänzungen (Feature Request) einbringen [94].
(82) Aspekte, die im weitesten Sinne einer Qualitätsplanung zuzuordnen sind, beschränken sich bei freien Softwareprojekten gewöhnlich auf diese beiden Mittel.
(83) Jeder Teilnehmer eines freien Softwareprojekts trägt die in diesem Zusammenhang anfallenden Kosten - z.B. für die Nutzung einer Internetverbindung - selbst. Kosten für eine entsprechende DV-technische Infrastruktur [95] werden entweder von den Projektbetreibern getragen oder von Sponsoren übernommen [96]. In ähnlicher Weise verhält es sich mit den Ressourcen, deren Beschaffung und Einsatz letztendlich dem einzelnen Projektteilnehmer obliegt.
(84) Ressourcen und Kosten sind in freien Softwareprojekten somit in den wenigsten Fällen Gegenstand systematischer Planungen.
(85) Eine Projektplanung im Sinne eines systematischen, vorwegnehmenden Durchdenkens zukünftiger Aufgaben und Maßnahmen kann demnach bei einem freien Softwareprojekt nur ansatzweise festgestellt werden.
(86) Zu den wesentlichen Aufgaben der Projektsteuerung gehören einerseits die Anleitung, Motivierung und Koordination der Projektteilnehmer sowie andererseits Maßnahmen zur Durchsetzung der während der Projektplanung getroffenen Vorgaben [97].
(87) Aufgrund des Fehlens einer entsprechenden Projektleitung lassen sich führende, koordinierende und überwachende Maßnahmen allenfalls dem Maintainer bzw. dem Core Team zuschreiben. Letztendlich werden im Bedarfsfall Entscheidungen und Maßnahmen gemeinschaftlich von der projektspezifischen Community diskutiert und durchgeführt [98].
(88) Die spezifischen Eigenschaften der Open Source-Community beeinflussen nicht nur die Organisation ihrer Softwareprojekte. Gleichermaßen lässt sich deren DV- technische Unterstützung als Reflektion ihrer organisatorischen Merkmale auf die genannten Eigenschaften zurückführen.
(89) Abgesehen von der eigentlichen Softwareentwicklung wird in einem freien Softwareprojekt nahezu jeder Prozess - beginnend bei der erstmaligen Ankündigung über die Bekundung der Teilnahme bis zur Veröffentlichung einzelner Versionen - durch DV-technische Mittel unterstützt. Bevor auf das Concurrent Versions System als das zentrale Werkzeug einer verteilten Softwareentwicklung eingegangen wird, sollen zunächst die für freie Softwareprojekte typischen Kommunikationsmittel genannt werden. Abschließend wird der Onlinedienst SourceForge.net, welcher die zuvor beschriebenen Werkzeuge an zentraler Stelle vereint, vorgestellt.
(90) Die dominierenden Kommunikationsmittel für die weltweit verteilte Kooperation in freien Softwareprojekten sind [99]:
(91) Viele OSS-Projekte verfügen über zwei oder mehrere Mailinglisten [102]. Üblich ist die Einrichtung einer öffentlich zugänglichen Liste, welche hauptsächlich für Anwender gedacht ist, sowie einer geschlossenen Liste für die Mitglieder des Core Teams und ggf. weitere Softwareentwickler, die auf Anfrage in diese Liste eingetragen werden können [103].
(92) Ursache für die Einrichtung mehrerer Mailinglisten kann z.B. eine zu hohe Signal-To-Noise Ratio auf der öffentlichen Liste sein. In einem solchen Fall überwiegt unwichtige über nützliche und dem Fortschritt des Projekts dienende Diskussion, sodass die Kernentwickler eine interne Liste anlegen, auf der sie über grundlegende Fragen der Entwicklung diskutieren können [104].
(93) Mit zunehmender Verbreitung und Komplexität standen die Betreuer freier Softwareprojekte zunehmend vor der Problematik einer effizienten Integration zahlreicher Patches, die von den Anwendern erarbeitet und an die Maintainer gesendet wurden. Mit der Zeit benötigten mehr und mehr Projekte ein System, "das automatisch Beiträge annimmt und jeden auf dem aktuellen Stand der Änderungen des Quelltextes hält." [105] Darüber hinaus sollte es möglich sein, bereits in den Quellcode integrierte Änderungen bei Bedarf - z.B. weil sie sich als fehlerhaft erwiesen haben - automatisch wieder zu entfernen. Das gesuchte System musste somit eine Art Historie des Projekts führen, um ältere Versionen wiederherstellen zu können [106].
(94) Walter Tichy schrieb mit dem Revision Control System (RCS) ein Programm, dass den o.g. Anforderungen weitgehend gerecht werden konnte. Aufgrund einiger Unzulänglichkeiten, wie z.B. fehlender Netzwerkfähigkeit, begannen jedoch andere Entwickler, RCS zu erweitern und später vollkommen neu zu schreiben. Ergebnis dieser Aktivitäten ist das Versionsverwaltungssystem Concurrent Versions System (CVS) [107].
(95) Mit dem CVS ist es nun möglich, die gleichzeitige Arbeit mehrerer Entwickler an denselben Dateien zu koordinieren und zusammenzufügen sowie ggf. über mögliche Konflikte [108] zu informieren. Aufgrund der Netzwerkfähigkeit können darüber hinaus Programmierer weltweit auf den Quellcode zugreifen.
(96) Konkret können sich interessierte Entwickler mittels CVS die aktuellste Version (Entwicklerversion) aus dem sog. CVS-Repository [109] auf ihre lokalen Rechner kopieren, Veränderungen an Teilen des Quellcodes vornehmen und sich von CVS einen Patch erzeugen lassen, welcher dann - sofern keine Konflikte vorliegen - automatisch in das CVS- Repository integriert wird.
(97) Die technische Umsetzung erfolgt derart, dass sich ein Entwickler mittels eines Check Out die Entwicklerversion als sog. Arbeitskopie auf seinen Rechner überträgt. Nach erfolgten Änderungen kann der Entwickler versuchen, diese durch ein Commit in das CVS-Repository einzuspielen. Erkennt CVS durch einen Abgleich der aktuellen Version mit der Arbeitskopie des Entwicklers, dass in der Zwischenzeit andere Programmierer Veränderungen am CVS-Repository vorgenommen haben, veranlasst es den Entwickler, vor dem Commit eine Aktualisierung (Update) seiner veralteten Arbeitskopie mit der Entwicklerversion durchzuführen. Sollte ein Konflikt zwischen der Entwicklerversion und der Arbeitskopie vorliegen, so muss der Entwickler die Ursache hierfür zunächst in seiner Arbeitskopie beheben, um einen Commit durchführen zu können.
(98) Um unterschiedlich stark veraltete Arbeitskopien mehrerer Entwickler mit dem aktuellen CVS-Repository aktualisieren zu können, zeichnet CVS alle Commits seit Projektbeginn auf und aktualisiert die jeweiligen Arbeitskopien nur mit denjenigen Commits, die seit dem Check Out durchgeführt wurden [110].
(99) CVS fand vor allem deshalb einen hohen Verbreitungsgrad, weil sich durch intelligentes Zusammenführen von Veränderungen "die Entwickler nur selten um die logistischen Probleme kümmern [mussten], die entstehen, wenn mehrere Leute an den gleichen Quelltexten arbeiten." [111] CVS reduziert somit den Aufwand sowohl für die Betreuung eines Projekts als auch für die Mitarbeit an diesem, indem es Funktionen zum automatischen Erzeugen von Beiträgen in Form von Patches anbietet und öffentlichen Zugriff auf den Quellcode ermöglicht. Es ist demnach gleichermaßen ein Werkzeug für die Zusammenarbeit von Entwicklern und für die Softwareverteilung [112].
(100) SourceForge.net [113] ist ein freier Onlinedienst (Hosting Service) für Open Source Software-Entwickler, welcher von einer Gruppe von Anhängern freier Software betrieben und von VA Linux Systems unterstützt wird. Er bietet Softwareentwicklern verschiedenartige Hilfsmittel für die Verwaltung und die Betreuung ihres Projekts sowie Interessierten unterschiedliche Möglichkeiten der Beteiligung. Zu den zur Verfügung stehenden Mitteln zählen bspw.:
(101) SourceForge.net vereint nicht nur verschiedene Hilfsmittel für den Informationsaustausch und die Organisation eines freien Softwareprojekts, sondern bietet darüber hinaus mit CVS, einer Datenbank und der Möglichkeit, Software auf unterschiedliche Plattformen zu portieren, wichtige Werkzeuge für den eigentlichen Software-Entwicklungsprozess.
(102) Dienste wie SourceForge.net [114], die eine umfangreiche DV-technische Infrastruktur für freie Softwareprojekte an zentraler Stelle vereinen, können eine wesentliche Erleichterung für sämtliche Beteiligten eines solchen Projekts darstellen und einen beschleunigten Projektverlauf begünstigen [115].
(103) Der Ablauf kommerzieller Softwareprojekte besteht i.d.R. aus einer Folge systematisch geplanter Aktivitäten. Zu den bekanntesten Software Engineering- Modellen, die einen solchen Verlauf abbilden, zählt das sog. Wasserfall- Modell, welches die Vorgehensweise der Softwareentwicklung als das kaskadenartige Durchlaufen einer Reihe klar definierter Phasen beschreibt [116]. Wie jedoch in Abschnitt 3.2.2.1 bereits dargestellt wurde, lässt sich auf freie Softwareprojekte keines der üblichen Phasenkonzepte gänzlich übertragen [117].
(104) Der eigentliche Prozess der Softwareentwicklung innerhalb einer Open Source- Community dagegen ähnelt der Methode des evolutionären Prototyping (Rapid Prototyping). Auch in freien Softwareprojekten werden laufend - aufgrund von Patches, Bug Reports und Feature Requests - Modifikationen an der getesteten Software vorgenommen, bis diese die geforderte bzw. gewünschte Funktionalität erreicht hat. Beiden Vorgehensweisen gemeinsam ist somit die Tatsache, dass in einem kontinuierlichen Prozess eine erste, möglichst frühzeitig realisierte und vorgelegte Version schrittweise erweitert wird [118].
(105) Diejenigen Ereignisse und Tätigkeiten, welche sich als typisch für freie Softwareprojekte und insbesondere für deren Software-Entwicklungsprozess herausgestellt haben, sollen im folgenden modellartig dargestellt werden. Dieses Modell soll und kann jedoch kein Referenzmodell für die OSS-Entwicklung darstellen, sondern lediglich den für derartige Projekte üblichen Verlauf illustrieren [119].
(106) Zur Darstellung des Projektverlaufs wird auf die Methode der Ereignisgesteuerten Prozessketten (EPK) zurückgegriffen. Nachfolgend sollen die wesentlichen Merkmale dieser Methode kurz erläutert werden [120].
(107) EPK haben die Darstellung der zeitlich-logischen Abfolge von Funktionen zum Gegenstand. Über das Konzept der Ereignissteuerung können dynamische Prozesse abgebildet werden. Funktionen und Ereignisse, die durch logische Verknüpfungsoperatoren zueinander in Beziehung gebracht werden, stellen demnach die wesentlichen Elemente für eine Prozessmodellierung dar.
(108) Eine Funktion im Sinne einer Aufgabe stellt eine durch physische oder geistige Aktivitäten zu verwirklichende Sollleistung dar. Funktionen werden durch Ereignisse ausgelöst.
(109) Unter einem Ereignis wird der Eintritt eines definierten Zustands, welcher eine Folge von Aktivitäten bewirken kann, verstanden. Ereignisse können demnach Funktionen auslösen.
(110) Mögliche Verknüpfungsarten sind:
(111) Abbildung 3.4.1/1 zeigt die zur Darstellung der Elemente benutzten Symbole.
(112) In Abbildung 3.4.2/1 erfolgt zunächst die Darstellung derjenigen Ereignisse und Tätigkeiten, welche gewöhnlich zum Beginn, zur Übernahme von oder zur Teilnahme an freien Softwareprojekten führen [121].
(113) Abbildung 3.4.2/2 zeigt den typischen Verlauf des eigentlichen Software- Entwicklungsprozesses aus der Sicht eines sich nicht nur auf die Verwaltung und Koordination des Projekts beschränkenden Maintainers.
(114) [1] Vgl. Grassmuck (2001a).
[2] Vgl. Lerner/Tirole (2000), S. 3. Eric S. Raymond formuliert es folgendermaßen: "Every good work of software starts by scratching a developer's personal itch." Raymond (2001d), S. 23.
[3] 1999 waren es z.B. bei Perl etwa 100 Beteiligte weltweit, bei Debian GNU/Linux ca. 500 und bei XFree86 ca. 600, vgl. O'Reilly & Associates (Hrsg.) (1999), Ronneburg (2001) sowie Hohndel (2001). Daneben gibt es unzählige Projekte, an denen - aufgrund ihrer Bedeutung, ihres Bekanntheitsgrades oder ihres Fortschritts - nur wenige, mitunter sogar nur ein einziger Entwickler auf lokaler Ebene, z.B. an einer Universität, arbeiten.
[4] Vgl. Abschnitt 3.3.1.
[5] Dirk Hohndel, Mitglied des Board of Directors' des XFree86-Projekts, erläutert hierzu:"Wir haben keine bezahlten Mitarbeiter ... [und] basieren vollkommen auf freier Mitarbeit." Hohndel (2001).
(115) [6] Vgl. Dalheimer (2001).
[7] Vgl. Abschnitt 4.3.
[8] Theoretische Überlegungen über die Verhaltensmotive von Menschen finden sich z.B. in der Maslow'schen Motivationstheorie, vgl. Maslow (1954) und Maslow (1971).
[9] Ähnliche Überlegungen hinsichtlich der Motivation von Softwareentwicklern finden sich in Lerner/Tirole (2000), S. 14 - 19.
[10] "It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work." Raymond(2001d), S. 61. Lakhani/von Hippel sprechen in diesem Zusammenhang von "intrinsically-rewarding tasks", Lakhani/von Hippel (2001), S. 10.
(116) [11] Vgl. Glasl (2001). "In such situations, having a taillight to follow is a proxy for having strong central leadership." Valloppillil (2001).
[12] Matthias Dalheimer, Mitglied des K Desktop Environment-Projekts (KDE), erläutert hierzu: "Wir haben keinen Entwickler, dessen einzige Motivation das Gehalt oder der Wunsch ist, seinen Job nicht zu verlieren. ... Unsere Motivation ist der Ruhm, den man sich mit dieser Arbeiterwerben kann." Eine Konsequenz hieraus sei zudem qualitativ hochwertige Software, denn Anerkennung und hohes Ansehen seien nur erreichbar, wenn gute Arbeit geleistet wird. Vgl. Glasl (2001). Eric S. Raymond prägte für eine solche Gemeinschaft, dessen Mitglieder durch freiwillige Beiträge zu öffentlichen Projekten um ihren Status wetteifern, den Begriff Gift Culture. Er schreibt: "... participiants compete for prestige by giving time, energy, and creativity away. .. In gift cultures, social status is determined not by what you control but by what you give away." Raymond (2001c), S. 65 und S. 80.
[13] Dies mag eine Erklärung dafür sein, dass diejenigen Tätigkeiten, welche eine vermeintlich geringe Herausforderung darstellen, z.B. die Erstellung einer Dokumentation, innerhalb der Open Source-Community als weniger attraktiv gelten. Für ein vergleichsweise unpopuläres und/oder wenig anspruchsvolles Projekt besteht somit die Gefahr, dass es schon bald aufgrund mangelnden Interesses eingestellt wird. Vgl. Lerner/Tirole (2000), S. 19 und S. 34 sowie Behlendorf (1999), S. 159.
[14] Vgl. Raymond (2001c), S. 84 f. Innerhalb der Open Source-Community gilt es daher als schwerwiegendes Fehlverhalten, jemanden aus der Liste der Projektteilnehmer zu streichen, vgl. Lerner/Tirole (2000), S. 19 f.
[15] Vgl. Glasl (2001).
(117) [16] In ihrer Untersuchung über die Apache Newsgroup comp.infosystems.www.servers.unix (CIWS-U) kommen Karim Lakhani und Eric von Hippel zu folgendem Ergebnis: "... information providers (and seekers) report that the most important reason they read CIWS-U is to learn: they gain valuable information from reading about problems other users are encountering, and how these might be solved." Lakhani/von Hippel (2001), S. 23.
[17] Sun Microsystems und Netscape Communications wurden bspw. durch die ehemaligen OSS-Entwickler William Joy bzw. Jim Clark gegründet, vgl. Lerner/Tirole (2000), S. 14 f. und Lerner/Tirole (2001), S. 822 f.
[18] Matthias Ettrich, Begründer des KDE-Projekts, führt über einen solchen Verfechter freier Software aus: "Das hehre Ziel, mehr Freiheit in die Welt zu bringen, wiegt ihm mehr als sein persönlicher Vorteil." Ettrich (2001).
[19] Vgl. Abschnitt 2.2.
[20] Vgl. Lerner/Tirole (2001), S. 822. Rishab Aiyer Ghosh begründet eine solche Überzeugung von OSS-Entwicklern damit, dass sie ihre Projektbeiträge als eine Art Bezahlung für die Ideen verstehen, die sie von der Community erhalten haben. Jeder Teilnehmer erziele somit einen mehr als fairen Ertrag in Form der kombinierten Beiträge anderer. Vgl. Ghosh (2001).
(118) [21] Grassmuck (2001a).
[22] Vgl. Raymond (2001b), S. 10 - 15.
[23] Vgl. Grassmuck (2001c).
[24] Vgl. Fogel (2000), S. 129, Lerner/Tirole (2000), S. 19 und S. 21 sowie The K Desktop Environment (Hrsg.) (2001a). Die Funktionstüchtigkeit der ersten Versionen kann mitunter von entscheidender Bedeutung für den Erfolg des Projekts sein. Jamie Zawinski, ehemaliger Angestellter von Netscape Communications, behauptet, einer der wesentlichen Gründe für das vermeintliche Scheitern des Mozilla-Projekts sei, dass der ursprünglich herausgegebene Quellcode aufgrund zu vieler Fehler nahezu unbrauchbar war. Vgl. Zawinski (2001).
[25] Vgl. Fogel (2000), S. 126 und Köppen/Nüttgens (2000), S. 234.
(119) [26] Der Initiator bzw. Betreuer eines (Teil-)Projekts ist in der OSS-Terminologie dessen Maintainer.
[27] "If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource." Raymond (2001d), S. 38. Vgl. ebenso Fogel (2000), S. 139 ff.
[28] Vgl. Lerner/Tirole (2000), S. 23 f.
[29] Vgl. Fogel (2000), S. 33.
[30] Vgl. Abschnitt 3.3.
(120) [31] Vgl. Grassmuck (2001a) und Nüttgens/Tesei (2001b), S. 6. Eine solche modulare Struktur lässt sich ebenfalls sehr gut beim Apache-Projekt beobachten, vgl. Behlendorf (1999), S. 150 f.
[32] Vgl. Grassmuck (2001a) und Lerner/Tirole (2000), S. 32.
[33] Vgl. Ghezzi/Jazayeri/Mandrioli (1991), S. 18 - 36. Ähnliche softwarebezogene Qualitätsmerkmale finden sich in Balzert (2001), S. 1102 f. und in Schwander (1996), S. 18.
[34] Der verhaltensorientierte Aspekt betrifft weniger eine bestimmte Geisteshaltung oder Denkweise, sondern vielmehr das konkrete Verhalten aufgrund dieser Überzeugung. Vgl. Schwander (1996), S. 140 f.
[35] Vgl. Yeh (1993), S. xx.
(121) [36] Vgl. Lerner/Tirole (2000), S. 18 und Deutsche Gesellschaft für Qualität (Hrsg.) (1995), S. 18 - 26 und S. 87 f.
[37] Vgl. Deutsche Gesellschaft für Qualität (Hrsg.) (1995), S. 18 - 26.
[38] Vgl. Raymond (2001d), S. 30 f.
[39] Köppen/Nüttgens (2000), S. 231.
[40] Vgl. Köppen/Nüttgens (2000), S. 231. Sozialwissenschaftler fanden schon vor Jahren heraus, dass die gemittelte Meinung einer Menge von gleich kompetenten Beobachtern zuverlässigere Vorhersagen erlaubt als die eines einzelnen, willkürlich bestimmten Beobachters. Sie prägten hierfür den Begriff Delphi-Effekt. Vgl. zum Delphi-Effekt bzw. zur Delphi-Methode bspw. Linstone/Turoff (Hrsg.) (1975).
(122) [41] Die Open Source-Community befindet sich hiermit - wohl eher unbeabsichtigt - in der Tradition der akademischen Wissenschaftsverfassung, wie sie in der Gelehrtenrepublik des 19. Jahrhunderts entstand. In ihrem Grundsatz von der Trennung von Erkenntnis und Eigentum fordert sie u.a. die Veröffentlichung von Forschungsergebnissen, um sie in einem Peer Review-Prozess überprüfen, kritisieren und fortschreiben zu können. Vgl. Grassmuck (2001a).
[42] Vgl. z.B. BMWi (Hrsg.) (2001), S. 21.
[43] Vgl. Raymond (2001f), S. 222 f.
[44] Die sog. Halloween-Dokumente aus dem Jahr 1998 waren zunächst Microsoft-interne und vertrauliche Analysen von OSS im Allgemeinen und von GNU/Linux im Speziellen, wurden jedoch Eric S. Raymond zugespielt und anschließend veröffentlicht. Microsofts ursprünglicher Titel des ersten Teils lautet: "Open Source Software: A (New?) Development Methodology", vgl. Valloppillil (2001). Weltweit bekannt wurde dieses Dokument vor allem aufgrund der dort beschriebenen Strategien, mit denen Microsoft einer weiteren Verbreitung von GNU/Linux entgegenwirken kann.
[45] Vgl. Valloppillil (2001).
(123) [46] Im selben Dokument jedoch widerspricht der Autor z.T. seiner Aussage, indem er darlegt, dass neuartige Ideen der Grundlagenforschung als erstes unter GNU/Linux implementiert würden und verfügbar seien, vgl. Valloppillil (2001).
[47] Vgl. Grassmuck (2001a) und O'Reilly (2001).
[48] "Insight comes from individuals." Raymond (2001f), S. 222. Vgl. zudem Schwander (1996), S. 97 und S. 127 f. Lerner/Tirole entgegnen dem: "... the probability that the innovation is made need not increase with the number of developers, as free-riding is stronger when the number of potential developers increases." Lerner/Tirole (2000), S. 18. Der Erfolg freier Software lässt jedoch vermuten, dass - neben den verhaltensorientierten Aspekten - die Rahmenbedingungen, welche die Entwicklung derartiger Software auszeichnen, wie z.B. die uneingeschränkte Modifizierbarkeit des Quellcodes und die für jeden offen stehende Teilnahme, einen positiven Einfluss auf die Wahrscheinlichkeit innovativer Entwicklungen haben können.
[49] Vgl. Abschnitt 3.2.2.2.
[50] Vgl. Fogel (2000), S. 27 und S. 207 - 211.
(124) [51] Vgl. Abschnitt 3.1.5.
[52] Vgl. Mundie (2001).
[53] Benutzer können bspw. per eMail in direkten Dialog mit den Entwicklern bzw. Betreuern treten.
[54] Vgl. Abschnitt 3.1.5.
[55] Vgl. Glasl (2001) und Eilebrecht (2001). Dave Clark von der Internet Engineering Task Force (IETF) formulierte es folgendermaßen: "We reject: kings, presidents, and voting. We believe in: rough consensus and running code." Borsook (2001). Die genannten Entscheidungsprobleme können z.B. die Integration verschiedener Funktionalitäten, die Nachfolge des aktuellen Maintainers oder die Art und Weise der Anerkennung von Projektbeiträgen betreffen.
(125) [56] Vgl. Abschnitt 3.2.1.2.
[57] Vgl. Raymond (2001c), S. 103 f.
[58] Beispiele hierfür sind die Trennung des XEmacs vom GNU Emacs, diejenige des egcs vom gcc sowie die verschiedenen BSD UNIX-Varianten. Vgl. Raymond (2001c), S. 72.
[59] Ursachen hierfür können nicht nur in einer fachlichen Überforderung zu finden sein, sondern gleichermaßen in der Überlastung des Maintainers: "... I would like to point out that leaders of successful OSS projects get so much e-mail that just reading it may constitute a substantial workload. ... To create a successful product, you need to sacrifice time and energy." Bezroukov (2001).
[60] Vgl. Fogel (2000), S. 151 und Raymond (2001c), S. 85.
(126) [61] Vgl. Hill/Fehlbaum/Ulrich (1994), S. 17.
[62] Vgl. Grochla (1995), S. 24.
[63] Vgl. Grassmuck (2001b).
[64] Vgl. Dalheimer (2001).
[65] Vgl. Dalheimer (2001). Vereinzelt lässt sich in der Open Source-Community beobachten, dass die Betreuer eines Teilprojekts nach dem Rotationsprinzip ständig untereinander wechseln. Vgl. Lerner/Tirole (2000), S. 6 und S. 12.
(127) [66] Vgl. Lerner/Tirole (2000), S. 21.
[67] Vgl. Dalheimer (2001). Da die Aufnahme in das Core Team in einem solchen Fall "als Belohnung für individuelle Begabung, persönlichen Einsatz und die unbestreitbare Leistung" (Young (1961), S. 144.) erfolgt, beruhen derartige Projekte auf einer Meritokratie (Herrschaft der Verdienten). Vgl. Grassmuck (2001b). Plausible und überlegte Entscheidungen sind ebenfalls hinsichtlich der Zusammensetzung der Projektleitung wichtig, da sich benachteiligt fühlende Teilnehmer jederzeit ihre Beteiligung beenden können. Vgl. Bezroukov (2001).
[68] Die Ankündigung von IBM, mit der Apache Group zusammenarbeiten zu wollen, veranlasste letztere bspw. zu der Gründung der Apache Software Foundation. Vgl. Grassmuck (2001b).
[69] Vgl. Software in the Public Interest (Hrsg.) (2001).
[70] Vgl. The Apache Software Foundation (Hrsg.) (2001c).
(128) [71] Vgl. Eilebrecht (2001).
[72] Vgl. Grochla (1995), S. 25.
[73] Vgl. Balzert (2001), S. 55 und Schwander (1996), S. 1.
[74] Manche Unternehmen bieten jedoch kommerziellen Support für OSS an, vgl. hierzu Abschnitt 4.2.
[75] Vgl. Balzert (2001), S. 1090 - 1093.
(129) [76] Vgl. Fogel (2000), S. 208 ff.
[77] Vgl. Raymond (2001d), S. 47 sowie Abschnitt 3.1.3.1.
[78] Raymond erklärt hierzu: "Given enough eyeballs, all bugs are shallow." Raymond (2001d), S. 30.
[79] Seine Überlegungen testete er an fetchmail, einem freien Softwareprojekt, welches er selbst koordinierte und betreute. Aufgrund dieser Erfahrungen und weiteren Beobachtungen übertrug er die Ergebnisse seiner Analyse der GNU/Linux-Entwicklung auf OSS-Projekte im Allgemeinen. Raymond prägte für das OSS-Entwicklungsmodell den Begriff Basarmethode.
[80] Vgl. Lerner/Tirole (2000), S. 21 f.
(130) [81] Linus Torvalds bspw. veröffentlichte anfangs mehrere aktualisierte Versionen des Linux-Kernels an nur einem Tag, vgl. Raymond (2001d), S. 29.
[82] OSS-Entwickler betrachten die Integration ihrer Vorschläge und Beiträge oft als Belohnung für ihre Mitarbeit. Vgl. Raymond (2001d), S. 30 und Behlendorf (1999), S. 161.
[83] Vgl. Lerner/Tirole (2000), S. 21 und Bezroukov (2001).
[84] Auch im kommerziellen Bereich setzt sich zunehmend die Erkenntnis durch, zukünftige Benutzer der Software frühzeitig in deren Entwicklungsprozess einzubeziehen, jedoch vorwiegend vor dem Hintergrund, die Software möglichst optimal an die Möglichkeiten und Bedürfnisse der Benutzer anzupassen sowie Anregungen für zusätzliche Funktionalitäten zu erhalten. Vgl. Schwander (1996), S. 136 ff. und Lerner/Tirole (2001), S. 822.
[85] Dementsprechend lässt sich beobachten, dass viele Anwender Korrekturen selbst vornehmen und testen, noch bevor sie diese an den Betreuer des Projekts weiterleiten. Vgl. Raymond (2001d), S. 38.
(131) [86] Brooks war Manager bei IBM und Leiter des OS/360-Projekts.
[87] Ein Resultat seiner Untersuchungen ist als Brooks' Gesetz bekannt: "Adding manpower to a late software project makes it later." Brooks (1975), S. 25.
[88] In der DV-Terminologie bezeichnet ein Bug einen technischen, syntaktischen oder logischen Fehler in der Hard- oder Software. Das Lokalisieren, Analysieren und Korrigieren dieser Fehler wird Debugging genannt, vgl. Deutsche Gesellschaft für Qualität (Hrsg.) (1995), S. 88.
[89] Vgl. Raymond (2001d), S. 32 f.
[90] Vgl. Fogel (2000), S. 152 f.
(132) [91] Vgl. Biethahn (1996), S. 195 und Mertens/Bodendorf/König/Picot/Schumann (1996), S. 196 f.
[92] Eine Ausnahme bildet das KDE-Projekt. Matthias Dalheimer erläutert hierzu: "Es gibt einen Rahmenplan, der den Tag der Veröffentlichung und die einzelnen Arbeitsfortschritte bestimmt." Jedoch sei es ohne weiteres möglich, "den Tag der Veröffentlichung um einen Monat zu verschieben, wenn wir merken, dass wir sonst die angestrebte Qualität nicht erreichen können." Vgl. Glasl (2001). Darüber hinaus ist bei einem OSS-Projekt, welches das Concurrent Versions System (CVS, vgl. Abschnitt 3.3.2.) einsetzt, ohnehin der Zugriff auf den tagesaktuellen Stand der Entwicklung möglich.
[93] Im Unterschied zu einem Code Freeze sind bei einem sog. Feature Freeze "kleinere Verbesserungen dann erlaubt, wenn sie an isolierter Stelle eingebaut werden und (theoretisch) den Quelltext nicht destabilisieren können." Hierbei kann es sich z.B. um die Ausgabe von Fehlermeldungen handeln. Da sich jedoch ein Code Freeze nur schwer von einem Feature Freeze unterscheiden lässt, werden die beiden Begriffe meist synonym zueinander verwendet, vgl. Fogel (2000), S. 293.
[94] Vgl. bspw. The K Desktop Environment (Hrsg.) (2001b).
[95] Hierunter fallen bspw. Ausgaben für Hardware, etwa für leistungsfähige Rechner, oder für Leistungen, die im Zusammenhang mit der Anbindung an das Internet in Anspruch genommen werden.
(133) [96] Vgl. bspw. VA Linux Systems (Hrsg.) (2001a).
[97] Vgl. Biethahn (1996), S. 196 und Mertens/Bodendorf/König/Picot/Schumann (1996), S. 170.
[98] Vgl. Eilebrecht (2001) und Glasl (2001).
[99] Vgl. z.B. Lehmann (2001), Ronneburg (2001) oder Dalheimer (2001).
[100] Mailinglisten dienen der Kommunikation via eMail. Auf einem sog. Listserver werden die eMail-Adressen aller eingetragenen Nutzer abgelegt. Der Listserver selbst ist über eine feste eMail-Adresse erreichbar. Sobald einer der eingetragenen Nutzer eine eMail an den Listserver sendet, leitet dieser die Nachricht an alle anderen eingetragenen Nutzer weiter. Vgl. Institute for Telecommunication Sciences (Hrsg.) (2001).
(134) [101] Auf IRC greifen nur wenige freie Softwareprojekte, wie z.B. The GIMP, zurück.
[102] Zu den Mailinglisten des KDE-Projekts gehören bspw. eine Liste für Anwender, auf der sich diese untereinander helfen können, eine Liste für Programmierer für Fragen hinsichtlich Entwurf und Entwicklung, eine Liste für Autoren und Übersetzer der Dokumentation, eine Liste für Lizenzfragen und eine geschlossene Liste für das Core Team, auf der bspw. über Fragen des Marketing und über die Öffentlichkeitsarbeit diskutiert wird. Vgl. Dalheimer (2001).
[103] Vgl. Lehmann (2001).
[104] Vgl. Lehmann (2001). Gleichermaßen kann die Bildung einer offiziellen Projektleitung auf derartige Ursachen zurückzuführen sein, vgl. Bezroukov (2001).
[105] Fogel (2000), S. 27 f.
(135) [106] Vgl. Fogel (2000), S. 29 und S. 39.
[107] Vgl. Fogel (2000), S. 29 f.
[108] Ein sog. Konflikt liegt vor, wenn zwei oder mehrere Entwickler gleichzeitig unterschiedliche Veränderungen an ein und derselben Stelle des Quellcodes vornehmen, vgl. Fogel (2000), S. 41.
[109] CVS-Repository ist in etwa mit CVS-Archiv zu übersetzen. Es handelt sich hierbei um den "Ort, an dem die Hauptquelltexte mit den Veränderungshistorien aufbewahrt werden." Fogel (2000), S. 30.
[110] Eine detaillierte Beschreibung der Funktionalität des CVS findet sich in Fogel (2000).
(136) [111] Fogel (2000), S. 30.
[112] Vgl. Fogel (2000), S. 143.
[113] Vgl. VA Linux Systems (Hrsg.) (2001a).
[114] Neben SourceForge.net gibt es noch weitere, z.T. kommerzielle Onlinedienste mit einem vergleichbaren Leistungsumfang. Vgl. hierzu Abschnitt 4.2.
[115] Obwohl SourceForge.net erst im November 1999 gegründet wurde, beläuft sich die Anzahl der hierüber koordinierten OSS-Projekte zum 2001-10-17 auf 28.039. 273.566 registrierte User wurden an diesem Tag gezählt. SourceForge.net gilt als der führende Application Service Provider (ASP) für OSS-Entwickler weltweit.
(137) [116] Vgl. Ghezzi/Jazayeri/Mandrioli (1991), S. 360 - 374.
[117] Davon abgesehen würde die Anwendung eines Phasenkonzepts aufgrund des Umfangs und der Komplexität zahlreicher freier Softwareprojekte einen unverhältnismäßigen Mehraufwand bedeuten.
[118] Vgl. Biethahn/Mucksch/Ruf (1996), S. 213 - 216, Yeh (1993), S. 8 und Fogel (2000), S. 218 ff.
[119] Grundlage dieser modellartigen Darstellung sind die bisherigen Ausführungen sowie vor allem Raymond (2001d) und Fogel (2000), S. 125 - 128, weshalb auf weitere Erläuterungen hierzu an dieser Stelle verzichtet werden soll.
[120] Vgl. zu den weiteren Ausführungen über Ereignisgesteuerte Prozessketten u.a. Scheer (1992) und Keller/Nüttgens/Scheer (2001).
[121] Alternative Ereignisse und Tätigkeiten, die nicht in diesen Entscheidungen resultieren, bleiben unberücksichtigt.
Kapitel 4: Ökonomische Implikationen (138) Zurück:
Vorwort
Inhalts- und Abkürzungsverzeichnis
Kapitel 1: Einleitung
Kapitel 2: Grundlagen