Wissenschaftliche Debatte und Argumentation zum Thema ``Open-Source-Software-Entwicklung''

Balázs Bárány, 9606800 (301 295)

Ulrike Felt, Martina Erlemann: Hat Wissenschaft ein Monopol auf Wissen? Wissensformen, Machtstrukturen und Geschlechterverhältnisse. WS 2001/2002


Abstract: Die Software-Entwicklung nach dem ``Open-Source''-Modell ist eine der wichtigsten Entwicklungen der Informatik in den 90er Jahren. Das Modell ist zwar älter, doch eine bewußte Beschäftigung mit seinen Vor- und Nachteilen wurde erst um 1997 mit dem einflußreichen Paper ``The Cathedral and the Bazaar'' (CatB) von Eric S. Raymond begonnen.

Die Theorien aus CatB berühren sowohl die etablierte Theorie der Software-Entwicklung (z.B.: ab einer bestimmten Grenze können auch mehr Leute ein Projekt nicht schneller entwickeln) als auch fremde Gebiete wie die Wirtschaft (z.B.: ``gift economy'': Leute produzieren wirtschaftlich verwertbare Produkte ohne finanzielle Gegenleistung). Im Verlauf der Debatte kam bald der Standpunkt auf, die Open-Source-Software-Entwicklung mit der wissenschaftlichen Gemeinschaft zu vergleichen.

Raymond, wie die meisten anderen Teilnehmer der Debatte, kommt direkt aus der Software-Entwicklung. Ein großer Teil der Argumentation -- auch wenn soziale oder wirtschaftliche Themen angesprochen werden -- ist erkennbar durch diese technisch-naturwissenschaftliche Sichtweise eingefärbt.

Das eröffnet einigen Raum für Kritik, da hier ``berufsfremde'' Personen -- viele sogar ohne akademischen Grad, Position und Veröffentlichungsgeschichte -- sich berufen fühlen, wissenschaftliche Aussagen über Dinge zu treffen, für die sie nach herkömmlichen wissenschaftlichen Kriterien nicht ``zuständig'' sind.

Ein anderer kritisierter Aspekt ist die vereinfachende, naive und manchmal fast fundamentalistisch schwarz-weiße Sichtweise der BefürworterInnen der Open-Source-Software-Entwicklung.

Meine Arbeit wird die wesentlichen Argumentationslinien der viel rezipierten Teilnehmer der Debatte sowie die von ihnen und über sie geäußerte Kritik vorstellen.

Es erscheint mir aus zwei Gründen interessant, dieses Thema zu bearbeiten: erstens, weil hier die Entwicklung der Argumentation auf einem neu erschlossenen Gebiet zu beobachten ist und zweitens wegen der Verbindung der Open-Source-Entwicklung mit den Methoden der Wissenschaft.

$Id: seminararbeit.lyx,v 1.8 2002/05/23 20:58:05 bb Exp bb $





Table of Contents

1  Einleitung

Am Anfang ihres kommerziellen Einsatzes wurden Computerprogramme ausschließlich zusammen mit den Computern vertrieben. Immer wurde auch der Quellcode mitgeliefert. (Der Quellcode ist in einer für Menschen verständlichen Sprache geschrieben, und wird mit einem Compiler (Übersetzerprogramm) in die ``Sprache'' der Maschine übersetzt.) Dies wurde mit dem Entstehen einer unabhängigen Software-Industrie in den Hintergrund gedrängt, die nicht daran interessiert war, daß die BenutzerInnen das Programm selbst ändern und weiterentwickeln können.

In bestimmten Kreisen, etwa um Universitäten herum, und im Unix-Bereich (Unix ist ein Betriebssystem, das am Anfang der 70er Jahre geschrieben wurde, und heute die Grundlage für viele andere Betriebssysteme, etwa Linux und MacOS X ist), war jedoch der Austausch von Quellcode weiter üblich, da dieser sich auf verschiedenen Maschinen übersetzen läßt, während der ``Binärcode'' (der übersetzte Maschinencode) nur auf einem Computertyp läuft.

Die ``Free Software Foundation'' (FSF) entstand 1984, um die Entwicklung von ``Freier'', also frei zugänglicher, kopierbarer und selbst änderbarer Software voranzutreiben.

In der Umgebung solcher an quelloffene Software gewöhnten Gruppen wurden wesentliche Bestandteile des Internet wie e-mail und das World Wide Web entwickelt. Auch heute sind Programme mit offenem Quellcode in diesen Bereichen dominant (im WWW führt das Programm ``Apache'', für e-mail-Server wird meistens ``sendmail'' verwendet).

Diese Koexistenz der frei kopierbaren, quelloffenen auf der einen und der ``proprietären'' Software auf der anderen Seite galt lange Zeit als selbstverständlich und wurde nicht weiter hinterfragt. Mitte/Ende der 90er Jahre gab es erste Versuche, das Phänomen zu erklären und ihm einen Namen zu geben. Als Name wurde ``Open Source'' auserkoren, da es mit dem früheren Begriff ``Freie Software'' in den USA ein großes Verständnisproblem gab: ``free'' bedeutet sowohl ``frei'' als auch ``gratis'', was etwa in der Wirtschaft Vorbehalte gegenüber ``free software'' erzeugte. Die Bezeichnung ``free software'' existiert nach wie vor und wird etwa von der FSF weiter so genannt; die öffentliche und wissenschaftliche Diskussion verwendet jedoch meist ``open source''. Ich schreibe in dieser Arbeit ``open source'', weil das auch meine Quellen tun, und nicht als Parteinahme für eine Seite dieser intensiv geführten Namens-Debatte.

Um 1997 begann die Beschäftigung mit Open Source als eigener Software-Entwicklungs-Methode sowie aus wirtschaftlicher und sozialer Sicht. Dieses Gebiet wurde vorher von der Wissenschaft gar nicht separat bearbeitet.

Meine Arbeit wird zwei frühe Teilnehmer der Debatte und ihre Werke, die großen Einfluß auf die Diskussion hatten, vorstellen. Die Auswahl ist bewußt auf die Dokumente, die den Stil der Anfänge der Debatte bestimmten, begrenzt worden.

2  Die Arbeiten von Eric S. Raymond

Eric S. Raymond ist eine der wichtigsten Figuren der Open-Source-Bewegung. Er beschäftigt sich seit den 80er Jahren neben seiner technischen Tätigkeit mit der Dokumentation der sozialen und psychologischen Eigenschaften der ``Geek''-s ( Computerfreak) oder ``Hacker'' (jemand, der/die sich überdurschnittlich viel mit technologischen oder wissenschaftlichen Dingen beschäftigt1).

Raymond hat keine akademische Ausbildung2, bis auf einige Mathematik- und Philosophie-Kurse, die er an einer Universität besucht hat; jedoch keinen Abschluß. Dennoch war er Gast-Lektor an Universitäten, und seine Papers wurden als wissenschaftliche Dokumente publiziert und diskutiert.

Er hat in Software-Engineering und Informatik keine formelle Ausbildung, gilt aber als sehr guter Programmierer. Zum Beispiel hat er zu Linux (dem berühmtesten Freien Betriebssystem), zum Texteditor EMACS und zum e-mail-Übertragungsprogramm fetchmail beigetragen.

Wichtiger ist jedoch seine Arbeit als Historiker, Soziologe und Öffentlichkeitsarbeiter der Open-Source-Bewegung.

2.1  Wissenschaftliche Arbeiten

Einige von Raymonds Veröffentlichungen sind eindeutig als wissenschaftliche Publikation positioniert und wurden auch so angenommen. (Z.B. bei First Monday -- nach Eigendarstellung3 ein ``peer-reviewed journal on the Internet''.) Die Papers wurden von WissenschaftlerInnen zitiert und kommentiert, und waren auch Argumentations-Grundlage für Entscheidungen von Software-Firmen. (Netscape nennt explizit ``The Cathedral and the Bazaar'' (CatB, [Ray99a]) als wichtigen Faktor in der Entscheidung, den Quellcode des Netscape-Browsers zu veröffentlichen. Auch bei Microsoft (eigentlich ein typischer Vertreter der anderen Seite) wird teilweise die Argumentation von CatB übernommen, etwa in den ``Halloween Documents'' [Val98].)

Raymond ist kein Mitglieder der streng genommenen academic community, und weicht auch in einigen Punkten von den Gebräuchen dieser ab. So enthalten die meisten seiner Papers eine Versions-Geschichte, in der die nachträglichen Änderungen am bereits publizierten Dokument beschrieben sind. Das ist typisch für die Software-Entwicklung (so etwas wie das ``perfekte'' Programm gibt es nicht -- es sind immer Verbesserungen möglich), aber nicht fürs wissenschaftliche Publikationswesen. Diese Änderungen werden meist nach Anregungen der LeserInnen eingearbeitet. Deswegen zirkulieren von den beliebteren bzw. älteren Papers mehrere Versionen. Wo es notwendig ist, werde ich auf die Unterschiede eingehen.

2.2  The Cathedral and the Bazaar (CatB)

Von diesem Dokument sind mir vier Versionen bekannt -- eine einfache Web-Suche würde wahrscheinlich noch einige finden (abgesehen davon, daß Eric S. Raymond den Text in einem Versionsverwaltungswerkzeug hält und somit beliebige alte Versionen hervorholen kann). Es gibt auch Übersetzungen, die von der offiziellen Seite verlinkt sind.

2.2.1  Kurze Inhaltsangabe

Raymond beschreibt, daß die Software-Community -- und auch er selbst -- vom Erfolg des Betriebssystems Linux im Laufe der 90er Jahre überrascht waren. Die etablierte Meinung -- selbst unter den VertreterInnen der Freien Software -- war, daß so große Programme wie ein universelles Betriebssystem nicht in weltweiter Zusammenarbeit (Metapher: Bazar), sondern nur in einer kleinen Gruppe von SpezialistInnen (Metapher: Kathedrale) geschrieben werden können. Eric Raymond beschloß also, seine Theorien darüber, wie das funktionieren kann, an einem eigenen Projekt (fetchmail) zu testen. Es folgt eine (etwas technische) Beschreibung der Ziele dieses Projekts, und die von der Linux-Entwicklung abgeschauten Elemente -- Hypothesen, die laut Raymond durch die Erfahrungen verifiziert wurden.

Raymond übernimmt also ein bestehendes Projekt, das für ihn ein Problem löst, und das vom ursprünglichen Autor nicht mehr weiterentwickelt wird. Er wendet die von Linus Torvalds (Autor des Linux-Betriebssystems) übernommenen Methoden an. Das Projekt entwickelt sich zügig weiter, und es kommt zu einem wichtigen Punkt: Ein User schickt die Idee, und auch gleich den Sourcecode, für eine Erweiterung, die sich bald als die wichtigste und nützlichste erweist. Dies ist laut Raymond der wichtigste und offensichtlichste Beweis für die Qualität der Open-Source-Entwicklung -- so ein Ereignis hätte bei ``Closed Source'' nicht passieren können, da die BenutzerInnen keine Zugriff auf den Quellcode des Programms haben, es daher auch nicht weiterentwickeln können.

Danach folgt die Widerlegung einer bis dahin als unumstößliche Wahrheit angenommenen Aussage aus dem Klassiker der Software-Entwicklung, Fred Brooks' ``The Mythical Man-Month'', nämlich daß die Anzahl der ProgrammiererInnen nicht notwendigerweise zu einer schnelleren Entwicklung führe. Raymond zeigt, unter welchen Umständen diese Regel nicht auf die Open-Source-Entwicklung anwendbar ist.

In aktuelleren Versionen (im Buch schon enthalten, im First Monday-Paper noch nicht) folgt noch ein Kapitel mit Empfehlungen, wie ein Open-Source-Projekt ``geführt'' werden kann.

2.2.2  Zentrale Aussagen und wie sie argumentiert werden

(Ich werde mich mit den Aussagen nicht inhaltlich auseinandersetzen -- darum geht es hier nicht, und das haben wesentlich erfahrene Leute schon getan --, sondern damit, wie sie argumentiert werden. Das Ziel ist, abzuleiten, wie gültig die Aussagen nach wissenschaftlichen Kriterien erscheinen.)

Diese Aussagen erscheinen im Text speziell abgesetzt und numeriert -- es ist also davon auszugehen, daß Eric S. Raymond ihnen besondere Bedeutung zumißt und das Paper um sie aufbaut.

1. Every good work of software starts by scratching a developer's personal itch. (Jede gute Software wird geschrieben, weil einE EntwicklerIn ein zu lösendes Problem (``Jucken'') hat.)

Dies scheint offensichtlich, wird aber nur mit der Beobachtung argumentiert, daß in der herkömmlichen Software-Industrie zu viele ProgrammiererInnen an langweiligen Projekten, an denen sie kein persönliches Interesse haben, arbeiten, und daß es in der Open-Source-Entwicklung anders sei.

2. Good programmers know what to write. Great ones know what to rewrite (and reuse). (Gute ProgrammiererInnen wissen, was sie schreiben sollen - die Großartigen wissen, was sie umschreiben und wiederverwenden sollen.)

Argumentiert wird diese Aussage damit, daß auf diese Weise die Produktivität steigt; Wiederverwendbarkeit ist tatsächlich ein häufig genanntes Ideal der Software-Entwicklung. Das sieht offensichtlich aus, aber die Unterscheidung ``Good ... Great ... programmers'' wird nicht wirklich belegt.

3. ``Plan to throw one away; you will, anyhow'' (Fred Brooks, ``The Mythical Man-Month'', Chapter 11) (Plane im Voraus ein, daß du Arbeit wegwerfen wirst müssen - es wird so kommen.)

Diese zitierte Aussage wird etwas umformuliert: manchmal versteht mensch ein Problem erst nachdem mensch es einmal gelöst hat. Die zweite Lösung kann dann vernünftiger sein und sogar im Hinblick auf die zukünftige Wartung der Software den Aufwand rechtfertigen, das Programm komplett neu zu schreiben.

Als Beleg für die Richtigkeit der Aussage wird aber (abgesehen von der zitierten Autorität) nur die eigene Entscheidung in Kenntnis der Brooks'schen Regel angeführt.

(An dieser Stelle beschreibt Raymond, wie er die Verantwortung für die Weiterentwicklung des Projekts ``popclient'' vom ursprünglichen Autor, der das Interesse daran verloren hat, übernimmt.)

4. If you have the right attitude, interesting problems will find you. (Mit der richtigen Einstellung werden dich die interessanten Probleme finden.)

Das einzige angeführte Argument dafür ist Raymonds eigene Erfahrung. Dieser Punkt hat, wie einige andere, eigentlich nichts mit dem Thema des Papers, der Open-Source-Entwicklung, zu tun, und ist eher ein ``literarisches'' als ein ``wissenschaftliches'' Element in CatB.

5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. (Wenn jemand ein Projekt aufgibt, sollte er/sie sich um die kompetente Weiterführung kümmern.)

Dieser in der Hacker-Gesellschaft beobachtbare Usus wird später in ``Homesteading the Noosphere'' [Ray99b] weiter ausgeführt; die Aussage basiert auf einer Beobachtung Raymonds (der zweifellos eine Autorität auf dem Gebiet der sozialen Spielregeln der Hacker-Community ist), ist aber nicht, wie es auf dieser Grundlage angemessen wäre, deskriptiv formuliert (etwa: ``...people usually hand it off...''), sondern normativ.

6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. (Die Behandlung der BenutzerInnen als MitentwicklerInnen ist der einfachste Weg zu schneller Entwicklung und effektiver Fehlerbehebung.)

Dies ist eines der wichtigsten Argumente der Open-Source-VertreterInnen. Die empirischen Beispiele (Linux, Fetchmail, Apache und praktisch jede erfolgreiche Open-Source-Software) zeigen ihnen zufolge klar, daß der Zugriff auf den Quellcode dazu führt, daß die BenutzerInnen (wenigstens die mit Programmierkenntnissen, oder auch die, die solche Leute kennen) selbst die Dinge in die Hand nehmen können.

Für einen richtigen Vergleich mit der Closed-Source-Methode müßte jedoch ein Experiment herangezogen werden, in dem ein vergleichbares Programm mit vergleichbaren Ressourcen (Zeitaufwand etc.) als Closed Source implementiert und gewartet wird. Erst dann wären sichere Aussagen über die qualitativen Unterschiede zwischen beiden Methoden möglich. So beweisen Raymonds Beispiele nur, daß Open Source eine funktionierende Methode ist.

(In späteren Versionen von CatB, zuerst im CatB-Buch, taucht das Beispiel des EGCS-Projekts auf [Experimental GNU Compiler System]. EGCS wurde bewußt nach den Empfehlungen von CatB entwickelt und erreichte nach 20monatiger Entwicklung den Stand des früheren Projekts GCC (GNU Compiler Collection), mit der Konsequenz, daß das offizielle GCC-Team die eigene Arbeit einstellte und dem EGCS-Projekt beitrat. Dies könnte als eine experimentelle Bestätigung der Überlegenheit der offeneren Entwicklung gewertet werden. GCC wurde früher zwar als Open Source veröffentlicht, aber eher nach der Cathedral-Methode von einer geschlossenen Gruppe entwickelt.)

7. Release early. Release often. And listen to your customers. (Veröffentliche früh und oft und hör auf deine ``KundInnen''.)

Laut Raymond wirken die kleinen, inkrementellen Verbesserungen als Motivationsfaktor für die BenutzerInnen, weil ihre Probleme ``sofort'' gelöst werden, und für die EntwicklerInnen, weil sie ``sofort'' die Gratifikation, daß ihre Arbeit im beliebten System erscheint, bekommen.

Das ist eine Aussage über menschliche Motivation, also aus dem Bereich der Psychologie oder Sozialpsychologie. In einer wissenschaftlichen Publikation würde eine solche Aussage üblicherweise mit Bezügen auf vorhandene Literatur belegt, oder im Paper selbst begründet werden. Hier wird jedoch die Verhaltensempfehlung nur mit der aufgestellten Theorie erklärt, ohne die Theorie zu belegen oder etwa darauf einzugehen, wie sehr die angeblich höhere Motivation den höheren Zeitaufwand aller Beteiligten kompensiert.

8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. (Bei einer genügend großen Gruppe aus TesterInnen und MitentwicklerInnen wird jedes Problem schnell gefunden und die Lösung für jemanden offensichtlich sein.)

Diese Aussage ist so zentral (und wird auch so häufig zitiert), daß Raymond ihr einen speziellen Namen, ``Linus's Law'', gegeben hat. (``Linus'' ist Linus Torvalds, der finnische Programmierer, der das Linux-Projekt gestartet hat und nach wie vor die Entwicklung leitet.)

Das grundlegende Argument für Linus' Law ist ein logischer Umkehrschluß: Wäre das Gesetz nicht gültig, wäre ein so komplexes und von so vielen verschiedenen Leuten ``angefaßtes'' System wie der Linux-Kernel unter der Last von unvorhergesehenen Interaktionen und tief versteckten Programmierfehlern zusammengebrochen. (Es ist bekannt in der Forschung über Software-Entwicklung, daß mit der Komplexität eines Projekts die Wahrscheinlichkeit des Mißerfolgs überproportional ansteigt.)

Die zweite Absicherung der Aussage ist der Bezug auf die in der Soziologie bekannte Delphi-Effekt-Theorie, die besagt, daß der Durchschnitt der Vorhersagen vieler fähigen BeobachterInnen meist zuverlässiger ist als die einzelnen Vorhersagen. Raymond scheint davon auszugehen, daß sein Publikum diese soziologische Theorie so gut kennt, daß er keine Literaturhinweise oder Quellen -- die beim Bezug auf eine fremde Theorie in wissenschaftlichen Publikationen sonst üblich sind -- anführt.

Linus' Law bezieht sich nur auf einen Aspekt der Software-Entwicklung, nämlich auf die Fehlersuche und -behebung. Diese zusammen verursachen laut Brooks mindestens 40 % der Kosten der Software-Entwicklung -- wenn sie durch Open Source stark verbessert werden, kann der Vorteil also dieses Ausmaß erreichen.

9. Smart data structures and dumb code works a lot better than the other way around. (Kluge Anordnung der Daten mit einfachen Befehlen funktioniert viel besser als umgekehrt.)

Dies ist eine Aussage über Software-Entwicklung, Raymonds eigenes Betätigungsfeld. Sie wird mit der Autorität des Software-Entwicklungs-Klassikers von Brooks' ``Mythical Man-month'' und Raymonds eigener Erfahrung belegt. Es handelt sich allerdings nicht um den Vergleich der beiden Entwicklungsmethoden, ist also in diesem Rahmen weniger interessant.

10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. (Wenn du deine Beta-TesterInnen7 wie deine wertvollste Ressource behandelst, werden sie deine wertvollste Ressource werden.)

Diese Aussage leitet Raymond auch aus seiner Theorie, die er in der Linux-Entwicklung gesehen und mit fetchmail bestätigt hat, her. Er hat die ``Methode'' von Linus Torvalds und dessen Stil der Organisation der Linux-Entwicklung übernommen, und sie scheint auch bei ihm zu funktionieren.

(Es gibt allerdings auch bekannte Gegenbeispiele. Die ungarische Entwicklergruppe der beliebten Linux-Videoabspielsoftware ``mplayer'' gilt als unfreundlich, intolerant und arrogant, siehe z.B. den vieldiskutierten Artikel ``MPlayer: The project from hell''8.)

11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. (Fast so gut wie selbst gute Ideen zu haben ist das Erkennen der guten Ideen der BenutzerInnen. Manchmal ist das zweite sogar besser.)

Dies wird nur als ``Ego-Aufbaumethode'' für LeiterInnen von Open-Source-Projekten ausgeführt, kaum in Bezug auf das eigentliche Thema, die Software-Entwicklung.

12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. (Oft entstehen die eindrucksvollsten und innovativen Lösungen dadurch, daß mensch realisiert, daß die eigene Problemsicht falsch war.)

Es ist genauso schwer, diese Aussage zu belegen, wie sie zu widerlegen: Das Wort ``oft'' ist zu unscharf für eine wissenschaftliche Theorie. Raymond beschreibt hier lediglich, daß es in diesem einzelnen Fall eben so war.

13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.'' (``Ein perfekter Entwurf wird nicht erreicht, wenn es nichts mehr zum Hinzufügen, sondern wenn es nichts mehr zum Wegnehmen gibt.`` -- Raymond zitiert hier Antoine de Saint-Exupéry, aber ohne Quellenangabe.)

Der einzige Beleg Raymonds für diesen Slogan ist folgender Satz: ``When your code is getting better and simpler, that is when you know it's right.'' (Wenn dein Programmcode besser und gleichzeitig einfacher wird, weißt du, daß es richtig ist. [Hervorhebung durch ESR]) Das ist kaum eine über alle Zweifel erhobene Argumentation -- es ist aber anzunehmen, daß sie einem erfahrenen Software-Entwickler so vorkommt.

In einem folgenden Absatz beschreibt Raymond ohne besondere Hervorhebung das, was er eigentlich mit den letzten drei Slogans belegen wollte: Linus' Law gelte nicht nur für die Fehlersuche, sondern auch für die ``Entdeckung des Entwurfsraums'' (``exploration of design space''), also für die Suche nach möglichen Lösungen eines Problems.

14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. (Ein Werkzeug sollte seine vorgesehene Aufgabe lösen, aber ein wirklich großartiges Werkzeug bietet sich auch für unvorhergesehene Aufgaben an.)

Dies ist wiederum keine wissenschaftliche Aussage, und wohl auch nicht nur auf die Open-Source-Entwicklung bezogen.

15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and *never* throw away information unless the recipient forces you to! (Wenn du ``vermittelnde'' Software schreibst, bemühe dich, den Datenstrom so wenig wie möglich zu ändern -- und werfe *niemals* Information weg, es sei denn, der Empfänger zwingt dich dazu.)

Dies ist ein ziemlich allgemein anerkanntes Ideal in der Software-Entwicklung; Raymond erklärt nur, wie es für fetchmail sinnvoll war, sich daran zu halten.

16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend. (Wenn deine Sprache [hier ist die ``Sprache'' der fetchmail-Konfigurationsdatei gemeint] nicht annähernd Turing-komplett ist, kann ``Syntaktischer Zucker'' dein Freund sein.)

17. A security system is only as secure as its secret. Beware of pseudo-secrets. (Ein Sicherheitssystem ist nur so sicher wie sein Geheimnis. Hüte dich von Pseudo-Geheimnissen.)

Diese beiden Punkte empfiehlt Raymond nur für technisch gebildete LeserInnen, und sie machen auch nur für diese Sinn. (``Turing-complete'' ist eine Bezeichnung für Programmiersprachen, die bestimmten Kriterien des Mathematikers und Computer-Pioniers Alan Turing entsprechen. ``Syntactic sugar'' ist InformatikerInnen-Slang, nachlesbar im von Eric S. Raymond selbst betreuten ``Jargon File''9. Ein ``pseudo-secret'' wäre im Fall von Fetchmail eine scheinbare Verschlüsselung der Paßwörter, die aber gegenüber Angriffen keinerlei Sicherheit böte.)

Beide Aussagen werden halbwegs ausgeführt, aber nur mit persönlichen Erfahrungen argumentiert.

18. To solve an interesting problem, start by finding a problem that is interesting to you. (Um ein interessantes Problem zu lösen, such ein Problem, das für dich interessant ist.)

Raymond formuliert hier Regel 1 neu, ohne etwas zur Aussage oder auch zur Erklärung hinzuzufügen. Jedoch beginnt hier ein längerer Teil, der anhand der Frage der Motivation die Thesen von Brooks und Gerald Weinberg (``The Psychology of Computer Programming'') herausarbeitet und auf die Open-Source-Entwicklung überträgt.

19. Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. (Wenn die Person, die die Entwicklung koordiniert, ein mindestens so gutes Kommunikationsmittel wie das Internet hat, und weiß, wie sie ohne Zwang führen kann, sind mehr Köpfe unweigerlich besser als einer.)

Diese These wird mit Weinbergs Beobachtungen über unterschiedliche Kommunikationsstile bei Gruppen von ProgrammiererInnen und einem Zitat aus ``Memoirs of a Revolutionist'' von Pjotr Alexejewitsch Kropotkin, einem russischen Anarchisten des 19. Jahrhunderts belegt. Weitere Parallelen aus der Biologie und aus den Wirtschaftswissenschaften (``...a collection of selfish agents...'', [Ray99a, S. 64]) werden genannt. Raymond schließt daraus, daß wegen der Motivationsmechanismen und der leichteren Kommunikation, die nicht wie bei Brooks zu exponentieller Komplexität führt, für die Open-Source-Entwicklung andere Regeln gelten. Er suggeriert weiter, daß Open-Source-Software über die kommerzielle Seite ``triumphieren'' wird, weil sie viel mehr Menschen (und damit mehr Programmierzeit) einbeziehen kann.

Die Originalversion von CatB endet hier (z.B. in der Version auf redhat.com nachzulesen). In neueren Revisionen folgt noch eine Auseinandersetzung mit Einwänden, die nach der Publikation auf First Monday aufgetaucht sind. Ab der First Monday-Version gibt es auch einen Epilog, der beschreibt, wie Netscape Communications 1998 mit Bezug auf die Thesen in CatB sich entschieden hat, den Quellcode des Netscape-Browsers freizugeben. (Das daraus entstandene Mozilla-Projekt will jetzt, im Frühjahr 2002, die Version 1.0 seines Browsers veröffentlichen.)

2.2.3  Bewertung der Argumentation in CatB

Die 19 numerierten Kernaussagen von ``The Cathedral and the Bazaar'' lassen sich folgenden Themenkreisen zuordnen: Vom Ansatz und auch von der Rezeption her scheint der Schwerpunkt von CatB auf den Unterschieden zwischen Closed- und Open-Source-Entwicklung zu liegen - dazu gehören die Frage der Motivation und die speziellen Eigenschaften der Open-Source-Entwicklung. Die Gepflogenheiten werden in ``Homesteading the Noosphere'' [Ray99b] und anderen Werken Raymonds genauer ausgeführt; für die eher verstreuten und punktuellen Aussagen über die ``gute'' Software-Entwicklung gibt es wesentlich besser anerkannte und systematischere Quellen.

Mit einem in der Wissenschaft üblichen Zitat von fachlich passender Literatur (also Quellenangabe etc.) wird nur die Aussage 19 belegt.

Die Anwendung der vom Linux-Kernel abgeleiteten Theorien, also der neuen Erkenntnis, erfolgt in der Begründung der Aussagen 6 (``threating the users as co-developers''), 7 (``release early, release often''), 8 (``Linus's Law''), 10 (``if you treat your beta-testers...'') und 19 (``many heads are inevitably better than one''). Der ``Beweis'' ist jeweils die Gemeinsamkeit zwischen dem Linux-Kernel und der eigenen fetchmail-Entwicklung. Andere Erklärungsmodelle werden gar nicht angeboten.

Alle anderen Aussagen -- der größere Teil -- werden nur mit eigener Erfahrung, mit der Aussage selbst (!), mit ``klugen Sprüchen'' (die einem erfahrenen Software-Entwickler wie ESR wohl als selbstverständlich erscheinen) oder gar nicht belegt.

``The Cathedral and the Bazaar'' wurde als wissenschaftliche Veröffentlichung präsentiert, und wird auch seitdem so behandelt. Es ist sicherlich gut geschrieben, angenehm zu lesen und wohl auch ziemlich überzeugend, wird aber dem Anspruch der Wissenschaft wegen des eher lockeren Umgangs mit wissenschaftlichen Methoden nicht ganz gerecht. In meinen Augen eignet es sich nur bei sehr vorsichtiger Anwendung als zitierbare Quelle für andere Arbeiten -- eher nur als Anregung, einzelne Punkte davon besser zu belegen.

2.3  Homesteading the Noosphere

(Etwa: Besitznahme an der ``Noosphäre''. Noosphäre wird als ``Territorium der Ideen, der Raum aller möglichen Gedanken'' erklärt.)

Auch dieses Werk wurde in verschiedenen Versionen veröffentlicht; ich benutze hier die, die im CatB-Buch [Ray99b] abgedruckt ist. (Laut Versionsgeschichte auf der Raymond-Homepage ist seitdem am Inhalt nichts geändert worden.)

Homesteading the Noosphere könnte am ehesten als soziologische Arbeit bezeichnet werden. Ihr Grundgedanke ist, daß zwischen den öffentlich geäußerten Zielen der Open-Source- / Freie Software-Bewegung (die z.B. aus den Lizenzverträgen, die den Programmen beiliegen, hervorgehen) und den tatsächlichen Verhaltensweisen der beteiligten EntwickerInnen eine gewisse Diskrepanz merkbar ist. Das Paper geht diesen Diskrepanzen auf den Grund und versucht sie zu erklären.

HtN richtet sich eher nur an die Gruppen, die sich selbst mit Open Source beschäftigen. Es wurde außerhalb dieser Kreise anscheinend weniger diskutiert, und versucht auch nicht, Aussagen aufzustellen, die außerhalb des eigenen Feldes, etwa auf die kommerzielle Software-Entwicklung, anwendbar wären.

Drei ``Tabus'' werden identifiziert:
  1. ``Forking'', das Abspalten eigener Versionen von einem anderen Open-Source-Projekt. Obwohl jede Open-Source-Lizenz das Forking vorsieht (es ist sogar eines der primären Kriterien für Open-Source-Lizenzen), ist Forking sehr selten, und wenn, dann geschieht es nur mit öffentlicher Rechtfertigung.
  2. Der Vertrieb von Änderungen an fremden Projekten ohne Billigung der AutorInnen.
  3. Entfernung der Urheber-Angaben ohne expliziten Auftrag der UrheberInnen.
Raymond argumentiert, daß es auch im Open-Source-Bereich eine implizite Annahme von Besitzrechten gibt, die dem von germanischen Stämmen ausgebildeten, im Mittelalter in westeuropäischen Ländern angewendeten und erstmals von John Locke systematisch beschriebenen System der Landbesitzrechte ähneln. So wie beim Landbesitz erwirbt jemand einen ``Besitztitel'' durch die ``Besetzung'' eines vorher nicht bevölkerten Teiles des virtuellen oder bestehenden ``Landes''. Wer ein Projekt ins Leben gerufen hat, hat durch diese ``Entdeckung'' gezeigt, daß er/sie geeignet ist, es weiterzuführen, und auch zu bestimmen, wer es weiterführen soll, falls er/sie selbst das nicht mehr tun kann oder will.

Weiters sei die Open-Source-Gemeinschaft eine ``Geschenkkultur'' (gift culture). Laut Raymond ist das ein Gesellschaftsmodell, das nicht allgemein bekannt sei, außer bei AnthropologInnen (``not generally recognized except by anthropologists'' [Ray99b, S. 99]). Nach dieser Theorie erlangen Open-Source-EntwicklerInnen Reputation nicht durch Macht oder Besitz, sondern durch das ``Verschenken'' der Ergebnisse ihrer Arbeit. Die drei genannten Tabus würden genau deswegen existieren, weil sie einen Schutz für die so gewonnene Reputation sicherstellen.

Im folgenden Teil des Papers werden die beobachteten Verhaltensweisen (etwa zur Lösung von Konflikten) anhand dieser zwei Erklärungsmodelle erläutert.

In einem anscheinend erst im Laufe der ``Weiterentwicklung'' des Papers hinzugefügten Teil am Ende von ``Homesteading the Noosphere'' zieht Raymond Parallelen zwischen Open-Source-Gemeinschaft und der akademischen Kultur.

``Homesteading the Noosphere'' ist ähnlich geschrieben wie CatB: Wegen der Erzählweise von Eric Raymond und seines selbstsicheren Stils ziemlich überzeugend, aber wissenschaftliche Merkmale fehlen. Die benutzten Theorien etwa aus dem Bereich der Anthropologie und Soziologie werden ohne Quellenangabe erwähnt: offensichtlich geht Raymond davon aus, daß seine Audienz diese Theorien bereits kennt.

2.4  The Magic Cauldron

(``Der magische Kessel''; in der walisischen Mythologie hatte die Göttin Ceridwen einen Kessel, der mit Hilfe einer speziellen Beschwörungsformel Essen produziert hat.)

Ich behandle hier die Revision aus dem CatB-Buch [Ray99c]; seitdem sind laut Versionstabelle keine inhaltlichen Änderungen geschehen.

In ``The Magic Cauldron'' betritt Raymond wieder ein neues Gebiet: die Wirtschaft. Er erklärt das scheinbar unerklärliche Phänomen, daß aufwendige Software hervorragender Qualität ``aus dem Nichts'' entsteht und allgemein ohne Beschränkungen zur Verfügung steht.

Grundlage der Argumentation bildet die Erkenntnis, daß Software großteils kein für den Markt erzeugtes Produkt, sondern eine Dienstleistung ist. Daher seien viele Gesetze des Produkt-Marktes nicht anwendbar. Vielmehr würde es häufig sowohl der anbietenden als auch der nachfragenden Seite schaden, das Produkt-Markt-Modell anzuwenden.

Raymond kehrt das berühmte ``Tragödie der Allmende''-Modell10 zum ``inverse commons''-Modell um. In diesem Modell verringert die Benutzung nicht den Wert der Software, sondern erhöht ihn -- etwa weil Fehler gefunden und gleich auch behoben werden. Für die Person, die den Fehler behoben hat, ist es ökonomisch besser, die Fehlerbehebung herauszugeben als sie für sich zu behalten oder zu verkaufen: im ersten Fall verliert sie nichts, da sie ja schon ihre Arbeitszeit erfolgreich investiert hat; im anderen Fall hätte sie mehr Mühe mit einer Preisfestsetzung sowie der immer wieder durchzuführenden Anwendung der Fehlerbehebung, wenn neue Versionen erscheinen.

Auf Grundlage dieser Analyse kategorisiert Raymond verschiedene Geschäftsmodelle, und gibt für jedes von ihnen eine Empfehlung ab -- nicht in allen Fällen Richtung Open Source.

``The Magic Cauldron'' ist ähnlich geschrieben wie CatB und HtN: es gibt kaum direkte Zitate; ökonomische Modelle werden als bekannt vorausgesetzt oder ohne Quellenangabe beschrieben; Einwände von LeserInnen wurden in neuere Versionen eingearbeitet.

Es ist deswegen ein interessantes Dokument, weil seine Zielgruppe die Leute sind, die finanzielle Entscheidungen treffen. Solche Leute haben üblicherweise eine wirtschaftliche Ausbildung -- die Theorien und Schlußfolgerungen müssen also ``halten'', noch mehr als bei den anderen zwei Papers.

2.5  Zusammenfassung: Arbeiten von Eric S. Raymond

Raymond könnte als eine der wichtigsten Schnittstellen zwischen der ziemlich selbstbezogenen Welt der Open-Source-Community und der ``wirklichen Welt'' gesehen werden. Seine Arbeiten sind die eines vielseitig interessierten, autodidaktisch gebildeten Laien.

In jedem der vorgestellten Werke stößt er in neue Bereiche vor -- er will lange bekannte ``Wahrheiten'' (z.B. Brooks' Annahme, daß größere Teams nicht schneller entwickeln können) widerlegen, holt wenig bekannte oder ``fremde'' Theorien vor und wendet sie auf ein neues Feld an (z.B. die Landbesitz-Theorie von Locke), oder betritt überhaupt komplett neue Wege (z.B. mit der Feststellung, daß der Softwaremarkt kein Produktmarkt ist). Dabei bewegt er sich selbstsicher zwischen unterschiedlichen Feldern wie Informatik, Soziologie, Wirtschaft, Recht, Geschichte und Völkerkunde. Er hat wesentlich zum Verständnis vieler Mechanismen der Open-Source-Software-Entwicklung beigetragen, während diese sich ihren heutigen Platz erkämpft hat.

Nach strengen, traditionellen Maßstäben ist sein Werk nicht ``wissenschaftlich genug''. Er hat jedoch, wie auch seine Kritiker anerkennen, wesentlich dazu beigetragen, das Feld für die wissenschaftliche Erforschung zu öffnen, und damit ``Wissen'' geschaffen.

3  Kritik an Eric S. Raymonds Werken

Raymonds Schriften haben in der Open-Source-Community selbst großen Anklang gefunden, weil sie den Betroffenen ein sehr positives Weltbild anbieten. Da die Werke (vielleicht bis auf HtN) auch andere Felder betreffen, haben sie eine kritische Auseinandersetzung nach sich gezogen.

Viele Anmerkungen hat Raymond in neuere Versionen seiner Papers eingearbeitet. Diese und andere Artikel, die sich mit Einzelaspekten etwa von CatB beschäftigen, sind von der Webseite11 verlinkt.

Von den vielen Stellungnahmen habe ich einen der lautesten Kritiker, Dr. Nikolai Bezroukov herausgegriffen.

3.1  Dr. Nikolai Bezroukov: ``vulgärer Raymondismus''

Einer der meistreflektierten Kritiker speziell von CatB ist Dr. Nikolai Bezroukov, ein Universitätsprofessor russischer Abstammung, der in den USA lehrt. Er hat sich 1999 gleich zweimal zum Thema zum Wort gemeldet.

Dr. Bezroukov hat eine lange Publikationsgeschichte12 und betreibt die Website ``softpanorama.org'', eine ``(etwas skeptische) Open Source Software Bildungsgesellschaft''13. Er gehört, anders als Eric S. Raymond, zum ``wissenschaftlichen Establishment''.

Sein erstes Paper, ``Open Source Software Development as a Special Type of Academic Research (Critique of Vulgar Raymondism)'' [Bez99a] war nicht dazu gedacht, auf fachlicher Ebene die Aussagen von CatB zu widerlegen. Vielmehr handelt es sich um eine Kritik der Argumentationsweise und des Aufbaus eines ``Fan-Kults'' um Raymond herum. Die zweite wichtige Aussage ist, daß Open-Source-Software-Entwicklung keine komplett neue, revolutionäre Idee, sondern eine andere Form der akademischen Forschung sei.

Im zweiten Paper, ``A second look at The Cathedral and The Bazaar'' [Bez99b] versucht Dr. Bezroukov, CatB zu analysieren und ein (ihm zufolge) objektiveres Bild der Open-Source-Softwareentwicklung zu zeichnen.

Beide Papers wurden, wie schon CatB, auf First Monday publiziert und lösten große Kontroversen aus.

3.1.1  Open Source Software Development as a Special Type of Academic Research (Critique of Vulgar Raymondism)

Dr. Bezroukov beschreibt zuerst, daß er in der Open-Source-Gemeinschaft und auch bei Eric S. Raymond übermäßig optimistische und unrealistische Sichtweisen über Open Source ortet und nennt einige Gründe für diese ``Verzerrung der Wirklichkeit (``distortion of reality''). Er sieht auch ernste Probleme mit dem Entwicklungsmodell selbst, die Raymond nicht anspricht.

Dr. Bezroukov bezeichnet Raymonds Interpretation von Open Source als ``Vulgärmarxistisch'', und hat damit -- obwohl es sich um einen anerkannten wissenschaftlichen Begriff14 handelt, der nichts über politische Einstellungen, sondern über die Annahme simpler, deterministischer sozio-ökonomischer Regeln des Klassenkampfes aussagt -- viel Verwirrung und sehr feindliche Kommentare (nicht zuletzt von Raymond selbst) provoziert. Dies hat die Akzeptanz des Papers wesentlich bestimmt, und zwar wahrscheinlich negativ, weil das großteils von CatB beeinflußte und in dieser Zeit in der Open-Source-Euphorie lebende Publikum diesen persönlichen Angriff übelgenommen hat.

Folgende Probleme, die Dr. Bezroukov in Raymonds Schriften erkannt haben will, werden genannt: Danach beschreibt Dr. Bezroukov Parallelen zwischen der Erstellung von Programmen und wissenschaftlichen Theorien. Programmieren sei ein Spezialfall von, oder zumindest sehr nah an wissenschaftlicher Forschung. Es gebe weitere Ähnlichkeiten in der Motivation (nicht Geld, sondern die Suche nach Lösungen für interessante Probleme) und in der Kommunikaton von virtuellen, nicht ortsgebundenen Gruppen, wie es bei WissenschaftlerInnen schon länger üblich sei.

Die Probleme der Open-Source-Entwicklung werden vor allem mit Zitaten von prominenten Linux- und anderen Entwicklern belegt. Dr. Bezroukov beschreibt organisatorische und Kommunikationsprobleme, die bei Raymond nicht vorkommen, aber empirisch (etwa durch Betrachtung der Linux-Kernel-Entwicklung) belegbar sind, und die These, daß internet-basierte Zusammenarbeit besonders effizient sei, widerlegen sollen.

Ein weiteres Problem sei die einseitige Auswahl der Projekte wegen der Motivation: Da ProgrammiererInnen programmieren, wählten sie in ihrer Freizeit ausschließlich Projekte aus, die nur für ProgrammiererInnen interessant seien. Deswegen gebe es in manchen Kategorien (z.B. ``Text-Editor'') Hunderte von konkurrierenden Open-Source-Programmen, in anderen wiederum gar keine.

Mit der wissenschaftlichen Gemeinschaft teilt die Open-Source-Entwicklung das ``Nicht Hier Erfunden''-Syndrom (``Not Invented Here''): Verwendbare Entwicklungen und Ergebnisse anderer Gruppen werden nicht verwendet, gerade weil sie von anderen Gruppen (also nicht vom eigenen ``Stamm'') kommen.

Laut Dr. Bezroukov würde der Erfolg eines Projekts auch dazu führen, daß die LeiterInnen überfordert werden und ``ausbrennen''. Dies wäre nur mit einer strengen hierarchischen Organisation und damit der Rückkehr zur ``Kathedrale'' handhabbar.

Ein wesentlicher Teil der Motivation sei auch, daß ein ``Feind'' existiert, dessen ``Zerstörung'' als übergeordnetes Ziel hilft, die Gruppe trotz einzelner unterschiedlichen Ansichten zusammenzuschmieden. Dieser Feind sei die Firma Microsoft, und das Ziel, Microsoft zu schwächen, würde andere Alliierte, die sich sonst nicht für Linux interessieren würden, anlocken (so etwa IBM). Dies sei laut Dr. Bezroukov gefährlich, weil die Software-Entwicklung sich dadurch aus der sicheren akademischen Ecke auf ein gefährlicheres Feld, in den Kampf gegen einen übermächtigen Gegner begebe.

Für die Akzeptanz des Papers waren die persönlichen Angriffe auf Raymond wahrscheinlich nicht sehr hilfreich, wie schon gesagt. Häufig wurde auch die Argumentationsführung kritisiert: währen CatB wenigstens beschreibt, wie von einem beobachteten Beispiel (Linux) Theorien abgeleitet und erfolgreich auf fetchmail angewendet werden, seien in Dr. Bezroukovs Werk keinerlei empirische Belege vorhanden. In manchen Fällen (Konflikte, burn-out etc.) ignoriere er sogar die Realität der Projekte.

Eric S. Raymond selbst beschreibt in seinem ``A Response to Nikolai Bezroukov''15 (neben seiner Aufregung über den Vorwurf, ``Vulgärmarxist'' zu sein), daß Dr. Bezroukovs Paper nicht wirklich zur Debatte beitrage: Im ersten Teil des Papers würden Dinge in CatB hineininterpretiert, die nicht drinnen stehen, und im Rest nur neue Probleme auf nicht sehr originelle Weise angesprochen, die aber CatB nicht wiederlegten, weil sie sich gar nicht damit beschäftigen. Raymond wirft Bezroukov daher vor, eine künstliche Kontroverse erzeugt haben, nur um das eigene Paper zu promoten.

3.1.2  A Second Look at the Cathedral and the Bazaar

Als Reaktion auf die Erscheinung von CatB in Buchform publizierte Dr. Bezroukov auf First Monday seine zweite, diesmal genauer fokussierte Kritik von ``The Cathedral and the Bazaar''.

Das Paper [Bez99b] beginnt mit einer Aufzählung der Kernideen von CatB, die in die ``open source folklore'' eingegangen sein sollen, und seitdem als richtig vorausgesetzt werden.

Über die Annahme ``Brooks' Law gilt nicht für internet-basierte Entwicklung'' schreibt Dr. Bezroukov, daß die Vorstellung, Internet-Zugriff könnte die Leistung von EntwicklerInnen-Gruppen beeinflussen, naiv sei. Er glaubt (``I believe...''), daß diese ``Illusion'' bei solchen Projekten entstehen kann, die bereits funktionsfähige Prototypen haben und bei denen alle Architektur-Fragen bereits gelöst sind. Weiters drückt er seine Hochachtung vor ``The Mythical Man-Month'' aus, und befürchtet, daß CatB Leute dazu verleiten könnte, dieses viel wichtigere (``by several orders of magnitude more important than CatB'' [Bez99b]) Werk nicht zu lesen.

Zur Idee ``Mit genug Augen sind alle Fehler leicht zu finden'' meint er, daß sie zwar nicht durch den Linux-Kernel, aber komplette Linux-Distributionen (die aber aus mehrere hundert mal so viel Software bestehen) widerlegt werden. Weiters fragt er, ob die verteilte Fehlersuche die beste Möglichkeit ist, die Zeit talentierter EntwicklerInnen zu nützen. Mit einem Zitat von Ken Thompson, der am Anfang der 70er Jahre das Original-Unix mitentwickelt hat, argumentiert Dr. Bezroukov, daß Linux technisch überhaupt schlecht und fehlerhaft sei. (Thompson ist allerdings kein Linux-Experte, und er arbeitet an einem Konkurrenzsystem.) Die Position, daß Linux instabil und fehlerhaft sei, wird übrigens in der Industrie nicht gerade von Konsens getragen; sogar der größte Konkurrent Microsoft gab intern zu [Val98], daß Linux den eigenen Produkten in Leistung und Zuverlässigkeit zu der Zeit überlegen war. (In vielen anderen Texten Bezroukovs auf softpanorama.org ist das Motiv ``Linux ist schlechter als Solaris oder FreeBSD oder OpenBSD'' [andere Betriebssysteme] zu finden.)

Die Vorstellung, daß Linux zum Bazar-Modell gehöre, ist für Dr. Bezroukov zu sehr vereinfacht. Es gäbe auch Aspekte, die eher ``kathedralen-ähnlich'' seien, so wie bei den meisten anderen Open-Source-, aber auch proprietären Software-Projekten. Dies wird durch Aussagen von führenden Entwicklern der Kernel von Linux und FreeBSD und weiteren Experten belegt.

Die idealisierte Aussage, daß das Open-Source-Entwicklungsmodell automatisch die besten Resultate erbringe, versucht Dr. Bezroukov durch seine eigene Erfahrung mit einer Gruppe von Programmen, die er jahrelang beobachtet hat (``Orthodoxe Dateimanager'') zu belegen, wo keine signifikanten Qualitätsunterschiede zwischen Open- und Closed-Source-Vertreter zu bestehen scheinen.

Zum Thema ``was ist wirklich neu am Entwicklungsmodell von Linux?'' gibt Dr. Bezroukov zu bedenken, daß sehr ähnliche Entwicklungsmuster schon in den 80er Jahren bei anderen Freien Softwareprojekten (dem Übersetzerprogramm ``gcc'' und dem Texteditor ``EMACS'') zu beobachten waren und Linux nur eine verbesserte Version davon, aber keine Revolution darstelle. Außerdem sei die Menge der Quelltexte bei größeren Projekten schon ein ähnliches Hindernis wie die Nichtverfügbarkeit des Sourcecode bei proprietärer Software.

Der zweite Teil von ``A Second Look at the Cathedral and Bazaar'' beschäftigt sich mit dem Thema ``Status-Wettkämpfe in internetbasierten EntwicklerInnen-Gruppen'', vor allem mit Kommunikationsproblemen. (Hier verläßt also auch Dr. Bezroukov sein Feld, die Informatik.) Raymond wird vorgeworfen, sich zu wenig mit der reichlich vorhandenen bestehenden Literatur beschäftigt zu haben.

Die Kommunikationsprobleme werden mit Zitaten von Linux-Kernel-Entwicklern und aus der soziologischen Literatur belegt, und Vergleiche mit schlechten Tendenzen im ``peer review''-Prozeß der Wissenschaft aufgestellt.

Dr. Bezroukovs Fazit ist, daß das Bazar-Modell keine Vorhersagekraft für die positiven und negativen Punkte der Open-Source-Softwareentwicklung habe. Ihm zufolge sei der Vergleich mit der akademischen Gemeinschaft eine viel bessere Erklärung des Phänomens.

Im ``Second Look'' springen die eingestreuten Zitate ziemlich deutlich ins Auge. Es handelt sich unter anderem um ein Zitat von Friedrich Nietzsche (``Die häufigste Lüge ist es, sich selbst zu belügen...''), eines von Albert Einstein über die unendliche menschliche Dummheit und andere, die nicht wirklich den Text unterstützen, aber die in ihrem Umfeld dargestellten Leute (vor allem Eric S. Raymond) in ein schlechtes Licht bringen. Die wichtigsten Aussagen von CatB werden, obwohl das deklarierte Ziel des Papers genau das ist, nicht glaubwürdig und über alle Zweifel erhaben widerlegt.

4  Schlußfolgerungen

Freie bzw. Open-Source-Software ist zwar ein mehrere Jahrzehnte altes Phänomen, die wissenschaftliche Beschäftigung damit kann aber nur auf 5 Jahre zurückblicken. Dieses Feld wurde also erst vor sehr kurzer Zeit erschlossen, die Entwicklung der Argumente und Methoden ist also -- auch weil fast alles im Internet dokumentiert ist -- leicht zu beobachten. Diese (wegen der Einschränkungen einer Seminararbeit notwendigerweise kurze) Beschäftigung mit den zwei wichtigsten Linien der Argumentation sollte zeigen, wie ein ziemlich neues, interdisziplinäres wissenschaftliches Feld anfangs erschlossen wurde.

Eric S. Raymonds Konzept von der Besetzung der Noosphäre gilt interessanterweise auch für seine Publikationen: diese (vor allem ``The Cathedral and The Bazaar'') haben auch ein neues Gebiet für die wissenschaftliche Beschäftigung, aber auch für ein breites Publikumsinteresse erschlossen. Die Nachkommenden (hier Dr. Bezroukov) mußten sich auf einem Teil dieses Gebietes positionieren und ihre ``Grenzen'' markieren.

Für diese Erschließung der unbesetzten Teile war es, wie ich gezeigt habe, nur teilweise notwendig, streng wissenschaftlich zu argumentieren (Zitate, empirische Belege etc.) -- wichtiger war eine überzeugende Darstellung. CatB ist trotz der bei näherer Betrachtung nicht genau abgesicherten Argumentation und der häufigen narrativen Elemente ein unvermeidlicher Bezugspunkt für spätere Werke und wird es wahrscheinlich für lange Zeit bleiben. Der große Erfolg und die enorme Wirkung der Publikation färben auf die frühen Nachfolger ab, die sich vor allem mit der Positionierung gegenüber dem ``Standardwerk'' beschäftigen, weniger mit der Stärke der wissenschaftlichen Argumente.

Mit der Zunahme der wissenschaftlichen Beschäftigung mit dem Thema hat sich der Ton der Veröffentlichungen erkennbar an die Spielregeln der herkömmlichen Wissenschaft angenähert: das ist z.B. in den online publizierten Papers16 auf der ``Free/Open Source Research Community''-Seite des Massachusetts Institute of Technology zu sehen. Sie werden großteils an Universitäten oder Forschungseinrichtungen geschrieben; enthalten ``korrekte'', ``wissenschaftliche'' Zitierweisen und viel Literatur; diskutieren ihre Methoden und sie konzentrieren sich -- anders als etwa CatB -- auf einzelne Aspekte.

In den Zitaten nehmen Eric S. Raymonds Arbeiten eine zentrale Position ein: kein Paper, das ich gesehen habe, kommt ohne Bezug auf ihn aus. So wird sein Werk in einer Weise für die Wissenschaft ``legitimiert''.

References

[Bez99a]
Bezroukov, Dr. Nikolai: Open Source Software Development as a Special Type of Academic Research (Critique of Vulgar Raymondism). First Monday, 4(10), 1999. http://www.firstmonday.org/issues/issue4_10/bezroukov/index.html.

[Bez99b]
Bezroukov, Dr. Nikolai: A Second Look at the Cathedral and the Bazaar. First Monday, 4(12), 1999. http://www.firstmonday.org/issues/issue4_12/bezroukov/index.html.

[Ray99a]
Raymond, Eric S.: The Cathedral & the Bazaar, The Cathedral and the Bazaar,  27. O'Reilly, 1999.

[Ray99b]
Raymond, Eric S.: The Cathedral & the Bazaar, Homesteading the Noosphere,  79. O'Reilly, 1999.

[Ray99c]
Raymond, Eric S.: The Cathedral & the Bazaar, The Magic Cauldron, 137. O'Reilly, 1999.

[Val98]
Valloppillil, Vinod: Open Source Software: A (New?) Development Methodology. 1998. Interne Microsoft-Memo, die später unter der Hand an Eric S. Raymond weitergegeben wurde, der sie mit eigenen Kommentaren versehen veröffentlicht hat: http://www.opensource.org/halloween/halloween1.html.
1
Das Wort ``Hacker'' wird in den Medien anders verwendet, nämlich als ``jemand, der/die in fremde Computersysteme einbricht''. Die korrekte Bezeichnung dieser Leute ist ``Cracker''.
2
Diese Informationen stammen von seiner Lebenslauf-Seite: http://www.tuxedo.org/~esr/resume.html.
3
http://firstmonday.org/idea.html
4
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
5
http://www.firstmonday.org/issues/issue3_3/raymond/
6
http://www.redhat.com/support/wpapers/community/cathedral/whitepaper_cathedral.html
7
Beta-Test: Test der Entwicklungsversion einer Software, von der noch bekannt ist, daß sie Fehler hat
8
Joe Barr: MPlayer: the project from hell. LinuxWorld, 2001-12-17

http://www.linuxworld.com/site-stories/2001/1214.mplayer.html
9
Eric S. Raymond (Hrsg.): the Jargon File. http://tuxedo.org/~esr/jargon/html/
10
(``tragedy of the commons''): wenn eine Weidefläche von den Kühen mehrerer Eigentümer benützt wird, sind diese daran interessiert, möglichst früh möglichst viele Kühe weiden zu lassen, solange eben die Ressourcen (das Gras) halten. Dadurch wird die Fläche aber schnell unbrauchbar und alle verlieren. Gäbe es eine Übereinkunft über die Benutzung, könnte ein Gleichgewicht behalten werden.
11
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
12
Selected Papers of Dr. Nikolai Bezroukov

http://www.softpanorama.org/Articles/index.shtml
13
http://www.softpanorama.org/
14
http://www.softpanorama.org/OSS/Bla_faq/vulgar_marxism.shtml
15
http://www.firstmonday.org/issues/issue4_11/raymond/index.html
16
http://opensource.mit.edu/online_papers.php
This document was translated from LATEX by HEVEA.