Kategorisierung von Open Source Projekten: Aufbau- und Ablauforganisation


Diplomarbeit, 2003

71 Seiten, Note: 1


Gratis online lesen

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

1 BerliOS Developer: http://developer.berlios.de - Zugriffsdatum: 03.07.2003

70 von 71 Seiten

Details

Titel
Kategorisierung von Open Source Projekten: Aufbau- und Ablauforganisation
Hochschule
Wirtschaftsuniversität Wien
Note
1
Autor
Jahr
2003
Seiten
71
Katalognummer
V108766
Dateigröße
1110 KB
Sprache
Deutsch
Anmerkungen
HTML- PDF- und PS Versionen verfügbar unter: http://www.matuska.org/martin/diplom/
Schlagworte
Kategorisierung, Open, Source, Projekten, Aufbau-, Ablauforganisation
Arbeit zitieren
Martin Matuska (Autor), 2003, Kategorisierung von Open Source Projekten: Aufbau- und Ablauforganisation, München, GRIN Verlag, https://www.grin.com/document/108766

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Kategorisierung von Open Source Projekten: Aufbau- und Ablauforganisation



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden