Der folgende Abschnitt soll zeigen, wie die Softwareentwicklung in einer offenen, locker organisierten Gemeinschaft (ansatzweise in Abschnitt 1.4 erläutert) funktioniert und warum die produzierte Software nicht in einem heillosen Chaos in verschiedene, inkompatible Bruchstücke zerfällt. Soziale, organisatorische und technische Aspekte des Entwicklungsprozesses werden ebenso betrachtet wie das Software-Projekt, in dem dieser seine Entfaltung findet.
Linus Torvalds machte diese Art der Softwareentwicklung im Basar-Stil populär [36]. Basar deshalb, weil sich häufig ein freies Software-Projekt anderer Softwarekomponenten bedient und weil die Entwickler und Anwender wie Händler auf einem Basar nehmen und geben. Aber vor allen Dingen kommunizieren sie intensiv wie in einer langjährigen Gemeinschaft; ein riesiger Gedankenaustausch. Zwar hatten Jahre vor ihm bereits andere ansatzweise mit dieser Methode gearbeitet, aber es war Torvalds, der sie effektiv und praktisch umzusetzen wußte, allerdings ohne sich dessen - zumindest zu Anfang - bewußt zu sein. Eric Raymond war schließlich derjenige, der mit seinem analytischen Gespür als ,,Hacker-Anthropologe`` die freie Softwareentwicklung genau anhand von Fallbeispielen untersuchte. In den drei bekannten Essays The Cathedral and the Bazaar, Homesteading the Noosphere [37] und The Magic Cauldron [38] hielt er seine Gedanken und Entdeckungen schriftlich fest. Sie besprechen jeweils die technischen, sozial-gesellschaftlichen und wirtschaftlichen Aspekte von Open Source.
Freie Software vor Linux wurde meist in kleinen, geschlossenen und eng zusammenarbeitenden Gruppen geschrieben. Es bestand also in der Arbeitsweise selbst gar kein so großer Unterschied zu der Art wie proprietäre Software in Unternehmen entwickelt wurde. Beiträge von unbekannten Außenstehenden wurden selten in die Hauptversion integriert. Aufgrund fehlender Kommunikationskanäle - schließlich war das Internet damals noch schwach entwickelt - waren diese auch äußerst selten. Viele Projekte der FSF, z.B. Emacs und der GNU C Compiler entstanden auf diese Weise.
Heute aber ist das Internet ein globales Netzwerk und fast alle großen, freien Software-Projekte werden nach Linux-Manier oder ähnlich organisiert. GNOME, KDE, Perl und Samba leben von weltweiter, reger Beteiligung. An Größe und Komplexität reichen sie mittlerweile an ihre proprietären Gegenstücke heran.
Am Anfang einer freien Software steht die Idee eines einzelnen Entwicklers. Sie erwächst oft aus einem Problem, das während der täglichen Arbeit mit dem Computer auftritt. Eine Umständlichkeit, eine Inkompatibilität, ein Mangel oder sich ständig wiederholende, monotone Verwaltungsarbeiten sind Grund für den Hacker, ein Programm zu schreiben, das diese Unwägbarkeiten automatisch ausräumt oder übernimmt. Not macht erfinderisch.
,,Every good work of software starts by scratching a developer's personal itch.`` - Eric Raymond
Die zweite Möglichkeit für die Idee einer neuen freien Software bieten ihre proprietären Gegenstücke. Oft entdeckt ein Programmierer eine Software auf einem Windows- oder Mac-System, die er gerne auch auf dem von ihm favorisierten Betriebssystem nutzen möchte. Dort baut er sie in seiner Freizeit einfach nach.
Beginnt der Entwickler mit einem völlig neuen Programm, so wird ein erstes Design erdacht, welches die folgende Arbeit massiv beinflussen wird, denn Design hat eine sehr hohe Priorität und muß deshalb genau überdacht werden. Dennoch wird das Design des öfteren teilweise oder komplett überarbeitet bzw. Komponenten ausgetauscht, weil sie sich als nicht brauchbar erwiesen haben. Der Programmierer kann aber auch als Basis eine fremde freie Software nehmen, die in etwa oder zum Teil sein Problem löst. Er entscheidet, was er davon benutzt, was herausgenommen und was erweitert oder verändert werden soll. Aber auch hier steht das Design an oberer oder oberster Stelle.
,,It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode.`` - Eric Raymond
Eine solche erste Vorabversion ist immer noch die Entwicklung eines einzelnen oder einer kleinen Gruppe und hat somit noch nicht das Stadium der verteilten, gemeinschaftlichen Arbeit erreicht. Sie ist häufig instabil, unvollständig und schlecht dokumentiert, läßt aber schon eine klare Struktur erkennen, die durch das Design geformt wurde. Die Reife und Komplexität einer ersten Version beeinflußt den Erfolg der Folgeversionen. Ist sie zu mager, könnten sich hinzugewonnene Programmierer, wenn überhaupt, mehr auf das Fehlerbeheben statt auf Erweiterungen konzentrieren. Andererseits kann eine zu komplexe erste Version weniger versierte Entwickler abschrecken.
Hat der Schöpfer sich für einen Mittelweg entschieden, so kann er sein Werk in einer Newsgroup ankündigen und es im Internet zum Herunterladen bereitstellen, so daß jeder ambitionierte Hacker es studieren kann.
Um die hohe Hürde von der ersten Version zu einem organisierten Projekt zu nehmen, muß die Software einige Bedingungen erfüllen. Sie muß über einen so allgemeinen Funktionsumfang verfügen, daß sie möglichst viele Entwickler und Anwender anspricht. Löst sie ein Problem, das viele Benutzer haben, so ist es wahrscheinlich, daß sich viele Programmierer an der Weiterentwicklung beteiligen werden. Das Projekt muß ein gewisses Attraktivitäts-, Identifikations- und Entwicklungspotential besitzen. Verstärkt wird diese Eigenschaft noch, wenn es lückenfüllende Funktionen bietet (z.B. Perl) oder das Zeug zu einer ,,Killerapplikation`` in seinem Einsatzgebiet hat (z.B. sendmail, DNS/BIND).
Auch die Struktur eines Projekts trägt zu ihrem Erfolg bei. Stark modularisierte Werke, die in weitere unabhängige Unterprojekte aufgeteilt werden können, haben grundsätzlich bessere Voraussetzungen. Bei KDE oder GNOME können Programmierer, ohne auf die Kernentwicklung und komplizierte Vorgaben zu achten, relativ schnell Anwendungen, Hilfs- oder Systemprogramme erstellen [39]. Erfolgserlebnisse stellen sich hier wesentlich schneller ein als bei einem monolithischen Projekt wie Mozilla, bei dem der Entwickler viele Spezifikationen und Schnittstellen einzuhalten hat und auf eine enge Kommunikation mit dem Kern-Team angewiesen ist. Ein sichtbares Ergebnis bleibt dann bei dieser Arbeit aber meistens dennoch aus.
Die folgenden Unterabschnitte beschreiben die menschlichen und technischen Ressourcen, die für ein erfolgreiches, freies Software-Projekt benötigt werden. Sie werden umso wichtiger, je größer es wird. In der Regel spricht man erst von einem Projekt, wenn es einige zehntausend Codezeilen hat und zumindest zehn Programmierer daran beteiligt sind. Zur Orientierung: KDE besteht aus ca. zwei Millionen Zeilen, die von weltweit über 200 Entwicklern programmiert werden. An Linux beteiligen sich noch mehr Hacker mit insgesamt fast drei Millionen Zeilen.
Ein freies Software-Projekt wird von seinen Mitgliedern getragen. Die Quelle ihrer kreativen Energie ist nicht Geld, sondern eine Vielzahl von sozialen und persönlichen Vorteilen, die durch die Zusammenarbeit in einer Gemeinschaft von Gleichgesinnten entstehen. Neben dem Spaß am Programmieren ist der Erfolg, die intellektuelle Herausforderung und technische Neugier Antriebskraft (nicht nur) für effektive Softwareentwicklung. Anerkennung und Prestige sind soziale Statussymbole, die eine emotionale Verbundenheit vom Programmierer zum Projekt herstellen. Sie fehlen weitgehend in der traditionellen Softwareherstellung. Für Hacker stellt es eine Genugtuung dar, wenn Anwender Software benutzen, die sie entwickelt oder an der sie mitgearbeitet haben.
,,There's one lesson that's really obvious: You cannot motivate the best people with money. Money is just the way to keep score. The best people in any field are motivated by passion. This becomes more true the higher the skill level gets.`` - Eric Raymond
Der Zwang, etwas tun zu müssen, der klassische, demotivierende Faktor bei der bezahlten Arbeit in einem Unternehmen entfällt, da die meisten Mitglieder freiwillig in ihrer Freizeit Arbeit für das Open-Source-Projekt erledigen, was aber auf keinen Fall bedeutet, daß sie ihr Hobby nicht ernst nehmen. Im Gegenteil, an Eifer und Enthusiasmus sind sie kaum zu überbieten.
Das wichtigste Mitglied eines freien Software-Projekts ist der Gründer bzw. Inhaber. Er sollte nicht nur ein gute Programmierer, sondern auch ein guter Designer (im softwaretechnischen Sinn) und Organisator sein. Ist er das nicht, so muß er zumindest gute Programmierung und gutes Design erkennen können. Besonders wichtig ist aber seine Fähigkeit zur Kommunikation, die Grundlage für eine dezentrale, verteile Entwicklung, denn bei ihm laufen die Fäden zusammen, die zu einem Tau verstrickt werden müssen. Oft ist der ,,Code Captain`` eine charismatische oder visionäre Persönlichkeit, die von anderen beteiligten Projektmitgliedern in vollem Maße akzeptiert und respektiert wird.
Den Leiter umgibt meist ein Kreis von Kernentwicklern, die Schreibzugriff auf den Quellcode haben und somit eigenmächtig Änderungen tätigen können, falls sie sich vorher durch entsprechend wertvolle Beiträge hervorgehoben haben. Um sie zieht sich ein weiterer Kreis von sporadisch beitragenden Programmierern und Anwendern. Sie arbeiten häufig an der Fehlerbeseitigung und an Tests sowie an kleineren Modifikationen und Erweiterungen. Nichtsdestotrotz werden sie gebührend behandelt und gewürdigt, was wiederum ihre Motivation fördert.
Ab einer gewissen Projektgröße sind oft auch Manager, PR-Leute und sogenannte Evangelisten involviert, die das Vorhaben strategisch planen und fördern. Sie propagieren mit rhetorischem und diplomatischem Geschick seine Vorzüge und die der freien Softwareentwicklung.
Daß Linux und andere Open-Source-Software mit dem Internet gewachsen sind, ist kein Zufall, denn das Netz ist ihre Entwick(lungs/ler)- und Kommunikationsumgebung, die Quelle neuer Ideen, der Rekrutierungsort neuer Mitglieder. Ohne schnellen und globalen Informationsaustausch ist jedes große, freie Software-Projekt zum Untergang verdammt.
,,The real lesson to be learned from open source communities are the techniques of networked collaboration that they've pioneered.`` - Tim O'Reilly
Ein tieferer Blick auf die Internet-Infrastruktur enthüllt verschiedene Wege der Kommunikation und Präsentation [40]:
Oft wird auch eine Fehler-Datenbank gepflegt, die für Mitglieder über ein Web-Interface angesprochen werden kann. Bug-Tracking und -Fixing wird so deutlich vereinfacht.
Die Organisation von hunderten oder mehr auf der ganzen Welt verteilten Entwicklern wäre aus der Sicht einer Führungsperson eines Unternehmens eine äußerst schwierige Aufgabe, denn die dort üblicherweise streng hierarchische Struktur, die durch top-down-Entscheidungen geprägt ist, skaliert mit der Anzahl der involvierten Personen nur schlecht. So ist es nicht verwunderlich, daß sich die Hacker-Gemeinde anderen, lockeren Organisationsformen bedient, die sich im Laufe der Zeit mehr oder weniger selbst entwickelten. Autarke Gruppen, ,,wohlwollende Diktatoren`` (benevolent dictator) oder Komitees sind Ausprägungen dieser Formen.
Linus Torvalds stellt ein Exemplar des wohlwollenden Diktators dar, der als Hauptkoordinator mehrere Gruppen von vertrauten Kernentwicklern, die für bestimmte Arbeitsgebiete (Netzwerk, Gerätetreiber usw.) zuständig sind, organisiert. Er überwacht und entscheidet, welche Fehler für das nächste Release behoben und welche Änderungen durchgeführt werden. Er erhält Patches und integriert sie in eine neue Version, die er veröffentlicht [41]. Die Sichtung aller Beiträge gehört zusammen mit ihrer Integration zu den zeitaufwendigsten Arbeiten der freien Softwareentwicklung und ist einer ihrer Nachteile.
Trotz solch vielfältiger und schwerer Aufgaben lastet auf dem Projektleiter kein großer Druck. Er erhält in der Regel von allen Seiten Unterstützung und genießt zudem großes Ansehen, wenn die Gemeinde seine Entscheidungen einhellig nachvollziehen kann. Wenn diese aber fehlendes Talent und mangelnde Objektivität des Oberhaupts erkennt, dann wird sie einen kompetenteren Nachfolger fordern.
Ein etwas anderes Modell verfolgt die Apache Software Foundation, an deren oberster Stelle ein Komitee von Entwicklern und Managern steht, die durch Abstimmungen den weiteren Werdegang der Software bestimmen. Sehr viele der getroffenen Entscheidungen betreffen die technische Seite des Projekts in kurz- oder mittelfristiger Hinsicht. Marktpolitische Beschlüsse wie in der Industrie sind eher selten. Trotzdem ist eine starke Verbindung zum Kunden/Anwender vorhanden, vornehmlich dadurch bedingt, daß dieser sich häufig aktiv am Projekt beteiligt.
Entfernt man sich weiter vom Zentrum der Entwicklung, so findet man oftmals selbstorganisierende Gruppen aus den verschiedensten Bereichen, die nicht nur einfaches Bug-Fixing betreiben, sondern auch eigene, hochkomplexe Softwarekomponenten erstellen und diese zum Projekt beitragen, also gewissermaßen bottom-up agieren.
,,Authority follows resonsibility. If you're willing to take responsibility, you have the authority to make decisions.`` - Eric Raymond
Einfluß auf Entscheidungen kann derjenige nehmen, der wertvolle Beiträge leistet, die die Entwicklung voranbringen. Durch ungeschriebene Verhaltensregeln, die jeder Hacker im Laufe der Zeit in der Gemeinschaft lernt und achtet, kommt es selten zu Konflikten.
Der Organisation der menschlichen Ressourcen steht technische Entwicklung und deren Koordination gegenüber. Tausende Dateien müssen geprüft und in die vorhandene Code-Basis integriert werden. Es kann sich dabei um eine einzelne Basis handeln, deren Äste verschiedene Architekturen repräsentieren (Linux) oder um mehrere Code-Basen (BSD-Varianten), für die dann zwar die Programmierung leichter fällt, aber das Management erschweren. Hin und wieder passiert es, daß eine Code-Basis aufgespalten wird (forking) und sich ihre Teilbäume unabhängig voneinander - meist in verschiedende Richtungen, auf bestimmte Einsatzgebiete spezialisiert - weiterentwickeln. Im allgemeinen wird dieser Akt in der Open-Source-Gemeinde nicht gerne gesehen und muß wohl begründet sein.
Häufig werden zwei Linien der Code-Basis gepflegt. Eine stabile, produktionsreife Version und eine Entwicklerlinie, die neueste Features beinhaltet und somit relativ instabil ausfällt. Linux und die freien BSD-Varianten arbeiten mit diesem Verfahren. Zusätzlich können Termine für den Code- und den Feature-Freeze vereinbart werden. Mit dem Code-Freeze geht die Software en in die ,,Fertigung``. Für die aktuelle Version werden bis zur Veröffentlichung keine Änderungen mehr vorgenommen. Beim Feature-Freeze werden keine neuen Beiträge mehr integriert; lediglich Fehlerbehebung und Integration finden noch statt.
Die weitaus wichtigste technische Eigenschaft eines freien Software-Projekts ist ihre Modularität. Sie ist die Voraussetzung für eine verteilte und unabhängige Entwicklung. Je modularer eine Software aufgebaut ist, umso besser können Aufgaben an Gruppen verteilt werden, und umso einfacher wird die Organisation und Koordination. Im Falle einer einzelnen Anwendung kann Modularität durch ein Plug-In-Konzept sichergestellt werden, wie es das Bildverarbeitungsprogramm GIMP eindrucksvoll zeigt. Grafische Funktionen oder Konvertierungen können leicht über ein Plug-In in die Applikation integriert werden. Modulares Design steht über der Benutzerfreundlichkeit und über Performanz. Sie läßt sich aber nur dann realisieren, wenn offene Standards und dokumentierte Schnittstellen zur Verfügung stehen.
Die hochgepriesene Stabilität freier Software resultiert aus der ungeheuren Masse der Anwender und Entwickler in Bezug auf Tests und Fehlerbehebung. Da der Quellcode verfügbar ist, kann jeder gefundene Fehler selbständig beheben. Oft werden Fehler von Benutzern gefunden und gemeldet, die aber dann von anderen Anwendern oder Entwicklern verstanden und womöglich wiederum von anderen behoben werden. Dieses Vorgehen ist parallelisierbar und läßt sich so ideal auf eine große, verteile Gemeinde anwenden. Ein ganz entscheidender Vorteil gegenüber der traditionellen Softwareentwicklung.
,,One of the core practices used in open-source software is peer review: because everyone can see the code, everyone can see your work. One obvious benefit of peer review is that mistakes get caught sooner. I call this Linus's Law, after Linus Torvalds: 'With enough eyeballs, all bugs are shallow.'`` - Eric Raymond
Stetige Verbesserungen, Ergänzungen und Fehlerbereinigungen verlangen nach ebenso stetigen Veröffentlichungen. Ein Motto von Open Source ist deshalb ,,release early, release often``. Die schnelle Behebung schwerwiegender Fehler mündet daher sofort in einer neuen Version. Für den Teardrop-Bug oder den ,,Ping of Death`` vor wenigen Jahren standen 24 Stunden nach ihrer Entdeckung Patches für Linux bereit. Bleibende kurze Veröffentlichungsintervalle deuten auf das große Entwicklungspotential einer freien Software hin.
Auch wenn an der Spitze jedes freien Software-Projekts ein oder mehrere Führungspersonen stehen, so heißt das nicht, daß allein von ihnen sein Werdegang bestimmt wird. Vielmehr gleicht der Entwicklungsprozeß einer freien Software der natürlichen Evolution, die sich an die vorhandene Umgebung anpaßt. Ihr Weg ist nicht vorherbestimmt, weil sie weder von einem zentralen Organ entwickelt noch kontrolliert wird. Die Art der Entfaltung manch freier Software gefällt dem einen mehr, dem anderen weniger. Aber derjenige, dem sie weniger gefällt, hat zumindest die Chance, sie nach eigenen Bedürfnissen anzupassen.
Ausgeklügelte Methoden, Studien und Konzepte sind in der freien Softwareentwicklung kaum zu entdecken. Viele Phasen der traditionellen Herstellung, wie sie in Abschnitt 5.1 beschrieben wurden, werden einfach übersprungen. Statt exakter Planung bedient man sich des Just-in-Time-Verfahrens. Es wird das entwickelt, was gerade benötigt wird. Hat man im Augenblick Bedarf nach der Analyse von Textdateien, so wird eben ein Parser geschrieben, der sich einfach in das vorhandene, modulare Design einfügen läßt. Das Grunddesign ist eines der wenigen Dinge, die sehr wohl nach einer genauen Planung verlangen.
,,While coding remains an essentially solitary activity, the really great hacks come from harnessing attention and brainpower of entire communities.`` - Eric Raymond
Ganz unabhängig von Finanzen ist ein Open-Source-Projekt trotz ihrer meist unentgeltlich arbeitenden Mitgliedern nicht. Bisher behalf man sich mit Spenden und Geldern von interessierten Sponsoren. Auch die Unterstützung von Regierung und Forschung, sowie der Verkauf von Software, Dokumentation und Souvenirs brachte ein wenig Geld. In letzter Zeit bezahlen mehr und mehr Firmen ihre Angstellten, um freie Software zu entwickeln.
Die letzten Abschnitte haben gezeigt, daß die Open-Source-Softwareentwicklung enorme Vorteile aber auch Schwierigkeiten mit sich bringt, die aus einer riesigen Entwickler- und Benutzergemeinde herrühren. Wenn das Projekt ein großes Potential und einen hohen Gebrauchswert besitzt, dann wird es gelingen, menschliche und technische Ressourcen mit Hilfe des weltumspannenden Internet in einem Maße zu erschließen und zu kollektivieren, wie es nur der freien Software vorbehalten ist. Raymond spricht hier von der ,,Noosphäre``, die Sphäre menschlichen Gedankenguts und Ideen, die eingefangen werden muß. Je mehr Wissen und Ideen beigetragen werden, je mehr Augen auf den Quellcode eines Programms schauen und je mehr Anwender es benutzen, desto größer ist die Wahrscheinlichkeit, daß die Software anwendernah gedeiht, innovativer und stabiler wird. Das Internet ist dazu die ideale Plattform; mit ihr wächst auch die Menge freier Software. Eine Evolution im Kollektiv.