15 Fußnoten

[JB] In Programing Pearls, kommentiert Jon Bentley, der berühmte Aphorist der Informatik, Brooks' Beobachtungen mit Wenn Sie planen, eine Version wegzuschmeißen, werden Sie zwei wegschmeißen. Er liegt damit ziemlich sicher richtig. Der springende Punkt hinter Brooks' Feststellung und der hinter Bentleys' ist nicht bloß, dass man vom ersten Versuch erwarten sollte, dass er fehlschlägt, sondern dass es effektiver ist, noch einmal von vorne anzufangen, als zu versuchen, einen Sauhaufen auszumisten.

[QR] Es gibt Beispiele erfolgreicher Open Source-Projekte im Basar-Stil, die noch vor der Internet-Explosion stattfanden und mit Unix in keinem Bezug stehen. Die Entwicklung des DOS-Packprogramms  info-Zip während der Jahre 1990-1992 ist ein solches. Ein weiteres war das Bulletin Board System RBBS (auch für DOS), das 1983 begann und eine so starke Gemeinde entwickelte, dass es bis heute (Mitte 1999) sehr regelmäßige Freigaben gibt, und das trotz der gewaltigen technischen Vorteile von Internet-Mail und gemeinsamer Nutzung von Dateien über lokale BBSs. Während die Info-Zip-Gemeinde bis zu einem gewissen Grad Internet-Mail nutzte, basierte die Entwicklerkultur der umfangreichen RBBS-Gemeinde auf RBBS, das von der  TCP/IP-Infrastruktur völlig unabhängig war.

[JH] John Hasler regte eine interessante Erklärung für den Umstand an, dass es bei Open Source-Projekten verhältnismäßig wenig vergebliche Mühe durch überlappende Anstrengungen gibt. Ich nenne seine Vorstellung Haslers Gesetz: Die Kosten für doppelt gemachte Arbeit tendieren dazu, weniger als mit dem Quadrat der Team-Größe zu wachsen. In anderen Worten, sie werden immer geringer sein als die Planungs- und Management-Unkosten, die gebraucht würden, um sie zu eliminieren.

Diese Behauptung widerspricht Brooks' Gesetz nicht. Es mag sein, dass die Unkosten für die gesamte Komplexität und die Anfälligkeit für Bugs mit dem Quadrat der Team-Größe wachsen, aber die Kosten für doppelt vorgenommene Arbeiten sind nichtsdestoweniger ein Spezialfall, der eine weniger dramatische Wachstumscharakteristik hat. Es ist nicht schwierig, plausible Erklärungen dafür zu finden. Bedenken Sie nur, dass es viel einfacher ist, sich auf die Abgrenzung der Funktionalität der jeweiligen Module verschiedener Entwickler zu einigen (was doppelt investierten Aufwand verhindert), als die ungeplanten Interaktionen über das ganze System hinweg auszuschließen, das den meisten Bugs zugrunde liegt.

Die Kombination von Linus' Gesetz und Haslers Gesetz legt drei ausschlaggebende Umstände von Software-Projekten nahe. Bei kleinen Projekten (bis zu drei Entwickler, würde ich sagen) ist keine aufwendigere Managementstruktur notwendig, als einen Entwickler als Chef-Programmierer zu haben. Dann gibt es einen mittleren Bereich der Projektgröße, bei dem die Kosten für traditionelles Management relativ gering sind, so dass die Vorzüge aus der Vermeidung von überlappendem Aufwand, Bug-Tracking und dem unentwegten Kampf gegen übersehene Details unter dem Strich einen Gewinn darstellen.

Für jenseits dieser Projektgröße aber sagt die Kombination aus Linus' Gesetz und Haslers Gesetz voraus, dass die Kosten und Probleme des traditionellen Managements viel schneller anwachsen als die zu erwartenden Kosten für doppelt erbrachten Aufwand. Sicher nicht die geringsten dieser Kosten entsteht durch die immanente Unfähigkeit, die Zuwendung sehr vieler Entwickler in effektiver Weise vor den Wagen zu spannen, was aber (wie wir gesehen haben) eine bessere Methode als das traditionelle Management ist, um zu garantieren, dass keine Bugs und Details übersehen werden. Daher treibt die Kombination der beiden Gesetze den Nettogewinn aus traditionellem Management praktisch gegen Null, wenn es um große Projekte geht.

[IN] Ob jemand Projekte von Beginn an als Basar abwickeln kann, hängt von der Frage ab, ob der Basar wahrlich innovative Arbeit ermöglicht. Einige behaupten, dass der Basar aus Mangel an starker Führung nur das Klonen und Verbessern von Ideen handhaben kann, die bereits allgemeiner Standard der Ingenieurskunst sind, aber nicht in der Lage ist, darüber hinaus etwas zum Fortschritt beizutragen. Dieses Argument wurde vielleicht am prominentesten in den berüchtigten  Halloween Dokumenten breitgetreten, zwei Microsoft-internen Memoranden über das Open Source-Phänomen. Die Autoren verglichen Linux' Entwicklung mit der Jagd von Rücklichtern (chasing taillights) und drückten die Meinung aus, dass sobald ein Projekt Gleichstand mit dem State Of The Art erreicht habe, der Aufwand an Management, der für das Erreichen neuer Fronten notwendig ist, zu hoch wird (once a project has achieved "parity" with the state-of-the-art, the level of management necessary to push towards new frontiers becomes massive).

Dabei macht man aber grobe Fehler, die Implikationen dieser Überlegung widersprechen den Tatsachen. Einer wird deutlich, wenn die Autoren der  Halloween Dokumente später selbst feststellen, dass neuartige Ideen der Grundlagenforschung als erstes unter Linux implementiert werden und verfügbar sind (often [...] new research ideas are first implemented and available on Linux before they are available / incorporated into other platforms).

Wenn wir Open Source für Linux einsetzen, sehen wir, dass dies weit von einer neuen Erscheinung entfernt ist. Historisch gesprochen: die Open Source-Gemeinde erfand Emacs, das World Wide Web oder das Internet nicht durch die Jagd nach Rücklichtern oder durch erheblichen Managementaufwand -- und gegenwärtig geht in der Open Source-Welt soviel an innovativer Arbeit vor sich, dass man von der Auswahl regelrecht verwöhnt wird. Im  GNOME-Projekt (um willkürlich eines herauszugreifen) begegnen wir zum Beispiel erheblichen Fortschritten auf den Gebieten der graphischen Benutzeroberflächen und Objekttechnologie, die bedeutend genug sind, um die Aufmerksamkeit der Fachpresse auch außerhalb der Linux-Gemeinde auf sich zu ziehen. Es gibt Berge von anderen Beispielen, wovon sich jeder durch einen Besuch bei  Freshmeat selbst überzeugen kann.

Es gibt aber einen noch fundamentaleren Fehler in der impliziten Annahme, dass das Modell der Kathedrale (oder das des Basars oder irgendeine andere Form von Management-Struktur) Innovation zuverlässig erzeugen kann. Das ist Nonsense. Bandenbildung verhilft nicht automatisch zu bahnbrechenden Geistesblitzen -- nicht einmal die Gruppen von freiwilligen Basaranarchisten sind für gewöhnlich zu echter Originalität in der Lage, gar nicht zu reden von Kommittees im Bauch von Firmensauriern, deren Überleben von Status Quo Ante abhängt. Einsichten stammen von Individuen. Das Beste, auf das ihre umgebende soziale Maschinerie jemals hoffen kann, ist, auf bahnbrechende Einfälle fördernd zu reagieren -- sie zu belohnen und zu testen, anstatt sie zu zermalmen.

Einige werden das als romantische Ansicht sehen, einen weiteren Aufguss des überholten Cliches vom einsamen Erfinder. Das ist es aber nicht; ich unterstelle hier nicht, dass Gruppen unfähig sind, bahnbrechende Einsichten weiterzuentwickeln, sobald es sie gibt. Es ist ja so, dass gerade der Prozess der Kritik durch andere Teilnehmer (peer review) solche Gruppen in die Lage versetzt, Resultate von höchster Güte hervorzubringen. Stattdessen weise ich darauf hin, dass jede solche Gruppe ihren Anfang -- den notwendigen Funken -- durch eine gute Idee in jemandes Kopf erhält. Kathedralen und Basare und andere soziale Strukturen können diesen Geistesblitz aufnehmen und verfeinern, aber nicht auf Kommando erzeugen.

Daher ist die Wurzel der Problemstellung der Innovation (in der Software und auch überall sonst) mehr die Frage, wie man vermeiden kann, den Funken auszulöschen -- oder, noch fundamentaler, wie man möglichst viele Menschen heranzieht, die zu Einsichten und Geistesblitzen fähig sind.

Einfach anzunehmen, die Software-Entwicklung im Stil der Kathedrale könnte diesen Trick zustande bringen, aber die geringen Hürden und Flexibilität des Basars könnte es nicht, das ist absurd. Wenn es nur einer Person mit einer guten Idee bedarf, um in einem entsprechend gewogenem sozialen Milieu rasch eine Kooperation von hunderten oder tausenden von Teilnehmern zu etablieren, dann wird diese Person jeder anderen mit dieser Idee davonziehen, die sie erst einmal an eine Hierarchie politisch verkaufen muss, um daran arbeiten zu können, ohne gefeuert zu werden.

Und, mehr noch: Wenn man die Geschichte der Software-Innovationen betrachtet, die von Organisationen hervorgebracht wurden, die nach dem Modell der Kathedrale arbeiteten, finden wir schnell heraus, dass dergleichen sehr selten geschieht. Große Firmen sind bei neuen Ideen von der Grundlagenforschung der Universitäten abhängig (daher die Nervosität der Autoren der  Halloween Dokumente darüber, dass Linux die Gabe hat, dieser Grundlagenforschung schneller zu entsprechen). Oder sie schlucken kleine Firmen, die um das Gehirn eines Innovators herum aufgebaut sind. In keinem der beiden Fälle ist die Innovation auf dem Nährboden der Kathedralenkultur entstanden -- viele derart importierten Innovationen enden damit, dass sie unter dem Druck des massiven Managements (wie das die Autoren der  Halloween Dokumente huldigend nennen) still erstickt werden.

Das ist aber ein Negativ-Beispiel. Der Leser wäre durch ein positives besser bedient. Ich schlage daher folgendes Experiment vor:

1. Greifen Sie irgendein Kriterium für Originalität heraus, von dem Sie annehmen, dass es durchgehend angewendet werden kann. Wenn Ihre Definition lautet Ich erkenne es als solches, wenn ich es sehe, dann ist das für diesen Test auch kein Problem.
2. Greifen Sie irgendein Closed Source-Betriebssystem heraus, das mit Linux konkurriert und die beste Quelle für Berichte über gegenwärtige Entwicklungsarbeit an ihm.
3. Beobachten Sie diese Quelle und Freshmeat für einen Monat. Zählen Sie jeden Tag die Anzahl der Verlautbarungen von Freigaben auf Freshmeat, die Sie für eine Innovation halten. Wenden Sie die gleiche Definition von Innovation auf das andere Betriebssystem an und zählen Sie mit.
4. Nach dreißig Tagen addieren Sie die jeweiligen Zahlen.

Am Tag als ich dies schrieb, gab es bei Freshmeat zweiundzwanzig Ankündigungen von Freigaben, von denen drei den State Of The Art in gewisser Hinsicht weiterzubringen scheinen. Das war ein schwacher Tag bei Freshmeat, aber ich wäre erstaunt, wenn es irgendeinem Leser möglich sein sollte, auf irgendeinem Closed Source-Kanal auch auf drei wahrscheinliche Innovationen pro Monat zu kommen.

[EGCS] Wir können heute auf die längere Geschichte eines Projekts zurückblicken, das einen aussagekräftigeren Test der Behauptungen über den Basar zulässt als fetchmail; die Rede ist von  EGCS, dem Experimental GNU Compiler System.

Dieses Projekt wurde Mitte August 1997 angekündigt und war ein bewusster Versuch, die Ideen der frühen Versionen von Die Kathedrale und der Basar anzuwenden. Die Gründer des Projekts standen unter dem Eindruck, dass die Entwicklung von GCC, des Gnu C Compilers, seit geraumer Zeit stagnierte. Für die zwanzig darauf folgenden Monate führte man GCC und EGCS als parallele Produkte weiter -- beide schöpften aus dem selben Pool der Internet-Entwicklerpopulation, beide starteten vom selben GCC-Codestamm und beide verwendeten im Großen und Ganzen die selben Unix-Tools und -Entwicklungsumgebungen. Die Projekte unterschied nur, dass EGCS bewusst versuchte, die Basar-Taktik anzuwenden, die ich beschrieben hatte, während GCC seine mehr Kathedralen-artige Organisation beibehielt, die aus einer geschlossenen Entwicklergruppe bestand und nur selten Freigaben durchführte.

Das kam einem kontrollierten Experiment so nahe, wie man es sich nur wünschen konnte, und die Resultate waren dramatisch. Innerhalb von Monaten lagen die EGCS-Versionen bei den Features bedeutend in Führung; bessere Optimierung, bessere Unterstützung für FORTRAN und C++. Viele Leute befanden die EGCS-Entwicklungs-Snapshots für zuverlässiger als die neuesten stabilen Versionen von GCC und bedeutende Linux-Distributionen begannen, auf EGCS zu wechseln.

Im April 1999 löste die Free Software Foundation (die offiziellen Sponsoren von GCC) die ursprüngliche GCC Development Group auf und händigte die Kontrolle über das Projekt dem  EGCS Steering Team aus.

[SP] Natürlich werfen Kropotkins Kritik und Linus' Gesetz allgemeinere Fragen über die  Kybernetik von sozialen Organisationen auf. Eine davon wird durch ein anderes Volkstheorem der Software-Entwicklung nahegelegt: Conways Gesetz. Üblicherweise wird es so formuliert: Wenn man vier Gruppen hat, die an einem Compiler arbeiten, bekommt man einen 4-Pass-Compiler. Ursprünglich hatte diese Aussage die Form Organisationen, die Systeme entwerfen, sind auf das Hervorbringen von Entwürfen beschränkt, die Kopien der Kommunikationsstrukturen dieser Organisationen sind. Prägnanter könnten wir sagen: Die Mittel bestimmen das Ergebnis, oder noch zackiger: Prozess wird Produkt.

Dementsprechend ist es wertvoll festzuhalten, dass in der Open Source-Gemeinde die organisatorische Form die Funktion auf vielen Ebenen widerspiegelt. Das Netzwerk ist alles und allgegenwärtig -- nicht nur das Internet, sondern auch die Seilschaften der Teilnehmer formen eine verteilte, locker gekoppelte Arbeitsgruppe ("  peer-to-peer network"), die viel an Redundanz bietet und in der alle graziöse Zurückhaltung zeigen. In beiden Netzwerken ist jeder Knoten nur so weit wichtig, als dass andere Knoten mit ihm kooperieren wollen.

Die peer-to-peer-Charakteristik ist hier sehr bedeutend für die erstaunliche Produktivität der Gemeinde. Was Kropotkin versuchte im Zusammenhang mit Machtverhältnissen deutlich zu machen, wird durch das  snafu-Prinzip (Situation normal -- all fucked up) weiter entwickelt: Wirkliche Kommunikation kann es nur zwischen Gleichgestellten geben, weil Untergebene in aller Regel eher für das Erzählen von gefälligen Lügen belohnt werden als für das Sagen der Wahrheit. Kreative Teamarbeit hängt sehr von echter Kommunikation ab und wird daher durch die Präsenz von Machtverhältnissen ernsthaft behindert. Die Open Source-Gemeinde ist wirklich frei von solchen Machtverhältnissen und lehrt uns durch ein dazu in krassem Gegensatz stehendes Beispiel, wie teuer Macht ist: hohe Kosten durch Bugs, geringere Produktivität und verpennte Gelegenheiten.

Darüber hinaus sagt das snafu-Prinzip voraus, dass es in autoritär orientierten Organisationen einen Realitätsverlust unter Entscheidungsträgern gibt. Er kommt durch die Erscheinung zustande, dass nach und nach mehr und mehr der Information aus gefälligen Lügen besteht -- die Folgen sind in konventionellen Softwareprojekten klar zu erkennen. Es gibt für Untergebene sehr starke Anreize für das Herunterspielen, Verstecken und Ignorieren von Problemen. Wenn dieser Prozess Produkt wird, ist die Software ein Desaster.