Man braucht nur wenig Kapital, um grossartige Software zu erschaffen, und sogar noch viel weniger, um grossartige Software zu kopieren. Deshalb können in der Software-Welt Meinungsverschiedenheiten auf eine interessante Art und Weise gelöst werden, die in der Welt der Atome unmöglich wäre: Vorausgesetzt die Regeln zum Schutz geistigen Eigentums lassen das zu, können Einzelpersonen schlicht jeweils eine Kopie einer Software erstellen und unabhängig voneinander mit deren Entwicklung fortfahren. Das wird dies als Fork oder Abspaltung bezeichnet. Auf ähnliche Weise können produktive Kräfte gebündelt und Softwareprojekte zusammengeführt werden, ein Prozess, der als Merge bezeichnet wird. In der Unternehmenswelt gibt es zwar Vorgänge, die so ähnlich heissen, nämlich die Abpaltung oder Fusion von Unternehmen oder Unternehmensteilen. Aber bei ihnen handelt es sich um Nullsummenspiele. Um Softwarebereich kann das ganz anders sein.
Während Konflikte in demokratischen Prozesse zum Stillstand und zu einer Verzögerung der Entwicklung führen würden, resultieren aus ihnen im Geltungsbereich von rough consensus and running code und release early, release often konkurrierende, divergierende Entwicklungspfade, die mehrere mögliche Welten gleichzeitig erkunden.
Diese Methode der Konfliktlösung ist uns so radikal unvertraut,1 dass es fast drei Jahrzehnte dauerte, bis die ersten pragmatischen Hacker begannen, Forking als etwas Erstrebenswertes zu begreifen. Nachdem der Begriff „fork“ 1980 vom Unix-Hacker Eric Altman zum ersten Mal in diesem Sinne verwendet wurde, vergingen fünfundzwanzig Jahre, bis ein Tool entwickelt wurde, das Forking eher förderte, als es zu verhindern: git, entwickelt von Linus Torvalds im Jahr 2005. Git ist mittlerweile das weltweit meistgenutzte Codeverwaltungssystem und legte den Grundstein für Github, das führende Online-Code-Verzeichnis.
In der Softwareentwicklung funktioniert dieses Modell so gut, dass ein fast zwei Jahrhunderte altes industrielles Arbeitsmodell zugunsten eines Modells aufgegeben wird, das auf einer hochgradig offenen Zusammenarbeit, häufigen Abspaltungen und einer selbst gewählten Personalbesetzung bei Projekten basiert.
Besonders deutlich wird die Dynamik dieses Modells bei einigen modernen Programmierwettbewerben wie beispielsweise den periodischen Matlab-Programmierwettbewerben, die von MathWorks angeboten werden.
Häufig bieten solche Ereignisse den Teilnehmern die Möglichkeit, ihren in der Entwicklung befindlichen Code in kurzen Abständen in einem gemeinsamen Verzeichnis einzugeben. In der Frühphase sorgt die Veröffentlichung des Codes für eine schnelle Verbreitung der besten Entwicklungsideen unter den Wettbewerbern. Die Teilnehmer stimmen quasi für die vielversprechendsten Ideen, indem sie sie für ihre eigenen Entwicklungen nutzen und sich somit faktisch zu einer temporären Zusammenarbeit zusammenschliessen. Das Horten von Ideen oder Code erweist sich oft als kontraproduktiv, denn es ist wahrscheinlich, dass ein anderer Teilnehmer auf die gleiche Idee stossen und sie auf unerwartete Weise verbessern wird – oder eine Schwachstelle erkennt, die zu einem schnellen Scheitern („fail fast“) führen kann. Im weiteren Verlauf führt dieses Verfahren jedoch zu verzwickten Wettbewerbsverhältnissen, in denen eine schnelle Ausführung über die Qualität einer Idee siegt. Wenig überraschend gewinnt häufig ein Teilnehmer, der in letzter Minute eine kleine Änderung an der besten eingereichten Lösung vornimmt.
Solche Wettbewerbe, die in vereinfachter Form sowohl die Dynamik der Open-Source-Community als auch Praktiken in führenden Unternehmen sichtbar werden lassen, demonstrieren nicht nur das Leistungsvermögen von RCRC und RERO, sondern auch, warum hemmungsloses Forking und ein offener Austausch zu besseren Gesamtergebnissen führen.
Software, die in einer solchen Umgebung gedeiht, weist eine besondere Eigenschaft auf, die der Computerwissenschaftler Richard Gabriel als worse is better beschrieb.2 Funktionierender Code, der erkennbar einfach ist, eine effiziente Zusammenarbeit und zügige Experimente fördert, tendiert dazu, sich schnell und unvorhersehbar zu verbreiten. Überfrachteter Code hingegen, der autoritäre puristische Bedenken wie formale Richtigkeit, Konsistenz und Vollständigkeit in den Vordergrund stellt, tendiert zum Aussterben.
Im echten Leben bilden sich Teams per Selbstauswahl rund um grossartigen Code, der üblicherweise nicht bei einem Wettbewerb entstanden ist, sondern von einem oder zwei Programmierern geschrieben wurde, die den Kern des Teams bilden. Meistens sind die Teammitglieder mindestens flüchtig miteinander bekannt, sodass Produktteams selten auf mehr als wenige Dutzend Mitglieder anwachsen. Entwickler, denen es nicht gelingt, sich erfolgreich zu integrieren, verlassen das Team oft schon nach kurzer Zeit. Wenn sie das Team nicht verlassen können oder wollen, werden sie oft explizit darum gebeten, sich zurückzuhalten und auf die aktive Mitwirkung zu verzichten. Wenn sie dennoch darauf bestehen, werden sie aktiv gemieden und vom Geschehen ausgeschlossen.
Wie gross das optimale Team sein sollte, ist umstritten, doch die „Zwei-Pizza-Regel“ von Jeff Bezos legt nahe, dass es nicht mehr als zwölf Personen umfassen sollte.3
Die Qualität der Software, die von Teams anonymer, austauschbarer Entwickler mit einer bürokratischen Top-Down-Personalstruktur entwickelt wird, ist oft grauenhaft – im krassen Gegensatz zu dem hochwertigen Code, der in „worse is better“-Prozessen entsteht. Das Ergebnis einer solchen Softwareentwicklung kann man umgekehrt als „better is worse“ bezeichnen: utopische Visionen, die bei der Implementierung vorhersehbarerweise scheitern, wenn sie denn jemals über den Status der Vaporware hinausgelangen.
Ein sehr treffendes Beispiel hierfür ist das IBM OS/2-Projekt der frühen neunziger Jahre,4 das als Nachfolger des damals vorherrschenden Betriebssystems MS-DOS konzipiert war. Jeder der mehreren Tausend mitwirkenden Programmierer sollte lediglich zehn Zeilen Code am Tag entwickeln, schreiben, debuggen, dokumentieren und unterstützen. Wenn jemand mehr als zehn Zeilen schrieb, galt dies als unverantwortlich. Projektkalkulationen wurden errechnet, indem die Anzahl der Codezeilen im fertigen Projekt geschätzt, durch die Anzahl der dem Projekt zugewiesenen Tage geteilt und anschliessend das Ergebnis durch 10 geteilt wurde, um so die Anzahl der Programmierer zu ermitteln, die dem Projekt zugewiesen werden sollten. Es ist unnötig zu erwähnen, dass diese Programmierer als vollständig austauschbar galten. Die für die Fertigstellung eines Projektes erwartete „Planungs“zeit konnte jederzeit beliebig halbiert werden, indem die Anzahl der zugewiesenen Entwickler verdoppelt wurde.5 Gleichzeitig konnten Dutzende Manager im gesamten Unternehmen ihre Genehmigung verweigern und eine Veröffentlichung zurückhalten, ein Vorgang, der ominöserweise als Nichtübereinstimmung („nonconcurrence“) bezeichnet wurde.
„Worse is better“ kann für diejenigen, die an die Arbeitsprozesse des Industriezeitalters gewöhnt sind, einen regelrechten Kulturschock darstellen. Die häufigste Beschwerde besteht darin, dass typischerweise einige wenige schnell wachsende Startups und Open-Source-Projekte einen grossen Teil der talentierten Arbeitskräfte einer Region zu einer gegebenen Zeit für sich beanspruchen und es somit anderen Projekten schwer machen, selber zu wachsen. Um dem Ganzen die Krone aufzusetzen, scheint dieser Prozess gelegentlich die kapriziösesten und albernsten Projekte zu übersättigen, während wichtig erscheinende Projekte ausgehungert werden. Dieser Prozess, in dem die talentiertesten Köpfe unvorhersehbar andere Vorhaben aufgeben und sich um einige wenige Möglichkeiten scharen, ist unerbittlich. Er macht einzelne ausgewählte Produkte zu Gewinnern und lässt eine grosse Zahl an Verlierern und gescheiterten Projekten zurück, sodass jeder mit festen autoritären Ansichten zu „guten“ und „schlechten“ Technologien tief enttäuscht wird.
Doch dieses Modell funktioniert nicht nur, sondern es schafft auch einen enormen neuen Wohlstand durch Startups im Technologiebereich und Open-Source-Projekte. Mittlerweile werden die ihm zugrunde liegenden Konzepte wie ungefährer Konsens, Pivot, fast failure, unendliches beta, hemmungsloses Forking, selbstbestimmte Mitarbeit (opt-in) und worse is better auch auf andere Bereiche als Software übertragen und weit über das Silicon Valley hinaus angewandt. Dort, wo sie hingelangen, treten beschränkende autoritäre Visionen und puristische Ideologien den Rückzug an.
Sicherlich birgt dieser Ansatz auch Risiken und nur ein unverbesserlicher Optimist würde sie leugnen. Das Internet von heute ist das Ergebnis von Millionen pragmatischer, zweckdienlicher Entscheidungen von Hunderttausenden Einzelpersonen, die laufenden Code erschafften – und zum Zeitpunkt ihrer Entstehung machten all diese Entscheidungen Sinn. Zweifellos trugen diese Entscheidungen zu den ernsthaften Problemen bei, mit denen wir uns heute konfrontiert sehen, von der unzureichenden Sicherheit von Internetprotokollen bis zu dem viel diskutierten Problem der Netzneutralität. Doch wenn die pragmatische Herangehensweise nicht gesiegt hätte, hätte sich das Internet über das ursprüngliche ARPANET hinaus wohl kaum nennenswert weiterentwickelt. Anstatt eine florierende Internetwirtschaft zu entwickeln, die eine Wiederbelebung der alten Wirtschaft verheisst, wäre womöglich die ganze Welt Japan in die puristische Sackgasse des Grossrechners der fünften Generation gefolgt.
Gegenwärtig werden obendrein mehrere Ansätze verfolgt, um solche aus der Vergangenheit herrührenden ernsthaften Probleme zu lösen, beispielsweise die Blockchain-Technologie (die Softwaregrundlage für Kryptowährungen wie Bitcoin). Sie sind um einiges kreativer als die in den Anfangsjahren des Internets diskutierten Lösungen und zeugen von einem Verständnis der tatsächlich aufgetretenen Probleme, anstatt die limitierenden Ängste autoritärer hochmodernistischer Visionen zu reflektieren. Wichtiger noch: Sie bestätigen die anfängliche Entscheidung, der vorzeitigen Optimierung zu widerstehen und so viel kreativen Freiraum wie möglich für zukünftige Innovatoren zu lassen. Wenn aufstrebende Lösungen Erfolg haben, gelangen natürlich auch weitere lauernde Probleme an die Oberfläche, die wiederum in der fortlaufenden pragmatischen Tradition des unendlichen Beta gelöst werden müssen.
Unsere Beschreibung des Wesens der Software sollte zu einer offensichtlichen Schlussfolgerung führen: Es handelt sich um eine zutiefst subversive Kraft. Für diejenigen, die sich auf der falschen Seite dieser Kraft befinden und von den Blitzkrieg-Massnahmen eines hochfunktionalen agilen Softwareteams getroffen werden, kann sich dies wie eine ständig zunehmende Zemblanität anfühlen: Es entsteht ein Gefühl des unweigerlich bevorstehenden Untergangs.
Schon häufiger überkam die gesamte traditionelle Wirtschaft ein allgemeines Gefühl der Zemblanität. Jedes aggressiv wachsende Startup wirkt wie eine Spezial-Kampfeinheit, dicht gefolgt von einer Besatzungsarmee aus Robotern und jobfressenden Programmen des maschinellen Lernens.
Intern wird die von Software verzehrte Wirtschaft noch stärker von Disruptionen angetrieben: Die Zeit, die vergeht, bis eine disruptive Kraft selbst disruptiert wird, ist innerhalb der letzten zehn Jahre stark gesunken – und die Startups von heute sind sich dieses Risikos sehr bewusst. Das erklärt auch die rauhe Aggressivität, mit der sie vorgehen.
Es ist verständlich, dass Software, die die Welt verzehrt, für diejenigen, die sich in einer traditionellen Wirtschaftsform befinden, nach einem erbitterten Krieg zwischen der Technologie und der Menschheit klingt.
Doch tatsächlich ist genau das Gegenteil der Fall. Im Gegensatz zu Krieg und zur Hochfinanz im Stil der Wall Street ist der technische Fortschritt kein Nullsummenspiel, und darin liegt der entscheidende Unterschied. Die prometheische Macht der Technik ist heutzutage – und seit jeher – die Macht, die die Menschheit aus ihren schwersten Krisen befreite, auch wenn es bereits unmöglich schien, den Zusammenbruch der Zivilisation zu verhindern. Nach jedem einzelnen technischen Fortschritt von der Erfindung der Schrift bis zur Erfindung des Fernsehens prophezeiten diejenigen, die das Wesen des technischen Fortschritts als Nicht-Nullsummenspiel nicht begreifen konnten, unseren Untergang – und jedes Mal lagen sie falsch. Jedes Mal argumentierten sie auf die eine oder andere Weise, dass dieses Mal alles anders sei, und wurden eines Besseren belehrt.
Die Menschheit erlitt keinen Zusammenbruch der Zivilisation, sondern erhob sich jedes Mal auf eine neue Ebene des Wohlstands.
Natürlich sind diese dürftigen Belege für vorausgesagte und nicht eingetroffene gesellschaftliche Zusammenbrüche kein ausreichender Beweis dafür, dass es diesmal nicht doch anders sein kann. Es gibt schliesslich keinen zwingenden Grund für die Annahme, die Zukunft müsse so sein wie die Vergangenheit. Genausowenig gibt es einen zwingenden Grund dafür, dass unsere moderne globalisierte Gesellschaft auf einzigartige Weise immun gegen jene Sorte Mega-Katastrophen sein sollte, die zum Untergang des Römischen Reiches oder der Zivilisation der Maya geführt haben. Bei jedem technischen Fortschritt muss von neuem dessen Zukunftstauglichkeit erörtert werden, und neu auftauchende Bedenken wie aktuell der Klimawandel sind sehr ernstzunehmen.
Doch Bedenken, das Spiel könne enden, sollten uns nicht dazu bringen, uns auf die vom Philosophen James Carse6 als finite game bezeichnete Weltsicht zu beschränken, die darauf beruht, zu „gewinnen“ und als Preis einen unveränderlichen, reinen und utopischen Zustand zu erlangen. Im nächsten Essay werden wir aufzeigen, dass die richtige Denkweise in dem besteht, was Carse als infinite game-Sichtweise bezeichnete, der es darum geht, das Spiel auf eine zunehmend produktive Art und Weise weiterzuspielen. Wenn man von einem nie endenden Spiel ausgeht, ist Software, die die Welt verzehrt, tatsächlich das Beste, das der Welt passieren konnte.
[1] Der Gedanke der Abspaltung als Mechanismus der Konfliktlösung, der durch die Möglichkeit des kostenfreien Kopierens bzw. das rivalitätsfreie Wesen der Software entstand, ist eng verbunden mit dem Begriff des exit in Albert O. Hirschmans bekanntem Modell des Dissens als Entscheidung zwischen exit und voice, d. h. zwischen dem Verlassen einer Organisation oder Situation und dem Versuch einer aktiven Veränderung oder dem Äussern von Beschwerden. Dies bietet uns einen weiteren Ansatzpunkt, um das Wesen der Software zu verstehen: Wenn es darum geht, einen Widerspruch oder eine abweichende Meinung zum Ausdruck zu bringen, favorisiert sie exit gegenüber voice. Dies führte nicht nur zur gemeinsamen Nutzung von Code, sondern beispielsweise auch zur Beliebtheit des Gesetzes der zwei Füsse auf informellen Unkonferenzen im Technologiebereich, einer sozialen Norm, die es Teilnehmern freistellt, Vorträge und Sitzungen, an denen sie nicht interessiert sind, zu verlassen, anstatt aus Höflichkeit gegenüber dem Redner zu bleiben. Balaji Srinvasan regte in einem Vortrag im Jahr 2013 zu dem Gedanken an, der Ausstieg könne auch bei Dissens im breiteren politischen Sinne zur besseren Option werden. Diese Anregung löste Protest unter politischen Mainstream-Kommentatoren aus, die darin eine sezessionistische Gesinnung und Verantwortungslosigkeit sahen. Balaji und andere haben seitdem darauf hingewiesen, dass eine solche Assoziierung unnötig ist. Software bietet kreative Möglichkeiten für Ordnungsmodelle, die den Ausstieg standardmässig einplanen, beispielsweise Bruno Freys Konzept der Functional, Overlapping, Competing Jurisdictions (FOCJ, zu Deutsch „funktional überlappende konkurrierende Hoheit“) oder Ideen wie Charter Cities, die eine Entsprechung der „Abstimmung mit den Füssen“ auf der Ebene ganzer Städte umfassen. Es gibt auch „softe“ Exit-Modelle, die den Ausdruck abweichender Verhaltensweisen durch die Auswahl virtueller Kontexte umfassen. Auf einer alltäglicheren Ebene ist der vom Ausstieg getriebene politische Dissens bereits ein wesentliches ökonomisches Phänomen. Die Idee einer regulatorischen Arbitrage – dem Überqueren von Grenzen durch Einzelpersonen und Unternehmen, um die Vorteile freundlich gesinnter politischer Systeme zu nutzen – ist in vielen Nationen bereits Realität. Angesichts der fortlaufenden Experimente mit raffinierten neuen Konzepten der Staatsbürgerschaft, beispielsweise der E-Staatsbürgerschaft in Estland, werden diese Dynamiken sich weiter verstärken.
[2] Der Satz worse is better durchlief eine facettenreiche Geschichte, seit er von Gabriel 1989 in einem Essay geprägt wurde. Zunächst war er nur als halb ernst gemeinter zynischer Kommentar zu einem neuen Trend in der Entwicklung beabsichtigt und nicht als Werturteil. Kritik und neue Überlegungen liessen ihn von der Bestätigung dieser Idee in dem unter einem Pseudonym veröffentlichten Folgeessay Worse is Better is Worse zurücktreten. Von diesem Punkt an wird die Geschichte noch komplizierter und es lohnt sich, sie in Gabriels eigenen Worten nachzulesen. Letztendlich schien sich Gabriel persönlich für eine ambivalente Haltung zu entscheiden. Im Softwarebereich entwickelte der Satz jedoch ein lebhaftes und polarisierendes Eigenleben. Für Pragmatiker wurde er zum Statement für ein leistungsstarkes Prinzip und eine betriebliche Wahrheit. Für Puristen wurde er zu einem ständigen Lamento.
[3] Siehe das Wall Street Journal-Profil von Jeff Bezos von 2011, Birth of a Salesman, als Belegstelle für die „Zwei-Pizza-Regel“. Das Konzept war jedoch schon deutlich länger ein Bestandteil der Folklore der Technikbranche.
[4] Diese Beschreibung basiert auf Gesprächen mit Marc Andreessen über seine Erinnerung an die Arbeit bei IBM in den frühen neunziger Jahren.
[5] 1975 war schon weithin bekannt, dass ein bereits verzögertes Projekt sich noch weiter verzögert, wenn Entwickler hinzugezogen werden (ein Prinzip, das als „Brooksches Gesetz“ bekannt wurde), siehe The Mythical Man Month von Frederick Brooks. Das Prinzip entstand ironischerweise aus einem IBM-Projekt.
[6] James Carses dichte Mischung aus Poesie und Metaphysik in Finite and Infinite Games ist strenggenommen von wenig direkter Relevanz für die Ideen dieser Essays. Philosophisch veranlagte Leser finden darin jedoch das wahrscheinlich ausführlichste philosophische Plädoyer für pragmatische anstelle puristischer Methoden, einem Hacker-Ethos anstelle eines auf formalen Qualifikationen basierenden Ethos und einer prometheischen anstelle einer bukolischen Ästhetik.