Als das pragmatische Hacking auf dem Vormarsch war, begann für puristische Ansätze eine Zeit des langsamen, schmerzhaften und kostspieligen Niedergangs. Selbst als sie mit zunehmendem Ehrgeiz betrieben wurden, wurden Softwareprojekte, die auf puristischen Architekturen und austauschbaren Programmiererteams basieren, immer schwerer steuerbar. Wie vorherzusehen, zeigten sich die Muster des Misserfolgs, die schon das Industriezeitalter geprägt hatten: massive Kostenüberschreitungen, lange Verzögerungen, missglückte Produktstarts, unbeabsichtigte negative Konsequenzen und defekte, nicht benutzbare Systeme.
Diese Muster des Misserfolgs sind charakteristisch für das, was der Politikwissenschaftler James Scott1 als autoritären Hochmodernismus bezeichnet: eine puristische architektonische Ästhetik, die von autoritären Prioritäten angetrieben wirdUmwelt-Elemente, die nicht ihren puristischen Designvorstellungen entsprechen, erscheinen autoritären Hochmodernisten als „unlesbar“ und angsteinflössend. Dementsprechend versuchen sie, die Umwelt lesbar zu machen, indem sie unlesbare Elemente gewaltsam entfernen. Das Resultat sind Fehlschläge, weil wichtige Elemente, die für das Funktionieren eben dieser Umwelt notwendig sind, im Laufe des Prozesses entfernt werden.
So sind beispielsweise geometrisch angelegte Vororte lesbar und gehen mit platonischen architektonischen Visionen konform, auch wenn sie praktisch unbewohnbar sind und wirtschaftlich stagnieren. Slums hingegen erscheinen als unlesbar und rufen in den Planern Ängste hervor, selbst wenn sie ein florierendes ökonomisches Leben beherbergen. Infolgedessen machen autoritäre Planer Slums dem Erdboden gleich und siedeln die Bewohner in kostengünstige geplante Wohngebiete um. Dabei zerstören sie häufig ökonomische und kulturelle Vitalität.
In der Software sind es die chaotischen, ungeplanten Tüfteleien, mit denen Hacker kreative Lösungen erschaffen, die autoritären Architekten als unlesbar und beängstigend erscheinen. Als das pragmatische Modell in den sechziger Jahren entstand, reagierten autoritäre Architekten nicht anders als Städteplaner: sie versuchten, „Code-Slums“ zu bereinigen. Diese Versuche nahmen die Form von zunehmend rigiden Dokumentations- und Kontrollprozessen an, die aus der Produktion übernommen wurden. Dabei ging das Wissen der Hacker, das nötig gewesen wäre, um ein Projekt am Leben zu halten, häufig verloren.
Zusammenfassend kann man den autoritären Hochmodernismus als eine Art Tunnelblick bezeichnen. Besonders anfällig für diesen Tunnelblick sind Architekten in Umgebungen, die reicher sind, als es der menschliche Geist begreifen kann. Das Verlangen, Dinge vorzuschreiben und zu organisieren, ist in einem solchen Umfeld kontraproduktiv, denn es bringt Architekten dazu, das vermeintliche Chaos zu zerstören, das für den Erfolg unverzichtbar ist.
Die Schwächen des autoritären Hochmodernismus wurden zuerst in Bereichen wie Forstwirtschaft, Stadtplanung und Bauwesen spürbar. Fehlschläge autoritärer Entwicklungen in diesen Bereichen führten zu von Schädlingen verwüsteten Wäldern, unbewohnbaren Planstädten, Vetternwirtschaft und chronischer Korruption. In den 1960er Jahren hatten zukunftsweisende Kritiker autoritärer Modelle wie die Städtebaukritikerin Jane Jacobs und die Umweltschützerin Rachel Carlson begonnen, das Problem korrekt zu diagnostizieren.
In den Siebzigern übernahmen liberale Demokratien allmählich die demokratischeren Verfahren der Bürgerbeteiligung, die auch heute noch eingesetzt werden. Ein ähnlicher Umbruch geschah auch in der Programmierung, so wie auch die frühe Zeit der Grossrechner der Zeit der Minicomputer wich.
Auch wenn demokratische Prozesse die Probleme entschärften, führte dies häufig zu einer langsameren Entwicklungsgeschwindigkeit, steigenden Kosten und einer immer noch chronischen, aber zunehmend unsichtbaren Korruption, Neue Akteure brachten konkurrierende utopische Visionen und autoritäre Tendenzen auf den Plan. Das Problem bestand nun darin, die widerstreitenden autoritären Visionen miteinander zu vereinen. Noch härter traf es diejenigen verbleibenden unlesbaren Realitäten, die allen Akteuren als beängstigend erschienen. Sie waren nun noch stärker der Gefahr von Vorurteilen oder der Beseitigung ausgesetzt. Als Folge sind komplexe Technologieprojekte oft kostspielig und festgefahren und es geht nur im Schneckentempo vorwärts. Die Tyrannei der Mehrheit – durch autokratische Vertreter besonders mächtiger Wählerschaften zum Ausdruck gebracht – machte sich über jeden erzielten Fortschritt her. Das grösste Leidtragende war die Innovation, denn sie wird per definitionem von Ideen angetrieben, die für alle bis auf wenige unlesbar erscheinen. Peter Thiel bezeichnet dies als secrets – Dinge, an die Entrepreneure glauben, ohne dass jemand diesen Glauben teilt. Dies treibt sie zu unvorhersehbaren Durchbrüchen an.
Dieser Prozess zeigte in Bereichen wie der Verteidigung am deutlichsten. In den grossen liberalen Demokratien konkurrieren unterschiedliche Zweige des Militärs darum, die Gestaltung neuer Waffensysteme zu beeinflussen, und Politiker konkurrieren darum, Arbeitsplätze in ihren Wahlkreisen zu schaffen. Als Ergebnis gerieten viele Grossprojekte ausser Kontrolle und schlugen auf vorhersehbare Weise fehl: Sie verzögerten sich, wurden zu teuer oder scheiterten an technischen Problemen. Im nicht-demokratischen Teil der Welt waren die Folgen noch gravierender: Der autoritäre Hochmodernismus blieb bestehen (und besteht in Ländern wie Russland und Nordkorea noch heute) und richtete unkontrolliert verheerende Schäden an, die vermeidbar gewesen wären.
Software bildet keine Ausnahme von dieser Symptomatik. Aufsehenerregende Fehlschläge wie die Einführung von healthcare.gov2 zeigen, dass „demokratische“ Prozesse, die ursprünglich Risiken reduzieren sollten, dazu tendieren, zu ins Stocken geratenden oder festgefahrenen Prozessen zu führen, die das Problem verschärfen.
Sowohl in traditionellen Ingenieursdisziplinen als auch im Bereich der Software führt der autoritäre Hochmodernismus in eine Zwickmühle: Entweder fährt man mit einem Zuviel an unkontrolliertem Autoritarismus in eine grandiose Katastrophe (Trainwreck-Szenario) – oder man fährt gar nicht mehr, weil ein Zuviel an Kontrollen und Gegenkontrollen praktisch keine Bewegung mehr zulässt (Stalled-Train-Szenario).
Zum Glück gelingt es der agilen Softwareentwicklung, entscheidungsfreudige Autorität und pluralistische Visionen zu vereinen und somit Risiken zu mindern, ohne die Entwicklung bis auf Schrittgeschwindigkeit abzubremsen. Die Grundprinzipien der agilen Entwicklung wurden im Jahr 2001 von einer Gruppe aus 17 Programmierern in einem Dokument festgehalten, das als das Agile Manifest bekannt wurde. Sie stellen eine Weiterentwicklung der pragmatischen Philosophie dar, die als Erstes explizit von der IETF übernommen wurde.
Der Preis für diese Agilität besteht in scheinbar anarchischen Fortschrittsmustern. Agile Entwicklungsmodelle katalysieren unlesbare kollektive Strukturen der Kreativität, schwächen Illusionen der Kontrolle und widersetzen sich jeder Vereinnahmung zum Zwecke des Vorantreibens utopischer Visionen. Durch die Übernahme agiler Modelle können Einzelpersonen und Organisationen nach und nach ihre eigene Angst angesichts des scheinbaren Chaos in den Griff bekommen. Auf diese Weise können agile Modelle im Laufe der Zeit noch agiler werden.
Agile Modelle treiben nicht nur Reformen im Softwarebereich voran, sondern springen auch auf jene traditionellen Bereiche über, in denen der autoritäre Hochmodernismus ursprünglich entstand. Allmählich verzehrt die Software auch Bereiche wie Forstwirtschaft, Stadtplanung und Umweltschutz. Open Geographic Information Systems (GIS) in der Forstwirtschaft, Open Data-Initiativen in der Stadtverwaltung und Überwachungstechnologien in der Landwirtschaft erhöhen die Verfügbarkeit von Informationen und beseitigen gleichzeitig umständlichen Papierkram. In den folgenden Essays werden wir sehen, dass jeder Bereich durch eine erhöhte Verfügbarkeit von Informationen und verringerte Widerstände hackerfreundlich werden kann. Sobald ein Bereich hackerfreundlich wird, wird er allmählich von der Software verzehrt. Die Entwicklung legt an Tempo zu: Der Zug kann immer schneller fahren, ohne ein Zugunglück zu verursachen, und die Zwickmühle wird aufgelöst.
Heutzutage ist der Wandel von Purismus zu Pragmatismus weit genug vorangeschritten, um sich auch auf der Ebene der Ökonomie der Softwareentwicklung bemerkbar zu machen. In vergangenen Jahrzehnten plädierten ökonomische Puristen je nach ideologischer Position mal für die idealisierte Open Source-, mal für die marktorientierte oder die staatlich gesteuerte Entwicklung von wichtigen Projekten. Doch sie alle sahen sich mit einer aufkommenden Realität konfrontiert, die zu komplex war, als dass eine ökonomische Ideologie sie beherrschen könnte. Somit blieben der ungefähre Konsens und laufende ökonomische Mechanismen vorherrschend gegenüber spezifischen ökonomischen Ideologien und festgefahrenen Debatten. Heute wurde jeder verfügbare ökonomische Mechanismus – marktorientiert, staatlich, Nonprofit oder sogar kriminell – auch an der Softwarefront eingesetzt. Der gleiche ökonomische Pragmatismus weitet sich ausserdem auf Bereiche aus, die von der Software gegessen wurden.
Dies ist eine natürliche Konsequenz aus dem dramatischen Anstieg sowohl der Partizipation in der Gesellschaft als auch der Ambitionen in der Welt der Software. 1943 hatte nur eine kleine Handvoll an Personen, die an geheimen Militärprojekten arbeiteten, Zugriff auf die ersten Computer. Selbst im Jahr 1974, dem Jahr des Höhepunkts der Zentralisierung, hatte nur eine kleine privilegierte Gruppe Zugang zu den frühen hackerfreundlichen Minicomputern wie beispielsweise der DEC PDP-Reihe. Doch schon 1993 hatte die PC-Revolution Bill Gates‘ Vision von einem Computer auf jedem Schreibtisch beinahe zur Wirklichkeit werden lassen – zumindest in den Industrienationen. Und im Jahr 2000 liessen Laptops und Blackberries bereits die Welt von heute erahnen, in der Smartphones nahezu für jedermann verfügbar sind und die Anzahl der Computer pro Person rasant in die Höhe schnellt.
Der Slogan der IETF, rough consensus and running code (RCRC), erwies sich als die einzig funktionsfähige Doktrin für sowohl die technologische Entwicklung als auch die unter diesen Bedingungen zugehörigen ökonomischen Modelle.
Durch den vorherrschenden Pragmatismus wurde ein nahezu unbeherrschbares prometheisches Feuer entfacht. Hunderttausende von Softwareunternehmern lassen Innovationen auf eine nichtsahnende Welt los, angetrieben durch eine Macht, die „niemand Bestimmtes“ihnen verliehen hatte, und mit allen erforderlichen ökonomischen Mitteln.
In genau diesem Kontext des angsteinflössenden Chaos und der Komplexität einer Massenblütezeit stellen wir die Frage: Was genau ist Software eigentlich?
[1] James Scott, Seeing Like a State, 1999.
[2] Das national Krankenversicherungsportal der USA, 2013 als Teil des Patient Protection and Affordable Healthcare Act gestartet.