Seminararbeit: Open Source Software Entwicklung Wie kann der Erfolg von Open Source Projekten definiert bzw. gemessen werden?

Transkript

1 Seminararbeit: Open Source Software Entwicklung Wie kann der Erfolg von Open Source Projekten definiert bzw. gemessen werden? Lernveranstaltungsleiter: o. Univ. Prof. Dkfm. Dr. Wolfgang H. Janko Univ.-Ass. Mag. Dr. Stefan Koch Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft Wirtschaftsuniversität Wien Ausgearbeitet von: Jozef Puchon MatrNr.:

2 Stichworte: Open Source, die Motivation, der Erfolg, die Entwicklung, die Bewertung Keywords: open source, motivation, prosperity, development, evaluation Abstract Open Source is the new catchword for a phenomenon, which has been existing in the EDP already since the 70s, namely free software. In the early times of the data processing, it was completely normal that the developers exchanged their source code, i.e. the base of their products, among themselves, and so they helped one another and improved themselves.e.g. the UNIX Business System and a broad field of applications originated also on this basis. My work does not deal with comprehension, how an Open Source program comes to its existence, which Open Source types can be developed and which business models can be used, but my analysis settles with the question how a success of Open Sorce can be overall measured. Also the whole concept of my work undergoes to it. Einführung Open Source ist das neue Schlagwort für ein Phänomen, das es schon seit den 70er Jahren in der EDV gibt, nämlich freie Software. In der Frühzeit der Datenverarbeitung war es völlig normal, dass die Entwickler ihren Quellcode, also die Basis ihrer Produkte, untereinander austauschten und sich somit auch gegenseitig halfen und verbesserten. Auf dieser Basis entstanden zum Beispiel auch das Betriebssystem UNIX und ein breites Feld von Anwendungen. In meiner Arbeit geht es nicht um das Verständnis, wie ein Open Source Programm entsteht, welche Arten von Open Source entwickelt werden können und welche Geschäftsmodelle verwendet werden können, sondern meine Analyse setzt sich mit der Frage wie kann man Erfolg von Open Source überhaupt messen auseinander. Dem wird auch die ganze Konzeption meiner Arbeit unterlegt. 2

3 Inhaltsverzeichnis 1.Open-Source-Software Einführung Definition Warum gibt es Open-Source-Software? Open Source Merkmale Freie Weiterverbreitung Quellcode Abgeleitete Arbeiten Unversehrtheit des Quellcodes von Autoren Keine Diskriminierung von Personen oder Gruppen Keine Einschränkungen von Einsatzmöglichkeiten der Software Verbreitung der Lizenz Die Lizenz darf nicht für ein bestimmtes Produkt gelten Die Lizenz darf andere Software nicht einschränken Die Lizenz muss technologisch neutral sein Anreize, Interessen und Motive Motivation für die Entwickler Motivation für die Beteiligten Erfolgsfaktoren von Open-Source-Produkten Einführung Sicherheitsargumente für Open Source Software Das Viele Augen -Argument Das Fehlersuche ist nur im Quellcode möglich -Argument Das Besserer Code -Argument Das Unabhängigkeitsargument Erfolgsfaktoern für den Einsatz Anforderungsanalyse und Leistungsspezifikation Evaluation der Produkte Einsatz von "stable Releases" Aktivität der Entwickler-Community Verbreitung des Produkts Aktivität der Nutzer-Community Berücksichtigung von Standards Professioneller Support Organisatorische Implementierung Bewertungsmaßstäbe für den Erfolg von Open Source-Projekten Einführung Messgröße für den Erfolg Entwicklerzahl Lebenszyklusphase / Alter des Projekts Marktanteils der Software / Bekanntheitsgrad Anzahl der Diskussionsforen bzw. Chat Rooms Erhebung der Erfolgsmaße Datenerhebung Beobachtung Fragebogen Interview

4 3.3.2 Datenauswertung Deskriptive Statistiken (beschreibende Statistik, empirische Statistik) Indukative Statistik (schließende Statistik, mathematische Statistik) Praxisbeispiele von erfolgreichen Open source Produkten Einführung Linux Apache Web Server Mozilla- Firefox Azureus...23 Literaturverzeichnis...25 Internetquellen

5 1.Open-Source-Software 1.1 Einführung Um Open Source Software (OSS), vor allem die für diese Arbeit relevante Erfolg von Open Source Projekten, verstehen und analysieren zu können, ist es notwendig die Grundlagen über Open Source Software im Griff zu haben. Aus diesem Grund beschreibe ich im Kapitel 1 eine Einführung in die Theorie von Open Source Programmen. Mit dieser Basistheorie soll ein Verständnis über die Anreize, Motive, Kosten usw. aufgebaut werden 1.2 Definition Open Source Software umschreibt wie der Begriff schon andeutet, Software, deren Quellcode ( Source Code ) im Gegensatz zu Closed Source Software für jedermann frei zugänglich ist. Jeder Benutzer sollte die Software nicht nur verwenden dürfen, sondern auch die Freiheit haben, sie zu kopieren, zu vertreiben, zu studieren, zu verändern und zu verbessern. 1.3 Warum gibt es Open-Source-Software? Die Philosophie von Open Source Software geht zurück auf den Grundgedanken des freien Austauschs von Wissen und Gedanken. Software kann, wie auch Ideen, jedem frei zur Verfügung gestellt werden - ohne Verluste. Wird Software weitergeben, entwickelt sie sich wie in einem evolutionären Prozess. 1.4 Open Source Merkmale Die Open Source Definition stellt in der Version 1.9 die folgenden zehn Anforderungen an Open Source Softwarelizenzen Freie Weiterverbreitung Die Software kann uneingeschränkt weiterverbreitet werden. Das Verkaufen bzw. Weitergeben ist dann allerdings als Dienstleistung zu verstehen, da in der Lizenz für einen solchen Vertrieb keine Gebühren verlangt werden dürfen. 1 [Open Source Initiative 2006 ] 5

6 1.4.2 Quellcode Die Lizenz muss die Weitergabe sowohl für den Quellcode als auch für die kompilierte Form erlaubt sein. Der Quellcode muss in einer verständlichen Form verbreitet werden. Der Quellcode darf nicht unverständlich geschrieben sein, noch sich in einer Zwischenform befinden (z.b. vorkompliliert) Abgeleitete Arbeiten Veränderungen und Derivate müssen zugelassen sein. Diese müssen unter der gleichen Lizenz veröffentlicht werden können Unversehrtheit des Quellcodes von Autoren Die Lizenz darf die Distribution des Quellcodes in modifizierter Form nur dann einschränken, wenn die Lizenz die Verwendung sogenannter Patch-Dateien vorsieht, um das Programm zur build time zu modifizieren. Die Lizenz kann fordern, dass Weiterentwicklungen einen anderen Namen oder eine andere Versionsnummer tragen. Dadurch sollen Originalcode und veränderter Code ganz eindeutig differenzierbar bleiben und die Nutzer sollen erkennen können, welcher Autor für welchen Code zuständig ist Keine Diskriminierung von Personen oder Gruppen Die Lizenz darf Personen oder Gruppen nicht benachteiligen. Niemand darf von der Weiterentwicklung ausgeschlossen werden Keine Einschränkungen von Einsatzmöglichkeiten der Software Die Nutzung der Software darf durch die Lizenz nicht für bestimmte Anwendungsgebiete begrenzt werden. Dies gilt auch für die kommerzielle Nutzung oder die Anwendung in umstrittenen Einsatzgebieten Verbreitung der Lizenz Die zu dem Programm gehörenden Rechte gelten für alle, an die es verbreitet wurde, ohne eine zusätzliche Lizenz beziehen zu müssen. 6

7 1.4.8 Die Lizenz darf nicht für ein bestimmtes Produkt gelten Die zu dem Programm gehörenden Rechte dürfen nicht davon abhängig sein, dass sie Teil einer speziellen Distribution sind. Wenn das Programm aus dem Software-Paket herausgenommen wird, gelten weiterhin für alle dieselben Rechte am Programm, als wenn sie mit der originalen Distribution vergeben worden wären Die Lizenz darf andere Software nicht einschränken Die Lizenz darf die Weitergabe der Software gemeinsam mit anderen Programmen nicht einschränken, dass alle anderen Programme Open Source sein müssen Die Lizenz muss technologisch neutral sein Es dürfen keine bestimmten Technologien oder Arten von Schnittstellen vorgeschrieben und andere damit ausgeschlossen werden. 1.2 Anreize, Interessen und Motive 23 Was motiviert die Entwickler-Innen, Benutzer auf die Teilname von Open Source Projekten? Motivation für die Entwickler - eigenes Problem lösen: Mit der Hilfe von anderen Entwickler kann die Lösung des Problems leichter gefunden werden - Lernen, Weiterbildung: Der Wunsch, seine Fähigkeiten, Erfahrungen als Softwareentwickler zu verbessern. - Anerkennung, Ego: 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 - eigenen Berufsaussichten zu verbessern: Mitarbeiter an besonders großen und prestigeträchtigen Open Source Projekten können damit z.b. auch ihren Lebenslauf aufwerten. 2 [Benno Luthiger] 3 [HERTEL, Guido] 7

8 - Identifikation mit der Gruppe: Die Identifikation mit der Community bezieht sich sehr eng an die menschlichen Bedürfnissen nach Liebe und Zugehörigkeit. Die Mitglieder der Community sehen die anderen Mitglieder als ihre Verwandten an und sind daher bereit, etwas für sie zu tun. - Kreativität: Für viele professionelle Softwareentwickler ist der Antrieb aber auch gerade die Auslebung eigener Kreativität, bzw. Einschränkungen bei der täglichen Arbeit Motivation für die Beteiligten - source code einsehbar (wichtig für bestimmte Zielgruppen) - volle Kontrolle über die Verwendung der Software: Die im Programm eingesetzten Verfahren sind jederzeit auf ihre Korrektheit und Sicherheit überprüfbar. - Möglichkeit zu Feedback und Fehler eliminieren: Feedback zu geben und Fehler zu melden geben das Gefühl etwas zurückzugeben und so zum Projekt beizutragen. - direkter Support: Möglichkeit in direkten Kontakt mit den Entwicklern zu treten. - keine Lizenzkosten: Wichtigstes Argument für Open Source Software ist meist das Fehlen von Lizenzkosten zu sein. 8

9 2. Erfolgsfaktoren von Open-Source-Produkten 2.1 Einführung In dem Kapitel 2 gehe ich auf die beeinflussenden Erfolgsfaktoren von OSS ein. Die Faktoren werden auf Sicherheitsargumente, Erfolgseinsatzargumente von OSS geteilt und näher beschrieben. 2.2 Sicherheitsargumente für Open Source Software 4 Es gibt vier hauptsächliche Sicherheitsargumente für Open Source Software.1.Die Quellcode kann von vielen Personen begutachtet und kontrolliert werden (das Viele Augen - Argument).2. Der Fehler und Hintertüren können überhaupt nur im Quellcode gefunden werden (das Fehlersuche ist nur im Quellcode möglich -Argument). 3 Open Source Software zeichnet sich generell durch besseren Code aus (das Besserer Code -Argument). 4. Entwickler von Open Source Software sind unabhängig von kommerziellen Interessen (das Unabhängigkeitsargument) Das Viele Augen -Argument Das Argument der vielen Augen ist nun die Behauptung, dass die so entwickelte Software sicherer wird, da man annimmt, dass die Fehlerrate in der Software deutlich sinkt, wenn sehr viele Entwickler immer und immer wieder den Quellcode auf Fehler hin untersuchen. Der daraus resultierende Software-Entwicklungs-Prozess ist effizienter als bei Entwicklung proprietärer Software. Grundvoraussetzung dafür, dass dieses Prinzip greifen kann, ist allerdings zum einen, dass genügend viele Entwickler aktiv daran beteiligt sind und zum anderen, dass diese über hinreichend fundierte technische Kenntnisse verfügen, um Sicherheitslücken aufspüren und beheben zu können Das Fehlersuche ist nur im Quellcode möglich -Argument Die Programmierer von Open Source Software argumentieren, dass das Suchen und Finden von Fehlern und Hintertüren (z.b. durch freiwillige Softwareentwickler) nur auf der Basis von Quellcode möglich ist. Diese Annahme ist nicht ganz korrekt. Es gibt schon heute Werkzeugen (insbesondere Debugger und Dekompiler), die auch aus einem Maschinencode 4 [Sich. Beurteilung] 9

10 einen funktional korrekten Quellcode erzeugen können und das bedeutet, dass das Finden von Fehler auch in einen Maschinecode möglich ist Das Besserer Code -Argument Die Verfechter von Open Source Software behaupten, dass alleine die Tatsache, dass der Quellcode offen gelegt ist, dazu führe, dass sich die Entwickler besser an Programmierrichtlinien zur Erstellung von gutem und qualitativ hochstehendem Quellcode halten. Es wird angenommen, dass ein Softwareentwickler zwar guten und qualitativ hochstehenden Quellcode erzeugen kann, aber er tut das vielleicht im Rahmen von Closed Source Software nicht, weil er nicht fürchten muss, dass andere Personen seinen Quellcode anschauen und kritisch bewerten. Auf der andern Seite ist es aber fraglich, ob ein Softwareentwickler seinen Programmierstil ändert, nur weil möglicherweise andere Personen die von ihm entwickelte Software im Quellcode sehen können Das Unabhängigkeitsargument Bei dem Unabhängigkeitsargument von Open Source Software wird behauptet, dass die Entwickler von Open Source Software grundsätzlich nicht an die kommerziellen Interessen gerichtet sind.damit wird bestimmte Freiheit erzielt, die auch höhere Kreativität bringen kann. Dieses Unabhängigkeitsargument ist teilweise richtig. Man kann nämlich niemals sagen, welche Antriebsmotive hinter der Entwicklung von Open Software versteckt sind. 2.3 Erfolgsfaktoren für den Einsatz 5 Die Erfolgsfaktoren für den Einsatz von Open-Source-Software sind in vielen Punkten im Vergleich mit kommerzieller Software sehr ähnlich. Warum sollte das auch anders sein? Nur weil die Software kostenlos herunterladen ist? Dennoch müssen beim Einsatz von Open- Source-Produkten noch einige zusätzliche Aspekte beachtet werden Anforderungsanalyse und Leistungsspezifikation Als Erste sollte wie bei jeder Softwareanschaffung zuerst das Einsatzszenario geplant werden und die daraus resultierenden Anforderungen festgelegt und gewichtet werden. Daraus kann man notwendige Funktionalitäten und ihre Wichtigkeit ableiten. 5 [Efolgsfaktoren 2006] 10

11 2.3.2 Evaluation der Produkte Die in Frage kommende Open Source Software muss anhand der Anforderungsspezifikation intensiv bewertet und definiert werden. Bei diesem Prozess werden eventuelle Schwächen bezüglich der technischen Stabilität und Produktreife aufgedeckt Einsatz von "stable Releases" Bei der Auswahl der in Frage kommenden Produkte sollten nur "stable Releases" berücksichtigt werden. Open-Source-Programme gibt es im Allgemeinen als Stable Releases und Experimental Releases. Die Stable Releases sind ausgiebig getestete Programm- Versionen, die stabil laufen. Die Experimental Releases hingegen befinden sich noch in der Entwicklung Aktivität der Entwickler -Community Ein zentrales Element jedes Open-Source-Projektes ist die Aktivität der Entwickler Community, durch die es getragen wird. Es sollten in regelmäßigen Abständen neue Versionen mit neuen Releases veröffentlicht werden Verbreitung des Produkts Das Produkt muss möglichst auf vielen Anwender verbreitet werden. Das stellt sicher, dass neue Versionen von vielen Anwendern getestet und evtl. Fehler schnell gefunden und beseitigt werden können. Auskunft über die Nutzer - Community sollte eine Liste von Referenzinstallationen geben, die im Internet verfügbar ist Aktivität der Nutzer - Community Ein wichtiger Aspekt für die zukünftige Entwicklung der Software ist ebenso die Aktivität der Nutzer - Community. In Supportforen, die in der Regel über die Homepages der Produkte zugänglich sind, tauschen sich die Anwender über ihre Erfahrungen und Probleme aus und helfen sich Gegenseitig bei der Lösung von Problemen. Außerdem werden in solchen Nutzerforen auch gewünschte Änderungen und Weiterentwicklungen der Tools diskutiert Berücksichtigung von Standards Das Aufsetzen auf häufig international verankerten Standards(wie z. BLOM und SCORM). sichert in der Regel ein größeres Maß an Unabhängigkeit von einem einzelnen Lieferanten 11

12 Dadurch wird eine Investitionsfalle vermieden, die auftreten kann, wenn ein Produktwechsel erforderlich wird, z. B. wenn durch das Produkt die eigenen Anforderungen nicht mehr abgedeckt werden Professioneller Support Ein besonders wichtiger Aspekt für den erfolgreichen Einsatz von Open Source Software ist die Existenz von professionellem Support. Bis vor einiger Zeit fehlten professioneller Support und Service für Open-Source-Produkte weitgehend. Das hat sich geändert. Längst gibt es Dienstleister, die die Arbeit mit Open-Source-Programmen zur Geschäftsgrundlage gemacht haben. Hinzu kommt die kostenlose Unterstützung aus dem Internet: In Newsgroups und Mailing- Listen helfen sich Tausende von interessierten Open-Source-Anwendern und - Entwicklern gegenseitig Organisatorische Implementierung Wie auch bei der Implementierung von kommerzieller Software erfordert die Einführung einer Open Source Software Maßnahmen zur Organisationsentwicklung, wie z. B. Schulungen der Mitarbeiter, für die finanzielle Mittel zur Verfügung stehen müssen. Auch für den nachhaltigen Betrieb und einen eventuellen späteren Ausbau müssen personelle und finanzielle Mittel eingeplant werden. 12

13 3. Bewertungsmaßstäbe für den Erfolg von Open - Source- Projekten 3.1 Einführung In diesem Kapitel werden zunächst die Messgrößen für den Erfolg erklärt und nachfolgend werden die Erhebungsmethoden für die Messung des Erfolges vorgestellt. 3.2 Messgröße für den Erfolg Messgröße für den Erfolg sind schwer definierbar und können nicht exakt festgelegt werden aber ich versuchte aus meiner Sicht relevante Messgroße zu beschreiben Entwicklerzahl 6 Ein mögliches Maß für den Erfolg kann die Anzahl von Entwickler sein. Im Jahre 2002 wurde eine Floss-Studie durchgeführt, wo Open Source Projekte nach der Anzahl der Entwickler untersucht werden. Die Studie zeigte, dass die meisten Projekte einen oder zwei Entwickler ( ,71%)hatten, 109 Projekte weißten nur von Entwickler(0,6%) auf und nur sieben Projekte (0,04%) erreichten mehr als 500 Entwickler. Quelle: Software Source Code Survey 6 [Software Source Code Survey] 13

14 Probleme bei der Messung von Arbeitsintensität der Entwickler Nicht alle Entwickler / Projekte sind registriert Es gibt inaktive Entwickler, die jedoch als Entwickler auftreten, aber keine aktive Mitarbeit aufweisen (Programmierer wird als aktiv definiert, wenn er in dem betrachteten Zeitraum z.b. ein Monat mindestens einen Checkin durchgeführt hat) Aus der Studie kann man sehen, dass nur die besten und erfolgreichen Projekte mehr als 100 Entwickler gewinnen. Für einen Entwickler sind verschiedene Kriterien wichtig. Das Ziel der Projekts muss attraktiv sein 7 Der Entwickler beteiligt sich nur dann, wenn er ein ganz persönliches Interesse an diesem Projekt hat. Dabei kann das Interesse in ganz unterschiedlichen Bereichen liegen. z.b.: Diese Software brauche ich zu Lösung eines speziellen Problems Diese Software sollte mal geschrieben werden Das Projekt muss öffentlich zugreifbar sein Alle Dokumente und der vollständige Quellcode des Projekts müssen leicht über das Internet erreichbar sein Von Anfang an muss die Software verwendbar sein Ein reiner Benutzer ist nur an lauffähiger Software interessiert. Auch jemand, der sich an der Weiterentwicklung beteiligen will, wird eher anhand eines lauffähigen Prototyps die Attraktivität eines Projektes bewerten. Mit dem freiwilligen Zusammenschluss zur Entwicklungsarbeit ist jedoch auch die Gefahr verbunden, dass Projekte austrocknen können. Wenden sich die Entwickler neuen, aus ihrer Sicht interessanteren und evtl. visibleren Projekten zu, kann es dazu kommen, dass Projekte aufgrund fehlender Unterstützung nicht zu Ende geführt werden Lebenszyklusphase / Alter des Projekts Als nächstes Erfolgsmaß kann man unter die Lebenszyklusphase finden. 7 [Bernd Brügge] 14

15 Auf der Seite unterscheidet man den Development Status nach 1. Planning, 2. Pre-Alpha, 3.Alpha, 4. Beta, 5. Production/Stable, 6. Mature und 7. Inactive. In der Planungsphase hat man ausschließlich eine Idee. Es ist noch kein Code geschrieben worden. Mit dem ersten Code steigt das Projekt in die Pre-Alpha Phase ein. Dabei liegen die ersten meistens Experimentiercode vor, welche nicht zwingend kompiliert werden können. Kann der Code oder ein Teil davon kompiliert werden und kann man eine Richtung des Projektes erkennen, so spricht man von Alpha. Sind die meisten Funktionalitäten hinzugefügt, Code ist ausreichend stabil, führt man Beta- Software ein. Diese Phase kann noch beträchtliche Fehler erhalten. Sind die meisten Fehler im Programm korrigiert und für den täglichen Gebrauch geeignet, spricht man von Stable-Software. Kompakte Software, die man schon länger verwenden kann und keine neuen konkreten Fehler mehr aufweist wird als Phase Mature genannt. In diese Phase werden nur noch kleinste Änderungen an der Software durchgeführt, falls überhaupt. Projekte, die vorläufig nicht weiterentwickelt werden fallen unter die Kategorie Inactive. Es kann auch den Fall vorliegen, dass die Software, die sich stable bzw. Mature Zustand befindet, parallele Phasen (z.b. Stable und Beta) aufweist. Bei diesem Fall geht es darum, dass die Entwickler neu ungetestete Tätlichkeiten, Verbesserungen einsetzen wollen und das führt zum parallelen Entwicklungsphasen, von denen meistens einer stable bleibt und nur noch korrigiert wird, und andere sich im Alpha- oder Betazustand befinden. Das kommt aber meisten nur bei großen Projekten vor. Interessant ist die Verteilung der Projektstatik über eine große Zahl von Projekten anzusehen, dargestellt in Tabelle: Entwicklungszustand Anzahl der Projekte Planning Pre-Alpha Alpha Beta Production/Stable Mature 1468 Inactive 2097 Quelle: SourceForge.net (Stand ) 15

16 Die meisten Open Source Projekte auf der Seite Sourceforge.net befinden sich in der Planungsphase (Planning, Pre-Alpha, Alpha). Die Erfolgszahlen für wenig überlegte Projektideen scheinen nicht sehr hoch zu sein. Das kann damit erklärt werden, dass es sehr einfach in ein Projekt einzusteigen ist, aber Weiterführung der Software ist sehr oft problematisch. Man kann argumentieren, dass zumindest die ersten Funktionalitäten (Planning, Pre-Alpha oder Alpha) vom Autor selbst entworfen werden müssen, damit das Projekt auch für andere Entwickler attraktiv war. Davon kann man die Schlussfolgerung ableiten, dass den meisten Erfolg von Open Source Programmen erst bei den letzten zwei Phasen erreicht werden kann Marktanteils der Software / Bekanntheitsgrad Am wichtigsten Erfolgsmaß für Benutzer, Unternehmen scheint sehr logisch Markanteils der Software zu sein. Zwar ist es generell schwierig den Marktanteil von Open Source zu messen, da wegen der kostenlosen Downloadmöglichkeiten nahezu keine Verkaufszahlen vorliegen, dennoch wird versucht aus den Zugriffsstatistiken von Webseiten Informationen über den Verbreitungsgrad der Web-Browser und Betriebssysteme zu erlangen. Wie sieht die Problematik von Marktgröße und Marktwachstum aus. Die Problematik wir anhand eines Beispiels dargestellt 8. Die Marktforschungsfirma IDC schätzt, dass der gesamte Linux OSS-Markt(Desktop und Server), der sicherlich der wichtigste Bereich des OSS- Marktes überhaupt ist, im Jahre 2007 ein Volumen von US $ 170 Millionen haben wird. Das entspricht einer durchschnittlichen Wachstumsrate von Jahre 2002 an beginnend von ca. 14 %. Die Analysten der Credit Suisse First Boston halten diese Prognose für reichlich konservativ. In einem Report vom rechnen sie vor, das gerade der Servermarkt erheblich mehr Dynamik aufweist und unter realistischen Annahmen über den Server-Hardwareabsatz, die Vorinstallierungsraten mit dem Linux - Betriebssystem und die Preisentwicklung von einem Marktvolumen von annähernd US $ 350 Millionen ausgegangen werden kann, was einem durchschnittlichen jährlichen Wachstum von 60 % entspräche. Es gibt auch ganz andere Schätzungen, so hat das deutsche Marktforschungsunternehmen Soreon Mitte 2003 allein den deutschen Unternehmensmarkt für OSS auf 131 Millionen Euro geschätzt und prognostiziert, dass im Jahre 2007 ein Volumen von 307 Millionen Euro erreicht werden kann. So beeindruckend diese Zahlen sind, 8 [Gläßer, Lothar] 16

17 so sehr muss allerdings beachtet werden, dass das Marktvolumen im OSS im Vergleich zum Marktvolumen der Softwareindustrie insgesamt eher bescheiden ist. Auf jedem Fall sind die Prognose der OSS Zahlen (Marktanteil, Wachstumsrate) nicht eindeutlich definierbar Anzahl der Diskussionsforen bzw. Chat Rooms Ein Diskussionsforum von Open Source ist ein Ort, wo sich die Entwickler, Benutzer zum Austausch von Gedanken und Erfahrungen treffen. So wird vielen Entwickler Benutzern eine Hilfestellung angeboten, die besonders für spezielle Probleme oder bei nur wenigen anderen Informationsquellen die einzige Hilfe ist. (z.b.: Quellcodeproblem).Bei den erfolgreichsten und verbreiteten Open Source Programme(z.B.: Linux, Apache WebServer) stehen den Entwickler, Benutzer, eine große Anzahl von Diskussionsforen zur Verfügung. Erfüllungskriterien der Diskussionsforen - Internes Nachrichtensystem für alle Nutzer mit Verwaltung der eigenen Nachrichten und Profil - Versand der Nachrichten intern und/oder extern an die -Adresse - Nachrichten an Gruppen - Diskussionsforen mit verschiedenen Sichten (Wer hat zuletzt geantwortet? Wer hat auf wen geantwortet?) - Anfügen von Dateien an Diskussionsbeiträge - Administration der Foren und Inhalte 3.3 Erhebung der Erfolgsmaße Wen man die Erfolgsmaße herausfinden, analysieren will, braucht man dazu Informationen, Wissen, die mit der Hilfe von Erhebungstechniken gut definiert, festgelegt werden können. Bei dem Open Source Programmen finden vor allem die quantitativen Verfahrend wie Beobachtung Befragung, Interview seine Relevanz. 17

18 3.3.1 Datenerhebung Beobachtung Ziel der Beobachtung ist es, den Untersuchungsgegenstand des jeweiligen Interesses möglichst genau zu erfassen. Sie ist eine grundlegende Methode der Datengewinnung und Faktensammlung zum Zeitpunkt des Geschehens. Mittels Beobachtung kann man auf dem Internet verschiedene Diskussionsforen, Chat Rooms, Community-Aktivitäten beobachten und daraus Intensität der Beiträgen, Anzahl der Beteiligten genau festlegen und beschreiben. (Ist mein Open Source ausreichend attraktiv? Sind die Entwickler für die Zusammenarbeit interessiert?...) Andersartige Beobachtung ist z.b. Messen von Zugriffen auf eine Webseite, die danach mit deskriptiver Statistik umfassend ausgewertet und interpretiert werden können Fragebogen Ein Fragebogen ist eine spezielle Art von Fragenkatalog, als Instrument der Datenerhebung für eine/mehrere Statistik-en. Meist wird derselbe Fragebogen mehreren Personen vorgelegt und dann statistisch ausgewertet. Man unterscheidet zwischen Papier- und elektronischen Fragebogen. Bei der Open source Problematik werden vor allem Fragen im Bezug auf Qualität, Zufriedenheit, Meinungen, Verbesserungen gestellt Interview Bei einem Interview ist eine Befragung durch Fragesteller (sogenannte Interviewer) mit dem Ziel, persönliche Informationen oder Sachverhalte zu ermitteln. Es werden meist dieselben Fragen wie bei einem Fragebogen gestellt, aber der grundlegende Unterschied liegt bei der realen Interaktion zwischen Befragtem und Interviewer Datenauswertung Deskriptive Statistiken (beschreibende Statistik, empirische Statistik) Mit der vorliegende Daten in geeigneter Weise beschrieben und zusammengefasst werden. Mit ihren Methoden verdichtet man quantitative Daten zu Tabellen, graphischen Darstellungen und Kennzahlen. (Marktanteils, Veränderung des Marktanteils, Umsätze) 18

19 Indukative Statistik (schließende Statistik, mathematische Statistik) In der induktiven Statistik leitet man aus den Daten einer Stichprobe Eigenschaften einer Grundgesamtheit ab. Die Wahrscheinlichkeitstheorie liefert die Grundlagen für die erforderlichen Schätz- und Testverfahren. (z.b. Prognose einer Software über den Marktanteil im Jahr 2007,) 19

20 4. Praxisbeispiele von erfolgreichen Open source Produkten 4.1 Einführung Im Kapitel 4 beschäftige ich mich mit den bekanntesten Open Source Programme. Vor allem werden die Hintergründe zu der Frage untersucht Warum OSS so erfolgreich und bekannt ist? Linux 9 Als populärster Vertreter der quelloffenen Software darf das Betriebssystem Linux, oder genauer gesagt, GNU/Linux gelten. Seit Linus Torvalds es 1991 unter die GPL gestellt hat, haben viele tausend freiwillige Entwickler, aber auch Unternehmen, Verbesserungen beigesteuert und die Weiterentwicklung des Systems vorangetrieben. Die Zuverlässigkeit ist eine der klaren Stärken von Linux. Die Stabilität des Linux Kernels ist herausragend, Systemabstürze sind unter diesem Betriebssystem eine absolute Ausnahme. Die Bedrohung durch Viren und Würmer ist minimal. Auch wenn die Aufmerksamkeit der Schadsoftwareprogrammierer durch seine steigende Verbreitung zukünftig auch vermehrt auf Linux gerichtet werden könnte, so bietet Linux doch einige entscheidende Vorteile durch seine Architektur. Da ein normaler Benutzer unter Linux ohne Systemrechte arbeitet kann, ist der mögliche Schaden etwa durch Viren auch lokal begrenzt. Linux ist ein sehr leistungsfähiges Betriebssystem, das sich auch für den Betrieb in einer Hochleistungsumgebung eignet. Aufgrund der freien Verfügbarkeit von Linux ist die Abschätzung seines Marktanteils entsprechend schwierig. Schätzungen gehen von einem Marktanteil 10 von ca 3.3% auf Clients und rund 25% auf Servern aus. Linux kann derzeit in Bezug auf den Marktanteil auch stark zulegen. Man geht von einer Verdopplung des Marktanteils auf dem Client in den nächsten Jahren und von einem weiteren starken Wachstum im Serverbereich aus. 9 [Barth, Wolfgang] 10 [Linux- Browser Statistics] 20