Copyright (C) 2003 Martin Matuska.

Dieses Werk kann durch jedermann gemäß den Bestimmungen der Lizenz für die freie Nutzung unveränderter Inhalte (Version 1.0, Mai 2003) genutzt werden.

Die Lizenzbedingungen können unter http://www.uvm.nrw.de/opencontent abgerufen oder bei der Geschäftsstelle des Kompetenznetzwerkes Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen, schriftlich angefordert werden.

Eine Kopie dieser Lizenzbestimmungen befindet sich im Anhang A dieser Arbeit.

2

Inhaltsverzeichnis

Inhaltsverzeichnis   3

1  Einführung  6

2  Grundlagen  7

2.1  Definitionen  7

2.1.1  Open Source Definition  7

2.1.2  Definition der Freien Software  8

2.2  Lizenzen  9

2.2.1  Public Domain  10

2.2.2  BSD  10

2.2.3  Artistic License  10

2.2.4  GPL  11

2.2.5  LGPL  11

2.3  Open Source Entwicklungsgeschichte  11

3  Open Source und Wirtschaft  13

3.1  Akteure und ihre Rollen  13

3.1.1  Rollen und Motivation von Personen  13

3.1.2  Organisationen  14

3.1.3  Öffentlicher Sektor  15

3.2  Betriebswirtschaftliche Potentiale  16

3.2.1  Unternehmen als Anwender  16

3.2.2  Unternehmen als (Mit-)Entwickler  16

3.2.3  Unternehmen als Dienstleister  16

3.3  Makroökonomische Perspektive  17

3.4  Praxisbeispiel: Das BerliOS-Projekt  18

4  Merkmale von Open Source Projekten  20

4.1  Größenmerkmale  21

4.1.1  Codelänge und Entwicklerzahl  21

4.1.2  Unterprojekte  22

4.2  Strukturmerkmale  23

4.2.1  Organisationsstruktur  24

4.2.2  Ablaufstruktur und Release-Prozess  25

4.3  Entwicklungsspezifische Merkmale  27

4.3.1  Entwicklungszustand  27

4.3.2  Betriebssystem  28

4.3.3  Programmiersprache  29

4.3.4  Aktivitätsgrad  30

4.3.5  Versionierung  31

4.4  Benutzerspezifische Merkmale  31

3

4.4.1 Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4.2 Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4.3 Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.4 Themenbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5 Kommunikations- und Präsentationsinfrastruktur . . . . . . . . . . . . . . 34 4.5.1 Web-Seiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.5.2 Mailing-Listen und Newsgroups . . . . . . . . . . . . . . . . . . . . 34 4.5.3 Entwicklerwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.1 Produktbezogene Dokumentation . . . . . . . . . . . . . . . . . . . 35 4.6.2 Projektbezogene Dokumentation . . . . . . . . . . . . . . . . . . . . 36 5 Fallbeispiele 37

5.1 SourceForge.net: AWStats . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1 Merkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.2 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 Horde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.1 Merkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.2 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3 FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.1 Merkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.2 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.3.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.4 Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.4.1 Merkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.4.2 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.4.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.5 Zusammenfassung Fallbeispiele . . . . . . . . . . . . . . . . . . . . . . . 55 6 Resümee 57 58 A Lizenz für die freie Nutzung unveränderter Inhalte Literaturverzeichnis 63

4

Tabellenverzeichnis

1 Fünf häufigste Lizenztypen in Sourceforge . . . . . . . . . . . . . . . . . . 9

2 Wichtige Open Source Meilensteine . . . . . . . . . . . . . . . . . . . . . 12 3 Open Source Projekte nach der Bytegröße . . . . . . . . . . . . . . . . . . 22 4 Open Source Projekte nach der Entwicklerzahl . . . . . . . . . . . . . . . . 23 5 Kategorisierung von OSS Projekten nach Codegröße und/oder Entwicklerzahl 23 6 SourceForge.net Projekte - Entwicklungszustand . . . . . . . . . . . . . . . 28 7 SourceForge.net Projekte - Betriebssysteme . . . . . . . . . . . . . . . . . 29 8 SourceForge.net Projekte - 10 häufigste Programmiersprachen . . . . . . . 30 9 SourceForge.net Projekte - Zielgruppe . . . . . . . . . . . . . . . . . . . . 32 10 SourceForge.net Projekte - Benutzerschnittstellen . . . . . . . . . . . . . . 33 11 SourceForge.net Projekte - 10 häufigste natürliche Sprachen . . . . . . . . 34 12 SourceForge.net Projekte - 10 häufigste Themenbereiche . . . . . . . . . . 35 13 AWStats: Entwicklungsspezifische Merkmale . . . . . . . . . . . . . . . . 39 14 AWStats: Benutzerspezifische Merkmale . . . . . . . . . . . . . . . . . . . 39 15 Horde: Entwicklungsspezifische Merkmale . . . . . . . . . . . . . . . . . . 43 16 Horde: Benutzerspezifische Merkmale . . . . . . . . . . . . . . . . . . . . 43 17 Horde: allgemeine Mailing-Listen . . . . . . . . . . . . . . . . . . . . . . 44 18 FreeBSD: Entwicklungsspezifische Merkmale . . . . . . . . . . . . . . . . 47 19 FreeBSD: Benutzerspezifische Merkmale . . . . . . . . . . . . . . . . . . 48 20 Debian: Entwicklungsspezifische Merkmale . . . . . . . . . . . . . . . . . 52 21 Debian: Benutzerspezifische Merkmale . . . . . . . . . . . . . . . . . . . . 53 22 Fallbeispiele: Vergleich - Projektgröße . . . . . . . . . . . . . . . . . . . . 55 23 Fallbeispiele: Vergleich - Projektleitung . . . . . . . . . . . . . . . . . . . 55 24 Fallbeispiele: Vergleich - Merkmale . . . . . . . . . . . . . . . . . . . . . 56 25 Fallbeispiele: Vergleich - Kommunikation, Dokumentation . . . . . . . . . 56

Abbildungsverzeichnis

1 BerliOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 AWStats: Projektseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3 Horde: Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4 FreeBSD: Homepage in Deutsch . . . . . . . . . . . . . . . . . . . . . . . 46 5 Debian: Sitemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5

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 Source) 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 betriebswirtschaftlichen 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 Softwareprojekte 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 entsprechenden Merkmale bei vier existierenden Open Source Projekten - AWStats, Horde, FreeBSD und Debian identifiziert und anschließend teilweise verglichen.

6

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ührlich 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 Definition ¹ 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öglichkeit 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 gleichen 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-Dateien ² vorsieht. Die Lizenz darf den Programmnamen schützen, und die Weitergabe des veränderten Quellcodes nur unter einem anderen Programmnamen zulassen.

¹ Für eine genauere Beschreibung der Entwicklung der Open Source Lizenz siehe Perens, 1999.

² 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.

7

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 Softwarepakets 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 einschrä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 Schnittstelle 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.

8

• 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 gemeinsame 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-Projekten ¹ 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)

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 Quellcode 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 integrieren, ohne daß diese Programme zwingend unter derselben Lizenz stehen müssen, ist sie stark restriktiv.

¹ Sourceforge ist eine der größten Open Source Entwicklungsplatformen im Internet. Abrufbar unter http://sourceforge.net - Zugriffsdatum: 08.04.2003.

9

Von diesen zwei Merkmalen ausgehend wurden die Lizenzen in drei Kategorien eingestuft: (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äufigste 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änkungen 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 integriert 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 Werbezwecken 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 entwickeln sind z.B. FreeBSD, Apache (siehe Apache Software Foundation, 2003a), PostgreSQL (siehe PostgreSQL Global Development Group, 2002).

2.2.3 Artistic License

Die Hauptgedanke der ”Artistic Licence” ist, daß diese dem Author eine Art ”künstlerische 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 Source Initiative (Open Source Initiative, 2003a). Eines der bekannten Projekte mit diesem Lizenztyp ist die Programmiersprache Perl (für Lizenzlaut siehe perl.com, 1997).

10

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 restriktiven 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 ”Copyleft” 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 besonders 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 Abschnitt 2.2.4 das GNU-Projekt. Diese Lizenz ist bis auf einige wenige punkte der GPL Lizenz ähnlich. Sie wurde hauptsächlich für Funktions- bzw. Objektbibliotheken entwickelt. Programme, die diese Bibliotheken verwenden, werden nicht als abgeleitete Werke angesehen und unterliegen nicht der Copyleft-Einschränkung. Dies gilt aber nicht für Veränderungen 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 Softwareentwicklung 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 Projekte rund das GNU Projekt bzw. rund um BSD haben eine ähnliche Entwicklungspolitik und die im Kapitel 2.2 vorgestellten Lizenzen verwendet.

11

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.

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äftsmodelle 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- kakojiu. 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 kommerziellen Software. Er wird hauptsächlich von der Qualität bzw. Anpassungsfähigkeit der Software angezogen.

• reader

Den ”Leser” interessiert nicht nur die Nutzung, sondern auch die Struktur und Funktionsweise 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 Softwareentwicklung.

• bug fixer

Der ”bug fixer” korrigiert entweder selbst erkannte oder vom ”bug reporter” berichtete 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 vereinzelt.

13

• 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 Teilnehmern 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ähigkeiten 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 gemeinnützige Organisationen wie z.B. Apache Foundation (Apache Software Foundation, 2003b) an der Open Source Entwicklung teil. Die Teilnahme der gewinnorientierten Organisationen basiert meistens auf den im Kapitel 3.2 vorgestellten Geschäftsmodellen. Gemeinnützige 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 Bereitstellung von Infrastruktur an wie z.B SourceForge.net (SourceForge.net, 2003c, Sektion A1).

14

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 IDA ¹ (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 (GNUPG ² , INTERMiT).

Im dritten Teil der IDA Studie (IDA, 2001, Part 3, S. 15-21) werden in einer Umfrage 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 Quellcodes. Einige wichtige Gegenargumente sind gebundenes Kapital in bereits vorhandenen Lösungen, vertragliche Bindungen, Angst vor Budgetkürzungen und Fehlen von schlüsselfertigen 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 Standards 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 Grundlagenforschung) 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.

¹ IDA - Interchange of Data between Administrations, eine strategische Initiative der Europäischen Kommision, http://europa.eu.int/ISPO/ida/ - Zugriffsdatum: 06.05.2003

² GNUPG - GNU Privacy Guard: http://www.gnupg.de - Zugriffsdatum: 06.05.2003

15

3.2 Betriebswirtschaftliche Potentiale

Dieser Unterabschnitt behandelt das Verhältnis zwischen Unternehmen und Open Source. 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ösungen. 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 Software, 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 Software 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- riumfü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 Softwareentwicklung 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 erweitern. 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 wichtigsten Begründungen des Engagements von Unternehmen in der Open Source Softwareentwicklung. Die Kernbereiche der Open Source Software-Dienstleistungen beinhalten Zusammenstellung und Verkauf von Open Source Softwarepaketen, Dokumentation, technische Unterstützung, sowie verschiedene Internet-Dienstleistungen. Grassmuck (2002)

16

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 Hardwaretreibern für Open Source Betriebssysteme kann auch zur Verbesserung der Einsetzbarkeit 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. Musterbeispiele sind hier die Großen Linux-Distributoren RedHat ¹ und SuSE 2

• 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 OSDN ³ 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 Verlag ⁴ .

3.3 Makroökonomische Perspektive

Die Hauptproblematik in diesem Bereich ist der Mangel an Daten zur einer umfassenden Analyse des Makroökonomischen Einflusses von Open Source. Grundsätzlich ist aber festzustellen, dass Open Source Software eindeutig einen wichtigen, aber auch sehr komplexen 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 Produzenten und Konsumenten von Software und Informationen sind, eröffnen neue Wege und Möglichkeiten in der New Economy (siehe Grosse u. a., 2001).

¹ RedHat: http://www.redhat.com - Zugriffsdatum: 06.05.2003

² SuSE: http://www.suse.de - Zugriffsdatum: 06.05.2003

³ OSDN - Open Source Development Network: http://www.osdn.com - Zugriffsdatum: 06.05.2003

⁴ O’Reilly & Associates Verlag: http://www.oreilly.com - Zugriffsdatum: 06.05.2003

17

3.4 Praxisbeispiel: Das BerliOS-Projekt

Ein Pionierbeispiel für ein deutsches umfangreiches unternehmensorientiertes Open Source 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 BerliOS Entwicklungsportal Deloper ¹ 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.

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

18

4 Merkmale von Open Source Projekten

Dieses Kapitel beschäftigt sich mit allgemeinen Merkmalen, Strukturen und Eigenschaften von Open Source Projekten. Die bearbeiteten Merkmale betreffen den Aufbau und Ablauf von Open Source Projekten und sind in vier Hauptgruppen organisiert: Größenmerkmale (4.1), Strukturmerkmale (4.2), entwicklungsspezifische Merkmale (4.3) und benutzerspezifische 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 deutsche 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)

20

• Programming Language - Programmiersprache

Die im Projekt verwendeten Programmiersprachen werden in dieser Kategorie erwä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 Entwickler. 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.

In der FLOSS Studie werden auch die Bytegröße und die Anzahl der Entwickler in Zusammenhang gebracht und festgestellt, dass mit steigender Codegröße Projekte mit mehr Entwicklern anzutreffen sind. In Zahlen: Ein Entwickler ist vor allem bei Projekten

21

(Quelle: International Institute of Infonomics und Berlecon Research GmbH, 2002, Part 5, Figure 5)

zwischen 69 und 20.000 Byte anzutreffen, zwei Entwickler zwischen 5.000 und 50.000 Byte und vier Entwickler zwischen 50.000 und 1.000.000 Byte. 7 bis 20 Entwickler sind grundsätzlich bei Projekten ab 200.000 Byte tätig und mehr als 20 Entwickler bei Projekten mit einer Größe von 500.000 Byte und mehr.

Aus diesen Zusammenhängen wird für den Gebrauch in dieser Arbeit vom Autor eine grobe Größen-Kategorisierung von Open Source Projekten vorgenommen, die sich in Tabelle 5 befindet. Es kann aber je nach Situation gewählt werden, ob grundsätzlich nach der Entwicklerzahl oder nach der Projektgröße klassifiziert wird.

4.1.2 Unterprojekte

Um die im Kap. 4.1.1 analysierten Größen erfolgreich ermitteln zu können, muss das Projekt eingrenzbar sein. Viele Projekte sind in Unterprojekte geteilt, welche wiederum mehr oder weniger stark untereinander vernetzt sein können. Handelt sich um praktisch unabhängige Projekte, die sich in der Entwicklung gar nicht oder nur sehr wenig gegenseitig beeinflussen, ist es sinnvoller diese Unterprojekte statt des Hauptprojekts als Vergleichsbasis zu verwenden. Ein gutes Beispiel sind hier die Unterprojekte von Debian Linux (Debian-Projekt, 2003k). Auf der Gegenseite können die Unterprojekte so stark vernetzt sein, das sie lebenswichtige Teile des Hauptprojekts darstellen und ihr Ausschließen die Funktionsgrundlage entziehen würde. Hier ist sinnvoller das Hauptprojekt als Vergleichseinheit zu betrachten. Entscheidend ist aber nicht nur, wie die Beziehung des Hauptprojekts zum Unterprojekt ist, sondern auch die der Unterprojekte untereinander. Deswegen können die Unterprojekte der Entwicklungsplattformen wie z.B. HORDE (siehe Kap. 5.2) als eigenständige Open Source Projekte betrachtet werden. Jedes der Programme benötigt nur das Hauptgerüst, um funktionieren zu können.

22

(Quelle: International Institute of Infonomics und Berlecon Research GmbH, 2002, Part

Tabelle 5: Kategorisierung von OSS Projekten nach Codegröße und/oder Entwicklerzahl

Eine sehr häufig anzutreffende Sonderform der Unterprojekte sind die sog. Dokumentationsprojekte. Sie sind meistens bei größeren oder komplexen Projekten anzutreffen und beinhalten oft nicht nur Dokumentation für Anwender, sondern auch für Entwickler. Ein umfangreiches Beispiel ist hier das Dokumentationsprojekt von FreeBSD (FreeBSD Project, 2003h). Bei diesen Projekten handelt sich aber meistens nicht unbedingt um Open Source Projekte, weil nur Dokumentationsinhalte und keine Software hergestellt werden.

4.2 Strukturmerkmale

In diesem Unterkapitel werden wichtige strukturelle Merkmale und Eigenschaften von Open Source Projekten dargestellt, die Einfluss auf den Entwicklungsprozess haben. Näher eingegangen wird in diesem Kapitel auf die Organisationsstruktur (4.2.1) und die Ablaufstruktur (4.2.2). In der Organisationsstruktur wird die Leitungs- und Entscheidungsstruktur und die Rollen und Rechte der einzelnen Teilnehmer dargestellt. Die Ablaufstrukur kennzeichnet sich durch den standardisierten Release-Prozess.

23

4.2.1 Organisationsstruktur

Wie bereits Raymond in seinem Aufsatz (Raymond, 1998a) umschreibt, unterscheidet sich die allgemeine Organisationsstruktur der Open Source Projekte von jener proprietärer Softwareprojekte. Er nennt diese zwei Formen ”cathedral” und ”bazaar”. Die erste Form, also die Kathedrale, stellt ein geschlossenes isoliertes Entwicklungssystem mit strikten Regeln dar. Die Anzahl der Entwickler bleibt im Prinzip vom Anfang an gleich, das Projekt hat strikte Zeitvorgaben und Verantwortungszuweisungen. Direkte Kommunikation mit der Zielgruppe kommt während der Entwicklung prinzipiell nicht zum Stande. Im Gegensatz steht das zweite Modell - Bazar, wo viele gleichgestellte Entwickler kleine Beiträge leisten und es zu starker Kommunikation mit den Anwendern kommt - wie z.b. die Entwicklung des Linux Kernels.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging (Raymond, 1998a)

Leitungs- und Entscheidungsstruktur

Eine besondere Rolle bei der Aufbaustruktur der Open Source Projekte spielt die Leitungs- und Entscheidungsstruktur. Hier werden grundsätzlich folgende Modelle unterschieden (Raymond, 1998b):

• benevolent dictator

Der ”wohlwollende Diktator” hat alleine Kontrollrechte und Entscheidungsgewalt über das gesamte Projekt, d.h. er muss Entwicklerbeiträge akzeptieren, bestimmt was in die Releases kommt und wie die weitere Entwicklungsrichtung ausschauen wird. Dieser Diktator delegiert meistens Teile seiner Kompetenzen an ”trusted Lieutenants” weiter (Johnson, 2001, Kap. 4.1). Ein Beispiel ist hier Linus Torvalds als Leiter der Linux-Kernel Entwicklung.

• rotating dictatorship

Diese Form der Leitung wird z.B. beim Perl Projekt praktiziert - führende Entwickler wechseln sich in der Projektleitung ab.

• Komitee

Bei Projekten, die von einem gewählten Komitee geleitet werden, wird die Leitung für eine bestimmte Zeitspanne von allen (berechtigten) Entwicklern gewählt. Gute Beispiele sind hier das FreeBSD ¹ Projekt oder das Apache HTTP ² Server Projekt

Rollen der Beteiligten

An Open Source Projekten beteiligen sich meistens alle im Kapitel 3.1.1 vorgestellten Personengruppen. Die Rollenverteilung ist abhängig von der Projektgröße. Auf SourceForge.net sind hauptsächlich kleine und mittelgroße Projekte untergebracht und das System

¹ The FreeBSD Project - http://www.freebsd.org - Zugriffsdatum: 15.05.2003

² The Apache HTTP Server Project - http://httpd.apache.org - Zugriffsdatum: 15.05.2003

24

dort unterscheidet zum Beispiel nur zwei Typen von Projektmitarbeitern: Administratoren und Entwickler. Die ersteren sind für die Infrastruktur und Verwaltung zuständig (Fehlerberichte der User, Verwaltung der Benutzerforen, Mailinglisten, eventuell auch Distribution der Dateien) und die zweite Gruppe sind Entwickler, die für den Quellcode zuständig sind. Große Projekte wie der Linux-Kernel oder FreeBSD haben eine ganze Reihe von verschiedenen ”Posten” mit unterschiedlichen Zuständigkeiten. FreeBSD hat z.B. einen Security-Officer mit seinem Team, die für sicherheitsrelevante Updates, Patches und Benachrichtigungen der Benutzer zuständig sind, oder ein Release-Team (mehr im Kapitel 5.3).

Einschränkungen der Rollenbesetzung

Nicht jedes Projektmitglied kann uneingeschränkt eine beliebige Rolle im Projekt ausüben. Da bestimmte Rollen (z.B. Entwickler) Kenntnisse oder Qualikifationen erfordern, die oft auch in einer Art Bewährungsperiode nachgewiesen werden müssen, existieren prinzipiell bei allen Projekten Regeln der Rollenvergabe. Bei einigen Projekten wie z.B. FreeBSD existieren sogar feste ”Stellen” mit explizit ausgegliederten Zuständigkeitsbereich, die besetzt werden müssen.

Die SourceForge.net Projekt-Administratoren (siehe SourceForge.net, 2003a) sind als einzige berechtigt, projektbezogene Rechte an andere Benutzer zu delegieren. Sie können Entwickler aufnehmen und entlassen, regeln den Zugang zum Quellcode und bestimmen Verwalter der einzelnen Unterbereiche wie Mailing-Listen und Support. Beim FreeBSD Projekt (siehe 5.3) entscheiden die Verwalter der einzelnen Bereiche (Core, Ports, Dokumentation) über die Aufnahme und Entlassung von Entwicklern. Eines der extremsten Beispiele in diesem Bereich ist das Debian Projekt. Die Aufnahme eines neuen Entwicklers ist ein äußerst komplexer Prozess (Debian-Projekt, 2003c, Kap. 2), der eine nicht nur eine Prüfung der Fähigkeiten sondern auch eine detaillierte Überprüfung der Identität der Person beinhaltet.

Eingriffe in den Quellcode

Grundsätzlich werden Entwickler in Entwickler mit und ohne direkten Quellcode-Zugang unterteilt ¹ . Nur Entwickler mit direktem Quellcode-Zugang dürfen den gemeinsamen Quellcode verändern. Daher ist zu erwarten, dass die von anderen aktiven Teilnehmern am Open Source Entwicklungsprozess bereitgestellten Beiträge normalerweise (z.b. nach Mailinglisten- oder Forendiskussionen) von den berechtigten Entwicklern entweder (korrigiert) in den Quellcode aufgenommen oder abgewiesen werden.

4.2.2 Ablaufstruktur und Release-Prozess

Unter der Ablaufstruktur eines Open Source Projektes ist zu verstehen, von welchen geschriebenen (oder ungeschriebenen) Gesetzen sich die Entwicklung leiten lässt und wie der Release-Prozess abläuft.

¹ Bezogen auf ein einzelnes Projekt, verschiedene Entwicklerrollen siehe Kap. 3.1.1.

25

Standardisierung der Vorgänge

Die Standardisierung der Entwicklungsvorgänge wird meistens bereits durch die Entwicklungswerkzeuge und die Entwicklungsplatform selbst impliziert. Viele Open Source Projekte verwenden standardisierte Entwicklungs- und Konfigurationswerkzeuge aus dem GNU-Projekt wie z.B. GNU-autoconf (GNU-Projekt, 2001a) für automatische betriebssystemübergreifende Konfiguration und GCC - GNU C Compiler (GNU-Projekt, 2003b) als Kompilierwerkzeug. Andere bekannte Vorschriften sind z.B. Dateinamen- und Pfadregelungen, damit die Übersichtlichkeit der Projekte nicht beeinträchtigt wird. Mehrere größere Projekte, an denen viele Entwickler beteiligt sind, stellen ihren Entwicklern detailierte Entwicklerdokumentation zur Verfügung. Ein Beispiel hierfür ist das Entwicklerhandbuch von FreeBSD (FreeBSD Project, 2003f). Release-Prozess

Das Kernstück der Ablaufstruktur ist der Release-Prozess. Dieser hängt sehr stark vom Entwicklungszustand (siehe Kap. 4.3.1) ab. Hier behandelte Releases sind geordnete und gekennzeichnete Veröffentlichungen des Projekts in Form von Dateien. Erenkrantz zählt die folgenden wichtigen Charakteristika (Erenkrantz, 2003, Kap 2.) von allgemeinem Release-Management bei Open Source Projekten auf:

• Release Authority

Das Projekt benötigt eine Stelle, die für die Koordination des Release-Prozesses zuständig ist. Bei kleinen Projekten ist es meistens nur eine Person, bei großen Projekten wie FreeBSD wird diese Aufgabe von einem Team übernommen.

• Versionierung

Jedes Release bekommt eine Kennzeichnung (z.B. Versionsnummer) zugewiesen. Aus dieser sollte der Entwicklungszustand und die daraus resultierende Stabilitätserwartung eindeutig erkennbar sein (z.B. alpha, beta, RC, stable). Mehr im Kapitel 4.3.5.

• Pre-Release Tests

Interne Regelungen im Projekt können bestimmen welche Kriterien erfüllt werden müssen, damit es überhaupt zu einem Release kommt (z.B. neue Funktionen, Stabilität).

• Zulassung von Releases

Die endgültige Zulassung eines Releases kann je nach Projektregeln entweder von der Release Authority alleine oder noch durch eine zusätzliche Kontrollstelle erfolgen.

• Distribution

Die Benutzergemeinde muss über das neue Release informiert werden (Mailinglists, Foren) und das Release muss frei verfügbar sein.

• Formate

Die Formatregelungen bestimmen wie die zu veröffentlichende Datei auszusehen hat. Ziel ist eine möglichst einfache und universelle Handhabung.

26

Mehrere Projekte wie z.B. Mozilla (siehe mozilla.org, 2003) oder FreeBSD (siehe FreeBSD Project, 2003k) verfolgen die folgende Release-Politik:

ALPHA -> BETA -> RC -> RELEASE

Am Anfang werden in vielen Fällen ALPHA-Releases veröffentlicht. Sie sind im Prinzip nur Abbildungen des Entwicklungs-Quellcodes (sog. Code-Snapshots) zu einem bestimmten Zeitpunkt, oder kompilierte Versionen von diesen, die einen minimalen Grad an Stabilität haben sollten. Der Zweck ist ein Vorschau auf die neuen Funktionen zu bieten und die ersten Tester und Fehlerberichtserstatter zu gewinnen. Die Versionierung wird üblicherweise durch das Anhängen von einer ”alpha” Kennzeichnung oder einer ungeraden Versionszahl realisiert. Nicht alle Projekte veröffentlichen ALPHA-Releases. Höhere Stabilitätserwartung haben BETA-Releases. Es werden üblicherweise keine neuen Funktionen ab diesem Release mehr integriert, das Ziel ist möglichst viele berichtende Tester zu bekommen und an der Problem- und Fehlerbehebung zu arbeiten. Es können aber eventuell noch kleine Änderungen und Anpassungen durchgeführt werden. Die Versionierung geschieht meistens durch eine ”beta” Kennzeichnung. (z.B. Mozilla 1.4 Beta)

Die letzte Vorstufe vor einem ”endgültigen” stabilen Release ist ein RELEASE CAN-DIDATE (RC). Es dient hauptsächlich zur Behebung kleiner Fehler. Größere Veränderungen sind in dieser Phase nicht erlaubt. Versioniert wird normalerweise mit einer ”RC” Kennzeichnung. (z.B. FreeBSD 4.6-RC3)

Letzter Schritt ist das endgültige RELEASE. Es soll möglichst stabil und fehlerfrei sein. Das Programm wird in mehreren Quellen angekündigt und breit verfügbar gemacht. Nach dem Release werden üblicherweise noch sog. BUGFIX-RELEASES veröffentlicht, die weitere gefundenen Fehler korrigieren. Diese Releases werden oft durch die Erhöhung der Patch-Versionszahl (siehe 4.3.5) gekennzeichnet.

4.3 Entwicklungsspezifische Merkmale

Die entwicklungsspezifischen Merkmale stellen wichtige Eigenschaften des Entwicklungsprozesses dar, sie charakterisieren den Reifezustand des Open Source Projektes, die Entwicklungsumgebung, die unterstützten Betriebssysteme und die verwendeten Programmiersprachen und -werkzeuge.

Zusätzlich zur Trove-Kategorisierung wird bei SourceForge.net und anderen Projekthostern regelmäßig die Aktivität von Open Source Softewareprojekten bewertet und dementsprechend eingestuft - siehe 4.3.4. Abschließend wird die Versionierung von Projekt-Releases vorgestellt (4.3.5).

4.3.1 Entwicklungszustand

Der Entwicklungszustand ist ein Merkmal des Quellcodes, bzw. der Releases. Er bezieht sich immer auf einen bestimmten Zeitpunkt und bestimmten Quellcode (oder Teil des Quellcodes) oder ein Release. Die typische Trove-Kategorisierung unterscheidet folgende

27

Entwicklungszustände:

Planning, Pre-Alpha, Alpha, Beta, Production/Stable, Mature und eventuell Inactive. Die ersten zwei Zustände, Planning und Pre-Alpha, beschreiben Software, welches sich noch vollständig in der Entwurfphase (Planning) oder bereits in der Vorbereitung zur Entwicklung befindet (Pre-Alpha, meistens Experimentiercode). Die Kernentwicklungsphase ist dann die Alpha-Phase, wo Releases in Form von Code-Snapshots gemacht werden (siehe Kap. 4.2.2). Erweist sich der Code als stabil genug, wird die sog. Beta-Phase eingeführt, wo bereits eine funktionsfähige Software vorliegt, welche aber meistens noch Fehler (Bugs) beinhaltet. (Zukünftige) Endbenutzer werden aufgefordert, die Software zu testen um diese Fehler zu entdecken und melden. In der Beta-Phase werden meistens keine neuen Optionen bzw. Funktionen integriert. Nach einem bestimmten Zeitabstand tritt die Software dann in den Production/Stable Zustand und kann breit eingesetzt werden. Stabile Software, die sich bereits eine längere Zeitperiode erfolgreich im Einsatz befindet und keine neuen wichtigen Fehler mehr aufweist wird ”mature” (reif). Da aber die Entwickler der meisten Projekte, die sich im stable bzw. mature Zustand befinden auch neue ungetestete Funktionen und Verbesserungen integrieren wollen, führen diese üblicherweise mehrere parallele Entwicklungsstränge, von denen meistens einer stable bleibt und nur noch korrigiert wird, und andere sich im Alpha- oder Betazustand befinden. Dies trifft auch für große Projekte zu, die nicht bei Projekthostern organisiert sind wie z.B FreeBSD (Entwicklungsstränge STABLE und CURRENT, siehe Kap. 5.3) oder Debian (siehe Kap. 5.4).

Projekte, die vorübergehend nicht weiterentwickelt werden fallen unter die Kategorie ”Inactive”. Die Statistik der Projekt-Entwicklungszustände bei Sourceforge kann aus Tabelle 6 abgelesen werden.

4.3.2 Betriebssystem

Die Kategorie Betriebssystem ist insofern wichtig, dass viele Projekte nur auf ein bestimmtes Betriebssystem, bzw. eine Betriebssystemklasse spezialisiert sind und dadurch spezielle Anforderungen an die Entwicklung haben. Platformübergreifende Software hat

28

diese Einschränkung zwar nicht, benötigt dafür aber wesentlich mehr Entwicklungs- und Testaufwand.

Die Trove-Kategorisierung von SourceForge.net unterscheidet folgende Betriebssysteme (oder Klassen): BeOS, MacOS, Microsoft, betriebsystemunabhängig (OS independent), OS/2, andere Betriebssysteme (other OS), PDA Systeme, POSIX. Aus Abbildung 7 kann man erkennen, das POSIX eine besonders große Anzahl von Projekten aufweist. Unter POSIX sind alle POSIX-kompatiblen Betriebssysteme zusammengefasst, d.h. die meisten UNIX-ähnlichen Betriebssysteme (z.B. Linux, BSD).

4.3.3 Programmiersprache

Die Trove-Kategorisierung von Sourceforge.net unterscheidet mehr als 40 Programmiersprachen ¹ . Die Programmiersprache hängt logischerweise sehr stark von der Benutzerschnittstelle (siehe 4.4.2) und vom Betriebssystem (siehe 4.3.2) ab, da jede Benutzerschnittstelle bzw. jedes Betriebssystem unterschiedliche Ressourcen und Möglichkeiten für die Arbeit in verschiedenen Programmiersprachen zur Verfügung stellt. Zum Beispiel wird man in Windows-Entwicklungsumgebungen visuelle Programmiersprachen bevorzugen (Visual Basic, Visual C), die Programmiersprache PHP wird überwiegend in der Web-Umgebung eingesetzt, da sie für diese entwickelt worden ist (siehe Schmid u. a., 1997-2003, Vorwort). Komplexität und benötigte Rechenzeit stellen auch einen wichtigen Faktor dar. Zusätzlich stellt jede Programmiersprache unterschiedliche Anforderungen an die Fähigkeiten und Hardware- und Software-Kenntnisse der Programmierer (z.B. Programmierung im Assembler erfordert mehr System-Kenntnisse als Programmierung in den Skriptsprachen Tcl oder Unix Shell). Eine Auflistung der 10 am häufigsten verwendeten Programmiersprachen in SourceForge.net Projekten befindet sich in Tabelle 8.

¹ Anzahl der aufgelisteten Programmiersprachen in der Software Map von Sourceforge.net zum 17.7.2003: 44. http://sourceforge.net/softwaremap/trove_list.php?form_cat=160s

29

Tabelle 8: SourceForge.net Projekte - 10 häufigste Programmiersprachen (Quelle: SourceForge.net, 2003d)

4.3.4 Aktivitätsgrad

Der Aktivitätsgrad ist eine künstlich geschaffene Variable, mit der die Projektaktivität bewertet, eingestuft und anschließend mit anderen Projekten verglichen werden kann. Die Berechnung dieser Variable kann unterschiedlich verlaufen. Projekthoster die SourceForge.net Software (SourceForge.net, 2003b) verwenden (z.B. SourceForge.net, BerliOS), setzen (möglicherweise mit kleinen Modifikationen) die folgende Formel zur Berechnung des sog. Aktivitätsperzentils ein: Primäre Variablen

CNT = Anzahl der Projekte M = Anzahl der Forenbeiträge (Forum Messages) T = Anzahl der Aufgaben (Tasks) B = Anzahl der Fehlerberichte (Bug Reports) S = Anzahl der Supportanfragen (Support Requests) P = Anzahl der Quellcode-Korrekturen (Patches) C = Anzahl der Quellcode-Eintragungen im CVS (CVS commits) F = Anzahl der veröffentlichten Releases (File Releases) D = Anzahl der Benutzerdownloads (Downloads) Sekundäre Variablen

SCORE = Summe der Bewertungen der einzelnen Projektaktivitäten RANK = Projekplatzierung, absteigende Sortierung aller Projekte nach SCORE (Project Ranking) AP = Aktivitätsperzentil (Activity Percentile)

30

Formel zur Berechnung des Aktivitätsperzentils SCORE = log(3 ∗ M ) + log(4 ∗ T ) + log(3 ∗ B) + log(10 ∗ P ) + (1)

(SourceForge.net, 2003b, SF2.5.tar.gz, SF2.5/cronjobs/project_metric.php)

Der Aktivitätsperzentil wird bei SourceForge.net entweder zeitlich unbegrenzt oder auf die ”diese Woche” begrenzt angegeben (SourceForge.net, 2003e). Bei der zeitlichen Begrenzung werden bei den Variablen M,T,B,S,P,C,F,D nur Datenbankeinträge betrachtet, die im untersuchten Zeitraum eingetragen wurden

4.3.5 Versionierung

Die Versionierung ist für jedes Projekt sehr wichtig, da dadurch die Releases und Entwicklungsstränge eindeutig identifiziert werden können. Viele Projekte (z.B. FreeBSD, Apache HTTPD, Linux Kernel, Mozilla, u.a.) verwenden das folgende Format der Versionierung:

Veränderung der Patch-Versionsnummer steht ausschließlich für Fehlerkorrektur, Veränderung der Minor-Versionsnummer steht für neue bzw. verbesserte Funktionalität (zusätzlich zur Fehlerkorrektur). Mehrere Minor-Versionen unter derselben Major-Version sollen kompatibel sein. Veränderung der Major Versionsnummer steht für Veränderungen größeren Ausmaßes wie z.b. Neu-Gestaltung des Quellcodes und haben oft keine oder nur stark eingeschränkte Kompatibilität mit älteren Versionen.

Viele Projekte aus dem GNU-Bereich wie z.B der Linux-Kernel (siehe Erenkrantz, 2003, Kap 3.2) verwenden die Minor-Versionsnummer für die Identifizierung von Stabilität. Ungerade Nummern repräsentieren Entwicklungsreleases (Alpha) und gerade Zahlen stabile Releases (Production).

4.4 Benutzerspezifische Merkmale

Zu den benutzerspezifischen Merkmalen eines Open Source Software Projektes gehören unter anderem der gewünschte Benutzer selbst (Zielgruppe), die Schnittstelle, über die der Benutzer mit dem Programm interagiert, die natürliche Sprache (benutzerorientiert) und der Themenbereich. Diese werden in den folgenden Unterkapiteln näher erörtert.

4.4.1 Zielgruppe

Die Zielgruppe eines Open Source Softeareprojekts sind Personen- oder Geschäftsbereiche, für welche die erstellte Software geeignet sein soll. Die Trove-Kategorisierung der

31

SourceForge.net Software unterscheidet 14 Kategorien, alle sind sowohl bei SourceForge.net als auch bei BerliOS vorhanden. In Tabelle 9 sind alle diese Kategorien aufgelistet. Die zwei häufigsten Zielgruppen sind Entwickler und Endbenutzer, die drittgrößte sind Systemadministratoren. Da aber praktisch alle Programme von Personen bedient werden sollen, haben die meisten Projekte bei SourceForge.net zumindest eine der drei Hauptgruppen in der Liste ihrer Zielgruppen. Diese drei Zielgruppen können generell für alle Open Source Softeareprojekte als Einstufung dienen.

Die Wünsche und Vorstellungen der Zielgruppe spielen im Open Source Entwicklungsprozess eine große Rolle, da die zukünftigen Benutzer bereits Einsicht in die Entwicklung haben können, Testversionen ausprobieren können und die Entwickler auf fehhlerhafte, fehlende oder überflüssige Teile bzw. Eigenschaften von entwickelten Programmen aufmerksam machen können. Kommunikationswerkzeuge zwischen Entwicklern und der Zielgruppe sind meistens Mailing-Listen und Benutzer-Foren.

4.4.2 Benutzerschnittstelle

Unter der Benutzerschnittstelle wird verstanden, ob und wie die Interaktion des Benutzers mit dem Programm durchgeführt wird. Die typische Trove Kategorisierung unterscheidet hier folgende Basiskategorien: Console, Daemon, Web, X-Windows (X11), MS Windows (Win32) und Andere. SourceForge (SourceForge.net, 2003d) inkludiert hierzu auch MacOS X und Handheld/PDA. Die Kategorie Daemon beinhaltet Server-Software, das keine direkte I/O Schnittstelle zum Benutzer hat, Console ist Text-basierte Benutzerschnittstelle. Kategorie Web sind Programme, deren Bedienung über Web-Browser geschieht und

32

zur Ausführung meistens ein Web-Server benötigt wird. X-Windows, MS Windows und MacOS X sind verschiedene Typen von Fenster-basierten Benutzerschnittstellen. Handheld/PDA ist eine Sonderkategorie für Software, die für tragbare Kleinrechner entwickelt wird. Die meisten dieser Kategorien werden noch weiter nach platformspezifischen Kriterien unterteilt. Nicht aufgelistete Projekte werden unter Andere (Other) eingestuft. Die Benutzerschnittstelle steht im Zusammenhang mit der Zielgruppe (Kap. 4.4.1). Zum Beispiel wird Software ohne I/O Schnittstelle mit hoher Wahrscheinlichkeit weniger für Endbenutzer und mehr für Administratoren gedacht sein. Eine Statistik der Benutzerschnittstellen der SourceForge Projekte befindet sich in Tabelle 10.

4.4.3 Sprache

Die natürliche Sprache(n) eines Projekte ist/sind die Sprache(n) der Zielgruppe(n) und der Entwickler. Aus Tabelle 11 kann man eindeutig erkennen, das Englisch die überwiegende Sprache bei SourceForge.net ist. Dies ist aber auch darauf zurückzuschließen, dass Englisch die am meisten verwendete Sprache im Internet ist und das viele Projekte ihre Zielgruppen und Entwicklerkreise nicht geographisch eingrenzen wollen. Daher haben auch Projekte mit anderen Sprachen in der Kategorien-Liste oft auch Englisch als Sprache. Rein nicht-englische Projekte sind selten, aber doch vorhanden ¹ .

4.4.4 Themenbereich

Das letzte in dieser Arbeit behandelte Element der Trove-Kategorisierung von SourceForge.net ist der Themenbereich. Hier wird der Bereich angegeben, in dem die entwickelte Software Lösungen bieten soll. Diese Kategorisierung hängt sehr stark mit der Zielgruppe zusammen, da diese prinzipiell aus dem Themenbereich abgeleitet werden kann. Tabelle 12 liefert einen Überblick über die 10 häufigsten Themenbereiche bei SourceForge.net.

¹ Beispiel für nicht-englisches SourceForge.net Projekte: Spanisches Projekt Facturalux: http:// sourceforge.net/projects/facturalux/ - Zugriffsdatum: 21.07.2003

33

Tabelle 11: SourceForge.net Projekte - 10 häufigste natürliche Sprachen (Quelle: SourceForge.net, 2003d)

4.5 Kommunikations- und Präsentationsinfrastruktur

Eine funktionierende Kommunikations- und Präsentationsinfrastruktur ist eine wichtige Voraussetzung für die Existenz von Open Source Softeareprojekten. Sieckmann (2001) gibt vier Hauptkanäle an, die zur Kommunikation zwischen Entwicklern untereinander und zwischen Entwicklern und Benutzern, sowie zur Präsentation genutzt werden (Sieckmann, 2001, Kap. 5.2.3.2): Web-Seiten, Mailing-Listen, Newsgroups und Entwicklerwerkzeuge.

4.5.1 Web-Seiten

Die Projekt-Webseiten sind eine wichtige Informations-, Präsentations-, Kommunikations-, Koordinations-, Dokumentations- und Distributionsquelle. Es werden Basisinformationen über das Projekt vermittelt, Releases werden oft über diesen Kanal angekündigt und vertrieben, die Projektdokumentation wird hierdurch zugänglich gemacht (u.a. auch FAQ - Häufig gestellte Fragen). Eine andere wichtige Anwendung dieses Kanals ist die Präsentation des Projekts und das Werben von neuen Benutzern, Beta-Testern und manchmal auch Entwicklern. Zu den Web-Seiten gehören auch eventuelle Benutzerforen, die leicht zugängliche Diskussionen zwischen Benutzern und Entwicklern ermöglichen. Zusätzlich kann man oft auch auf Web-basierte Systeme treffen, die für Bug-Reporting (Fehlerberichte), Verbesserungsvorschläge, oder Support optimiert sind, wie z.B. das System von SourceForge.net (siehe SourceForge.net, 2003c).

4.5.2 Mailing-Listen und Newsgroups

Die zweite wichtige Gruppe sind Mailing-Listen. Sie dienen hauptsächlich der Kommunikation zwischen Entwicklern untereinander bzw. zwischen Benutzern und Entwicklern. Hierfür werden diese Listen meistens je nach Art getrennt geführt, mit unterschiedlichen Zugangsberechtigungen. Üblich ist die Trennung in Benutzer- und Entwickler sowie allge-

34

Tabelle 12: SourceForge.net Projekte - 10 häufigste Themenbereiche (Quelle: SourceForge.net, 2003d)

meine und spezielle Mailing-Listen. Als Ergänzung der Mailing-Listen (oder selbständig) können auch projekteigene Newsgroups geführt werden.

4.5.3 Entwicklerwerkzeuge

Das Infrastruktur-Kern vieler Open Source Softeareprojekte sind die Entwicklerwerkzeuge. Ein Großteil der Projekte verwendet das Versionsmanagementsystem CVS (Concurrent Versions System) für die Quellcode-Zugang (siehe Cederquist u. a., 1992, 1993). Dieses System stellt eine Grundlage für einen standardisierten, einheitlichen und koordinierten Zugang zur Bearbeitung des gemeinsamen Quellcodes für alle Entwickler zur Verfügung und speichert alle Versionen von bearbeiteten Dateien. Die Fehlersuche kann dadurch erheblich einfacher gemacht werden, da Änderungen zwischen verschiedenen Versionen von Dateien einzeln veranschaulicht werden können.

4.6 Dokumentation

Die Dokumentation ist ein wichtiger Bestandteil jedes Open Source Projekts. Dieses Unterkapitel soll einen groben Überblick über die mögliche Dokumentationszusammensetzung von Open Source Softeareprojekten liefern. Die Dokumentation kann grundsätzlich in zwei Bereiche geteilt werden - die produktbezogene- und die projektbezogene Dokumentation.

4.6.1 Produktbezogene Dokumentation

Die produktbezogene Dokumentation hat das Ziel das Produkt, d.h. die Open Source Software, und seine Nutzung zu beschreiben. Hier können je nach Zielgruppe in zwei Kategorien unterschieden werden - Dokumentation für Entwickler und Dokumentation für Endbenutzer.

35

• Benutzerdokumentation

Diese Dokumentation hat das Ziel dem Benutzer die Nutzung der Software zu erleichtern. Hierzu gehört meistens die Installations- und Nutzungsanleitung. Es kann vorkommen, dass diese getrennt werden, z.B. wenn es sich um Software handelt, die auf Servern installiert werden soll und Benutzer auf diese zugreifen sollen (z.B. Horde - siehe Kap 5.2). Hier ist die Installationsdokumentation an den Systemadmi-nistrator und die Nutzungsdokumentation and die zugreifenden Benutzer gerichtet.

Die Benutzerdokumentation kann in verschiedenen Formaten vorliegen, z.B. Textbasierte Ausgabe in der Shell, Web-Seiten oder auch in Bücherform (z.B: FreeBSD German Documentation Project, 2003).

• Entwicklerdokumentation

Die produktbezogene Dokumentation für Entwickler beschreibt üblicherweise den Aufbau und Funktionsweise der Software, eventuell Richtlinien für dessen Gestaltung, Änderung oder Erweiterung. Diese Art der Dokumentation ist oft bereits im Quellcode in Kommentar-Form verankert. Es ist aber ebenfalls auch in Dokumen-tenform anzutreffen - wie z.B. bei FreeBSD (FreeBSD Project, 2003f).

4.6.2 Projektbezogene Dokumentation

Die projektbezogene Dokumentation betrifft wie bereits im Namen verankert das Projekt und seine Mitglieder selbst. Hierzu gehört vor allem die Dokumentation des Projektaufbaus, der Projektabläufe, sowie interne Projektrichtlinien.

• Aufbaudokumentation

Die Aufbaudokumentation beschreibt den Aufbau der projekteigenen Strukturen wie z.B. die Organisationsstruktur inkl. Projektstellen mit Zuständigkeiten oder die Leitungs- und Entscheidungsstruktur.

• Ablaufdokumentation

Die Ablaufdokumentation beinhaltet Dokumentation spezifischer Projektabläufe. Hierzu gehören z.B der Prozess der Aufnahme neuer Entwickler, bei demokratisch organisierten Projekten die Wahlprozedur, oder die Dokumentation der Abläufe beim Release-Prozess.

• Projektrichtlinien

Die Projektrichtlinien dienen als Navigation für bestimmte Projektabläufe. Hierzu gehört unter anderem die Pflicht zum Dokumentieren von bestimmten Zuständen und Aktivitäten (z.B. Meldung über durchgeführte Änderungen im Quellcode).

36

5 Fallbeispiele

In diesem Kapitel werden einige bestehende unterschiedliche Open Source Projekte im Bezug auf die im Kapitel 4. vorgestellten Merkmale beschrieben und untersucht. Das Ziel der ersten Projektuntersuchung ist die grobe Darstellung der Dienste und Prinzipien des Open Source Portals SourceForge.net. Da alle Projekte, die bei Open Source Portalen mit der SourceForge Software diese verwenden (können), kann man dies bereits als eine Art Standardisierung, die vor allem kleine und mittlere Projekte betrifft. Größeren Projekten stehen oft viel mehr Ressourcen zur Verfügung und diese verwenden daher oft eigene, selbstentwickelte und für das Projekt optimierte Infrastruktur. Das zweite untersuchte Projekt ist das Projekt HORDE, welches eine Basisplatform für eine Web-basierte Groupware-Lösung darstellt. Im letzten Teil dieses Kapitels werden zwei sehr große Open Source Projekte FreeBSD und Debian Linux untersucht. Im letztem Unterkapitel (5.5) werden einige Gemeinsamkeiten und Unterschiede dieser Projekte zusammengefasst.

5.1 SourceForge.net: AWStats

Beim OS-Projekt AWStats (Project AWStats, 2003e), welches bei SourceForge.net untergebracht ist, handelt sich um ein Web-Statistikprogramm, welches neben umfangreichen Web- auch Mail- und FTP- Statistiken erzeugen kann. Dieses Projekt wurde ausgewählt zur groben Schilderung der SourceForge.net Infrastruktur, die für alle dort untergebrachte Projekte gleich ist.

Das erste Release von AWStats datiert 2 Jahre zurück (siehe Project AWStats, 2003d). Das letzte Release zu diesem Zeitpunkt (30.08.2003) ist 5.7 und es wird an der Version 5.8 gearbeitet. Das Programm selbst ist in der Skriptsprache Perl modular geschrieben, Zusätze (Plug-ins) sind möglich.

5.1.1 Merkmale

Projektgröße

Das Projekt hat 5 registrierte Entwickler, einer davon ist zur gleichen Zeit Projektad-ministrator. Die Größe des CVS Quellcodes ¹ beträgt 2.86 MB (Project AWStats, 2003e, Files), wobei aber zu beachten ist, daß auch Dokumentation (ca. 25% der Bytegröße) enthalten ist. Die im Kap. 4.1 eingeführte Größenklasifizierung empfiehlt für dieses Projekt nach der Entwicklerzahl die Kategorie ”mittel” und nach der Bytegröße die Kategorie ”groß”. Hier wird die Entscheidung zugunsten von ”mittel” getroffen, da nur 5 Entwickler am Projekt arbeiten. Das Projekt deklariert drei Unterprojekte (Quelle: Project AWStats, 2003e, Tasks): AWStats Dokumentation, AWStats Plugins und AWStats. Es gibt aber nur ein gemeinsames Release, daher kann nicht von alleinstehenden Unterprojekten gesprochen werden.

¹ Quellcode direkt von AWStats CVS, Datum: 03.09.2003

37

Leitungs- und Entscheidungsstruktur

Bei der Leitungs- und Entscheidungsstruktur liegt hier eindeutig der Fall eines ”benevolent dictator” (siehe 4.2) vor, da es nur einen Projektadministrator gibt. Bei SourceForge.net ergibt der Status eines Projektentwicklers Schreibrechte auf den Quellcode und nur Projektadministratoren können neue Entwickler (aber auch neue Administratoren) aufnehmen und alte entlassen. Damit ein neuer Projektadministrator oder Projektentwickler aufgenommen werden kann, wird zusätzlich ein registriertes Benutzerkonto bei Source-Forge.net benötigt.

Entwicklung und Release Management

Das Projekt arbeitet mit dem CVS-System (Project AWStats, 2003e, CVS), dass von SourceForge.net angeboten wird (siehe SourceForge.net, 2003c, Sektion F). Besondere Wegen der niedrigen Entwicklerzahl ist der Bedarf nach einer Standardisierung und Überprüfung der Einhaltung der Standards der einzelnen Entwicklungsvorgänge relativ niedrig. Das Projekt führt nur einen Entwicklungsstrang, aus diesem werden Releases gemacht. Das Release Management wird (Standardvorgehen bei SourceForge.net) von Administra-toren bestimmt und geleitet. Das News-Bereich der Projekt Hauptseite (Project AWStats, 2003e, News) kann abgelesen werden, dass zwei Typen von Releases veröffentlicht wer-

38

den, der erste im Beta-Zustand, nur über die Homepage distribuiert, und der zweite Typus ist das offizielle Final-Release, welches über das SourceForge.Net Distributionssystem verteilt wird (Project AWStats, 2003e, Files). Releases werden in komprimierter Form in vier verschiedenen Formaten zum Download angeboten (ab Version 5.0, zuletzt überprüft: Version 5.7).

Entwicklungsspezifische Merkmale

Da sich das Projekt bei SourceForge.net befindet, liegt eine Trove Kategorisierung vor (siehe Kap. 4.3). Diese befindet sich in Tabelle 13. Die Versionierung beim Projekt ist zweistellig, Major und Minor. (siehe 4.3.5). Das Aktivitätsperzentil des Projekts ist sehr hoch (99.9268%, bezogen auf vorgegangene Woche) (Project AWStats, 2003e, Summary), woraus man auf eine sehr aktive Teilnahme der Benutzer und Entwickler schließen kann. Das Projekt unterliegt der GPL (GNU General Public License, siehe Kap. 2.2.4) (siehe Project AWStats, 2003e, Summary). Die entwicklungsspezifischen Merkmale sind in Tabelle 13 zusammengefasst.

Benutzerspezifische Merkmale

Die Hauptsprache des Projektes ist Englisch, die Ausgabe der Software enthält aber Module für eine Vielzahl an Sprachen. In der SourceForge.net Trove Kategorisierung wurde aber nur Englisch und Französisch angeführt. Die Zielgruppe sind vor allem Syste-madministratoren. Die Benutzerschnittstelle ist Console (Text) für Steuerung und Einstellungen, Web-Umgebung für Präsentation (kann aber auch zur Steuerung genutzt werden). Als Themenbereich haben die Autoren Untergruppen des Themenbereichs Internet angeführt (näheres siehe Tabelle 14).

5.1.2 Infrastruktur Web-Seiten

Das Projekt AWStats präsentiert seine Ergebnisse (Software) auf der Homepage (Pro- jectAWStats, 2003d). Um zusätzliche Anwender zu gewinnen, wird auf dieser Webseite auf die Funktionsvielfalt der Software hingewiesen, sowie ein Vergleich mit konkurrierenden Open Source Softeareprojekten durchgeführt. Über diesen Kanal ist auch Software-Dokumentation abrufbar.

Die Release-Dateien zum Download, sowie Mailing-Listen, Benutzerforen, Fehlerberichte, Änderungsvorschläge und Support-Anfragen (alles Standarddienste von Source-Forge.net) sind über die Projektseite von AWStats bei SourceForge.net (Project AWStats, 2003e) zugänglich.

Das Projekt führt zwei Benutzerforen (Project AWStats, 2003e, Forums). Eines nur für Entwickler, und eines wo auch Benutzer ihre Meinung mitteilen bzw. austauschen können.

Mailing-Listen

Es wird eine Mailing-Liste mit dem Namen ”awstats-public” (Project AWStats, 2003e, Lists) geführt. Diese dient laut der Listenbeschreibung (Project AWStats, 2003b) für E-Mail Ankündigungen an die Abonennten über die Verfügbarkeit neuer Releases und Updates. Zu diesem Zweck wird auch das Nachrichtensystem genutzt.

Fehlerberichte und Änderungsvorschläge

Entdeckte Fehler können über das Bug-Reporting-System von registrierten Source-Forge.net Benutzern an die Projektentwickler mitgeteilt werden. Zusätzlich können noch Support-Anfragen und Vorschläge für neue Funktionen über einen eigenen Bereich vermittelt werden. Vorschläge für neue Funktionen haben ebenfalls ein eigenes Interface zur Vermittlung.

Support

Supportanfragen werden über das standardisierte Support-Interface von SourceForge.net abgewickelt (Project AWStats, 2003e, Support), oder in den Mailing-Listen.

5.1.3 Dokumentation

AWStats besitzt eine umfangreiche Benutzerdokumentation (Project AWStats, 2003a), die sowohl Installations- als auch Nutzungsaleitung beinhaltet. Eine Kopie dieser Dokumentation befindet sich direkt im Release (Unterverzeichnis docs, Stand Version 5.7). Zusätzlich existiert eine Liste der häufig gestellten Fragen (Project AWStats, 2003c). Entwicklerdokumentation ist nur im Quellcode und im CVS System vorhanden. Da das Projekt die Dienste von SourceForge.net in Anspruch nimmt, zählt die Dokumentation der Nutzung dieser Dienste (siehe SourceForge.net, 2003c) zur projektbezogenen Dokumentation.

40

5.1.4 Zusammenfassung

Beim Projekt AWStats handelt um ein aktives SourceForge.net Projekt mittlerer Größe mit einfacher Struktur, detailierter Dokumentation und funktionierender Benutzer-Unterstützung. Das Projekt wird von einem einzigen Administrator geleitet, steht unter der GPL Lizenz und bedient sich fast aller Infrastruktur-Dienste von SourceForge.net.

5.2 Horde

Das Projekt Horde stellt ein Basissystem für Web-Anwendungen (z.B. Groupware Lösungen) zur Verfügung, das einheitliche Funktionen wie Authentifizierung, Sitzungsmanagement, Log-Dateien, Verschlüsselung, Formularmanagement und andere anbietet (siehe Horde Project, 2003f). Unter dem Dach von Horde sind weitere (Unter-)Projekte organisiert, die Anwendungen für dieses Basissystem bereitstellen. Zu diesen gehören auch IMP -Webmail, Turba - Web-Adressbuch oder Kronolith - eine Web-Kalenderanwendung (siehe Horde Project, 2003f, Projects). Dieses Projekt wurde ausgewählt, weil es zu der Gruppe von Projekten gehört die abhängig von ihren Unterprojekten sind. Zum sinnvollen Gebrauch vom Horde-Basissystem wird immer mindestens eine Zusatzanwendung benötigt. Untersucht wird aber nur das Basissystem von Horde, nicht die Zusatzanwendungen. Das Projekt ist über 4 Jahre alt, das Datum des 1.0.0 Releases, sowie der Copyright-Hinweis enthalten die Jahreszahl 1999 (siehe Horde Project, 2003e). Das letzte Stabile Release ist 2.2.3 (zum 31.08.2003) und die Entwicklungsversion ist 3.0 (ebenfalls zum 31.08.2003).

5.2.1 Merkmale

Projektgröße

Das Projekt hat 9 Hauptentwickler, die sich selbst das ”Core Team” nennen (siehe Horde Project, 2003b), und zum Teil auch an einzelnen Zusatzanwendungen tätig sind. Zugang zum Quellcode haben laut CVS ¹ 26 Entwickler. Die Bytegröße des Quellcodes im CVS ² für das Horde-Basissystem ist 9.3 MB, davon ca 3.6 MB Sprachdateien. Bei der Größenklassifizierung muss man sich die Frage stellen, ob Unterprojekte einbezogen werden sollen, oder nicht. Hier liegt ein Fall vor, wo das Horde Basissystem alleinstehend prinzipiell nicht genutzt werden kann, es wird mindestens eine dieser Anwendung benötigt. Es ist aber nicht festgelegt, welche. Daher wird das Basissystem alleine eingestuft. Die Kategorisierung im Kap. 4.1 empfiehlt die Einstufung als ”mittel” nach der Entwicklerzahl, oder ”sehr groß” nach der Bytegröße. Hier wird wegen der niedrigen Zahl der aktiven Entwickler auch eine Einstufung als ”mittel” vorgenommen (bei Nicht-Beachtung der Zusatzanwendungen, betrachtet wird nur das Horde-Basissystem alleine, d.h. auch nur Entwickler die am Basissystem arbeiten).

¹ siehe http://cvs.horde.org/co.php/CVSROOT/cvsusers, Zugangsdatum: 31.08.2003

² Quellcode direkt von Horde CVS, Datum: 03.09.2003

41

Leitungs- und Entscheidungsstruktur

Die Leitungs- und Entscheidungsstruktur des Projektes ist nach dem Zwiebelschalenprinzip organisiert ¹ . Im Zentrum liegt wieder ein ”benevolent dictator” mit seinen ”trusted lieutenants” - dem Core Team. Das Core Team hat die Entscheidungsgewalt über die Aufnahme und Entlassung neuer Entwickler.

Entwicklung und Release Management

Das Projekt hat ein eigenes CVS-System (siehe Horde Project, 2003c) und führt zwei Entwicklungsstränge (Horde Project, 2003h). Der erste (Stable 2.0) ist der Produktionsstrang und aus ihm werden Releases gemacht (z.B: 2.2.x). Der zweite Strang (HEAD) dient der Entwicklung (es wird an der künftigen Version 3.0 gearbeitet). Es gibt keine fixe Zuständigkeit für das Release Management, es wird nach Rücksprache mit anderen von einem beliebigen Core-Mitglied durchgeführt. Vor endgültigen Releases werden Release Candidates (RC) zum Testen veröffentlicht. Die Distribution erfolgt über FTP (Horde Project, 2003e), Dateien werden in einem komprimierten Format zum Download angeboten.

¹ Informationen über die Leitungs- und Entscheidungsstruktur und das Release-Management basieren auf der Beantwortung einer E-Mail Anfrage durch eines der Core-Mitglieder.

42

Entwicklungsspezifische Merkmale

Bei den zwei Entwicklungssträngen ist beim ersten ein Produktions- und beim zweiten ein Alpha-Entwicklungszustand zu erkennen. Zusätzlich kann man vom Alter der Software und Referenzen ausgehen, dass auch der Reifezustand erreicht wurde. Die verwendete Programmiersprache ist die Skriptsprache PHP, und daraus können auch die entsprechenden Abhängigkeiten abgeleitet werden. Horde benötigt einen Webserver, der mit PHP und bestimmten Erweiterungen von PHP arbeiten kann. Es ist aber nicht an ein bestimmtes Betriebssystem gebunden. Die Projektlizenz ist LGPL (siehe Horde Project, 2003a), die Versionierung ist dreistellig, MAJOR.MINOR.PATCHLEVEL (siehe Releases unter: Horde Project, 2003e).

Das Projekt unterliegt der LGPL (GNU Lesser Public License, siehe Kap. 2.2.4) (siehe Project AWStats, 2003e, Summary). Dies ist auf Tabelle 15 zusammengefasst.

Benutzerspezifische Merkmale

Die Projekt-Zielgruppe sind Entwickler von Zusatzanwendungen, und in Verbindung mit diesen auch Endbenutzer und Systemadministratoren. Die Interaktion mit dem Programm findet über die Web-Umgebung statt. Das Hauptsprache des Projekts ist Englisch (Webseiten, Dokumentation), das Benutzerinterface arbeitet aber mit mehreren Übersetzungen ¹ . Das Themengebiet des Projektes sind Web-Anwendungen für das Internet. Eine Zusammenfassung ist in Tabelle 16.

¹ siehe Verzeichnis ”locale” in der Distribution (z.B. 2.2.3, ftp://ftp.horde.org/pub/horde/ horde-2.2.3.tar.gz - Zugriffsdatum: 31.08.2003

43

5.2.2 Infrastruktur Web-Seiten

Das Projekt Horde zentralisiert seine Webseiten auf horde.org (Horde Project, 2003f). Ähnlich wie beim Projekt AWStats präsentiert das Projekt dort sich und seine Ziele. Da beim Projekt Horde vor allem die Zusatzapplikationen für Endbenutzer interessant sind, werden diese inklusive des hier untersuchten Basissystems (”The Horde Application Framework”) unter ”Projects” vorgestellt.

Zusätzlich kann man über die Homepage zu den folgenden wichtigen Bereichen gelangen: Dokumentation für Endbenutzer und Systemadministratoren, Web-Portal zum CVS, Mailing-Listen. Datei-Download von Releases erfolgt über eine FTP-Verbindung (Horde Project, 2003e).

Dokumentation für Entwickler ist über eigene Web-Seiten abrufbar. (Horde Project, 2003h)

Mailing-Listen

Ein Großteil der Kommunikation bei Horde wird über die Mailing-Listen abgewickelt. Das Projekt Horde hat vier benutzerorientierte und drei entwicklerorientierte allgemeine Mailing-Listen (siehe Tabelle 17). Die Auflistung auf der Homepage von Horde beinhaltet auch Mailing-Listen von Zusatzanwendungen (siehe Horde Project, 2003j).

Fehlerberichte, Änderungsvorschläge und Support

Für Fehlerberichte existiert bei Horde ein gesondertes Interface (Horde Project, 2003g), welches das Bugzilla (Bugzilla, 2003) System für Verfolgung von Fehlern verwendet. Für sonstige Anfragen inkl. Support und Änderungsvorschlägen sind die Mailing-Listen vorgesehen.

5.2.3 Dokumentation

Die Benutzerdokumentation für Horde besteht aus einer im Release inkludierten Installationsanleitung (Datei docs/INSTALL, Stand: Release 2.2.3), eingebauter Online-Hilfe und

44

zwei FAQ-Listen (Horde Project, 2003d), eine für Benutzer und eine für Systemadmi-nistratoren. Entwicklerdokumentation ist im Quellcode, im CVS-System und eine Dokumentation der Funktionen ist auch im Web vorzufinden (Horde Project, 2003h). Zusätzlich werden auf der Homepage Verweise zu mehreren Publikationen (Horde Project, 2003i) angeführt, die die Horde-Entwicklung betreffen.

5.2.4 Zusammenfassung

Das Projekt Horde ist ein zusammengesetztes Projekt, welches aus einem Kern und mehreren an dieses Kern angeknüpften (Unter-)Projekten besteht. Das Kern kann selbst als mittelgroßes Projekt eingestuft werden. Es steht unter der LGPL Lizenz. Ein Core-Team von 9 Mitgliedern leitet das Projekt, wobei dem Gründer besondere Privilegien zustehen. Das Projekt hat detailierte Dokumentation für Benutzer und auch eine Dokumentation für Entwickler. Die Kommunikation wird hauptsächlich über Mailing-Listen abgewickelt und die verwendeten Infrastruktur-Dienste werden vom Projekt selbst unabhängig geführt.

5.3 FreeBSD

FreeBSD ist ein Open Source Betriebssystem, welches auf mehreren Platformen läuft und dank seiner hervorragenden Netzwerkfähigkeiten hauptsächlich im Server-Bereich eingesetzt wird, aber auch im Desktop Bereich mit gängigen Linux-Distributionen verglichen werden kann.

Wir glauben unsere erste und wichtigste “Mission” ist es, Software für jeden Interessierten und zu jedem Zweck zur Verfügung zu stellen, damit die Software größtmögliche Verbreitung erlangt und größtmöglichen Nutzen stiftet. (FreeBSD German Documentation Project, 2003, Kap. 1.3.2)

Das FreeBSD Projekt ging aus dem Betriebssystem 386BSD hervor und die Version 1.0 erschien im Dezember 1993 (FreeBSD German Documentation Project, 2003, Kap. 1.3.1).

5.3.1 Merkmale

Projektgröße

Das Projekt hat über 300 Entwickler mit CVS Schreibrechten (FreeBSD Project, 2003a, Abschnitt 3). Die Größe des Quellcode der Version 4.8 für die i386 Platform ¹ beträgt über 370 MByte. Dies beinhaltet nicht die FreeBSD-Dokumentation (FreeBSD Project, 2003h). Der Gesamt-Quellcode des Projektes ist aber noch wesentlich größer. Das Projekt ist sowohl nach der Entwicklerzahl als auch nach der Bytegröße als ”sehr groß” einzustufen (nach Kap. 4.1).

¹ Die Information über die Größe des Quellcodes wurde direkt vom FreeBSD CVS bezogen (Web-Interface: FreeBSD Project, 2003d)

45

Leitungs- und Endscheidungsstruktur

Das Projekt wird von einem Core Team geleitet, das aus 9 Mitgliedern besteht (siehe FreeBSD Project, 2003b). Das Core Team wird alle 2 Jahre von den FreeBSD Entwicklern mit CVS-Schreibrechten gewählt. Das Projekt besitzt drei leitende Stellen ² : Das Core Team (zuständig für den Haupt-Quellcode ”src”), die ”Port Manager” Gruppe (zuständig für ”ports” ³ ) und die ”Documentation Engineering” Gruppe (zuständig für die FreeBSD Dokumentation). Die CVS-Schreibrechte können von diesen Stellen für ihre Bereiche vergeben werden und alle drei Stellen können neue Entwickler aufnehmen. Das Core Team bleibt aber weiterhin die höchste Instanz. Neue Entwickler werden üblicherweise von einem bereits existierendem Entwickler vorgeschlagen, nach ihren bisherigen Beiträgen beurteilt, und falls es zu einer Aufnahme kommt dient der vorschlagende Entwickler als ”Mentor” (Helfer) für den neuen Entwickler.

² Diese Informationen beruhen auf der Antwort eines FreeBSD Entwicklers auf E-Mail Anfrage.

³ FreeBSD Ports ist ein System für angepasste projektfremde Anwendungen, die hierdurch installiert und verwaltet werden können.

46

Entwicklung und Release-Management

Das Projekt führt ein eigenes CVS-System (siehe Web-Interface: FreeBSD Project, 2003d). Dieses ist prinzipiell in zwei Hauptstränge geteilt (siehe Jorgensen, 2001, Abschnitt 5):

• CURRENT - der auf neue Funktionen ausgerichteter Entwicklungsstrang, neuer Code wird hier zuerst intensiv getestet

• STABLE - der auf Stabilität ausgerichteter Produktionsstrang, bewährter, stabiler und sicherer Code wird in diesen Strang importiert

Das Release-Management wird von einer hierfür geschaffenen Stelle geleitet, dem ”FreeBSD Release engineering team”. Dieses verfügt über eigene Dokumentation (siehe Stokley, 2003). Releases werden grundsätzlich aus dem STABLE-Strang gemacht (Ausnahme: beim Umstiegsprozess auf neue MAJOR-Version). Vor dem Release findet immer eine Test-Periode mit einem ”Code-Freeze” statt, wo neue Beiträge nur nach Zulassung durch das Release Engineering Team hinzugefügt werden können. Während dieser Periode werden Release Candidates (RC) veröffentlicht. Auf der Homepage von Release Engineering (FreeBSD Project, 2003k) werden betreffende Informationen und Termine angezeigt.

Releases werden als CD-Images oder komprimierte Dateien zum Download angeboten (FreeBSD German Documentation Project, 2003, Anhang A.2), sind aber auch von mehreren komerziellen Anbietern auf CD oder DVD Medien erhältlich (FreeBSD German Documentation Project, 2003, Anhang A.1).

Entwicklungsspezifische Merkmale

Den zwei geführten Entwicklungssträngen können Entwicklungszustände Alpha und Produktion zugewiesen werden. Releases aus dem STABLE-Strang können wegen umfangreichen Tests sogar als Reif (Mature) betrachtet werden (z.B: 4.8-RELEASE). Die verwendete Programmiersprache ist überwiegend C (es kommen aber auch andere Sprachen wie z.B. Perl vor). Da es sich selbst um ein Betriebssystem handelt, ist diese Software Betriebssystem-unabhängig. Der Großteil der Software steht unter der BSD Lizenz (siehe 2.2.2), einzelne Teile stehen aber auch unter anderen Lizenzen wie z.B. GPL oder LGPL. Die Versionierung ist üblicherweise zweistellig, es kann aber bei Releases auch eine dritte Stelle (PATCHLEVEL) vorkommen (siehe FreeBSD Project, 2003l). Eine Übersicht über die entwicklungsspezifischen Merkmale ist in Tabelle 18 zu finden.

Benutzerspezifische Merkmale

Da sich beim FreeBSD um ein Betriebssystem handelt, das sowohl als Basis für Desktop-Anwendungen, auch als Mehrbenutzer-Server arbeiten kann. Es umfasst die Zielgruppen Systemadministratoren, Endbenutzer und Entwickler. Die Hauptsprache von FreeBSD ist Englisch, ein Teil der Dokumentation ist bereits in andere Sprachen übersetzt wie z.B. die deutsche Version des FreeBSD Handbuchs (FreeBSD German Documentation Project, 2003). Viele mitgelieferte Anwendungen von FreeBSD unterstützen Ausgabe in mehreren Sprachen. Die FreeBSD Releases alleine inkludieren ein text-basiertes Interface (Console), zusätzliche Interfaces wie z.B. X-Windows müssen als Drittanwendung nachträglich installiert werden (FreeBSD German Documentation Project, 2003, Kap. 5.3). Serverprogramme sind aber in der Basisdistribution enthalten, und daher zählt auch kein Input/Output (Daemon) dazu. Der Themenbereich ist relativ einfach zu identifizieren, es handelt sich um die Themengruppe System und Untergruppen Betriebssystemkernel und Softwaredistribution. Eine Zusammenfassung ist in Tabelle 19 zu finden.

5.3.2 Infrastruktur

Web-Seiten

Das Projekt FreeBSD organisiert seine primäre Web-Präsenz auf freebsd.org (FreeBSD Project, 2003j). Diese Präsenz wird auf mehreren Servern weltweit gespiegelt. Das Web beinhaltet unter anderem die Vorstellung der Software, aktuelle Informationen, Verweise zum Besorgen der Software, ein Fehlerberichtssystem, Web-Interface zum CVS-System, umfangreiche Dokumentation und umfangreiche technische Unterstützung.

Mailing-Listen und Newsgroups

Eine Vielzahl an Mailing-Listen und Newsgroups gehören zum FreeBSD Support (FreeBSD Project, 2003m, Mailing-Lists, Newsgroups). Die Mailing-Listen (FreeBSD German Documentation Project, 2003, Appendix C.1.1) teilen sich in allgemeine, technische und eingeschränkte. Diese Listen inkludieren auch eine Liste für Ankündigungen von neuen Software-Releases (freebsd-announce), oder über sicherheitsrelevante Aspekte (freebsd-security).

Fehlerberichte, Änderungsvorschläge und Support

FreeBSD besitzt ein eigenes, komplexes System zur Bearbeitung von Fehlerberichten und Änderungsvorschlägen. Hierzu wird die sog. GNATS Datenbank verwendet (siehe FreeBSD Project, 2003m, GNATS). Die Fehlerberichte (und Änderungsvorschläge) werden in mehreren Dimensionen unterteilt, unter anderem nach Dringlichkeit und nach Teil

48

des Betriebssystems. Support-Anfragen werden überwiegend über die Mailing-Listen und Newsgroups beantwortet.

5.3.3 Dokumentation

Die Dokumentation wird von einem Unterprojekt bereitgestellt, das sich das FreeBSD Documentation Projekt nennt (FreeBSD Project, 2003h). Die Dokumentation (FreeBSD Project, 2003e) teilt sich technisch in drei Kategorien (FreeBSD Project, 2003h, The FreeBSD Documentation Set):

• ”Manual pages”

dies ist ein Teil des Basissystems von FreeBSD, es handelt sich um spezielle Dokumentation im UNIX ”man” Format, die zu einzelnen Teilen des Betriebssystems geliefert wird.

• Bücher

unter Büchern werden umfangreichere Publikationen zusammengefasst, die in konvertierbarem SGML Format geschrieben sind und in mehreren Formaten heruntergeladen werden können (z.B: HTML, PDF). Hierzu gehören Dokumentation für Benutzer - z.B. das FreeBSD Handbuch (FreeBSD German Documentation Project, 2003), oder FAQ (Häufig gestellte Fragen), Dokumentation für Entwicklerz.B. : FreeBSD Developer’s Handbook (FreeBSD Project, 2003f), oder FreeBSD Architecture Handbook (FreeBSD Project, 2003g).

• Artikel

Die vom FreeBSD Documentation Project angebotenen Artikel umfassen verschiedene Themen rund um FreeBSD und werden in auch in konvertierbarem SGML Format geschrieben und können in mehreren Formaten heruntergeladen werden. Zu diesen Artikeln gehören auch die Liste der FreeBSD Beitragenden (FreeBSD Project, 2003a) oder die Dokumentation zum Release-Engineering (Stokley, 2003). Das FreeBSD Projekt besitzt auch eine umfangreiche projektbezogene Dokumentation. Ein Großteil dieser Dokumentation ist im im internen FreeBSD Web-Bereich (FreeBSD Project, 2003i) aufgelistet. Zu diesen Dokumenten gehören auch die Wahlprozedur zum FreeBSD Core Team (FreeBSD Project, 2003c) und die Dokumentation zur Behandlung von Fehlerberichten (Smørgrav und Pandya, 2003).

5.3.4 Zusammenfassung

Das Projekt FreeBSD ist ein Großprojekt mit mehreren hundert Entwicklern. Es wird von einem demokratisch für eine Periode von 2 Jahren gewähltem Core-Team geleitet und besitzt ein funktionierendes System von internen Richtlinien und Regelungen. Das Projekt hat ein weit ausgebautes Kommunikations- und Koordinationsnetz und verfügt über detailierte Dokumentation für Benutzer und Entwickler, sowie über Dokumentation der internen Projektvorgänge und -strukturen.

49

5.4 Debian

Debian ist eine Organisation, die 100% aus Freiwilligenarbeit besteht und sich der freien Software und den Grundsätzen der Free Software Foundation verschrieben hat. (Perens u. a., 1996-2002, Kap. 1.1)

Das Debian-Projekt stellt ein freies Betriebssystem zusammen, welches den Linux-Betriebssystemkern verwendet und für mehrere Hardwareplatformen angeboten wird. Die meisten Systemwerkzeuge stammen vom GNU-Projekt (GNU-Projekt, 2003c). Das Debian-Projekt wurde von Ian Murdock in August 1993 angefangen (Debian Documentation Team, 2003, Kap. 4.1).

5.4.1 Merkmale

Projektgröße

Das Debian-Projekt ist in sog. ”packages” (Pakete) geteilt, von denen jedes einen oder mehrere ”maintainer” (Verwalter) hat. Diese ”maintainer” sind die eigentlichen Entwickler,

50

deren Zahl beträgt über 1000 (siehe Debian-Projekt, 2003l). Die Größe des Quellcodes liegt im Bereich von mehreren hundert MB bis mehreren GB ¹ . Daher ist das Projekt zweifelsfrei als ”sehr groß” einzustufen.

Leitungs- und Entscheidungsstruktur

Laut Debian-Verfassung (Debian-Projekt, 2003b) werden jede der Entscheidungen im Projekt getroffen von:

• Entwicklern (über Wahl oder Beschluß der Hauptversammlung)

• Projektleiter

• technischem Ausschuss und/oder seinem Vorsitzenden

• einem individuellen Entwickler der an einer bestimmten Aufgabe arbeitet

• Delegierten des Projektleiters, die mit einer bestimmten Aufgabe beauftragt wurden

• Projektsekretär

Die Debian-Verfassung ordnet jeder der erwähnten Stellen entsprechende Rechte zu. Grundsätzlich trifft in technischen Fragen der technische Ausschuss und in nichttechnischen Fragen der Projektleiter die letzte Entscheidung. Der Projektleiter wird für eine Periode von einem Jahr gewählt. Die Generalversammlung der Entwickler kann die Verfassung ändern und auch die Entscheidungen vom Projektleiter oder technischem Ausschuss aufheben. Die Wahlprozedur ist ebenfalls im Dokument der Debian-Verfassung beschrieben. Die Aufnahme neuer Entwickler ist eine komplexe Prozedur, in der die Fähigkeiten und Identität der Kandidaten überprüft werden müssen. (Carlo u. a., 1997-2003, Kap. 2).

Entwicklung und Release Management

Zur Entwicklung wird das CVS System verwendet (Web-Interface: Debian-Projekt, 2003a). Es werden immer mindestens drei Stränge (Releases) geführt (Debian-Projekt, 2003h):

• stable - die Produktionsversion, wird zur Verwendung empfohlen

• testing - Zwischenstufe zwischen stable und unstable, Stadium der Prüfung im Bezug auf Sicherheit und Stabilität

• unstable - aktive Entwicklung

Diese Versionen werden mit Decknamen versehen (aktuelle stable = ”woody”, testing = ”sarge”, unstable = ”sid”; Zeitpunkt: 07.09.2003). In der Dokumentation für Entwickler (Carlo u. a., 1997-2003) befinden sich Richtlinien für das Arbeiten mit CVS und Paketen.

¹ Indirekter Schluss auf die Bytegröße bezogen auf den Speicherplatzbedarf der Spiegel-Server: http: //www.debian.org/mirror/size.de.html - Zugriffsdatum: 07.09.2003

51

Das Release Management wird von einer hierfür geschaffenen Stelle organisiert (Debian-Projekt, 2003i, Distribution/Release-Verwaltung). Die Vorgehensweise beim Release besteht prinzipiell mittels ”einfrieren” des Quellcodes der ”testing” Version (Debian- Projekt,2003f, Kap. 5.4). Diese wird dann möglichst fehlerfrei gemacht und anschließend in ”stable” umgewandelt und vertrieben.

Die Distributionen können von kommerziellen Anbietern auf CDROM(s) besorgt (Perens u. a., 1996-2002, Kap. 4.1), oder von Debian-Spiegelservern heruntergeladen werden (Perens u. a., 1996-2002, Kap. 4.2).

Entwicklungsspezifische Merkmale

Der Entwicklungsstrang ”stable” kann einem Production-/Stable-, bzw. einem Mature-, ”testing” einem Beta und ”unstable” einem Alpha Entwicklungszustand zugerechnet werden. Releases werden aus ”stable” und ”testing” gemacht, die Versionierung der Releases ist üblicherweise zweistellig (siehe Debian-Projekt, 2003h). Da es sich wieder um ein Betriebssystem handelt, ist es betriebssystemunabhängig. Die Programmiersprache von Debian ist überwiegend C. Da sich Debian aus einzelnen Paketen zusammensetzt, kann die Lizenz je nach Paket variieren. In vielen Fällen (inkl. der Kernpakete) wird es die GPL Lizenz sein (siehe Perens u. a., 1996-2002, Kap 1.8).

Benutzerspezifische Merkmale

Die Zielgruppe von Debian ist prinzipiell identisch mit der von FreeBSD: Endbenutzer, Systemadminist., Entwickler. Die Benutzerschnittstelle ist problematisch zu bestimmen, da sie prinzipiell von den einzelnen Debian-Paketen abhängt. Grundsätzlich ist eine Textschnittstelle ¹ vorhanden, X-Windows sind aber auch in der Distribution enthalten (z.B. bei Ver. 3.0). Zusätzlich können verschiedene Pakete auch andere Schnittstellen bereitstellen. Das Projekt ist international, Entwickler aus der ganzen Welt ² sind involviert. Die Webseiten und Dokumentation sind zum Teil mehrsprachig, als Hauptsprache zählt Englisch. Der Themenbereich ist Softwaredistribution.

¹ Die Textschnittstelle zählt prinzipiell zur Basisausstattung der Linux- bzw. BSD Betriebssysteme.

² Die Weltkarte der Debian Entwickler befindet sich in http://www.debian.org/devel/ developers.loc.de.html - Zugriffsdatum: 07.09.2003

52

5.4.2 Infrastruktur Web-Seiten

Das Debian-Web ist zentral auf www.debian.org organisiert (mit mehreren Spiegelservern weltweit). Das Web beinhaltet unter anderem die Vorstellung des Projekts und der angeboteten Software, Nachrichten, Verweise auf Distributionsquellen, Dokumentation für Benutzer und Entwickler, Fehlerdatenbank und technische Unterstützung. Zur einfacheren Orientierung ist eine Sitemap vorhanden (Debian-Projekt, 2003m) - siehe Abbildung 5.

Mailing-Listen

Die Mailing-Listen von Debian werden auf einem eigenen Server verwaltet (Debian- Projekt,2003g). Diese werden in mehrere Typen unterteilt, unter anderem Mailing-Listen für Benutzer, Entwickler, Übersetzungen und Fehlerberichte. Es wird eine Mailing-Liste für Ankündigungen (debian-announce) geführt und ähnlich wie bei FreeBSD auch eine Mailing-Liste (debian-security-announce) für sicherheitsrelevante Ankündigungen . Die Mailing-Listen für Entwickler beinhalten auch Ankündigungslisten. Das Projekt führt auch Usenet-Newsgroups (siehe Debian-Projekt, 2003n).

Fehlerberichte, Änderungsvorschläge und Support

Das Debian-Projekt führt ein eigenes Fehlerverfolgungssystem (siehe Debian-Projekt, 2003d). Dieses wird detailiert dokumentiert, z.B. eine Anleitung für die Meldung der Fehler ¹ liegt vor. Diese Berichte werden ähnlich wie bei FreeBSD mit Dringlichkeitsstufen und Tags versehen. Änderungsvorschläge können über dieses System, oder über die Mailing-Listen (bzw. per Direkt-Mail an Paketverwalter) übermittelt werden. Support-Anfragen können mit der Hilfe von Mailing-Listen, Newsgroups oder über IRC beantwortet werden (siehe Debian-Projekt, 2003n).

¹ Anleitung zur Meldung der Fehler in Debian: http://www.debian.org/Bugs/Reporting. de.html - Zugriffsdatum: 07.09.2003

53

5.4.3 Dokumentation

Die online verfügbare Debian-Dokumentation (Debian-Projekt, 2003j) wird in folgende Kategorien unterteilt:

• Benutzer-Handbücher

Die Benutzer-Handbücher beinhalten Installations- und Nutzungsanleitungen für Endbenutzer und Systemadministratoren, einige der Dokumente sind auch in mehreren Sprachen verfügbar. Zu dieser Gruppe gehören das Installationshandbuch (Perens u. a., 1996-2002), oder FAQ (die häufig gestellten Fragen).

• Entwickler-Handbücher

Diese Gruppe umfasst Referenzdokumente und Richtlinien für Entwickler. Hierzu gehört auch die Debian Entwickler-Referenz (Carlo u. a., 1997-2003), oder die Anleitung für zukünftige Debian-Maintainer (Rodin, 1998-2001).

• Verschiedene

Hier werden sonstige Dokumente aufgelistet, wie z.B. die Geschichte des Debian Projekts (Debian Documentation Team, 2003) oder Anleitungen zur Erstellung der Dokumentation.

Die projektbezogene Dokumentation befindet sich überwiegend auf den Web-Seiten von Debian. Zu wichtigen Dokumenten dieser Klasse zählen die Debian-Verfassung (Debian- Projekt,2003b) und die Debian-Organisationsstruktur (Debian-Projekt, 2003i).

5.4.4 Zusammenfassung

Das Großprojekt Debian vereinigt mehr als tausend Entwickler unter seinem Dach. Es funktioniert wie eine Organisation, mit eigenen Statuten. Der Kopf der Organisation ist der jährlich demokratisch gewählte Projektleiter, der gemeinsam mit dem technischen Ausschuss über das Projekt entscheidet. Das Projekt verfügt über komplexe Kommunikations-und Koordinationsstrukturen. Es liegt umfangreiche Dokumentation für Benutzer und Entwickler vor, die internen Vorgänge und Strukturen im Projekt sind ebenfalls zum Teil dokumentiert.

54

5.5 Zusammenfassung Fallbeispiele

In diesem Unterkapitel werden einige Gemeinsamkeiten und Unterschiede bei den in Unterkapiteln 5.1 bis 5.4 dargestellten Projekten zusammengefasst.

In Tabellen 22 und 23 werden die Größe, Leitung und Art des Treffens von Entscheidungen verglichen. Die kleineren Projekte AWStats und Horde werden von einer Person ”diktatorisch” geleitet, die großen Projekte FreeBSD und Debian sind demokratisch organisiert.

Tabelle 23: Fallbeispiele: Vergleich - Projektleitung

Tabelle 24 beinhaltet den Vergleich von einigen Projektmerkmalen. Die Lizenzen und Versionierung sind vom Projekt zu Projekt verschieden, wobei die Versionierung aller vier Projekte zumindest die MAJOR- und die MINOR-Version beinhaltet. Hauptsprache is bei allen Projekten Englisch, Zielgruppen sind bei AWStats, FreeBSD und Debian Entwickler, Systemadministratoren und Endbenutzer. Das Basisystem von Horde ist für Entwickler von Zusatzanwendungen gerichtet, erst in Verbindung mit diesem kann es sinnvoll genutzt werden. Bei AWStats und Horde handelt sich um spezielle Internetanwendungen, FreeBSD und Debian sind Betriebssysteme (komplette Distributionen).

¹ Untersucht wird nur das Horde-Kern, das Gesamtprojekt (inkl. Zusatzanwendungen) hat über 20 Entwickler mit CVS Schreibrechten.

² Für Angelegenheiten technischer Natur ist der technische Ausschuss zuständig.

55

Tabelle 25: Fallbeispiele: Vergleich - Kommunikation, Dokumentation

In Tabelle 25 werden die Kommunikationsstrukturen und Dokumentation verglichen. Alle Projekte verfügen über Mailing-Listen, zusätzlich hat jedes Projekt eine Mailing-Liste für Ankündigungen von neuen Versionen bzw. Updates. FreeBSD und Debian haben auch Mailing-Listen wo Sicherheitslücken bzw. -probleme angekündigt werden. AWStats und Horde haben keine offiziellen Newsgroups. Alle Projekte verwenden ein System zur Fehlerberichterstattung. Jedes der Projekte verfügt über Benutzerdokumentation (verschiedene Formate), die kleineren Projekte haben nur beschränkte Entwicklerdokumentation und keine projektbezogene Dokumentation.

¹ Die Lizenzen der Zusatzanwendungen können sich unterscheiden (z.B: GPL, BSD).

² Bestimmte Betriebssystemteile bzw. Pakete stehen unter anderen Open Source Lizenzen.

³ Im geringen Umfang werden auch andere Programmiersprachen verwendet.

⁴ E: Entwickler, S: Systemadministratoren, B: Endbenutzer

⁵ In Verbindung mit Zusatzanwendungen sind auch Systemadministratoren und Endbenutzer Zielgruppe.

⁶ Unterstützung für mehrere Sprachen vorhanden

⁷ Es liegt auch eine Funktionsreferenz im Web vor.

⁸ Die Dokumentation der SourceForge.net Dienste kann zum Teil auch als projektbezogene Dokumentation verstanden werden.

56

6 Resümee

Das Ziel dieser Arbeit war einen Überblick darüber zu gewinnen, wer die Benutzer und Entwickler von Open Source Software sind, in welchem Verhältnis Sie zum Projekt stehen und über welche Kanäle sie miteinander kommunizieren. Zusätzlich sind verschiedene Projektstrukturen und -abläufe vorgestellt worden, die bei Open Source üblich sind. An-hand dieser Informationen sollte es möglich sein, Open Source Projekte zu identifizieren und zu beschreiben. Dadurch entsteht ein Beitrag zur Erforschung der Eigenschaften und Strukturen von Open Source-Projekten und ein Hilfsmittel zur Organisation und Auswahl von Open Source Projekten in der Wirtschaft.

Viele Unternehmen, aber auch der öffentliche Sektor betrachten bereits Open-Source-Lösungen als ebenbürtige, wenn nicht auch zum Teil überlegene Konkurrenten der proprietären Software in vielen Bereichen. Dies verleiht Open Source immer mehr Bedeutung. Zu den Hauptvorteilen der Open-Source-Softwarelösungen gehört vor allem die fast ultimative Anpassungs- und Erweiterungsfähigkeit. Was aber die Open Source Software am Leben erhält, sind deren Benutzer. Deswegen kommt es selten zu Open Source Projekten, die sehr spezialisierte Gebiete betreffen, wo es nur wenige Benutzer gibt.

Offen bleibt die Frage nach der zukünftigen Entwicklung von Open Source. Ein Faktum ist, dass immer mehr Weltbürger Zugang zum Internet erhalten und daher künftige Generationen neue Experten in dieser Richtung produzieren, welche wiederum zu neuen Entwicklern von Open Source Software zählen können. Aus der Seite der Wirtschaft trifft man auf verschiedene Einstellungen. Es gibt Unternehmen, die Open Source Software als schädlich bezeichnen, da dieses in direkter Konkurrenz mit ihren (Software-)Produkten steht und das Umsatzpotential nach unten drückt. Andere Unternehmen betreiben aber Open Source Geschäftsmodelle, und für diese ist das Fortbestehen der Open Source Entwicklung Geschäftsgrundlage. Solange die Gesetzgebung freundlich gegenüber Open Source eingestellt ist kann in jedem Fall ein weiteres Wachstum in diesem Bereich erwartet werden.

57

A Lizenz für die freie Nutzung unveränderter Inhalte

Version 1.0, Mai 2003

Copyright (c) 2003 Kompetenznetzwerk Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen

Es ist jedermann gestattet, diese Lizenz in unveränderter Form zu vervielfältigen, zu verbreiten und öffentlich wiederzugeben.

Präambel

Ziel der Lizenzierung eines Werkes unter der Lizenz für die freie Nutzung unveränderter Inhalte ist es, die freie Verwendung von Inhalten durch jedermann zu ermöglichen. Die Lizenz richtet sich vornehmlich an diejenigen, die ihre urheberrechtlich geschützten Leistungen der Allgemeinheit in der bestehenden Form zur Verfügung stellen wollen, ohne dass für einzelne Nutzungen gesondert Rechte eingeholt werden müssen. Sie richtet sich aber auch an diejenigen, die ein Werk vervielfältigen oder verbreiten möchten, welches nach den Bedingungen dieser Lizenz genutzt werden darf.

Durch die Lizenz für die freie Nutzung unveränderter Inhalte werden dem Lizenznehmer die Nutzungsrechte für alle bekannten Nutzungsarten eingeräumt, aber kein Bearbeitungsrecht. Die ideellen Interessen der Urheber am Werk werden von der Lizenz dabei beachtet, denn es ist eines der Ziele der Lizenz, die kreativen Leistungen der Urheber und anderen Leistungsschutzberechtigten in angemessener Weise anzuerkennen und ihre geistigen Belange zu schützen. Der Urheber soll mit seinem Werk in Verbindung gebracht werden, indem sein Name genannt wird.

Die Lizenz für die freie Nutzung unveränderter Inhalte schützt die Lizenzgeber und die Allgemeinheit davor, dass Dritte die Nutzung des Werkes nachträglich beschränken können. Dazu dient der ”Copyleft”-Effekt, der gewährleistet, dass ein Werk, welches dieser Lizenz unterstellt wurde, nur gemäß den Bestimmungen dieser Lizenz genutzt werden darf, und das Verbot, zusätzliche Verpflichtungen für den Nutzer aufzustellen.

1. Abschluss der Lizenz

(a) Dieser Lizenztext stellt ein Angebot auf Abschluss eines Lizenzvertrages unter den nachfolgenden Bedingungen dar. Das Angebot richtet sich an jedermann. Der Lizenzvertrag kommt durch die Ausübung der in Ziffer 2 genannten Rechte zustande, insbesondere durch die Vervielfältigung oder Verbreitung des Werkes. Der Erwerber dieser Rechte wird im Folgenden als Lizenznehmer bezeichnet. (b) Für eine bloße Benutzung des Werkes, etwa das private Anhören eines Tonträgers, Lesen eines Buchs oder Betrachten eines Photos, muss dieser Lizenzvertrag nicht abgeschlossen werden. Dies gilt auch für Befugnisse zur Nutzung des Werkes, die sich aus einer gesetzlichen Beschränkung des Urheberrechts ergeben, etwa für das Anfertigen einer Sicherungskopie oder für die Weitergabe eines rechtmäßig erworbenen Vervielfältigungsstückes.

58

2. Nutzungsrechte

(a) Der Lizenznehmer erwirbt mit Abschluss der Lizenz das zeitlich und räumlich unbeschränkte Recht, das Werk umfassend zu nutzen. Dies beinhaltet das Recht, das Werk in digitaler und analoger Form, online und offline, körperlich und unkörperlich zu verwenden. Die Nutzungserlaubnis erfolgt lizenzgebührenfrei. (b) Zur umfassenden Nutzung wird insbesondere das Recht eingeräumt, das Werk zu vervielfältigen, zu verbreiten und zu vermieten, zum Download bereitzuhalten oder in anderer Weise öffentlich zugänglich zu machen, vorzutragen, aufzuführen oder in anderer Form öffentlich wiederzugeben.

(c) Wer das Werk nutzt, darf von Dritten keine Lizenzgebühren für das Werk verlangen. Es ist dem Lizenznehmer jedoch gestattet, für andere Leistungen als das Einräumen eines Nutzungsrechts ein Entgelt zu verlangen. Dazu gehören auch Dienstleistungen im Zusammenhang mit dem Werk, die Erstellung von Datenträgern mit dem Werk sowie die Aufführung des Werkes.

(d) Die durch diese Lizenz erworbenen Nutzungsrechte dürfen nicht an Dritte weiterübertragen werden. Dritte können die Nutzungsrechte durch den Abschluss dieser Lizenz nur direkt von den Urhebern oder sonstigen Inhabern der ausschließlichen Nutzungsrechte erwerben. Dafür genügt es, dass Dritte das Werk mit dieser Lizenz von einer beliebigen Person erhalten und gemäß Ziffer 1 den Lizenzvertrag abschließen.

3. Keine Bearbeitungen

(a) Bearbeitungen des Werkes sind nicht gestattet. (b) Eine Bearbeitung in diesem Sinne liegt nicht vor, wenn das Werk

- mit einem anderen selbständigen Werk verbunden wird. Dies gilt auch dann, wenn die verbundenen Werke als ein Gesamtwerk genutzt werden;

- in eine Datenbank oder ein sonstiges Sammelwerk eingefügt wird. In diesen Fällen muss ein deutlicher Hinweis darauf erfolgen, welche Teile des Gesamtwerkes oder Sammelwerkes dieser Lizenz unterstehen.

4. Freigabe von verwandten Schutzrechten (”Copyleft”)

Wer bei der Nutzung des Werkes ein verwandtes Schutzrecht erwirbt, zum Beispiel ein Datenbankherstellerrecht oder ein Recht an einer Interpretation des Werkes, muss dieses Recht den Bestimmungen dieser Lizenz unterstellen, wenn er das Werk verbreitet, vermietet, zum Download bereithält oder in anderer Weise öffentlich zugänglich macht, vorträgt, aufführt oder in anderer Form öffentlich wiedergibt und das verwandte Schutzrecht für diese Nutzungen erforderlich ist.

59

5. Namensnennung

(a) Wird das Werk verbreitet, vermietet, zum Download bereitgehalten oder in anderer Weise öffentlich zugänglich gemacht, vorgetragen, aufgeführt oder in anderer Form öffentlich wiedergegeben, müssen Namensnennungen von Urhebern und Interpreten in der vorgefundenen Art und Weise übernommen werden. Die Namensnennung hat dann in einer angemessenen und für die jeweilige Nutzungsart üblichen Form zu erfolgen.

(b) Die vorstehenden Ausführungen zur Namensnennung gelten entsprechend für die Inhaber der ausschließlichen Nutzungsrechte, sofern diese im Zusammenhang mit dem Werk genannt werden.

6. Sonstige Verpflichtungen

(a) Bei einer Nutzung in körperlicher Form muss eine Kopie dieser Lizenz beigefügt oder eine Internetadresse angegeben werden, bei der der Lizenztext dauerhaft abrufbar ist. Bei unkörperlicher Wiedergabe des Werkes darf eine Wiedergabe der Lizenz unterbleiben, wenn dies untunlich ist. Dies kann der Fall sein bei Vorträgen und Aufführungen sowie Fernseh- und Rundfunksendungen.

(b) Hinweise auf die Geltung dieser Lizenz und Urheberrechtsvermerke dürfen nicht verändert oder gelöscht werden. Wo ein solcher Hinweis nach der konkreten Art der Nutzung unzumutbar ist, kann er unterbleiben, so etwa in Rundfunksendungen, die nur terrestrisch, via Kabel oder Satellit übertragen werden oder bei der Nutzung des Werkes in der Fernsehwerbung.

(c) Die Nutzung des Werkes darf nicht von der Erfüllung von Verpflichtungen abhängig gemacht werden, die nicht in dieser Lizenz genannt sind. (d) Wer im Zusammenhang mit der Nutzung des Werkes sonstige Schutzrechte erwirbt, insbesondere Patente, Marken, Geschmacksmuster und Gebrauchsmuster, darf mittels dieser Schutzrechte keine zusätzlichen Verpflichtungen für die Nutzung des Werkes aufstellen.

(e) Die Nutzung des Werkes darf nicht durch technische Schutzmaßnahmen, insbesondere Kopierschutzvorrichtungen und ähnliche Vorrichtungen, verhindert oder erschwert werden, es sei denn, die Nutzung des Werkes wird zugleich ohne solche Vorrichtungen ermöglicht.

7. History

(a) Die History soll Informationen über das Werk, zum Beispiel über seinen Titel, die Urheber und andere Rechtsinhaber und das Veröffentlichungsdatum enthalten.

60

(b) Ist dem Werk eine History beigefügt, so muss die History bei der Nutzung des Werkes mit den enthaltenen Informationen weitergegeben werden. Insoweit findet Ziffer 6 (a) entsprechende Anwendung.

(c) Sofern ein Rechtsinhaber wünscht, dass er vor der Nutzung des Werkes benachrichtigt wird, etwa um eine aktualisierte Version zur Verfügung zu stellen, kann er einen entsprechenden Hinweis in der History aufnehmen. Es wird empfohlen, diesem Wunsch nachzukommen. (d) Die History darf nicht geändert werden.

8. Beendigung der Rechte bei Zuwiderhandlung

(a) Jede Verletzung der Verpflichtungen aus dieser Lizenz beendet automatisch die Nutzungsrechte des Zuwiderhandelnden.

(b) Die Nutzungsrechte Dritter, die das Werk oder Rechte an dem Werk von dem Zu-widerhandelnden erworben haben, bestehen weiter.

9. Haftung und Gewährleistung

(a) Die Haftung der Lizenzgeber ist auf das arglistige Verschweigen von Rechtsmängeln beschränkt.

(b) Dieser Haftungshinweis bezieht sich ausschließlich auf die Einräumung von Rechten durch diese Lizenz. Die Haftung und Gewährleistung für andere Leistungen, etwa die Verbreitung von Werkstücken, richtet sich nach den gesetzlichen Bestimmungen oder individuellen Vereinbarungen.

10. Neue Versionen dieser Lizenz

Das Kompetenznetzwerk Universitätsverbund MultiMedia NRW kann diese Lizenz aktualisieren, soweit eine Veränderung der rechtlichen oder tatsächlichen Umstände dies erfordert. Der Lizenzgeber überlässt dem Kompetenznetzwerk Universitätsverbund MultiMedia NRW die Bestimmung des Inhalts künftiger Versionen dieser Lizenz. Die Bestimmung erfolgt durch öffentliche Bekanntgabe des Lizenztextes. Künftige Versionen müssen den Grundprinzipien dieser Lizenz entsprechen. Soweit ein Werk nicht ausdrücklich einer bestimmten Version dieser Lizenz unterstellt ist, gilt die jeweils aktuellste Version.

Anhang: Wie unterstelle ich ein Werk der Lizenz für die freie Nutzung

unveränderter Inhalte?

Um ein Werk nach den Bestimmungen dieser Lizenz zur freien Nutzung durch jedermann zur Verfügung zu stellen, muss dem Werk der folgende Hinweis in gut wahrnehmbarer

61

Weise beigefügt werden. Es wird darüber hinaus empfohlen, einen Urhebervermerk aufzunehmen, der das Jahr der ersten Veröffentlichung sowie den Inhaber der ausschließlichen Nutzungsrechte (Name oder allgemein verständliche Abkürzung) enthält. ”Copyright (C) 20[jj] [Name des Inhabers der ausschließlichen Nutzungsrechte].

Dieses Werk kann durch jedermann gemäß den Bestimmungen der Lizenz für die freie Nutzung unveränderter Inhalte genutzt werden.

Die Lizenzbedingungen können unter http://www.uvm.nrw.de/opencontent abgerufen oder bei der Geschäftsstelle des Kompetenznetzwerkes Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen, schriftlich angefordert werden.”

62

Literaturverzeichnis

[Apache Software Foundation 2003a] The Apache Software Foundation: The Apache Software License. 2003. - URL http://www.apache.org/LICENSE.txt -Zugriffsdatum: 19.04.2003. - Version 1.1

[Apache Software Foundation 2003b] The Apache Software Foundation: Foundation Project. 2003. - URL http://apache.org/foundation/ - Zugriffsdatum: 06.05.2003

[BerliOS-Projekt 2003a] Das BerliOS-Projekt: Das BerliOS-Projekt. 2003. - URL http://www.berlios.de/index.php.de - Zugriffsdatum: 12.09.2003 [BerliOS-Projekt 2003b] Das BerliOS-Projekt: Informationsplattform. 2003. - URL http://www.berlios.de/info_plat.php.de - Zugriffsdatum: 12.09.2003 [Bugzilla 2003] Bugzilla: Bugzilla Project Home Page. 2003. - URL http://www. bugzilla.org/ - Zugriffsdatum: 01.09.2003

[Bundesministerium für Inneres 2000] Bundesministerium für Inneres: KBSt-Brief Nr. 2/2000, Open Source Software in der Bundesverwaltung. Deutschland, 2000 [Bundesministerium für Wirtschaft und Arbeit 2001] Bundesministerium für Wirtschaft und Arbeit: Open-Source-Software, Ein Leitfaden für kleine und mittlere Unternehmen. Deutschland, März 2001

[Carlo u. a. 1997-2003] Carlo, Adam D. ; Hertzog, Raphaël ; Schwarz, Christian: Debian Developer’s Reference. Das Debian-Projekt, 1997-2003. - URL http://www. debian.org/doc/manuals/developers-reference/index.en.html - Zugriffsdatum: 07.09.2003. - Version 3.3.4 [Cederquist u. a. 1992, 1993] Cederquist, Per u. a.: Version Management with CVS, for CVS 1.11.6, 1992, 1993. - URL http://ftp.cvshome.org/ release/stable/cvs-1.11.6/cederqvist-1.11.6.pdf - Zugriffsdatum: 24.07.2003

[Debian Documentation Team 2003] Debian Documentation Team: A Brief History of Debian. Das Debian-Projekt, 2003. - URL http://www.debian.org/doc/ manuals/project-history/ - Zugriffsdatum: 07.09.2003. - Version 2.4 [Debian-Projekt 2003a] Das Debian-Projekt: CVS Repository. 2003. - URL http: //cvs.debian.org - Zugriffsdatum: 07.09.2003

[Debian-Projekt 2003b] Das Debian-Projekt: Debian Constitution. 2003. - URL http://www.debian.org/devel/constitution.en.html - Zugriffsdatum: 07.09.2003

63

[Debian-Projekt 2003c] rence.

developers-reference/ - Zugriffsdatum: 19.08.2003 [Debian-Projekt 2003d] Das Debian-Projekt: Debian Fehlerdatenbank. 2003.

- URL http://www.debian.org/Bugs/index.de.html - Zugriffsdatum: 07.09.2003

[Debian-Projekt 2003e] Das Debian-Projekt: Debian-Gesellschaftsvertrag. 2003. -URL http://www.debian.org/social_contract.de.html - Zugriffsdatum: 08.04.2003

[Debian-Projekt 2003f] Das Debian-Projekt: The Debian GNU/Linux FAQ. 2003. -URL http://www.debian.org/doc/FAQ - Zugriffsdatum: 07.09.2003 [Debian-Projekt 2003g] Das Debian-Projekt: Debian Mailing Lists. 2003. - URL http://lists.debian.org - Zugriffsdatum: 07.09.2003

[Debian-Projekt 2003h] Das Debian-Projekt: Debian-Releases. 2003. - URL http: //www.debian.org/releases - Zugriffsdatum: 07.09.2003

[Debian-Projekt 2003i] Das Debian-Projekt: Debian’s Organisationsstruktur. 2003.

- URL http://www.debian.org/intro/organization.de.html - Zugriffsdatum: 07.09.2003

[Debian-Projekt 2003j] Das Debian-Projekt: Dokumentation. 2003. - URL http: //www.debian.org/doc/index.de.html - Zugriffsdatum: 07.09.2003 [Debian-Projekt 2003k] Das Debian-Projekt: Entwickler-Ecke. 2003. - URL http: //www.debian.org/devel/index.de.html - Zugriffsdatum: 14.05.2003 [Debian-Projekt 2003l] Das Debian-Projekt: Projektmitglieder. 2003. - URL http: //www.debian.org/devel/people.de.html - Zugriffsdatum: 07.09.2003 [Debian-Projekt 2003m] Das Debian-Projekt: Sitemap der Debian-Webseiten. 2003.

- URL http://www.debian.org/sitemap.de.html - Zugriffsdatum: 07.09.2003

[Debian-Projekt 2003n] Das Debian-Projekt: Unterstützung. 2003. - URL http: //www.debian.org/support.de.html - Zugriffsdatum: 07.09.2003 [Erenkrantz 2003] Erenkrantz, Justin R.: Release Management Within Open Source Projects. In: Proceedings of the 3rd Open Source Software Development Workshop. Port-land, Oregon, USA, May 2003, S. 51-55. - URL http://opensource.ucc.ie/ icse2003/3rd-WS-on-OSS-Engineering.pdf - Zugriffsdatum: 22.07.2003

64

[FreeBSD German Documentation Project 2003] The FreeBSD German Documentation Project: FreeBSD Handbuch. 2003. - URL ftp://ftp.freebsd.org/pub/ FreeBSD/doc/de/books/handbook - Zugriffsdatum: 03.09.2003 [FreeBSD Project 2003a] The FreeBSD Project: Contributors to FreeBSD. 2003. - URL ftp://ftp.freebsd.org/pub/FreeBSD/doc/en/articles/ contributors - Zugriffsdatum: 03.09.2003. - Version 1.419 [FreeBSD Project 2003b] The FreeBSD Project: Core Bylaws. 2003. - URL http: //www.freebsd.org/internal/bylaws.html - Zugriffsdatum: 03.09.2003 [FreeBSD Project 2003c] The FreeBSD Project: Core’s Voting Procedures. 2003. - URL http://www.freebsd.org/internal/core-vote.html - Zugriffsdatum: 05.09.2003

[FreeBSD Project 2003d] The FreeBSD Project: CVS Repository. 2003. - URL http: //www.freebsd.org/cgi/cvsweb.cgi - Zugriffsdatum: 03.09.2003 [FreeBSD Project 2003e] The FreeBSD Project: Documentation. 2003. - URL http: //www.freebsd.org/docs.html - Zugriffsdatum: 05.09.2003 [FreeBSD Project 2003f] The FreeBSD Project: FreeBSD Developers’ Handbook. 2003. - URL ftp://ftp.freebsd.org/pub/FreeBSD/doc/en/books/ developers-handbook - Zugriffsdatum: 24.06.2003

[FreeBSD Project 2003g] The FreeBSD Project: FreeBSD Developers’ Handbook. 2003. - URL ftp://ftp.freebsd.org/pub/FreeBSD/doc/en/books/ arch-handbook - Zugriffsdatum: 05.09.2003

[FreeBSD Project 2003h] The FreeBSD Project: FreeBSD Documentation Project. 2003. - URL http://www.freebsd.org/docproj/index.html - Zugriffsdatum: 14.05.2003

[FreeBSD Project 2003i] The FreeBSD Project: FreeBSD Internal. 2003. - URL http://www.freebsd.org/internal - Zugriffsdatum: 05.09.2003 [FreeBSD Project 2003j] The FreeBSD Project: Homepage. 2003. - URL http: //www.de.freebsd.org/home - Zugriffsdatum: 05.09.2003 [FreeBSD Project 2003k] The FreeBSD Project: Release Engineering Information. 2003. - URL http://www.freebsd.org/releng/ - Zugriffsdatum: 22.07.2003

[FreeBSD Project 2003l] The FreeBSD Project: Release Information. 2003. - URL http://www.freebsd.org/releases/ - Zugriffsdatum: 04.09.2003 [FreeBSD Project 2003m] The FreeBSD Project: Support. 2003. - URL http: //www.freebsd.org/support.html - Zugriffsdatum: 05.09.2003

65

[freshmeat.net 2003] freshmeat.net: freshmeat.net: Statistics and Top 20. 2003. - URL http://freshmeat.net/stats/ - Zugriffsdatum: 22.07.2003 [GNU-Projekt 1985,1993] Das GNU-Projekt: Das GNU-Manifest. 1985,1993.

- URL http://www.gnu.org/gnu/manifesto.de.html - Zugriffsdatum: 07.09.2003

[GNU-Projekt 1999] Das GNU-Projekt: GNU Lesser General Public License. Februar 1999. - URL http://www.gnu.de/lgpl-ger.html - Zugriffsdatum: 02.05.2003. - Deutsche Übersetzung der Version 2.1 [GNU-Projekt 2001a] Das GNU-Projekt: Autoconf. April 2001. - URL http:// www.gnu.org/software/autoconf/ - Zugriffsdatum: 24.06.2003 [GNU-Projekt 2001b] Das GNU-Projekt: GNU General Public License. June 2001.

- URL http://www.gnu.de/gpl-ger.html - Zugriffsdatum: 08.04.2003. -Deutsche Übersetzung der Version 2

[GNU-Projekt 2003a] Das GNU-Projekt: Die Definition Freier Software. 2003. -URL http://www.gnu.org/philosophy/free-sw.de.html - Zugriffsdatum: 08.04.2003

[GNU-Projekt 2003b] Das GNU-Projekt: GCC Home Page. June 2003. - URL http: //www.gnu.org/software/gcc/gcc.html - Zugriffsdatum: 24.06.2003 [GNU-Projekt 2003c] Das GNU-Projekt: Homepage. 2003. - URL http://www. gnu.org/home.de.html - Zugriffsdatum: 07.09.2003

[Grassmuck 2002] Grassmuck, Volker: Freie Software zwischen Privat- und Gemeineigentum. Bonn, Deutschland : Bundeszentrale für politische Bildung, 2002. -URL http://freie-software.bpb.de/Grassmuck.pdf - Zugriffsdatum: 02.05.2003

[Grosse u. a. 2001] Grosse, Matthias ; Hainzer, Manuela ; Kornfeld, Alexander ; Lippert, Stefan ; Wagner, Beate: Studentenprojekt: New Economy@Wien / Institut für Stadt-und Regionalforschung, Technische Universität Wien. Wien, Österreich : Univ.-Prof.Dr. Jens Dangschat, May 2001. - URL http://www.newecon.at - Zugriffsdatum: 06.05.2003

[Horde Project 2003a] The Horde Project: About Horde. 2003. - URL http://www. horde.org/about.php - Zugriffsdatum: 31.08.2003

[Horde Project 2003b] The Horde Project: Core Team. 2003. - URL http://www. horde.org/horde/team/ - Zugriffsdatum: 31.08.2003

[Horde Project 2003c] The Horde Project: CVS Directory of /horde. 2003. - URL http://cvs.horde.org/cvs.php/horde - Zugriffsdatum: 31.08.2003

66

[Horde Project 2003d] The Horde Project: Frequently Asked Questions. 2003. - URL http://dev.horde.org - Zugriffsdatum: 05.09.2003 [Horde Project 2003e] The Horde Project: FTP Site. 2003. - URL ftp://ftp. horde.org/pub/horde/ - Zugriffsdatum: 31.08.2003

[Horde Project 2003f] The Horde Project: Homepage. 2003. - URL http://www. horde.org - Zugriffsdatum: 31.08.2003

[Horde Project 2003g] The Horde Project: Horde Bugs Page. 2003. - URL http: //bugs.horde.org - Zugriffsdatum: 01.09.2003

[Horde Project 2003h] The Horde Project: Horde Development Resources. 2003. -URL http://dev.horde.org - Zugriffsdatum: 01.09.2003 [Horde Project 2003i] The Horde Project: Horde Library. 2003. - URL http:// www.horde.org/papers/ - Zugriffsdatum: 05.09.2003

[Horde Project 2003j] The Horde Project: Horde Mailing Lists. 2003. - URL http: //www.horde.org/mail/ - Zugriffsdatum: 31.08.2003

[IDA 2001] IDA: Study into the use of Open Source Software in the Public Sector / Interchange of Data between Administrations. European Commision, DG Enterprise, June 2001. - URL http://europa.eu.int/ISPO/ida/export/files/ staticdocs/egovo/333.html - Zugriffsdatum: 06.05.2003

[International Institute of Infonomics und Berlecon Research GmbH 2002] International Institute of Infonomics ; Berlecon Research GmbH: Free/Libre and Open Source Software: Survey and Study / University of Maastricht. The Netherlands, June 2002. -URL http://www.infonomics.nl/FLOSS/ - Zugriffsdatum: 12.05.2003 [Johnson 2001] Johnson, Kim: A Descriptive Process Model for Open-Source Software Development, Department of Computer Science, University of Calgary, Diplomarbeit, 2001. - URL http://www.cpsc.ucalgary.ca/˜johnsonk/thesis/ thesis.htm

[Jorgensen 2001] Jorgensen, Niels: Putting it All in the Trunk: Incremental Software Engineering in the FreeBSD Open Source Project. In: Information Systems Journal 11 (2001), Nr. 4, S. 321-336

[Kienzle 2001] Kienzle, Rene: Sourceforge Preliminary Project Analysis, 2001. - URL http://fs.phdstuff.com/sfreport/ - Zugriffsdatum: 14.05.2003 [Lakhani und von Hippel 2000] Lakhani, Karim ; Hippel, Eric von: How Open Source Software works: ’Free’ user-to-user assistance. MIT Sloan School of Management, 2000. - URL http://opensource.mit.edu/online_papers.php - Zugriffsdatum: 05.05.2003

67

[Lerner und Tirole 2002] Lerner, Josh ; Tirole, Jean: The Scope of Open Source Licensing / National Buerau of Economic Research. New York, NY, December 2002. - URL http://papers.nber.org/papers/W9363

[mozilla.org 2003] mozilla.org: Releases. 2003. - URL http://www.mozilla. org/releases/ - Zugriffsdatum: 22.07.2003

[Nakakoji u. a. 2002] Nakakoji, Kumiyo ; Yamamoto, Yasuhiro ; Nishinaka, Yoshiyuki ; Kishida, Kouichi ; Ye, Yunwen: Evolution Patterns of Open -Source Software Systems and Communities. In: Proceedings of the International Workshop on Principles of Software Evolution 2002 (IWPSE2002). Orlando, Florida, May 2002. - URL http:// www.cs.colorado.edu/˜yunwen/papers/IWPSE02.pdf - Zugriffsdatum: 05.05.2003 [Netscape 2000] Netscape: Open Source Whitepaper. 2000. - URL http: //wp.netscape.com/browsers/future/whitepaper.html - Zugriffsdatum: 06.05.2003

[Open Source Initiative 2003a] Open Source Initiative: The Artistic License. 2003. - URL http://www.opensource.org/licenses/artistic-license. php - Zugriffsdatum: 01.05.2003

[Open Source Initiative 2003b] Open Source Initiative: The BSD License. 2003. - URL http://opensource.org/licenses/bsd-license.php - Zugriffsdatum: 19.04.2003

[Open Source Initiative 2003c] Open Source Initiative: The Open Source Definition. 2003. - URL http://www.opensource.org/docs/definition.php - Zugriffsdatum: 07.04.2003 [Open Source Initiative 2003d] Open Source Initiative: OSI approved licenses. 2003. - URL http://www.opensource.org/licenses/ - Zugriffsdatum: 08.04.2003 [Open Source Initiative 2003e] Open Source Initiative: OSI History. 2003. -URL http://www.opensource.org/docs/history.php - Zugriffsdatum: 02.05.2003

[Perens 1999] Perens, Bruce: The Open Source Definition. In: DiBona, Chris (Verf.) ; Ockman, Sam (Verf.) ; Stone, Mark (Verf.): Open Sources: Voices from the Open Source Revolution. Cambridge, Massachusetts : O’Reilly and Associates, 1999. - URL http: //www.oreilly.com/catalog/opensources/book/perens.html

[Perens u. a. 1996-2002] Perens, Bruce u. a.: Debian GNU/Linux 3.0 installation; Für Intel x86. Das Debian-Projekt, 1996-2002. - URL http://www.debian.org/ releases/stable/i386/install.de.pdf - Zugriffsdatum: 07.09.2003.deutsche Übersetzung der Version 3.0.24

68

[perl.com 1997] perl.com: The Artistic Licence. August 1997. - URL http:// www.perl.com/pub/a/language/misc/Artistic.html - Zugriffsdatum: 01.05.2003

[PostgreSQL Global Development Group 2002] PostgreSQL Global Development Group: The PostgreSQL Licence. 2002. - URL http://www.postgresql.org/ licence.html - Zugriffsdatum: 19.04.2003

[Project AWStats 2003a] Project AWStats: AWStats logfile analyzer Documentation. 2003. - URL http://awstats.sourceforge.net/docs/index.html -Zugriffsdatum: 05.09.2003

[Project AWStats 2003b]

- awstats-public -Zugriffsdatum: 30.08.2003

[Project AWStats 2003c] Project AWStats: Frequently Asked Questions. 2003. -URL http://awstats.sourceforge.net/docs/awstats_faq.html -Zugriffsdatum: 05.09.2003

[Project AWStats 2003d] Project AWStats: Homepage. 2003. - URL http: //awstats.sourceforge.net - Zugriffsdatum: 30.08.2003 [Project AWStats 2003e] Project AWStats: SourceForge.net project page. 2003.

- URL http://sourceforge.net/projects/awstats/ - Zugriffsdatum: 30.08.2003

[Raymond 1998a] Raymond, Eric S.: The Cathedral and the Bazaar. In: First Monday 3 (1998), March, Nr. 3. - URL http://www.firstmonday.org/issues/ issue3_3/raymond/index.html - Zugriffsdatum: 16.05.2003 [Raymond 1998b] Raymond, Eric S.: Homesteading the Noosphere. In: First Monday 3 (1998), October, Nr. 10. - URL http://www.firstmonday.dk/issues/ issue3_10/raymond/index.html - Zugriffsdatum: 16.05.2003 [Raymond 2001] Raymond, Eric S.: How To Become A Hacker, 2001. - URL http://www.catb.org/˜esr/faqs/hacker-howto.html - Zugriffsdatum: 02.05.2003

[Rodin 1998-2001] Rodin, Josip: Anleitung für zukünftige Debian-Maintainer. Das Debian-Projekt, 1998-2001. - URL http://www.debian.org/doc/manuals/ maint-guide/maint-guide.de.pdf - Zugriffsdatum: 07.09.2003. - deutsche Übersetzung der Version 1.0.2

[Rosen 2002] Rosen, Lawrence: Why the Public Domain Isn’t a License. In: Linux Journal (2002), October, Nr. 102. - URL http://www.linuxjournal.com/ article.php?sid=6225 - Zugriffsdatum: 08.04.2003

69

[Salus 1994] Salus, Peter H.: A Quarter Century of Unix. Addison-Wesley Pub Co, June 1994

[Schmid u. a. 1997-2003] Schmid, Egon ; Bakken, Stig S. ; Aulbach, Alexander ; Winstead, Jim ; Wilson, Lars T. ; Lerdorf, Rasmus ; Zmievski, Andrei ; Ahto, Jouni: PHP Handbuch, June 1997-2003. - URL http://www.php.net/distributions/ manual/php_manual_de.pdf.bz2 - Zugriffsdatum: 17.07.2003 [Sieckmann 2001] Sieckmann, Jens: Bravehack. 2001. - URL http://www. bravehack.de - Zugriffsdatum: 07.04.2003. - Version 1.0 [Smørgrav und Pandya 2003] Smørgrav, Dag-Erling ; Pandya, Hiten: Problem Re-port Handling Guidelines. The FreeBSD Project, 2003. - URL ftp://ftp. freebsd.org/pub/FreeBSD/doc/en/articles/pr-guidelines - Zugriffsdatum: 05.09.2003. - Version 1.13

[SourceForge.net 2003a] SourceForge.net: An Overview of the SourceForge.net User Community. 2003. - URL http://sourceforge.net/docman/display_ doc.php?docid=9331&group_id=1 - Zugriffsdatum: 19.08.2003 [SourceForge.net 2003b] SourceForge.net: Project: Alexandria-Devel. 2003. - URL http://sourceforge.net/projects/alexandria-dev - Zugriffsdatum: 02.07.2003

[SourceForge.net 2003c] SourceForge.net: Project Documentation. 2003. - URL http://sourceforge.net/docman/ - Zugriffsdatum: 30.08.2003 [SourceForge.net 2003d] SourceForge.net: SourceForge.net: Software Map. 2003. -URL http://sourceforge.net/softwaremap/trove_list.php - Zugriffsdatum: 21.07.2003

[SourceForge.net 2003e] SourceForge.net: SourceForge.net: Top Project Listings. 2003. - URL http://sourceforge.net/top/ - Zugriffsdatum: 02.07.2003 [SourceForge.net 2003f] SourceForge.net: SourceForge.net: Welcome. 2003. - URL http://www.gnu.org/gnu/manifesto.html - Zugriffsdatum: 02.07.2003 [Stokley 2003] Stokley, Murray: FreeBSD Release Engineering. The FreeBSD Project, 2003. - URL ftp://ftp.freebsd.org/pub/FreeBSD/doc/en/ articles/releng - Zugriffsdatum: 03.09.2003. - Version 1.48 [Sun Microsystems: SunSource.net 2003] Sun Microsystems: SunSource.net: Why is Sun Doing Open Source. 2003. - URL http://www.sunsource.net/why. html - Zugriffsdatum: 06.05.2003

[Working Group on Libre Software 2000] Working Group on Libre Software: Free Software/Open Source: Information Society Opportunities for Europe? / Information Society

70

Directorate  General of the European Commission. URL http://eu.conecta.it,  

April   2000

71