# Die Geburt von Linux! ### Kapitel Eins **Helsinki, Herbst 1991.** Der Raum ist klein. Zu klein für das, was in ihm entsteht. Ein schmales Bett an der Wand, ein Schreibtisch, dessen Oberfläche von Kratzern und Brandflecken gezeichnet ist. Darauf Disketten in dünnen Papiertaschen, handbeschriftet, manche schon mehrfach überschrieben. Ausdrucke mit endlosen Textzeilen liegen übereinander, die Ränder eingerissen vom häufigen Umblättern. Kabel ziehen sich über den Boden, als hätten sie keinen festen Platz gefunden. Der Computer läuft seit Stunden. Ein gleichmäßiges Summen erfüllt den Raum. Das tiefe Brummen des Netzteils, das unregelmäßige Klicken der Festplatte. Auf dem Bildschirm stehen grüne Buchstaben auf schwarzem Grund. Keine Fenster, keine Symbole, keine Maus. Nur Text. Der Cursor blinkt. Geduldig. Unerbittlich.  Draußen ist es still. Der finnische Herbst verliert langsam den Kampf gegen den Winter. Das Licht verschwindet früh, der Himmel bleibt grau. Helsinki ist keine laute Stadt, und um diese Uhrzeit scheint sie fast zu verschwinden. Autos fahren selten, Stimmen hört man kaum. Die Welt zieht sich nach innen zurück. Ich bin wach.  Ich heiße L.... T..... Einundzwanzig Jahre alt. Student. Die Welt weiß nichts von mir — und hat auch keinen Grund dazu. 1991 ist ein Jahr des Übergangs. Niemand nennt es so, aber man spürt es. Alte Gewissheiten lösen sich auf, ohne dass neue bereits festen Halt bieten. Der Kalte Krieg ist vorbei, zumindest sagt man das. Die Nachrichten zeigen Bilder von zerfallenden Symbolen, von Fahnen, die eingeholt werden. Die Sowjetunion wankt, auch wenn sie offiziell noch existiert. Grenzen, die jahrzehntelang unverrückbar schienen, beginnen zu verschwimmen. Europa hält den Atem an. Gleichzeitig wirkt vieles erstaunlich unverändert. Computer stehen nicht in jedem Haushalt. Telefone hängen an Wänden, mit Kabeln, die sich verdrehen. Wer jemanden erreichen will, muss warten — oder hoffen. Informationen reisen langsam. Nachrichten kommen aus Zeitungen, aus dem Radio, aus dem Fernsehen zu festen Uhrzeiten. Und doch gibt es Risse in dieser Welt. Der Rechner vor mir ist kein Luxus. Ein Intel‑80386‑Prozessor mit 33 Megahertz. Vier Megabyte Arbeitsspeicher. Eine Festplatte, deren Geräusche ich inzwischen besser kenne als manche Stimme. Kein Internet, wie man es sich später vorstellen wird. Keine Webseiten. Kein permanentes Verbundensein. Aber es gibt Verbindungen. Modems pfeifen und kreischen, wenn sie sich einwählen. Daten bewegen sich langsam, Zeile für Zeile. In Newsgroups diskutieren Menschen, die sich nie gesehen haben. E‑Mails brauchen Minuten, manchmal Stunden. Trotzdem fühlt es sich an wie Magie: Gedanken reisen durch Leitungen, über Ländergrenzen hinweg. Computer sind Werkzeuge für Büros, Universitäten, Labore. Für die meisten Menschen sind sie fremd, kompliziert, unnahbar. Spielekonsolen stehen in Kinderzimmern, Walkmans in Jackentaschen. CDs beginnen, Kassetten zu verdrängen. Alles ist physisch, greifbar, schwer. Software kommt in Kartons. Und fast alles ist abgeschlossen. Man darf Computer benutzen, aber nicht verstehen. Man darf Programme starten, aber nicht sehen, wie sie funktionieren. Das Innere der Maschine bleibt verborgen, geschützt durch Lizenzen, Verträge, Unsichtbarkeit. Ich habe mich nie damit zufriedengegeben. Schon früh wollte ich wissen, warum Dinge tun, was sie tun. Nicht nur wie man sie bedient, sondern warum sie reagieren. Und was passiert, wenn man eingreift. Ein Computer ist für mich kein Gerät, sondern ein Gesprächspartner — manchmal stur, oft gnadenlos ehrlich. Der Bildschirm flackert kurz. Eine neue Zeile erscheint. Ich tippe langsam, konzentriert. Jeder Befehl ist präzise. Ein Fehler genügt, und alles bricht zusammen. Dann wird der Bildschirm schwarz, der Cursor verschwindet, und Stunden von Arbeit lösen sich auf. Ich atme aus. Starte neu. Es gibt keine klaren Anleitungen für das, was ich hier tue. Wissen ist fragmentiert. Dokumentationen sind unvollständig. Antworten findet man in Textdateien, auf Servern irgendwo auf der Welt, geschrieben von Menschen, die man nie treffen wird. Und doch fühlt man sich nicht allein. Nächte vergehen. Tage verschwimmen. Der Rhythmus der Welt draußen verliert an Bedeutung. Kaffee wird kalt. Essen bleibt stehen. Die Uhrzeit spielt keine Rolle mehr. Nur der nächste Schritt. Die nächste Zeile Code. Irgendwann formt sich ein Gedanke, der sich nicht mehr ignorieren lässt. Er kommt nicht als Vision. Nicht als großer Plan. Eher als leises Unbehagen. Was, wenn Programme nicht genug sind? Was, wenn die eigentliche Macht tiefer liegt — dort, wo entschieden wird, welche Programme überhaupt laufen dürfen? Wo die Maschine selbst gelenkt wird? Der Cursor blinkt. Ich sehe ihn an. Lange. Dann lege ich die Hände auf die Tastatur. Draußen wird es kälter. Die Welt verändert sich, auch wenn niemand genau sagen kann, wohin. Systeme zerfallen. Neue entstehen, tastend, unsicher. In diesem Zimmer, in dieser Nacht, beginnt etwas Kleines. Unauffällig. Zerbrechlich. Noch trägt es keinen Namen. Noch weiß niemand davon. Aber die Zeit ist bereit.  --- ## Kapitel 2 ## Die Welt der Betriebssysteme! Der Campus der Universität Helsinki liegt nur wenige Kilometer von meiner Wohnung entfernt, aber die Rechner dort sind eine andere Welt. Die Terminals stehen in langen Reihen, ihre Bildschirme glimmen grün im gedämpften Licht. Wenn ich zwischen den Vorlesungen hierherkomme, setze ich mich an einen freien Platz und tauche ein in Systeme, die größer sind als alles, was ich zu Hause betreiben kann. Einen festen Platz habe ich nicht. Niemand hat das. Man kommt, sucht sich eine freie Maschine, arbeitet, bis der nächste sie braucht. Aber ich kenne die Zeiten, in denen es ruhig ist. Die frühen Morgenstunden, bevor die ersten Vorlesungen beginnen. Die späten Abende, wenn die meisten längst zu Hause sind. Dann habe ich die Terminals manchmal stundenlang für mich. In diesen Stunden ist der Raum wie mein eigenes Labor. Nur das Summen der Lüfter, das leise Klackern der Tastatur und ich. *UNIX*.  Der Name klingt nach Klarheit. Nach Struktur. Nach etwas, das von Leuten gebaut wurde, die wussten, was sie taten. Hier kann ich mehrere Programme gleichzeitig laufen lassen. Hier sind Prozesse voneinander getrennt. Wenn eines abstürzt, reißt es die anderen nicht mit. Hier gibt es echte Speicherverwaltung, Zugriffsrechte, eine durchdachte Hierarchie. Ich sitze vor diesen Terminals und spüre, das ist Architektur. Kein zusammengewürfeltes Provisorium, sondern ein Gebäude, das von Grund auf entworfen wurde. Kleine Werkzeuge, die sich kombinieren lassen. Alles an seinem Platz. Manchmal ertappe ich mich dabei, wie ich einfach nur dasitze und die Struktur bewundere, so wie andere ein Gemälde betrachten. Die Eleganz, mit der alles zusammenhängt. Die Art, wie kleine Programme sich zu großen Lösungen fügen. Aber es bleibt ein Gebäude, das mir nicht gehört. Der Quellcode von *UNIX* ist lizenziert, geschützt, teuer. Die Bell Laboratories haben ihn geschaffen, und jetzt kontrollieren Unternehmen, wer ihn sehen darf. Als Student kann ich das System benutzen, aber ich kann nicht verstehen, warum es tut, was es tut. Das Wissen bleibt verschlossen. Es ist, als dürfte man ein wunderschönes Buch lesen, aber alle Seiten, die erklären, wie die Buchstaben dorthin kamen, sind herausgerissen. Manchmal, spät abends, wenn ich allein im Terminalraum bin und die grünen Zeilen über den Bildschirm fließen, überkommt mich eine seltsame Mischung aus Bewunderung und Frustration. Ich sehe, was möglich ist. Ich spüre, wie durchdacht alles ist. Aber ich kann nicht hineinsehen. Ich bin Besucher, nicht Bewohner. Dann ist da *MS-DOS*. Das läuft zu Hause, auf meinem eigenen Rechner. C>: erscheint auf dem Bildschirm, und dahinter liegt nichts als Gehorsam. DOS tut, was ich sage, aber es tut nicht viel. Programme laufen nacheinander, als müssten sie sich anstellen. Der Speicher ist eng. 640 Kilobyte, dahinter beginnt ein Bereich, den man nur mit Tricks erreicht. Und selbst diese Tricks sind nicht wirklich Verstehen, sie sind Zaubersprüche, die man auswendig lernt, ohne zu wissen, warum sie wirken. DOS ist direkt, fast ehrlich. Aber es ist auch ein Käfig. Sein Innerstes bleibt mir verborgen, gehört jemand anderem. Wenn ich DOS starte, habe ich das Gefühl, in einem fremden Haus zu wohnen. Ich darf die Möbel benutzen, aber ich darf nicht fragen, wie sie gebaut sind. Ich darf nicht in den Keller sehen. Ich wechsle zwischen diesen Welten hin und her und spüre, dass etwas fehlt. Etwas Grundlegendes. Dann, in einem Semester, stoße ich auf *MINIX*. Andrew Tanenbaum, Professor in Amsterdam, hat ein Lehrbuch geschrieben: „Operating Systems: Design and Implementation“. Und in diesem Buch steht der vollständige Quellcode eines Betriebssystems. Seite für Seite abgedruckt. MINIX. Ich erinnere mich noch an den Moment, als ich das Buch zum ersten Mal in der Bibliothek aufschlug. Ich stand da, zwischen den Regalen, und blätterte zu den Seiten mit dem Code. Da war es. Zeile für Zeile. Alles. Ich konnte es kaum glauben. Meine Hände zitterten leicht, als ich weiterblätterte. Zum ersten Mal hatte ich das Gefühl, dass mir jemand nicht nur das Ergebnis zeigt, sondern den gesamten Weg dorthin. MINIX ist klein. Bewusst klein. Es soll erklären, nicht wachsen. Veränderungen sind möglich, aber sie sollen nicht weitergegeben werden. Das System will unterrichten, nicht leben. Es ist wie ein Schmetterling unter Glas. Wunderschön anzuschauen, aber er wird nie fliegen. Und dann ist da die Lizenz. MINIX gehört Tanenbaum. Man darf es studieren, aber man darf nichts Eigenes daraus machen. Es bleibt sein Geschenk an die akademische Welt. Aber Geschenke haben Bedingungen. Ich spüre Dankbarkeit, aber auch eine leise Enttäuschung. So nah am Verstehen, und doch wieder eine Mauer. In den Pausen zwischen den Vorlesungen, in den Nächten, in denen der Compiler läuft und ich auf den nächsten Test warte, denke ich darüber nach. Die Gedanken kreisen, finden keine Ruhe. Es gibt MS-DOS: nah an der Hardware, aber primitiv und verschlossen. Es ist wie ein Werkzeug, das man benutzt, ohne zu verstehen, wie es geschmiedet wurde. Es gibt UNIX: mächtig, elegant, aber unerschwinglich und kontrolliert. Die Kathedrale, in die man nur als Besucher darf. Es gibt MINIX: offen im Code, aber begrenzt im Anspruch. Das schöne Modell, das nie Wirklichkeit werden soll. Was fehlt, ist etwas anderes. Etwas, das die Stärken vereint. Etwas, das man wirklich besitzen kann. Nicht im rechtlichen Sinne, sondern im Sinne von Verstehen. Etwas, das wachsen darf, weil es nicht eingezäunt ist. Die Sehnsucht danach wird stärker mit jedem Tag, mit jeder Zeile Code, die ich lese. Ich denke an Richard Stallman und sein GNU-Projekt. Er hat verstanden, worum es geht: Software soll befreien, nicht einsperren. Als ich zum ersten Mal das GNU-Manifest las, saß ich nachts auf meinem Bett, das Buch auf den Knien, der Rechner noch warm vom Kompilieren. Draußen war es still. Und während ich las, merkte ich, dass mich diese Worte nicht nur technisch trafen, sondern persönlich. Dass Software keine Ware sein muss, sondern etwas sein kann, das man teilt, wie Wissen, wie Freundschaft. Aber sein Kernel, der Hurd, lässt auf sich warten. Das Projekt ist riesig, komplex, schwer zu durchdringen. Ich bewundere Stallman, aber sein Traum ist so groß, dass er kaum zu fassen ist. Vielleicht braucht es etwas Kleineres. Etwas, das ein Mensch wirklich im Kopf behalten kann. Etwas, das anfängt wie MINIX. Überschaubar, verständlich. Aber dann weitergehen darf. Keine Kathedrale, sondern eine Werkstatt. Ein Ort, an dem man bauen kann, ohne erst Architektur studiert zu haben. Keine große Vision. Noch nicht. Nur eine Ahnung, dass die Lücke, die ich zwischen all diesen Systemen spüre, nicht zufällig ist. Sie wartet darauf, gefüllt zu werden. Und je länger ich darüber nachdenke, desto mehr fühle ich, dass diese Lücke vielleicht genau auf mich wartet. Auf jemanden, der versteht, was fehlt, weil er selbst darunter leidet. Ich schließe die Tür zum Terminalraum hinter mir. Die grünen Bildschirme erlöschen, das Summen der Klimaanlage verklingt. Draußen ist es kalt, der Wind trägt den Geruch von Schnee. Die Luft beißt in der Lunge, weckt mich auf aus den Gedanken. Zurück in meinem Zimmer. Der eigene Rechner, das vertraute Summen, der blinkende Cursor. Hier riecht es nach mir, nach meinen Nächten, meinem Kaffee, meinen Ausdrucken. Hier bin ich nicht Besucher. Ich habe gesehen, was möglich ist. Ich habe gesehen, was fehlt. Der Unterschied zwischen den Systemen ist nicht nur technisch. Es ist ein Unterschied in der Haltung. Die einen schließen ein, die anderen öffnen. Die einen lehren, die anderen lassen lernen. Die einen geben dir ein fertiges Haus, die anderen zeigen dir, wie man Steine setzt. Ich setze mich an den Schreibtisch. Vor mir liegt kein Buch, keine Lizenz, keine Einschränkung. Nur die Maschine und die Frage, was ich aus ihr machen will. Noch weiß ich nicht, wie die Antwort aussieht. Aber ich weiß, dass ich sie nicht in einem Terminalraum finden werde, nicht in einem Buch, nicht in einem fertigen System. Sondern hier. In diesem Zimmer. In den Zeilen, die ich selbst schreibe. Ich schalte den Rechner ein. Der Bildschirm flackert kurz, dann erscheint die Eingabeaufforderung. Ich öffne einen Editor. Ein leeres C‑File. Der Cursor blinkt. Ich weiß noch nicht, wie die ersten Zeilen aussehen werden. Aber ich weiß, dass ich sie bald schreiben werde. Und zum ersten Mal fühlt sich das nicht wie eine Einschränkung an. Sondern wie eine Möglichkeit.  --- ## Kapitel 3 ## Die ersten Zeilen! Die Entscheidung ist gefallen. Ich weiß noch nicht, wann genau es passiert ist. Es gab keinen einzelnen Moment, keinen dramatischen Entschluss. Nur viele Nächte des Nachdenkens, des Vergleichens, des Spürens, dass etwas fehlt. Und dann, irgendwann, die schlichte Erkenntnis: Ich werde es selbst machen. Kein großes Projekt. Keine Ankündigung. Nur ein leiser Vorsatz, den ich mit mir trage, als ich mich eines Abends an den Schreibtisch setze. Am Anfang steht kein Betriebssystem. Nur ein Terminal-Emulator. Ich will von meinem PC aus auf die UNIX-Rechner der Universität zugreifen. Ein einfaches Programm, das mir erlaubt, mich einzuwählen, Befehle zu senden, Ausgaben zu empfangen. Nichts Besonderes. Nur ein Werkzeug für den Alltag. Ich beginne zu schreiben. Tastatureingaben abfangen. Bildschirmausgaben darstellen. Die Verbindung über die serielle Schnittstelle. Kleine, überschaubare Stücke, die sich zusammenfügen. Der Code wächst, Zeile für Zeile, und mit jedem Schritt verstehe ich mehr. Es funktioniert. Der Terminal-Emulator läuft. Ich kann mich einloggen, arbeiten, bin verbunden mit den großen Maschinen der Uni. Doch während ich programmiere, merke ich etwas. Die Dinge, die ich baue – Tastatur-Treiber, Bildschirm-Ausgabe, Speicher-Verwaltung für die Puffer – das sind keine Teile eines Terminal-Programms mehr. Das sind die Grundbausteine von etwas Größerem. Warum aufhören? Der Gedanke kommt nicht als Vision. Kein Blitz, keine Erleuchtung. Nur eine leise Frage, die sich immer wieder in den Vordergrund schiebt. Ich versuche, sie zu ignorieren, mich auf den Emulator zu konzentrieren. Aber sie bleibt. Sie wird lauter. Was genau ich da baue, weiß ich selbst noch nicht genau. Kein Plan. Keine Roadmap. Nur Neugier. Nur das Gefühl, dass all das Wissen, das ich in den letzten Monaten aufgesogen habe – aus Tanenbaums Buch, aus den Nächten im Terminalraum, aus dem Studium von MINIX – jetzt einen Weg nach draußen sucht. Einen Weg, etwas Eigenes zu werden. Die Frage bleibt im Raum, während ich den Emulator teste, während ich Fehler korrigiere, während ich in den Nächten vor dem Bildschirm sitze. Sie verschwindet nicht. Manchmal, wenn die Zeilen vor meinen Augen verschwimmen und ich nicht mehr weiterweiß, ist es etwas ganz anderes, das mich rettet. **Randi.** Meine kleine Katze, grau getigert mit weißen Pfoten, die immer aussieht, als hätte sie in Milch gepatscht. Sie hat ihren eigenen Kopf, wie alle Katzen. Aber wenn ich lange genug gesessen habe, kommt sie angeschlichen, stupst mit der Pfote gegen mein Bein, verlangt Aufmerksamkeit. Ihr Schnurren ist das einzige Geräusch, das ich neben dem Summen des Computers ertrage. Manchmal lege ich die Tastatur zur Seite und streichele sie, einfach um für ein paar Minuten nicht an Speicherverwaltung und Prozessoren denken zu müssen.  In diesen kurzen Pausen kehrt etwas zurück, das im Tasten und Compilieren oft verloren geht. Das Gefühl, dass es eine Welt gibt jenseits des Bildschirms. Eine Welt, in der Katzen schnurren und Schnee fällt und die Stadt lebt, auch wenn ich sie gerade nicht sehe. Dann, wenn Randi wieder zufrieden auf ihrem Platz auf dem Bett zusammengerollt ist, wende ich mich zurück zum Bildschirm. Irgendwann, an einem Abend, als der Schnee wieder fällt und die Stadt verstummt, öffne ich eine neue Datei. Der Emulator ist fertig. Er tut, was er soll. Aber ich bin es nicht. Die neue Datei hat keinen Namen, keinen Kommentar. Nur eine leere Fläche, auf der ich entscheiden muss, was als nächstes kommt. Der Cursor blinkt. Das vertraute Grün auf Schwarz. Zum ersten Mal seit Wochen fühlt es sich nicht wie eine Aufgabe an. Sondern wie eine Einladung. Ich beginne mit dem, was mich am meisten interessiert: dem Task-Switching des 386ers. Der Prozessor hat etwas Wunderbares. Er kann von sich aus zwischen verschiedenen Aufgaben hin und her springen. Man muss ihm nur sagen, wie. Man muss Tabellen anlegen, Register setzen, Deskriptoren definieren. Die Theorie steht in den Handbüchern, die ich mir von der Universität ausgeliehen habe. Die Praxis liegt jetzt vor mir. Die erste Zeile ist unspektakulär. Eine Definition, eine Initialisierung, nichts, was später einmal jemand bewundern würde. Aber sie ist der erste Stein. Der Grundstein. Ich tippe. Der Compiler läuft. Fehler. Ich korrigiere. Neu compilieren. Wieder ein Fehler. Drei Stunden später habe ich eine Datei, die fehlerfrei übersetzt. Ob sie auch tut, was sie soll, weiß ich nicht. Das wird der Test zeigen. Ich starte das Programm neu, diesmal mit meinem eigenen Code. Der Bildschirm bleibt schwarz. Keine Fehlermeldung, kein Lebenszeichen. Nur dieses endlose, leere Schwarz, das mich anstarrt. Ich drücke die Reset-Taste. Alles neu. Wieder tippen, wieder compilieren, wieder testen. Irgendwann, ich weiß nicht mehr nach wie vielen Versuchen, passiert es. Der Bildschirm zeigt zwei Prozesse an. Sie laufen parallel. Sie teilen sich die CPU, ohne sich zu stören. Es ist nichts Besonderes, nichts, was ein fertiges System nicht tausendmal besser könnte. Aber es ist meins. Ich lehne mich zurück. Die Uhr zeigt weit nach Mitternacht. Der Tee neben mir ist kalt. Randi liegt zusammengerollt auf dem Bett und schläft. Ihr gleichmäßiges Atmen mischt sich mit dem Summen des Computers. Für einen Moment ist alles still. Und in dieser Stille spüre ich etwas, das ich lange nicht gefühlt habe. Es ist nicht Stolz. Es ist nicht Triumph. Es ist etwas Ruhigeres. Etwas, das sich anfühlt wie: Es geht. Ich kann es. Der Computer tut, was ich ihm sage. Nicht, was andere ihm gesagt haben. Ich. In den folgenden Nächten wächst der Code. Zeile für Zeile, Funktion für Funktion. Ein primitiver Treiber für die Tastatur. Eine erste Speicherverwaltung. Ein Bildschirmtreiber, der Buchstaben an die richtige Stelle setzt. Jedes Stück für sich ist klein, überschaubar, fast bescheiden. Aber zusammen ergeben sie etwas, das langsam nach einem Betriebssystem aussieht. Nach etwas, das atmet. Das lebt. Ich taufe es noch nicht. Es hat keinen Namen. In den Ordnern heißt es einfach "projekt" oder "kernel" oder manchmal "dieses verdammte ding". Die Namen sind nicht wichtig. Was zählt, ist, dass es läuft. Manchmal, in den frühen Morgenstunden, wenn der erste Lichtschein sich durch die zugefrorenen Fenster kämpft, halte ich inne und starre auf den Bildschirm. Da ist Code, den ich geschrieben habe. Da läuft etwas, das es vor ein paar Wochen noch nicht gab. Das ich aus dem Nichts geholt habe, aus Zeilen und Logik und langen Nächten. Neben mir regt sich Randi im Schlaf. Sie träumt wohl von Mäusen oder von Wärme oder von Dingen, die wir nie verstehen werden. Ich streiche ihr kurz über das Fell, dann wende ich mich wieder dem Bildschirm zu. Ich habe nicht geplant, einen Kernel zu schreiben. Ich wollte nur einen Terminal-Emulator. Aber der Emulator war der erste Funke. Und jetzt brennt es lichterloh. --- ## Kapitel 4 ## Der Funke springt über Die Nächte werden länger, der Code wächst. Was als kleiner Terminal-Emulator begann, hat sich längst verselbstständigt. Ich schreibe Treiber, verwalte Speicher, lasse Prozesse nebeneinander laufen. Der Kernel ist noch primitiv, noch weit entfernt von dem, was MINIX oder gar UNIX kann. Aber er läuft. Auf meiner Maschine. Unter meiner Kontrolle. Jeden Abend setze ich mich hin, und jeden Abend wird es ein bisschen mehr. Eine Funktion hier, eine Korrektur dort. Manchmal sind es nur wenige Zeilen, manchmal schreibe ich Seiten voll Code, bis meine Finger schmerzen und die Buchstaben vor meinen Augen verschwimmen. Randi liegt dann auf dem Bett und beobachtet mich mit halb geschlossenen Augen, als wolle sie sagen: Du schon wieder. Irgendwann im Spätsommer, ich weiß nicht mehr genau wann, sitze ich wieder einmal vor dem Bildschirm und starre auf die Zeilen. Draußen färbt sich der Himmel langsam von Schwarz zu Dunkelblau. Der Winter ist vorbei, Helsinki erwacht. Ich höre die ersten Vögel, weit weg, ein leises Zwitschern, das sich mit dem Summen der Festplatte mischt. Und plötzlich wird mir klar - **Das hier ist nicht mehr nur für mich.** Ich habe monatelang daran gearbeitet, Nächte durchgemacht, Fehler gefunden und korrigiert. Ich habe etwas geschaffen, das existiert. Etwas, das atmet und läuft und funktioniert. Nicht perfekt, nicht fertig, aber da. Und je länger ich darüber nachdenke, desto stärker wird das Gefühl - Das sollte nicht in diesem Zimmer bleiben. Nicht nur auf dieser Festplatte. Nicht nur für meine Augen. Ich denke an die Newsgroups. An comp.os.minix, wo ich so viel gelernt habe, wo Tanenbaum sein Wissen teilt, wo Menschen diskutieren, fragen, helfen. Ich habe dort so oft gelesen, aber noch nie selbst geschrieben. Noch nie etwas beigetragen. Vielleicht ist es jetzt Zeit. Vielleicht interessiert es dort jemanden. Vielleicht nicht. Aber die Möglichkeit allein ist es wert. Ich zögere tagelang. Jedes Mal, wenn ich mich hinsetzen will, um die Nachricht zu schreiben, finde ich einen Grund, es nicht zu tun. Noch ein Fehler, den ich korrigieren muss. Noch eine Funktion, die nicht rund läuft. Noch eine Nacht, um alles zu perfektionieren. Aber perfekt wird es nie. Das weiß ich tief in mir. Irgendwann muss man loslassen. Am 25. August 1991 setze ich mich hin und schreibe. Meine Finger sind etwas feucht, als ich die Tasten drücke. So eine Nachricht schreibt man nicht jeden Tag. Ich versuche, bescheiden zu klingen, die Erwartungen niedrig zu halten. Nichts versprechen, was ich nicht halten kann. Nur zeigen, was da ist. "Hello everybody out there using minix " Die Adresse ist klar. Die Leute, die MINIX nutzen, sind meine potenzielle Gemeinschaft. Sie kennen die Grenzen, die Frustration, das Gefühl, an einem System zu arbeiten, das nicht wachsen darf. Sie werden verstehen, warum ich das tue. Vielleicht. "I'm doing a free operating system just a hobby, won't be big and professional like gnu for 386 486 AT clones." Nur ein Hobby. Nicht groß, nicht professionell. Ich will niemanden in die Irre führen. Keine Versprechungen machen, die ich nicht halten kann. Aber der Kern ist da: frei. Für alle. Ohne die Einschränkungen, die ich so lange gespürt habe. Ohne die Mauern, die mich so oft frustriert haben. "This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like dislike in minix, as my OS resembles it somewhat same physical layout of the file system due to practical reasons among other things." Ich lese die Nachricht dreimal durch. Korrigiere hier ein Komma, dort einen Buchstaben. Dann, bevor ich es mir anders überlegen kann, drücke ich ab. Die Nachricht ist weg. In den Äther geschickt, irgendwohin in die Weiten des Internets, das damals noch klein war, noch überschaubar, noch ein Ort für Enthusiasten und Träumer. Ein Ort für Leute wie mich. Dann warte ich. Die ersten Tage passiert nichts. Keine Antwort, keine Reaktion. Ich checke die Newsgroup immer wieder, manchmal stündlich, aber nichts. Vielleicht war es doch zu kühn. Vielleicht interessiert es wirklich niemanden. Vielleicht bleibe ich doch allein in diesem Zimmer mit meinem Kernel und meiner Katze. Randi merkt, dass ich unruhig bin. Sie kommt öfter zu mir, stupst mich an, verlangt Aufmerksamkeit. Ich streichle sie, aber meine Gedanken sind woanders. Bei der Nachricht, die da draußen ist. Bei den Menschen, die sie vielleicht lesen. Oder auch nicht. Aber dann, eines Morgens, als ich die Verbindung zur Uni aufbaue, sind sie da. E-Mails. Mehrere. Ich starre auf den Bildschirm und traue mich kaum zu klicken. Vielleicht sind es nur automatische Antworten. Vielleicht Fehlermeldungen. Vielleicht Leute, die sagen, ich solle mich nicht so wichtig nehmen. Aber es sind keine Fehlermeldungen. Es sind Menschen, die meine Nachricht gelesen haben. Die neugierig sind. Die Fragen stellen. Die den Code sehen wollen. Aus den USA, aus Deutschland, aus England. Einer schreibt: "Das klingt interessant, erzähl mehr." Ein anderer, "Ich habe auch mit so etwas gespielt, vielleicht können wir zusammenarbeiten." Ein Dritter schickt einfach nur eine kurze Zeile: "Cool. Weiter so." Ich lese die Zeilen, einmal, zweimal, dreimal. Fremde Menschen, irgendwo auf der Welt, interessieren sich für das, was ich in meinem kleinen Zimmer gebaut habe. Sie wollen es sehen. Vielleicht sogar benutzen. Vielleicht sogar verbessern. Randi streicht um meine Beine, verlangt Aufmerksamkeit, aber ich kann mich nicht losreißen. Da ist eine E-Mail aus Australien, in der jemand fragt, ob der Kernel auch auf seiner Hardware laufen würde. Eine aus Deutschland mit detaillierten Fragen zum Speichermanagement. Jemand anders bietet Hilfe bei den Treibern an. Einer will einfach nur den Code, um damit zu spielen. In den folgenden Wochen wird es mehr. Viel mehr. Ich stelle die erste Version online, 0.01, kaum mehr als ein Gerüst, eigentlich nicht lauffähig, nur ein Symbol dafür, dass es etwas gibt. Aber die Leute laden es trotzdem herunter. Sie testen, finden Fehler, schicken mir Berichte. Sie wollen Teil davon sein. Im Oktober kommt 0.02, die erste wirklich nutzbare Version. Bash läuft, GCC läuft, die GNU Utilities laufen. Der Kernel ist noch klein, noch zerbrechlich, aber er atmet. Er lebt. Und er lebt nicht mehr allein in meinem Zimmer. Die E-Mails werden mehr, die Namen wiederholen sich. Menschen, die ich nie getroffen habe, werden zu Bekannten, zu Mitstreitern. Sie schicken Code, Vorschläge, Korrekturen. Manchmal sind es nur ein paar Zeilen, manchmal ganze Treiber. Ich lerne, loszulassen, nicht alles selbst schreiben zu müssen. Ich lerne, zu vertrauen. Eines Abends, als ich wieder einmal spät in der Nacht die neuesten Einsendungen durchsehe, fällt mein Blick auf Randi. Sie liegt zusammengerollt auf dem Bett, ihr Fell schimmert im Licht des Bildschirms, die weißen Pfoten sind unter dem Kinn versteckt. Sie schnurrt leise im Schlaf, dieses tiefe, gleichmäßige Geräusch, das ich so gut kenne. Ich lächele. Sie hat keine Ahnung, was hier gerade passiert. Für sie bin ich immer noch der, der zu lange am Computer sitzt und manchmal vergisst, sie zu streicheln. Der, der sie abends füttert und morgens wieder verschwindet. Aber irgendwie, in diesem Moment, ist sie Teil davon. Sie war dabei, vom ersten Tag an. Sie hat die Nächte durchschlafen, in denen der Kernel wuchs. Sie hat geschnurrt, wenn ich nicht mehr weiterwusste. Sie hat mich begleitet, ohne je eine Zeile Code zu verstehen. Ich streiche ihr kurz über den Kopf. Sie zuckt im Schlaf, aber wacht nicht auf. Dann wende ich mich wieder dem Bildschirm zu. Die nächste E-Mail wartet. Jemand aus Australien hat einen Treiber geschrieben, den ich mir ansehen soll. Jemand aus Deutschland fragt nach der Lizenz. Jemand aus den USA will wissen, ob der Kernel schon Netzwerk kann. Noch nicht, denke ich. Aber bald. Die Gemeinschaft wächst. Der Kernel wächst. Und ich sitze immer noch in meinem kleinen Zimmer in Helsinki, mit meiner Katze auf dem Bett, und staune. Ich habe nicht geplant, eine Bewegung zu starten. Ich wollte nur einen Terminal-Emulator. Nur ein kleines Programm, das mir hilft, mich in die Uni-Rechner einzuwählen. Aber der Emulator war der erste Funke.  **Eine bildhafte Veranschaulichung des Linux-Kernels.** ---- ## Kapitel 5 ## Der Name Es klingt vielleicht seltsam, aber ein Betriebssystem zu bauen ist einfacher, als einen guten Namen dafür zu finden. Wochenlang hatte ich mich mit Task Switching herumgeschlagen, mit Speicherverwaltung, mit Treibern, die nicht wollten, wie sie sollten. Das waren harte Nüsse, aber lösbare. Code lässt sich korrigieren. Fehler lassen sich finden. Man kämpft sich durch, Zeile für Zeile, testet, stürzt ab, beginnt von vorn, und irgendwann, nach Stunden oder Tagen, läuft es. So einfach ist das. Die Maschine gehorcht, wenn man hartnäckig genug ist. Aber ein Name? Ein Name gehorcht nicht. Ein Name bleibt. Ein Name ist das Erste, was die Leute sehen, das Erste, woran sie sich erinnern. Ein Name kann alles ruinieren, bevor jemand nur eine Zeile Code gesehen hat. Ein schlechter Name haftet wie Kaugummi unter der Schuhsohle, man wird ihn nicht mehr los. Ein guter Name dagegen verschwindet im Ohr, man vergisst, dass es ihn überhaupt gibt, weil er einfach richtig klingt. Ich hatte einen Arbeitstitel, mehr nicht. **Freax**. Eine Schnapsidee ehrlich gesagt, zusammengesetzt aus free, freak und Unix. Frei, ein bisschen verrückt, und angelehnt an das System, das ich nachbilden wollte. Es klang neutral, bescheiden. Es klang nicht nach mir. Das war mir wichtig. Denn eines wollte ich auf keinen Fall: dass es so aussah, als hätte ich mir die ganze Sache nur ausgedacht, um meinen eigenen Namen zu verewigen. Dieses Projekt war nie dazu gedacht, eine Statue für mich zu werden. Es war aus Frustration geboren, aus Neugier, aus dem Wunsch, etwas zu verstehen, indem man es selbst baut. Nicht aus Ego. Also blieb es bei Freax. Zumindest in meinem Kopf. Zumindest für den Moment. Doch dann kam Ari Lemmke ins Spiel. Ari war Administrator an der Universität Helsinki und betreute unter anderem den FTP Server des finnischen Universitätsnetzwerks. Die Adresse lautete ftp.funet.fi, FUNET stand für Finnish University and Research Network. Ich kannte ihn flüchtig, einen ruhigen, pragmatischen Typ mit einem trockenen Humor, der dafür sorgte, dass die Technik lief und sich nicht in den Vordergrund drängte. Genau die richtige Person für so einen Job. Keiner, der Aufhebens macht. Einer, der einfach macht. Als die Nachfrage nach meinem Projekt wuchs, wurde klar: Ich brauche einen festen Platz im Netz, wo die Leute den Code herunterladen können. Bisher verschickte ich alles per E Mail, einzeln, mühsam, und jede neue Anfrage bedeutete, dass ich wieder eine Datei zusammensuchen und abschicken musste. Das konnte so nicht weitergehen. Also schrieb ich Ari eine kurze Nachricht und fragte, ob er mir Platz auf dem Server einrichten könne. Für mein Projekt, Freax. Er sagte zu, kein Problem. Ich war erleichtert. Endlich ein richtiges Zuhause für den Code. Ein Ort, an den ich die Leute einfach verweisen konnte. Ein Ort, der bleiben würde. Ein paar Tage später, als ich das erste Mal nachschaute, ob mein Verzeichnis angelegt war, traute ich meinen Augen nicht. Ari hatte nicht freax angelegt. Sondern linux. Ich starrte auf den Bildschirm und wusste nicht, ob ich lachen oder protestieren sollte. Linux? Das war doch nie der Plan. Aber Ari hatte es einfach gemacht. Einfach so. Ohne zu fragen. Ich stellte mir vor, wie er vor seinem Terminal saß, bereit, das Verzeichnis anzulegen. Ich hatte ihn gebeten, Freax zu nennen. Vielleicht tippte er die Buchstaben ein, hielt dann inne. Vielleicht sprach er sie leise vor sich hin. Freax. Freax. Es klang irgendwie sperrig, nicht rund. Nichts, was man sich leicht merken konnte. Nichts, das auf der Zunge lag. Also suchte er nach etwas Besserem. Sein Blick fiel auf meinen Namen, Linus, den er natürlich kannte. Und er verband ihn mit dem System, um das es ging. Unix. **Linus und Unix**. **Linux**. Zwei Silben. Einfach. Klar. Direkt. Er tippte es ein, ohne viel Aufhebens. Für ihn war es die logische Entscheidung. Der Name des Entwicklers, verbunden mit dem System, das er nachbaute. Mehr nicht. Keine große Theorie, keine Diskussion. Einfach gemacht. Für mich war es der Moment, in dem mein Projekt einen Namen bekam, den ich nie gewählt hätte – der aber genau richtig war. Die ersten Nutzer, die meine Dateien herunterluden, sahen das Verzeichnis linux. Sie sprachen darüber, schrieben in den Newsgroups davon. Hast du schon Linux gesehen? Läuft bei dir Linux? Der Name verbreitete sich wie von selbst, ohne dass ich etwas dafür tun musste. Er wanderte von Mund zu Mund, von Tastatur zu Tastatur, von einem Ende der Welt zum anderen. Ich musste ihn nicht verteidigen, nicht erklären, nicht bewerben. Er war einfach da. Und das Schönste daran? Der Server existiert heute noch. Wer will, kann ftp.funet.fi aufrufen und findet immer noch dieses Verzeichnis, diesen Namen, dieses Stück Geschichte, das mit einer kleinen administrativen Entscheidung begann. Ein Verzeichnis, das ein Administrator nach seinem Gefühl benannte, ohne groß darüber nachzudenken. Der Name stand da, klein und endgültig, als hätte ihn niemand erfunden, sondern nur freigelegt. **Linux**. Zwei Silben, die keinen Vertrag brauchten. Kein Logo. Keine Erklärung. Keine Marketingstrategie, keine Agentur, kein Designer, der stolz sein Konzept präsentierte. Nur diese nüchterne Ordnerstruktur auf einem FTP-Server, unscheinbar und doch voller Bedeutung. Und darin ein Versprechen: Hier ist es. Nimm es, probier es, bau darauf. Ich hörte in der Stille des Zimmers mein eigenes Zögern lauter als das Netzteil. Einen Moment lang wollte ich ihn zurückschieben, diesen Namen, der zu nah an mir war. Zu persönlich. Zu sehr ich. Aber dann begriff ich: Die Dinge, die wirklich wachsen, lassen sich nicht an der Leine führen. Sie bekommen einen Namen, weil andere ihn aussprechen müssen. Nicht weil ich ihn gewählt habe, sondern weil er sich durchsetzt. Weil er richtig ist. Ich schaltete den Monitor aus. Grün erlosch zu Schwarz. Das leise Summen des Computers verstummte nicht ganz, es blieb, dieses Hintergrundgeräusch, das mich all die Nächte begleitet hatte. Aber der Bildschirm war leer, und in der Dunkelheit spiegelte sich mein Gesicht, verschwommen, kaum zu erkennen. Und ich begriff in diesem Moment: Das war der Punkt, an dem es nicht mehr nur mein System war. Nicht mehr nur mein Code, mein Projekt, meine Nächte. Es gehörte jetzt den anderen. Denen, die es herunterluden, testeten, verbesserten. Denen, die den Namen aussprachen, ohne mich zu fragen. **Linux**. Nicht als Besitz. Sondern als Richtung. Ich stand auf, ging zum Fenster, sah hinaus auf die schlafende Stadt. Irgendwo da draußen, in tausenden Kilometern Entfernung, saßen jetzt Menschen vor ihren Bildschirmen und taten dasselbe wie ich. Sie lasen Code, schrieben Code, träumten von dem, was möglich wäre. Und sie sagten Linux. Nicht meinetwegen. Sondern weil es das Wort war, das ihnen gegeben worden war. Ein Wort, das weitermachen würde. Lange nachdem diese Nacht vorbei war. Lange nachdem der Schnee geschmolzen war. Lange nachdem ich selbst vielleicht nicht mehr hier sein würde. Der Name stand nicht auf dem Monitor. Aber er war da. In den Köpfen, in den Fingern, in den Zeilen, die noch geschrieben werden würden. **Linux**. Es klang gut. Es klang richtig. Es klang nach Zukunft.  ## Kapitel 6 ## Die Debatte Der Name stand. Die Gemeinschaft wuchs. Mein Kernel entwickelte sich weiter, Version 0.02, dann 0.03, dann 0.10. Im Dezember 1991 kam 0.11, die erste Version, die sich selbst kompilieren konnte. Es ging voran, schneller als ich je gedacht hätte. Jeden Abend setzte ich mich hin, sah die E-Mails, die hereinkamen, die Patches, die Vorschläge, die Fragen. Menschen, die ich nie getroffen hatte, halfen mir, etwas zu bauen, das größer war als ich. Es war wie ein Wunder, das sich jeden Tag neu wiederholte. Und dann, Anfang 1992, an einem ganz gewöhnlichen Tag, passierte etwas, womit ich nicht gerechnet hatte. Ich saß vor meinem Bildschirm, wie so oft. Eine Tasse Tee stand neben mir, längst kalt geworden. Durch das gefrorene Fenster fiel das blasse Licht des kurzen Wintertags. Ich blätterte durch die Beiträge in der Newsgroup comp.os.minix, wie ich es jeden Tag tat. Es war Routine, fast schon meditativ. Die Namen der Poster, die Betreffzeilen, die Diskussionen – ich kannte sie alle. Und dann sah ich es. Die Nachricht kam aus den Niederlanden, von der Vrije Universiteit in Amsterdam. Der Absender: Andrew S. Tanenbaum. Der Betreff: "LINUX is obsolete". Ich las die Zeilen einmal, zweimal, dreimal. Tanenbaum. Der Schöpfer von MINIX. Der Professor, dessen Buch ich verschlungen hatte, dessen Code ich studiert hatte wie andere die Bibel. Der Mann, der mir indirekt beigebracht hatte, wie Betriebssysteme funktionieren. Ich hatte seine Exercises gelöst, seine Architektur bewundert, seine Herangehensweise verinnerlicht. Und jetzt, jetzt nannte er mein Projekt überholt. Veraltet. Einen Schritt zurück in die 1970er Jahre. Mein Magen zog sich zusammen. Einen Moment lang saß ich nur da und starrte auf den Bildschirm. Die Worte verschwammen vor meinen Augen. Ich spürte, wie mir heiß wurde, obwohl das Zimmer kühl war. Da war dieser schale Geschmack im Mund, den man bekommt, wenn etwas, das einem wichtig ist, mit einem Schlag in Frage gestellt wird. Als hätte jemand eine Tür zugeschlagen, hinter der ich gerade noch stehen durfte. Tanenbaums Argument war klar und hart. Ich las es Wort für Wort, und jedes traf mich wie ein kleiner Stich. Linux sei ein monolithischer Kernel, schrieb er, eine Architektur aus der Steinzeit der Computerentwicklung. Die Zukunft gehöre den Mikrokernen, so wie MINIX, so wie das geplante GNU Hurd. Ein modernes Betriebssystem müsse modular sein, die einzelnen Komponenten voneinander getrennt, in eigenen Adressräumen laufen. Nur so sei es sicher, nur so portabel, nur so zukunftsfähig. Und dann kam der Satz, der sich für immer in mein Gedächtnis brannte: "Writing a monolithic kernel in 1991 is a giant step back into the 1970s." Ein monolithischer Kernel 1991 zu schreiben sei ein gigantischer Schritt zurück in die Siebziger. Ich lehnte mich zurück und atmete tief durch. Da saß ich nun, in meinem kleinen Zimmer in Helsinki, hatte Nächte durchgemacht, Code geschrieben, getestet, verworfen, neu geschrieben, hatte alles gegeben für dieses Projekt. Ich hatte gelernt, Fehler gemacht, wieder gelernt. Und einer der großen alten Männer der Betriebssystemwelt, einer meiner stillen Lehrer, erklärte meine Arbeit für obsolet. Für einen Moment war ich einfach nur gekränkt. Vielleicht hatte ich wirklich etwas falsch gemacht. Vielleicht war ich ein Anfänger, der sich an etwas vergriffen hatte, das er nicht verstand. Vielleicht war alles, was ich gebaut hatte, nur ein Umweg, eine Sackgasse, die niemand gehen sollte. Die Gedanken wirbelten in meinem Kopf, einer jagte den nächsten, und ich konnte sie nicht stoppen. Die Stille meines Zimmers drückte auf mich. Nur das leise Summen meines Computers war zu hören, dieses Geräusch, das mich all die Nächte begleitet hatte. Es klang plötzlich anders, irgendwie vorwurfsvoll, als wollte es sagen: Du hast dich überschätzt. Du hast geglaubt, du könntest mithalten, aber du bist nur ein Student, der in seinem Zimmer herumspielt. Doch dann, langsam, fast gegen meinen Willen, wich die Kränkung einer anderen Regung. Sie kam von tief unten, kroch hoch wie Wärme, die sich ausbreitet. Wut. Nicht die laute, aggressive Sorte. Sondern eine kalte, klare Entschlossenheit. Sie kam leise, aber sie kam mit Macht. Ich dachte an all die Nächte. An all die Fehler, die ich gefunden und korrigiert hatte. An all die Menschen, die meinen Code herunterluden, testeten, verbesserten. An die E-Mails, die mich erreichten, voller Begeisterung, voller Ideen, voller Hoffnung. Sollte das alles falsch sein? Sollten die alle unrecht haben? Nein, dachte ich. Nein, so einfach mach ich es ihm nicht. Am nächsten Tag setzte ich mich hin und schrieb meine Antwort. Meine Finger flogen über die Tastatur, schneller als sonst. Die Worte kamen von allein, ich musste nicht nachdenken. Sie waren einfach da, als hätten sie nur darauf gewartet, endlich rausgelassen zu werden. Ich spürte, wie sich etwas in mir löste, wie die angestaute Energie einen Weg fand. Ich begann mit einer klaren Ansage: Ja, aus theoretischer und ästhetischer Sicht hatte Tanenbaum vielleicht recht. Mikrokernel sind elegant, sauber, durchdacht. Das hatte ich nie bestritten. In einer perfekten Welt, mit unbegrenzten Ressourcen und unendlich viel Zeit, hätte ich vielleicht auch so etwas gebaut. Aber die Realität sah anders aus. GNU Hurd, das große Mikrokernel-Projekt, auf das alle warteten, war nicht fertig. Würde noch Jahre brauchen, wenn überhaupt. Ich schrieb: "If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't." Wäre der GNU-Kernel letztes Frühjahr fertig gewesen, hätte ich gar nicht erst angefangen. Aber er war es nicht. Ist es immer noch nicht. Und MINIX? MINIX hatte Designprobleme, die nicht wegzudiskutieren waren. Kein ordentliches Multithreading, Beschränkungen, die einem die Haare raufen ließen. Ich wurde deutlicher, vielleicht zu deutlich. Aber es musste raus. Ich hatte zu lange in der zweiten Reihe gestanden, zu lange nur konsumiert, gelernt, nachgebaut. Jetzt war ich dran, meine eigenen Entscheidungen zu verteidigen. Meine eigenen Fehler zu machen. Meinen eigenen Weg zu gehen. Dann griff ich sein Argument der Portabilität auf. Tanenbaum warf Linux vor, zu sehr an die x86-Architektur gebunden zu sein. Ja, gab ich zu, Linux war speziell für den Intel 80386 geschrieben. Das war Absicht, kein Versehen. Ich wollte die besonderen Fähigkeiten dieses Prozessors nutzen. Ich wollte sehen, was möglich war, wenn man nicht kompromittierte, wenn man das System für die Maschine schrieb, die vor einem stand. Aber das bedeutete nicht, dass Linux nicht portabel sei. Im Gegenteil: Weil die API sauber war, waren Anwendungen leicht zu portieren. Und darum ging es doch letztlich. Nicht um die Maschine, sondern um das, was darauf lief. Nicht um die Architektur, sondern um die Ideen. Ich schloss mit einem Satz, der vielleicht überheblich klang, aber ich meinte es ernst: "linux is more portable than minix." Linux sei portabler als MINIX. Ich las meine Antwort dreimal durch, korrigierte hier und da ein Wort. Dann, bevor ich es mir anders überlegen konnte, drückte ich ab. Meine Nachricht verschwand im Äther, rauschte durch Kabel und Server, machte sich auf den Weg nach Amsterdam. Ich lehnte mich zurück und merkte, dass meine Hände zitterten. Der Puls raste, der Schweiß stand mir auf der Stirn. Ich hatte es getan. Ich hatte dem großen Tanenbaum widersprochen. Tanenbaum ließ nicht lange auf sich warten. Seine Antwort kam schnell und präzise, und ich musste zugeben: Auch er hatte gute Punkte. Verdammt gute Punkte sogar. Er erklärte, warum MINIX so war, wie es war. Als Professor müsse er an die Studenten denken, an deren schwache Hardware. Ein Intel 8088, manchmal ohne Festplatte. Darauf musste MINIX laufen. Mein Linux dagegen setzte den teuren 386 voraus, den sich viele Studenten nicht leisten konnten. Und dann wagte er eine Prognose. In fünf Jahren, schrieb er, würde jeder auf leistungsstarken Workstations laufen. SPARCstation-5 mit 64 MB RAM, 200 MIPS. Und darauf würde dann ein freies GNU laufen. Die x86-Architektur, an die Linux so eng gekettet war, würde dann längst überholt sein. Ich las seine Worte und musste schmunzeln. Fünf Jahre. Eine Ewigkeit in der Computerwelt. Wer wusste schon, was in fünf Jahren sein würde? Vielleicht hatte er recht. Vielleicht auch nicht. Aber das war nicht der Punkt. Der Punkt war, dass wir hier und jetzt etwas brauchten, das funktionierte. Etwas, das die Leute benutzen konnten, während sie auf die perfekte Lösung warteten. Die Diskussion zog Kreise. Andere mischten sich ein. Peter MacDonald, einer der ersten Linux-Entwickler, meldete sich zu Wort. David S. Miller, der später zu einem meiner wichtigsten Mitstreiter wurde. Theodore Ts'o, der erste nordamerikanische Linux-Entwickler. Sie alle verteidigten Linux auf ihre Weise. Besonders Kevin Brown traf den Punkt: "Different design goals get you different designs." Unterschiedliche Ziele führen zu unterschiedlichen Designs. Tanenbaum wollte ein Lehrsystem für schwache Rechner. Ich wollte die Leistungsfähigkeit des 386 ausschöpfen. Beides war legitim. Warum musste das ein Gegensatz sein? Warum musste einer von uns unrecht haben? Konnte es nicht einfach zwei Wege geben, zwei Ansätze, zwei Lösungen für zwei verschiedene Probleme? Nach einigen Tagen, als die Wogen sich etwas geglättet hatten und die schärfsten Diskussionen abgeklungen waren, wurde mir klar, dass ich vielleicht überreagiert hatte. Die Wut war verraucht, die Kränkung verblasst. Was blieb, war ein leiser Zweifel, aber auch Dankbarkeit. Tanenbaum war kein Feind. Er war ein Professor, der seine Meinung vertrat. So wie ich meine vertrat. Und er hatte mir, ohne es zu wollen, einen Gefallen getan. Er hatte mich gezwungen, laut zu denken, meine Position zu finden, sie zu formulieren. Er hatte mich gezwungen, erwachsen zu werden. Ich setzte mich hin und schrieb ihm eine private E-Mail. Kurz, knapp, ohne große Worte. Ich entschuldigte mich für den scharfen Ton. Es tat mir nicht leid, was ich gesagt hatte, aber wie ich es gesagt hatte, das hätte besser sein können. Ich war jung, ich war hitzig, ich war vielleicht zu schnell mit meinen Schlüssen gewesen. Seine Antwort kam Tage später. Sie war freundlich, fast väterlich. Er wünschte mir viel Erfolg mit Linux. Mehr nicht. Aber es reichte. Es war wie ein stiller Segen, eine Geste des Respekts von einem, der viel länger im Geschäft war als ich. Jahre später, als die Wogen sich längst geglättet hatten und Linux kein kleines Studentenprojekt mehr war, sondern etwas, das die Welt veränderte, las ich irgendwann ein Interview mit ihm. Der Journalist fragte ihn nach der alten Debatte, und Tanenbaum lächelte nur. Er sagte, dass er nie böse auf mich gewesen sei. Dass MINIX für ihn nur ein Hobby war, eine Möglichkeit, seinen Studenten etwas beizubringen. Dass er froh war, als Linux kam und ihm die Last abnahm, weiter an MINIX zu arbeiten. Und dann kam ein Satz, der mich wirklich berührte. Er sagte: "To the extent that Linus can be counted as my student, I'm proud of him, too. Professors like it when their students go on to greater glory." In dem Maße, wie ich als sein Student gelten könne, sei auch er stolz auf mich. Professoren mögen es, wenn ihre Studenten zu größerem Ruhm gelangen. Ich las diese Worte und musste einen Moment lang innehalten. Der Bildschirm verschwamm vor meinen Augen, aber diesmal nicht vor Wut oder Kränkung. Sondern vor etwas anderem. Etwas Weichem. Etwas, das sich anfühlte wie Ankommen. Vielleicht hatte Tanenbaum recht gehabt, auf eine Weise, die er selbst nicht ahnte. Sein Buch, sein Code, seine Ideen – sie hatten mich geprägt, ob er wollte oder nicht. Sie waren der Grundstein, auf dem ich baute. In gewisser Weise war ich sein Schüler. Und ich war stolz darauf. Stolz, von einem wie ihm gelernt zu haben. Stolz, seine Ideen weiterentwickelt zu haben. Stolz, ihm zeigen zu können, dass seine Arbeit Früchte trug, auch wenn die Früchte anders aussahen, als er es sich vorgestellt hatte. Draußen war es still geworden. Der Schnee fiel leise und gleichmäßig, bedeckte Helsinki mit einer Schicht, die alles dämpfte. Die Stadt schlief. Nur mein Zimmer war wach, nur mein Bildschirm leuchtete, nur der Cursor blinkte, geduldig wie immer. Die Debatte war vorbei. Aber die Arbeit ging weiter. Linux wuchs. Und ich wuchs mit ihm.  ## Kapitel 7 ## Die ersten Distributionen Mein Kernel wuchs. Die Community wuchs. Und mit ihr wuchs ein Problem, das ich lange unterschätzt hatte. Mein Code war da. Die GNU-Tools waren da. Der Compiler gcc, der mir erlaubte, Code in laufbare Programme zu übersetzen. Die Shell bash, in der ich Befehle eintippen konnte. Die tausend kleinen Utilities, die ein Betriebssystem erst nutzbar machten. All das war da, aber es war nichts davon zusammengepackt. Wer Linux nutzen wollte, musste sich die einzelnen Teile mühsam zusammensuchen, herunterladen, kompilieren, installieren. Es war wie ein Koffer voller Einzelteile, und jeder musste selbst herausfinden, wie sie zusammengehörten. Ich hatte nie darüber nachgedacht. Für mich war das normal. Ich wusste, was ich brauchte, und ich wusste, wie ich es zusammensetzte. Aber je mehr Leute dazukamen, desto deutlicher wurde mir: Das funktioniert nicht für alle. Nicht jeder hat die Zeit oder die Geduld, sich durch Dutzende von Dateien zu wühlen, Abhängigkeiten zu prüfen, Fehler zu beheben. Ich saß oft abends da, las die E-Mails, die hereinkamen, und spürte die Frustration hinter manchen Zeilen. Leute, die von Linux gehört hatten, die es ausprobieren wollten, die sich den Kernel herunterluden und dann nicht wussten, wie es weitergeht. Was wir brauchten, war etwas Einfacheres. Etwas, das man einfach installieren und loslegen konnte. Ich wusste damals noch nicht, dass andere genau darüber nachdachten. **Peter MacDonald** Eines Tages, ich weiß nicht mehr genau wann, hörte ich zum ersten Mal von Peter MacDonald. Er war Kanadier, Softwareentwickler, einer von denen, die früh zu Linux gefunden hatten. Aber während ich in meinem Zimmer in Helsinki saß und mich um den Kernel kümmerte, dachte Peter an etwas anderes. Er fragte sich: Wie bringt man dieses Ding den Leuten bei, die nicht den ganzen Tag mit Compilern verbringen wollen? Im Mai 1992 veröffentlichte er das Softlanding Linux System. SLS. 15 Disketten, die alles enthielten, was man brauchte. Den Kernel, die GNU-Tools, eine grafische Oberfläche, Netzwerk, Emacs. Alles, was man für ein ernsthaftes System brauchte. Man musste nichts mehr kompilieren, nichts mehr zusammensuchen. Man steckte die Diskette ein und installierte. Ich erinnere mich, wie ich zum ersten Mal davon hörte. Jemand schickte mir eine E-Mail und schrieb: "Hast du das gesehen? Jemand hat deinen Kernel in ein komplettes System gepackt. Man kann es einfach installieren, wie ein richtiges Betriebssystem." Ich lächelte, als ich das las. Es war ein seltsames Gefühl. Etwas, das ich geschrieben hatte, in meinem kleinen Zimmer, in Helsinki, war plötzlich Teil von etwas, das andere zusammengestellt hatten. Es fühlte sich an, als würde mein Code die Welt betreten, als würde er aufhören, nur mir zu gehören. Aber SLS war nicht perfekt. Das spürte ich in den E-Mails, die mich erreichten. Bugs, die nicht behoben wurden. Eine Installation, die manchmal abstürzte. Pakete, die nicht richtig zusammenarbeiteten. Peter hatte den Anfang gemacht, aber er war überfordert. Das Projekt war zu groß geworden für einen einzelnen Entwickler. In der Community wuchs die Unzufriedenheit. Ich las die Diskussionen in den Newsgroups und spürte, wie die Stimmung kippte. Viele begannen, sich zu fragen: Geht das nicht besser? **Patrick Volkerding** Patrick Volkerding war einer von ihnen. Er studierte in Minnesota, ein ruhiger Typ mit langen Haaren und Brille, der sich in den Computerlaboren herumtrieb. Er brauchte für ein Schulprojekt einen LISP-Interpreter und fand CLISP. CLISP lief unter Linux. Also lud er SLS herunter und installierte es. Aber die Installation war mühsam. Stundenlang saß er vor dem Bildschirm, kämpfte mit Bugs, suchte nach Lösungen. Er machte sich Notizen, schrieb auf, was er fand und wie man es beheben konnte. Sein Professor, der Linux auch nutzen wollte, fragte ihn: Könntest du das nicht einfacher machen? Könntest du nicht die Installationsdisketten so anpassen, dass die Fehler gleich behoben sind? Patrick fing an, daran zu arbeiten. Er verbesserte SLS, fixte Bugs, tauschte Pakete aus, brachte alles zum Laufen. Bald hatte er eine Version, die viel stabiler war als das Original. Ich stellte mir vor, wie er in seinem kleinen Apartment in Minnesota saß, umgeben von Disketten, die auf seinem Schreibtisch stapelten, und wie er immer wieder testete, immer wieder verbesserte. Es war, als würde ich mich selbst sehen, nur dass er nicht den Kernel baute, sondern das Haus darum herum. Er hatte nicht vor, daraus ein eigenes Projekt zu machen. Er dachte, SLS würde bald eine neue Version herausbringen, die seine Verbesserungen übernehmen würde. Aber nichts passierte. Also fragten ihn seine Freunde: Warum stellst du das nicht online? Warum bietest du es nicht anderen an? Patrick zögerte. Ich kann mir vorstellen, wie er da saß und überlegte, ob er wirklich so ein Projekt starten sollte. Ob er sich das zutraute. Ob er bereit war für das, was da auf ihn zukommen würde. Dann, eines Tages, schrieb er eine Nachricht in die Newsgroup: "Anyone want an SLS-like system?" Die Antworten überwältigten ihn. So viele wollten es. Der Server der Universität brach fast zusammen unter den Zugriffen. Hunderte von Downloads in den ersten Tagen. Tausende. Am 17. Juli 1993 veröffentlichte Patrick die Version 1.00 von Slackware. 24 Disketten. Ein komplettes System. Er nannte es Slackware. Der Name kam von "Slack", einem Begriff aus der Church of the SubGenius, einer Parodie-Religion, die Patrick mochte. Ein humorvoller Name, um das Projekt nicht zu ernst erscheinen zu lassen. Aber das Publikum nahm es sehr ernst. Ich erinnere mich, als ich Slackware das erste Mal sah. Ich saß vor meinem Bildschirm, hatte die Dateien heruntergeladen und durchstöberte die Verzeichnisse. Da war mein Kernel. Und da waren all die GNU-Tools, all die Patches, all die Entscheidungen, die Patrick getroffen hatte. Es war nicht mehr mein Code allein. Aber es fühlte sich an, als ob mein Kernel endlich ein Zuhause gefunden hatte. Ich schrieb Patrick eine kurze E-Mail. Ich weiß nicht mehr genau, was drinstand. Wahrscheinlich etwas in der Art: "Das ist großartig. Mach weiter so." Ich hoffe, ich sagte das. Denn was er tat, war viel mehr, als ich je hätte tun können. Slackware wurde schnell zur beliebtesten Linux-Distribution. Es war einfach, stabil, und es blieb dem Unix-Gedanken treu: einfache Werkzeuge, einfache Konfiguration, kein unnötiger Schnickschnack. Patrick entwickelte es über Jahre weiter, hielt an der Einfachheit fest und bewahrte den Geist des klassischen Unix. Bis heute ist Slackware die älteste noch aktive Distribution. Mehr als dreißig Jahre. Ich denke manchmal daran, was für ein Weg das war. Von einem Studenten in Minnesota, der LISP für ein Schulprojekt brauchte, zu einem der wichtigsten Namen in der Geschichte von Linux. **Ian Murdock** Fast zeitgleich, nur einen Monat später, schrieb ein junger Student an der Purdue University in Indiana eine E-Mail, die die Geschichte von Linux auf eine ganz eigene Weise prägen sollte. Ian Murdock war frustriert. Auch er hatte SLS ausprobiert, und auch er fand es fehlerhaft. Aber seine Lösung war eine andere. Er wollte nicht einfach ein bestehendes System reparieren. Er wollte etwas Neues bauen. Etwas, das nicht von einer Person abhing, sondern von einer Gemeinschaft. Etwas, das wirklich frei war, in dem jeder mitmachen konnte, der gute Arbeit ablieferte. Am 16. August 1993 schrieb Ian in die Newsgroup. Er nannte sein Projekt Debian. Eine Kombination aus seinem Vornamen Ian und dem Vornamen seiner damaligen Freundin Debra. Deb und Ian. Debian. Ich erinnere mich, dass ich den Namen damals etwas seltsam fand. Aber der Name war das Unwichtigste. Was Ian wirklich ausmachte, war seine Haltung. Er schrieb ein Manifest, in dem er sagte: Diese Distribution wird nicht kommerziell sein. Sie wird offen sein für jeden, der etwas beitragen will. Sie wird sorgfältig gepflegt werden, mit klaren Regeln und Verantwortlichkeiten. Sie wird eine Gemeinschaft sein, kein Ein-Mann-Projekt. Ich las seine Worte und spürte, wie sich etwas in mir regte. Da war jemand, der dasselbe dachte wie ich. Der glaubte, dass Software nicht von oben herab entwickelt werden sollte, sondern von einer Gemeinschaft, die gemeinsam entscheidet, gemeinsam Verantwortung trägt. Ich hatte Linux einfach so entstehen lassen, ohne darüber nachzudenken. Ian machte daraus eine bewusste Entscheidung. Ian bekam Unterstützung von der Free Software Foundation. Ein Jahr lang finanzierten sie seine Arbeit. Das gab ihm den Freiraum, etwas wirklich Neues aufzubauen. Und er tat es. Debian führte ein Paketmanagement ein, das weit über das hinausging, was andere Distributionen hatten. dpkg, später APT – diese Werkzeuge machten es möglich, Software zu installieren, zu aktualisieren und zu entfernen, ohne dass man sich um Abhängigkeiten kümmern musste. Es war so einfach, dass es sich anfühlte wie Magie. Ich erinnere mich, wie ich zum ersten Mal ein Debian-System installierte. Ich legte die Diskette ein, und es passierte fast von allein. Ich lehnte mich zurück und dachte: Das hätte ich früher auch gebraucht. Ian schrieb später in einem Interview, dass er nicht an die Technologie glaubte. Nicht daran, dass der Code allein die Welt veränderte. Sondern an den Entwicklungsprozess. An die Idee, dass viele Menschen, verteilt über die ganze Welt, ohne wirtschaftlichen Anreiz, etwas Komplexes bauen können. Er nannte es das erste bewusste Gemeinschaftsprojekt. Ich dachte oft darüber nach. Linux war zufällig entstanden. Aus Neugier, aus Frustration, aus dem Wunsch, etwas zu verstehen. Debian wurde mit Absicht so gebaut. Ian hatte eine Vision, und er setzte sie um. Ian Murdock starb 2015, viel zu früh. Aber sein Werk lebt weiter. Debian ist bis heute eine der wichtigsten Distributionen, die Grundlage für Ubuntu und unzählige andere. Wenn ich daran denke, werde ich traurig, aber auch stolz. Stolz, dass ich mit ihm zusammenarbeiten durfte, dass er meinen Code genommen und etwas daraus gemacht hat, das so viel größer ist als wir beide. **Die Welt verändert sich** Die drei Distributionen veränderten alles. Plötzlich war Linux nicht mehr nur ein Kernel, den sich hartgesottene Bastler selbst kompilieren mussten. Es war ein komplettes Betriebssystem, das man auf Disketten kaufen oder herunterladen und einfach installieren konnte. Es gab eine grafische Oberfläche, wenn man wollte. Es gab Netzwerk, Compiler, Textverarbeitung. Es gab eine Gemeinschaft von Menschen, die sich darum kümmerten, dass alles funktionierte. Ich saß in meinem Zimmer in Helsinki und verfolgte das alles mit einer Mischung aus Staunen und Dankbarkeit. Ich hatte den Kernel geschrieben, ja. Aber das, was da gerade passierte, war so viel mehr. Diese Menschen, die ich nie getroffen hatte, nahmen meinen Code und machten etwas daraus, das ich mir nie hätte vorstellen können. Peter MacDonald, der mit SLS den Anfang gemacht hatte, zog sich später zurück. Aber seine Idee lebte weiter. Patrick Volkerding entwickelte Slackware über Jahrzehnte weiter, hielt an der Einfachheit fest und bewahrte den Geist des klassischen Unix. Und Ian Murdock schuf mit Debian etwas, das bis heute als eine der wichtigsten Distributionen gilt. Ich saß eines Abends vor dem Bildschirm und sah mir die Download-Zahlen von Slackware an. Tausende. Zehntausende. Menschen, die meinen Kernel benutzten, ohne jemals eine Zeile kompiliert zu haben. Es war ein seltsames Gefühl. Da waren plötzlich so viele, und ich kannte keinen von ihnen. Aber sie alle kannten meinen Code, zumindest ein Stück davon. Sie vertrauten ihm, benutzten ihn, machten ihn zu ihrem eigenen. Ich dachte an Peter MacDonald, der mit SLS den Anfang gemacht hatte. An Patrick Volkerding, der in Minnesota an Disketten saß und ein System zusammenschraubte, das plötzlich auf tausenden Rechnern lief. An Ian Murdock, der etwas ganz Neues baute, eine Gemeinschaft, die sich selbst organisierte, ohne einen Chef, ohne einen Plan, nur mit der Idee, dass Zusammenarbeit besser ist als Alleingang. Ich hatte nie geplant, dass das passiert. Ich hatte nur einen Terminal-Emulator schreiben wollen. Und jetzt saß ich hier, in meinem kleinen Zimmer, und sah zu, wie mein Code die Welt eroberte. Nicht mein Code. Unser Code. Das wurde mir in diesem Moment klar. Es gehörte nicht mehr mir. Es gehörte all den Menschen, die es herunterluden, installierten, verbesserten. Die es auf Disketten packten und weitergaben. Die es in ihre Systeme einbauten und daraus etwas machten, das ich mir nie hätte vorstellen können. Die ersten Distributionen waren nur der Anfang. Aber sie zeigten, wohin die Reise ging. Nicht zu einem Kernel. Nicht zu einem Betriebssystem. Sondern zu einer Welt, in der jeder, überall, seinen Teil beitragen konnte. Ich schaltete den Bildschirm aus und saß einen Moment lang im Dunkeln. Nur das leise Summen des Computers war noch zu hören, dieses Geräusch, das mich all die Nächte begleitet hatte. Aber es klang nicht mehr wie das Summen einer Maschine. Es klang wie etwas Lebendiges. Etwas, das wuchs und sich veränderte und immer größer wurde. Und ich war nur ein kleiner Teil davon. Das war gut so.    ## Kapitel 8 ## Der Geist der Freiheit Es gab einen Mann, den ich nie getroffen hatte, der aber vielleicht mehr Einfluss auf Linux hatte als ich selbst. Er saß nicht in Helsinki, er schrieb keinen Kernel, er verbrachte seine Nächte nicht mit Task Switches und Speicherverwaltung. Aber ohne ihn wäre mein Code nie das geworden, was er heute ist. Sein Name war **Richard Stallman**. Stallman war einer dieser Menschen, die man nicht vergisst, wenn man sie einmal gesehen hat. Lange Haare, ein buschiger Bart, und immer diese durchdringenden Augen, die dich ansehen, als ob sie dich fragen: Glaubst du wirklich, was du da sagst? In den 1970ern arbeitete er als junger Programmierer im berühmten MIT Artificial Intelligence Laboratory. Damals teilten Hacker ihren Code noch wie selbstverständlich. Man gab ihn weiter, verbesserte ihn, gab ihn zurück. Es war eine Kultur des Teilens, des Lernens voneinander, der reinen Neugier. Keine Lizenzen, keine Verträge, keine Anwälte. Nur Menschen, die gemeinsam herausfinden wollten, was Maschinen können. Dann kam die Wende. Die Computerindustrie entdeckte, dass man mit Software Geld verdienen konnte. Firmen wie AT&T, die Unix entwickelt hatten, begannen, ihren Code unter Verschluss zu nehmen. 1982 wurde AT&T aufgespalten, und plötzlich wurde Unix verkauft. Ohne Quellcode. Ohne die Möglichkeit, ihn zu studieren oder zu verändern. Ohne die Freiheit, die vorher selbstverständlich war. Die freie Atmosphäre, in der Stallman aufgewachsen war, zerbröselte wie altes Papier. Für viele war das einfach der Lauf der Dinge. Für ihn war es ein Schock. **Der Drucker, der die Welt veränderte** Es war ein kleiner Vorfall, der alles auslöste. Im MIT gab es einen neuen Xerox Drucker, der ständig klemmte. Aber wenn er klemmte, bekam niemand Bescheid. Man musste den ganzen Flur runterlaufen, nur um zu sehen, dass der Drucker wieder blockiert war. Stallman, der wie viele andere den Drucker täglich nutzte, fand das inakzeptabel. Er war Programmierer. Er konnte das Problem beheben. Er brauchte nur den Quellcode des Druckertreibers, ein paar Zeilen ändern, und der Drucker hätte beim nächsten Papierstau eine Meldung schicken können. Aber Xerox gab den Code nicht her. Der Drucker war proprietär. Der Hersteller hatte sich entschieden, dass niemand sehen durfte, wie er funktionierte. Aus Sicherheitsgründen, hieß es. Aus Wettbewerbsgründen. Aus Gründen, die Stallman für vorgeschoben hielt. Für viele wäre das nur eine kleine Frustration gewesen. Eine Notiz in der Abteilung, ein halbherziger Versuch, den Chef zu überzeugen, einen anderen Drucker zu bestellen. Für Stallman war es eine Erkenntnis, die sein Leben verändern sollte. Es ging nicht um einen Drucker. Es ging um Kontrolle. Darum, wer entscheidet, wie Technologie funktioniert. Der Nutzer oder der Hersteller. Er sagte später einmal in einem Vortrag: Bei Software kontrolliert entweder der Anwender die Software, oder die Software kontrolliert den Nutzer. Es gibt keinen Mittelweg. Das war der Moment, in dem er sich entschied, nicht zu schweigen. **Die Ankündigung** Am 27. September 1983 postete Richard Stallman eine Nachricht in die Newsgroup net.unix wizards. Der Betreff war unspektakulär, aber der Inhalt war es nicht. Er schrieb, dass er ein neues Betriebssystem entwickeln wolle. Es sollte frei sein. Frei im Sinne von Freiheit, nicht von Preis. Jeder sollte es nutzen, studieren, verändern und weitergeben können. Keine Einschränkungen. Keine verschlossenen Türen. Er nannte es GNU, ein rekursiver Akronym, wie sie damals am MIT beliebt waren. GNU's Not Unix. Die Reaktionen waren gemischt. Einige fanden es naiv. Andere waren begeistert. Die meisten wussten nicht, was sie davon halten sollten. Ein Betriebssystem von Grund auf neu zu schreiben, das hatte noch niemand allein versucht. Es klang wie ein Traum, wie eine Utopie, wie etwas, das nie Wirklichkeit werden würde. Aber Stallman meinte es ernst. Ein Jahr später, im Januar 1984, gab er seine Stelle am MIT auf. Nicht weil er das Institut hasste, sondern weil er sichergehen wollte, dass seine Arbeit nicht dem Institut gehören könnte. Er lebte von Ersparnissen, später von Spenden, später von dem, was ihm andere zusteckten. Er schlief manchmal in seinem Büro, arbeitete Tag und Nacht, schrieb Code, baute Werkzeuge. Er war besessen von der Idee, dass Software frei sein muss. 1985, im März, veröffentlichte er das GNU Manifest. Es war eine Mischung aus technischem Plan und philosophischem Aufruf. Er erklärte, warum freie Software wichtig war. Er widerlegte Einwände, die er schon kommen sah. Nein, Programmierer müssten nicht hungern, nur weil sie ihre Arbeit teilten. Ja, es gab andere Wege, Geld zu verdienen. Durch Support, durch Dienstleistungen, durch das, was man um die Software herum anbot. Nein, freie Software war kein Kommunismus. Es war einfach die Rückkehr zu dem, was früher normal war. Später gründete er die Free Software Foundation, um dem Projekt eine rechtliche und finanzielle Struktur zu geben. Er brauchte eine Organisation, die Lizenzen verwalten, Spenden sammeln und den Kampf gegen proprietäre Software aufnehmen konnte. Die FSF wurde sein Werkzeug, seine Stimme, seine Armee. **Die Werkzeuge** Während Stallman kämpfte, schrieb er auch Code. Und was für einen Code. Da war Emacs, ein Texteditor, den manche liebevoll als eigenes Betriebssystem bezeichneten. Emacs war mehr als ein Editor. Es war eine Umgebung, in der man E-Mails lesen, Newsgroups durchstöbern, Programme kompilieren und sogar spielen konnte. Es war Stallmans Antwort auf die proprietären Editoren, die damals den Markt beherrschten. Da war GCC, der GNU C Compiler. GCC war ein Meisterwerk. Er konnte Programme auf völlig unterschiedlichen Maschinen übersetzen, von kleinen Mikrocontrollern bis zu großen Mainframes. Er war so gut, dass viele ihn dem proprietären Compiler von AT&T vorzogen. Er war so gut, dass er zur Grundlage der gesamten Open Source Bewegung wurde. Da war bash, die Shell, in der man Befehle eintippen konnte. Da war glibc, die C Bibliothek, ohne die kein Programm laufen konnte. Da waren all die tausend kleinen Utilities, die ein System erst nutzbar machen. `ls`, das Verzeichnisse anzeigt. `grep`, das nach Text sucht. `awk`, das Daten verarbeitet. `make`, das Programme baut. `ld`, das sie zusammenbindet. All das war frei. All das konnte jeder nehmen, verändern, verbessern. All das war das Ergebnis eines einzigen Mannes, der sich weigerte, aufzugeben. Nur eines fehlte: ein Kernel. GNU arbeitete an einem eigenen Kernel, dem Hurd. Hurd sollte auf dem Mach Mikrokernel basieren, einer eleganten, modernen Architektur. Aber Hurd kam nicht voran. Das Projekt war ambitioniert, vielleicht zu ambitioniert. Die Entwickler stritten über Details, die Architektur war komplex, und die Zeit verging. Während die GNU Tools die Welt eroberten, blieb der Kernel eine Baustelle. Ein Versprechen, das sich nicht einlösen wollte. **Die Begegnung** Und dann kam ich. Ich wusste damals noch nicht viel von Stallman. Ich kannte seine Tools, aber ich kannte nicht die ganze Geschichte dahinter. 1991, als ich anfing, meinen Kernel zu schreiben, hatte ich GNU nicht im Kopf. Ich wollte nur einen Terminal Emulator bauen, der es mir erlaubte, mich in die Rechner der Universität einzuwählen. Aber die GNU Tools waren da. GCC war da, bash war da, die Utilities waren da. Und weil sie frei waren, konnte ich sie nutzen, ohne zu fragen, ohne zu bezahlen. Ich konnte meinen Kernel mit ihnen kompilieren, mit ihnen testen, mit ihnen laufen lassen. Es war eine Hochzeit, die keiner geplant hatte. Aber sie war perfekt. 1992, als mein Kernel langsam Form annahm und die ersten Nutzer sich meldeten, stellte ich ihn unter die GNU General Public License. Die GPL war Stallmans Idee, sein Geniestreich. Sie besagte: Wer diesen Code nutzt, muss ihn auch teilen. Man darf ihn verändern, aber man muss die Veränderungen auch wieder öffentlich machen. Der Code bleibt frei, für immer. Es war eine Lizenz, die nicht nur erlaubte, was andere verboten, sondern die Freiheit aktiv schützte. Wer die GPL umging, machte sich rechtlich angreifbar. Es war eine Waffe im Kampf gegen proprietäre Software. Viele fragten mich später, warum ich die GPL gewählt habe. Ich hatte keine große Philosophie. Ich wusste nur: Frei ist besser. Teilen ist besser. Und Stallman hatte mit seiner Lizenz genau das geschaffen, was wir brauchten. **Die Folgen** Ohne Stallman wäre Linux nie mehr gewesen als ein Kernel in einem Studentenzimmer. Die GNU Tools waren das, was daraus ein Betriebssystem machte. GCC, bash, Emacs, all die tausend Utilities. Das waren die Werkzeuge, mit denen die ersten Entwickler arbeiteten. Das waren die Werkzeuge, mit denen die ersten Distributionen entstanden. Das waren die Werkzeuge, die Linux überhaupt erst nutzbar machten. Und die GPL war die Lizenz, die sicherstellte, dass der Code frei blieb, auch als die ersten Firmen kamen. Red Hat, SUSE, Caldera. Sie alle bauten auf Linux, und sie alle mussten sich an die GPL halten. Sie konnten ihren Code nicht verschließen, wie es AT&T mit Unix getan hatte. Sie konnten nicht einfach kommen und nehmen. Sie mussten geben, was sie bekamen. Heute nennt Stallman das System konsequent GNU/Linux. Viele streiten sich über den Namen. Manche finden es pedantisch, manche finden es falsch. Aber im Kern hat er recht. Linux ist der Kernel, aber das Betriebssystem ist viel mehr. Es ist die Summe von Tausenden von Teilen, die von Tausenden von Menschen geschrieben wurden. Und viele dieser Teile stammen von Stallman und seinen Mitstreitern. Ich dachte oft über ihn nach. Ein Mann, der seine Stelle aufgab, der von Spenden lebte, der gegen die ganze Industrie kämpfte. Ein Mann, der keine Kompromisse machte, der nie aufgab, der immer weitermachte, auch wenn alle um ihn herum längst kapituliert hatten. Nur weil er daran glaubte, dass Software frei sein muss. Er war kompromisslos, manchmal schwer zu ertragen, manchmal schwer zu verstehen. Aber er hatte recht. Vielleicht nicht in jedem Detail, aber im Großen und Ganzen. **Das Vermächtnis** Ich erinnere mich an eine Geschichte, die mir jemand erzählte. Als Stallman das GNU Manifest schrieb, saß er in seinem Büro am MIT, umgeben von Computern, die ihm nicht gehörten, in einer Welt, die längst dabei war, sich zu verändern. Unix wurde kommerzialisiert, die großen Firmen übernahmen das Ruder, und die Idee, dass Software etwas Gemeinsames sein könnte, geriet in Vergessenheit. Aber Stallman glaubte daran, dass es einen anderen Weg gab. Er glaubte daran, dass man nicht einfach aufgeben musste. Heute, Jahrzehnte später, laufen Milliarden von Geräten mit GNU/Linux. Android Handys, die mehr Rechenleistung haben als die Supercomputer der 1980er. Server, die das Internet am Laufen halten. Supercomputer, die Wettervorhersagen berechnen und Proteine falten. Sogar Raumschiffe, die zum Mars fliegen. Die Idee, dass Software frei sein muss, hat die Welt verändert. Nicht über Nacht, nicht ohne Kämpfe, nicht ohne Widerstand. Aber sie hat sich durchgesetzt. Ich sitze manchmal abends in meinem Zimmer und denke an Stallman. An diesen Mann mit dem langen Bart, der nie aufhörte zu kämpfen. An seine Worte, die damals wie eine Utopie klangen und heute wie eine Selbstverständlichkeit. An seine Überzeugung, die so viele Menschen angesteckt hat. Richard Stallman ist bis heute eine umstrittene Figur. Er bleibt kompromisslos, wo andere längst Kompromisse geschlossen haben. Viele in der Open Source Bewegung haben sich von ihm entfernt, haben ihn kritisiert, haben ihn fallengelassen. Er ist nicht einfach, das weiß ich. Er ist schwierig, eigensinnig, unbequem. Aber eines wird man ihm nie nehmen können. Er hat die Welt verändert. Er hat eine Bewegung gestartet, die heute Millionen von Menschen verbindet. Er hat uns gelehrt, dass Software mehr sein kann als Ware. Dass sie etwas Gemeinsames sein kann, etwas, das allen gehört, etwas, das uns verbindet. Und er hat mir, einem Studenten in Helsinki, der nur einen Terminal Emulator schreiben wollte, die Werkzeuge gegeben, die ich brauchte, um etwas zu bauen, das größer ist als ich selbst. Die Werkzeuge, die aus einem kleinen Kernel ein Betriebssystem machten. Die Werkzeuge, die aus einem Studentenzimmer eine Weltbewegung machten. Ohne ihn wäre Linux nicht Linux. Dafür bin ich dankbar.  ## Kapitel 9 ## Der Pinguin Nach all den Jahren voller Code, Debatten und Distributionen wurde es Zeit für etwas anderes, etwas das nicht aus Zeilen bestand, sondern aus Farben und Formen. Ein Gesicht für das, was wir gebaut hatten, etwas das man sehen, anfassen, auf T Shirts drucken konnte. Etwas das lächelt. Die Idee kam nicht von mir. 1996, als Linux langsam erwachsen wurde und die ersten Firmen wie Red Hat und SUSE sich um das System scharten, schlug jemand in der Community vor, dass wir ein Maskottchen brauchten. Nicht nur ein Logo, sondern etwas mit Charakter, etwas das man auf Webseiten setzen, in Präsentationen zeigen, auf Aufkleber drucken konnte. Etwas das lustig war, aber nicht albern, etwas das blieb, etwas das man lieben konnte. Ich hatte keine starke Meinung zu dem Thema. Ein Adler vielleicht, majestätisch und kraftvoll mit ausgebreiteten Schwingen, oder ein Hai, schnell und gefährlich mit Zähnen, die zubeißen konnten. Irgendetwas das nach Power und Geschwindigkeit klang, das war meine erste Idee. Ich stellte mir vor, wie so ein Tier über den Bildschirm flog, wie es die Konkurrenz in den Schatten stellte, wie es die Welt eroberte. Aber die Community hatte andere Pläne, wie so oft. **Die Wahl** In den Newsgroups entspann sich eine Diskussion, die wochenlang dauerte und immer hitziger wurde. Die Vorschläge waren wild und vielfältig, jeder hatte eine andere Vorstellung davon, was Linux ausmachte. Ein Löwe, weil Linux der König der Betriebssysteme sei, ein Fuchs, weil Linux schlau und anpassungsfähig sei, ein Eichhörnchen, weil es so schnell von Ast zu Ast springe, wie Linux von Idee zu Idee. Ein Dachs, weil er zwar klein, aber zäh sei, ein Wal, weil Linux so viel Speicherplatz fraß, ein Känguru, weil es immer weiterhüpfte, ohne müde zu werden. Es gab keinen klaren Favoriten, nur viele Meinungen und noch mehr leidenschaftliche Diskussionen, die sich im Kreis drehten. Die einen sahen die technische Überlegenheit von Linux, die anderen die Gemeinschaft, die dritten die Freiheit. Wie sollte ein einzelnes Tier all das ausdrücken? Wie sollte ein Bild all das einfangen, was wir in Jahren aufgebaut hatten? Dann meldete sich Alan Cox zu Wort. Alan war einer der ersten und wichtigsten Kernel Entwickler neben mir, ein Brite mit einem trockenen Humor, der manchmal so trocken war, dass man nicht wusste, ob er gerade einen Witz machte oder es ernst meinte. Er liebte unkonventionelle Ideen und hatte keine Angst davor, gegen den Strom zu schwimmen, und er schrieb in die Diskussion, warum nicht ein Pinguin. Pinguine sind cool, schrieb er, Pinguine sind freundlich, und sie sehen aus, als ob sie einen Frack tragen. Die Idee blieb hängen, so einfach war das. Ich muss zugeben, dass ich zuerst zögerte bei dem Gedanken an einen Pinguin, denn das klang nicht nach Power und das klang nicht nach Geschwindigkeit. Pinguine watscheln, sie fliegen nicht, sie sind tollpatschig auf dem Land, auch wenn sie im Wasser elegant gleiten. War das das Bild, das wir von Linux vermitteln wollten, ein tollpatschiger Vogel, der nicht fliegen kann? Aber je länger ich darüber nachdachte, desto mehr gefiel mir der Gedanke, der sich langsam in meinem Kopf festsetzte. Pinguine sind robust, sie überleben in den extremsten Umgebungen der Erde, in der Antarktis, wo Temperaturen auf minus sechzig Grad fallen und der Wind mit zweihundert Stundenkilometern bläst. Sie stehen zusammen, um sich warmzuhalten, tausende Tiere dicht an dicht, jeder profitiert vom anderen, keiner wird allein gelassen. Sie sind sozial, sie arbeiten zusammen, sie geben nicht auf, egal wie kalt es wird, egal wie hart der Wind bläst. Und ja, sie sehen gut aus im Frack, mit dieser schwarz weißen Eleganz, die niemanden gleichgültig lässt. Vielleicht war der Pinguin doch die richtige Wahl, vielleicht hatte Alan recht. **Der Biss** Ein paar Jahre vorher, als ich auf einer Reise in Australien war und die Welt entdeckte, besuchte ich einen Zoo. Ich war jung, neugierig, vielleicht ein bisschen zu sorglos, und irgendwo an der Ostküste, ich weiß nicht mehr genau wo, gab es eine Pinguin Ausstellung. Ein großes Becken mit kühlem Wasser, und am Rand standen die Tiere, die sich putzten und in die Sonne blinzelten, so friedlich und zufrieden, dass man ihnen stundenlang zusehen konnte. Ich stellte mich an das Becken, um die Tiere zu beobachten, und einer von ihnen kam näher. Neugierig, ohne jede Scheu, watschelte er direkt auf mich zu, blieb stehen, schrägte den Kopf und musterte mich mit kleinen schwarzen Augen, die so tief und klug wirkten. Dann kam er noch einen Schritt näher, und ich streckte die Hand aus, vielleicht weil ich dachte, er würde sie beschnuppern oder mit dem Schnabel tippen, vielleicht weil ich unterschätzte, wie schnell so ein Tier sein kann. Der Pinguin biss zu. Es war nicht schlimm, nur ein kleiner Schreck, ein kurzer, fester Druck auf den Finger, und dann ließ er wieder los. Kein Blut, keine Wunde, aber der Biss saß, und ich zog die Hand zurück, lachte ein bisschen verlegen, während der Pinguin watschelte, als wäre nichts gewesen. Später, als die Diskussion um das Maskottchen aufkam, erinnerte ich mich an diesen Moment, und ich dachte, dass ein Pinguin mich gebissen hatte. Vielleicht war das ein Zeichen, vielleicht wollte das Universum mir sagen, dass Pinguine eine Rolle in meinem Leben spielen sollten, oder vielleicht war es nur ein lustiger Zufall, der sich gut erzählen ließ. Ich entschied mich für Letzteres und erzählte die Geschichte in der Newsgroup, und die Leute fanden sie großartig. Der Pinguin, der Linus gebissen hatte, das war die beste Werbung für das Maskottchen, die man sich vorstellen konnte. **Larry Ewing** Jetzt brauchten wir nur noch jemanden, der das Ding zeichnen konnte, jemanden mit Geduld und Talent und einer Vorstellung davon, wie ein lächelnder Pinguin aussehen sollte. Larry Ewing war damals Student an der Texas A&M University, und er studierte kein Grafikdesign, keine Kunst, nichts was ihn auf diesen Moment vorbereitet hätte. Aber er konnte mit Gimp umgehen, dem freien Bildbearbeitungsprogramm, das Teil des GNU Projekts war, und er hatte Spaß daran, Dinge zu zeichnen. Er mochte Linux, und er setzte sich hin und fing an. Es dauerte Wochen, und Larry arbeitete akribisch an seinem Werk. Er schickte seine Entwürfe in die Newsgroup, und die Community gab Feedback, das manchmal hart war, aber immer ehrlich. Zu dick, zu dünn, zu rund, zu eckig, zu ernst, zu albern, zu aggressiv, zu schüchtern, die Meinungen gingen weit auseinander und widersprachen sich direkt. Larry ließ sich nicht entmutigen, er änderte, verbesserte, begann von vorn, verwarf alles und startete neu, Nacht für Nacht. Irgendwann, nach vielen Iterationen und unzähligen Stunden vor dem Bildschirm, entstand das Bild, das wir heute kennen, ein Bild das sofort ins Herz traf. Ein Pinguin, der sitzt, leicht nach vorne gelehnt, mit einem zufriedenen, fast verschmitzten Lächeln, als wüsste er etwas, das wir nicht wussten. Die Flügel sind ausgebreitet, als würde er gleich eine Umarmung anbieten oder jemanden in die Arme schließen, und der Bauch ist rund und einladend, so weich, dass man sein Gesicht darin vergraben wollte. Die Füße sind flach auf dem Boden, fest und stabil, und die Augen, diese kleinen schwarzen Augen, sehen dich an, als ob sie sagen wollen: Alles gut, ich bin bei dir, mach dir keine Sorgen. Larry nannte ihn Tux, und der Name kam von mir, ehrlich gesagt. Torvalds UniX, TUX, ein schlechter Wortwitz, eine dieser Ideen, die einem in den frühen Morgenstunden kommen, wenn man zu lange wach ist und der Kaffee kalt wird. Aber der Name blieb hängen, die Leute fanden ihn passend, kurz und einprägsam, mit einer kleinen Geschichte dahinter, die man erzählen konnte, wenn jemand fragte, woher der Pinguin seinen Namen hatte. **Die Wirkung** Tux war nicht nur ein Logo, er war ein Statement, eine Botschaft an die Welt, die lautete: Wir sind anders. In einer Welt voller aggressiver Maskottchen, die um Aufmerksamkeit kämpften, setzte Linux auf einen Pinguin. Feuer speiende Drachen, zornige Adler, muskelbepackte Helden, die mit gezückten Schwertern in die Schlacht zogen, überall dasselbe Bild von Kampf, Konkurrenz und Sieg. Und dann kam Linux mit einem Pinguin, der einfach nur da saß und lächelte, der nichts beweisen musste, weil er wusste, wer er war. Ein Tier, das nicht kämpft, sondern watschelt, das nicht angreift, sondern freundlich schaut, das nicht einschüchtert, sondern einlädt. Ein Tier, das nicht fliegen kann, aber dafür umso besser taucht, das in den eisigen Wassern der Antarktis zu Hause ist, wo andere längst aufgegeben hätten. Genau das war Linux, dachte ich in diesen Tagen, als ich die ersten Tux Bilder sah. Kein Unternehmen, das seinen Marktanteil verteidigte, keine Armee, die ihre Technologie verschloss, kein Monolith, der alles unter sich begrub. Sondern eine Gemeinschaft, die zusammenarbeitete, die Spaß hatte, die sich nicht zu ernst nahm, die wusste, dass Technologie nicht nur aus Code bestand, sondern auch aus Menschen, die ihn schrieben. Natürlich gab es Kritik an dem Pinguin, und die Kritik war laut. Ein Pinguin sei nicht professionell genug, sagten manche, wie sollten Unternehmen Linux ernst nehmen, wenn sein Maskottchen ein Pinguin war. Wie sollten Banken, Versicherungen, Regierungen ein System akzeptieren, das sich selbst mit einem watschelnden Vogel schmückte, der nicht fliegen konnte? Aber die Zeit zeigte, dass sie unrecht hatten, alle miteinander. Tux wurde zum Symbol für etwas, das stärker war als jedes aggressive Logo, für etwas, das nicht einschüchtern musste, weil es überzeugte, für etwas, das nicht brüllen musste, weil es funktionierte. **Der Pinguin lebt** Heute ist Tux überall, und jedes Mal wenn ich ihn sehe, muss ich lächeln. Auf Tausenden von Webseiten, die Linux vorstellen und erklären, auf unzähligen T Shirts, die auf Konferenzen getragen werden, auf Stickern an Laptops, die in Cafés und Universitäten aufklappen. Auf Servern in Rechenzentren, die das Internet am Laufen halten, in Filmen, die Linux kurz zeigen, ohne dass es jemand merkt, in Büchern, die die Geschichte des freien Betriebssystems erzählen, in Cartoons, die den Pinguin durch die Welt der Technologie watschen lassen. Sogar im Weltraum ist Tux zu Hause. Als ein Astronaut den ersten Linux Server zur Internationalen Raumstation brachte, hatte er einen Tux Aufkleber auf seinem Laptop, ein kleiner Pinguin, der die Erde umkreiste, immer wieder, Woche für Woche. Ich stelle mir vor, wie er dort oben sitzt, in der Schwerelosigkeit, die Arme ausgebreitet, und lächelt, während die Erde unter ihm vorbeizieht, während die Sonne auf- und untergeht, sechzehn Mal am Tag. Larry Ewing zeichnete Tux mit Gimp, einem freien Programm, unter Linux selbst, und das war es, was die Geschichte so perfekt machte. Ein freies Maskottchen für ein freies Betriebssystem, geschaffen mit freien Werkzeugen, ohne proprietäre Software, ohne teure Hardware, ohne geheime Formate. Einfach ein Student, der sich hinsetzte und das tat, was er liebte, weil er es liebte. **Die vielen Gesichter von Tux** Ich sitze manchmal abends vor meinem Bildschirm, wenn die Arbeit getan ist und der Code sich beruhigt hat, und sehe mir die neuesten Tux Variationen an, die die Community erschafft. Es gibt Tausende von Versionen, und keine ist die offizielle, alle sind willkommen, alle sind Teil der Familie. Tux als Superheld, mit Umhang und Maske, der die Welt der Technologie rettet. Tux als Cowboy, mit Hut und Stiefeln, der durch die Prärie der Daten reitet. Tux als Astronaut, mit Helm und Raumanzug, der durch die Galaxien der Algorithmen schwebt. Tux als Pirat, mit Augenklappe und Säbel, der die sieben Meere der Software durchsegelt. Tux als Weihnachtsmann, mit roter Mütze und Geschenken, der die guten Kinder mit neuen Kerneln beschert. Es gibt Tux in jeder Farbe, in jeder Pose, in jedem Stil, manche professionell, manche albern, manche künstlerisch wertvoll, manche einfach nur schnell gekritzelt. Aber alle haben eines gemeinsam, alle zeigen einen Pinguin, der sitzt und lächelt, der dich ansieht und sagt: Alles gut, ich bin bei dir. Das ist die Idee, die dahintersteckt, die Idee die uns alle verbindet. Keiner besitzt Tux, er gehört allen, wie Linux selbst. Jeder kann ihn nehmen, verändern, verbessern, neu zeichnen, ohne zu fragen, ohne zu bezahlen. Es gibt keine zentrale Behörde, die entscheidet, was Tux sein darf und was nicht, keine Richtlinien, keine Markenrechte, keine Anwälte, die mit Unterlassungsforderungen kommen, wenn jemand den Pinguin falsch malt. Tux ist frei, und das ist das Wichtigste. **Die wahre Geschichte** Der Pinguin ist kein Zufall, er ist die Summe von vielen kleinen Entscheidungen, die die Community getroffen hat, ohne es zu wissen. Alan Cox hatte die Idee, ich erzählte die Geschichte mit dem Biss, Larry Ewing zeichnete, was wir uns wünschten, und Tausende von Menschen auf der ganzen Welt machten ihn zu dem, was er heute ist. Ein Pinguin, der sitzt und lächelt, der keine Angst hat, der nicht kämpft, der einfach da ist. Manchmal, wenn ich auf eine Konferenz gehe und durch die Menge laufe, sehe ich Tux auf einem T Shirt, auf einem Rucksack, auf einer Tasse. Jemand hat ihn auf seinen Laptop geklebt, jemand hat ihn auf sein Notizbuch gezeichnet, jemand hat ihn als Plüschtier dabei, das er unter dem Arm trägt wie einen alten Freund. Und jedes Mal muss ich lächeln, nicht weil ich stolz bin, denn Stolz wäre das falsche Wort dafür. Sondern weil es mich daran erinnert, dass Linux nie nur mein Projekt war, dass es nie nur meine Nächte waren, mein Code, meine Träume. Es war immer unser Projekt, unser Code, unsere Träume, Tausende von Menschen, die über Jahre hinweg zusammenarbeiteten, Fehler fanden, Distributionen bauten, Dokumente übersetzten, Foren moderierten, Einsteiger betreuten. Tux ist nur das Gesicht davon, ein Gesicht das lächelt, ein Gesicht das uns alle anblickt und sagt: Ihr seid nicht allein. Und das reicht.  ## Kapitel 10 ## Der Informationsmanager aus der Hölle Das Jahr 2005 begann für mich wie jedes andere, ich saß in meinem Büro in Oregon, hatte meinen Bildschirm vor mir, die üblichen E Mails, die üblichen Patches, die üblichen Diskussionen über die neuesten Entwicklungen des Kernels. Der Kernel entwickelte sich weiter, die Community wuchs, alles schien in geordneten Bahnen zu laufen, und ich hatte das Gefühl, dass wir endlich eine stabile Arbeitsweise gefunden hatten, die für alle funktionierte. Dann, im Frühjahr, kam der Schock, der alles verändern sollte. **Was ist BitKeeper!** Bevor ich erzähle, was passierte, muss ich erklären, was BitKeeper überhaupt war. BitKeeper war ein Versionskontrollsystem, also eine Software, die es mehreren Entwicklern ermöglicht, gleichzeitig an demselben Code zu arbeiten, ohne sich gegenseitig zu behindern. Es speicherte alle Änderungen, die jemals gemacht wurden, verwaltete verschiedene Versionen und erlaubte es, Änderungen von einem Entwickler zum anderen zu übertragen, ohne dass alles in einem zentralen Archiv landen musste. Bevor wir BitKeeper hatten, war die Entwicklung des Linux Kernels eine einzige Katastrophe. Jeder Entwickler schickte mir seine Änderungen per E Mail, und ich musste jede einzelne von Hand in den Hauptkernel einpflegen. Das bedeutete, dass ich Tausende von E Mails mit Code Diffs bekam, jede davon musste ich lesen, prüfen, testen und dann manuell in die richtigen Dateien einfügen. Es war mühsam, fehleranfällig und unglaublich langsam, und je mehr Entwickler dazukamen, desto schlimmer wurde es. BitKeeper änderte das vollständig. Es war verteilt, das heißt, jeder Entwickler hatte eine vollständige Kopie des gesamten Kernel Repositories auf seiner eigenen Maschine, und man konnte Änderungen einfach von einem zum anderen übertragen, ohne dass ein zentraler Server alles kontrollieren musste. Es war schnell, es war zuverlässig, und es ermöglichte uns eine Arbeitsweise, die vorher undenkbar gewesen war. Wir hatten uns alle daran gewöhnt, dass die Verwaltung des Kernels endlich kein täglicher Kampf mehr war, und niemand wollte je wieder zu den alten Methoden zurückkehren. Es gab nur einen Haken. BitKeeper war proprietäre Software, das heißt, der Quellcode gehörte dem Hersteller BitMover, und niemand durfte ihn sehen oder verändern. Larry McVoy, der Chef von BitMover, erlaubte uns eine kostenlose Nutzung für die Open Source Entwicklung, was ein großzügiges Angebot war, aber es bedeutete auch, dass wir von seiner Gnade abhängig waren. Solange er uns gewähren ließ, konnten wir BitKeeper nutzen, aber wenn er seine Meinung änderte, standen wir mit leeren Händen da. **Der Konflikt!** Andrew Tridgell war ein kluger Entwickler, bekannt für seine Arbeit an Samba, einem Programm, das es Windows Rechnern erlaubte, mit Linux Servern zu kommunizieren. Er war neugierig, vielleicht zu neugierig, und er begann, das Protokoll von BitKeeper zu untersuchen, um zu verstehen, wie es funktionierte. Das Protokoll ist die Sprache, die der BitKeeper Client und der BitKeeper Server miteinander sprechen, und wenn man dieses Protokoll versteht, kann man im Prinzip ein eigenes Programm schreiben, das mit dem Server kommuniziert. Tridgell fand heraus, dass die Sache einfacher war als gedacht. Der BitKeeper Server zeigte ihm auf einfache Nachfrage alle verfügbaren Befehle an, es gab keine Verschlüsselung, keine Sicherheitsvorkehrungen, nichts, was ihn daran gehindert hätte, das Protokoll zu verstehen. Er schrieb ein kleines Programm, das die Kommunikation nachahmte, und nannte es SourcePuller. Als Larry McVoy davon erfuhr, war er wütend, richtig wütend. Er warf Tridgell vor, das Protokoll reverse engineered zu haben, was gegen die Lizenzvereinbarung verstieß, und er warf ihm vor, damit die Arbeit von BitMover zu stehlen. Die Diskussionen in den Newsgroups wurden hitzig, dann vergiftet, und bald sprach keiner mehr mit dem anderen. McVoy stellte ein Ultimatum. Wenn die Linux Community Tridgells Arbeit nicht verurteilen würde, würde er die kostenlose Lizenz für die Linux Entwicklung zurückziehen. Die Community versuchte zu vermitteln, aber es half nichts. Schließlich, im Frühjahr 2005, zog McVoy die Lizenz zurück, und wir standen vor dem Nichts. Plötzlich, über Nacht, hatten wir kein Versionskontrollsystem mehr. Keine Möglichkeit, unsere Änderungen zu verwalten, unsere Geschichte zu bewahren, unsere Zusammenarbeit zu organisieren. Die E Mails überschlugen sich, jeder wollte wissen, wie es weitergeht, und die Panik machte sich breit. **Die Entscheidung!** Ich saß in meinem Büro und starrte auf den Bildschirm, während die Nachrichten hereinfluteten und die Fragen immer drängender wurden. Sollten wir zu den alten Tarballs zurückkehren, zu der Zeit, als ich jede Änderung von Hand einpflegen musste? Sollten wir auf ein anderes System umsteigen, auf CVS oder Subversion oder eines der anderen Werkzeuge, die es da draußen gab? Es gab Alternativen, aber keine davon war gut genug für unsere Bedürfnisse. CVS war eine Katastrophe, es konnte nicht einmal Umbenennungen von Dateien richtig speichern. Subversion war kaum besser, es war zentralisiert, langsam und nicht für tausende von Entwicklern ausgelegt. Es gab ein Projekt namens Monotone, das konzeptionell interessant war, aber es war einfach zu langsam für unsere Bedürfnisse. Ein Patch in Monotone anzuwenden konnte mehrere Minuten dauern, und wenn man hundert Patches hatte, konnte man stundenlang warten. Ich dachte an all die Jahre, die wir mit BitKeeper gewonnen hatten, an die Arbeitsweise, die wir entwickelt hatten, an die Geschwindigkeit, mit der wir arbeiten konnten. Ich wollte nicht zurück zu den alten Methoden, ich wollte nicht auf ein System umsteigen, das nicht zu uns passte, und ich wollte auch nicht, dass unsere Arbeit durch die Entscheidung eines einzelnen Unternehmers gefährdet werden konnte. Also traf ich eine Entscheidung, die vielleicht verrückt klang, die aber in diesem Moment die einzig richtige war. Ich würde mein eigenes System schreiben. Die Community dachte, ich wäre wahnsinnig, und das war ich vielleicht auch. Ein Versionskontrollsystem von Grund auf neu zu entwickeln, das war ein riesiges Unterfangen, das normalerweise Jahre dauerte und ein ganzes Team von Entwicklern erforderte. Ich hatte keine Ahnung von Versionskontrollsystemen, ich hatte nur eine grobe Idee, wie so etwas funktionieren könnte, und ich hatte einen Zeitplan, der jeden vernünftigen Menschen zur Verzweiflung treiben würde. Aber ich hatte auch Wut, und Wut kann eine mächtige Triebfeder sein. **Die Kriterien!** Bevor ich auch nur eine Zeile Code schrieb, setzte ich mich hin und dachte darüber nach, was ein gutes Versionskontrollsystem überhaupt ausmachte. Ich hatte jahrelang mit BitKeeper gearbeitet, ich wusste, was funktionierte und was nicht, und ich hatte eine klare Vorstellung davon, worauf es ankam. Erstens brauchte ich Geschwindigkeit, unverschämte, unnachgiebige, beinahe obszöne Geschwindigkeit. Das System musste verdammt schnell sein, schneller als alles, was es da draußen gab. Wenn ich eine Serie von hundert Patches anwenden wollte, durfte das nicht Minuten dauern, ich wollte, dass es in Sekunden erledigt war. Ich setzte mir ein klares Ziel, das jeder für verrückt hielt: Das Anwenden eines Patches sollte nicht länger als drei Sekunden dauern, und ich wollte, dass das gesamte Repository auf einer Festplatte Platz fand, die klein genug war, um sie in der Tasche zu tragen. Zweitens brauchte ich eine verteilte Architektur, das war das Wichtigste, was BitKeeper uns gelehrt hatte. Jeder Entwickler sollte eine vollständige Kopie des gesamten Repositorys haben, nicht nur einen kleinen Ausschnitt, nicht nur die neuesten Änderungen, sondern die ganze Geschichte von der ersten Zeile Code bis zum letzten Commit. Das bedeutete, dass es keinen zentralen Server gab, der zur einzigen Fehlerquelle werden konnte, keinen Chef, der die Lizenz entziehen konnte, keine Wartezeiten, weil der Server überlastet war. Jeder Entwickler konnte unabhängig arbeiten, offline, ohne auf andere angewiesen zu sein, und wenn man wieder online war, konnte man seine Änderungen mit denen der anderen abgleichen. Drittens brauchte ich Datenintegrität, das war etwas, worüber vorher kaum jemand nachgedacht hatte. Ich wollte sicherstellen, dass nichts verloren ging, dass keine Änderung unbemerkt blieb, dass die Geschichte unveränderlich war, egal was passierte. Wenn jemand einen Commit machte, sollte dieser Commit für immer Teil des Repositorys sein, und jeder sollte ihn überprüfen können. Ich entschied mich für SHA 1 Hashes, das sind lange Zahlenfolgen, die wie ein Fingerabdruck für einen Commit funktionieren. Wenn sich auch nur ein einziges Bit im Commit änderte, änderte sich der gesamte Hash, und man konnte sofort sehen, dass etwas nicht stimmte. Später wurde das kritisiert, weil SHA 1 nicht mehr als sicher genug gilt, aber für mich ging es nie um Sicherheit gegen Angreifer. Es ging darum, sicherzustellen, dass die Daten nicht versehentlich korrumpiert wurden, dass keine Festplatte langsam starb, ohne dass es jemand merkte. Das waren die Grundpfeiler, und alles andere würde sich daraus ergeben. Ich hatte keine Ahnung, ob es funktionieren würde, aber ich war entschlossen, es herauszufinden. **Die zehn Tage!** Am 3. April 2005 begann ich zu schreiben, und von diesem Moment an existierte ich praktisch nicht mehr für die Außenwelt. Ich zog mich zurück, schaltete das Telefon aus, ignorierte die E Mails, die immer noch hereinfluteten, und konzentrierte mich nur auf das Wesentliche. Die ersten Tage waren chaotisch, ich hatte eine Idee im Kopf, aber sie musste erst Form annehmen, und das ging nicht ohne viel Herumprobieren. Ich schrieb Code, verwarf ihn, schrieb neu, verwarf wieder, und die Struktur wollte einfach nicht sitzen. Aber nach und nach, Zeile für Zeile, Nacht für Nacht, entstand etwas, das nach einem System aussah. Am 6. April, nur drei Tage nach dem ersten Code, kündigte ich das Projekt in der Kernel Mailingliste an, und die Reaktionen waren gemischt. Einige waren skeptisch, sie glaubten nicht, dass ein einzelner Entwickler in so kurzer Zeit etwas Brauchbares zustande bringen konnte. Andere waren neugierig, sie wollten sehen, was da kam. Die meisten wollten einfach nur abwarten, ob ich es wirklich durchziehen würde. Am 7. April war es so weit. Das System war nun self hosting, das heißt, es konnte sich selbst verwalten, es brauchte kein anderes Versionskontrollsystem mehr, um seine eigenen Änderungen aufzuzeichnen. Ich machte den ersten Commit, und die Nachricht, die ich hinterließ, war typisch für mich, vielleicht ein bisschen zu typisch. "Initial revision of git, the information manager from hell", schrieb ich, der Informationsmanager aus der Hölle. Es klang selbstironisch, aber es traf den Punkt. Git war nicht dafür gemacht, hübsch zu sein oder benutzerfreundlich oder auch nur im Entferntesten einladend. Es war dafür gemacht, zu funktionieren, und zwar verdammt schnell. Die ersten Versionen waren brutal, das muss ich zugeben. Es gab keine benutzerfreundlichen Befehle wie "git commit" oder "git push", sondern nur eine Sammlung von rohen Werkzeugen, die man mühsam zusammenschustern musste. Wer Git benutzen wollte, musste mit den Plumbing Befehlen arbeiten, den inneren Mechanismen des Systems, die normalerweise vor dem Anwender verborgen bleiben. Man musste "update cache" aufrufen, dann "write tree", dann "commit tree", und die zurückgegebenen SHA 1 Hashes von Hand in Dateien eintragen. Es war nichts für schwache Nerven, und die meisten Entwickler fanden es schrecklich. Aber es funktionierte, und es war schnell, unverschämt schnell. Am 29. April 2005, nicht einmal einen Monat nach dem ersten Commit, maß ich die Geschwindigkeit von Git, und das Ergebnis übertraf alle Erwartungen. 6,7 Patches pro Sekunde, mein Ziel von drei Sekunden pro Patch wurde damit weit übertroffen, und ich wusste, dass ich auf dem richtigen Weg war. Am 16. Juni 2005, nur zwei Monate nach dem ersten Commit, war es so weit. Ich veröffentlichte die erste Version des Linux Kernels, die vollständig mit Git verwaltet wurde, Version 2.6.12. Der Kernel, das Herz von Linux, wurde von nun an von einem System verwaltet, das ich in zehn Tagen zusammengehackt hatte, weil ich wütend über eine Lizenzänderung war. Es klang wie ein Witz, aber es war die Wahrheit. **Der Name!** Natürlich musste das Ding auch einen Namen haben, und wie sollte ein Projekt von mir sonst heißen? Ich hatte Linux nach mir benannt, wenn auch eher durch Zufall, und jetzt würde ich Git nach mir benennen, mit voller Absicht. Git ist britisches Englisch und bedeutet etwa dumme Person oder Idiot, und es war ein selbstironischer Seitenhieb auf mich selbst. Ich sagte damals in einem Interview, dass ich ein egoistischer Bastard sei und alle meine Projekte nach mir selbst benenne, erst Linux, jetzt Git. Die Community fand das witzig oder zumindest amüsant, und der Name blieb hängen. Später erfand jemand die rückwirkende Bedeutung "Global Information Tracker", aber das war nur ein frommer Wunsch von Leuten, denen der dumme Name nicht gefiel. In der README Datei schrieb ich, dass der Name Git von mir selbst gegeben wurde, als ich die allererste Version schrieb, und dass ich das Werkzeug als "the stupid content tracker" beschrieb, den dummen Inhaltsverfolger. In Wirklichkeit war es einfach nur Git, der Idiot, der Informationsmanager aus der Hölle, und das war genau richtig so. **Junio Hamano!** Ich wusste von Anfang an, dass ich Git nicht allein weiterentwickeln konnte, dafür war ich einfach zu beschäftigt. Ich hatte den Kernel, der immer mehr Aufmerksamkeit erforderte, ich hatte meine Familie, ich hatte nicht die Zeit, ein ganzes Versionskontrollsystem zu pflegen, das immer komplexer wurde. Glücklicherweise meldete sich bald jemand, der die Arbeit übernehmen konnte. Junio Hamano war ein japanischstämmiger Entwickler, der schon früh auf Git aufmerksam geworden war, und er begann, Patches zu schicken, kleine Verbesserungen hier, kleine Fehlerkorrekturen da. Er arbeitete akribisch, er verstand das System besser als jeder andere, und er hatte eine Vision davon, wohin sich Git entwickeln sollte. Schließlich, am 26. Juli 2005, nur viereinhalb Monate nach dem ersten Commit, übergab ich ihm das Projekt. Ich machte ihn zum Maintainer von Git, und von da an kümmerte er sich um alles, während ich mich wieder auf den Kernel konzentrieren konnte. Junio war der Richtige für diese Aufgabe, das wurde mir schnell klar. Er hatte Geduld, er hatte Weitblick, er hatte die Fähigkeit, Git von einem groben Werkzeug zu einem System zu machen, das auch normale Menschen benutzen konnten, ohne sich die Haare zu raufen. Er führte die Porcelain Befehle ein, die benutzerfreundliche Schicht über den eigentlichen Plumbing Befehlen, die es ermöglichte, dass man einfach "git commit" tippen konnte, ohne sich mit Hashes und Bäumen herumschlagen zu müssen. Er sorgte dafür, dass Git nicht nur für Kernel Entwickler nutzbar war, sondern für alle, für Studenten, für Hobbyisten, für Firmen, für die ganze Welt. Am 21. Dezember 2005 veröffentlichte Junio die Version 1.0 von Git, und das Projekt war endlich erwachsen geworden. Es hatte eine stabile Oberfläche, eine wachsende Gemeinschaft, und es war bereit für die große Bühne. Ohne Junio wäre Git nie das geworden, was es heute ist, das sage ich immer wieder. Ich habe Git erfunden, aber er hat es zu dem gemacht, was es ist, und dafür bin ich ihm bis heute dankbar. **Die Geburt von GitHub!** Git war da, aber Git allein war nicht genug. Wer Git nutzen wollte, musste es auf seinem eigenen Server installieren, musste sich mit der Kommandozeile herumschlagen, musste wissen, was er tat, und für viele Entwickler war das immer noch zu kompliziert. Git war ein Werkzeug für Profis, nicht für die breite Masse. Dann kamen Tom Preston Werner, Chris Wanstrath und PJ Hyett, drei junge Entwickler, die eine Idee hatten, die die Welt verändern sollte. Warum nicht eine Website bauen, die Git Repositories hostet und eine einfache, benutzerfreundliche Oberfläche dafür bietet, eine Seite, auf der Entwickler ihre Projekte teilen, zusammenarbeiten und sich vernetzen konnten, ohne sich um Server oder Berechtigungen zu kümmern. Im April 2008 wurde GitHub gegründet, und die Plattform war einfach, sozial und kostenlos für Open Source Projekte. Man konnte sich anmelden, ein Repository anlegen, Code hochladen, und schon war das Projekt online, für jeden sichtbar, für jeden nutzbar. Man konnte Projekte anderer Entwickler entdecken, sie forken, also eine eigene Kopie machen, Pull Requests schicken, um seine Verbesserungen dem Originalprojekt anzubieten, und Issues erstellen, um Fehler zu melden oder neue Funktionen vorzuschlagen. GitHub war der Katalysator, den Git brauchte, um von einem Nischenwerkzeug für Kernel Entwickler zu einem globalen Phänomen zu werden. Plötzlich konnten auch diejenigen mitmachen, die keine Erfahrung mit der Kommandozeile hatten, die keinen eigenen Server betreiben konnten, die einfach nur Code schreiben und teilen wollten. GitHub wurde zur Heimat der Open Source Bewegung, zum zentralen Ort für Zusammenarbeit, zur Plattform, auf der die großen Projekte der nächsten Jahrzehnte entstanden. Konkurrierende Plattformen wie Google Code mussten sich geschlagen geben, sie wurden eingestellt, weil niemand sie mehr nutzte. Atlassians BitBucket, das ursprünglich auf das Konkurrenzsystem Mercurial setzte, musste Git Unterstützung nachrüsten, um zu überleben. Git wurde zum De facto Standard, und GitHub war der Ort, an dem dieser Standard lebte. **Die Übernahme durch Microsoft!** Jahrelang wuchs GitHub unabhängig, und es schien, als ob die Plattform für immer ein eigenständiges Unternehmen bleiben würde. 2012 sicherte sich GitHub 100 Millionen Dollar Risikokapital, 2015 wurde es mit 2 Milliarden Dollar bewertet, und Millionen von Entwicklern strömten auf die Plattform. Microsoft, Google, Apple, Amazon, alle nutzten GitHub, es war der zentrale Ort für Code, für Zusammenarbeit, für die Zukunft der Softwareentwicklung. Aber GitHub war nie wirklich profitabel, das war das Problem. Die Plattform wuchs, aber sie wuchs mit Verlust, denn die Kosten für Server, Bandbreite und Entwickler waren enorm, während die Einnahmen aus Premium Abonnements und Unternehmenskunden nie ausreichten, um die Ausgaben zu decken. Es wurde Zeit für eine Veränderung, und die Veränderung kam in einer Form, die niemand erwartet hatte. Am 4. Juni 2018, während einer Entwicklerkonferenz in San Francisco, machte Microsoft CEO Satya Nadella eine Ankündigung, die die Welt der Technologie erschütterte. Microsoft kaufte GitHub für 7,5 Milliarden Dollar in Microsoft Aktien, das war das Sechsfache der letzten Bewertung von 2015, und die Branche hielt den Atem an. Die Reaktionen in der Open Source Gemeinschaft waren gemischt, um es vorsichtig auszudrücken. Viele Entwickler waren skeptisch, manche sogar verängstigt, und das aus gutem Grund. Das alte Microsoft, das Microsoft von Steve Ballmer, hatte Open Source als Krebs bezeichnet, eine Krankheit, die die Softwareindustrie befiel. Dieses Microsoft hatte gegen Linux gekämpft, wo es nur konnte, mit FUD, mit Patentdrohungen, mit unfairen Wettbewerbspraktiken. Dieses Microsoft hatte seine Technologie verschlossen, seine Quellcodes geheim gehalten, und die Gemeinschaft der freien Software verachtet. Sollte dieses Microsoft jetzt GitHub besitzen, die Heimat von Millionen von Open Source Projekten, das Herz der Bewegung, gegen die es jahrelang gekämpft hatte? Es klang wie ein schlechter Witz, aber es war die Wahrheit. Die Befürchtungen waren vielfältig und durchaus berechtigt. Würde Microsoft plötzlich Geld für das Hosten von Open Source Projekten verlangen? Würde Microsoft die Daten der Entwickler analysieren, um daraus eigene Produkte zu bauen? Würde Microsoft Open Source Projekte bevorzugen, die auf seiner eigenen Plattform liefen, und andere benachteiligen? Würde Microsoft eines Tages einfach den Stecker ziehen, wenn es ihm nicht mehr passte? Microsoft wusste um diese Befürchtungen, und Satya Nadella, der klüger war als sein Vorgänger, handelte geschickt. Er gab Versprechungen ab, die fast zu gut klangen, um wahr zu sein. GitHub würde unabhängig bleiben, sagte er, es würde seinen Entwickler Charakter behalten, es würde eine offene Plattform für alle sein, egal ob sie Microsoft Technologien nutzten oder nicht. Niemand würde gezwungen, Microsoft Dienste zu nutzen, niemand würde benachteiligt, weil er Linux oder macOS bevorzugte. Die Versprechungen wurden gehalten, zumindest auf den ersten Blick. GitHub blieb GitHub, das Logo blieb, die Oberfläche blieb, die Community blieb. Microsoft störte sich nicht ein, es gab keine plötzlichen Preiserhöhungen, keine versteckten Datenkrakeleien, keine Bevorzugung von Microsoft Technologien. Im Gegenteil, Microsoft integrierte GitHub in seine Produkte auf eine Weise, die für die Nutzer tatsächlich nützlich war. Aber die Frage, die viele stellten, war eine andere. Wem gehört GitHub wirklich, und was passiert, wenn Microsoft eines Tages seine Meinung ändert? Die Antwort war ernüchternd. GitHub gehört Microsoft, ganz und gar, und wenn Microsoft eines Tages beschließt, dass die Plattform nicht mehr so betrieben wird wie bisher, dann gibt es niemanden, der das verhindern könnte. Die Versprechungen von Satya Nadella sind keine Verträge, sie sind keine Gesetze, sie sind nur Worte, und Worte können sich ändern, wenn der Wind sich dreht. Die Integration von GitHub in Microsofts Ökosystem schritt trotzdem voran, und das geschickteste Werkzeug in diesem Prozess war GitHub Copilot. Copilot war ein KI gestütztes Programmierwerkzeug, das auf den öffentlichen Code Repositories auf GitHub trainierte worden war, also auf dem Code von Millionen von Entwicklern, die ihre Projekte kostenlos zur Verfügung gestellt hatten. Microsoft verkaufte Copilot als Abonnement, und die Entwickler zahlten, um von ihrer eigenen Arbeit zu profitieren, die Microsoft ohne ihr Einverständnis genutzt hatte. Es gab Klagen, natürlich gab es Klagen. Einige Entwickler argumentierten, dass Copilot ihre Open Source Lizenzen verletzte, weil es Code reproduzierte, der unter bestimmten Bedingungen stand. Andere argumentierten, dass Microsoft mit Copilot die Arbeit der Gemeinschaft monetarisierte, ohne die Gemeinschaft angemessen zu beteiligen. Die Klagen zogen sich hin, und bis heute ist nicht endgültig geklärt, ob Copilot legal ist oder nicht. Aber Microsoft kümmerte das wenig, denn Copilot war ein Kassenschlager, und die Anwälte von Microsoft waren die besten, die man für Geld kaufen konnte. **Die Integration!** 2025, sieben Jahre nach der Übernahme, zog Microsoft den nächsten Schritt, der die letzten Zweifel daran beseitigte, wem GitHub wirklich gehörte. GitHub CEO Thomas Dohmke kündigte seinen Rücktritt an, und Microsoft entschied, die Position nicht neu zu besetzen. Stattdessen wurde GitHub vollständig in die CoreAI Organisation von Microsoft integriert, eine neue Abteilung, die sich mit künstlicher Intelligenz befasste. GitHub war nicht mehr eine separate Einheit, nicht mehr eine Tochtergesellschaft mit eigener Kultur, eigenen Zielen, eigener Identität. Es war jetzt ein Teil von Microsofts KI Strategie, ein Rädchen in einer großen Maschine, die von Konzernstrategen gesteuert wurde, die noch nie eine Zeile Open Source Code geschrieben hatten. Die Plattform, die ich 2005 aus Wut und Verzweiflung geschrieben hatte, war zu einem zentralen Bestandteil des größten Technologieunternehmens der Welt geworden. Heute hat GitHub über 150 Millionen registrierte Entwickler, es ist die Heimat von mehr als einer Milliarde Repositories, und es ist der Ort, an dem Code geschrieben, geteilt und verbessert wird, jeden Tag, jede Stunde, jede Minute. Aber es ist auch ein Ort, der einem Unternehmen gehört, das in seiner Geschichte nicht immer freundlich zu Open Source war, und die Frage, ob das gut ist oder nicht, bleibt unbeantwortet. Der Informationsmanager aus der Hölle Als ich am 7. April 2005 die erste Commit Nachricht schrieb, dachte ich nicht an Ruhm oder Anerkennung, nicht an 150 Millionen Entwickler, nicht an 7,5 Milliarden Dollar, nicht an Microsoft oder an irgendeine Übernahme. Ich dachte nur daran, dass ich ein Problem lösen musste, dass ich nicht zurück zu den Tarballs wollte, dass ich etwas brauchte, das funktionierte, und zwar schnell. Git war nie als große Revolution gedacht, es war eine Notlösung, ein Werkzeug, das mir das Leben leichter machen sollte, mehr nicht. Dass es die Welt verändern würde, dass es die Grundlage für eine Plattform werden würde, auf der Millionen von Entwicklern zusammenarbeiten, dass es den gesamten Prozess der Softwareentwicklung revolutionieren würde, das konnte ich mir in jenen Apriltagen 2005 nicht vorstellen. Vielleicht ist das immer so. Die besten Dinge entstehen nicht aus großen Plänen, nicht aus langen Strategiepapieren, nicht aus Meetings mit Anzugträgern. Sie entstehen aus der Notwendigkeit, aus einem Problem, das gelöst werden muss, aus einem Entwickler, der nachts vor seinem Bildschirm sitzt und Code schreibt, weil er keine andere Wahl hat. Aus einem Informationsmanager aus der Hölle. --- Und das war die Geschichte von Linux. Von einem Studentenzimmer in Helsinki über die Debatten mit Tanenbaum, die ersten Distributionen, den Geist der Freiheit, den Pinguin, der die Welt eroberte, bis hin zu Git und GitHub – dem Werkzeug, das die Open-Source-Entwicklung für immer veränderte. Es war eine lange Reise. Und sie ist noch nicht zu Ende. Linux lebt, Git lebt, die Community lebt. Und solange es Menschen gibt, die neugierig sind, die Dinge verstehen wollen, die bereit sind, zu teilen und zusammenzuarbeiten, wird diese Geschichte weitergehen. Aber für heute ist Schluss. Der Cursor blinkt. Der Bildschirm leuchtet. Und irgendwo, in einem kleinen Zimmer in Helsinki, sitzt ein Student und schreibt Code. ***Nur ein Hobby. Nichts Großes.*** ---