Inhaltsverzeichnis
1 Einführung
2 Grundlagen
2.1 Definitionen
2.1.1 Open Source Definition
2.1.2 Definition der Freien Software
2.2 Lizenzen
2.2.1 Public Domain
2.2.2 BSD
2.2.3 Artistic License
2.2.4 GPL
2.2.5 LGPL
2.3 Open Source Entwicklungsgeschichte
3 Open Source und Wirtschaft
3.1 Akteure und ihre Rollen
3.1.1 Rollen und Motivation von Personen
3.1.2 Organisationen
3.1.3 Öffentlicher Sektor
3.2 Betriebswirtschaftliche Potentiale
3.2.1 Unternehmen als Anwender
3.2.2 Unternehmen als (Mit-)Entwickler
3.2.3 Unternehmen als Dienstleister
3.3 Makroökonomische Perspektive
3.4 Praxisbeispiel: Das BerliOS-Projekt
4 Merkmale von Open Source Projekten
4.1 Größenmerkmale
4.1.1 Codelänge und Entwicklerzahl
4.1.2 Unterprojekte
4.2 Strukturmerkmale
4.2.1 Organisationsstruktur
4.2.2 Ablaufstruktur und Release-Prozess
4.3 Entwicklungsspezifische Merkmale
4.3.1 Entwicklungszustand
4.3.2 Betriebssystem
4.3.3 Programmiersprache
4.3.4 Aktivitätsgrad
4.3.5 Versionierung
4.4 Benutzerspezifische Merkmale
4.4.1 Zielgruppe
4.4.2 Benutzerschnittstelle
4.4.3 Sprache
4.4.4 Themenbereich
4.5 Kommunikations- und Präsentationsinfrastruktur
4.5.1 Web-Seiten
4.5.2 Mailing-Listen und Newsgroups
4.5.3 Entwicklerwerkzeuge
4.6 Dokumentation
4.6.1 Produktbezogene Dokumentation
4.6.2 Projektbezogene Dokumentation
5 Fallbeispiele
5.1 SourceForge.net: AWStats
5.1.1 Merkmale
5.1.2 Infrastruktur
5.1.3 Dokumentation
5.1.4 Zusammenfassung
5.2 Horde
5.2.1 Merkmale
5.2.2 Infrastruktur
5.2.3 Dokumentation
5.2.4 Zusammenfassung
5.3 FreeBSD
5.3.1 Merkmale
5.3.2 Infrastruktur
5.3.3 Dokumentation
5.3.4 Zusammenfassung
5.4 Debian
5.4.1 Merkmale
5.4.2 Infrastruktur
5.4.3 Dokumentation
5.4.4 Zusammenfassung
5.5 Zusammenfassung Fallbeispiele
6 Resümee
A Lizenz für die freie Nutzung unveränderter Inhalte
Literaturverzeichnis
Tabellenverzeichnis
1 Fünf häufigste Lizenztypen in Sourceforge
2 Wichtige Open Source Meilensteine
3 Open Source Projekte nach der Bytegröße
4 Open Source Projekte nach der Entwicklerzahl
5 Kategorisierung von OSS Projekten nach Codegröße und/oder Entwicklerzahl
6 SourceForge.net Projekte - Entwicklungszustand
7 SourceForge.net Projekte - Betriebssysteme
8 SourceForge.net Projekte - 10 häufigste Programmiersprachen
9 SourceForge.net Projekte - Zielgruppe
10 SourceForge.net Projekte - Benutzerschnittstellen
11 SourceForge.net Projekte - 10 häufigste natürliche Sprachen
12 SourceForge.net Projekte - 10 häufigste Themenbereiche
13 AWStats: Entwicklungsspezifische Merkmale
14 AWStats: Benutzerspezifische Merkmale
15 Horde: Entwicklungsspezifische Merkmale
16 Horde: Benutzerspezifische Merkmale
17 Horde: allgemeine Mailing-Listen
18 FreeBSD: Entwicklungsspezifische Merkmale
19 FreeBSD: Benutzerspezifische Merkmale
20 Debian: Entwicklungsspezifische Merkmale
21 Debian: Benutzerspezifische Merkmale
22 Fallbeispiele: Vergleich - Projektgröße
23 Fallbeispiele: Vergleich - Projektleitung
24 Fallbeispiele: Vergleich - Merkmale
25 Fallbeispiele: Vergleich - Kommunikation, Dokumentation
Abbildungsverzeichnis
1 BerliOS
2 AWStats: Projektseite
3 Horde: Homepage
4 FreeBSD: Homepage in Deutsch
5 Debian: Sitemap
1 Einführung
Dem universitären, akademischen Ursprung entwachsen, stellt freie Software heute einen nicht zu unterschätzenden, wirtschaftlichen Faktor dar. (Sieckmann, 2001, Kap 1.1)
Wie das Zitat von Sieckmann andeutet, ist die Rolle der freien Software (Open Sour- ce) in der Wirtschaft immer bedeutender, unabhängig davon ob der betroffene Akteur als Benutzer oder Entwickler tätig ist. Es entstand eine neue Ressource, die nach betriebswirt- schaftlichen Grundsätzen möglichst effizient zu nutzen ist. Aus dieser Überlegung können Fragen abgeleitet werden, wie, wo, wann und von wem diese Ressource effizient genutzt werden kann oder ob sie überhaupt einen Nutzen stiften kann. Praxis zeigt aber, dass eine sehr große Menge an Open Source Projekten im Internet geführt wird, was bereits sehr gut das Entwicklungsportal SourceForge.net (SourceForge.net, 2003f) demonstriert. Über dieses oder ähnliche Systeme kann eine große Anzahl an Softwareentwicklern aus der ganzen Welt an Projekten aus fast allen Software-Bereichen arbeiten.
Diese Arbeit beschäftigt sich mit einem Ausschnitt der Open-Source-Welt, und zwar der Struktur und Funktionsweise der bereits existierenden Open Source Projekte. Hierzu werden am Anfang der Arbeit (Kap. 2) die grundlegenden Open Source Begriffe erläutert und einige der bekanntesten Open Source Softwarelizenzen vorgestellt, die später in der Arbeit untersuchte Softwareprojekte (Kap. 5) betreffen. Zusätzlich zu den Grundlagen werden im Kapitel 3 die Beziehungen zwischen der Open Source Softwareentwicklung, Privatpersonen und Wirtschaft sowie die betriebswirtschaftlichen Potentiale von Open Source Software im Überblick erläutert.
Das Kern der Arbeit ist eine Aufschlüsselung wichtiger Aufbau- und Ablaufmerkmale von Open Source Projekten (Kapitel 4) in Bezug auf deren Struktur, Entwicklung und Benutzer (Zielgruppe). Anhand dieser Merkmale sollten beliebige Open Source Softwa- reprojekte beschrieben und zum Teil auch kategorisiert werden können. Durch eine solche Kategorisierung soll einerseits die Forschung mittels durchgängiger Termini erleichtert, andererseits die Organisation eigener sowie die Auswahl fremder Open Source Projekte durch die Wirtschaft unterstützt werden. Im abschließenden Kapitel (5) werden die ent- sprechenden Merkmale bei vier existierenden Open Source Projekten - AWStats, Horde, FreeBSD und Debian identifiziert und anschließend teilweise verglichen.
2 Grundlagen
Dieses Kapitel liefert einen Überblick über die wichtigsten Begriffe, Lizenzen und eine kurze Zusammenfassung einiger wichtiger Ereignisse in der Entwicklungsgeschichte von Open Source.
2.1 Definitionen
In diesem Unterkapitel werden wichtige Grundbegriffe definiert, die in der Arbeit ausführ- lich behandelt werden. Mit den folgenden Definitionen wird geregelt, wann ein Programm als Open Source Software und wann als Freie Software bezeichnet werden kann.
2.1.1 Open Source Definition
Bruce Perens, Mitglied des Debian Projekts verfaßte die Grundlagen der Open Source Definition in den ”Debian-Richtlinien für Freie Software” (Debian-Projekt, 2003e). Diese wurden vom Debian-spezifischen Aussagen bereinigt und von der Open Source Initiative als Version 1.0 der Open Source Definition1 festgelegt (Open Source Initiative, 2003c).
Die ”Open Source Definition” (Quelle: Open Source Initiative, 2003c), stellt in der Version 1.9 explizit die folgenden zehn Anforderungen an Open Source Softwarelizenzen:
1. Freie Weitergabe
Die Lizenz darf die Weitergabe (Schenkung oder Verkauf) der Software in Paketen von Programmen verschiedenen Unsprungs nicht einschränken. Für die Weitergabe dürfen keine Gebühren verlangt werden.
2. Quellcode
Die Weitergabe muß sowohl für den Quellcode als auch für die kompilierte Form erlaubt sein. Wird der Quellcode in die Distribution nicht integriert, muß eine Mög- lichkeit bestehen, diesen frei beziehen zu können (z.B. aus dem Internet) oder zum Selbstkostenpreis zu erwerben. Der Quellcode darf nicht unverständlich geschrieben sein, noch sich in einer Zwischenform befinden (z.B. vorkompliliert)
3. Abgeleitete Software
Veränderungen und Derivate müssen zugelassen sein. Diese müssen unter der glei- chen Lizenz veröffentlicht werden können.
4. Unversehrtheit des Quellcodes des Autors
Die Weitergabe vom veränderten Quellcode darf nur dann eingeschränkt werden, wenn die Lizenz die Verwendung sogenannter Patch-Dateien2 vorsieht. Die Lizenz darf den Programmnamen schützen, und die Weitergabe des veränderten Quellcodes nur unter einem anderen Programmnamen zulassen.
5. Keine Diskriminierung von Personen oder Gruppen
Die Lizenz darf eine Person oder eine Gruppe von Personen nicht benachteiligen.
6. Keine Einschränkungen bezüglich des Einsatzfeldes
Das Einsatzfeld der Software darf von der Lizenz nicht eingeschränkt werden.
7. Weitergabe der Lizenz
Die Rechte an der Software müssen automatisch an alle Personen weitergeleitet werden, die diese Software beziehen, ohne eine zusätzliche Lizenz beziehen zu müssen.
8. Die Lizenz darf nicht auf ein bestimmtes Produktpaket beschränkt sein
Die Rechte am Programm dürfen nicht davon abhängen, ob dieses Teil eines Softwa- repakets ist. Wenn das Programm aus dem Software-Paket herausgenommen wird, soll dies als Folge keine Einschränkungen der Rechte haben.
9. Die Lizenz darf die Weitergabe zusammen mit anderer Software nicht ein- schränken.
Die Lizenz darf die Weitergabe der Software gemeinsam mit anderen Programmen nicht einschränken. (z.B. daß alle anderen Programme Open Source sein müssen)
10. Die Lizenz muß technologie-neutral sein
Keine Klausel der Lizenz darf sich an eine bestimmte Technologie, Stil oder Schnitt- stelle stützen.
Jede bei der Open Source Initiative eingereichte Lizenz, wird auf die Übereinstimmung mit der Open Source Definition geprüft. Entspricht diese Lizenz der Definition, wird sie in die Liste der sog. ”OSI-zertifizierten Lizenzen” aufgenommen. (Open Source Initiative, 2003d)
2.1.2 Definition der Freien Software
Der Begriff ”Freie Software” wird oft mit Open Source gleichgesetzt. Die Definition dieses Begriffs stammt vom GNU-Projekt und baut auf vier Arten von Freiheiten auf (Quelle: GNU-Projekt, 2003a), die jedem Benutzer der Software gewährt werden sollen:
- Freiheit 0
Die Freiheit, das Programm für jeden Zweck zu benutzen
- Freiheit 1
Die Freiheit, zu verstehen, wie das Programm funktioniert und wie man es für seine Ansprüche anpassen kann. Der Zugang zum Quellcode ist dafür Voraussetzung.
- Freiheit 2
Die Freiheit, Kopien weiterzuverbreiten, so daß man seinem Nächsten weiterhelfen kann.
- Freiheit 3
Die Freiheit, das Programm zu verbessern und die Verbesserungen der Öffentlichkeit zur Verfügung zu stellen, damit die ganze Gemeinschaft davon profitieren kann. Der Zugang zum Quellcode ist dafür Voraussetzung.
2.2 Lizenzen
Die im Abschnitt 2.1 vorgestellten Definitionen üben einen relativ großen Einfluss auf die Gestaltung von Softwarelizenzen aus. Alle Open Source Lizenzen haben einige gemein- same Merkmale. Zu diesen Merkmalen gehört, dass jede Open Source Lizenz jegliche Art von Garantie oder Gewährleistung für das Softwareprodukt ausschließt (siehe aufgelistete Lizenzen in Open Source Initiative, 2003d).
Lerner und Tirole führten in 2002 eine Untersuchung der Lizenzvorgaben von 38.610 Sourceforge-Projekten1 durch (Lerner und Tirole, 2002). Aus den Resultaten kann man die fünf häufigsten Lizenztypen ablesen – diese sind in Tabelle 1 zusammengefasst. Von diesen Lizenzen sind alle außer Public Domain OSI-zertifizierte Lizenzen (siehe 2.1.1). Eine Liste aller OSI-zertifizierter Lizenzen befindet sich auf den Webseiten der Open Source Initiative. (Open Source Initiative, 2003d)
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Fünf häufigste Lizenztypen in Sourceforge (Quelle: Lerner und Tirole, 2002, table 1)
Lerner und Tirole stellten zwei kritische Merkmale von Open Source Lizenzen fest: (Lerner und Tirole, 2002, S. 2)
- Wenn die Lizenz verlangt, daß mit modifizierten Versionen immer auch der Quell- code veröffentlicht werden muß, wird sie als restriktiv eingestuft. Diese Klausel wird auch als “Copyleft” Klausel bezeichnet.
- Wenn die Lizenz untersagt, Teile des Quellcodes in andere Programme zu integrie- ren, ohne daß diese Programme zwingend unter derselben Lizenz stehen müssen, ist sie stark restriktiv.
Von diesen zwei Merkmalen ausgehend wurden die Lizenzen in drei Kategorien ein- gestuft: (Lerner und Tirole, 2002, S. 3)
- nicht-restriktive (z.B. BSD, siehe 2.2.2)
- restriktive (z.B. LGPL, siehe 2.2.5)
- stark restriktive (z.B. GPL, siehe 2.2.4)
In den folgenden Abschnitten werden die von Lerner und Tirole ermittelten fünf häu- figste Lizenztypen im Überblick vorgestellt.
2.2.1 Public Domain
Die Public-Domain Lizenz ist die schwächste Lizenzform und wurde von der Open Source Initiative nicht zertifiziert (siehe 2.1.1). Da absolut keine Autorenrechte oder Beschrän- kungen für die Weitergabe oder Verwendung der Software vorliegen, kann prinzipiell bezweifelt werden, ob Public Domain überhaupt als eine Lizenz einzustufen ist (siehe Rosen, 2002).
2.2.2 BSD
Software, dass unter der BSD-Lizenz steht (siehe Open Source Initiative, 2003b), kann im Prinzip uneingeschränkt genutzt werden. Der Code darf in kommerzielle Produkte inte- griert werden, eine Pflicht zur Weitergabe des Quellcodes besteht nicht (siehe Grassmuck, 2002, S. 279-281). Lediglich ein Copyright-Hinweis der (ursprünglichen) Entwickler und die Erwähnung der Universität von Berkeley (nur bei der originellen BSD-Lizenz) muss sowohl in binären und Quellcode-Distributionen, als auch in Programmen, in die Teile der Software integriert wurden, vorhanden sein. Diese Hinweise müssen auch bei Wer- bezwecken angeführt werden. Je nach Derivat der BSD-Lizenz können auch einige dieser Einschränkungen wegfallen. Software-Projekte, die unter einer BSD-Style Lizenz ent- wickeln sind z.B. FreeBSD, Apache (siehe Apache Software Foundation, 2003a), Post- greSQL (siehe PostgreSQL Global Development Group, 2002).
2.2.3 Artistic License
Die Hauptgedanke der ”Artistic Licence” ist, daß diese dem Author eine Art ”künstle- rische Kontrolle” über die Entwicklung verschafft (siehe Sieckmann, 2001, Kap. 4.2.4). Die Anwender dürfen die Software uneingeschränkt nutzen und Vervielfältigen. Die Au- toren behalten aber weiterhin das Recht über die Weiterentwicklung zu entscheiden. Eine Beispielvorlage für eine Artistic Licence befindet sich auf der Homepage der Open Sour- ce Initiative (Open Source Initiative, 2003a). Eines der bekannten Projekte mit diesem Lizenztyp ist die Programmiersprache Perl (für Lizenzlaut siehe perl.com, 1997).
2.2.4 GPL
Die vom GNU-Projekt bzw. der Free Software Foundation aufgestellte GPL Lizenz (= GNU General Public License) (GNU-Projekt, 2001b) gehört zur Klasse der stark restrik- tiven Lizenzen. Sie ist wahrscheinlich die am meisten verbreitete Open Source Lizenz (siehe Tabelle 1). Wie bei anderen bereits hier vorgestellten Lizenzen besteht Pflicht zur Quellcode-Veröffentlichung und die Software darf frei genutzt, weiterverbreitet und ver- ändert werden. Die besonderen Bestimmungen der GPL-Lizenz werden oft auch als ”Co- pyleft” bezeichnet. Diese verlangen, das Software, welches GPL-Lizenzierte Teile enthält, als abgeleitetes Werk anzusehen ist und die gleichen Lizenzbestimmungen enthalten muß (siehe Grassmuck, 2002, S. 281-286). Diese Klausel stellt prinzipiell ein ohne eine Lizenz- änderung nicht zu lösendes Problem für Kombinationen von Open Source und proprietärer Software dar. Eine Deutsche Übersetzung befindet sich in GNU-Projekt, 2001b. Ein be- sonders bekanntes Beispiel GPL-Lizenzierter Software ist das Betriebssystem Linux.
2.2.5 LGPL
Der Autor dieser Lizenz (LGPL = GNU Lesser Public License) ist genauso wie im Ab- schnitt 2.2.4 das GNU-Projekt. Diese Lizenz ist bis auf einige wenige punkte der GPL Li- zenz ähnlich. Sie wurde hauptsächlich für Funktions- bzw. Objektbibliotheken entwickelt. Programme, die diese Bibliotheken verwenden, werden nicht als abgeleitete Werke ange- sehen und unterliegen nicht der Copyleft-Einschränkung. Dies gilt aber nicht für Verän- derungen der Bibliothek selbst, diese müssen ebenfalls unter LGPL veröffentlicht werden (siehe Grassmuck, 2002, S. 289-293). Eine Deutsche Übersetzung befindet sich in GNU- Projekt, 1999.
2.3 Open Source Entwicklungsgeschichte
Die Vorgeschichte von Open Source beinhaltet die gesamte Entwicklung rund um das Betriebssystem UNIX (siehe Salus, 1994) und seine Nachfolger bzw. Derivate, schnelle Verbreitung des Internet und der neu entstandenen Hackerkultur (Raymond, 2001).
Einige der wichtigen Meilensteine (Working Group on Libre Software, 2000, Appendix
C) waren die Gründung des GNU-Projekts vom Richard Stallman in 1984, die Gründung der Free Software Foundation in 1985 und die Anfänge der freien BSD-Betriebssysteme sowie des Linux in 1991. Eine Zusammenfassung befindet sich in Tabelle 2.
Im GNU Manifest (GNU-Projekt, 1985,1993) wird eine neue Art von Softwareent- wicklung vorgestellt, die im Form von Gemeinschaftsprojekten zwischen Entwicklern und (aktiven) Benutzern entsteht und nicht nur freie Nutzung und Vervielfältigung, sondern auch öffentlich zugänglichen Quellcode beinhaltet. Die eigentlichen Anwender können selbst die Softwareentwicklung beeinflussen. Der Grad der Teilnahme am Projekt, sowie der Ein- und Austritt stehen im Prinzip jedem frei. Es besteht keinerlei Bindung. Viele Pro- jekte rund das GNU Projekt bzw. rund um BSD haben eine ähnliche Entwicklungspolitik und die im Kapitel 2.2 vorgestellten Lizenzen verwendet.
Vom GNU-Projekt wurde der Begriff ”freie Software” eingeführt (siehe 2.1.2). Laut Open Source Initiative wurde die Bezeichnung ”open source” das erste mal während eines Brainstorming bei einer strategischen Sitzung am 3.2.1998 in Palo Anto, Kalifornien, USA erwähnt. Die Sitzung reagierte auf die Ankündigung von Netscape, den Quellcode seines Web-Browsers freizugeben. Die Bezeichnung ist Chris Petersen eingefallen (siehe Open Source Initiative, 2003e). Im Februar 1998 wurde anschließend vom Bruce Perens die Open Source Initiative gegründet. Die Open Source Initiative ist eine gemeinnützige Organisation mit Sitz in Redwood City, Kalifornien, USA.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Wichtige Open Source Meilensteine (Quelle: Working Group on Libre Software, 2000, Appendix C)
3 Open Source und Wirtschaft
Dieses Kapitel beschäftigt sich hauptsächlich mit Personen und Organisationen, die in Open Source Projekten mitwirken bzw. diese unterstützen. Es werden Geschäftsmodel- le vorgestellt, mit denen die Teilnahme von gewinnorientierten Organisationen an Open Source Projekten erklärt wird.
3.1 Akteure und ihre Rollen
In den nachfolgenden Abschnitten werden die Akteure im Entwicklungsprozess mit ihren möglichen Rollen beschrieben. Grundsätzlich können diese in Personen, (kommerzielle und nicht-kommerzielle) Organisationen und staatliche Institutionen eingeteilt werden.
3.1.1 Rollen und Motivation von Personen
Dieser Unterabschnitt versucht zu erläutern, wieso und in welcher Form Privatpersonen an der Open Source Softwareentwicklung Teilnehmen. Nakakoji u. a. führten in 2002 eine Untersuchung der Rollenstruktur von Teilnehmern in Open Source Projekten durch (Na- kakoji u. a., 2002). Sie entwickelten ein aus acht Rollen bestehendes Zwiebelmodell, dass die Rollen der am Open Source Entwicklungsprozess teilnehmenden Personen umfasste. Es wurden folgende Rollen aufgezählt: (Quelle: Nakakoji u. a., 2002, Kap. 4.1.1):
- passive user
Der ”passive Anwender” steht im Verhältnis zum Projekt ähnlich wie bei der kom- merziellen Software. Er wird hauptsächlich von der Qualität bzw. Anpassungsfähig- keit der Software angezogen.
- reader
Den ”Leser” interessiert nicht nur die Nutzung, sondern auch die Struktur und Funk- tionsweise der Software. Dies erfährt er durch Einblicke in den Quellcode.
- bug reporter
Dieser Akteur entdeckt und berichtet Fehler und muss dabei nicht den Quellcode kennen. Diese Rolle entspricht den ”Testern” bei der kommerziellen Softwareent- wicklung.
- bug fixer
Der ”bug fixer” korrigiert entweder selbst erkannte oder vom ”bug reporter” be- richtete Fehler. Er beherrscht den Teil des Quellcodes, wo der Fehler zu korrigieren ist.
- peripheral developer
Die ”Peripherieentwickler” leisten gelegentlich Beiträge mit neuer Funktionalität oder Fähigkeiten für das Projekt. Ihre Teilnahme ist kurz, unregelmäßig und verein- zelt.
- active developer
”Aktive Entwickler” arbeiten regelmäßig an der Softwareerweiterung und Fehler- korrektur. Sie sind eine der wichtigsten Stützen von Open Source Projekten.
- core member
”Kernmitglieder” tragen die Verantwortung für die Führung und Koordination des Softwareprojektes. Ihre Anzahl ist meistens von der Projektgröße abhängig.
- project leader
Der ”Projektleiter” ist meistens auch der Projektgründer. Er ist für die Vision und die Bestimmung der allgemeinen Entwicklungsrichtung zuständig.
Lakhani und von Hippel setzen sich mit der Frage der Motivation von einzelnen Teil- nehmern auseinander, unentgeltlich Beiträge an Open Source Projekte zu leisten (Lakhani und von Hippel, 2000). Sie legen sich grundsätzlich auf drei Hauptmotive fest (Lakhani und von Hippel, 2000, Kap 1.0):
- Direkter Bedarf für Software
In diesem Fall ist der Beitragende gleichzeitig auch Anwender. Er ist hauptsächlich an der Fehlerkorrektur und Funktionserweiterung der Software interessiert.
- künstlerische Freude
Die Selbstverwirklichung bzw. die Verbesserung der eigenen Programmierfähigkei- ten gehören auch zur Gruppe möglicher Gründe.
- Reputation
Aktive Teilnahme an Open Source Entwicklungsprojekten kann das Ansehen des Entwicklers steigern und neue Karrieremöglichkeiten eröffnen.
3.1.2 Organisationen
In der Praxis nehmen sowohl gewinnorientierte Firmen wie z.B. Sun Microsystems (Sun Microsystems: SunSource.net, 2003), oder Netscape (Netscape, 2000), als auch gemein- nützige Organisationen wie z.B. Apache Foundation (Apache Software Foundation, 2003b) an der Open Source Entwicklung teil. Die Teilnahme der gewinnorientierten Organisatio- nen basiert meistens auf den im Kapitel 3.2 vorgestellten Geschäftsmodellen. Gemeinnützi- ge Organisationen, die Förderung von Open Source als Ziel haben, unterstützen im Prinzip entweder direkt einzelne selbstgeführte Open Source Projekte wie z.B. Apache Foundation (Apache Software Foundation, 2003b), oder bieten allgemeine Unterstützung durch Bereit- stellung von Infrastruktur an wie z.B SourceForge.net (SourceForge.net, 2003c, Sektion A1 ).
3.1.3 Öffentlicher Sektor
In diesem Unterabschnitt wird das Verhältnis der öffentlichen Hand und der Open Source Projekte näher eingegangen. Im zweiten Teil der umfangreichen Studie von IDA1 (IDA, 2001, Part 2) wird der Einsatz von Open Source Software im öffentlichen Bereich und die Unterstützung der Open Source Projekte in mehreren EU-Ländern sowie der Europäischen Union selbst untersucht.
Als Beispiel kann Deutschland genommen werden (IDA, 2001, Part 2, S. 37-44). Die Studie berichtet über den Einsatz von Open Source Software im öffentlichen Bereich (z.B. siehe Bundesministerium für Inneres, 2000), Propagieren in der Wirtschaft (siehe Bundesministerium für Wirtschaft und Arbeit, 2001) und direkte Unterstützung von Open Source Projekten (GNUPG2, INTERMiT).
Im dritten Teil der IDA Studie (IDA, 2001, Part 3, S. 15-21) werden in einer Umfra- ge Gründe ermittelt, warum Open Source Software im öffentlichen Sektor zum Einsatz kommt. Zu den wichtigsten Pro-Gründen gehören Interoperabilität, Sicherheit, Verfolgung von Standards, einfache Anwendbarkeit, niedrige Kosten und Verfügbarkeit des Quellco- des. Einige wichtige Gegenargumente sind gebundenes Kapital in bereits vorhandenen Lösungen, vertragliche Bindungen, Angst vor Budgetkürzungen und Fehlen von schlüs- selfertigen Distributionen.
Grundsätzlich stehen der Regierung folgende Möglichkeiten zur Verfügung, Open Source Projekte zu unterstützen (IDA, 2001, Part 3, S. 53-54):
- direkte Unterstützung
Die einfachste Möglichkeit ist direktes Finanzieren von Entwicklern.
- direkte Förderung der offenen Standards
Wegen des engen Zusammenhangs von Open Source Software und offenen Stan- dards stützt die Unterstützung offener Protokolle und Standards die Grundlagen der Open Source Projekte.
- indirekte Unterstützung
Durch Finanzierung im Forschungsbereich (z.B. der universitären Grundlagenfor- schung) werden Open Source Projekte indirekt gefordert.
- Anpassung der Gesetzgebung
Verbesserungen in der bestehenden Gesetzgebung, vor allem in Bereichen der Au- torenrechte und Anti-Trust Gesetze, sowie Einführung von neuen Regelungen, die Open Source Softwareenwicklung begünstigen, können die Aktivitäten im Open Source Bereich steigern.
3.2 Betriebswirtschaftliche Potentiale
Dieser Unterabschnitt behandelt das Verhältnis zwischen Unternehmen und Open Sour- ce. Die Beziehung der Wirtschaftssubjekte zu Open Source Entwicklungsprojekten kann Grundsätzlich auf drei Ebenen geschehen (siehe Grassmuck, 2002, S. 329-360), und zwar kann das Subjekt selbst Anwender, Entwickler oder Dienstleister rund um Open Source sein. Die folgenden Unterabschnitte beschreiben Geschäftsmodelle und Sichtweisen aus diesen drei Grundperspektiven.
3.2.1 Unternehmen als Anwender
Aus dieser Perspektive ist das Unternehmen selbst Anwender von Open Source Software,
d.h. es wird die Kostenseite betrachtet. Nach betriebswirtschaftlichen Grundsätzen sucht jedes Unternehmen nach dem besten Preis-/Leistungsverhältnis für nötige Softwarelösun- gen. Es sind aber nicht nur die Anschaffungskosten relevant sondern auch andere Kosten wie z.B. Kosten für Anpassungen, Betrieb, Wartung und Schulungen. Hier kommt der sog. ”TCO-Ansatz” (Total Cost of Ownership) zum Einsatz (Working Group on Libre Softwa- re, 2000, Kap 5.5). Dieser Ansatz versucht die gesamten Kosten zu erfassen, die mit der Anschaffung und Anwendung von Software und Hardware verbunden sind.
Was den Software Teil betrifft, hat das Unternehmen grundsätzlich drei Möglichkeiten, und zwar entweder nur Open Source, eine gemischte Lösung oder nur proprietäre Softwa- re zu wählen. Bei jeder Alternative haben die verschiedenen Kostenarten unterschiedliche Ausprägung. Vergleichende demonstrative Beispiele sind in der Open Source Broschüre des Deutschen Bundesministeriums für Wirtschaft und Arbeit zu finden (Bundesministe- rium für Wirtschaft und Arbeit, 2001, S. 26-28).
3.2.2 Unternehmen als (Mit-)Entwickler
Die Antwort auf die Frage, warum sich Unternehmen auch an der Open Source Software- entwicklung beteiligen, ist meistens sehr eng mit den Anwendungen oder Dienstleistungen rund um Open Source verbunden. Wenn das Unternehmen zu Anwendern gehört, ist es Grundsätzlich an der Anpassung bzw. Verbesserung der verwendeten Software interessiert und kann eventuell Beiträge zur Entwicklung leisten. Mit anderen Worten werden diese Beiträge mit dem Ziel geleistet, TCO (siehe 3.2.1) zu senken bzw. Funktionalität zu er- weitern. Im anderen Fall geht es um Unternehmen, deren Hauptgeschäft mit Open Source verbundene Dienstleistungen sind. Hier ist zu erwarten, dass Hauptziel der Entwicklung Absatzsteigerungen bei den Dienstleistungen sind (siehe 3.2.3).
3.2.3 Unternehmen als Dienstleister
Das Gewinnpotential der Open Source Software-Dienstleistungen ist eine der wichtig- sten Begründungen des Engagements von Unternehmen in der Open Source Softwareent- wicklung. Die Kernbereiche der Open Source Software-Dienstleistungen beinhalten Zu- sammenstellung und Verkauf von Open Source Softwarepaketen, Dokumentation, tech- nische Unterstützung, sowie verschiedene Internet-Dienstleistungen. Grassmuck (2002)
unterscheidet vier Hauptgruppen von entgeltlichen Open Source Software-Dienstleistern (Grassmuck, 2002, S. 351-360):
- Systemhäuser, Hard- und Softwarehersteller
Viele große Hard- und Softwarehersteller können davon profitieren, dass sie Open Source Software als Basistechnologie einsetzen, und damit die Fähigkeiten bzw. Kompatibilität ihrer Produkte steigern können. Die Entwicklung von Hardwaretrei- bern für Open Source Betriebssysteme kann auch zur Verbesserung der Einsetzbar- keit und Kompatibilität führen, und daher steigende Absatzzahlen bzw. steigenden Produktwert bewirken.
- Distributoren
Die nächste Gruppe sind Distributoren, wobei hier das Kerngeschäft bei Support, Installationen, Dokumentation und Verkauf von ergänzendem Software liegt. Mu- sterbeispiele sind hier die Großen Linux-Distributoren RedHat1 und SuSE2
- Projekt-Hosting und Portale
Dies ist ein neues Geschäftsmodell, das mit der Projektinfrastruktur und -Vermittlung arbeitet. Ein bekanntes Beispiel hier ist das (zum Teil) werbefinanzierte, in dieser Arbeit bereits erwähnte Portal SourceForge.net (SourceForge.net, 2003c, About), dass Teil des OSDN3 ist, welches von VA Linux finanziert wird.
- Dokumentation
Eines der größten Probleme beim Einsatz von Open Source Software ist fehlende, unverständliche oder mangelhafte Dokumentation von vielen Projekten. Deswegen eröffnet sich hier wieder ein lukratives Geschäftsfeld für Autoren und Verleger. Einer der bekanntesten Computerbücher-Verlage, die sich auch auf Open Source spezialisieren ist der O’Reilly Verlag4.
3.3 Makroökonomische Perspektive
Die Hauptproblematik in diesem Bereich ist der Mangel an Daten zur einer umfassen- den Analyse des Makroökonomischen Einflusses von Open Source. Grundsätzlich ist aber festzustellen, dass Open Source Software eindeutig einen wichtigen, aber auch sehr kom- plexen Einfluss auf die Ökonomie ausübt (siehe Working Group on Libre Software, 2000, Kap. 5.6). Neue Märkte werden geschaffen und sog. ”Pro-User”, die zur gleichen Zeit Pro- duzenten und Konsumenten von Software und Informationen sind, eröffnen neue Wege und Möglichkeiten in der New Economy (siehe Grosse u. a., 2001).
3.4 Praxisbeispiel: Das BerliOS-Projekt
Ein Pionierbeispiel für ein deutsches umfangreiches unternehmensorientiertes Open Sour- ce Portal ist das BerliOS-Projekt (BerliOS-Projekt, 2003a). Das Ziel von BerliOS ist verschiedene Interessensgruppen rund um Open Source zu unterstützen, und zwar die Anwender, Entwickler, kommerzielle Hersteller von Open Source Betriebssystemen und Support-Firmen. BerliOS wird in drei Platformen unterteilt: Die Informationsplattform, die Entwicklungsplatform und die Präsentationsplatform. Eine graphische Übersicht befindet sich auf Abbildung 1.
Die Informationsplattform beinhaltet Dokumentation zu Open Source Software und allgemeine Informationen über die Open Source Gemeinde. Es besteht aus fünf Portalen (Quelle: BerliOS-Projekt, 2003b):
- SourceLines – Branchenspezifische Lösungen
- SourceWell – Software-Ankündigungen und Katalog
- DocsWell – Dokumentationsportal
- SourceBiz – Verzeichnis von Software-Herstellern und Dienstleistern
- News – Nachrichtenportal.
Die Entwicklungsplatform soll generell Open Source Projekte unterstützen. Das Ber- liOS Entwicklungsportal Deloper1 verwendet die gleiche Software wie SourceForge.net und beinhaltet ca. 800 Projekte (September 2003), eine Projekt- und Ideenbörse sowie Mailinglisten.
Die Präsentationsplatform bietet Selbstdarstellungsmöglichkeiten für Unternehmen und Entwickler, die sich mit Open Source beschäftigen. Hierzu gehört auch das bei der Informationsplattform erwähnte Portal SourceBiz und auch ein Portal für Software- Ankündigungen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: BerliOS (Quelle: BerliOS-Projekt, 2003a)
4 Merkmale von Open Source Projekten
Dieses Kapitel beschäftigt sich mit allgemeinen Merkmalen, Strukturen und Eigenschaf- ten von Open Source Projekten. Die bearbeiteten Merkmale betreffen den Aufbau und Ablauf von Open Source Projekten und sind in vier Hauptgruppen organisiert: Größen- merkmale (4.1), Strukturmerkmale (4.2), entwicklungsspezifische Merkmale (4.3) und be- nutzerspezifische Merkmale (4.4). Anschliessend werden noch die Kommunikations- und Präsentationsinfrastruktur (4.5) des Projekts sowie seine Dokumentation (4.6) erwähnt. Das Ziel ist ein Raster aufzustellen, mit dem die Größe bzw. Umfang, Aufbau (Struktur), Entwicklungszustand und -ablauf sowie Ziele eines Open Source Projektes identifiziert und anschließend kategorisiert werden können.
Trove-Kategorisierung
In den Kapiteln 4.3 und 4.4 wird die sog. ”Trove”-Kategorisierung von SourceForge.net (SourceForge.net, 2003d) als Basis verwendet, die Bestandteil der SourceForge Software ist (SourceForge.net, 2003b). Zm Beispiel verwendet diese Kategorisierung der größte Open Source Projekthoster SourceForge.net mit ca. 65000 Projekten oder der junge deut- sche Projekthoster BerliOS mit ca. 800 Projekten (BerliOS-Projekt, 2003a) bzw. das Open Source Projektverzeichnis ”freshmeat.net” mit ca. 29000 Projekten (freshmeat.net, 2003)
Die Trove-Kategorisierung besteht grundsätzlich aus den folgenden Kategorien:
- Development Status - Entwicklungszustand
Diese Kategorie identifiziert den Reifezustand des Quellcodes von Open Source Projekten. Mehr im Kap. 4.3.1.
- Environment - Benutzerschnittstelle
Diese Kategorie beschreibt die Art der Interaktion des Programms mit dem Benutzer (z.B Windows, Console, Server), siehe Kap. 4.4.2.
- Intended Audience - Zielgruppe
Hier wird die Gruppe von Personen/Organisationen definiert, für die das Produkt gedacht ist. Mehr im Kap. 4.4.1
- Licence - Lizenz
Die vierte Gruppe ist die Lizenz, unter der das Projekt steht. Unterschieden werden OSI-Zertifizierte Lizenzen (siehe Kap. 2.2), andere Lizenzen und Public Domain.
- Natural Language - Sprache
In dieser Kategorie wird die natürliche Sprache definiert, in der das Projektinterface (und die Dokumentation) geschrieben ist. Näheres siehe Kap. 4.4.3
- Operating System - Betriebssystem
Die unterstützten Betriebssysteme werden in dieser Kategorie aufgelistet. (siehe Kap. 4.3.2)
- Programming Language - Programmiersprache
Die im Projekt verwendeten Programmiersprachen werden in dieser Kategorie er- wähnt. (siehe Kap. 4.3.3)
- Topic - Themenbereich
Die Kategorisierung steht mit der Zielgruppe im Zusammenhang und beschreibt den Themenbereich, in dem das Projekt Lösungen anbietet. Näheres im Kap. 4.4.4.
4.1 Größenmerkmale
Einer der Basismerkmale zur Klassifizierung von Open Source Projekten ist deren Größe. Diese kann aber anhand verschiedener Kriterien gemessen werden. Für unsere Zwecke werden folgende Kriterien interessant: Codelänge, Anzahl der teilnehmenden Entwickler, aber auch die Ausstattung an Unterprojekten, bzw. deren Größe.
4.1.1 Codelänge und Entwicklerzahl
Die Codelänge ist ein wichtiges Maß, dass in enger Verbindung mit anderen Merkmalen steht. Diese Länge kann in LOC (Lines of Code) gemessen werden, es kann aber auch der gesamte durch das Projekte belegte Quellcode-Speicherplatz genommen werden. In der FLOSS-Studie (International Institute of Infonomics und Berlecon Research GmbH, 2002, Part 5, Kap. 1.5) werden 16905 Open Source Projekte nach ihrer Byte-Größe und der Anzahl der Entwickler untersucht. Durch die große Anzahl und Verschiedenheit der untersuchten Projekte kann angenommen werden, dass eine ähnliche Verteilung auch in der Menge aller Open Source Projekte anzutreffen wird. Das kleinste Projekt hat eine Bytegröße von 69 Byte und das größte 97.379.040 Byte. Der Median liegt bei 53.430 Byte. 17% der Projekte sind kleiner als 10.000 Byte und nur 1% ist größer als 5.000.000 Byte. Die Verteilung der Byte-Größen der FLOSS-Studie kann aus Tabelle 3 abgelesen werden.
Was die Anzahl der Entwickler betrifft, haben die meisten Projekte einen oder zwei Entwickler (8911 - 52,71%) und nur sieben Projekte (0,04%) haben mehr als 500 Ent- wickler. Das Median liegt bei zwei Entwicklern. Die entsprechenden Daten können aus Tabelle 4 abgelesen werden.
Diese Ergebnisse können mit den Ergebnisen der Analyse von 27918 SourceForge.net Projekten, die in 2001 von Kienzle durchgeführt wurde, verglichen werden. (Kienzle, 2001, Kap. 2.1): 67% der Sourceforge.net Projekte haben nur einem Entwickler (FLOSS ca. 30%), 28% haben 2-5 Entwickler (FLOSS ca. 50%) und nur 5% haben mehr als 5 Entwickler (FLOSS ca. 20%). Die maximale Anzahl von Entwicklern beträgt aber nur 78, was bedeutet, dass SourceForge.net für größere Projekte als Entwicklungsplatform nicht eingesetzt wird.
[...]
1 Für eine genauere Beschreibung der Entwicklung der Open Source Lizenz siehe Perens, 1999.
2 Bei der Verwendung von Patch-Dateien kann die Wahl getroffen werden, ob mit der veränderten oder der ursprünglichen Version des Quellcodes gearbeitet werden soll.
1 Sourceforge ist eine der größten Open Source Entwicklungsplatformen im Internet. Abrufbar unter http://sourceforge.net - Zugriffsdatum: 08.04.2003.
1 IDA - Interchange of Data between Administrations, eine strategische Initiative der Europäischen Kom- mision, http://europa.eu.int/ISPO/ida/ - Zugriffsdatum: 06.05.2003
2 GNUPG - GNU Privacy Guard: http://www.gnupg.de - Zugriffsdatum: 06.05.2003
1 RedHat: http://www.redhat.com - Zugriffsdatum: 06.05.2003
2 SuSE: http://www.suse.de - Zugriffsdatum: 06.05.2003
3 OSDN - Open Source Development Network: http://www.osdn.com - Zugriffsdatum: 06.05.2003
4 O’Reilly & Associates Verlag: http://www.oreilly.com - Zugriffsdatum: 06.05.2003
Häufig gestellte Fragen
Was ist der Inhalt des Dokuments "Inhaltsverzeichnis"?
Dieses Dokument ist eine Sprachvorschau, die ein Inhaltsverzeichnis, Zielsetzungen, wichtige Themen, Kapitelzusammenfassungen und Schlüsselwörter enthält. Es behandelt Open-Source-Software aus verschiedenen Perspektiven, darunter Definitionen, Lizenzen, wirtschaftliche Aspekte, Projektmerkmale und Fallbeispiele.
Welche Themen werden in der "Einführung" behandelt?
Die Einführung betont die wachsende wirtschaftliche Bedeutung von Open-Source-Software. Sie skizziert den Umfang der Arbeit, der sich auf die Struktur und Funktionsweise existierender Open-Source-Projekte konzentriert, und erwähnt die Notwendigkeit, diese Ressource effizient zu nutzen.
Welche Definitionen werden in Kapitel 2 ("Grundlagen") erläutert?
Kapitel 2 definiert wichtige Grundbegriffe wie "Open Source Definition" und "Freie Software Definition". Es werden die wesentlichen Anforderungen an Open-Source-Softwarelizenzen erläutert.
Welche Open-Source-Lizenzen werden in Kapitel 2.2 behandelt?
Kapitel 2.2 beschreibt verschiedene Open-Source-Lizenzen, darunter Public Domain, BSD, Artistic License, GPL (GNU General Public License) und LGPL (GNU Lesser General Public License). Die Charakteristika der Lizenzen werden hinsichtlich ihrer Restriktivität erörtert.
Was sind die Schwerpunkte des Kapitels 3 ("Open Source und Wirtschaft")?
Kapitel 3 analysiert die Beziehungen zwischen Open-Source-Softwareentwicklung, Privatpersonen und der Wirtschaft. Es werden betriebswirtschaftliche Potentiale, Rollen von Akteuren und die makroökonomische Perspektive beleuchtet. Das BerliOS-Projekt dient als Praxisbeispiel.
Welche Merkmale von Open-Source-Projekten werden in Kapitel 4 untersucht?
Kapitel 4 befasst sich mit den Merkmalen von Open-Source-Projekten, einschließlich Größenmerkmalen (Codelänge, Entwicklerzahl), Strukturmerkmalen (Organisationsstruktur, Release-Prozess), entwicklungsspezifischen Merkmalen (Entwicklungszustand, Programmiersprache), benutzerspezifischen Merkmalen (Zielgruppe, Sprache) und der Kommunikations- und Präsentationsinfrastruktur.
Welche Fallbeispiele werden in Kapitel 5 analysiert?
Kapitel 5 präsentiert Fallbeispiele von Open-Source-Projekten wie AWStats, Horde, FreeBSD und Debian. Die Merkmale, Infrastruktur und Dokumentation dieser Projekte werden analysiert und verglichen.
Was sind die wichtigsten Größenmerkmale von Open-Source-Projekten?
Zu den Größenmerkmalen gehören die Codelänge (gemessen in LOC oder Byte) und die Anzahl der teilnehmenden Entwickler. Die FLOSS-Studie wird als Referenz für die Verteilung von Projektgrößen und Entwicklerzahlen verwendet.
Was versteht man unter "Trove-Kategorisierung"?
Die Trove-Kategorisierung, die von SourceForge.net verwendet wird, dient zur Klassifizierung von Open-Source-Projekten anhand von Entwicklungszustand, Benutzerschnittstelle, Zielgruppe, Lizenz, Sprache, Betriebssystem, Programmiersprache und Themenbereich.
Welche Motivationen haben Personen, an Open-Source-Projekten mitzuwirken?
Zu den Motivationen gehören der direkte Bedarf an Software, künstlerische Freude und der Wunsch nach Reputation. Die Rollenstruktur von Teilnehmern in Open-Source-Projekten wird ebenfalls untersucht (passive user, reader, bug reporter, bug fixer, peripheral developer, active developer, core member, project leader).
Welche Möglichkeiten hat der öffentliche Sektor, Open-Source-Projekte zu unterstützen?
Die Regierung kann Open-Source-Projekte durch direkte Unterstützung (Finanzierung), Förderung offener Standards, indirekte Unterstützung (Forschung) und Anpassung der Gesetzgebung unterstützen.
Welche betriebswirtschaftlichen Potentiale hat Open-Source-Software?
Unternehmen können Open-Source-Software als Anwender, (Mit-)Entwickler oder Dienstleister nutzen. Die betriebswirtschaftlichen Potentiale umfassen Kostensenkung, Anpassung von Software und die Bereitstellung von Dienstleistungen rund um Open-Source-Software.
- Arbeit zitieren
- Martin Matuska (Autor:in), 2003, Kategorisierung von Open Source Projekten: Aufbau- und Ablauforganisation, München, GRIN Verlag, https://www.grin.com/document/108766