11 Über Management und die Maginotlinie

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, dass 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, dass 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, dass 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, dass 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, dass 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, dass 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 Kosten 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, dass 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 schief gegangen Projekt auf Schadenersatz zu verklagen. Das ist aber eine Illusion; die meisten Software-Lizenzen sind so abgefasst, dass 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 Prozess, 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, dass Software-Projektmanagement fünf Funktionen erfüllt:

1. Es definiert Ziele und sorgt dafür, dass alle Teilnehmer am selben Strang ziehen.
2. Es überwacht den Fortschritt und stellt sicher, dass wichtige Details nicht einfach unter den Tisch fallen.
3. Es motiviert die Leute dazu, auch stumpfsinnige, aber notwendige Plackerei zu machen.
4. Es organisiert den Aufwand der Leute zu maximaler Produktivität.
5. Es beschafft Ressourcen, die für den Fortschritt des Projekts notwendig sind.

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, dass vieles von der Beschaffung von Ressourcen prinzipiell defensiv ist; sobald man seine Leute, Geräte und Büroräumlichkeiten beisammen hat, muss 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 selbst ernannt 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, dass 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, dass die Entwickler das Interesse daran verlieren.

Aus diesem Grund ist es doppelt wichtig, dass 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 Ausschluss der Öffentlichkeit vertraut ist, glaubt, dass Open Source teilweise wegen seiner Auswahlkriterien so erfolgreich war, die nur 5 Prozent der programmierenden Bevölkerung zulässt. 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, dass 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, dass es oft billiger und effektiver ist, selbst ernannte 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, dass 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, dass 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, dass 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, dass 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, dass Management-Komitees 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-Ingenieurwesens ist, dass 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, dass in der Welt des heutigen Software-Ingenieurwesens schon alleine die Formel Management-Komitee 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, dass wir die bessere Software machen können, sondern auch, dass Spaß Kapital ist.

Zweieinhalb Jahre nach der ersten Version dieses Aufsatzes ist der radikalste Gedanke, den ich als Schlusswort 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ässt). 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 Stress 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, dass der Prozess 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, dass für Linux' Maskottchen ein kuscheliger, kindlicher Pinguin ausgesucht wurde.

Es könnte sich ohne weiteres herausstellen, dass die wichtigste Auswirkung des Erfolges der Open Source die Einsicht ist, dass es keinen ökonomisch effektiveren Modus kreativer Arbeit gibt als das Spielen.