4Bibeln: Freie Software

Homesteading the Noosphere | "Bewohnen/Bewohnbarmachung des Raumes aller denkbaren Gedanken"

Diese Übersetzung basiert auf der Fassung vom 8. August 1999.

Jeder, der die geschäftige und immens produktive Welt der Open Source eine Weile lang beobachtet hat, wird einen interessanten Widerspruch zwischen dem feststellen, was Open Source-Hacker sagen zu glauben, und dem, wie sie sich tatsächlich verhalten -- zwischen der offiziellen Ideologie der Open Source-Kultur und seiner tatsächlichen Praxis. Kulturen sind adaptive Maschinen, und die Open Source-Kultur ist das Ergebnsi eines gut erkennbaren Satzes von Anreizen und Sachzwängen. Wie das üblicher Weise so ist, bestehen die Adaptionen auch hier sowohl aus bewusster Ideologie als auch aus impliziter, unbewusster oder halbbewusster Kenntnis. Oft reiben sich dabei die unbewussten Adaptionen teilweise mit der bewussten Ideologie, was auch durchaus üblich ist.

In diesem Papier werden wir uns auf die Suche nach den Wurzeln dieses Widerspruchs machen und dann unsere Erkenntnisse dazu verwenden, um die treibenden Kräfte und Sachzwänge dahinter zu entdecken. Davon ableiten werden wir einige interessante Aussagen über die Hackerkultur und ihre Sitten. Wir werden mit Vorschlägen schließen, wie diese impliziten Kenntnisse der Kultur besser genutzt werden können.

Text in eckigen Klammern verweist auf die Bibliographie.

inhalt

Die Ideologie der Open Source-Kultur (also das, was Hacker sagen zu glauben) ist für sich schon ein relativ komplexes Thema. Alle Mitglieder sind sich darin einig, dass Open Source (also frei zirkulierbare Software, die nach Belieben weiterentwickelt und an den eigenen Bedarf angepasst werden kann) eine gute Sache ist und bedeutenden kollektiven Aufwand wert ist. Dieser Konsens definiert praktisch die Teilnahme an der Kultur. Trotzdem variieren aber die individuellen Motive einzelner Teilnehmer und Subkulturen beträchtlich.

Eine Variation ist der Grad an Fundamentalismus -- ob Open Source-Entwicklung als bloßes Mittel zum Zweck (gute Tools und schöne Spielsachen und schöne Computerspiele) oder als Selbstzweck betrachtet wird.

Eine Person mit sehr fanatischen Überzeugungen könnte vielleicht äußern: "Freie Software ist mein Leben! Ich existiere, um nützliche und schöne Computerprogramme und Informationsgüter herzustellen und zu verschenken." Eine Person von gemäßigtem Fanatismus mag vielleicht erklären: "Open Source ist eine runde Sache, und ich bin bereit, ordentlich Zeit zu investieren und dazu beizutragen." Eine noch gelassenere Person könnte sagen: "Open Source ist manchmal ganz in Ordnung. Ich spiele damit herum und respektiere die Leute, die daran arbeiten."

Eine weitere Dimension in der Variation ist der Grad an Feindseligkeit gegenüber kommerzieller Software und/oder den Firmen, die nach allgemeiner Auffassung den Markt für kommerzielle Software dominieren.

Eine sehr antikommerziell eingestellte Person könnte vielleicht äußern: "Kommerzielle Software ist Diebstahl. Ich schreibe freie Software, um diesem Übel ein Ende zu setzen." Eine gemäßigtere Person mag vielleicht erklären: "Kommerzielle Software im allgemeinen ist okay; die Programmierer verdienen es ja schließlich, für ihre Arbeit bezahlt zu werden. Firmen aber, die sich durch schlechte Produkte bereichern, und ihre Macht missbrauchen, sind ein Übel." Eine ganz und gar nicht antikommerziell eingestellte Person mag sagen: "Kommerzielle Software ist okay. Ich verwende und/oder schreibe Open Source-Software, weil sie mir besser gefällt." (Seit dem ersten Erscheinen dieses Papiers ist der Anteil des Open Source-Segments der Industrie gewachsen; man hört inzwischen auch oft: "Kommerzielle Software ist gut, solange ich auch den Quellcode bekomme oder sie alles kann, was ich will.")

Alle neun der Haltungen, die sich aus Kombination der obenstehenden Kategorien ergeben, sind in der Open Source-Kultur tatsächlich präsent. Es lohnt sich, auf diese Unterschiede hinzuweisen, denn sie implizieren verschiedene Anliegen und jeweils unterschiedliches adaptives und kooperatives Verhalten.

Historisch gesehen war und ist der am straffsten organisierte Teil der Hackerkultur sehr fanatisch und sehr antikommerziell. Die von Richard Stallman (RMS) gegründete Free Software Foundation (FSF) unterstützte einen beachtlichen Teil der Open Source-Entwicklung seit Beginn der 1980er, darunter Tools wie Emacs und gcc, die noch immer grundlegender Bestandteil der Open Source-Welt sind und es für absehbare Zukunft auch bleiben werden.

Viele Jahre lang war die FSF der wichtigste einzelne Brennpunkt des Open Source-Hacking und brachte eine gewaltige Anzahl an Tools hervor, die noch heute von zentraler Bedeutung für die ganze Kultur sind. Die FSF war auch lange Zeit der einzige Sponsor der Open Source und hatte eine institutionelle Identität, die auch für Beobachter außerhalb der Hackerkultur wahrnehmbar war. Sie definierte praktisch den Begriff "Freie Software" und verlieh ihr so bewusst Konfrontationspotential (das die neuere Bezeichnung "Open Source" bewusst zu vermeiden trachtet).

Daher tendierte die Auffassung von der Hackerkultur sowohl innerhalb als auch außerhalb dazu, die Kultur mit der fanatischen Haltung der FSF in Verbindung zu bringen und als antikommerziell zu verstehen (RMS selbst weist von sich, antikommerziell zu sein, aber sein Programm wurde von den meisten Leuten so verstanden, darunter einige seiner energischsten Partisanen). Die unbarmherzige und ausdrückliche Mission "Weg mit kommerzieller Software" kam einer Hacker-Ideologie am nächsten und RMS bekam größte Ähnlichkeit mit einem Anführer der Hackerkultur.

Die Lizenzklauseln der FSF, die "allgemeinen Geschäftsbedingungen" gewissermaßen ("General Public License" oder GPL), drückt diese Geisteshaltung aus. Sie ist in der Open Source-Welt sehr verbreitet. Metalab (vormals Sunsite) in North Carolina ist das größte und beliebteste Software-Archiv der Linux-Welt. Im Juli 1997 verwendete ungefähr die Hälfte aller dort gespeicherten Software-Pakete mit ausdrücklichen Lizenzen GPL.

Aber die FSF war niemals der einzige Schauplatz. Es gab immer auch stillere, weniger auf Konfrontation bedachte und marktfreundlichere Seitenarme in der Hackerkultur. Die Pragmatiker waren nicht so sehr einer Ideologie gegenüber loyal als einer Reihe von Ingenieurstraditionen, die noch in die Zeit vor der FSF reichen. Diese Traditionen beinhalten - und das ist hier am bedeutsamsten - die eng ineinander verzahnten technischen Kulturen von Unix und des präkommerziellen Internet.

Die typische Geisteshaltung dieser Pragmatiker ist nur mäßig antikommerziell und ihre größte Anklage gegen die kommerzielle Softwarewelt ist nicht das "Horten" per se. Stattdessen richtet sie sich gegen die verirrte Weigerung der Welt, die überlegenen Ansätze von Unix, der offenen Standards und Open Source-Software anzunehmen. Wenn überhaupt etwas, dann hasst ein solcher Pragmatiker wahrscheinlich nicht die Raffzähne im allgemeinen, sondern den jeweils zeitgenössischen Marktführer; früher war das IBM, heute ist es Microsoft.

Für Pragmatiker ist die GPL ein wichtiges Werkzeug, kein Selbstzweck. Ihr größter Wert liegt nicht in der Bewaffnung gegen das Horten, sondern in der Ermunterung, Software gemeinsam zu nutzen und das Wachstum von Entwicklergemeinden im Basar-Stil zu fördern. Der Pragmatiker schätzt gute Tools und schönes Spielzeug mehr als dass er Kommerzialismus ablehnt. Auch kann er kommerzielle Software verwenden, ohne in ideologischen Zwiespalt zu geraten. Gleichzeitig hat ihn seine Open Source-Erfahrung aber Standards der technischen Qualität vermittelt, die nur sehr wenige Closed Source-Programme erreichen können.

Viele Jahre lang verstand sich die pragmatische Auffassung innerhalb der Hackerkultur vorwiegend als sture Gegenbewegung zur Agenda der FSF im allgemeinen und der GPL im besonderen. Während der ganzen 1980er und frühen 1990er tendierte diese Haltung dazu, mit den Fans des Berkely Unix - Verwendern der BSD-Lizenz - in Verbindung gebracht zu werden, und den frühen Unternehmungen zur Schaffung von Open Source-Unixes auf der Grundlage des BSD-Codestammes. Diese Anstrengungen schafften es aber nicht, basarartige Gemeinden von bedeutender Größe aufzubauen und verloren durch Fragmentierung ernsthaft an Durchschlagskraft.

Nicht vor der Linux-Explosion von Anfang 1993-1994 konnte Pragmatismus eine wirkliche Basis finden. Obwohl Linus Torvalds niemals als Gegner von RMS auftrat, schuf er ein oft kopiertes Vorbild, indem er dem Wachstum einer kommerziellen Linux-Industrie mit Wohlwollen gegenübertrat, öffentlich für das Verwenden von kommerzieller Software für spezielle Aufgaben eintrat und die puristischen und fanatischen Elemente in der Kultur sanft zerstreute.

Ein Nebeneffekt des rapiden Wachstums von Linux war die Einführung einer großen Anzahl von neuen Hackern, deren Hauptanliegen Linux war und die in der Agenda der FSF ein in erster Linie historischer Belang war. Obwohl die neuere Welle der Linux-Hacker das System als "the choice of a gnu generation" bezeichnete, tendierten die meisten dazu, mehr Torvalds nachzuahmen als Stallman.

Mehr und mehr wurden die antikommerziellen Puristen zur Minderheit. Wie sehr sich die Dinge geändert hatten, wurde erst offensichtlich, als Netscape im Februar 1998 ankündigte, sie werde den Quellcode von Navigator 5.0 veröffentlichen. Das erzeugte mehr Interesse an "freier Software" in den Vorstandsetagen. Die darauf folgende Aufforderung an die Hackerkultur war dann, diese noch nie dagewesene Chance zu nutzen und die Bewegung von "Free Software" in "Open Source" abzuändern, was zu einer für alle Beteiligten überraschenden Akzeptanz führte.

Mitte der 1990er kam es einer bestärkenden Entwicklung, die den pragmatischen Teil der Kultur um mehrere Zentren herum gruppierte. Andere halb-autonome Gemeinden mit ihrem eigenen Selbstverständnis und eigenen charismatischen Führern begannen aus dem Stamm der Unix/Internet-Szene zu sprießen. Nach der Linux- war die wichtigste von ihnen die perl-Kultur um Larry Wall. Kleiner, aber auch bedeutend, waren die auf John Osterhouts Sprache Tcl und Guido van Rossums Python aufbauenden Traditionen. Alle drei dieser Gemeinden drückten ihre ideologische Unabhängigkeit durch die Stiftung eigener, von GPL unabhängigen, Lizenzverfahren aus.

inhalt

Trotz all dieser Veränderungen blieb ein breiter Konsens darüber bestehen, was "Free Software" oder "Open Source" bedeutet. Der klarste Ausdruck dieser allgemeinen Theorie kann in den verschiedenen Open Source-Lizenzen gefunden werden, die alle zentralen Elemente gemeinsam haben.

1997 wurden diese gemeinsamen Elemente in die Debian Free Software Guidelines destilliert, die zur Open Source Definition wurde. Nach diesen von der OSD definierten Richtlinien muss eine Open Source-Lizenz das unbedingte Recht schützen, dass jeder Open Source-Software verändern darf. Daher ist die implizierte Theorie der OSD (und OSD-konformen Lizenzen wie GPL, der BSD-Lizenz und perls Artistic License), dass jeder alles hacken darf. Nichts hält beispielsweise ein halbes Dutzend Leute davon ab, jegliches Open Source-Produkt herzunehmen (wie etwa den gcc C-Compiler der Free Software Foundation), deren Quellcode zu kopieren und in jeweils verschiedene Entwicklungsrichtungen auszuschwärmen und zu behaupten, an dem Produkt zu arbeiten.

In der Praxis gibt es solche "Forkings" ("Abgabelungen" aber so gut wie gar nicht. Zersplitterungen in bedeutenden Projekten sind selten geblieben und wurden immer von einer Umetikettierung und zahlreichen und langatmigen öffentlichen Rechtfertigungen begleitet. Es ist offensichtlich, dass in Fällen wie dem GNU Emacs/xemacs-Split oder dem gcc/egcs-Split oder bei den verschiedenen BSD-Splittergruppen die Beteiligten unter dem Eindruck standen, einer sehr starken der Gemeinde zuwiderzuhandeln

Tatsächlich verfügt (und das steht im Widerspruch zum verbrieten Grundsatz "Jeder darf alles hacken") die Open Source-Kultur über ein raffiniertes, stillschweigend angenommenes System zur Definition von Eigentümerschaft. Diese Sitten legen fest, wer Software verändern darf, die Umstände, unter denen sie verändert werden darf, und (besonders), wer das Recht hat, modifizierte Versionen in die Gemeinde zurückzuspeisen.

Die Tabus einer Kultur widerspiegeln ihre Normen in grellen Kontrasten. Daher wird es für später nützlich sein, wenn wir die wichtigsten Normen hier zusammenfassen.

• Es gibt starken sozialen Druck gegen das Forking von Projekten. So etwas geschieht einfach nicht, außer wenn die Umstände dazu zwingen; dann aber unter vielen öffentlichen Rechtfertigungen und mit einer Änderung des Projektnamens.

• Änderungen an einem Projekt ohne die Zustimmung der Moderatoren zu verbreiten, wird nicht gerne gesehen, außer in besonderen Fällen, wie etwa triviale Korrekturen von Portierungen.

• Den Namen einer Person aus der Project History, den Credits oder der Liste der Betreuer zu streichen, ist ohne die ausdrückliche Zustimmung dieser Person verboten.

Im Rest dieses Dokuments werden wir diese Tabus und Gebräuche der Eigentümerschaft im Detail untersuchen. Wir werden nicht nur darin eindringen, wie sie funktionieren, sondern auch, was sie über die zu Grunde liegende soziale Dynamik und Struktur der Anreize der Open Source-Gemeinde offenbaren.

inhalt

Was bedeutet "Eigentum", wenn dieses Eigentum unbegrenzt vervielfältigt und umgeformt werden kann und dessen umgebende Kultur weder Macht ausüben kann noch durch knappe Ressourcen eingeschränkt wird?

(Bei der in diesem Kapitel folgenden Erörterung über Eigentümerschaft verwende ich immer den Singular, so als ob alle Projekte nur einer Person gehörten. Man sollte aber wissen, dass Projekte auch einer Gruppe gehören können. Wir werden die interne Dynamik solcher Gruppen weiter unten in diesem Papier untersuchen.)

Wenn es nach den Standard-Lizenzen der Open Source geht, sind im Laufe der Entwicklung alle Teilnehmer gleichberechtigt. In der Praxis aber gibt eine allgemein anerkannte Unterscheidung zwischen "offiziellen", also abgesegneten, und in die Software unter Entwicklung integrierten Patches, und den "Rogue" ("abtrünnigen") Patches. Rogue Patches sind unüblich und ihnen wird im allgemeinen nicht getraut [RP].

dass öffentliche Verbreitung der zentrale Belang ist, kann leicht belegt werden. Es ist übliche Sitte, die Leute zu Patches für den persönlichen Gebrauch zu ermuntern, sollten sie notwendig werden. Die Haltung ist indifferent gegenüber Leuten, die ihre eigenen modifizierten Versionen in einer geschlossenen Gruppe von Benutzern oder Entwicklern zirkulieren. Nur, wenn Änderungen in die allgemeine Open Source-Gemeinde zurückgespeist werden, kommt der Belang der Eigentümerschaft zum Tragen.

Es gibt im allgemeinen drei Wege, auf denen Eigentümerschaft eines Open Source-Projekts erlangt werden kann. Der eine - der offensichtlichste - ist, das Projekt zu gründen. Wenn ein Projekt seit seinem Anfang nur einen Betreuer hatte, und dieser Betreuer noch aktiv ist, dann gestattet die Sitte nicht einmal die Frage, wem denn das Projekt nun gehöre.

Der zweite Weg zur Eigentümerschaft eines Projekts ist, sie vom bisherigen Eigentümer ausgehändigt zu bekommen (was manchmal "passing the baton" -- "die Staffette weiterreichen" genannt wird). In der Gemeinde wird das so verstanden, dass der Eigentümer die Pflicht hat, sein Projekt an kompetente Nachfolger weiterzureichen, wenn er die für die Entwicklung erforderliche Zeit nicht mehr aufbringen kann oder will.

Es ist bezeichnend, dass im Fall von bedeutenden Projekten solche Übergaben der Kontrolle mit viel Fanfare verlautbart werden. Während es in der Open Source-Gemeinde noch nicht vorgekommen ist, dass sich die Allgemeinheit in die Wahl des Nachfolgers einmischt, ist die übliche Auffassung, dass sie für die Öffentlichkeit überzeugend und legitim sein muss.

Für kleinere Projekte gilt, dass es im allgemeinen ausreicht, den Wechsel des Eigentümers in der Change History zu vermerken. Die klar ersichtliche Annahme hier ist, dass wenn der vorhergehende Eigentümer die Kontrolle nicht freiwillig abgegeben hat, dass er oder sie dann vielleicht die Eigentümerschaft mit Unterstützung der Gemeinde wiedererlangen kann, indem er oder sie innnerhalb einer angemessenen Zeit öffentlich Einspruch erhebt.

Der dritte Weg, um zur Eigentümerschaft eines Projekts zu kommen, ist, zu erkennen, dass noch Arbeit investiert werden muss, und der Eigentümer verschollen ist oder das Interesse verloren hat. Wenn man sich darum kümmern will, ist die erste Aufgabe, dass man den Eigentümer findet. Wenn man dabei erfolglos bleibt, sollte man an einer relevanten Stelle (etwa einer Usenet Newsgroup, die Applikationen gewidmet ist) ankündigen, dass das Projekt augenscheinlich verwaist ist, und dass man die Verantwortung dafür übernehmen will.

Die Sitten verlangen, dass man einige Zeit verstreichen lässt, bevor man mit der Verlautbarung herauskommt, man habe sich selbst zum neuen Eigentümer ernannt. Wenn während dieses Intervalls jemand anderer erklärt, dass er an dem Projekt arbeitet, hebt dieser Einwand jede andere Reklamation auf. Es wird als guter Stil gesehen, die Öffentlichkeit mehr als nur einmal darüber zu informieren. Zum guten Ton gehört auch, seine Verlautbarungen in mehreren relevanten Foren (Newsgroups, Mailing Lists) zu deponieren, und sich beim Warten auf die Reaktionen in Geduld zu wappnen. Im allgemeinen wird es so sein, dass die Überzeugungskraft der eigenen Reklamation mit dem Aufwand steigt, den man nachweislich für das Finden des vorigen Eigentümers oder anderer Betreuer erbracht hat.

Wenn man diesen Prozess unter den Augen der Benutzergemeinde des Projekts durchlaufen hat, und niemand Einwände erhebt, dann kann man die Eigentümerschaft für das verwaiste Projekt für sich reklamieren und in der History-Datei vermerken. Das ist aber weniger sicher als die Staffette ausgehändigt zu bekommen, und man kann nicht erwarten, dass man von der Gemeinde als Eigentümer voll legitimiert ist, bevor man nicht bedeutende Verbesserungen in das übernommene Projekt investiert hat.

Ich habe diese Sitten 20 Jahre lang in Aktion erlebt -- seit den Tagen vor der FSF. Die Gebräuche haben einige interessante Merkmale. Eines der interessantesten ist der Umstand, dass die meisten Hacker ihnen gefolgt sind, ohne sich dessen voll bewusst zu sein. Tatsächlich könnte das eben gesagte die erste vollständige niedergeschriebene Zusammenfassung sein.

Ein weiteres interessantes Merkmal der unbewussten Gebräuche ist, wie konsistent sie beachtet werden. Ich habe die Evolution von buchstäblich hunderten von Open Source-Projekten beobachtet, und kann immer noch die Zahl der bedeutenden Verletzungen dieser Normen an den Fingern abzählen.

Es gibt noch ein drittes beachtenswertes Merkmal: ihre Evolution erfolgte stetig und geradlinig in einer bestimmten Richtung. Mehr und mehr wurde zu Verantwortlichkeit, öffentlichen Verlautbarungen und Sorgfalt bei der Wartung der Credits und Change History ermuntert, die für die Legimität der Eigentümer bürgen sollen.

Diese Merkmale legen nahe, dass die Sitten nicht zufällig oder willkürlich sind, sondern Produkte einer impliziten Agenda oder eines generativen Musters in der Open Source-Kultur, das die Internet-Hacker in krassen Kontrast zur Kultur der Cracker und Software-Piraten ("warez d00dz") setzt, die um das Cracken von Computerspielen und Unterhalten von Piraten-BBSs entstanden ist. Dieser Unterschied illustriert beide generative Muster sehr gut. Wir werden weiter unten in diesem Papier auf die warez d00dz noch zurückkommen; der Untersiched zur Open Source-Kultur ist sehr aufschlussreich.

inhalt

Um dieses Muster zu verstehen, hilft es, einen Blick auf eine historische Analogie für diese Gebräuche zu werfen, die allerdings weitab von den üblichen Belangen der Hacker liegt. Wie Studenten der Rechtsgeschichte und Politologie vielleicht erkannt haben, ist die Theorie hinter dieser Form der Eigentümerschaft fast identisch mit der anglo-amerikanischen Rechtsauffassung von Grundbesitz!

Bei dieser Theorie gibt es drei Möglichkeiten, um zu Grundbesitz zu kommen.

Im Pioniergebiet, dort wo es Land ohne Besitzer gibt, kann man Grundbesitz durch Homesteading erwerben -- Arbeit plus unerschlossenes Gebiet plus Zaun plus Anspruch anmelden macht einen zum Besitzer dieses Grunds.

Für bereits erschlossene Gebiete ist der übliche Modus für die Übertragung von Eigentümerschaft der des Transfer of Title -- der neue Eigentümer bekommt das Land vom alten Eigentümer übertragen. Bei diesem Verfahren ist das Konzept der "Chain of Title" sehr wichtig. Der ideale Beweis für Eigentümerschaft ist eine Verkettung von Urkunden von Besitzern und Übertragungen, die bis zu dem Zeitpunkt zurückreichen, als das Land ursprünglich durch Homesteading erschlossen wurde.

Schließlich anerkennt diese Rechtsauffassung noch den Umstand, dass ein Anspruch auf Land verloren gehen kann oder plötzlich keinen Besitzer mehr hat (zum Beispiel, wenn der Eigentümer ohne Erben stirbt, oder die Urkunden verschwunden sind). Ein Landstück, das in dieser Weise herrenlos wurde, kann durch adverse posession beansprucht werden -- jemand besiedelt es, verbessert seinen Zustand und meldet Besitz an, ganz so wie durch Homesteading.

Diese Theorie entwickelte sich, genau wie die Gebräuche der Hacker, in organischer Weise in einem Kontext mit nur schwacher oder fehlender zentraler Autorität. Es evolvierte über einen Zeitraum von tausend Jahren aus den altnordischen und germanischen Stammesgesetzen. Da es durch den englischen politischen Philosophen John Locke systematisiert wurde, spricht man oft von der Lockeschen Auffassung von Grundbesitz.

Rechtsauffassungen mit ähnlicher Logik entstanden unabhängig davon sehr oft überall dort, wo Grundbesitz hohen ökomischen Wert hat oder lebenswichtig ist und wo es keine ausreichend mächtige einzelne Autorität gibt, die zentrale Rationierung knapper Güter auferlegen kann. Das gilt sogar für Kulturen von Jägern und Sammlern, von denen in romantischer Verklärung oft angenommen wird, sie hätten keine Auffassung von "Grundbesitz". Beispielsweise kennt die Tradition der !Kung San-Buschmänner der Kgalagadi (vormals "Kalahari")-Wüste tatsächlich keinen Anspruch auf Jagdgründe. Was sie aber kennt, ist Eigentümerschaft von Wasserstellen oder Quellen, deren Anspruch wie bei Locke geregelt wird.

Das Beispiel mit den !Kung Sans ist sehr lehrreich, weil es zeigt, dass Lockesche Sitten für Eigentümerschaft überall dort entstehen, wo der Ertrag aus einer Ressource die erwarteten Kosten seiner Verteidigung übersteigt. Jagdgründe sind kein Besitz, weil der Ertrag aus der Jagd variabel und nicht vorhersehbar und er (obwohl lukrativ) keine Notwendigkeit für das tägliche Überleben ist. Wasserstellen sind aber lebenswichtig und klein genug, um verteidigt zu werden.

Die "Noosphere", von der in diesem Papier die Rede ist, beschreibt den Raum aller denkbaren Gedanken [N]. Was wir in den Sitten der Eigentümerschaft impliziert sehen, ist eine Lockesche Rechtsauffassung von Besitzanspruch auf eine Untermenge der Noosphere, den Raum aller Computerprogramme. Daher ist der Titel "Homesteading The Noosphere" -- nach dem Aufwand, den jeder Gründer eines neuen Open Source-Projekts erbringen muss.

Faré Rideau <fare@tunes.org> weist ganz richtig darauf hin, dass Hacker nicht wirklich im Territorium reiner Ideen wirken. Er behauptet, dass Hacker Softwareprojekte besitzen -- Brennpunkte von konkreter Arbeit (Entwicklung, Service, etc.), mit denen Werte wie Reputation, Vertrauen, etc. verknüpft sind. Er schließt daraus, dass der von Hackerprojekten umspannte Raum nicht ein Teil der Noosphere ist, sondern eine Art Schatten davon, der Raum der die Noosphere erforschenden Softwareprojekte (mit einem entschuldigenden Kopfnicken in Richtung der Astrophysiker wäre es etymologisch korrekt, diesen Schattenraum als die "Ergosphäre" zu bezeichnen, den "Raum der Arbeit").

In der Praxis und für die Zwecke dieses Papiers ist diese Unterscheidung zwischen Noosphere und Ergosphere nicht notwendig. Es ist auch zweifelhaft, ob die "Noosphere" im Sinne Farés überhaupt in irgendeiner bedeutungsvollen Weise existiert; man müsste fast ein Philosoph aus der Schule Platons sein, um daran zu glauben. Und die Unterscheidung zwischen Noosphere und Ergosphere ist nur dann von praktischer Bedeutung, wenn man unterstellt, dass Ideen (die Elemente der Noosphere) nicht jemandem gehören können, die Manifestationen eines Projekts aber schon. Diese Frage führt uns zum Thema der Auffassung von geistigem Eigentum, das aber den Rahmen dieses Aufsatzes sprengt (mehr darüber in [DF]).

Um aber Verwirrung zu vermeiden, ist der Hinweis wichtig, dass weder die Noosphere noch die Ergosphere das selbe ist wie die Gesamtheit aller virtuellen Orte aller elektronischen Medien, die manchmal als "Cyberspace" bezeichnet wird (was oft den Ekel von Hackern erregt). Eigentümerschaft wird hier ganz anders geregelt, die genauen Verfahren sind denen für dessen materielles Substrat viel ähnlicher -- vereinfacht ausgedrückt, ist es so, dass, wer die Medien und Maschinen besitzt, die als Wirt eines bestimmten Teils des Cyberspace auftreten, auch diesen Teil des Cyberspace besitzt.

Die Lockesche Logik hinter den Gebräuchen legt es nahe, dass Open Source-Hacker diesen Gebräuchen folgen, um irgendeine Form von Ertrag aus ihrem Aufwand für sich zu beanspruchen. Dieser Ertrag muss bedeutender sein als der Aufwand, der in das Homesteading eines Projekts investiert wird, höher als die Unkosten für die Wartung der Versionsgeschichte, die den Besitzanspruch von Eigentümer zu Eigentümer verbrieft, und höher als der Aufwand, den die öffentlichen Verlautbarungen von der Übernahme eines verwaisten Projekts bedeuten.

Darüber hinaus muss der "Gewinn" aus Open Source höher sein als die bloße Möglichkeit, die Software zu verwenden; und höher als das, was durch Forking verdünnt würde oder verloren ginge. Wenn die Verwendung der Software der einzige Belang wäre, gäbe es kein Forking-Tabu, und Open Source-Eigentümerschaft sähe gar nicht wie die Auffassung von Grundbesitz aus. Tatsächlich wird diese Parallelwelt (Verwendung ist der einzige Gewinn, Forking ist kein Problem) durch die existierenden Open Source-Lizenzen impliziert.

Auf der Suche nach diesem versteckten Gewinn können wir einige Kandidaten sofort eliminieren. Da man über eine Netzwerkverbindung nicht effektiv Gewalt ausüben kann, fällt die Suche nach Macht aus. Da die Open Source-Kultur so etwas wie Geld oder ein Wirtschaften mit begrenzten Gütern nicht kennt, ist auch ein Streben nach matieriellem Wohlstand ausgeschlossen.

Es gibt aber einen Weg, auf dem Open Source-Aktivitäten Leuten helfen können, wohlhabender zu werden -- ein Weg, der uns einen wertvollen Hinweis darauf gibt, was diese Aktivitäten überhaupt motiviert. Gelegentlich kann die Reputation, die jemand in der Hackergemeinde erwirbt, in die Welt außerhalb dieser Gemeinde schwappen und ökonimische Bedeutung bekommen. Vielleicht springt ein besserer Job dabei heraus, oder ein Konsulentenvertrag, oder ein Buch.

Diese Art von Nebeneffekt kommt aber nur selten vor, und ist nicht einmal dann besonders lukrativ; als einzige Erklärung reicht er nicht aus, schon gar nicht, wenn wir dazu den wiederholten Protest der Hacker ignorieren müssen, dass sie nicht im Spiel sind, um Geld zu verdienen, sondern aus Idealismus oder Liebe.

Trotzdem ist die Weise, in der solche ökonomischen Nebeneffekte vermittelt werden, eine genauere Untersuchung wert. In den folgenden Abschnitten werden wir sehen, dass ein Verständnis der Dynamik der Reputation innerhalb der Open Source-Kultur selbst ausreichend erklärende Kraft liefert.

inhalt

Um die Rolle der Reputation in der Open Source-Kultur zu verstehen, ist es hilfreich, vom Gebiet der Geschichte in die der Anthropologie und Volkswirtschaft abzuschweifen und den Unterschied zwischen Tauschkulturen und Geschenkkulturen zu untersuchen. Die Menschen haben einen angeborenen Drang, um sozialen Status zu wetteifern; so ist es uns durch unsere evolutionäre Vergangenheit in die Gene gewoben. 90 Prozent dieser Geschichte liegen vor der Erfindung von Ackerbau und Viehzucht und unsere Vorfahren lebten in kleinen nomadischen Verbänden von Jägern und Sammlern. Individuen mit hohem Status (jene, die beim Bilden von Koalitionen und beim Überzeugen von anderen am erfolgreichsten waren) erlangten die gesündesten Sexpartner und die hochwertigste Nahrung. Dieser Drang nach Status drückt sich in vielfältiger Weise aus und hängt zu einem Großteil vom Grad ab, in dem eine lebensnotwendige Ressource begrenzt ist. Jede Facette dieses Aspekts hat seine eigene Art sozialen Status zu fördern.

Der einfachste Weg ist die Befehlshierarchie. Bei so einer Befehlshierarchie wird die Zuteilung von begrenzten Gütern durch eine zentrale Authorität vorgenommen und durch Gewalt exekutiert. Befehlshierarchien zeigen bei wachsender Anzahl von zu Befehlenden immer schlechtere Resultate [Mal] und werden entsprechend diesem Umfang immer brutaler und uneffektiver. Aus diesem Grund parasitieren Befehlshierarchien, deren Umfang den einer Großfamilie übersteigt, fast immer größere Ökonomien anderen Typs. In einer Befehlshierarchie wird der soziale Status durch den Zugang zur Befehlsgewalt bestimmt.

Unsere Ökonomie ist vorwiegend eine Tauschökonomie. Das ist eine sehr clevere Entsprechung der Knappheit von Gütern, deren Resultate auch bei umfangreichen Gesellschaften ihre Qualität behalten. Die Zuteilung von Gütern geschieht in dezentralisierter Weise durch Handel und freiwillige Kooperation (tatsächlich ist der bedeutendste Effekt des allgemeinen Wettbewerbs kooperatives Verhalten hervorzubrigen). In einer Tauschwirtschaft wird der soziale Status durch den Grad der Kontrolle über (nicht notwendigerweise materielle) Dinge bestimmt, die gebraucht oder gehandelt werden können.

Die meisten Menschen haben zumindestens eine vage Vorstellung für beide oben angeführte Modelle, und auch darüber, wie sie interagieren. Die Regierungen, die Armeen, und das organisierte Verbrechen sind Befehlshierarchien, die jeweils die übergeordnete Tauschwirtschaft parasitieren, die wir "den freien Markt" nennen. Es gibt aber auch ein drittes Modell, das von beiden sehr verschieden ist und nicht allgemein anerkannt wird, abgesehen von Anthropologen -- die Geschenkkultur.

Geschenkkulturen entsprechen nicht einem Mangel, sondern einem Überfluss. Sie treten in Populationen auf, die kein Problem der Begrenztheit von lebenswichtigen Gütern haben. Wir können Geschenkkulturen in Gesellschaften von Eingeborenen beobachten, die in Zonen mit mildem Klima und einem Überfluss an Nahrung haben. Auch in bestimmten Schichten unserer eigenen Gesellschaft kommen sie vor, besonders im Showbusiness und unter den sehr Wohlhabenenden.

Überfluss nimmt Machtverhätnissen die Grundlage und Tauschwirtschaft jeden Witz. In Geschenkkulturen wird der soziale Status nicht dadurch bestimmt, worüber man alles Kontrolle hat, sondern dadurch, was man alles verschenkt.

Das erklärt die Potlach-Parties des Kwakiutl-Häuptlings. Das erklärt die aufwendigen und üblicherweise öffentlichen philantropischen Gesten der Multimilloniäre. Und das erklärt die vielen Stunden, die Hacker in hochwertigen Open Source-Code investieren. Aus diesem Blickwinkel betrachtet, wird schnell klar, dass die Gesellschaft der Open Source-Hacker tatsächlich eine Geschenkkultur ist. Innerhalb dieser Kultur gibt es keinen wirklichen Mangel an "überlebenswichtigen" Gütern -- Plattenspeicher, Netzwerkbandbreite, Computermuskel. Software steht zur gemeinsamen Nutzung gratis zur Verfügung. Dieser Überfluss schafft eine Situation, in der das einzige Maß des Erfolgs im Wettbewerb die Reputation unter Gleichgesinnten wird.

Diese Beobachtung alleine reicht aber nicht aus, um die feststellbaren Merkmale der Hackerkultur ausreichend zu erklären. Die Cracker und warez d00dz haben eine Geschenkkultur, die im selben (elektronischen) Medium wohnt wie die der Hacker, ihr Verhalten ist aber ein ganz anderes. Die Gruppenmentalität ihrer Kultur ist viel ausgeprägter und legt mehr Wert auf Exklusivität als die der Hacker. Sie bunkern Geheimnisse, anstatt sie zu teilen; man wird viel öfter Crackertruppen finden, die eingekapselte Executables vertreiben, als welche, die Tips geben, wie ihre Babies funktionieren. (Einen Insiderbericht über dieses Verhalten finden Sie unter [LW]). Ich habe die Geschichte der Hackerkultur an anderer Stelle zusammengefasst [HH]; die Einflüsse, die dieses Verhalten prägen sind nicht weiter mysteriös. Hacker haben ihre Kultur durch eine Reihe von Regeln festgelegt, nach denen sie ihren Wettbewerb austragen. Es ist diese Form des Wettbewerbs, die wir noch im Rest dieses Papiers untersuchen werden.

inhalt

Beim Abfassen dieser Analyse des "Spiels um die Reputation" will ich nicht in Abrede stellen, dass das Schaffen von schöner, funktionierender Software ein rein schöpferisch befriedigender Akt sein kann. Wir alle kennen dieses Gefühl und haben unsere Freude daran. Menschen, für die es keine bedeutende Motivation ist, werden niemals Hacker sein können, wie ja auch Leute, die Musik nicht lieben, niemals Komponisten werden.

Vielleicht sollten wir also ein weiteres Modell von Hackerverhalten und -motivation erwägen, als bloß die reine Freude am fachmännisch ausgeübten Handwerk. Dieses Modell des "fachmännisch ausgeübten Handwerks" müsste die Sitten der Hacker als Weg erklären, der sowohl die Gelegenheit für fachliche Betätigung als auch die Qualität der Ergebnisse maximiert. Steht das in Konflikt mit den Erscheinungen oder legt es andere Erscheinungen nahe als das Modell mit dem Spiel um die Reputation?

Nicht wirklich. Bei der Untersuchung des "Handwerker-Modells" finden wir die selben Problemstellungen vor, die dem Hackertum auferlegen, als Geschenkkultur zu funktionieren. Wie kann man Qualität maximieren, wenn es kein Maß für Qualität gibt? Wenn die Ökonomie der begrenzten Güter nicht greift, welche Messlatte gibt es neben der Bewertung durch Gleichgesinnte? Es scheint, als müsste jeder Kult um virtuoses Handwerk sich letzten Endes um ein Spiel um Reputation strukturieren -- was wir tatsächlich in vielen historischen Handwerkerkulturen seit den Gilden des Mittelalters beobachten können. In einem bedeutenden Punkt aber ist dieses Modell schwächer als das der Geschenkkultur; auf sich gestellt, kann es den Widerspruch nicht erklären, mit dem wir dieses Papier eingeleitet haben.

Schließlich ist die Motivation durch fachmännisch ausgeübtes Handwerk selbst nicht so verschieden vom Wettbewerb um fachliche Anerkennung, wie wir vielleicht annehmen wollten. Stellen Sie sich vor, Ihr wunderbares Programm liegt in der Lade und wird nie wieder verwendet. Nun stellen Sie sich vor, Ihr Programm wird von vielen Leuten gern und gut verwendet. Welcher Traum gefällt Ihnen besser?

Trotzdem sollten wir das Handwerkermodell im Auge behalten. Es wird von vielen Hackern intuitiv verstanden und übt automatisch einen gewissen Reiz aus, und es erklärt einige Aspekte individuellen Verhaltens ausreichend gut. [HT].

Nach der Veröffentlichung der ersten Fassung dieses Papiers kommentierte ein anonymer Leser: "Man arbeitet vielleicht nicht, um sich Reputation zu schaffen, aber sie ist die wirkliche Entlohnung, die Konsequenzen hat, wenn man den Job gut macht." Das ist ein subtiler und wichtiger Einwand. Die Reputations-Anreize funktionieren auch weiterhin, egal, ob sich der Handwerker ihrer bewusst ist oder nicht; daher wird das Verhalten eines Hackers auch dann als Teil des Spiels um Reputation geprägt, wenn er es nicht als solches versteht.

Andere Leser siedelten die Entlohnung durch Anerkennung unter Gleichgesinnten und die Freude am Hacking in Abraham Maslows wohlbekannter "Bedürfnispyramide" in den Ebenen über den elementaren Notwendigkeiten an [MH]. Bei dieser Auffassung entspricht die Freude am Hacking einem Bedürfnis nach Selbstverwirklichung oder Transzendenz, das erst zum Tragen kommt, wenn die Bedürfnisse der unteren Ebenen (darunter jenes der physischen Sicherheit und "Zugehörigkeit" oder Anerkennung) wenigstens halbwegs erfüllt sind. Daher ist das Spiel um Reputation vielleicht von zentraler Bedeutung beim Schaffen eines sozialen Kontexts, innerhalb dessen die Freude am Hacking tatsächlich zum primären Motiv eines Individuums werden kann.

inhalt

Es gibt für jede Geschenkkultur viele Gründe, die das Spiel um Prestige unter Gleichgesinnten lohnend machen:

Zunächst einmal ist offensichtlich, dass ein guter Ruf unter Kollegen und Gleichgesinnten ein erstrebenswerter Vorzug ist. Wir alle sind aus evolutionären Gründen so gewoben, was schon an anderer Stelle erörtert wurde. (Viele Menschen lernen, ihren Drang nach Prestige in verschiedene Subliminationen umzuformen, die in keinem offensichtlichen Bezug zu einer unmittelbar umgebenenden Gruppe stehen, darunter "Ehre", "ethische Integrität", "Frömmigkeit", etc.; der zu Grunde liegende Mechanismus ändert sich aber nicht.)

Zweitens ist Prestige ein guter Weg (und in einer reinen Geschenkkultur der einzige Weg) um Aufmerksamkeit und Kooperation anderer zu erwirken. Wenn jemand für seine Großzügigkeit, Intelligenz, faire Behandlung, Führungseingenschaften oder andere Qualitäten bekannt ist, wird es viel leichter, andere Menschen davon zu überzeugen, dass sie durch Kooperation mit diesem jemand gewinnen.

Drittens ist es so, dass, wenn Ihre Geschenkkultur mit einer Tauschwirtschaft oder mit einer Befehlshierarchie in Verbindung steht oder mit ihr verzahnt ist, Ihr guter Ruf in diese andere Kultur hinüberschwappen kann und auch dort für hohes Ansehen sorgt.

Darüber hinaus machen die eigentülichen Umstände der Hackerkultur Prestige sogar noch wichtiger als für die "wirkliche" Geschenkkultur.

Der schwerwiegendste dieser "eigentümlichen Umstände" ist, dass die verschenkten Artefakte (anders gesagt: die verschenkte Zeit und Mühe) sehr komplex sind. Ihr Wert ist auf keinen Fall so leicht zu bemessen wie der von materiellen Gütern oder Geld. Es ist viel schwieriger, ein schönes Geschenk von einem armseligen zu unterscheiden. Dem entsprechend ist der Status des Stifters in heikler Weise vom Urteil seiner Umgebung abhängig.

Eine weitere Eigentülichkeit ist die relative Reinheit der Form der Open Source-Kultur. Die meisten Geschenkkulturen müssen Kompromisse eingehen -- sei es durch Beziehungen zu einer Tauschwirtschaft, sei es durch den Handel mit Luxusgütern, sei es durch Beziehungen zu ökonomisch orientierten Befehlshierarchien wie einer Familie oder eines Clans. In der Open Source-Kultur gibt es dazu keine Analogien; daher gibt es außer dem Urteil der Umgebung praktisch keine Möglichkeit zu Status zu kommen.

inhalt

Wir sind nun in der Position, die vorhergehenden Analysen in eine kohärente Darstellung der Sitten um die Eigentümerschaft in der Hackerkultur zu liefern. Wir verstehen den Nutzen aus dem Homesteading der Noosphäre; es ist die Reputation unter Gleichgesinnten in der Geschenkkultur der Hacker, mit allen sich daraus ableitenden Belohnungen und Nebenwirkungen.

Von diesem Verständnis ausgehend können wir die Lockesche Handhabung von Eigentümerschaft unter Hackern als ein Vehikel analysieren, das die Statusanreize maximieren und sicherstellen soll, dass die Würdigung durch Kollegen dem zuteil wird, der sie verdient.

Die drei Tabus, die wir oben erörtert haben, sind nach dieser Analyse völlig plausibel. Die eigene Reputation kann in unfairer Weise in Mitleidenschaft gezogen werden, wenn jemand anders die Früchte meiner Arbeit als die seinen ausgibt; die Tabus (und damit verwandte Gebräuche) versuchen das zu verhindern. (Oder, pragmatischer ausgedrückt, schrecken Hacker im allgemeinen vor Forking und Rogue Patches von Projekten anderer zurück, um so ein Verhalten nicht gegen das eigene Projekt zu legitimieren).

1. Das Forking von Projekten ist schlecht, weil es die Reputation der Autoren des ursprünglichen Projekts aufs Spiel setzt, dem sie nur durch Einflussnahme auf beide Projekte begegnen können (was im allgemeinen zu verwirrend oder schwierig wäre).
2. Die Verbreitung von Rogue Patches (oder, noch schlimmer, Rogue Binaries) setzt die Eigentümer einem unangemessenen Risiko aus. Sogar, wenn der offizielle Code perfekt ist, wird die Verantwortung für Bugs in den Patches ihnen zugeschoben (aber sehen sie dazu [RP]).
3. Ohne Rücksprache einen Namen aus einem Projekt zu streichen, ist, im kulturellen Kontext, eines der schlimmsten Verbrechen. Es stiehlt das Geschenk des Opfers und wird als das des Verbrechers ausgegeben.

Natürlich unterminieren das Forking und der Vertrieb von Rogue Patches direkt die Reputation der ursprünglichen Entwickler. Wenn ich von deinem Projekt abzweige oder Rogue Patches vertreibe, erkläre ich: "du hast eine falsche Entscheidung getroffen [weil du es nicht so gemacht hast, wie ich es jetzt mache]." Jeder, der meine Variante verwendet, stimmt dem zu. Das alleine wäre aber eine faire Herausforderung; es ist die schärfste Form von Kritik durch Gleichgesinnte. Daher reicht das alleine nicht aus, um die Tabus zu erklären, obwohl es ihnen natürlich ohne Zweifel Kraft verleiht.

Alle drei dieser Tabus bedeuten sowohl globalen Schaden für die Open Source-Gemeinde wie auch lokalen Schaden für die Opfer. Implizit ruinieren sie die ganze Gemeinde durch Verringerung der Wahrscheinlichkeit, dass produktives und großzügiges Verhalten von potentiellen Beitragenden auch gewürdigt wird.

Wichtig ist der Hinweis, dass es auch andere Kandidaten für eine Erklärung für zwei der drei Tabus gibt.

Der erste ist, dass Hacker ihre Antipathie gegenüber dem Forking von Projekten oft durch Beklagen der Verschwendung motivieren, die das Duplizieren des Aufwandes in jedem der Zweige bedeutet. Die unerwünschte Folge davon ist, dass weniger Gehirne für die Arbeit am Elternprojekt zur Verfügung stehen.

Ein Leser wies darauf hin, dass es nur selten vorkommt, dass mehr als ein Abkömmling eines geforkten Projekts auf lange Sicht überlebt und nennenswerten "Marktanteil" behält. Das verstärkt für alle Beteiligten die Anreize zu kooperieren und Forking zu vermeiden -- es ist schwierig, vorherzusehen, wer der beiden Abkömmlinge der Verlierer sein wird und wer seine Mühe vergeblich investiert.

Die Abneigung gegen Rogue Patches wird oft durch die Beobachtung erklärt, dass sie das Verfolgen von Bugs enorm verkompliziert und für die Betreuer unnötigen Mehraufwand bedeuten; immerhin ist es schon mühsam genug, die eigenen Programmierfehler zu finden und auszubessern.

Diese Überlegungen haben durchaus ihre Berechtigung, und ganz sicher verstärken sie die Logik des Lockeschen Modells der Eigentümerschaft. Trotz ihrer intellektuellen Attraktivität versagen sie aber bei der Erklärung, warum zu den seltenen Gelegenheiten die Gefechte um gebrochene Tabus mit so viel Emotion und Eifersüchteleien ablaufen. Das gilt nicht nur für die unmittelbar betroffenen Parteien, sondern auch für Außenstehende und Beobachter, die oft sehr hart reagieren und urteilen. Nüchterne Betrachtungen über Multiplizierung von Aufwand und Wartungsprobleme reichen da ganz einfach nicht aus, um dieses Verhalten zu erklären.

Es gibt aber noch ein drittes Tabu. Es ist nicht unmittelbar ersichtlich, wie es durch die Hypothese des Spiels um Reputation erklärt werden kann. Der Umstand, dass dieses Tabu selten profunder abgehandelt wird als durch "es wäre nicht fair" ist da auf seine Art schon verräterisch, wie wir im nächsten Abschnitt sehen werden.

inhalt

Zu Beginn dieses Essays erwähnte ich, dass das unbewusste adaptive Wissen einer Kultur oft im Widerspruch zu seiner bewussten Ideologie steht. Wir haben dafür bereits ein bedeutendes Beispiel gesehen: das Lockesche Besitzrecht bricht mit der durch die Standardlizenzen verbrieften Absicht.

Bei der Diskussion mit Hackern über die Analyse des Spiels um Reputation habe ich ein weiteres interessantes Beispiel für dieses Phänomen entdeckt: viele Hacker lehnten die Analyse ab und zeigten eine starke Abneigung zuzugeben, dass ihr Verhalten durch eine Sehnsucht nach dem Ansehen ihrer Kollegen ist, was ich damals unsensiblerweise als "Ego Satisfaction" (Ich-Befriedigung) bezeichnete.

Das illustriert eine interessante Facette der Hackerkultur. Sie misstraut Ego-basierten Motiven und verachtet sie; Eigenwerbung wird in der Regel gnadenlos verurteilt, sogar, wenn die Gemeinde dadurch etwas zu gewinnen hat. Das geht so weit, dass die "großen Männer" der Kultur, die "Stammesältesten", unter dem Druck stehen, nicht zu resolut aufzutreten und zu sich selbst eine ironische Distanz einzunehmen, um ihren Status behalten zu können. Wie diese Haltung mit der Anreizstruktur zusammengeht, die allem Anschein nach dahinter am Werk ist, fordert sehr nachdrücklich eine Erklärung.

Ein großer Teil davon stammt sicherlich von der im allgemeinen negativen anglo-europäischen Einstellung gegenüber "Ego". Die kulturelle Matrix der meisten Hacker hält sie zur Ansicht an, dass Ego Satisfaction ein verwerfliches (oder wenigstens unreifes) Motiv sei; dass Ego bestenfalls eine Schrulle ist, die man gerade noch bei Primadonnen tolerieren könne, wenn nicht gar eine Geisteskrankheit. Generell akzeptiert werden nur die sublimierten Formen, wie etwa "Ansehen in der Branche", "Selbstwertgefühl" oder "Stolz auf die eigene Leistung".

Ich könnte einen ganzen weiteren Essay über die Wurzeln dieses ungesunden Teils kulturellen Erbes schreiben, und den erstaunlichen Umfang des Schadens, der durch diese Selbsttäschung entsteht, trotz aller anderslautenden Belege, die uns Psychologie und Verhalten liefern). Ich brauche das aber nicht zu tun, denn Friedrich Wilhelm Nietzsche und Ayn Rand haben das Thema bereits in sehr kompetenter Weise abgehandelt (was auch immer ihre jeweiligen anderen Mängel waren) und "Altruismus" als getarnte Arten von Eigennutz entlarvt.

Mein Anliegen hier ist aber nicht Ethik oder Psychologie, daher werde ich nur ein geringes Beispiel für den Schaden herausgreifen, der durch die Ansicht hervorgerufen wird, dass Ego ein Übel sei. Der Schaden ist der, das es durch diese Ansicht vielen Hackern sehr schwer gemacht wird, ihre eigene Kultur zu verstehen!

Wir sind mit dieser Linie unserer Nachforschungen aber noch nicht zu Ende. Das Tabu der umgebenden Kultur gegen offen ego-motiviertes Verhalten ist in der Hacker-(Sub)Kultur so sehr verstärkt, dass einem der Verdacht kommen muss, dass es eine spezielle adaptive Funktion erfüllt. Sicher ist das Tabu in anderen Geschenkkulturen weniger ausgeprägt oder existiert gar nicht. Denken Sie nur an die Welt des Showgeschäfts oder die der sehr Vermögenden.

inhalt

Nach dem Verankern der These, dass Prestige das zentrale Element der Entlohnungsmechanismen der Hackerkultur ist, müssen wir uns als nächstes um ein Verständnis darüber bemühen, warum dieser Umstand so lange halb verborgen bleiben konnte und weitestgehend nicht anerkannt wurde.

Der Kontrast zur Kultur der Software-Piraten ist lehrreich. In dieser Kultur ist das Streben nach Status offensichtlich und oft alles andere als subtil. Diese Cracker greifen nach Ansehen durch die Freigabe von "zero-day warez" (gecrackte Software, die noch am selben Tag der Freigabe des Originals in Umlauf gebracht wird), halten sich aber darüber bedeckt, wie sie das zustande gebracht haben. Diese Zauberer wollen ihre Tricks nicht verraten. Als ein Resultat davon vermehren sich die kollektiven Kenntnisse der Crackerkultur nur sehr langsam.

Auf der anderen Seite die Gemeinde der Hacker. Die eigene Arbeit ist ein persönliches Statement. Es ist eine strenge Leistungsgesellschaft (bestes Handwerk gewinnt) und es gibt einen orthodoxen Ethos, dass die Qualität für sich selbst sprechen muss. Die durchschlagskräftigste Zeile lautet, dass etwas "halbwegs funktioniert" -- in Verbindung mit einem Werk, von dem jeder kompetente Programmierer sehen kann, dass es guter Stoff ist. Aus diesem Grund vermehrt sich das kollektive Wissen der Hackerkultur sehr schnell.

Das Tabu gegen Ego-motiviertes Posieren erhöht daher die Produktivität. Das für sich selbst ist aber ein Nebenprodukt; was hier direkt geschützt werden soll, ist die Qualität des Urteils der Gemeinde. Das heißt, Angabe oder Wichtigmacherei wird unterdrückt, weil es den Rauschpegel zu ungunsten der Signale von schöpferischen und kooperativen Experimenten erhöht.

Aus ähnlichen Gründen wird auch nie der Autor, sondern nur der Code attackiert. Eine interessante Subtilität erhärtet diese These: Hacker finden nichts dabei, einander bei persönlichen oder ideologischen Differenzen abzunesseln, aber es kommt nicht vor, dass ein Hacker einem anderen öffentlich die Kompetenz oder Arbeit schlecht macht (sogar private Kritik ist unüblich und in der Regel in zurückhaltendem Tonfall abgefasst). Die Jagd nach Bugs und Kritik richtet sich immer an ein Projekt, niemals an eine Person.

Darüber hinaus werden vergangene Bugs einem Entwickler nicht vorgeworfen; die Tatsache, dass ein Fehler beseitigt wurde, ist wichtiger, als die, dass es ihn jemals gegeben hat. Wie ein Leser beobachtete: jemand kann durch das Beheben eines "Emacs Bugs" Status erlangen, aber nicht durch das Beheben eines "Richard Stallman-Bugs". Und es würde als extremer Verstoß gegen die Etikette gesehen, kritisierte jemand Stallman für alte Emacs-Bugs, die bereits aus der Welt geschafft sind.

Das steht in interessantem Kontrast zu vielen Teilen der akademischen Welt, in denen es zur eigenen Reputation beiträgt, auf der Arbeit anderer herumzutrampeln. In der Hackerkultur ist dieses Verhalten massivst tabuisiert -- so massiv sogar, dass dieses Papier schon ein Jahr lang in Umlauf war, bevor mich jemand mit ungewöhnlicher Perspektive darauf hinwies!

Das Tabu gegen Angriffe auf die Kompetenz (das es in der akademischen Welt nicht gibt) ist sogar aufschlussreicher als das beiden gemeinsame Tabu gegen Posieren. Wir können diesen Unterschied zu einem Unterschied der Kommunikationsstrukturen der beiden Welten in Beziehung setzen.

Das Medium der Hackerkultur ist nicht stofflich ("intangible"); seine Kanäle sind für das Ausdrücken von emotonialen Nuancen ungeeignet. Wirkliche Begegnungen zwischen den Mitgliedern sind eher die Ausnahme als die Regel. Das erzeugt eine geringere Toleranz für Erhöhen des Rauschpegels als in anderen Geschenkkulturen üblich und kann das Tabu gegen Angriffe auf die Kompetenz gut erklären. Jeder bedeutende Verstoß dagegen würde die Reputationsskala der Kultur irritieren.

Die gleiche Anfälligkeit für höheren Rauschpegel wirft auch Licht auf die Bescheidenheit in der Öffentlichkeit, zu der die Stammesältesten der Gemeinde angehalten werden. Sie müssen als frei von Geltungssucht und Angeberei gesehen werden können, so dass das Tabu gegen gefährlichen Rauschpegel aufrecht erhalten bleibt. [DC]

Leise zu treten ist auch empfohlen, wenn jemand die Betreuung eines erfolgreichen Projekts anstrebt; man muss die Gemeinde von der eigenen Urteilsfähigkeit überzeugen, weil die Hauptaufgabe eines Betreuers die Bewertung von anderer Leute Code ist. Wer würde schon gerne Arbeit investieren, die dann von jemandem beurteilt wird, der nicht einmal den Wert des eigenen Codes erkennen kann? Oder dessen Verhalten nahe legt, dass er den "Reputationsertrag" aus dem Projekt unfairerweise für sich reklamiert? Potentielle Teilnehmer wollen Projektleiter mit genug Bescheidenheit und Klasse, um gegebenenfalls zu erklären: "Ja, das funktioniert besser als meine Version, bauen wir's ein" -- und die Anerkennenswertes anerkennen.

Noch ein weiterer Grund für Zurückhaltung ist, dass man in der Welt der Open Source nur selten den Eindruck erwecken will, dass ein Projekt vollendet ist. Das könnte potentiellen Beitragenden den Eindruck geben, nicht gebraucht zu werden. Der Weg zur maximalen Nutzung der eigenen Investition als Projektleiter führt über Bescheidenheit gegenüber dem Status des Programms. Wenn man den Code aber eher bemängelt und feststellt: "Well, er kann x nicht, und y und z auch nicht, er kann also so toll nicht sein", werden Patches für x, y und z oft sehr schnell folgen.

Schließlich habe ich selbst beobachten können, dass selbstentwertendes Verhalten einiger der führenden Hacker eine reale (und oft gerechtfertigte) Furcht davor reflektiert, das Objekt eines Personenkultes zu werden. Sowohl Linus Torvalds als auch Larry Wall bieten klare und zahlreiche Beispiele eines entsprechend ausweichenden Verhaltens. Während einer Dinner-Expedition mit Larry Wall witzelte ich einmal: "Du bist hier der Alpha-Hacker -- du darfst das Restaurant aussuchen". Das erschreckte ihn sichtlich, und das zu Recht. Das Versagen beim Auseinanderhalten der von allen anerkannten Werte und den Eigenheiten der Führungspersönlichkeiten hat mehr als nur einige Gemeinden ruiniert. Es ist ein Muster, das Linus voll bewusst sein muss. Auf der anderen Seite hätten wohl alle Hacker gern Larrys Problem, wenn es ihnen auch schwerfiele, es zuzugeben.

inhalt

Die Analyse des Spiels um Reputation hat noch mehr Implikationen, die nicht so ohne weiteres augenscheinlich sind. Viele davon beziehen sich auf den Umstand, dass jemand durch die Gründung eines Projekts höheres Ansehen erlangen kann als durch die bloße Teilnahme an einem schon bestehendem. Jemand gewinnt auch mehr durch Beiträge zu einem sehr innovativen Projekt, wenn man den Gewinn mit dem aus einer "me too"-Verbesserung etablierter Ingenieurskunst vergleicht. Auf der anderen Seite ist Software, die nur der Autor versteht, für das Spiel um Reputation wertlos, und oft ist es einfacher, seine Energien auf Beiträge zu einem bestehenden Projekt zu konzentrieren, als andere Leute für sein neu gegründetes zu interessieren. Schließlich ist es viel schwieriger, mit einem bereits erfolgreichen Projekt in Wettbewerb zu treten, als eine noch leere Nische zu füllen.

Aus diesen Gründen gibt es eine optimale Distanz von den eigenen Nachbarn (also den nächstähnlichen Projekten im Wettbewerb). Eine zu geringe Distanz bedeutet ein "Me Too"-Produkt von sehr geringem Wert und ein armseliges Geschenk (man wäre dann besser beraten, seine Zeit in Beiträge zu einem existierendem Projekt zu investieren. Eine zu große Distanz verunmöglicht es potentiellen Mitentwicklern und Anwendern, sich mit dem Programm zu befassen und die Bedeutung des eigenen Aufwandes zu würdigen (was auch ein armseliges Geschenk ergibt). Das erzeugt beim Homesteading der Noosphere ein Muster, das an das von in unerschlossenes Land ausschwärmende Siedler erinnert -- das Muster ist kein zufälliges, sondern das eines diffusions-begrenzten Fraktals. Projekte tendieren dazu, funktionelle Lücken am Saum des bereits erschlossenen Gebietes zu füllen. (siehe auch [NO] für eine weitere Erörterung des Wertes von Neuerungen).

Einige sehr erfolgreiche Projekte werden zu "Category Killers"; niemand will das Gebiet in ihrer Nähe beackern, weil der Wettbewerb um die Aufmerksamkeit der Hacker gegen eine so etablierte Basis zu schwierig ist. Leute mit eigenen Ideen zu solchen Unternehmen enden dann beim Schreiben von Erweiterungen für solche Killerprogramme. Das klassische Beispiel dafür ist GNU Emacs; seine Varianten füllen die ökologische Nische für einen voll programmierbaren Editor so vollständig aus, dass kein Konkurrent weit über das Ein-Mann-Projektstadium hinausgekommen ist. Stattdessen schreiben die Leute Emacs-Modes.

Global betrachtet haben diese beiden Tendenzen (Füllen von Lücken und Category Killers) im Laufe der Zeit zu einem ungefähr vorhersehbaren Trend bei der Gründung von Projekten geführt. In den 1970ern bestand die meiste Open Source-Software in Spielzeugprogrammen und Demos. In den 1980ern gingen alle Energien in Richtung Entwicklungs- und Internetwerkzeuge. In den 1990ern verlagerte sich der Schwerpunkt zu Betriebssystemen. In jedem Fall wurde eine neue und schwierigere Klasse von Problemen attackiert, sobald die Möglichkeiten und Aussichten der vorhergegangenen beinahe erschöpft waren.

Dieser Trend hat einige interessante Implikationen für die nahe Zukunft. Anfang 1998 sieht Linux sehr stark nach einem Category Killer für die Nische "Open Source-Betriebssystem" aus -- Leute, für die sonst das Schaffen eines konkurrierenden Betriebssystem attraktiv gewesen wäre, schreiben jetzt stattdessen Linux-Gerätetreiber und -Erweiterungen. Und die meisten von der Gemeinde nur denkbaren und ersehnten Lower Level Tools existieren bereits als Open Source. Was bleibt übrig?

Applikationen. Mit Näherrücken der Jahrtausendwende ist die Vorherssage recht sicher, dass die Energien für die Entwicklung von Open Source-Software mehr und mehr auf das letzte jungfräuliche Gebiet rücken werden -- Programme für Nicht-Techniker. Ein klarer erster Hinweis darauf ist die Entwicklung von GIMP, eines Photoshop-ähnlichen Bildbearbeitungsprogrammes, das Open Sources erste größere Applikation ist, die jene Art von benutzerfreundlicher Oberfläche bietet, die seit der letzten Dekade für kommerzielle Anwendungenals als unbedingt notwendig erachtet wird. Ein weiterer Indikator ist der Umfang an Geschäftigkeit um Toolkit-Projekte wie KDE und GNOME. Ein Leser dieses Papiers wies darauf hin, dass die Analogie mit dem Homesteading auch erklärt, warum Hacker auf Mircrosofts "embrace and extend"-Politik mit so vitriolischem Hass reagieren, die auf die Verkomplizierung und Einkapselung der Internet-Protokolle zielt. Die Hackerkultur kann mit der meisten Closed-Source-Software koexistieren; Adobe Photoshop beispielsweise macht das Territorium in der Nähe von GIMP (Photoshops Open Source- Äquivalent) nicht weniger attraktiv. Wenn aber Microsoft ihr angestrebtes de-commoditizing der Internet-Protokolle durchsetzen kann [HD] um damit die Entwicklung von Software dafür nur mehr Microsoft-Programmierern zu gestatten, schadt Microsoft damit nicht bloß seinen Kunden, die es dann auch hier mit einem Monopol zu tun haben. Microsoft reduziert auch den Umfang und die Qualität der Noosphäre, die Hackern für das Homesteading und die Kultivierung zur Verfügung steht. Es ist daher kein Wunder, dass Hacker Microsofts Politik oft als "Protokollverschmutzung" bezeichnen. Sie reagieren genau wie Farmer, die mitansehen müssen, wie jemand den Fluss vergiftet, mit dem sie ihr Land bewässern!

Schließlich erklärt die Analyse des Spiels um Reputation auch das oft zitierte Wort, dass man nicht zum Hacker wird, wenn man sich selbst als Hacker bezeichnet -- man ist erst Hacker, wenn von anderen Hackern so genannt wird. Ein Hacker ist, in diesem Licht, jemand, der (durch das Beisteuern von Geschenken) bewiesen hat, dass er oder sie sowohl technische Fertigkeiten hat, als auch versteht, wie das Spiel um Reputation funktioniert. Dieses Urteil gründet sich vorwiegend auf dieses Bewusstsein und Anpassung an die Kultur; es kann daher nur von jenen abgegeben werden, die in dieser Kultur bereits fest verankert sind.

inhalt

Es gibt konsistente Muster bei der Art und Weise, wie die Hackerkultur Beiträge bewertet und durch Ansehen würdigt. Es ist nicht weiter schwierig, folgende Regeln zu beobachten:

1. Wenn meine Software den von mir geweckten Erwartungen nicht entsprechen kann, ist sie nichts wert -- egal, wie clever und originell sie ist.

Beachten Sie die Formulierung "geweckte Erwartungen". Diese Regel verlangt keine Perfektion; Beta- und experimentelle Software darf Bugs haben. Die Regel verlangt, dass der Benutzer aus der Darstellung der Entwickler das Risiko genau abschätzen können muss, das die Verwendung der Software im augenblicklichlichen Projektstadium mit sich bringt.

Diese Regel beruht auf dem Umstand, dass Open Source-Software für lange Zeiträme im Betastadium bleibt und nicht einmal 1.0 erreicht, bevor die Entwickler nicht ganz sicher sind, dass sie zu vielen keinen Überraschungen führt. In der Closed Source-Welt bedeutet "1.0" meistens: "Ganz behutsam verwenden, und nur, wenn Sie versierter Anwender sind"; in der Open Source-Welt kann man das mehr als "Die Entwickler sind bereit, ihren guten Ruf darauf zu verwetten" sehen.

2. Software, die die Noosphere erweitert, ist besser als Software, die existierende Funktionalität wiederholt.

Die naive Art, diesen Grundsatz darzustellen war und ist: Neue Software ist besser als ein Aufguss schon bestehender. So einfach ist das aber nicht. Die Funktionen existierender Closed Source-Software zählen als neue Software, wenn man dadurch ein geschlossenes Protokoll oder Format aufbricht und dadurch das Territorium neu zugänglich macht.

Daher ist beispielsweise eines der prestigeträchtigsten Projekte in der augenblicklichen Open Source-Welt Samba -- der Code, der es Unix-Maschinen gestattet, als Klienten oder Server zu Microsofts proprietärem SMB File Sharing Protocol aufzutreten. Die darin enthaltene kreative Arbeit ist gering, es ist zur Gänze mehr ein Belang der Entzifferung und des Clonens der von Microsoft geschaffenen Details. Trotzdem werden die Mitglieder der Samba-Gruppe als Helden gesehen, weil sie Microsofts Zielsetzung unterminiert haben, die gesamte Benutzerpopulation in einem großen Bereich der Noosphere einzusperren.

3. Software, die in eine bedeutende Distribution übernommen wird, ist besser als solche, die das nicht schafft. Software, die von allen bedeutenden Distributionen übernommen wird, genießt das höchste Ansehen.

Zu den bedeutenden Distributionen gehören dabei nicht nur die großen Linux-Distributionen wie Red Hat, Debian, Caldera und S.u.S.E., sondern auch andere Kollektionen, die selbst einen Ruf zu verlieren haben und daher für Qualität bürgen -- wie etwa die BSD- oder Free Software Foundation Source Collections.

4. Verwendung ist die ehrlichste Form der Anerkennung -- und Category Killers gelten mehr als austauschbare Abklatsche.

Dem Urteil anderer zu vertrauen ist Vorraussetzung für den Prozess der Peer Review. Dieses Vertrauen ist notwendig, weil niemand Zeit hat, das ganze Angebot zu sichten und zu bewerten. So ist eine breite Basis von Anwendern für die Etablierung der Anerkennung besser als ein schmale Basis.

Wer seine Sache so gut gemacht hat, dass sich niemand mehr um eine Alternative kümmert, erntet damit gewaltige Anerkennung. Die maximale Reputation stammt aus Arbeit, die extrem populär ist, einen Categorie Killer darstellt, originell und in allen bedeutenden Distributionen enthalten ist. Leute, die das mehr als einmal geschafft haben, werden halbscherzend als "Halbgötter" bezeichnet.

5. Fortgesetzte Mühe mit harter, langweiliger Arbeit (wie Debugging oder Schreiben von Dokumentation) ist lobenswerter als sich die Rosinen (leichte und lustige Hacks) herauszupicken

Diese Norm ist die Art, wie die Gemeinde die Erledigung notwendiger Aufgaben belohnt, denen Hacker nicht ohne weiteres nachkommen. Zu einem gewissen Grad steht sie in Widerspruch zu

6. Nichttriviale Erweiterungen der Funktion sind besser als Low Level Patches und Debugging.

Das scheint so zu funktionieren, dass bei einzeln gebotenen Leistungen das Hinzufügen eines Features mehr gilt als das Beheben eines Programmierfehlers -- es sei denn, der Fehler ist extrem heimtückisch oder versteckt, so dass die Behebung eine Demonstration ungewöhnlicher Fertigkeiten oder Findigkeit ist. Wenn dieses Verhalten aber über einen längeren Zeitraum gezeigt wird, kommt die Person durch Befassen und Beheben gewöhnlicher Bugs in den Genuss höheren Ansehens als jemand, der die gleiche Mühe auf das Hinzufügen von leicht codierbaren Features investiert hat.

Ein Leser dieses Papiers wies darauf hin, dass diese Regeln in interessanter Weise miteinander in Beziehung stehen und interagieren, und nicht immer den höchsten Nutzen am höchsten bewerten. Fragen Sie einen Hacker, was ihn eher bekannt machen wird: ein brandneues Tool oder Erweiterungen zu einem Tool anderer, und die Antwort "brandneues Tool" wird angezweifelt werden. Fragt man aber nach
a) einem brandneuen Tool, das nur wenige male pro Tag vom Betriebssystem unsichtbar verwendet wird, aber schnell zu einem Category Killer wird
versus
b) mehreren Erweiterungen eines existierenden Tools, die weder neuartig noch Categorien Killer sind, aber jeden Tag von einer großen Zahl von Benutzern verwendet werden
dann wird man wahrscheinlich nach einigem Zögern als Antwort (a) erhalten. Diese Alernativen sind aber fast gleichwertig.

Der besagte Leser gab als Beispiel für (a) und (b) mein fetchmail und meine vielen Emacs-Erweiterungen an (wie etwa vc.el und gud.el. Er liegt damit tatsächlich richtig; ich werde wahrscheinlich eher als "Autor von fetchmail" bezeichnet als als "Autor einer Schiffsladung von Emacs-Modes", und das, obwohl im Laufe der Zeit letzteres einen höheren Gebrauchswert hat.

Was hier vielleicht stattfindet, ist einfach, dass die Arbeit an einer neuartigen "Markenidentität" mehr beachtet wird als Arbeit, die um eine existierende "Marke" angesammelt wird. Weitere Untersuchungen dieser Regeln, und was sie uns über das Bewertungssystem der Hackerkultur verraten, wären ein guter Gegenstand für weitere Nachforschungen.

inhalt

Um die Ursachen und Konsequenzen der Lockeschen Sitten um Eigentum zu verstehen, hilft es, sie aus einem weiteren Blickwinkel zu betrachten: jenem der Verhaltensforschung, speziell jenem Teilgebiet, das die Ethologie um Territorium behandelt.

Eigentum ist eine Abstraktion von Tierverhalten bei Auseinandersetzungen um ein Revier, das entwickelt wurde, um Gewalt innerhalb der Gattung zu reduzieren. Durch Markieren der Grenzen und Respektieren der Grenzen anderer verringert ein Wolf sein Risiko, in einem Kampf geschwächt oder getötet zu werden und ihn so bei der Reproduktion weniger erfolgreich zu machen. Ähnlich ist es bei der Anerkennung von Eigentum in der menschlichen Gesellschaft. Seine Aufgabe ist es, zwischenmenschliche Konflikte zu reduzieren, indem es Grenzen schafft, die friedliches Verhalten klar von Aggression abheben.

Es ist in manchen Kreisen modisch, menschliches Eigentum als willkürliche soziale Konvention zu sehen, aber das ist grundsätzlich falsch. Jeder, der schon einmal einen Hund gehabt hat, der Fremde anbellt, die dem Revier des Eigentümers zu nahe kamen, hat die unmittelbare Verwandtschaft zwischen der Territorialität im Tier- und Menschenreich eindringlich erfahren können. Unsere domestizierten Cousins des Wolfes wissen instinktiv, dass Grundbesitz mehr ist als ein bloßes Spiel oder eine bloße Konvention (was sie klüger macht als so manchen menschlichen Politologen).

Das Reklamieren von Grundbesitz (wie das Markieren eines Reviers) ist ein deklarativer Akt, ein Weg, zu erklären, welche Grenzen verteidigt werden. Die Unterstützung einer solchen Erklärung durch die Gemeinde ist ein Weg, Reibungen zu minimieren und kooperatives Verhalten zu maximieren. Diese Dinge bleiben auch dann stichhaltig, wenn die Reklamation aus nicht mehr besteht als einem Zaun oder dem Gebell eines Hundes, und sogar dann noch, wenn sie nicht mehr Stofflichkeit haben als der Name des Betreuers in einer README-Datei. Sie bleiben eine Abstraktion von Territorialität und basieren (wie andere Formen von Besitz) auf den Instinkten, die evolviert wurden, um die Lösung von Konflikten zu unterstützen.

Diese ethologische Analyse mag zunächst sehr abstrakt erscheinen und in keinem offensichtlichen Bezug zum Verhalten von Hackern stehen, hat aber einige wichtige Konsequenzen. Die eine ist der Wert für die Erklärung der Popularität von World Wide Web Sites, besonders für den Umstand, dass Open Source-Projekte mit Websites "realer" und substantieller erscheinen als jene ohne.

Objektiv betrachtet ist das nicht sehr plausibel. Verglichen mit dem Aufwand, den die Gründung und Wartung eines auch noch so kleinen Programmes bedeutet, ist die Einrichtung einer Webseite sehr leicht. Daher ist nicht ersichtlich, warum eine Webseite für ein Zeichen von Substanz oder ungewöhnlichen Aufwand stehen soll.

Auch ist es nicht so, dass die funktionale Charakteristik des Web selbst als ausreichende Erklärung herhalten kann. Die Kommunikation einer Webseite kann genauso gut oder besser durch eine Kombination aus FTP-Site, Mailing List und Usenet Postings geleistet werden. Tatsächlich ist es für die alltägliche Kommunikation über ein Projekt sehr ungewöhnlich, über eine Webseite abgewickelt zu werden, statt via Mailing List oder Newsgroup. Warum sind Webseiten dann als Heimat für Projekte so populär?

Die Metapher, die der Begriff "Home Page" impliziert, bietet einen wichtigen Hinweis. Während die Gründung eines Open Source-Projekts eine Reklamation von Territorium in der Noosphere ist (und durch die Sitten auch als solche anerkannt wird), ist das in psychologischer Hinsicht nicht gerade überzeugend. Software hat schließlich keine natürliche Heimat und ist innerhalb eines Augenblicks kopierbar. Man kann sie in unsere instinktive Auffassung von "Eigentum" und "Territorium" einbauen, aber nur durch etwas mentalen Aufwand

Eine Projekt-Homepage konkretisiert das abstrakte Homesteading im Reich der möglichen Programme durch Ausdrücken des Anspruchs im räumlicher organisierten Reich des World Wide Webs. Der Abstieg aus der Noosphere in den "Cyberspace" bringt uns zwar noch nicht in die konkrete Welt der Zäune und bellenden Hunde, verankert aber den abstrakten Gebietsanspruch wenigstens etwas fester in unser aller instinktiven Auffassung von Territorium. Und das ist der Grund, aus dem Projekte mit Webseiten "realer" erscheinen.

Dieser Punkt wird durch Hyperlinks und die Existenz guter Suchmaschinen noch erhärtet. Ein Projekt mit einer Webseite wird viel eher von jemandem wahrgenommen, der die noosphärische Umgebung des Projekts erforscht; andere können hinlinken, Suchmaschinen können es finden. Eine Webseite ist daher eine bessere Werbung, eine überzeugendere Reklamation von Territorium und ein deutlicherer deklarativer Akt.

Diese ethologische Analyse ermuntert uns auch dazu, die Mechanismen für die Bereinigung von Konflikten in der Open Source-Kultur näher zu untersuchen. Sie führt uns zu der Erwartung, dass die Gebräche der Eigentümerschaft neben der Maximierung der Reputationsanreize auch bei der Lösung von Konflikten eine Rolle spielen sollten.

inhalt

An Konflikten bei Open Source-Software können wir vier bedeutende Punkte ausfindig machen:

• Wer trifft verbindliche Entscheidungen über ein Projekt?
• Wer bekommt wofür Würdigung oder Schuld?
• Wer reduziert doppelt geleisteten Aufwand und verhindert abtrünnige Versionen, die das Verfolgen und Beheben von Bugs verkomplizieren?
• Was ist, technisch gesehen, das Richtige?

Wenn wir einen zweiten Blick auf das Thema "Was ist das Richtige" werfen, verschwindet es in der Regel. Für jede solche Frage gibt es entweder objektive Kriterien um sie in für alle beteiligten in befriedigender Weise zu entscheiden, oder es gibt sie nicht. Wenn es sie gibt, ist das Spiel vorbei und jeder gewinnt. Wenn es sie nicht gibt, reduziert sich die Frage auf "Wer trifft die Entscheidung?"

Dem entsprechend sind die drei Problemkreise, mit denen sich eine Theorie der Konfliktbereinigung befassen muss, diese:

1. Wer hat Design-Entscheidungen zu treffen?
2. Wie entscheidet man, welche Beitragenden wofür in welcher Weise Anerkennung bekommen?
3. Wie hält man eine Projektgruppe und das Produkt davon ab, in mehrere Versionen zu verzweigen?

Die Rolle, die die Gebräuche um Eigentümerschaft bei der Lösung von (1) und (3) spielen, ist klar. Die Sitten bestätigen den Eigentümern das Recht, verbindliche Entscheidungen zu treffen. Wir haben schon weiter oben gesehen, dass die Sitten auch starken Druck gegen Verdünnung des Eigentums durch Forking ausüben.

Es ist lehrreich, im Auge zu behalten, dass diese Sitten sogar dann Sinn ergeben, wenn jemand das Spiel um Reputation außer Acht lässt und aus dem rein "handwerklichen" Blickwinkel der Hackerkultur untersucht. Bei dieser Ansicht haben diese Sitten weniger mit der Verdünnung der Reputationsanreize zu tun als mehr mit dem Schutz des Rechts des Handwerkers, seine Vision auf dem von ihm gewählten Weg zu verwirklichen.

Das Handwerkermodell ist aber nicht ausreichend, um die Hackersitten für (2) zu erklären. Wer wofür Anerkennung bekommen soll -- als reiner Handwerker, der vom Spiel um Reputation nicht weiter beeindruckt ist, bin ich dadurch nicht motiviert. Um das zu analysieren, müssen wir die Lockesche Theorie noch einen Schritt weiter nehmen und Konflikte und die Wirkung des Eigentumsrechts untersuchen, die innerhalb von Projekten ablaufen -- und auch die zwischen Projekten.

inhalt

Der triviale Fall ist der eines Projekts mit einem einzigen Betreuer/Eigentümer. In diesem Fall ist kein Konflikt möglich. Der Eigentümer trifft alle Entscheidungen und sammelt alle Anerkennung und alle Vorwürfe. Die einzigen denkbaren Konflikte betreffen Belange der Nachfolge -- wer der neue Eigentümer werden soll, wenn der alte verschwindet oder das Interesse verliert. Es ist auch im Interesse der Gemeinde, dass, gemäß (3), Forking verhindert wird. Diese Anliegen werden durch die kulturelle Norm widergespiegelt, dass der Betreuer/Eigentümer die Eigentümerschaft öffentlich an jemand anderen weitergeben soll, wenn er oder sie das Projekt nicht weiter betreuen kann.

Der einfachste nicht-triviale Fall ist der eines Projekts mit mehreren Betreuern, die unter einem einzigen "wohlwohllenden Diktator" zusammenarbeiten, dem das Projekt gehört. Die Gebräuche favorisieren dieses Modell für Gruppenprojekte; wie sich gezeigt hat, funktoniert das für Projekte, die so groß sind wie der Linux-Kernel oder Emacs. Sie lösen auch das Problem "Wer entscheidet?" in einer Art, die nicht schlechter ist als jegliche Alternative.

Typischerweise evolviert so ein Gruppenprojekt um einen wohlwollenden Diktator aus einem Unternehmen eines Einzelnen, das dann Beitragende in seinen Bann zieht. Sogar wenn der Eigentümer der Diktator bleibt, führt es eine neue Ebene für mögliche Dispute darüber ein, wer die Anerkennung für welche Teile des Projekts erhält.

In dieser Situation üben die Gebräuche Druck auf den Eigentümer/Diktator aus, die Bedeutung der Beitragenden fair anzuerkennen (durch entsprechende Erwähnungen im README oder den History-Dateien). Nach den Begriffen des Lockeschen Modells der Eigentümerschaft bedeutet das, dass man durch Beitragen zu einem Projekt Teile des Reputationsgewinns für sich in Anspruch nehmen kann (sei er positiv oder negativ).

Geht man dieser Logik weiter nach, sieht man, dass ein wohlwollender Diktator sein ganzes Projekt nicht wirklich immer alleine besitzt. Obowhl er das Recht hat, verbindliche Entscheidungen zu treffen, tauscht er eigentlich Anteile am gesamten Ansehen des Projekts gegen die Arbeit anderer ein. Die Analogie mit dem Aufteilen der Ernte auf einer Farm ist fast unwiderstehlich, abgesehen von dem Umstand, dass ein Teilnehmer weiterhin in der Liste der Entwickler genannt wird, auch wenn er nicht mehr aktiv ist.

Wenn Projekte um einen wohlwollenden Diktator herum wachsen, tendieren sie zur Ausbildung von zwei Schichten von Entwicklern; gewöhnliche Beitragende und Mitentwickler. Ein typischer Pfad zur Mitentwicklerschaft ist es, Verantwortung für einen größeren Anteil des Projekts zu übernehmen. Ein weiterer ist der, die Rolle eines "erhabenen Reparierers" (Lord Higher Fixer) einzunehmen, der viele Bugs beschreibt und behebt. Auf diesen oder anderen Wegen treten Mitentwickler als die Beitragenden auf, die den bedeutenden und fortgesetzten Aufwand des Projekts erbringen.

Die Rolle eines solchen Sub-Eigentümers ist für unsere Analyse besonders wichtig und verdient genauere Untersuchung. Hacker sagen gern, dass "Autorität der Verantwortung folgt". Ein Mitentwickler, der die Verantwortung für die Wartung eines gegebenen Subsystems übernimmt, bekommt sowohl die Kontrolle über die Implementation dieses Subsystems als auch die Schnittstellen zum Rest des Projekts. Er ist nur den Korrekturen des Projektleiters unterworfen (der als Architekt auftritt). Wir beobachten, dass diese Regel innerhalb eines Projekts eigentlich abgegrenzte Gebiete nach dem Lockeschen Modell erzeugt und auch die selbe Rolle zur Vorbeugung von Konflikten spielt.

Nach diesen Gebräuchen erwartet man vom "Diktator" oder Projektleiter eines Projekts mit Mitentwicklern, seine Entscheidungen nicht an den Mitentwicklern vorbei zu treffen. Das gilt besonders für Entscheidungen, die ein Subsystem betreffen, das einem Mitentwickler "gehört" (also, in das er Zeit investiert hat und für das er Verantwortung übernommen hat). Ein weiser Manager, der die Funktion der projektinternen Eigentumsgrenzen anerkennt, wird nicht leichtfertig mit den Entscheidungen eines Eigentümers eines Subsystems kollidieren.

Einige sehr große Projekte verwerfen das Modell des wohlwollenden Diktators zur Gänze. Eine Art, es anders zu machen, ist, die Mitentwickler zu einem wählenden Komittee zu machen (ein Beispiel dafür ist die Apache-Gruppe). Ein anderer ist der einer rotierenden Diktatur, in der die Leitung gelegentlich innerhalb eines Zirkels von Mitenwicklern von einem Mitglied einem anderen übertragen wird (die perl-Entwickler organisieren sich in solcher Weise).

So komplizierte Arrangements werden aber allgemein als instabil und schwierig angesehen. Ganz klar ist diese Ansicht eine Funktion der bekannten Gefahren des Designs-by-Committee und Komittees selbst; diese Probleme versteht die Hackerkultur sehr gut und sehr bewusst. Ich glaube aber, dass einige der instinktiven Abneigungen der Hacker gegenüber Komittees und wechselnder Projektleitung von der Schwierigkeit her stammen, sie in das unbewusste Lockesche Modell der Eigentümerschaft einzugliedern, das Hacker für ihre simpleren Fälle verwenden. Es ist bei so komplexen Organisationen problematisch, die Eigentümerschaft und Reputationserträge zu verbuchen. Man kann die internen Abgrenzungen nur schwer ausmachen, daher sind Konflikte nicht so leicht zu vermeiden, es sei denn, die Gruppe erfreut sich eines außergewöhnlich hohen Maßes an Harmonie und Vertrauen.

inhalt

Wir haben bereits gesehen, dass es innerhalb von Projekten immer komplexer werdende Rollen gibt, die sich durch die Aufteilung von Designautorität und Eigentumsrechten ausdrücken. Obwohl das ein effizienter Weg ist, um Anreize zu verteilen, verdünnt es auch den Einfluss des Projektleiters -- am bedeutendsten ist dabei der geringere Einfluss des Projektleiters bei der Vermeidung von Konflikten.

Obwohl technische Streitigkeiten um das Design vielleicht wie das offensichtlichste Risiko zu zermürbenden Konflikten aussehen, sind sie aber nur selten die Ursache für ernste Auseinandersetzungen. Man kann sie relativ leicht durch die territorialen Regeln beilegen, nach denen die Autorität der Verantwortung folgt.

Ein weiterer Weg zur Lösung von Konflikten ist das Prinzip der Seniorität -- wenn zwei Beitragende oder Gruppen von Beitragenden einen Disput haben und dieser Disput nicht objektiv entschieden werden kann und keine der beiden Parteien das Territorium des Disputs besitzt, dann wird zu Gunsten der Seite entschieden, die mehr Arbeit in das Projekt als Ganzes investiert hat (das ist also jene, die mehr Eigentumsrechte am ganzen Projekt hat).

(Dementsprechend verliert die Seite mit dem geringeren Investitionen. Es ist interessant, dass viele relationale Datenbanken die selbe Heuristik verwenden, um Deadlocks aufzulösen. Wenn zwei Threads einander über bestimmten Ressourcen sperren, wird die Seite terminiert, die weniger in die augenblickliche Transaktion investiert hat. Das bedeutet für gewöhnlich, dass die am längsten laufende Transaktion gewinnt.)

Diese Regeln reichen im allgemeinen aus, um die meisten Projektstreitigkeiten zu schlichten. Falls nicht, kann der Projektleiter in fast allen Fällen ein Urteil aussprechen und die Sache entscheiden. Dispute, die alle diese Filter überleben, sind sehr selten.

Konflikte treten im allgemeinen überhaupt erst dann auf, wenn diese beiden Kriterien ("Autorität folgt der Verantwortung" und "Seniorität gewinnt") in verschiedene Richtungen zeigen und der Projektleiter schwach oder abwesend ist. Der offensichtlichste Fall dieser Kombination von Umständen ist ein Disput, der auf das Verschwinden der Projektleitung folgt. Ich war einmal in einem derartigen Gefecht; es war hässlich, schmerzhaft, langwierig und wurde erst gelöst, als die Beteiligten erschöpft genug waren, um die Projektleitung an eine außenstehende Person zu übergeben. Ich hoffe aufrichtig, nie wieder auch nur in die Nähe einer so üblen Sache zu kommen.

Letzten Endes beruhen alle diese Mechanismen zur Konfliktlösung auf der breiten Bereitschaft der Hackergemeinde, sie auch zu exekutieren. Die einzigen verfügbaren Mittel, um ihnen Nachdruck zu verleihen, sind "Flaming" und Ächtung -- öffentliches Anprangern derjenigen, die mit den Sitten brechen und Verweigerung der Zusammenarbeit mit ihnen.

inhalt

Eine frühe Version dieses Papiers warf folgende Frage zur weiteren Untersuchung auf: wie informiert und instruiert die Gemeinde ihre Mitglieder über ihre Sitten und Gebräuche? Sind diese Sitten und Gebräuche auf halbbewusster Ebene selbstverständlich oder selbstorganisierend? Werden sie durch Beispiele gelehrt? Oder durch ausdrückliche Anweisungen?

Die Praxis der ausdrücklichen Unterweisung ist offensichtlich selten, wenn auch nur aus dem Grund, dass bisher nur wenige explizite Beschreibungen der kulturellen Normen existierten.

Viele Normen werden durch Beispiel gelehrt. Um einen sehr einfachen Fall zu zitieren, gibt es die Norm, dass jede Software-Distribution eine Datei namens README oder READ.ME enthalten soll, die als erste Anlaufstelle für Instruktionen zur Durchsicht der Distribution dient. Diese Konvention ist zumindest seit den frühen 80ern gut eingeführt, und wurde sogar gelegentlich niedergeschrieben. Für gewöhnlich schließt man dieses Vorgehen selbst aus dem Befassen mit vielen Distributionen.

Auf der anderen Seite sind einige Hackersitten selbstorganisierend, sobald man ein elementares (möglicherweise unbewusstes) Verständnis des Spiels um Reputation erworben hat. Die meisten Hacker mussten niemals in die drei in Abschnitt 3 aufgeführten Tabus eingweiht werden oder würden wenigstens auf Anfrage angeben, dass sie selbstverständlich seien und nicht unterrichtet werden müssten. Dieses Phänomen lädt zu eingehenderer Untersuchung ein -- und vielleicht können wir dadurch eine Erklärung dafür finden, wie Hacker ihre Kenntnisse über die Kultur erlangen.

Viele Kulturen verwenden versteckte Hinweise (präziser ausgedrückt: "Geheimnisse" im religiös/mystischen Sinn) als Akulturationsmechanismus. Diese Hinweise sind Geheimnisse, die Außenstehenden nicht offenbart werden, von denen aber erwartet wird, dass sie vom frischen Aspiranten entdeckt oder abgeleitet werden. Um als Insider akzeptiert zu werden, muss man demonstrieren, dass man das Geheimnis sowohl versteht als auch auf durch die Kultur anerkanntem Weg erworben hat.

Die Hackerkultur macht ungewöhnlich bewussten und ausgiebigen Gebrauch von solchen verborgenen Hinweisen und Tests. Wir können diesen Prozess auf drei Ebenen wirken sehen:

• Password-ähnliche Geheimnisse. Als ein Beispiel kann man die USENET-News Group alt.sysadmin.recovery nennen, die ein sehr offensichtliches solches Geheimnis hat. Man kann nichts posten, ohne das Password zu kennen -- und es zu kennen wird als Zeichen dafür gesehen, dass man der Teilnahme würdig ist. Die Insider haben ein starkes Tabu gegen das Offenbaren dieses Geheimnisses.
• Die Forderung, für die Initiierung bestimmte technische Geheimnisse zu kennen. Man muss umfangreiche technische Kenntnisse besitzen, bevor man Geschenke von Wert beisteuern kann (zumindestens eine der bedeutenden Programmiersprachen muss man beherrschen). Diese Anforderung funktioniert im Großen so wie die versteckten Hinweise im Kleinen. Sie filtern Qualifikationen heraus (wie etwa die Fähigkeit zu abstraktem Denken, Hartnäckigkeit und geistiger Flexibilität), die für das Funktionieren innerhalb der Kultur notwendig sind.
• Geheimnisse des sozialen Kontextes. Jemand tritt mit der Kultur in Beziehung, indem er an bestimmten Projekten teilnimmt. Jedes Projekt ist ein lebender sozialer Kontext von Hackern, die der Eleve erforschen und sozial und technisch verstehen muss. (Konkret bedeutet das üblicherweise: Lesen der Webseite des Projekts und der e-Mail-Archive). Durch diese Projektgruppen erlernen Eleven das als Beispiel dienende Verhalten der Hacker-Veteranen.

Beim Erwerb dieser Geheimnisse erhält der Aspirant kontextuelle Kenntnisse, die nach einiger Zeit die drei Tabus und andere Sitten "selbstverständlich" erscheinen lassen.

Nur zufälligerweise könnte man hier argumentieren, dass die Struktur der Geschenkkultur der Hacker selbst das zentrale Geheimnis ist. Man ist nicht Teil der Kultur (konkret bedeutet das: niemand wird einen "Hacker" nennen), bis man demonstriert hat, das Spiel um Reputation, seine impliziten Tabus und Gebräuche bis in die Knochen verstanden zu haben. Das ist aber trivial; alle Kulturen verlangen von Aspiranten so ein Verständnis. Darüber hinaus zeigt die Hackerkultur keine besondere Sehnsucht danach, ihre interne Logik und Gebräuche geheim zu halten -- wenigstens wurde ich noch für deren Offenbarung "geflamed".

Leser dieses Papiers (zu viele, um sie alle zu nennen) wiesen darauf hin, dass die Gebräuche der Eigentümerschaft der Hacker in engem Zusammenhang zu den Praktiken der akademischen Welt zu stehen scheinen (oder direkt davon abstammen), besonders wenn man die Gemeinde der wissenschaftlichen Forschung betrachtet. Diese Forschergemeinde hat ähnliche Probleme beim Ausbeuten eines Territoriums von potentiell fruchtbaren Ideen und zeigt ganz ähnliche adaptive Lösungen für diese Probleme.

Da viele Hacker in der akademischen Welt geprägt wurden (es ist üblich, mit dem Hacken auf dem College anzufangen), ist das Ausmaß der Ähnlichkeiten zur Hackerkultur von mehr als nur oberflächlichem Belang; man muss verstehen, wie die Gebräuche angewendet werden.

Offensichtliche Parallelen zur Geschenkkultur der Hacker, wie ich sie darstelle, gibt es in der akademischen Welt sehr viele. Sobald ein Forscher sein Amt erhält, braucht er sich um sein Überleben keine Sorgen mehr zu machen (Tatsächlich kann die Auffassung von einer Festanstellung an einer Universität bis zu einer früheren Geschenkkultur zurückverfolgt werden, in der "Naturphilosophen" meistens reiche Adelige waren, die ihren Forschungen viel Zeit widmen konnten). Beim Wegfall der Belange des Broterwerbs wird das Erhöhen der Reputation die treibende Kraft, was zum Mitteilen neuer Ideen und Resultate durch Fachblätter und andere Medien ermuntert. Diese Einrichtung ist durchaus sinnvoll, da die wissenschaftliche Forschung wie die Hackerkultur auf der Idee beruht, dass die Teilnehmer "auf den Schultern von Riesen stehen", also nicht immer wieder von vorne anfangen müssen, um die grundlegenden Prinzipien selbst zu erarbeiten.

Einige gingen so weit, zu erklären, dass die Hackerkultur überhaupt ein bloßer Abklatsch der Kultur der wissenschaftlichen Gemeinde sei, die in den allermeisten Fällen von individuellen Hackern absorbiert wurde. Das überstrapaziert aber das Konzept, da die Hackergebräuche auch problemlos von intelligenten Hauptschülern angenommen wurden.

Es gibt hier eine interessantere Möglichkeit. Ich habe den Verdacht, dass die akademische Welt und die Hackerkultur adaptive Verhaltensmuster nicht gemeinsam haben, weil sie genetisch miteinander verwandt sind, sondern weil beide die für ihre Belange optimale soziale Organisation um die Naturgesetze und das menschliche Verhalten herum evolviert haben. Das Urteil der Geschichte scheint zu sein, dass freie Marktwirtschaft der optimale Weg für die Kooperation in ökonomisch effektiver Weise ist; vielleicht ist auf ganz ähnliche Art eine Geschenkkultur, die um Reputation spielt, der optimale Weg für die Kooperation zum Hervorbringen und Prüfen hochwertiger kreativer Arbeit.

Wenn dieser Punkt stichhaltig ist, dann ist er von mehr als nur akademischen Interesse. Er legt eine der Spekulationen in Die Kathedrale und der Basar nahe -- dass der industriell-kapitalistische Modus der Softwareproduktion von dem Zeitpunkt an dem Untergang geweiht war, zu dem der Kapitalismus für viele Programmierer genug Wohlstand erzeugt hatte, um an einer Geschenkkultur teilnehmen zu können.

inhalt

Wir haben die Sitten untersucht, die Eigentümerschaft und Einfluss auf Open Source-Software regeln. Wir haben gesehen, wie sie eine zu Grunde liegende Theorie der Besitzrechte impliziert, die mit der Lockeschen Theorie des Grundbesitzes homolog ist. In einer Analyse setzten wir diese Überlegungen zur Auffassung von der Hackerkultur als einer Geschenkkultur in Beziehung, in der die Teilnehmer durch Investition von Zeit, Energie und Kreativität um Prestige wetteifern. Wir haben die Implikationen dieser Analyse untersucht, um Wege zur Konfliktlösung innerhalb der Kultur zu finden.

Die nächste logische Frage ist: "Warum spielt das alles überhaupt eine Rolle?" Hacker haben diese Sitten ohne bewusste Analyse entwickelt und sind ihnen auch (bis jetzt wenigstens) ohne bewusste Analyse gefolgt. Es ist nicht ohne weiteres klar, dass uns die Analyse irgendetwas praktisch Verwertbares gebracht hat -- außer, wir vollziehen den Schritt von der bloßen Beschreibung hin zur ausdrücklichen Vorschrift und finden Wege zur Verbesserung der Funktionsweise dieser Sitten.

Wir haben in der Theorie des Grundbesitzes in der anglo-amerikanischen Rechtsauffassung eine sehr ähnliche logische Analogie zu den Gebräuchen der Hacker gefunden. Historisch betrachtet [Miller] verbesserten die europäischen Kulturen ihre Systeme zur Lösung von Konflikten durch den Schritt von den unausgesprochenen, halbbewussten Sitten zu einem Codex von Gesetzen, der von weisen Stammesältesten auswendig gelernt und schließlich niedergeschrieben wurde.

Mit dem Wachsen unserer Population und zunehmender Schwierigkeit der Akulturation neuer Mitglieder ist es vielleicht an der Zeit, dass die Hackerkultur etwas Analoges vollzieht -- einen geschriebenen Codex von guten Praktiken zu entwickeln, um die verschiedenen Arten von Disput zu lösen, die in Verbindung mit einem Open Source-Projekt entstehen können -- und auch eine Tradition, nach der die dienstälteren Mitglieder der Gemeinde bei Konflikten vermitteln können.

Die Analyse in diesem Papier skizziert, wie ein solcher Codex aussehen könnte und spricht aus, was vorher nur stillschweigend vermittelt und vollzogen wurde. Kein derartiger Codex kann oktroiert werden, er müsste von den Gründern und Eigentümern individueller Projekte freiwillig angenommen werden. Auch kann ein solcher Codex nicht vollkommen starr sein, da sich die Kräfte und Sachzwänge der Kultur wahrscheinlich im Laufe der Zeit verändern werden. Schließlich müsste der Codex für eine wirkungsvolle Exekution den breiten Konsens der Hackergemeinde widerspiegeln.

Ich habe mit der Arbeit an einem solchen Codex schon begonnen, der Arbeitstitel lautet "Malvern Protocol" -- nach der kleinen Stadt, in der ich lebe. Wenn die allgemeine Analyse dieses Papiers ausreichende Akzeptanz findet, werde ich das Malvern Protocol als Modell zur Beilegung von Konflikten veröffentlichen. Interessierte, die zur Entwicklung beitragen oder Kritik üben wollen, sind eingeladen, mich per e-Mail (esr@thyrsus.com) zu kontaktieren.

inhalt

Die Kultur (und ich) haben nur ein wackeliges Verständnis großer Projekte, die nicht dem Modell des wohlwollenden Diktators folgen. Die meisten solcher Projekte scheitern. Nur wenige werden spektakulär erfolgreich und wichtig (Perl, Apache, KDE). Niemand versteht, welcher Unterschied hier entscheidend ist. (Es gibt die vage Vorstellung, dass jedes derartige Projekt sui generis ist, und mit der Gruppendynamik seiner besonderen Mitglieder steht und fällt. Ist das richtig oder gibt es replizierbare Strategien, die eine Gruppe verfolgen kann?

inhalt

[Miller] Miller, William Ian; Bloodtaking and Peacemaking: Feud, Law, and Society in Saga Iceland; University of Chicago Press 1990, ISBN 0-226-52680-1. Eine faszinierende Studie des isländischen Stammesgesetzes, die sowohl die Ursprünge der Lockeschen Theorie des Grundbesitzes beleuchtet, als auch die späteren Phasen eines historischen Prozesses, bei dem aus Gebräuchen erst Gewohnheitsrechte und schließlich geschriebene Gesetze wurden.

[Mal] Malaclypse the Younger; Principia Discordia, or How I Found Goddess and What I Did To Her When I Found Her; Loompanics, ISBN 1-55950-040-9. Im Discordianismus lässt sich viel lehrreicher Quatsch finden. Darunter ist auch das "snafu-Prinzip", das eine recht treffende Analyse darüber enthät, warum Befehlshierarchien nicht gut skalieren. Es gibt auch eine HTML-Version am World Wide Web.

[BCT] J. Barkow, L. Cosmides, and J. Tooby (Eds.); The adapted mind: Evolutionary psychology and the generation of culture. New York: Oxford University Press 1992. Eine exzellente Einführung in die evolutionäre Psychologie. Einige der Papiere behandeln die drei Typen von Kulturen, die ich erörtere (Befehlshierarchie, Tauschwirtschaft, Geschenkkultur) und legen nahe, dass diese Verhaltensmuster sehr tief in die menschliche Psyche eingewoben sind.

[MHG] Goldhaber, Michael K.; The Attention Economy and the Net. Ich entdeckte dieses Papier nach Freigabe meiner Version 1.7. Es enthält einige offensichtliche Denkfehler (Goldhabers Argument der Nichtanwendbarkeit ökonomischer Betrachtungsweisen für Aufmerksamkeit hält einer genauen Untersuchung nicht stand), aber er hat einige komische und treffende Dinge über die Rolle zu sagen, die das Streben nach Aufmerksamkeit für organisierendes Verhalten spielt. Das Prestige oder Ansehen unter Gleichgesinnten, das ich hier diskutiert habe, kann sehr fruchtbar als Spezialfall von Aufmerksamkeit in Goldhabers Sinne aufgefasst werden.

[HH] Ich habe eine kurze Zusammenfassung der Geschichte der Hackerkulutr geschrieben: A Brief History Of Hackerdom. Das Buch, das die Geschichte des Hackertums wirklich gut schildert, muss erst noch geschrieben werden -- wahrscheinlich nicht von mir.

[N] Der Begriff "Noosphere" ("Noosphäre") ist ein obskurer Begriff von Kunst in der Philosophie. Wenn man mit der Orthographie peinlich korrekt sein will, sollte man eine Diarese über das zweite o setzen: "Noösphäre". Das Wort stammt von dem griechischen "nous" - Geist, Verstand. Es wurde von E. LeRoy in Les origines humaines et l'evolution de l'intelligence erfunden (Paris, 1928). Breit eingeführt wurde es dann vom russischen Biologen und Ökologie-Pionier Vladimir Ivanovich Vernadsky, (1863-1945), später vom jesuitischen Paläontologen und Philosophen Pierre Teilhard de Chardin (1881 - 1955). Heute wird der Begriff primär mit Chardins Theorie verbunden, nach der die zukünftige menschliche Evolution eine Form puren Geistes anstrebt und dann in einer Vereinigung mit dem höchsten Wesen kulminiert.

[DF] David Friedman, einer der bestechendsten und lesbarsten Denker der zeitgenössischen Volkswirtschaft, hat eine exzellente Zusammenfassung der Geschichte und Logik der Gesetze zum Schutz von geistigem Eigentum geschrieben. Ich empfehle sie jedem als Einstiegspunkt, der an dieser Materie interessiert ist.

[SP] Ein interessanter Unterschied zwischen den Linux- und BSD-Welten ist, dass der Linux-Kernel nie geforket wurde, der BSD-Kernel aber wenigstens dreimal. Was diesen Umstand interessant macht, ist die zentralisierte Struktur der BSD Group, die in gewisser Weise für klare Linien in der Autorität zu sorgen und Forking verhindern soll. Die Linux-Gemeinde, auf der anderen Seite, ist dezentralisiert, amorph und hat sieht keine derartigen Maßnahmen vor. Es ist anscheinend so, dass ein sehr offenes Projekt für Forking am wenigsten anfällig ist!

Henry Spencer <henry@spsystems.net> meint dazu, dass die Stabilität eines politischen Systems im allgemeinen umgekehrt proportional zur Höhe der Hürden ist, die man vor der Teilnahme am politischen Prozess überwinden muss. Seine Analyse ist es wert, hier zitiert zu werden:

"Eine der relativen Stärke einer offenen Demokratie sind die geringen Hürden, die potentielle Revolutionäre vorfinden, um ihre Ziele zu erreichen. Es ist in einer Demokratie einfacher, seine politischen Ziele auf den vom System vorgesehenen Wegen zu erreichen, als das System zu attackieren. Diese Stärke wird aber unterminiert, sobald etablierte Parteien zusammenarbeiten, um diese Hürden zu erhöhen und es so für kleine unzufriedene Gruppen schwieriger machen, irgendeinen Fortschritt in Richtung ihrer Anliegen zu sehen.

(Ein ähnliches Prinzip kann man auch in der Wirtschaft beobachten. Offene Märkte haben den schärfsten Wettbewerb, und im allgemeinen auch die besten und günstigsten Produkte. Aus diesem Grund ist es im besten Interesse der etablierten Firmen, den Eintritt in den Markt so schwierig wie möglich zu machen -- beispielsweise durch Überreden der Regierung zum Verlangen von aufwendigen RFI-Tests von Computern, oder durch Schaffen von "Konsens"-Standards, die so kompliziert sind, dass sie nicht von Grund auf neu implementiert werden können ohne gewaltige Ressourcen zu verschlingen. Die Märkte mit den höchsten Eintrittshürden sind auch am anfälligsten dafür, von Revolutionären unter Beschuss zu geraten (z. B. Internet und Justice Department vs. Bell System).

Ein offener Prozess mit geringen Einstiegshürden ermuntert zur Teilnahme statt zur Abspaltung, da man auch ohne die hohen Unkosten einer Sezession zu Resultaten kommen kann. Die Resultate sind vielleicht nicht so spektakulär wie die eines Bruchs mit dem System, kommen aber wesentlich günstiger. Die meisten Menschen sehen das als guten Tausch. (Als die spanische Regierung Francos Anti-Baskischen Gesetze zurücknahm und den baskischen Provinzen eigene Schulen und begrenzte lokale Autonomie anbot, verdunstete die baskische Separatistenbewegung praktisch über Nacht. Nur den Hardcore-Marxisten war das nicht genug.) "

[RP] Bei Rogue Patches gibt es einige Feinheiten. Man kann sie in "freundliche" und "unfreundliche" einteilen. Ein "freundlicher" Patch ist einer, der für das Zurückspeisen in die Hauptlinie unter Aufsicht des Projektbetreuers entworfen ist (egal, ob diese Eingliederung dann tatsächlich erfolgt oder nicht); ein "unfreundlicher" Patch aber soll dem Projekt eine neue Richtung geben, die der Betreuer nicht absegnet. Einige Projekte (darunter der Linux-Kernel) sehen freundliche Patches sehr gelassen und ermuntern sogar zur unabhängigen Verbreitung als Teil des Beta-Prozesses. Ein unfreundlicher Patch dagegen repräsentiert eine Entscheidung, die mit der des Betreuers in Wettbewerb tritt und ist eine ernste Angelegenheit. Die Wartung einer größeren Anzahl von unfreundlichen Patches führt oft zu Forking.

[LW] Ich stehe in der Schuld von Michael Funk <mwfunk@uncc.campus.mci.net>, der mich darauf hingewiesen hat, wie aufschlussreich die Gegenüberstellung der Hacker- und der Softwarepiratenkultur ist. Linus Walleij hat eine Analyse der kulturellen Dynamik gepostet, die von meiner verschieden ist (er beschreibt sie als eine Kultur der begrenzten Ressourcen): A Comment on `Warez D00dz' Culture

Diese Stichhaltigkeit dieser Gegenüberstellung hält möglicherweise nicht mehr lang. Der frühere Cracker Andrej Brandt <andy@pilgrim.cs.net.pl> ist der Ansicht, dass die Kultur der Cracker/Warez d00dz am Aussterben ist. Deren hellsten Köpfe und Projektleiter werden gerade von der Open Source-Welt assimiliert. Davon unabhängige Indizien könnte die bahnbrechende Aktion vom Juli 1999 liefern, bei der die Crackergruppe "Cult of the Dead Cow" ihr "Back Orifice 2000" zum Knacken der Microsoft Windows Security Tools unter der GPL veröffentlicht haben.

[HT] Nach den Maßstäben der Evolution könnte der Drang des versierten Handwerkers (so wie verinnerlichte Ethik) das Resultat des hohen Risikos und der hohen Kosten für Betrug sein. Evolutionäre Psychologen haben experimentell Indizien dafür gesammelt [BCT], dass die Menschen über einen neurologischen Apparat verfügen, der auf das Entdecken von sozialer Irreführung spezialisiert ist. Es ist klar, aus welchem Grund unsere Vorfahren nach ihrer Fähigkeit selektiert wurden, Mogelei als solche zu erkennen. Wenn jemand daher in den Ruf erstrebenswerter, aber teurer oder riskanter Charakterzüge kommen will, ist es für diesen jemand vielleicht besser, diese Züge tatsächlich zu haben als sei vorzutäuschen. ("Ehrlichkeit ist die beste Strategie").

Evolutionäre Psychologen haben nahegelegt, dass diese Überlegung das Phänomen der Wirtshausraufereien erklären könnte. Unter jungen geschlechtsreifen menschlichen Männchen ist die Reputation, "ein harter Knochen" zu sein, sowohl sozial als auch (sogar im heutigen von Feministinnen beeinflusstem Klima) sexuell nützlich. Diese Härte aber bloß vorzutäuschen ist extrem riskant; das negative Resultat einer Enttarnung kann einen in einer schlechteren Position zurücklassen, als man ohne die Reklamation dieses Charakterzugs geblieben wäre.

[MH] Eine genaue Zusammenfassung von Maslows Bedürfnispyramide und verwandter Themen findet sich am Web unter Maslow's Hierarchy of Needs

[DC]Die Forderung nach Demut von Führern mag eine allgemeinere Charakteristik von Geschenk- oder Überflusskulturen sein. David Christie <dc@netscape.com> berichtet von einer Reise über die äußeren Fidschiinseln:
"Bei den Dorfhäuptlingen der Fidschis beobachteten wir die gleiche Art von Selbstverharmlosung und unaufdringlichem Führungsstil, den Sie Open Source-Projektleitern zuschreiben. [...] Obwohl ihnen großer Respekt entgegebracht wird und sie tatsächlich über soviel Macht verfügen, wie das auf den Fidschis nur möglich ist, zeigten die Häuptlinge aufrichtige Demut und oft eine geradezu fromme Ergebenheit in ihre Pflicht. Besonders bemerkenswert ist das in Hinblick auf den Umstand, dass das Amt des Häuptlings ein ererbtes ist, keine gewählte Position oder der Gewinn eines Beliebtheitswettbewerbs. In irgendeiner Weise werden sie zu diesem Verhalten von der Kultur selbst erzogen, obwohl das Amt ein Geburtsrecht ist, und nicht durch die Wahl durch Gleichrangige erlangt wird." Er fährt fort mit dem Betonen seiner Ansicht, dass der charakteristische Führungsstil der Fidschi-Häuptlinge von der Schwierigkeit kommt, zur Kooperation zu zwingen -- ein Häuptling hat "weder eine große Keule noch eine große Karotte".

[NO] Man kann beobachten, dass Gründer erfolgreicher Projekte mehr Prestige erlangen als Leute, die nachweislich gleich viel Arbeit in das Debugging und andere Beiträge zu erfolgreichen Projekten investieren. Eine frühere Version dieses Papiers stellte die Frage: "Ist das eine rationale Bewertung, die wir hier geben?" Mehrere Antworten enthielten überzeugende und im Grunde genommen äquivalente Theorien. Folgende Analyse von Ryan Waldron <rew@erebor.com> formuliert sie sehr gut:

"Im Zusammenhang mit der Lockeschen Theorie hat jemand, der ein erfolgreiches Projekt gründet, neues Land entdeckt und erschlossen, das andere dann besiedeln und nutzen können. Bei den meisten Projekten gibt es ein Muster der abnehmenden Erträge, so dass nach einiger Zeit das Ansehen für Beiträge so verdünnt wird, dass es für späte Einsteiger schwierig wird, bedeutendes Prestige zu erwirtschaften, unabhängig von der Qualität seiner Arbeit.

Wie hoch müsste meine Leistung wohl beispielsweise sein, um durch Modikfikationen des perl-codes auch nur einen Bruchteil der Anerkennung zu erarbeiten, die Larry, Tom, Randall und andere erhalten haben? Wenn aber morgen jemand ein neues Projekt auf die Beine stellt, und ich bin ein früher und eifriger Teilnehmer, dann verbessern sich meine Chancen auf Prestige durch meinen frühen Einstieg erheblich. Das ist so ähnlich wie mit dem Unterschied zwischen Leuten, die schon früh in Micro$oft investiert haben, und jenen, die später eingestiegen sind. Profitieren mag jeder, aber die frühen Investoren profitieren mehr. Daher werde ich ab einem gewissen Zeitpunkt mehr Interesse an einem neuen und erfolgreichen Börsengang haben, als an einer Investition in den gemächlichen Fortschritt eines schon existierenden Papiers.;quot;

Ryan Waldrons Analogie kann aber noch weiter gefasst werden. Der Gründer eines Projekts muss seine neuartige Idee an andere verkaufen, die darin aber möglicherweise keinen Nutzen oder Wert sehen. Daher erscheint der Gründer wie jemand, der sich dem zum Börsengang analogen Risiko aussetzt (immerhin kann seine Reputation ruiniert werden), was eine Leistung beinhaltet, die jemand nicht erbringen muss, der sich einem schon von anderen akzeptierten Projekt einfach nur anschließt. Die Belohnung für den Gründer ist daher höher, sogar wenn seine Helferlein mehr tatsächliche Arbeit investieren. Mann kann leicht erkennen, dass es die gleiche Beziehung zwischen Risiko und Entlohnung ist, die wir auch in einer Tauschwirtschaft vorfinden.

Andere Antworten stellten fest, dass unser Nervensystem auf die Wahrnehmung von Veränderungen und Unterschieden optimiert ist, nicht auf die von Stasis. Die radikale Änderung, die das Schaffen eines neuen Projektes repräsentiert, ist daher viel wahrnehmbarer als der kumulative Effekt von konstanten inkrementellen Verbesserungen. Daher wird Linus als der Vater von Linux angesehen, obwohl der Nettoeffekt der Verbesserungen von tausenden von anderen Teilnehmern mehr zum Erfolg des Betriebssystems beigetragen haben als ein einzelner Mann jemals könnte.

[HD] Der Begriff "de-commoditizing" stammt aus den Halloween Documents, in denen Microsoft sehr unverhüllt über die aussichtsreichste Strategie zum Behalten ihres Monopols zur Ausbeutung von Benutzern sprach.

inhalt

Robert Lanphier <robla@real.com> trug viel zur Erörterung des Programmierens ohne Ego bei. Eric Kidd <eric.kidd@pobox.com> hob die Rolle der Bescheidenheit zur Verhinderung von Personenkulten hervor. Der Abschnitt über globale Effekte wurde durch Kommentare von Daniel Burn <daniel@tsathoggua.lab.usyd.edu.au> inspiriert. Mike Whitaker <mrw@entropic.co.uk> inspirierte das Gerüst des Abschnitts über Akulturation. Chris Phoenix <cphoenix@best.com> wies auf die Wichtigkeit des Umstands hin, dass Hacker nicht durch Schlechtmachen anderer Hacker zu mehr Prestige kommen können.

inhalt

Für den Inhalt dieses Papiers und Fehler und Irrtümer bin ich alleine verantwortlich (A. d. Ü: außer für Fehler des Übersetzers natürlich). Trotzdem waren Kommentare und Rückmeldungen sehr willkommen und haben zur Verbesserung dieser Arbeit beigetragen. Ein Ende dieses Prozesses erwarte ich für die absehbare Zukunft nicht.

10. April 1998: Version 1.2 am Web veröffentlicht.

12. April 1998: Version 1.3. Tippfehler korrigiert und die erste Runde öffentlicher Kommentare eingegliedert. Die ersten vier Einträge der Bibliographie hinzugefügt. Ein anonymer Beitrag lieferte die Beobachtung über Reputationsanreize, die sogar dann wirken können, wenn sich der Handwerker dessen nicht bewusst ist. Fügte den aufschlussreichen Kontrast mit zwischen warez d00dz und Open Source-Hackern, das Material über die Prämisse "Software soll für sich selbst sprechen" und die Beobachtung über die Vermeidung von Persönlichkeitskulten hinzu. Als Resultat all dieser Änderungen wuchs der Abschnitt so stark, dass ich "Das Problem mit dem Ego" als eigenständigen Abschnitt aussonderte.

16. April 1998: Version 1.7. Der neue Abschnitt "Globale Implikationen" behandelt historische Trends bei der Kolonisierung der Noosphäre und untersucht das Phänomen der "Category Killers". Fügte eine weitere Frage für weitere Untersuchungen hinzu.

27. April 1998: Version 1.8. Fügte der Bibliographie Goldhaber hinzu. Diese Version fand Eingang in die Linux Expo Proceedings.

26. Mai 1998: Version 1.9. Baute Fare Rideaus Unterscheidung zwischen Noosphäre und Ergosphäre ein. Baute RMS' Behauptung ein, er sei nicht antikommerziell eingestellt. Neuer Abschnitt über Akulturation und akademische Welt (Dank an Ross J. Reedstrom, Eran Tromer, Allan McInnes, Mike Whitaker und andere). Mehr über Demut, ("Programmieren ohne Ego" von Jerry Fass und Marsh Ray.

11. Juli 1998: Version 1.10: Entfernte auf seine Anfrage hin Fare Rideaus Hinweis über "Ruhm".

21. November 1998: Version 1.14. Kleinere redaktionelle Reparaturen und Link-Fixes.

8. August 1999: Größere Revision für das O'Reilly-Buch. Baute einige Ideen von Michael Chastain über die Kosten des Forkings und von Rogue Patches ein. Thomas Gagne <tgagne@ix.netcom.com> bemerkte die Ählichkeit zwischen dem Senioritätsprinzip und Datenbankheuristik. Henry Spencers politische Analogie. Ryan Waldron und El Howard <elhoward@hotmail.com> lieferten Beiträge über den Wert von Neuartigkeit. Thomas Byran <tbryan@arlut.utexas.edu> erklärte den Ekel der Hacker gegenüber Microsofts "embrace and extend". Darey Horrocks inspirierte den neuen Abschnitt "Was für ein Geschenk". Anderes neues Material über die Verbindung ziwschen Maslovscher Bedürfnispyramide und das Tabu gegen Attacken gegen die Kompetenz von Hackerkollegen.

inhalt

freiesoftware