Die ursprüngliche Fassung von "Cathedral and Bazaar" endete mit der oben beschriebenen Vision -- der von fröhlichen vernetzten Horden von Programmierern/Anarchisten, denen die hierarchische Welt konventioneller Software in keiner Weise gewachsen ist.
Nicht wenige Skeptiker überzeugte das aber gar nicht, und ihre Zweifel verdienen eine faire Erörterung. Die meisten der Einwände gegen das Basar-Argument lassen sich so zusammenfassen, daß Open Source-Verfechter den die Produktivität multiplizierenden Effekt konventioneller Management-Verfahren unterschätzen.
Traditionell orientierte Manager von Projekten der Software-Entwicklung wenden oft ein, daß die Lässigkeit, mit der sich Projektgruppen in der Open Source-Welt bilden, verändern und wieder auflösen, einen bedeutenden Teil der Vorzüge einer großen Zahl von Entwicklern zunichte mache. Ihre Feststellung hier ist, daß in der Software-Entwicklung nicht die Anzahl der auf einen Haufen geworfenen Leute zählt, sondern das Ausmaß der nachhaltigen Investitionen in ein Produkt, die Kunden erwarten können.
An diesem Einwand ist etwas dran, so viel ist sicher; tatsächlich habe ich in Der verzauberte Kessel die Idee entwickelt, daß in Zukunft der Wert der Dienstleistung der Schlüssel zur Ökonomie in der Softwareproduktion ist.
Dieses Argument hat aber auch ein ernstes verstecktes Problem; es unterstellt, daß Open Source-Entwicklung diese nachhaltigen Investitionen nicht liefern kann. Tatsächlich gab und gibt es Open Source-Projekte, die eine bestimmte Richtung und durchschlagskräftige Gemeinden von Teilnehmern treu verfolgt haben, und das über sehr lange Zeiträume hinweg und ohne institutionelle Aufsicht, die konventionelles Management so bedeutend findet. Die Entwicklung des Editors GNU Emacs ist ein extremes und lehrreiches Beispiel dafür; sie hat über fünfzehn Jahre hinweg die Zuwendung und Mühe von hunderten von Beitragenden in eine vereinigte architektonische Vision absorbiert, und das trotz hoher Fluktuation und trotz der Tatsache, daß nur eine Person (der Autor von GNU) während der ganzen Zeit ununterbrochen aktiv war. Kein Closed Source-Editor hat jemals solche Langlebigkeit erreicht.
Das alles legt es nahe, die Vorzüge von konventionell gemanageter Software-Entwicklung anzuzweifeln, die vom Rest der Einwände gegen das Kathedralen- vs. Basar-Modell unabhängig sind. Wenn es für GNU Emacs möglich ist, fünfzehn Jahre lang eine gerade Linie in der Architektur zu verfolgen, oder für acht Jahre im Falle eines Betriebssystems wie Linux, und wenn (was tatsächlich der Fall ist) es sehr viele gut entworfener Open Source-Projekte gibt, die länger als fünf Jahre am Leben waren -- dann sind wir berechtigt, uns zu fragen, was wir denn, wenn überhaupt irgendetwas, für die Unkosten für konventionelles Management eigentlich kaufen.
Was auch immer es ist, es hat sicher nichts mit der Lieferung von zuverlässiger Software zu einem versprochenen Termin zu tun, oder mit dem Einhalten des Budgets, oder mit allen in der Spezifikation geforderten Leistungsmerkmalen; es kommt ausgesprochen selten vor, daß ein "gemanagetes" Projekt auch nur eines dieser Ziele erreicht, von allen dreien gar nicht zu reden. Es scheint auch kein besonderes Talent von konventionellem Management zu sein, während des Lebenszyklus eines Projekts flexibel auf Veränderungen im technologischen oder ökonomischen Kontext zu reagieren. Die Open Source-Gemeinde hat sich bei dieser Wertung als bei weitem effektiver gezeigt. Davon kann man sich sehr leicht selbst überzeugen, beispielsweise durch den Vergleich der dreißigjährigen Geschichte des Internets mit den kurzen Halbwertszeiten proprietärer Netzwerktechnologien, oder den Kosten für die Migration von Microsoft Windows von 16-bit auf 32-bit auf der einen Seite und die fast kostenlose Migration von Linux im selben Zeitraum, die nicht nur auf Intel-Prozessoren beschränkt war, sondern auf mehr als ein Dutzend anderer Hardware-Plattformen ausgedehnt wurde, darunter den 64-bit Alpha.
Eines, was sich die Menschen vom traditionellen Modus der Software-Entwicklung versprechen, ist die Möglichkeit, jemanden nach einem schiefgegangen Projekt auf Schadenersatz zu verklagen. Das ist aber eine Illusion; die meisten Software-Lizenzen sind so abgefaßt, daß sie sogar jede Verantwortung für Verkäuflichkeit, ganz zu schweigen von Funktionstauglichkeit, ablehnen -- und die Fälle, in denen der Schaden durch nichtfunktionierende Software erfolgreich eingeklagt werden konnte, sind verschwindend gering. Sogar wenn das üblich wäre, ginge dieser Trost, jemanden belangen zu können, am Thema vorbei. Sie wollen keinen Prozeß, Sie wollen funktionierende Software.
Was erhalten wir also durch den Overhead des Managements?
Um das zu verstehen, müssen wir uns zunächst mit dem vertraut machen, was Software-Entwicklungsleiter glauben zu tun. Eine Bekannte, die sehr gut in diesem Job zu sein scheint, erklärt, daß Software-Projektmanagement fünf Funktionen erfüllt:
Anscheinend sind das alles erstrebenswerte Ziele, aber beim Open Source-Modell und seinem umgebenden sozialen Kontext können sie alle sehr schnell eine eigentümliche Bedeutungslosigkeit bekommen. Gehen wir die Ziele in umgekehrter Reihenfolge durch.
Meine Bekannte berichtet, daß vieles von der Beschaffung von Ressourcen prinzipiell defensiv ist; sobald man seine Leute, Geräte und Büroräumlichkeiten beisammen hat, muß man sie gegen gleichgestellte Manager verteidigen, die um die selben Ressourcen wetteifern, und gegen Vorgesetzte, die den größtmöglichen Nutzen aus einem begrenzten Pool herausholen wollen.
Open Source-Entwickler aber sind Freiwillige, die nach Interesse und Fähigkeit selbsternannt sind, um zu einem Projekt beizutragen (das bleibt sogar dann wahr, wenn sie für das Open Source-Hacken ein Gehalt bezahlt bekommen). Der Ethos der Freiwilligen hat die Tendenz, die gesamte "räuberische" Seite der Beschaffung von Ressourcen automatisch zu entschärfen: die Leute stiften ihre eigenen Ressourcen. Und es gibt wenig oder keinen Bedarf nach einem Manager, der den "Beschützer" im konventionellen Sinne spielt.
In einer Welt der billigen PCs und schnellen Internet-Verbindungen stellen wir praktisch überall fest, daß die einzige begrenzte Ressource kompetente Aufmerksamkeit ist. Open Source-Projekte, die im Sand verlaufen, scheitern nicht an einem Mangel von Maschinen oder Anschlüssen oder Büroräumlichkeiten, sondern daran, daß die Entwickler das Interesse daran verlieren.
Aus diesem Grund ist es doppelt wichtig, daß Open Source-Hacker sich selbst organisieren, um durch Selbsternennung das Maximum an Produktivität zu liefern -- und das soziale Milieu wählt gnadenlos nur die höchste Kompetenz. Meine Bekannte, die sowohl mit der Open Source-Welt als auch mit umfangreichen Projekten unter Ausschluß der Öffentlichkeit vertraut ist, glaubt, daß Open Source teilweise wegen seiner Auswahlkriterien so erfolgreich war, die nur 5 Prozent der programmierenden Bevölkerung zuläßt. Sie verbringt die meiste Zeit mir der Organisation der restlichen 95 Prozent und kennt daher den Unterschied zwischen den fähigsten Programmierern und den gerade noch kompetenten aus erster Hand; die Produktivität verhält sich ungefähr 1:100.
Dieser bedeutende Unterschied hat immer eine verlegene Frage hervorgerufen: wären individuelle Projekte und das gesamte Feld besser dran, wenn nicht mehr als 50 Prozent der weniger Fähigen daran teilnehmen würden? Besonnene Manager verstehen seit langem, daß das ganze Spiel keinen Wert mehr hätte, wenn es die einzige Funktion des konventionellen Managements wäre, die weniger Fähigen von einem Nettoverlust zu einem marginalen Gewinn zu machen.
Der Erfolg der Open Source-Gemeinde verschärft diese Frage bedeutend. Sie liefert harte Beweise dafür, daß es oft billiger und effektiver ist, selbsternannte Freiwillige über das Internet anzuheuern als ganze Gebäude voller Leute zu managen, die lieber etwas anderes täten.
Das bringt uns nahtlos zur Frage der Motivation. Eine äquivalente und oft gehörte Umformulierung der betreffenden Aussage meiner Bekannten ist, daß traditionelles Entwicklermanagement eine notwendige Kompensation für schlecht motivierte Programmierer ist, die andernfalls keine gute Arbeit liefern würden.
Diese Antwort tritt meistens zusammen mit der Behauptung auf, daß die Open Source-Gemeinde sich nur dort auf das Erbringen von Aufwand verlassen kann, wo er sexy ist oder technischen Glamour ausstrahlt; alles andere würde ungetan oder schlecht gemacht bleiben, wenn nicht geld-motivierte Großraumbürobewohner unter der Knute von Managern zu Hilfe kommen würden. Ich befasse mich mit den psychologischen und sozialen Gründen für Zweifel an dieser Behauptung in "Homesteading the Noosphere". Im Augenblick möchte ich aber auf die interessanten Implikationen hinweisen, wenn man unterstellt, daß diese Behauptung wahr ist.
Wenn der konventionelle, völlig durchgemanagete und nicht-öffentliche ("Closed Source") Stil der Software-Entwicklung wirklich nur durch eine Art Maginot-Linie von Problemen verteidigt wird, die Langeweile hervorrufen, dann wird jedes einzelne Feld von Anwendungen nur solange davor sicher sein, solange diese Problemstellungen niemand interessant findet und niemand einen Weg findet, sie zu umgehen. Ab dem Zeitpunkt, ab dem es einen Wettbewerb um ein "langweiliges" Stück Software gibt, erfahren dann auch die Kunden, daß sich endlich jemand gefunden hat, der dieses Problem interessant genug fand, um sich darum zu kümmern -- was bei Software wie bei jeder anderen kreativen Tätigkeit ein bei weitem machtvollerer Motivator ist als Geld allein.
Eine konventionelle Managementstruktur zu haben, um zu motivieren, ist so gesehen gute Taktik, aber schlechte Strategie; ein kurzfristiger Gewinn, aber langfristig ein sicherer Verlust.
Bis jetzt sieht das konventionelle Entwicklungsmanagement in zwei Punkten wie eine schlechte Wette gegen Open Source aus (Beschaffung und Organisation) und bei einem dritten (Motivation) lebt es von geborgtem Glück. Der arme, unter Druck stehende konventionelle Manager wird keine Aufgaben bei Überwachung vorfinden, auf dem er Punkte wettmachen kann; das stärkste Argument für Open Source ist die dezentralisierte, unentwegte Kritik und Verfeinerung durch Gleichgesinnte ("peer review"), die allen konventionellen Methoden der Qualitätssicherung weit überlegen ist.
Bleibt uns wenigstens die Definition von Zielen als Rechtfertigung für den Overhead des konventionellen Software-Projektmanagements? Vielleicht, aber das verlangt gute Gründe für den Glauben daran, daß Management-Kommitees und Firmenerlässe beim Definieren von lohnenden und allgemein anerkannten Zielen erfolgreicher sind als die Projektleiter und Stammesältesten, die eine analoge Rolle für die Open Source-Welt ausfüllen.
Diesen Einwand zu einem überzeugenden zu machen wird schwierig sein, und es ist nicht so sehr die Open Source-Seite dieser Gleichung (Langlebigkeit von Emacs und Linus Torvalds' Fähigkeit, ganze Horden von Entwicklern durch Reden über "Weltherrschaft" zu mobilisieren), die das so erschwert. Stattdessen ist es die Erbärmlichkeit der konventionellen Mechanismen zur Definition von Zielen für Software-Projekte.
Eines der bekanntesten Volkstheoreme des Software-Ingenieurswesens ist, daß 60 bis 75 Prozent aller konventionellen Software-Projekte entweder nie fertig oder von den vorgesehenen Anwendern nicht angenommen werden. Wenn diese Zahlen auch nur ungefähr stimmen (und ich habe niemals einen erfahrenen Manager getroffen, der sie abgestritten hätte), dann ist mehr als die Hälfte aller Projekte entweder (a) nicht realistisch spezifiziert oder (b) an den Anwendern vorbeispezifiziert.
Das ist mehr als alles andere der Grund dafür, daß in der Welt des heutigen Software-Ingenieurswesens schon alleine die Formel "Management-Kommittee" dem Hörer die Nackenhaare aufstellt -- sogar (oder vielleicht besonders) wenn der Hörer selbst ein Manager ist. Die Tage, in denen ausschließlich Programmierer dagegen Allergiereaktionen zeigten, sind lange vorbei; Dilbert-Comics hängen heute auch über den Schreibtischen der Chefs.
Unsere Stellungnahme gegenüber dem traditionellen Manager von Software-Entwicklung ist daher simpel: wenn die Open Source-Gemeinde den Wert des konventionellen Managements unterschätzt, warum begegnen dann so viele von euch euren eigenen Verfahren mit so viel Geringschätzung?
Wieder einmal verschärft die Existenz der Open Source-Gemeinde diese Frage erheblich -- weil wir Spaß an dem haben, was wir tun. Unsere kreative Spielerei hat Erfolge nach Kriterien der Technologie, Marktanteile und Beachtung gebracht, deren Häufigkeit das Erstaunliche ist. Wir beweisen nicht nur, daß wir die bessere Software machen können, sondern auch, daß Spaß Kapital ist.
Zweieinhalb Jahre nach der ersten Version dieses Aufsatzes ist der radikalste Gedanke, den ich als Schlußwort anbieten kann, nicht mehr länger eine Vision einer Open Source-dominierten Software-Welt, die heute sogar vielen nüchternen Menschen in Schlips und Kragen plausibel scheint.
Stattdessen weise ich auf eine allgemeinere Lektion zum Thema Software hin (die sich vielleicht auf jede Form von kreativer oder professioneller Arbeit ausdehnen läßt). Die Menschen haben in der Regel ihre Freude an einer Aufgabe, die in irgendeiner Weise in die Zone einer optimalen Herausforderung fällt, die also weder so leicht ist um zu langweilen noch so schwierig um zu überfordern. Ein glücklicher Programmierer ist einer, der weder unterfordert noch von schlecht formulierten Zielsetzungen und dem Streß bürokratischer Reibungsverluste geplagt ist. "Der Spaß kommt mit der Effizienz".
Von den Umständen und Methoden der eigenen Arbeit angewidert zu sein (sogar wenn sich nur milder Ekel durch Aufhängen von Dilbert-Comics zeigt) sollte daher als Zeichen dafür gewertet werden, daß der Prozeß selbst versagt hat. Freude, Humor und Verspieltheit sind ein wertvolles Gut und das Schlagwort von den "fröhlichen Horden" habe ich nicht nur wegen seiner Griffigkeit verwendet. Auch ist es mehr als nur ein Witz, daß für Linux' Maskottchen ein kuscheliger, kindlicher Pinguin ausgesucht wurde.
Es könnte sich ohne weiteres herausstellen, daß die wichtigste Auswirkung des Erfolges der Open Source die Einsicht ist, daß es keinen ökonomisch effektiveren Modus kreativer Arbeit gibt als das Spielen.