Die Software Rebellen

scanned & corrected by „Denklangenach“ Dieses E-Book ist nicht für den Verkauf bestimmt !!! Glyn Moody Die Software-...

Author: Moody Glyn

16 downloads 1286 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

scanned & corrected by „Denklangenach“

Dieses E-Book ist nicht für den Verkauf bestimmt !!!

Glyn Moody

Die Software-Rebellen

Glyn Moody

Die Software-Rebellen Die Erfolgsstory von Linus Torvalds und Linux Aus dem Amerikanischen übersetzt Von Annemarie Pumpernig

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Moody, Glyn: Die Software-Rebellen : die Erfolgsstory von Linus Torvalds und Linux / Glyn Moody. Aus dem Amerikan. übers, von Annemarie Pumpenng. - Landsberg am Lech : mi, Verl. Moderne Industrie, 2001 Einheitssacht: The rcbel code ISBN 3-478-38730-2

© 2000 by Glyn Moody. All rights reserved. © 2001 verlag moderne Industrie, 86895 Landsberg/Lech Internet: http://www.mi-verlag.de Titel der amerikanischen Originalausgabe: The Rebel Code Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Fotokopie. Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme gespeichert, verarbeitet, vervielfältigt oder verbreitet werden. Umschlaggestaltung: Bachmann & Seidel, Altötting Satz: abc Media-Services GmbH, Buchlohe Druck: Himrner, Augsburg Bindung: Thomas, Augsburg Printed in Germany: 38710/010101 ISBN 3-478-38730-2

Inhaltsverzeichnis

Dank................................................................................................ 7 Prolog............................................................................................. 9 Kapitel 1 Das coolste Jahr..........................................................

15

Kapitel 2 Ein ganz neues Ding: GNU........................................

25

Kapitel 3 Ein kleiner Aufstand....................................................

47

Kapitel 4 Der Faktor X................................................................ 79 Kapitel 5 Patches ohne Ende......................................................

99

Kapitel 6 Erst Boot, dann Root................................................... 121 Kapitel 7 Linus 2.0.................................................. ......................147 Kapitel 8 Lernen von Berkeley............................... .................... 167 Kapitel 9 Die Kunst des Codierens............................ ................. 195 Kapitel 10 Dort unten im Tal..................................... ................... 227 Kapitel 11 Lasst die Eidechse los................................... .............. 255 Kapitel 12 Ein fester Stand........................................ ................... 287 Kapitel 13 Allianzen und Börsengänge....................................... 307 Kapitel 14 Offen fürs Geschäft.......................... ............................331


-------------------------------------------------------------------------------------

Kapitel 15 Trolle und Gnome.......................................................... 351 Kapitel 16 Lügen, verdammte Lügen ... und Benchmarks ............. 375 Kapitel 17 Das Treibhaus von morgen............................................ 403 Kapitel 18 Jenseits des Marktes....................................................... 425 Epilog von Sebastian Hetze: Linux in Europa und Deutschland ... 453 Stichwortverzeichnis.................. ...................................................... 459

Wenn nichts Anderes vermerkt ist, stammt die überwältigende Mehrzahl der Zitate in diesem Buch aus Interviews, die zwischen September 1999 und September 2000 persönlich, telefonisch oder per E-Mail geführt wurden. Ergänzt werden sie durch Material, das aus einem ausführlichen Gespräch mit Linus Torvalds stammt, das ich im Dezember 1996 an einem kritischen Wendepunkt seines Lebens mit ihm führte. Andere Gespräche mit wichtigen Akteuren der Branche in den letzten drei Jahren sind ebenfalls in das Buch eingeflossen. Besonderen Dank schulde ich all jenen, denen es irgendwie gelungen ist, trotz ihrer vollgestopften Terminkalender und ihrer wichtigen Arbeit, Zeit für oft sogar sehr ausführliche Gespräche mit mir aufzubringen. Ich bedaure nur, dass ich nicht mehr Erinnerungen, Gedanken oder Kommentare in das Buch aufnehmen konnte.


------------------------------------------------------------------------------------Trotz der großzügigen Hilfe, die mir zuteil wurde, ist mir bewusst, dass dieses Buch nicht frei ist von Fehlern und Auslassungen, für die ich allein verantwortlich bin. Korrekturen sowie allgemeine Kommentare über den Text nehme ich unter der E-Mail-Adrcsse [email protected] gern entgegen. Das Interview mit Linus Torvalds im Jahr 1996 wurde für einen Sonderartikel geführt, der von Sean Geer, Redakteur der britischen Ausgabe des Magazins Wired, in Auftrag gegeben worden war. Der Artikel erschien in der Augustausgabe der US-Ausgabe von Wired unter dem Titel „The Greatest OS That (N)ever was" (Das großartigste Betriebssystem, das es je/nie gab). Verantwortlicher Redakteur war Jim Daly. Jim empfahl mich freundlicherweise Jacqueline Murphy von Perseus Books, die 1999 Ausschau nach jemandem hielt, der ein Buch über GNU/Linux und Open Source schreiben konnte. Ich danke Jacqueline, die Jims Empfehlung folgte und mich überredete, das Projekt in Angriff zu nehmen. Dankbar bin ich auch Marco Pavia dafür, dass er dieses Buch bis zur Produktion begleitet hat und Jennifer Blakebrough-Raeburn für ihr einfühlsames Lektorat. Zu den Menschen, die mir auf meinem Weg entscheidende Hilfe zuteil werden ließen, zählen auch David Croom. der mir von Anfang an mit wertvollen Ratschlägen zur Seite stand, und zwei Leute, die freundlicherweise die ersten Textentwürfe lasen und wertvolle Kommentare abgaben, Anna O'Donovan und Sean Geer. Schließlich mochte ich noch meiner Frau und meiner Familie meine tiefe Dankbarkeit ausdrücken. Ohne ihre Unterstützung wäre dieses Buch niemals zustande gekommen. Glyn Moody

Draußen senkt sich der Himmel über die geduckten weißen Gebäude von Seattle, die sich klumpenartig um einen riesigen, sich ständig erweiternden Campus auszudehnen scheinen. Manikürt wirkende Rasenflächen, sorgfältig gepflegte Blumenbeete und adrette Zierteiche schaffen eine Stimmung von klosterartiger Stille und Ruhe. Drinnen in den Cubicles, wo junge Männer und Frauen emsig bei der Arbeit sind, herrscht eine ähnliche Ruhe. Das Schweigen wird nur durch das Klappern der Tastaturen durchbrochen; es wird kaum ein Wort gesprochen, fast als hätten alle Anwesenden ein Gelübde abgelegt. Und trotzdem ist inmitten der ruhige Zuversicht ausstrahlenden Atmosphäre ein Unbehagen zu verspüren, eine Vorahnung von etwas, was man fast als Angst beschreiben könnte. Jeder weiß, dass in den klösterlichen Hallen von Microsoft ein schrecklicher Geist sein Unwesen treibt.


------------------------------------------------------------------------------------Der Geist hat einen Namen: Open Source. Seine Kennzeichen wurden von zwei erfahrenen Geistbeobachtern in langen Memos detailliert beschrieben. Obwohl sie den Vermerk „Vertraulich" trugen, tauchten sie außerhalb des Unternehmens auf und wurden - wie passend - zu Halloween 1998 im Web veröffentlicht. Microsoft, das sich gezwungen sah zuzugeben, dass die Memos tatsächlich aus der Firma kamen, tat sie als private, bedeutungslose Spekulationen zweier Techniker ab. Als Bill Gates die Memos las, die dieses verrückte Phänomen beschrieben, rieselte ihm wohl ein anerkennender Schauer über den Rücken - es war, als ob ihm ein Geist aus der Vergangenheit auf die Schulter klopfte. Gates hatte sich schon vor über zwanzig Jahren als Exorzist der freien Software versucht 1976 hatte er einen so genannten offenen Brief an die „Hobbyists" verfasst. Gemeint waren die Benutzer des ersten PC, des Altair des MIT. Gates und Paul Allen, der Mitbegründer von Microsoft, hatten eine Version der Programmiersprache Basic (Beginners All-Purpose Symbolic Instruction Code) geschrieben, die auf dieser rudimentären Maschine lief - eine beträchtliche Leistung, denkt man an den beschränkten Speicher. Gates schrieb seinen offenen Brief, um etwas zu verurteilen, was seiner Meinung nach Softwarepiraterie war - das Anfertigen illegaler Kopien des Programms, das er und Allen geschrieben hatten. In seiner Tirade gegen das gebührenfreie Weitergeben von Software donnerte Gates: „Wie den meisten Hobbyists sicher bewusst ist, stehlen die meisten von euch ihre Software. Hardware muss bezahlt werden, aber Software ist etwas, was man einfach weitergibt. Wen kümmert est ob die Leute, die daran gearbeitet haben, ihr Geld bekommen?" Die weitere Folge einer solchen Piraterie sei, so schrieb er, „dass damit verhindert wird, dass gute Software geschrieben wird." Er endete mit einer rhetorischen Frage: „Wer kann es sich schließlich leisten, professionelle Arbeit zu verrichten, ohne dafür bezahlt zu werden? Wer kann schon drei Mannjahre in das Programmieren, das Aufspüren aller Bugs und das Dokumentieren seines Produkts stecken und es dann gratis verteilen?" Als er diese Zeilen in die Tastatur hämmerte, dachte Gates wahrscheinlich, dass dies unwiderlegbare Argumente seien. Und

PROLOG

--------------------------------------------------------------------------------------trotzdem - die Memos von Halloween, geschrieben von seinen eigenen Technikern, sagten das genaue Gegenteil: Dort draußen gab es nicht nur einen Hobhyisten, sondern Tausende von ihnen. Gemeinsam steckten sie Tausende Mannjahre in das Programmieren, das Aufspüren von Bugs und das Dokumentieren der Produkte, die sie dann mitsamt dem Quellcode gratis verteilten - diesem heiligen Text, den Microsoft und andere Softwareunternehmen in den letzten zwanzig Jahren vor unbefugten Augen streng verborgen gehalten hatten. Vor dem Hintergrund seines offenen Briefs an die Hobbyisten erscheint die Open-Source-Bewegung wie Bill Gates' schlimmster Albtraum auf das Tausendfache vergrößert. Nun waren es nicht nur einige wenige Hobbyisten, die „stahlen", sondern eine ganze florierende Gemeinde, die - exzellenten - Code schrieb, um ihn dann zu verschenken. Da ihr Handeln offensichtlich nicht bewirkte. dass „keine gute Software mehr geschrieben wird", stellten sie indirekt die Grundlage des MicrosoftImperiums infrage: Wenn gute Software geschrieben und einfach so verschenkt werden konnte, wer brauchte dann Microsoft oder ähnliche Unternehmen? Für das Auftauchen der Halloween-Dokumente und die von ihnen aufgeworfenen grundlegenden Fragen hätte es für das Unternehmen keinen schlechteren Zeitpunkt geben können. Das Antitrust-Verfahren, das 1998 vom US-Justizministerium angestrengt worden war, hatte vielleicht zum ersten Mal die Aura der Unbesiegbarkeit von Microsoft geschwächt. Das Verfahren bedeutete, dass die Leute (wenn auch nur theoretisch) die Möglichkeit in Betracht zu ziehen begannen, dass die Computerwelt nicht unbedingt von dem Riesen aus Redmond dominiert werden musste. Diese Möglichkeit wurde dank der anhaltenden Verzögerung eines Produkts plausibler, das Microsoft unbekümmert sein Schlüsselprodukt für Unternehmen nannte. Früher hatte es Windows NT5 geheißen, aber als die Halloween-Dokumente auftauchten, war es soeben auf Windows 2000 umbenannt worden. Wenn Windows NT5 1998 auf den Markt gekommen wäre, hätten die Unternehmen zweifellos zu viel mit der Einführung zu tun gehabt, um Alternativen in Betracht zu ziehen; aber in Verbindung mit dem Antitrust-


------------------------------------------------------------------------------------Verfahren bewirkte das entstandene Vakuum, dass auch andere Optionen in Betracht gezogen werden konnten. Dazu kam ein noch nie da gewesener Schwund an Top-führungskräften, der infolge des Public-Relations-Desasters während des AntitrustVerfahrens sowie aufgrund schwer wiegender technischer Probleme bei der Einführung von Windows 2000 entstanden war. Ausgerechnet jene Leute, die Microsoft am dringendsten für die Lösung dieser Probleme gebraucht hätte, kehrten dem Unternehmen den Rücken. Selbst Bill Gates schien von dem Verfahren, das vom Justizministerium angestrengt worden war, ernsthaft aus dem Gleichgewicht gebracht worden zu sein. Seine grimmige Zeugenaussage, die für die Verhandlung auf Band aufgenommen worden war und bei der er nicht in der Lage zu sein schien, sich an seine eigene E-Mail oder auch nur an seine geschäftlichen Schlüsselentscheidungen zu erinnern, zerstörte ein für alle Mal sein Image als unfehlbarer Hohepriester der Hochtechnologie. Ausgerechnet in diesem Augenblick, als Microsoft am verwundbarsten war und sein Boss mit einem Imagetief kämpfte, tauchte in der Computerwelt nicht nur eine Alternative auf, sondern ein Konkurrent. Die Halloween-Dokumente hatten neben dem Internet den freien Betriebssystemkernel Linux als eines der erfolgreichsten Beispiele der Open-Source-Philosophie bezeichnet. „Linux wird in missionskritischen, kommerziellen Umgebungen angewendet und kann auf einen großen Pool positiver öffentlicher Kommentare verweisen", hatte Vinod Valloppillil, einer der Autoren des Memos, angemerkt. Außerdem stand Linux im Zentrum eines freien Softwareprojekts, das die Kernproduktlinie von Microsoft, nämlich das krisengeschüttelte Windows 2000, direkt angriff. Linux wurde von einem einundzwanzigjährigen finnischen Studenten namens Linus Torvalds entwickelt, der es mitsamt dem Quellcode - den zugrunde liegenden Programminstruktionen, die eine Art Blaupause der Software bilden - gratis verteilte. In Linus, wie er innerhalb seiner Gruppe allgemein genannt wird, hatte die Open-Source-Umgebung nicht nur eine talentierte Leitfigur, sondern eine unschätzbare Ikone gefunden. Obwohl komplexe, aber

PROLOG

--------------------------------------------------------------------------------------wichtige Fragen der Methoden der Softwareentwicklung die Massenmedien kalt ließen, erwies sich der bescheidene und fotogene junge Mann bald als Medienmagnet. Linus schien all das zu verkörpern, was Bill Gates nicht war, so wie Open Source die Antithese zu Microsoft war. Linus stand auch im Gegensatz zu dem traditionellen Bild der Protagonisten der Open-Source-Bewegung. Diese Hacker, wie sie sich selbst nannten (nicht zu verwechseln mit den böswilligen Crackern oder Crashern, die aus niederen Beweggründen durch Sicherheitslücken in Computersysteme einbrechen), galten traditionell als schlecht angepasste Jugendliche, die zu Hackern werden, weil ihnen soziale Fähigkeiten fehlten und weil sie sich an den Rand gedrängt fühlten. Und dann kam Linus Torvalds, ein Hackerprinz, der sich nicht nur regelmäßig wusch, einen ordentlichen Haarschnitt hatte und sauber und adrett gekleidet war, sondern auch Inhaber eines respektablen Jobs, Ehemann und Vater war. Es hätte kein besseres Symbol für die neue Hackergeneration geben können, die Open Source zu einem der einflussreichsten Elemente der Computerwelt von heute machte. Die neuen Hacker sind die Erben einer früheren Hackerkultur, die in den sechziger und siebziger Jahren florierte, als Computer noch Neuheitswert hatten. Die damalige Computergemeinde war der Meinung, dass Software etwas war, was weitergegeben werden sollte, damit alle davon profitieren konnten. Das war die Ethik, die Bill Gates in seinem offenen Brief an die Hobbyisten so beklagt hatte. Microsoft und einige andere große Marktakteure der damaligen Zeit, insbesondere AT&T, waren in erster Linie dafür verantwortlich, dass der alte Hackergeist nahezu erstarb und durch die Ansicht ersetzt wurde, dass die Weitergabe von Software Pirateric sei. Dank der Einführung der relativ kostengünstigen, aber leistungsstarken PCs und der Globalisierung des Netzes sind die neuen Hacker unvergleichlich zahlreicher, produktiver und geeinter als ihre Vorgänger. Verbunden werden sie von einem gemeinsamen Ziel großartige Software zu schreiben - und einem gemeinsamen Glauben: dass diese Software allen kostenlos zur Verfügung stehen sollte. Die Hacker rebellieren gegen die Vorstellung, dass der zugrunde liegende Quellcode geheim gehalten werden sollte. Für


------------------------------------------------------------------------------------sie sind diese Spezialtexte eine neue Art Literatur, die einen Teil des gemeinsamen Erbes der Menschheit bildet. Ihrer Meinung nach soll diese Literatur veröffentlicht, gelesen und sogar erweitert werden und nicht in den Schreibtischschubladen unzugänglicher Klosterbibliotheken verkümmern, wo sie nur von einigen Eingeweihten ehrfürchtig betrachtet werden kann. Die Folge ist dass die Open-Source-Umgebung nicht nur für Microsoft eine Herausforderung darstellt, sondern für die gesamte Softwarebranche und möglicherweise sogar noch für andere Branchen. Denn je wichtiger das Internet für die moderne Welt wird, desto unausweichlicher wird es, dass es jene freien Programme transportiert, auf denen es beruht, und jene Werte verbreitet die zu ihrer Entstehung führten. Der grundlegende Geist der Offenheit, der Großzügigkeit und der Zusammenarbeit beginnt sich über die Grenzen einer oder zweier Hightechbranchen hinaus zu verbreiten. Heute meinen schon viele, dass diese viel versprechende Kombination von Internet und Open Source mehr als den Funken einer Chance hat, in der Post-Microsoft-Ära unserer Zeit zu überleben.

1

Das coolste Jahr

WENN 1998 UND 1999 DIE SCHLIMMSTEN JAHRE in der Geschichte von Microsoft waren, muss 1991 ein Jahr gewesen sein, in dem sich Bill Gates wunderbar fühlte. Windows 3.0, eingeführt im Mai 1990, war zunehmender erfolgreich; allein im ersten Jahr wurden vier Millionen Kopien ausgeliefert, eine enorme Zahl für die damalige Zeit. Im Mai 1991 führte Microsoft Visual Basic ein, eine radikal neue Programmiermethode, die anstelle der traditionellen Designmethoden, die auf der Bearbeitung von Textdateien beruhten, auf visuelle setzte. Etwas noch Besseres stand unmittelbar bevor: Windows 3.1. Obwohl es sich nur um ein Punkt-Upgrade handelte, war Version 3.1 in fast jeder Hinsicht eine wesentliche Verbesserung gegenüber Version 3.0. Microsoft behauptete, dass sie über 1.000 Verbesserungen enthielt. Die coole neue Benutzerschnittstelle begeisterte fast alle, die sie zu Gesicht bekamen.


------------------------------------------------------------------------------------Als Windows 3.1 im Juni 1992 ausgeliefert wurde, zementierte es die vorherrschende Stellung von Microsoft auf dem Desktop. Es fährte auch zu einer Diskontinuität in der Softwarewelt da die Unternehmen von Programmen auf DOS-Basis auf solche umstiegen, die unter Windows liefen. Microsoft konnte diese Umstellung nutzen, um sich in den Bereichen Tabellenkalkulation und Textverarbeitung an die Spitze zu katapultieren, indem es rasch Programme wie Excel und Word auf den Markt warf. Windows 3.1 war nicht das einzige wichtige Betriebssystem, das 1991 knapp vor der Fertigstellung stand. Microsoft Windows New Technology, besser bekannt als Windows NT, war 1988 in der Hoffnung eingeführt worden, ein Betriebssystem auf Unternehmensebene zu schaffen, das in den Büros der Unternehmen genauso breit eingesetzt werden konnte wie MS-DOS, und Windows sollte in den Verkaufsräumen dominieren. Pionier des Windows-NT-Projekts war Dave Cutler, der das Betriebssystem VMS für den Computerriescn Digital, ehemals als DEC bekannt, entwickelt hatte. VMS war ein Konkurrent von Unix, einem anderen robusten Betriebssystem, war aber im Gegensatz zu Unix, das immer als eine Software für Hacker gegolten hatte, ein offizielles Unternehmensprodukt. Auch Windows NT wurde unverblümt als UnixKiller lanciert, als sich entgegen den Erwartungen Unix und nicht VMS als führendes Betriebssystem für Unternehmen entpuppte. Die Chancen von NT lagen gut. Ende der achtziger Jahre war Unix hochgradig zersplittert, und jeder Anbieter hatte eine geringfügig andere Version; das bedeutete, dass die Anwendungssoftware viele Male umgeschrieben werden musste und dass die Benutzer an die Software eines Lieferanten gefesselt waren. Da es Unix auch nicht gelungen war, voll auf den Zug der grafischen Schnittstellen aufzuspringen, waren seine Lösungen in diesem Bereich im Vergleich zu Apple Macintosh oder Microsoft Windows unelegant. Windows NT war im Gegensatz dazu ausgelegt, die Leistung eines VMS-ähnlichen Betriebssystems mit der Eleganz und Benutzerfreundlichkeit von Windows 3.1 zu verbinden. Außerhalb des unmittelbaren Intcressensbereichs von Microsoft passierte in dieser Zeit viel. 1991 brachte Tim Berners-Lee, ein

1. Das coolste Jahr

---------------------------------------------------------------------------------------

britischer Physiker im Europäischen Kernforschungszentrum CERN, ein Hypertextsystem heraus, das er in den vergangenen zwei Jahren entwickelt hatte. Das System, das er das World Wide Web nannte, lief über das Internet, ein damals noch kleines Netz, das hauptsächlich von Wissenschaftlern verwendet wurde. Ebenfalls 1991 entwickelte ein Team von Sun Microsystems eine neue Programmiersprache namens Java. Ursprünglich ein Versuch, eine interaktive Settopbox für die Kabelfemsehindustrie zu entwickeln, wurde Java später für die Verwendung im Internet adaptiert. Ein wichtiges Feature von Java war die Portierbarkeit: Dasselbe Programm konnte ohne Modifikationen auf einer breiten Palette von Hardware verwendet werden - damals eine Neuheit. Obwohl die Bedrohung, die diese Entwicklungen zur damaligen Zeit darstellten, im Vergleich zu ihren späteren Auswirkungen vernachlässigbar waren, ist es möglich, dass Microsoft sie 1991 bereits verfolgte. Das Internet war schon bekannt, das Web stand im öffentlichen Besitz, und Sun war ein Konkurrent, dessen Schritte auf jeden Fall mit Aufmerksamkeit verfolgt werden mussten. Aber es ist nicht vorstellbar, dass Microsoft im selben Jahr auch nur den geringsten Verdacht hätte hegen können, dass im Schlafzimmer eines Computerstudenten im zweiten Jahr m Helsinki, Finnland ein Schlüsselelement einer ebenso großen Bedrohung drauf und dran war, Gestalt anzunehmen. Linus Benedict Torvalds wurde am 28. Dezember 1969 in eine geordnete Welt hineingeboren. Er erklärt die Bedeutung dieses Tages in seiner Kultur: „Es ist im skandinavischen Kalender ein besonderer Tag, der mit einer traditionellen Bedeutung belegt ist. Der 28. Dezember ist der .mcnlösa barns dag', der ,Tag der unschuldigen Kinder'.“ Der Name Linus war eine außergewöhnliche Wahl: „Nicht gänzlich unbekannt", so Linus, „aber in Finnland auch nicht wirklich häufig." Der Name selbst hat eine Geschichte, die an die Wurzeln der westlichen Zivilisation reicht Er kommt in Homers Ilias in seiner original griechischen Form Linos vor, wo er mit einem Trauerlied in Verbindung gebracht wird. Es gibt auch einen Heiligen Linus, der traditionell als zweiter Papst nach dem heiligen Petrus genannt wird. Ein weiterer berühmter Linus - der allerdings


------------------------------------------------------------------------------------besser unter seinem Nachnamen bekannt ist - ist der amerikanische Erfinder Linus Yale. „Ich glaube, dass auch der Cartoon-Linus Pate für meinen Namen stand", sagt Linus hinzu und merkt an, dass ihn das zu einer „50:50-Mischung zwischen nobelpreisgekröntem Chemiker und einer Schmusedecke tragenden Cartoonfigur11 mache. Die Familie Torvalds gehört in Finnland zur schwedischsprachigen Gemeinde, die rund 300.000 Personen zählt. Dass die Muttersprache dieser Leute sprachlich nichts mit der finnischen Sprache zu tun hat von der sie umgeben sind, hat zweifellos dazu beigetragen, dass sie eine eng verschworene Gemeinschaft bilden. Der Name, den die Schwedischsprachigen ihrer Gruppe selbst verliehen haben Ankdammen (Ententeich) -, spiegelt diese Tatsache wider. Einer von Linus' Freunden aus Helsinki, sein späterer Hackerfreund Lars Wirzenius, sagt: „Fast alle schwedischsprachigen Leute kennen andere schwedischsprachige Leute, die ihrerseits wieder viele schwedischsprachige Leute kennen. Das führt letzten Endes dazu, dass jeder jeden kennt oder jeder jemanden kennt, der seinerseits jemanden kennt." Als Mitglied des „Ententeichs" sprach Linus zu Hause und mit Freunden der Familie Schwedisch. Finnisch begann er erst im Alter von fünf Jahren zu lernen. Der Kontakt mit Englisch, das Jahre später ein entscheidender Faktor seiner Arbeit werden sollte, kam erst einige Jahre später. Etwa um diese Zeit hatte er das erste Mal mit einem Computer zu tun. Linus erzählt, dass sein Großvater mütterlicherseits Statistiker an der Universität von Helsinki war. Er kaufte einen Commodore VC-20Mikrocomputer, „einen der ersten auf dem Markt, zumindest in Finnland". Er fügt hinzu: „Er war nicht wirklich das, was uns heute vor Ehrfurcht erblassen lassen würde, aber er war damals jedenfalls schneller als jeder andere Rechner." Die Prozessorgeschwindigkeit betrug nur 1 Megahertz, etwa ein Tausendstel der Geschwindigkeit moderner PCs. Linus erinnert sich, dass sein Großvater „den VC-20 für seine mathematischen Aufgaben kaufte", aber bald bat er seinen jungen Enkelsohn um Hilfe. „Ich glaube, mein Großvater wollte in Wahrheit, dass ich den Umgang mit dem Gerät lernte. Deshalb bat

1. Das coolste Jahr

--------------------------------------------------------------------------------------er mich um Hilfe", erklärt er. „Also begann ich, ihm mit dem Computer zu helfen, und dann machte ich daneben das, was mich selbst interessierte“ Linus erinnert sich: „Ich hatte den VC fünf Jahre lang, weil ich mir nichts Besseres leisten konnte. Etwa die beiden ersten Jahre programmierte ich in Basic.“ Aber Linus ließ diese populäre Anfängersprache bald links liegen und wandte sich etwas Anspruchsvollerem zu: der Assembler-Sprache. Die Befehle in Assembler sind für den Computer leichter zu verarbeiten, aber für die Programmierer ist es schwerer, in dieser Sprache zu denken. „Ich lernte mit der Zeit, selbst Dinge zu tun, indem ich Bücher über Assembler las", erzählt er. „Ich hatte keine Ahnung von Assemblern" - Programmen, die das Programmieren in Assembler leichter machten -, „also mussie ich alles von Hand machen. Nach einigen Jahren musste ich mir ein besseres Gerät anschaffen, weil nun alle bessere Computer hatten." Linus nennt einen weiteren Grund für die Anschaffung eines neuen Computers. „Ich kannte den VC schon zu gut." Linus sollte während seines gesamten Lebens als Computerexperte nach neuen Programmierherausforderungen suchen, aber es ist interessant, dass sich dieser Zug schon so früh herauskristallisierte. Seine nächste Maschine und die Gründe, warum er sie wählte, sind ebenfalls höchst charakteristisch für den späteren Linus. „Ich sah mir verschiedene Maschinen an. Einen PC wollte ich nicht, weil mir die Z80-[Chip]architektur überhaupt nicht gefiel und weil der Chip des PC im Wesentlichen derselbe war", sagt er. Er entschloss sich, keinen PC zu kaufen, weil ihm das Design der Intel-Chipfamilie, die seinen Kern bildete, missfiel. Eine außergewöhnliche Art, die Dinge zu sehen. „Damals arbeitete ich nur in Assembler, und ich wollte nichts mit diesem [spezifischen Prozessor] zu tun haben/' Da Linus maschinennahen „Low-Lcvel“-Code schrieb, der direkt mit dem Chip interagierte, waren ihm die Vor- und Nachteile der verschiedenen Chipfamilien vertraut. Die meisten Programmierer schreiben in Hochsprachen wie Basic, die sie effektiv von den Details der Hardware abschirmen.


------------------------------------------------------------------------------------Wie Linus selbst sagt, war er seit jeher ein „Low-Level“-Mann. Für sein früh erwachtes Interesse an diesem Aspekt gibt es wahrscheinlich zwei Gründe. Einer war seine sich entwickelnde Liebe zum Programmieren auf der grundlegendsten Ebene. Der andere ist pragmatischerer Natur: „Ich war seit jeher ein Leistungsjunkie. Wenn man Spiele für einen langsamen 1-MHz-Prozessor schreiben musste", erklärt Linus, „musste man irgendwie verrückt sein und die Zyklen auspressen. „Zyklen auszupressen“ bedeutete, dem Code auch noch den letzten Leistungstropfen zu entringen. Das sollte später dazu führen, dass Linux viel schneller und schlanker war als vergleichbare Programme. Am Ende entschied sich Linus für einen außergewöhnlichen Mikrocomputer, den Sinclair QL (Quantum Leap). Der war ein verrücktes Produkt des britischen Erfinders Sir Clive Sinclair. Linus gab sich aus einem einfachen Grund mit dem Sinclair QL zufrieden, obwohl das Gerät offensichtliche Mangel hatte. Das Wichtigste war für ihn, „eine Maschine zu Hause zu haben, die zu Multitasking fähig ist" Obwohl der Sinclair QL in vielerlei Hinsicht ein Spielzeug war, hatte er dank seines Chips ein sehr leistungsstarkes Merkmal: Er konnte wie kommerzielle Minicomputer mehrere Programme gleichzeitig abarbeiten. Diese Fähigkeit namens Multitasking ermöglichte es ihm, den Code für ein einfaches Programm zu schreiben, das schließlich zu Linux werden sollte. Aber das war einige Jahre nach der Zeit, als Linus auf seinen Sinclair QL einhackte. Im Herbst 1988 trat er in die Universität von Helsinki ein, um Computerwissenschaften zu studieren, und nun hatte es den Anschein, als wollte er seine Leidenschaft zu seinem Beruf machen. An der Universität stellte Linus fest, dass die zweisprachigen Gemeinden die Tendenz beibehielten, jeweils für sich zu bleiben. Sein Kollege beim Studium der Computerwissenschaften, Lars Wirzenius, meint dass „es damals nicht besonders viele schwedischsprachigen Studenten der Computerwissenschaft gab, und die, die es gab, waren mindestens ein paar Jahre älter als wir". Deshalb war es nur natürlich, dass sich innerhalb der finnischen Mehrheit eine Hand voll schwedischsprachiger Studenten zusammenfand.

1. Das coolste Jahr

--------------------------------------------------------------------------------------Wirzenius erinnert sich an das erste Mal, als er Linus traf: „Es war bei einer der Einführungsvorlesungen für neue Studenten." Wirzenius bemerkte an diesem Tag nicht viel von seinem Freund, außer dass „die Spitze seiner großen Nase zuckte, wenn er sprach, und das war lustig anzusehen". Abgesehen von der Nase, die in Wahrheit nicht ganz so groß ist, gibt es in Linus' Erscheinungsbild nur wenig Außergewöhnliches. Er ist mittelgroß, hat braunes Haar, und seine blauen Augen blicken ruhig hinter seiner Brille hervor. Nur die Augenbrauen, die bemerkenswert dunkel und buschig sind, machen das ansonsten jungenhafte Gesicht etwas ernster. In dem Bestreben, mehr Studenten im Ententeich aufzuspüren, schlössen sich Wirzenius und Linus einem der vielen Vereine an, die einen wichtigen Bestandteil der Studentenszene der Universität von Helsinki bilden. „Der Klub, dem Linus und ich beitraten, nannte sich Spektrum", erinnert sich Wirzenius. „Das war der schwedischsprachige Klub für Leute, die Mathematik, Computerwissenschaft, Physik oder Chemie studierten." Was den Unterricht an der Universität anbelangte, erklärt Wirzenius, dass es „eigentlich keinen Lehrplan gibt, der einem sagt dass man im ersten Jahr diesen oder jenen Kurs belegen soll. Die so genannte akademische Freiheit in Finnland wird so interpretiert, dass die Studenten jeden Kurs belegen können, den sie wollen, und größtenteils auch in der Reihenfolge, die sie für richtig halten," „Einmal hatte Linus - ich weiß nicht mehr aus welchem Grund -in einem Kurs seine Hausarbeiten nicht gemacht. Also behauptete er einfach, er hätte eine der Übungen gemacht, die er in Wirklichkeit nicht gemacht hatte, und der Lehrer bat ihn prompt, seine Lösung zu präsentieren. [Linus] ging an die Tafel ... und war zum ersten Mal mit dem Problem konfrontiert, das er angeblich bereits gelöst hatte. Linus erklärte, dass es ganz einfach sei, zeichnete ein paar Diagramme und wedelte viel mit der Hand. Es dauerte lang, bis der Lehrer verstand, dass ihm da tatsächlich eine richtige Lösung präsentiert wurde." Laut Wirzenius war dieser Vorfall in einer Hinsicht atypisch: [Linus] schwindelte normalerweise nicht, weil er das nicht nötig hatte. Er konnte Mathematik noch vom Gymnasium her gut. Er hatte eine Art mathematisches Denken, und deshalb brauchte er


------------------------------------------------------------------------------------nicht viel Zeit auf Hausaufgaben zu verwenden. Wirzenius ist davon überzeugt, dass die Art, wie sein Freund mit der Situation umging, etwas Charakteristisches hatte - „die Einstellung, die Arroganz, die er an den Tag legte; die meisten Leute hätten einfach zugegeben, dass sie die Lösung nicht hatten“, aber Linus hasste es zuzugeben, dass er eine Antwort nicht wusste. Wirzenius sagt, dass die „Arroganz, die er damals zeigte, heute immer noch sichtbar ist" - und zwar darin, wie Linus an Herausforderungen innerhalb der Linux-Gemeinde herangeht. „Heute könnte er behaupten, dass ein bestimmter Ansatz zur Lösung eines Problems der richtige ist, obwohl er nicht unbedingt über alle anderen möglichen Ansätze oder Lösungen nachgedacht hat, und dann stimmt ihm der Rest der Internetgemeinde entweder zu oder versucht, ihn von etwas anderem zu überzeugen." Dieser Ansatz funktioniert, weil Linus „klug genug ist, das nicht dauernd zu tun. Wenn er etwas sagt, hat er meistens darüber nachgedacht", erklärt Wirzenius und schließt an: „Ich möchte lieber nicht mit ihm pokern. Er kann nämlich bluffen." Aber wenn Linus beim Bluffen ertappt wird und man ihm das Gegenteil beweist, akzeptiert er die Korrektur mit freundlicher Mine. Dieser Charakterzug erwies sich im Umgang mit der Gemeinde gleich gesinnter und begabter Hacker, die sich später um ihn sammeln sollte, als entscheidend. Dem Einführungskurs des ersten Jahres folgte eine wesentliche Unterbrechung ihrer Studien. „Alle finnischen Männer müssen entweder Militär- oder Zivildienst leisten", erzählt Wirzenius. „Der Zivildienst ähnelt einem normalen Job, abgesehen davon, dass man dafür nicht bezahlt wird." 1989, als er und Linus vor die Wahl gestellt wurden, „betrug die kürzeste Zeit für den Militärdienst acht Monate, während der Zivildienst auf jeden Fall sechzehn Monate dauerte. Also dachte ich mir, dass acht Monate schon zu viel seien, und ich wollte natürlich den kürzestmöglichen Dienst. Mit der allerkürzesten Zeit kam man davon, wenn man beide Dienste verweigerte - dann musste man für sechs Monate ins Gefängnis." Wie Wirzenius entschied sich auch Linus gegen das Gefängnis. Aber anstatt sich für die nächstkürzere Option zu entscheiden -

1. Das coolste Jahr

--------------------------------------------------------------------------------------acht Monate als einfacher Soldat -, verpflichtete er sich auf elf Monate und absolvierte eine Offiziersausbildung. Über diese Ausbildung sagt Wirzenius: „Irgendwie ist es als Leadershipübung gar nicht so schlecht, aber nur für eine bestimmte Art Leadership ... Was das Militär braucht, sind Gruppenführer, die ihrer Gruppe beibringen, fast auf Reflex zu handeln, was irgendwie angsterregend ist. Das ist das Zeug, das man beim Militär immer lernt, egal, wo man ist." Er fügt hinzu: „Dabei wäre es nicht nur notwendig zu lernen, wie man Reflexe hervorruft, sondern auch, wie man eine Gruppe als Arbeitseinheit zusammenhält, wenn sich ihre Mitglieder nicht mögen und Ähnliches mehr." Besser hätte man kaum beschreiben können, welche Fähigkeiten für die Koordination der globalen Freiwilligenbewegung, die Linux entwickelt, notwendig sind. Wirzenius erinnert sich, dass Linus und er einander in dieser Zeit nicht viel sahen, obwohl sie gegen Ende ihres Dienstes beide im selben Gebiet im Osten Finnlands stationiert waren; sobald sie aber wieder an der Universität waren, holten sie die verlorene Zeit auf und machten sich wieder mit Fifer an die Erforschung der Computerwelt. Sie belegten einen Kurs, der nicht nur sie beeinflussen sollte -Wirzenius sagte, es fühle sich an „wie sich das erste Mal zu verlieben" -, sondern die ganze Geschichte der Computerwelt. Im Herbst 1990 begannen sie, mit dem von der Universität kurz davor erworbenen Micro VAXSystem zu arbeiten, das von niemand anderem als Dave Cutler entwickelt worden wart der zu diesem Zeitpunkt fleißig an der Entwicklung von Windows NT arbeitete. Wirzenius und Linus standen davor, Unix zu entdecken.

(Leerseite)

2

Ein ganz neues Ding: GNU

ElN PROGRAMM, DAS LINUS' HERZ im Herbst 1991 ein wenig höher schlagen ließ, war Ultrix von Digital, eine der vielen kommerziellen Varianten des Unix-Betriehssystems. Daneben gab es andere wie Solaris von Sun, AIX von IBM und HP-UX von HewlettPackard. Trotz des Durcheinanders an Versionen leiteten sie sich alle vom Unix-System ab, das von Ken Thompson und Dennis Ritchie im Jahr 1969 - Linus' Geburtsjahr - in den Labors von AT&T Bell entwickelt worden war, Peter Salus, Autor des Buches A Quarter Century of Unix, das allgemein als die Standardgeschichte dieses Betriebssystems gilt, erklärt, wie Unix zustande kam: „Anfang 1969 war da eine Gruppe von Leuten, die an einem Gemeinschaftsprojekt von MIT, AT&T Bell Labs und General Electric arbeiteten. Das Projekt wurde Multics genannt. Im Februar 1969 hatten sie das Budget um mehrere Millionen überschritten, sie hinkten Monate hinter dem


------------------------------------------------------------------------------------Zeitplan her, und schließlich entschieden die Chefs von Bell Labs, das Ganze sein zu lassen. Sie zogen sich aus dem Vertrag zurück. „So kam es, dass die Hand voll Beil-Mitarbeiter, die an dem Projekt gearbeitet hatten, plötzlich nichts mehr zu tun hatten*', fährt Salus fort. „Aber sie hatten jede Menge Ideen, die ihnen aus der fruchtbaren Zusammenarbeit mit GE und dem MIT geblieben waren." Zu ihnen zählten Ken Thompson und Dennis Ritchie. Sie beschlossen gemeinsam, von dem ursprünglichen Projekt abzugehen, hielten jedoch „eine abgespeckte Version dieses unglaublichen Projekts für eine viel kleinere Maschine" für möglich. „Die Maschine, an der das Projektteam arbeitete, war ein GE 645 - das, was man ein ordentliches Stück Blech nennen würde", sagt Salus. „Dennis und Ken begannen, ein paar Ideen auf eine Tafel zu kritzeln", fuhr er fort. „Im August '69 hatten Ken Thompson und seine Frau einen Sohn bekommen. Der war nun schon fast ein Jahr alt, und keiner der Verwandten der Familie, die alle an der Westküste der USA lebten, hatte ihn noch gesehen. Also packten [Kens Frau] Bonnie und er ihren fast Einjährigen ins Flugzeug und verbrachten mit ihm den August 1969 an der Westküste." In dieser Zeit, so Salus, „setzte sich Ken einfach auf seine vier Buchstaben und schrieb das Unix-Betriebssystem in vier Wochen in Assembler" - der maschinennahen Programmiersprache, die nur etwas einfacher ist, als den zweistelligen binären Maschinencode direkt einzugeben. „Er sagte mir, es sei gar nicht so schlecht. Für mich war es auf jeden Fall das, was Brooks den .mythischen Mannmonat' nannte. Es war wirklich nur ein einziger Mannmonat eines Typen, den ich für den wahrscheinlich [großartigsten] Meisterprogrammierer halte, den ich je gesehen habe. Es war ungeheuerlich", schließt Salus. Fred Brooks klassisches, 1974 erschienenes Essaybuch The Mythikal Man-Month, war eine frühe und geistreiche Analyse der Probleme des Managements großer Softwareprojekte. Mit dem neuen Unix änderte sich die Denkweise über Betriebssysteme. „Die Unix-Philosophie ist im Grunde ganz einfach", sagt Salus. „Sie besteht aus vielleicht zwei oder drei Ideen. Die erste, die vielleicht innovativste, die Thompson je hatte, lautet, dass alles eine Datei ist. Die zweite lautet, dass man, wenn man etwas

2. Ein ganz neues Ding: GNU

--------------------------------------------------------------------------------------entwickelt, ganz gleich, ob es ein Editor ist oder eine Methode zum Anhängen einer Datei an eine andere, die Dinge so schreibt, dass sie nur einen einzigen Zweck erfüllen, den aber hervorragend." Die erste Idee hätte vielleicht einige amüsante persönliche Konsequenzen für Linus gehabt, die zweite erwies sich jedoch als entscheidend für den Erfolg von Linux. Sie bedeutete, dass ein Unixartiges Betriebssystem Stück für Stück entwickelt werden konnte und dass Außenstehende durch eigene Arbeit an einigen der Komponenten Beiträge leisten konnten. Es war sogar vorstellbar, dass eine Person wenn sie nur gut genug war - das gesamte Betriebssystem allein entwickeln konnte, wenn man ihr nur genug Zeit gab. Eine solche außergewöhnliche Person war Richard Stallman, der jahrelang daran arbeitete, ein Unix-artiges System zu entwickeln, das von der Pike aufgeschrieben werden und gratis verteilt werden sollte. Er arbeitete zunächst allein; dann erhielt er zunehmend Beiträge von anderen, darunter von Linus, dessen Programm Linux sich als das letzte Puzzleteilchen erweisen sollte, das in Stallmans riesigen Softwarepuzzle noch fehlte. Richard Matthew Statlman wurde 1953 in New York geboren. Er war Einzelkind. Sein Vater besaß eine Druckerei, seine Mutter war Lehrerin. Er wuchs auf der New Yorker West Side auf und profitierte von den vielen Anregungen der großen Stadt. Wie sicher Stallman im Umgang mit Computern war und wie breit seine intellektuellen Fähigkeiten waren, zeigt eine Bemerkung anlässlich seines Eintritts in Harvard im Jahr 1970, es sei wohl „überflüssig", dort Computerwissenschaften zu studieren. „Ich lernte das Programmieren, indem ich es einfach tat, und so beschloss ich, das Studium anderen Zwecken zu widmen. Ich wollte so viel wie möglich lernen", sagte er und wählte Mathematik und Physik als Hauptfächer. „Ich liebte die Mathematik", schreibt er. „Ich sagte immer zu den Leuten, dass ,MathYou' mein Mittelname sei." Aber „die Freude, die ich daran hatte, programmieren und etwas Richtiges produzieren zu können", wurde bald übermächtig, wie er schreibt. „In Physik und Mathematik konnte ich nur lernen, nichts tun, und so gewann meine Freude, etwas mit dem Computer zu


------------------------------------------------------------------------------------bewerkstelligen, schließlich die Oberhand." Trotzdem graduierte Stallman 1974 in Physik - magna cum laude. Stallman war unendlich stolz darauf, dass die Programme, die er schrieb, „für die Leute nützlich waren. Darauf war ich viel stolzer als auf die Dinge, die ich nur gelernt hatte." Dieser Wunsch, etwas zu tun, was anderen half, wurde bald zu einer der stärksten Triebfedern seines Lebens; er sollte unerwartete Auswirkungen auf die Softwarewelt haben, die er eben erst für sich entdeckte. Eines der entscheidendsten Ereignisse in seiner Harvard-Zeit trug sich 1971 am Ende seines Freshman-Jahres zut als er dem berühmten AILabor einen Besuch abstattete. Das AI-Lab war damals eines der großartigsten Forschungszentren der Welt, das sich mit künstlicher Intelligenz (Artificial Intelligence - AI) befasste, deren Ziel es ist, Computern menschenähnliche Fähigkeiten zu verleihen. Die Größe dieser Aufgabe erforderte die modernste Computertechnologie der damaligen Zeit, und das AI-Lab lockte die besten Programmierer der Welt an. Obwohl dieser Besuch in diesem Mekka der Computerwissenschaften im Jahr 1971 überraschend spät erscheint, wusste Stallman nicht erst seit damals von seiner Existenz. Außerdem, so sagt er, „war ich irgendwie schüchtern, ich kannte dort niemanden, ich wusste nicht, wie sie jemanden wie mich behandeln würden. Aber schließlich brachte ich doch den Mut auf, mich in die Höhle des Löwen zu wagen und zu sehen, was dort los war." Der Vorstoß erwies sich als erfreulich unproblematisch. „Ich spazierte herum, sagte, dass ich gern eine Dokumentation [über ihren Computer] hätte, und jemand schlug mir vor: ,Nun, und wie wäre es mit einem Sommerjob?' Dann brachten sie mich zu irgendeinem Manager. Er redete mit mir und sagte: ,0K, wir stellen Sie ein.'" Stallman wusste damals noch nicht, dass er drauf und dran war, in ein Hackerparadies einzutreten. Die Treibhausatmosphäre, in der das kleine Grüppchen großartiger Programmierer arbeitete, wird von Steven Levy in seinem 1984 erschienenen Buch Hackers sehr anschaulich beschrieben. Levy beschreibt das klassische Hackerleben: Schlafen am Boden des AI-Lab, wenn die Erschöpfung schließlich den Sieg über die Inspiration davontrug; die zahllosen chinesischen Take-away-Mahlzeiten,


--------------------------------------------------------------------------------------die hitzigen Diskussionen, die Wortspiele, die Streiche. „Spaß" war ein zentrales Wort im goldenen Zeitalter des Hackens. „Wir hatten Spaß beim Programmieren, wir hatten Spaß, wenn wir einander auf die Schaufel nahmen", sagt Stallman. Er beschreibt den Hackergeist als „spielerische Cleverness" Dieses Eldorado blieb Stallman fast zehn Jahre lang erhalten, nachdem er den Ferienjob im AI angenommen hatte. Seine Aufgabe bestand darin, das Betriebssystem des Digital-PDP-10-Minicomputer des AJLab leistungsfähiger zu machen. Die Software, die er dazu verwendete, nannte sich ITS, Incompatible Time-Sharing System. Der Name war eine bewusste Anspielung auf das frühere Compatible Time-Sharing System CTSS, das für die Entwicklung von Multics, dem Vorgänger von Unix, verwendet worden war. Obwohl es keinen wirklichen Plan für seine Arbeit gab - Jch tat eigentlich nichts anderes, als mir ein Feature auszudenken und es hinzuzufügen, sagt Stallman -, bestand das Ergebnis in der berühmtesten und leistungsfähigsten Software, die je geschrieben worden war, auch wenn sie heute außerhalb der Programmiererkreise nur wenig bekannt ist. Es handelt sich um ein Editorprogramm namens Emacs, das für ,Editing MACroS´ steht.“ In der textbestimmten, vorgrafischen Welt vor Apple Macintosh und Microsoft Windows war der Editor ein wichtiges Programm für die Erstellung und Bearbeitung von Text. Er war für die damaligen User so wichtig wie es der Webbrowser für das Internetzeitalter ist. Der vorhergehende ITS-Editor hieß TECO, was für TExt Editor und COrrector stand und sich ebenfalls auf eine Sprache desselben Namens bezog. „Die Leute editierten nicht länger, indem sie TECO-Befehle eingaben", erklärt Stallman. „Stattdessen schrieben sie große Sammlungen von TECO-Programmen namens Makros, und die Benutzer riefen die Makros auf." Die Makros hatten für die Benutzer den Vorteil, dass sie nun mehr unmittelbares Feedback auf dem Bildschirm erhielten. „Emacs diente dazu, die besten Ideen der anderen in TECO geschriebenen Editoren zu vereinen und einen Editor zu entwickeln, der sie ersetzen und die besten Merkmale und Features von ihnen allen in sich vereinen würde." Das erste Emacs kam 1975 heraus. Ursprünglich wurde das Programm nur am MIT verwendet - „nicht nur innerhalb des AI-


------------------------------------------------------------------------------------Labs, sondern auch von ein paar benachbarten Labors, die ebenfalls mit ITS arbeiteten", und Emacs lief nur auf HS. Ein oder zwei Jahre später „portierte jedoch jemand TECO, damit es auf einem anderen TimeSharing-System laufen konnte", erinnerte sich Stallman. Mit „Portieren" ist das Übersetzen eines Programms gemeint, sodass es auf einer anderen Hardware verwendet werden kann; sobald TECO anderswo laufen würde, würde auch Emacs laufen. Dieser Schritt bewirkte nicht nur, dass sich Emacs verbreitete, sondern er hatte auch andere wichtige Folgen. Mit den Kopien verschickte Stallman die „informelle Regel" aus, „dass jeder, der Verbesserungen vornimmt, sie zu mir zurücksenden muss". Diese informelle Regel wurde, sobald sie sich durchgesetzt hatte, zur Grundlage der gesamten Bewegung der freien Software und einer der entscheidendsten Faktoren für ihren Erfolg. Stallman hatte die informelle Regel deshalb festgelegt, weil er Leuten Kopien schickte, die außerhalb der unmittelbarer Hackergemeinde im AI-Lab standen und „überhaupt keine Erfahrung damit hatten; also betrachtete ich es nicht als selbstverständlich, dass sie ihre Ergebnisse weitergeben würden", sagte er. Die Frage der Weitergabe, die mit dem Schreiben von Computerprogrammen anscheinend untrennbar verbunden ist, war für die Ereignisse Anfang der achtziger Jahre von enormer Wichtigkeit. Diese Ereignisse machten nicht nur der einzigartigen Gruppe ein Ende, die im AI-Lab so lange floriert hatte, sondern trieben Stallmans Programmierkünste auf ein Niveau, das wahrscheinlich weder davor noch danach jemals erreicht wurde. Sie führten auch direkt zu Stallmans Entschluss, einen kostenlosen Unix-Klon von der Pike auf zu schreiben - allein, wenn es sein musste. Im Zentrum dieser Ereignisse stand eine Maschine, die Lisp Machine genannt wurde. Die Programmiersprache Lisp (kurz für List Processing) ist heute wie Emacs außerhalb der Programmiererkreise nur wenig bekannt; wie bei Stallmans Editor genießt Lisp jedoch innerhalb dieser Gruppe einen fast mythischen Ruf, Stallman beschreibt Lisp als „leistungsstärkere und elegantere Sprache als irgendeine andere". Wenn Emacs der Editor der Hacker war, war Lisp ihre Sprache.


--------------------------------------------------------------------------------------Da Lisp für die Computerforschung im AI-Lab von so zentraler Bedeutung war, war eines der dortigen Schlüsselprojekte die Entwicklung der Lisp Machine, eines Hardwaresystems, das für LispProgramme optimiert war Indem man die Leistungsstarke von Lisp mit der Geschwindigkeit spezieller Hardware verband, konnte eine neue Generation von Computeraufgaben in Angriff genommen werden. Der Entwickler der Lisp Machine, Richard Greenblatt, der von Levy als „König aller Hacker" beschrieben wird, wollte ein neues Unternehmen gründen. Stallman erinnert sich, dass er „etwas machen wollte, was er eine Hackerfirma nannte" - also eine Firma, in der das Management die Fäden lockerer in der Hand hielt und in der in vieler Hinsicht freundlichere Gesetze herrschen sollten. „Wir dachten, dass sie keine Investoren von außen finden würden", fährt Stallman fort. „Wir waren uns nämlich sicher, dass die darauf bestehen würden, alle üblichen Vorschriften zu machen, sodass das Ganze bald ziemlich hässlich aussehen würde. Und wir dachten, dass sie die Hacker vom [AI-J Lab nur in Teilzeit einstellen würden, sodass die Hackerkultur im Lab aufrecht bleiben und die Gemeinschaft, zu der wir gehörten, nicht einfach ausgelöscht werden würde." Aber es sollte ganz anders kommen. „Die anderen Leute [im AI-Lab] sagten, sie trauten Greenblatt die Führung eines Unternehmens nicht zu", sagt Staliman. Deshalb wurde eine Firma namens Symbolics gegründet, und zwar ohne Greenblatt. Der ließ sich davon aber nicht aus dem Konzept bringen und gründete sein eigenes Unternehmen namens Lisp Machine Incorporated (LMI). Wie sich Stallman erinnert: „Symbolics hatte mehr Geld und stellte einige der besten Hacker des Lab ein. Ein Jahr später holten sie die übrigen nach, bis auf mich und Greenblatt. Die Folge war, dass meine Gemeinschaft ausgelöscht wurde." Stallman zeigt sich noch immer emotional, wenn er an diese Zeit denkt. Sein geliebtes Lab „war zu einer Geisterstadt verkommen", wie er sagt. »Es war verlassen, und ich war ganz deprimiert." Als ob es nicht genug gewesen wäre, dass seine Freunde und Kollegen das Schiff verlassen hatten, verlor er in der Folge auch noch [TS. „Zu dieser Zeit kaufte das AI-Lah einen neuen Computer", sagt er. „Und es gab keine Hacker, die ITS für diesen portiert


------------------------------------------------------------------------------------hätten." Der Grund war, dass keine Hacker mehr da waren. „Alles ging den Bach runter." Diese Wendung der Ereignisse hätte Stallman verzweifeln lassen können. Zum Glück gelang es ihm, seinen Schmerz in eine produktive Wut zu kanalisieren, die ihn in einen Kreuzzug trieb, der bis heute nicht abgeschlossen ist. Er entschied sich, auf die einzige Weise zurückzuschlagen, die ihm möglich war: durch Codieren. Als das Entwicklungsteam von Symbolics - größtenteils die ehemaligen Hacker des AI-Lab - ihre Version der Software für die Lisp Machine erweiterten, begann Stallman, dieselben Features in der Softwareversion zu reproduzieren, die vom AI-Lab verwendet wurde. „Ich ließ mich aus allen Mailinglisten streichen, weil ich durch nichts abgelenkt werden wollte. Ich wusste, dass ich mit einer viel größeren Armee konkurrieren musste und dass ich die Arbeit mehrerer Leute allein machen musste. Ich würde so konzentriert arbeiten müssen, wie ich nur irgendwie konnte", sagte er. Da LMI und Symbolics beide berechtigt waren, die Features der Software des AI-Lab für die Lisp Machine zu verwenden - und Symbolics die neuen Features bereits hatte -, versetzte Stallman LMI in die Lage, nach jeden Schritt von Symbolics gleichzuziehen. Damit verhinderte er, dass Symbolics aus seinem größeren Entwicklerteam irgendeinen Vorteil ziehen konnte. „Irgendwie war es eine sehr schöne Zeit, weil ich fast nichts anderes machte", sagt er. „Ich ging schlafen, wenn ich müde war. Sobald ich erwachte, ging es wieder ans Programmieren, und wenn ich müde wurde, ging ich eben wieder schlafen. So etwas wie einen Tagesplan hatte ich nicht. Ich schlief wahrscheinlich anderthalb Mal am Tag ein paar Stunden, und es war wundervoll." Stallman hielt seinen beispiellosen Arbeitsanfall fast zwei Jahre lang aufrecht. Aber 1983 begann sich die Situation zu ändern. Positiv war, dass „LMI immer größer wurde und nun ein paar Programmierer einstellen konnte", erinnert er sich. „So war es für mich absehbar, dass LMI bald in der Lage sein würde, diese Arbeit selbst zu machen." Negativer war, dass Symbolics eine neue Art Lisp Machine entwickelt hatte. Das bedeutete, dass es „hoffnungs-


--------------------------------------------------------------------------------------los war und auch keinen Sinn machte, die MIT-Version der Systemsoftware auf diesen Maschinen zum Laufen zu bringen/' Diese Situation nahm die neue Art, Programme zu entwickeln, vorweg. Stallman erklärt: „Ich konnte Code schreiben, aber ich konnte nicht alles selbst testen. Die Benutzer mussten die Fehler finden." Er erzählt weiter: „Als das AI-Lab in der Folge auf die [neuen] Maschinen von Symbolics umstieg, konnte ich keinen guten Code für die LMIMaschine mehr produzieren, weil ihn niemand im Lab testen konnte. Ich hätte nicht weitermachen können", sagt er. Diese Entwicklung erwies sich als ungeahnter Segen. „Ich kam zu dem Schluss, dass ich mein Leben nicht damit zubringen wollte, Symbolics zu bestrafen. Sie hatten meine Gemeinschaft zerstört. Nun wollte ich einen Ersatz für sie schaffen", sagt er. „Ich entschloss mich, ein freies Betriebssystem zu entwickeln und auf diese Weise das Fundament für eine neue Gemeinschaft wie jene zu legen, die ausgelöscht worden war." Eine weitere wichtige Überlegung dabei war, so erinnert er sich, dass das „System der Lisp Machine des MIT urheberrechtlich geschützte Software war. Sie wurde vom MIT an Symbolics und LMI lizenziert, und damit war ich nicht glücklich." Der Grund lag darin, dass das Wesen von urheberrechtlich geschützter "Software darin besteht, dass sie nicht kostenlos weitergegeben werden kann. Dadurch wurde die Bildung jener Art von Softwaregemeinschaft behindert, die Stallman nun schaffen wollte. An der Software der Lisp Machine des MIT zu arbeiten, war irgendwie der falsche Weg gewesen. Sobald Stallman sich zu diesem neuen Schritt (ein neues Betriebssystem zu entwickeln) entschlossen hatte, traf er „die wichtige Designentscheidung, dass wir uns an Unix halten würden", erzählt er. Rückblickend war das logisch, aber zum damaligen Zeitpunkt war es in keiner Weise klar. Schließlich wusste Stallman wenig über das System. „Ich hatte es nie verwendet'1, sagt er. „Ich hatte nur ein wenig darüber gelesen, aber es schien mir ein gutes, sauberes Design zu sein, in dem ein paar interessante und starke Ideen steckten."


------------------------------------------------------------------------------------Aber der Hauptanstoß für seine Entscheidung kam ein weiteres Mal aus den Erfahrungen, die er in der Zeit der Diaspora der Hackergemeinde im AI-Lab gesammelt hatte. „Digital hatte den PDP-10 (die letzte Maschine, auf der ITS gelaufen war) eingestellt. Das bedeutete, dass ITS nun auf keinem modernen Computer mehr verwendet werden konnte", sagt Stallman. „Und ich wollte nicht, dass so etwas noch einmal passierte. Die einzige Möglichkeit, das zu verhindern, bestand darin, ein portierbares System zu entwickeln." Stallman wollte ein Betriebssystem, das leicht von einer Art Hardware auf eine andere übertragen werden konnte. Da die meisten Betriebssysteme als „Haushalts"-Software für eine Art Computer konzipiert worden waren, war Portierbarkeit nicht die Regel, sondern eher die Ausnahme. „Unix war, soweit ich wusste, das einzige portierbare System, das von Benutzern verschiedener Arten von Computern verwendet wurde. Also war es nicht nur theoretisch portierbar, sondern tatsächlich", erklärt Stallman. Ein weiterer wichtiger Grund, warum Stallman Unix als sein Modell wählte, war, dass er sich „entschlossen hatte, das System mit Unix kompatibel zu machen, sodass die Leute, die bereits Programme für Unix geschrieben hatten, in der Lage sein würden, sie auf diesem System zu verwenden. Leute, die sich mit Unix auskannten, würden wissen, wie man dieses System verwendete, ohne etwas Neues lernen zu müssen." Noch einmal baute er, wie er es schon bei Emacs getan hatte, auf etwas auf, was bereits existierte, und verbesserte es Schritt für Schritt. In diesem Fall entwickelte er ein unixartiges System, das frei weitergegeben werden konnte. Obwohl die Geburtsstunde dieses Projekts für Stallman in eine sehr ungünstige Zeit fiel, zeugte der Name, den er ihm gab, doch von typischem Hackerhumor. Sein Unix-Verwandter sollte GNU heißen, ein Akronym, das für „GNU's Not Unix" stand und damit selbsterklärend war. Bei Hackern waren solche Wortspiele gängige Praxis. Der Name GNU erwies sich als fruchtbare Quelle der Inspiration für ähnliche selbsterklärende Namen, die vielen jener Programme verliehen wurden, aus denen sich das GNU-Projekt zusammensetzen sollte. Ein weiterer wichtiger Vorteil von Unix bestand darin, dass


--------------------------------------------------------------------------------------sein Design „aus einer Menge kleiner Teilchen, oft ziemlich kleiner Teilchen", bestand, wie Stallman erklärt. Um ein Unix-artiges System zu schaffen, „muss man eben jedes Stück einzeln schreiben. Also setzte ich mich hin und begann, kleine Stücke zu schreiben." Obwohl diese Erklärung den gesamten Prozess entwaffnend einfach erscheinen lässt, war das Schreiben dieser „kleinen Stücke" eine Reproduktionsarbeit, für die Hunderte Leute fünfzehn Jahre brauchten. Das war eine noch schwierigere Aufgabe, als Stallman sie vor sich hatte, als er das ganze Programmiererteam bei Symbolics ersetzen musste. In seinem Kampf gegen dieses Unternehmen konnte er sich den Quellcode ansehen, was ihm beim Schreiben seiner eigenen Versionen half. Aber bei Unix war das nicht möglich. „Ich hatte nie einen Blick auf den Quellcode von Unix geworfen", sagt Stallman. „Kein einziges Mal. Ich sah nur zufällig einmal eine Datei, und als ich erkannte, dass sie zum Quellcode von Unix gehörte, schaute ich nicht mehr hin." Der Grund lag auf der Hand: „Der Quellcode war ein Geschäftsgeheimnis, und ich wollte nicht beschuldigt werden, dieses Geschäftsgeheimnis gestohlen zu haben", sagt er. „Ich lehne Geschäftsgeheimnisse ab, ich finde, dass sie etwas Unmoralisches sind. Aber wenn ich wollte, dass das Projekt ein Erfolg würde, musste ich mich an die bestehenden Gesetze halten, auch wenn sie unmoralisch waren." Der offizielle Startschuss für das GNU-Projekt fiel im Januar 1984, als Stallman begann, an einem Ersatz für ein obskures Programmierwerkzeug namens Yacc zu arbeiten. Hiner der Gründe, warum er sich dafür entschied, bestand darin, „dass es ein ähnliches Programm namens Bison" gab - ein weiterer typischer Hackerscherz -, „das aber nicht mit Yacc kompatibel war. Ihm fehlten einige Features." Stallman holte die Erlaubnis des Autors ein, Bison mit Yacc kompatibel zu machen, und legte damit den ersten kleinen Grundstein für das GNUGebäude. Nachdem er diese relativ kleine Aufgabe bewältigt hatte, ging Stallman zu einer wichtigeren über. Eines der Schlüsselelemente eines UnixSystems ist der C Compiler, In C geschriebene Programme sind Textdateien, deren Inhalt in Instruktionszeilen besteht, die sprachlichen Regeln folgen. Bevor ein Computer den im Quellcode


------------------------------------------------------------------------------------enthaltenen Instruktionen folgen kann, muss er sie in Binärcode verwandeln - in jene Nullen und Einsen, die der Prozessorchip verstehen kann. Das ist die Aufgabe des C Compilers, einer Art Mittler zwischen Quellcode und Binärcode, der daher ein unverzichtbares Werkzeug für jeden C-Programmierer ist Als solcher war er für Stallman und seinen Vorsatz, eine neue, frei verfügbare Version von Unix zu schaffen, besonders wichtig. Ein schlechter C Compiler konnte die Chance, dass GNU ernst genommen würde, ernsthaft beeinträchtigen; ebenso konnte ein großartiger C Compiler, der frei verfügbar war, dazu führen, dass die Leute sofort aufhorchten und Notiz von dem Projekt nahmen. Noch einmal versuchte Stallman, auf einem bestehenden Programm aufzubauen, um seine Arbeitslast zu verringern. Etwas, wovon er gehört hatte, erwies sich als perfekt für diese Aufgabe. Das Amsterdam Compiler Kit war ein leistungsstarker Compiler, der auf Unix lief und nicht nur in C, sondern in den meisten anderen damals verwendeten Sprachen kompilieren konnte. Er war von dem US-Wissenschaftler Andrew Tanenbaum von der Free University of Amsterdam geschrieben worden. Von einem anderen Softwarenamen, dem Compiler Kit der Free University» vielleicht leicht verwirrt, schrieb Stallman an Tanenbaum und fragte ihn, ob er das Produkt für sein GNU-Projekt verwenden dürfe. Wie sich Stallman erinnert, schrieb [Tanenbaum] zurück: „Die Universität ist frei, aber der Compiler ist es nicht. Warum vergessen Sie diese dumme Idee eines freien Systems nicht einfach? Ich möchte ein paar Dienstprogramme, die ich mit dem Compiler verteilen kann, um den Verkauf in die Höhe zu treiben. Geben Sie mir ein paar Dienstprogramme, und ich gebe Ihnen einen Anteil des Gewinns." Was Tanenbaum vernünftig - ja sogar großzügig -erschien, war für Stallman eine Beleidigung. Schließlich war urheberrechtlich geschützte Software, wie sie der Amsterdam Compiler Kit verkörperte, für ihn genau das, was er mit seinem GNU-Projekt bekämpfen wollte. Tanenbaum weiß nicht mehr, was er genau sagte, aber er erklärte, warum er Stallman keine Genehmigung geben konnte, den Amsterdam Compiler Kit (ACK) als Teil von GNU zu verwenden.


--------------------------------------------------------------------------------------„Ich glaube, wir hatten bereits einen Vertrag über den kommerziellen Verkauf von ACK über eine US-Firma und eine europäische Firma unterzeichnet", sagt er. „Unsere Forschungsgruppe brauchte dieses Geld, um zum Beispiel Dissertanten zu unterstützen, und wenn ich mich recht erinnere, hatten wir uns bereits verpflichtet, als er an uns herantrat." Trotz dieser löblichen Argumente sah Stallman nur Tanenbaums Weigerung, ihm in seinem Kreuzzug für freie Software beizuspringen. Seine Reaktion war gleich wie bei Symbolics einige Jahre davor: Er entschloss sich, Konkurrenzsoftware zu schreiben, die dem missliebigen Code gleichwertig sein oder ihn aus dem Feld schlagen würde. Im September 1984 kehrte Stallman nach einem erfolglosen Versuch, einen weiteren Compiler zu adaptieren, zu seinem bislang erfolgreichsten Programm, Emacs, zurück. Der Code für dieses neue Emacs, das GNU Emacs genannt wurde, hatte „nichts mit dem ursprünglichen Emacs gemeinsam, das in TECO geschrieben war", erklärt Stallman. Und in einem weiteren symbolischen Akt der Rückbesinnung auf seine Wurzeln im AI-Lab entschloss er sich, den Großteil von GNU Emacs in Lisp, dieser „leistungsstarken und eleganten Sprache", die er so schätzte, neu zu schreiben. Anfang 1985 konnte GNU Emacs bereits Dateien editieren, und Stallman stellte es öffentlich zur Verfügung. Das war ein wichtiger Schritt, weil es das erste Mal war, dass die Leute GNU-Software verwenden und beurteilen konnten. Obwohl das freie GNUBetriebssystem noch praktisch inexistent war, konnten die Leute Emacs verwenden: Die Kompatibilität zu Unix, die für Stallman stets Leitstern war, bedeutete, dass GNU Emacs auf jedem Unix-System verwendet werden konnte und ihm so ein riesiges Benutzerpotenzial erschloss. „Die Leute begannen, nach Verbesserungen zu fragen, und schrieben sie. So kam es, dass ich weiterhin viel an Emacs arbeitete, viel länger, als ich gedacht hatte. Schließlich war es viel besser, als ursprünglich geplant", erinnert sich Stallman. Dieser Ansatz, den Code freizugeben und sich von den Benutzern Feedback und Änderungen zu holen, war zwar nicht neu (er war seit Jahren ein nicht wegzudenkender Teil der Unix-Kultur), aher nun wurde er


------------------------------------------------------------------------------------entscheidend für die rasante Entwicklung der freien Software. Die extreme Anwendung dieses Ansatzes bei der Entwicklung von Linux war einer der wichtigsten Faktoren für das rasante Wachstum und die Robustheit dieses Betriebssystems. Die öffentliche Bereitstellung von Emacs hatte noch eine weitere Folge: Stallman konnte das Programm auf Magnetband verkaufen, dem Standardvertriebsmedium, bevor die Disketten kamen. Diese Vertriebsmethode wählte er neben der freien Verteilung im Internet, weil zu diesem Zeitpunkt nur wenige Leute Zugang zu dem jungen Medium hatten. Der Verkauf der Bänder hatte für Stallman den zusätzlichen Vorteil, dass er ihm ein Einkommen verschaffte. „Es war so", sagt er, „dass ich meinen Job am MIT an den Nagel hängte, um mit dem GNU-Projekt zu beginnen. Ich wollte nämlich sicherstellen, dass das MIT mich nicht daran hindern konnte, die GNU-Software in der Weise frei zur Verfügung zu stellen, wie ich das tun wollte. Ich wollte das MIT nicht um Erlaubnis bitten müssen. Wer weiß, ob sie nicht irgendwie versucht hätten, mir das Ganze abzudrehen." Lobend muss erwähnt werden, dass das AI-Lab Stallman die Weiterverwendung seiner Computer erlaubte und dass er sogar zwölf Jahre lang in seinem ehemaligen Büro in 545 Tech Square schlafen durfte. Er war unter dieser Adresse sogar als Wähler eingetragen, Stallman hat noch heute eine Erinnerung an diese glücklichen Zeiten im Kopf: seine Login-ID. Bis heute lautet sie „rms", sein ursprünglicher Username für die ITS-Maschine, und der Großteil der Hackerwelt erkennt ihn an diesen Buchstaben. Obwohl Stallman behauptete, er brauche nicht viel Geld, waren die Finanzen in diesen frühen Tagen von GNU natürlich ein Problem. „Ich wusste am Anfang nicht, ob ich überhaupt Einkommensquellen haben würde", erinnert er sich, „obwohl ich im ersten Jahr von LMI für die Aktualisierung einiger Handbücher des MIT bezahlt wurde. Jedenfalls war ich fest entschlossen, die Sache durchzuziehen. Nichts hätte mich davon abbringen können/1 Zum Glück bescherte ihm der Verkauf von GNU Emacs für 150 USDollar pro Stück („Ich fand einfach, dass das ein guter Preis war") bald ein stetiges Einkommen. „Bis zur Jahresmitte hatte ich


--------------------------------------------------------------------------------------acht bis zehn Bestellungen pro Monat. Das war genug zum Leben, [obwohl] ich mir davon allein kein Geld hätte ersparen können." Da GNU Emacs nun fertig war und er sich durch das Geld, das er damit verdiente, ermutigt fühlte, wandte Stallman seine Aufmerksamkeit anderen Projekten zu, darunter dem problematischen C Compiler. Diesmal, so beschloss er, würde er nicht versuchen, ein bereits bestehendes Programm zu adaptieren, sondern würde es von der Pike auf neu schreiben. Das Projekt erwies sich als enorm komplex. „Es war das anspruchsvollste Programm, das ich je geschrieben hatte", sagt er einfach. „Ich musste Pläne dafür erstellen. Es reichte nicht mehr aus, dass ich einfach Code auf ein Stück Papier kritzelte." Normalerweise codiert Stallman ganz anders. „Am Anfang habe ich eine vage Vorstellung im Kopf, sagt er, „und ich beginne einfach an irgendeinem Punkt zu schreiben. Sobald ein Teil fertig ist, kann ich mir benachbarte Teile vorstellen und sie niederschreiben. Dann mache ich immer so weiter und habe schließlich das ganze Ding vor mir." Das erklärt wahrscheinlich zum Teil, warum Unix als Modell für sein GNUProjekt so attraktiv war: Stallman konnte irgendwo ansetzen und eine Utility hier, ein Programm dort schreiben, bis er schließlich „das ganze Ding" vor sich hatte. Stallman nannte seinen Compiler GCC - für GNU C Compiler. Dieser Compiler machte das GNU-Projekt noch bekannter als GNU Emacs, denn GCC erwies sich als eine Software der Spitzenklasse. „Ein paar Jahre lang war GCC für die meisten von ihm unterstützten Systeme praktisch der beste Compiler", erinnert sich Stallman. „Aber das war nicht sofort so, denn GCC musste eine Zeit lang optimiert werden, bevor es seine endgültige Klasse erreichte." Wie bei Emacs wurde dieser Prozess enorm durch die Kommentare der Benutzer unterstützt, sobald das Programm veröffentlicht war. Das neue GCC trieb Stallmans Einkommen weiter in die Höhe. Auftragsarbeiten kamen in Hülle und Fülle. „Die Leute gaben viel mehr Änderungen von GCC in Auftrag und forderten viel mehr Einschulungen an, als sie es bei Emacs getan hatten", erklärt Stallman. „Ich war über diese Einkommensquellen sehr froh, besonders als die Free Software Foundation gegründet wurde. Ich glaube, es war im Oktober 1985. Sie übernahm den Verkauf der


------------------------------------------------------------------------------------Emacs-Bänder von mir, sodass diese Einnahmen für mich ausfielen." Die Free Software Foundation (FSF) war für GNU ein wichtiger Schritt vorwärts. „Als ich sie gründete, hatte sie kein Geld, um Leute einzustellen. Dann war das Geld für eine Person da, und eine Person wurde eingestellt", erzählt er. „So konnten wir mehr Arbeit gleichzeitig erledigen, weil noch jede Menge Programme fehlten." Diese Programme wurden nach und nach geschrieben, entweder von Stallman selbst oder von der wachsenden Zahl von FSF-Mitarbeitera und Freiwilligen. „In den frühen Jahren [gab es] nur zwei oder drei Leute, die halfen", erinnert er sich. „In der zweiten Hälfte der achtziger Jahre waren es dann, glaube ich, irgendwo zwischen dreißig und fünfzig," Zwei der anderen großen Projekte bestanden in der Entwicklung eines Shell-Programms und einer C-Bibliothek. Eine Shell ist die Basisschnittstelle zum Betriebssystem. „Wenn man Befehle eingeben will, braucht man eine Shell", sagt Stallman. Das GNU-Programm hieß Bash, kurz für Bourne Again Shell, eine Anspielung auf die Unix Shell, die Bourne Shell hieß. Die C-Bibliothek ist ein Stück Hilfscode, das andere Programme aufrufen können. Indem auf diese Weise eine Gruppe häufig verwendeter Funktionen abgetrennt wird, können die Benutzerprogramme viel kleiner gehalten werden. Die Erstellung einer C-Bibliothek für GNU war daher eine wichtige Vorbedingung, bevor das GNUBetriebssystem solche Benutzerprogramme abarbeiten und nützlich sein konnte. Die C-Bibliothek und Bash wurden gemeinsam mit vielen anderen Elementen des Unix-Betriebssystems um 1990 fertig gestellt. Was immer noch fehlte, war allerdings das in vielerlei Hinsicht wichtigste Programm: der Kernel. Wie der Name schon sagt, sitzt der Kernel im Zentrum des Betriebssystems. Seine Funktion ist die eines „Haushälters" (der für Dinge wie Bildschirm und Tastatur verantwortlich ist) und eines „Richters" (der sicherstellt, dass alle konkurrierenden Rufe der Benutzerprogramme nach Aufmerksamkeit „gerecht" behandelt werden). Obwohl viele andere Programme für ein voll funktionierendes Betriebssystem unabding-


--------------------------------------------------------------------------------------bar sind - wie zum Beispiel eine C-Bibliothek und eine Shell -, ist es der Kernel, der sein Wesen bestimmt. Die Tatsache, dass Stallman sich den Kernel bis zuletzt aufgehoben hatte, mag angesichts seiner zentralen Natur eigenartig erscheinen. Der Grund für die Zurückhaltung lag zum Teil darin, dass er durch seine Fehde mit Tanenbaum und seinen Schwur, dass ein C Compiler eines der ersten Programme sein würde, die er für sein GNU-System schrieb, abgelenkt wurde. Darüber hinaus machte es Sinn, alle Programmiertools zuerst zu entwickeln, damit sie dann für die Entwicklung des Kernels verwendet werden konnten. Es gab jedoch noch einen anderen Grund. „Ich versuchte, die schwerste Aufgabe von allen zu umgehen", sagt Stallman. Die Entfernung von Bugs aus einem Kernel ist schwierig, weil die Standardprogrammiertools von einem funktionierenden Kernel abhängig sind. Um diese Klippe zu umschiffen, hielt Stallman einmal mehr nach einer geeigneten Software Ausschau, die adaptiert werden konnte, und er hatte etwas Bestimmtes im Sinn: „Ich suchte einen Mikrokernel", sagt er. Ein Mikrokernel ist ein Kernel, der die Idee einer kleinen, zentralen, anpassungsfähigen Softwareeinheit zu ihrer logischen Vollendung fuhrt; er macht alle anderen Haushaltungsaufgaben, die in einem Kernel normalerweise vorkommen, zu Programmen, die genau wie Endbenutzerapplikationen wie Textverarbeitungs- oder Tabellenkalkulationsprogramme kontrolliert werden. Die Vor-und Nachteile dieses Ansatzes, verglichen mit dem klassischen Alles-ineinem-Kernel, auch monolithischer Kernel genannt, bilden den Gegenstand eines „religiösen Krieges", der bis zum heutigen Tag wütet. Stallman interessierte sich nicht aus doktrinären Gründen für den Mikrokernel, sondern weil „wir auf diese Weise das Debuggen jenes Teils der Software vermeiden konnten, der auf der nackten Maschine läuft" - der zugrunde liegenden Hardware. Wie gewohnt versuchte er vernünftigerweise, Zeit und Mühe zu sparen, indem er bestehenden Code heranzog und darauf aufbaute. Stallman hatte Glück - oder das dachte er zu diesem Zeitpunkt jedenfalls. „Endlich hatten wir einen Mikrokernel gefunden, von dem wir zumindest glaubten, dass er bereits entwickelt war und


------------------------------------------------------------------------------------funktionierte“, sagt er. „So brauchten wir nur noch die Benutzerprogramme zu schreiben, die die Arbeit machen ... die normalerweise von Teilen des Kernels erledigt wird", um das fehlende Herz des GNUBetriebssystems zu schaffen, das als GNU Hurd bekannt wurde. Leider war der Mikrokernel, den er gefunden hatte, entgegen seiner Annahme noch nicht besonders zuverlässig. Dazu kam, dass sich das Debuggen dieses Codes als viel schwieriger erwies als erwartet. „Es zeigte sich, dass das Debuggen schwierig war", erklärt er. „Genau genommen war das Problem an der Sache, dass es sich um ein Forschungsprojekt handelte. Ich versuchte im Allgemeinen, Forschungsprojekte zu vermeiden, [und] setzte stattdessen auf bewährte Designs. Ein Forschungsprojekt ist schließlich etwas Riskantes. Es kann passieren, dass man etwas ausprobiert und feststellen muss, dass es nicht besonders gut funktioniert. Wie auch immer: Wir probierten dieses Design aus und stellten fest, dass es schwer fertig zu stellen war/ Er fährt fort: „Rückblickend erscheint es mir, dass die Entwicklung eines monolithischen Kernels viel schneller und einfacher gewesen wäre. Wahrscheinlich wäre das das Richtige gewesen." Die erste funktionierende Version von Hurd wurde erst 1996 veröffentlicht. Aber Stallman sieht die Sache philosophisch: „Wissen Sie", meint er, jedes individuelle Softwareprojekt ist nur ein Teil des GNU-Projekts. Das GNU-Projekt bedeutet im Grunde nicht, dass dieses oder jenes Stück Software entwickelt wird. GNU ist wie jedes Betriebssystem eine Ansammlung vieler Programme. Einige davon schrieben wir selbst und andere beschafften wir von anderswo. Am Ende erreichten wir das allgemeine Ziel: ein vollkommen freies System." Als Stallman mit dem Schreiben der Komponenten seines GNUBetriebssystems begann und sie veröffentlichte, wollte er vor allem sicherstellen, dass die Programme, die er und seine Kollegen schufen, frei und offen blieben, wenn sie von Benutzer zu Benutzer weitergegeben wurden. Es war nicht damit getan, sie einfach zu veröffentlichen, weil jederzeit jemand kommen und die GNUProgramme als seine eigene geschützte und somit auch „verschlossene" Software hätte kaufen können. Stallman musste etwas Neues


--------------------------------------------------------------------------------------und Radikales tun: Er musste eine Softwarelizenz entwickeln, welche die Benutzerrechte nicht einschränkte, wie es die meisten anderen Lizenzen taten, sondern sie schützte. Die erste Form dieser Lizenz war die GNU Emacs General Public Licence im Jahr 1985, „Ich erstellte sie gemeinsam mit einem Rechtsanwalt", erzählt er. Er musste sicherstellen, dass die Freiheiten, die er auf lange Sicht schützen wollte, aus rechtlicher Sicht wasserdicht waren. Unter diesem neuen „Copyleft" (im Gegensatz zu Copyright) konnten die Benutzer das Original kopieren, modifizieren und es oder die modifizierten Versionen verkaufen. Was sie jedoch nicht konnten, war die Rechte modifizieren, die das Copyleft jedem Benutzer erteilte; so musste zum Beispiel Software, die auf dem von ihnen verkauften Programm basierte, ebenfalls frei zur Verfügung gestellt werden. In ähnlicher Weise mussten Modifikationen, die sie an copyleftgeschützten Programmen vornahmen, ebenfalls durch Copyleft geschützt und damit frei zur Verfügung gestellt werden. Wenn darüber hinaus Software, die unter der GNU General Public Licence (GPL) veröffentlicht wurde, mit urheberrechtlich geschütztem (nicht freiem) Code kombiniert wurde, so musste die resultierende Kombination unter der GPL veröffentlicht werden. Anders ausgedrückt: Die GNU GPL „konvertierte" die Software, mit der sie verwendet wurde, in ihre eigene Lizenz. Dieser ersten GNU Emacs General Public Licence [GPL) folgte später eine GCC GPL und eine ähnliche Lizenz für mehrere andere GNUProgramme. Aber Stallman wurde bald klar, dass dieser Stückwerkansatz nicht nur unelegant (eine Kardinalsünde unter Hackern) war, sondern auch unzweckmäßig, weil er bestimmte Dinge blockierte. So „konnte man zum Beispiel nicht Code aus einem [unter einer GPL-Lizenz veröffentlichten Programm] nehmen und ihn in ein anderes einfügen“, erklärt Stallman. „Deshalb fand ich, es wäre besser, eine allgemeine Lizenz zu haben, die für alles verwendet werden konnte." Das war die GNU General Public Licence. Stallman nannte sie die „Subroutinenlizenz", weil „man sie praktisch in jedes Programm hineinwerfen konnte, und sie galt". Stallmans Absicht beabsichtigte mit GNU GPL, die neuen Bibliotheken zu schützen, die seine GNU-Software beinhaltete. Aber die GNU GPL hatte noch eine andere Folge, die sich als


------------------------------------------------------------------------------------entscheidend für den Erfolg späterer freier Softwareprojekte wie Linux erweisen würde. Die Freiheit, ein GNU-GPL-Programm modifizieren zu können bedeutet, dass der Quellcode für Copyleft-Software verfügbar sein muss: Wenn nur der Binärcode - die Abfolge von Nullen und Einsen bereitgestellt wird, ist die Modifikation des Programms sehr umständlich und verletzt daher die Lizenz. Die GNU GPL stellt unter anderem sicher, dass der Quellcode eines Programms immer verfügbar ist. Das ist entscheidend, wenn Außenstehende das Programm modifizieren und verbessern sollen. Darüber hinaus sorgt die GNU GPL auch dafür, dass solche Verbesserungen gemeinsam mit ihrem Quellcode frei verfügbar gemacht werden, sodass die ganze Gemeinde von den gemeinsamen Fortschritten aller Benutzer profitieren kann. Außerdem wird auf diese Weise die Duplikation von Arbeit vermieden. Sobald ein Programm, das eine bestimmte Funktion ausführt, unter einem Copyleft herausgebracht wird, können andere, die ähnliche Software schreiben wollen, selbstverständlich auf dieser Arbeit aufbauen. Man braucht das Rad nicht jedes Mal, wenn eine bestimmte Art Software geschrieben wird, ein zweites Mal zu erfinden, wie es bei kommerzieller Software der Fall ist. Stallman schuf mit der GNU GPL eine Art schriftliche Verfassung für die Hackerwelt, die grundlegend regelt, wie ihre Gemeinde funktionieren soll. Dabei ebnete er den Weg zu viel effizienteren Fortschritten, als sie in der Vergangenheit möglich gewesen waren, als diese „Gesetze" noch ungeschrieben waren. Je stärker sich die GNU GPL verbreitete, desto größer wurde ihre Wirkungskraft. Mehr Copyleft-Programme bedeuten schließlich, dass der Pool solcher Programme» aus dem in Zukunft geschöpft werden kann, ständig wächst. Das erleichtert die Entwicklung neuer Programme, und der Pool der GPL-Software wächst noch schneller, Diese enorme Effizienz war einer der Hauptmotoren, der dafür sorgte, dass die freien Softwareprojekte in den neunziger Jahren so außerordentlich erfolgreich waren. Allein dafür und für die Entwicklung des GNU-Systems schuldet die Computergemeinde Stallman immensen Dank.


--------------------------------------------------------------------------------------Aber für Stallman geht diese Betonung der Effizienz am Sinn des GNUProjekts und am Sinn der GNU GPL vorbei. Sein wichtigstes Anliegen ist die Freiheit, und er betrachtet das GNU-Projekt dabei nicht als Selbstzweck, sondern als ein Mittel zum Zweck. Er sagt: „Eigentlich geht es darum, den Benutzern Freiheit zu geben, indem ihnen freie Software zur Verfügung gestellt wird und die Grenzen dessen, was man mit freier Software tun kann, möglichst stark zu dehnen. Schließlich besteht die Idee von GNU darin, den Leuten die Arbeit mit ihren Computern zu ermöglichen, ohne dass sie die Vorherrschaft von jemand anderem anerkennen müssen. Ohne dass irgendein Softwareeigentümer sagen kann: Ich lasse nicht zu, dass Sie verstehen, wie das funktioniert. Ich werde dafür sorgen, dass Sie hilflos und von mir abhängig bleiben. Und wenn Sie die Software an Ihre Freunde weitergeben, werde ich Sie einen Piraten nennen und Sie ins Gefängnis stecken lassen." „Ich halte das für unmoralisch", fährt Stallman fort, „und ich arbeite daran, ein solches Verhalten unmöglich zu machen, weil ich finde, dass niemand so vorgehen sollte. Die einzige Möglichkeit, dieses Ziel zu erreichen, besteht darin, viel Software zu schreiben und den Leuten zuzurufen: ,Kommt und verwendet sie, gebt sie an eure Freunde weiter, ändert sie und tut mit ihr, was immer ihr wollt. Kommt zu uns, habt Spaß: Genau dafür ist GNU gedacht - den Leuten die Alternative zu geben, in Freiheit zu leben." Stallman hat diesem Ziel nicht nur viel seiner Zeit und Energie gewidmet, sondern er hat auch Geld hineingesteckt. 1990 wurde er zum Fellow der McArthur Foundation ernannt. Dafür erhielt er etwa 230.000 US-Dollar, ausbezahlt über fünf Jahre hinweg in vierteljährlichen Raten. „Das war viel mehr Geld, als ich zum Leben brauchte, und mehr Einkommen, als ich je in meinem Leben gehabt hatte. Anstatt es auszugeben, beschloss ich, das meiste davon in Investmentfonds zu stecken, damit ich den Rest meines Lebens davon leben und mich der freien Software oder einer anderen guten Sache widmen kann." Er hat kein Auto: „Ich lebe in einer Stadt, in der man kein Auto braucht." Eine Wohnung? Ein gemietetes Zimmer. Stallman war nie verheiratet und hat keine Kinder. „Das kostet viel Geld. Für mich würde es nur eine Möglichkeit geben, dieses Geld zu verdienen: das


------------------------------------------------------------------------------------zu tun, wofür ich mich schämen würde - kommerzielle Software zu schreiben", sagt er. Mit seiner starren Weigerung, Kompromisse zu schließen, stößt Stallman mitunter selbst Unterstützer vor den Kopf. „Der einzige Grund, warum wir ein vollkommen freies Betriebssystem haben, ist die Bewegung, die sagte, wir wollen ein Betriebssystem, das vollkommen frei ist und nicht zu 90 Prozent frei", sagt er. „Wenn man die Freiheit nicht zum Prinzip erhebt, wird man immer wieder einen Grund für eine Ausnahme finden“ Er gibt zu, dass er es manchmal müde ist, diese Botschaft immer wieder zu predigen, aber er ist davon überzeugt, es tun zu müssen - auch dann, wenn er damit die Toleranz seines Publikums überfordert. Wann wird sein Werk vollendet sein? „Nun, vielleicht nie", räumt er ein. „Kann die Freiheit je für alle Zukunft gesichert sein? Die Leute werden sich immer bemühen müssen, die Gesellschaft frei zu halten." Das eigentlich Wichtige an GNU's Not Unix und an Ideen wie „Copyleft" ist, dass Stallman sich damit nicht nur für die Freiheit von Software einsetzt. Er sagt: „Es geht um viel allgemeinere Fragen der Freiheit - Fragen, die jeder kennt und die von viel größerer Bedeutung sind als diese hier: Redefreiheit, Pressefreiheit, Versammlungsfreiheit." Stallmans Arbeit ist nicht nur deshalb von Bedeutung, weil sie viele der Schlüsselelemente enthält, die für den Erfolg des späteren Betriebssystems GNU/Linux ausschlaggebend waren, sondern weil sie auch den ethischen Hintergrund bildet, vor dem sich die gesamte Geschichte von Open Source und freier Software entfaltet. Stallman sollte nicht nur als größter Hacker aller Zeiten gelten -das ist er sicher. Das Beispiel, das er uns mit seinem Bekenntnis zu hehren Zielen gibt, mag manchen zu idealistisch erscheinen, aber es bildet die Richtgröße, an der die Integrität seiner Programmiererkollegen, der großen und der weniger großen, gemessen werden kann.

3

Ein kleiner Aufstand

ALS LINUS IM HERBST 1991 UNIX entdeckte, stand das große GNU-Projekt, das Stallman einige Jahre davor begonnen hatte, vor seiner Vollendung. Nur ein entscheidendes Element fehlte noch -der Kernel. Er wurde gerade in Form des GNU Hurd entwickelt und bildete das Herz von Stallmans Betriebssystem. Für Stallman war diese Verzögerung bedauerlich, aber nicht gravierend. Wichtiger war es, dass die meisten Elemente seines freien Unix-artigen Systems nun verfügbar waren und dass das fehlende Puzzleteilchen ebenfalls bald nachgereicht werden würde. Das war ein schwacher Trost für Linus, der seine eigene Kopie von Unix sofort verwenden wollte und nicht erst in ein paar Jahren, wenn GNU Hurd fertig war. Je mehr er und Lars Wirzenius über Unix erfuhren, desto faszinierter waren sie. Wirzenius erinnert sich an die Begeisterung, mit der er und Linus diese neue Welt erforschten: „Wir brachten einige Abende


------------------------------------------------------------------------------------damit zu, über die Übungen für den Kurs dieses Herbstsemesters zu sprechen, und wir unterhielten uns mit kleinen Wettbewerben, wie zum Beispiel, wie man eine bestimmte Aufgabe auf die eleganteste und vielleicht auch auf die kürzeste Weise lösen konnte" -klassische Programmiererspielchen. Aber ihre eigene wachsende Frustration, sich für Unix anstellen zu müssen (der einzige Computer, der mit Unix lief, unterstützte immer nur sechzehn User), führte dazu, dass sie Verzweiflungstaten ins Auge fassten, „Eines der Dinge, über die wir sprachen, [war, dass] wir Unix von der Pike auf selbst neu schreiben müssten, weil die kommerzielle Version furchtbar teuer war", erzählt Wirzenius, fügt aber hinzu: „Das war ein Scherz, vor allem von meiner Seite. Ich bin als Programmierer nicht so gut wie Linus. Es ist nichts, was man einfach so entscheidet: ´Diese Woche schreibe ich ein Betriebssystem'." Aber es zeigte sich, dass der Scherz näher an der Wahrheit lag, als irgendjemand sich hätte vorstellen können. Zum Glück machten Linus' Studien in diesem Herbst ihm nicht nur den Mund nach Unix wässrig, sondern sie eröffneten ihm auch eine Möglichkeit, das Betriebssystem zu erwerben. Er erinnert sich: „Eines unserer Lehrbücher hieß: Operating Systems: Design and Implementation“ Das Buch war eine Novität: Es wurde mit illustrierender Software geliefert. Diese Software namens Minix war geschrieben worden, um den Studenten zu zeigen, wie ein Betriebssystem arbeitete. Zu diesem Zweck wurde der Quellcode analysiert. Linus stellte fest, dass Minix im Wesentlichen ein Unixartiges System war, das auf einem PC lief. Er konnte damals nicht wissen, dass es ihm nicht nur das Gerüst für die Entwicklung seines eigenen Unix-Kernels auf PC-Basis, Linux, liefern würde, sondern dass es auch ein Vorbote vieler kommender Techniken und Entwicklungen war. Minix war von demselben Andrew Tanenbaum geschrieben worden, der 1984 die Avancen von Richard Stallman, der nach einem Compiler suchte, zurückgewiesen hatte, und der Stallman dazu getrieben hatte, GCC zu entwickeln. Trotz dieses Starts mit Hindernissen erzählt Tanenbaum, Stallman hätte ihm später vorgeschlagen, dass Minix den fehlenden Kernel des ansonsten vollständigen GNU-Systems bilden könne. „Er trat mehrere Male an mich

3. Ein kleiner Aufstand

--------------------------------------------------------------------------------------heran", sagt Tanenbaum, „und wir durchliefen alle Stadien. Es muss so sein, nein, es muss anders sein. Ich fand ihn irgendwie anstrengend“ Stallman sagt, er könne sich nicht erinnern, räumt aber ein, dass die Gespräche stattgefunden haben könnten. Hätte Tanenbaum Ja zu Stallmans Vorschlag gesagt, wäre die Geschichte des Computing ganz anders verlaufen. Linus betonte später: „Wenn der GNU-Kemel fertig gewesen wäre" - zum Beispiel, als er nach seiner eigenen Unix-Kopie suchte, durch eine Form von Minix -, „hätte ich mich nicht darauf eingelassen, das [Linux-]Projekt auch nur zu beginnen." Aber Tanenbaum sagte Nein, und anstatt Linux im Keim zu ersticken, trug Minix stark dazu bei, es zum Blühen zu bringen. Nach seinen Studien am MIT im ersten und an der University of California in Berkeley im zweiten Studienabschnitt war Tanenbaum 1971 an das Institut für Computerwissenschaften der Freien Universität Amsterdam gegangen. Dort wurde er 1980 Professor. 1979, zehn Jahre nachdem Unix entstanden war, brachte AT&T die Version 7 des Systems heraus. Diese Version war aus mehreren Gründen etwas Besonderes; zum Beispiel war es das erste Unix, das an einen Intel-Prozessor, den 8086, portiert (übersetzt für die Verwendung darauf) war. Dieser Prozessor war eine etwas leistungsfähigere Version des 8088-Chip, der später im ersten IBM-PC verwendet werden sollte. Xenix, wie das Betriebssystem genannt wurde, war das gemeinsame Produkt zweier Unternehmen. Eines war The Santa Cruz Operation, heute besser bekannt als SCO (späterer Eigentümer von Unix), das andere war Microsoft. Heute weiß man kaum mehr, dass Microsoft ein Jahr bevor es 1981 MS-DOS herausbrachte, bereits eine PC-Version von Unix auf den Markt gebracht hatte. Aber die Existenz von Xenix, das nie zu einem populären Produkt wurde, macht die aktuelle Herausforderung von Systemen, die auf Linux basieren, zumindest pikant. Es war eine andere wichtige Änderung gegenüber Version 6, von der Tanenbaum stärker betroffen war: „In der Lizenz stand ziemlich ausdrücklich, [dass] der Quellcode den Studenten nicht zur Verfügung gestellt werden sollte", erinnert sich Tanenbaum. «Punkt. Nichts. Gar nichts. Null“ Version 7 repräsentierte den


------------------------------------------------------------------------------------symbolischen Verschluss von Unix in der schwarzen Kiste der urheberrechtlich geschützten Software - ein trauriges Ende eines Systems, das lange Zeit das Eldorado der studentischen Hacker gewesen war. Aus studentischer Sicht war der Bannfluch, mit dem die Diskussionen über den Quellcode von Unix nun belegt waren, alles andere als befriedigend. „Zwischen 1979 und 1984 hörte ich vollkommen auf, die praktische Anwendung von Unix zu unterrichten, und wandte mich wieder der Theorie zu", sagt Tanenbaum. Er hatte erkannt, dass es nur eine Möglichkeit gab, seinen Studenten etwas Vergleichbares zur Verfügung zu stellen: „Selbst ein Betriebssystem zu schreiben, das systemkompatibel zu Unix war" - das heißt, ein System, das genau auf dieselbe Weise arbeitete. „Dazu schrieb ich aber meinen eigenen Code. Ich verwendete überhaupt keinen Code von AT&T." Als Tanenbaum 1984 begann, Minix zu schreiben - das Jahr, in dem Stallman mit GNU begann -, beschloss er, ein zu Unix kompatibles System zu schreiben, und: „Wenn ich schon dabei war, wollte ich es ordentlich machen." Das war ein interessanter Gegensatz zu Stallmans Ansatz, den hauptsächlich die freie Verfügbarkeit seines Produkts interessierte und nicht so sehr die Schreibweise. Tanenbaums Vorsatz, es „ordentlich zu machen“ bedeutete in diesem Kontext, einen Mikrokernel zu verwenden. Dabei hatte er sich, wie er schnell anmerkt, „schon lang entschieden» einen Mikrokernel zu entwickeln, bevor noch irgendjemand von Mikrokernels gehört hatte. Eigentlich denke ich, dass Minix der allererste Mikrokernel war." Die Folge war, dass der grundlegende Kernel sehr, sehr einfach war. Das bedeutete aber nicht, dass es leicht gewesen wäre, Minix fertig zu stellen. „Es dauerte Abertausende von Stunden. Leicht war es wirklich nicht", erklärt Tanenbaum. Er schrieb Minix an den Abenden zu Hause. Ein neues Betriebssystem zu schreiben ist eine langwierige und komplexe Aufgabe. Das war einer der Gründe, warum Stallman sich auf die Suche nach einem bestehenden Mikrokernelsystem begab, das er verwenden konnte. Tanenbaum erinnert sich, dass das „Debuggen eines Kernels auf instabiler Hardware, mit der man


--------------------------------------------------------------------------------------nicht wirklich gut vertraut ist, schrecklich ist. Ich hätte das Projekt ein paar Mal fast aufgegeben. Es gab da Fehler, die ich einfach nicht finden konnte." Das Problem lag zum Teil darin, dass die Hardware, mit der er arbeitete, undokumentierte Features und eigenartige Bugs hatte, die von der Temperatur irgendwelcher Chips abhingen. Tanenbaum hätte das Ganze mit Sicherheit an den Nagel gehängt, wäre das Problem nicht durch eine zufällige Bemerkung eines seiner Studenten geklärt worden. Schließlich, 1986, nach zwei Jahren harter Arbeit, hatte er ein System entwickelt, das von anderen verwendet werden konnte. „Ich stellte eine Mitteilung ins Netz, in der ich sagte, was ich machte. Daraufhin meldeten sich ein paar Leute, die mir halfen." Als Tanenbaum eine neue Usenet-Newsgroup für die Software einrichtete, die mit dem Buch verteilt wurde, das er zur Erklärung seines Systems für die Studenten geschrieben hatte, kam die Sache in Gang. „Das Buch und die Software kamen gemeinsam heraus. Das war 1987'\ erinnert sich Tanenbaum. „Die Newsgroup, die eben erst eingerichtet worden war, spielte bald verrückt. Innerhalb eines Monats hatte sie 40.000 Mitglieder. Die Begeisterung war der Begeisterung für Linux heute ähnlich." Was als persönliches Projekt begonnen hatte, das den Studenten laut Tanenbaum „durch ein einfaches und direktes Beispiel zeigen sollte, wie ein Betriebssystem funktioniert", hatte in der Computergemeinde etwas viel Größeres und noch nie Dagewesenes ins Rollen gebracht. Von Anfang an erhielt Tanenbaum „in der Newsgroup täglich zweihundert Nachrichten. Außerdem kamen täglich zweihundert EMails, in denen nach dem Motto ,ich will dieses, ich will jenes‘ Anpassungen aller Art verlangt wurden." Tanenbaum weigerte sich, den Wünschen nachzukommen. „Ich hatte Angst, dass der Systemcode immer komplizierter und immer umfangreicher werden würde", sagt er. „Dann würde das System nicht mehr auf der minimalen Hardware laufen, die ich für die Studenten wollte, und es würde schwer erklärbar werden. Ich wollte ans Ende [des beiliegenden Buches] keinen 10.000 Seiten-Anhang einfügen müssen."


------------------------------------------------------------------------------------Trotzdem nahm Tanenbaum einige Veränderungen vor. Die grundlegenden Kriterien waren: „Wenn alle danach schrien, wenn es relativ einfach zu machen war und die Struktur des Systems nicht besonders störte, dann machte ich es", erklärt er. „Wenn es nicht allzu viel Nachfrage gab oder wenn es wirklich haarig gewesen wäre und außerdem das System verändert hätte, dann machte ich es nicht." Die Folge war, dass Minix sich entwickelte, wenn auch langsamer als viele seiner Benutzer wollten. „Es gab jede Menge neue Versionen", sagt Tanenbaum. „Es gab keinen Kalender in dem Sinn, dass alle sechs Monate eine neue herauskommen musste. Es häufte sich einfach neues Zeug an, und irgendwann einmal sagte ich: ,So, jetzt reicht es aber, jetzt muss eine neue Version her. Sie ist stabil und ist von einer Menge Leute im Netz getestet worden. Sie funktioniert: Das war der richtige Zeitpunkt, um eine neue Version auf Diskette herauszubringen." Minix wurde auch an andere Chips als an den 8088 des ursprünglichen PC portiert, darunter auch an den Intel 80386 Prozessor. Die Einführung des 80386-Chip und der schrittweise Preisverfall der Systeme, die ihn verwendeten, erwiesen sich als wichtig für Linus. „Der 386er war viel besser als alle vorhergehenden Chips", erinnerte er sich später. „Darüber hinaus", so Linus, „wusste ich aus Tanenbaums Buch, dass man Unix für einen PC bekommen konnte. An diesem Punkt fügte ich mich endlich ins Unvermeidliche und schaffte mir einen PC an" etwas, was er davor auf keinen Fall wollte. Die Finanzierungsart des finnischen Universitätssystems erwies sich als Glücksfall für Linus. Wie Wirzenius sagt: „Die finnische Regierung gibt den Studenten Geld und besichert auch die Studentenkredite, die die Studenten von den Banken erhalten. Das Geld soll für Unterkunft und Verpflegung verwendet werden, aber auch für Studienunterlagen. Linus gelang es, einen Studentenkredit zu bekommen, den er für den Kauf des Computers verwenden konnte. Schließlich lebte er bei seiner Mutter und hatte nicht so hohe Lebenshaltungskosten." Im November 1992 waren die Schulden abbezahlt.


--------------------------------------------------------------------------------------Linus investierte noch weitere vor kurzem erworbene Mittel „Ich hatte Weihnachtsgeld bekommen", sagt er. „Ich weiß noch, dass ich am ersten Geschäftstag nach Neujahr ins Geschäft stürzte, um einen PC zu kaufen." Das war am 5. Januar 1991. 1996 erinnerte er sich immer noch an die Daten der Maschine: „386, DX33, 4 MB RAM, kein Koprozessor, 40 MB Harddisk." Das ist an heutigen Standards gemessen mehr als karg, aber abgesehen von Festplatte, von der Linus einräumte, dass sie „nicht sehr groß" gewesen sei, waren diese Spezifikationen für die damalige Zeit durchaus respektabel - vor allem für die Verwendung von Minix. In seinem ersten veröffentlichten Interview mit Linux News, das von Wirzenius initiiert worden war und ab Herbst 1992 sechs Monate lang erschien, erzählt Linus, was als Nächstes passierte. „Ich hatte meine Maschine zwar am 5. Januar 1991 bekommen, war aber gezwungen, sie einige Monate lang mit DOS zu betreiben, weil ich noch keine MinixDisketten hatte.“ Er vertrieb sich die Zeit auf eine ungewöhnliche Weise: „Januar und Februar verbrachte ich zu siebzig Prozent mit dem Computerspiel ,Prince of Persia' und zu dreißig Prozent damit, mich mit der Maschine vertraut zu machen." Wirzenius erzählt, dass Linus in dieser Zeit „begann, mit Programmiertools für MS-DOS auf einem PC herumzuspielen. Irgendwann einmal hatte er einen Assemhler, mit dem er Assemblerprogramme schrieb", was er schon auf dem VC-20 seines Großvaters getan hatte. Die Vorteile des Programmierens in Assemblersprache bestanden in schnelleren Programmen und in der direkten Kontrolle der Hardware. Zweifellos war die Möglichkeit, den 386er-Chip auf diese Weise zu erforschen, der Hauptgrund» warum Linus sie verwendete. Wirzenius erinnert sich an diese ersten Assemblerprogramme in DOS. „Ich weiß noch, dass er sehr stolz auf ein kurzes Stück Code mit einer Subroutine war, die nichts anderes tat, als die Länge einer Zeichenfolge zu berechnen. Stolz war er nicht darauf, dass er eine so komplizierte Aufgabe bewältigt hatte, sondern darauf, dass er alles selbst geschrieben hatte.“ Wie Wirzenius in einer Rede sagte, die er 1998 bei der Linux Expo hielt: „Wenn Linus sich entschließt, etwas zu lernen, dann lernt er es auch, und zwar schnell." Dass diese ersten Schritte klein


------------------------------------------------------------------------------------waren, bedeutete nicht, dass sie es auch blieben. Schon sein nächstes Assemblerprogramm war viel ausgefeilter als die erste Subroutine und untersuchte eines der Schlüsselmerkmale des 386er-Chips: das Task Switching. Die Fähigkeit des Intel-Chips 80386, zwischen Aufgaben hinund herzuwechseln bedeutete, dass er mehr als eine Aufgabe oder einen Benutzer auf einmal verkraftete (indem er schnell zwischen beiden hinund hersprang). Task Switching war das Kernstück von Multitasking, das wiederum eine der wichtigsten Fähigkeiten von Unix war. Linus wusste damals möglicherweise nicht, dass sich seine Experimente fast unmerklich in Richtung der Entwicklung des Kernels eines unixartigen Systems bewegten. Linus beschreibt seine ersten Experimente in diese Richtung auf dem 386 so: „Ich testete die Task-Switching-Fähigkeiten. Also entwickelte ich einfach zwei Prozesse, ließ sie auf den Bildschirm schreiben und hatte einen Timer, der zwischen den Aufgaben hin und her wechselte. Ein Prozess schrieb ,A' der andere ,B'. Also sah ich ,AAAABBBB' und so weiter." Später schrieb Linus über diesen Task Switcher: „Gott, war ich stolz auf ihn!" Aber das war trotzdem noch kaum der Kernel eines Betriebssystems zu nennen, geschweige denn der Kernel eines Unixkompatiblen Betriebssystems. Linus näherte sich diesem Ziel jedoch an - zumindest im möglichen Maß. Den endgültigen Sprung tat er, als Minix auf der Bildfläche erschienen. Dieser historische Augenblick ist in seinem ersten Posting an die Newsgroup comp.os.minix festgehalten, das in die Zeit der Einführung von Minix fiel. Linus hatte diese Newsgroup zweifellos bereits einige Zeit verfolgt - „Ich verfolgte damals viele Newsgroups", aber erst am Freitag, den 29. März 1991 brachte er den Mut zu seinem ersten Posting dort auf. Es begann wie folgt: Hallo an alle, ich habe Minix jetzt seit einer Woche und habe auf 386-Minix upgegradet (nett) und GCC für Minix heruntergeladen. Ja, es läuft, aber ... die Optimierung funktioniert nicht, und ich


--------------------------------------------------------------------------------------bekomme eine Fehlermeldung, die ,floating point Stack exceeded" oder so ähnlich lautet. Ist das normal? und endet mit der eigenartigen Signatur: advTHANKSance, Linus Torvalds torvalds@cc. helsinki.fi In diesem Posting fallen mehrere interessante Punkte auf. Zuerst hatte Linus 386-Minix installiert, bestehend aus einer Reihe von Patches (Änderungen und Zusätze) zum ursprünglichen Minix-Code, „sodass es auf einem 386 laufen konnte und man die 32 Bits wirklich nutzen konnte, denn das ursprüngliche Minix nutzte nur 16 Bits", erklärt Linus. Diese Patches bestanden in dem von dem Australier Bruce Evans geschriebenen Port. Er erinnert sich, dass er um ihre Akzeptanz kämpfen musste - so konservativ war Tanenbaum, wenn es darum ging, sein Unterrichtssystem zu erweitern. Evans sollte bald der Erste werden, der Linus beim Schreiben von Linux mit Rat und Tat zur Seite stand. Linus verwendete bereits den C Compiler GCC, was zeigt, dass er in C schrieb oder kurz davor stand. C war die Computersprache, die von den meisten professionellen Programmierern verwendet wurde und wie Assembler ein beträchtliches Maß an Fähigkeiten verlangte. Diese CProgramme würden, kombiniert mit den einfachen Experimenten in Assemblersprache, die er durchgeführt hatte, schließlich zur Grundlage von Linux werden. Das erste Posting von Linus an comp.os.minix ist interessant, aber sein zweites ist außergewöhnlich. Wie er selbst sagte, hatte er Minix erst eine Woche lang, und trotzdem antwortete er zwei Tage später - am 1. April 1991 - auf eine höfliche Frage von einem Teilnehmer, der Probleme mit 386-Minix hatte, als ob er ein Minix-Experte sei, für den solche Fragen so banal waren, dass sie ihn fast beleidigten. Er schrieb: RTFSC (Read the F**ing Souree Code :-} (Lies den verdammten Quellcode). Er ist umfassend kommentiert, und die Lösung sollte auf der Hand liegen.


------------------------------------------------------------------------------------Dann aber schwächt er diesen brüsken Ton ab und fügt hinzu: (Nimm das nicht so ernst, es hat mich auch eine Zeit lang genervt:-) Obwohl der erste Teil offensichtlich als Scherz gemeint war, ist der übertriebe selbstbewusste Ton charakteristisch. In der Öffentlichkeit versucht Linus oft, das Bild der Arroganz durch selbstabwertende Bemerkungen und ehrliche Bescheidenheit abzuschwächen. Die Erklärung für dieses verwirrende Verhalten ist nicht schwer zu finden. Wie viele begabte Intellektuelle litt Linus in jungen Jahren unter einem schwachen Selbstbewusstsein. Von seiner Studienzeit sagt er zum Beispiel: „Ich war so schüchtern, dass ich mich in den Vorlesungen nicht den Mund aufzumachen getraute. Ich war nicht fähig, meine Hand zu heben und irgendetwas zu sagen." Sein drittes Posting nach dem Ausbruch vom 1. April an die MinixNewsgroup, wieder eine Antwort auf die schriftliche Frage eines anderen Minix-Users, fiel moderater aus: „Ich bin selbst ein ziemlicher Neuling, was 386-Minix anbelangt", begann er bescheiden, „aber ich habe versucht, ein paar Dinge zu portieren und habe daher einige Kommentare“ Die Anforderungen seines Universitätsstudiums mögen dafür verantwortlich gewesen sein, dass fast drei Monate vergingen, bevor Linus sein nächstes Posting an die Newsgroup schickte. Wie Wirzenius sich erinnert, verbrachte Linus genügend Zeit an der Universität, um seine Prüfungen zu absolvieren, war aber zunehmend von seinem Programmierprojekt fasziniert. Linus war gezwungen, seine Prüfungen zu bestehen, weil er seinen PC mithilfe eines Studentenkredits gekauft hatte. Wirzenius sagt dazu: „Wenn du nicht genügend Zeugnisse für ein Jahr schaffst, bekommst du im nächsten Jahr eben keine Unterstützung vom Staat. Und wenn du zwei Jahre lang nicht genügend Zeugnisse sammelst, musst du mit der Rückzahlung des Kredits beginnen, und das ist ganz schön viel Geld, wenn du nicht arbeitest."


--------------------------------------------------------------------------------------Zum Glück war Linus begabt genug, um die vorgeschriebenen Prüfungen zu bestehen und trotzdem Zeit für die Arbeit am Computer zu haben. Im April, etwa um die Zeit, als er mit der Erforschung von Minix begann, entschloss er sich, sein einfaches Task-SwitchingProgramm, bei dem ein Prozess „A" und der andere „Bu schrieb, zu einem Terminalemulator umzuschreiben, der es ihm gestatten würde, die Usenet-Newsgroups im Universitätssystem von seinem Schlafzimmer aus zu lesen, indem er ein Modem an seinen PC anschloss. Linus beschreibt seine Arbeit entwaffnend einfach: „Ich änderte diese beiden Prozesse so, dass sie wie ein Terminalemulationspaket arbeiteten. Man hat da einen Prozess, der von der Tastatur liest und an das Modem sendet, und einen anderen, der vom Modem liest und an den Bildschirm sendet." Zu diesem Zweck musste er mehrere Treiber schreiben. Dabei handelt es sich um kleine Softwareprogramme, die als Mittler zwischen Peripheriegeräten wie Tastatur und Bildschirm und der zentralen Software fungieren, die den Großteil der Rechenarbeiten durchführt. Wie Linus in dem Interview vom Oktober 1992 sagte: „Die Grenze von Linux war eine Zeit lang das Terminalemulatorstadium. Ich spielte mit Minix herum und verwendete mein Programm dazu, Nachrichten vom Universitätscomputer zu lesen." Später entschloss er sich jedoch, es stärker zu erweitern. „Ich möchte Dinge herunterladen können“, sagt er. Das bedeutete, dass er seine modifizierte Task-Switching-Software mit einem Diskettenlaufwerk verbinden musste. „Also musste ich einen Festplattentreiber schreiben", erinnert er sich. Theoretisch war das ganz einfach, aber als Tanenbauin Minix schrieb, „begannen die Probleme mit schlechter Dokumentation, um uns zu behindern", sagte Linus später. Linus schrieb in einem Usenet-Posting im Jahr 1992: „Der PC ist derzeit die vielleicht meistverwendete Architektur der Welt, aber das bedeutet nicht, dass die Dokumentation irgendwie besser ist." Es war der Minix-Hacker Bruce Evans, der ihm an diesem kritischen Zeitpunkt half, indem er Linus einige undokumentierte Features der Hardware erklärte, die er verwendete. Nachdem er die Sache mit dem Festplattentreiber geklärt hatte, musste Linus eine Methode finden, um Dateien zu lesen und sie auf


------------------------------------------------------------------------------------die Platte zu schreiben, die nun zugänglich war. Dazu war etwas erforderlich, was man ein Dateiensystem nennt, eine Gruppe von Regeln, die bestimmen, wie die Daten auf der Festplatte organisiert werden. Linus setzte sich hin und schrieb ein System, das auf dem Minix-Dateisystem basierte, das er nun seit einigen Monaten verwendete. Er wollte „in der Lage sein, Dateien zu schreiben und Dateien zu lesen, um sie hochzuladen", erklärt er. „Am Anfang versuchte ich, ein Dateisytem zu erstellen, und verwendete dafür das Minix [-Dateisystem]. Dafür gab es einfache, praktische Gründe. Auf diese Weise hatte ich nämlich bereits ein Dateilayout, auf dem ich Dinge testen konnte“, erklärte er im Linux-News-Interview. Das „Dateilayout" bezog sich auf die bereits bestehende MinixInstallation auf seinem PC. Er konnte den Code seines neuen Dateisystems testen, indem er versuchte, davon zu lesen und darauf zu schreiben. Linus mag das Minix-Dateisystem „aus einfachen, praktischen Gründen" verwendet haben, aber aus dem Minix-Code in Tanenbaums Buch zu lernen, war offensichtlich ein anderer wesentlicher Vorteil dieses Ansatzes. Wie sich Linus in dem Posting aus dem Jahr 1992 erinnert, begann nun zwar „der schlimmste Teil", aber je mehr grundlegende Features zu seinem System hinzukamen, desto einfacher wurde es: „Das Codieren war immer noch haarig, aber ich hatte nun einige Hilfsmittel, und das Debuggen wurde leichter. Ich begann in dieser Zeit, mit C zu arbeiten, und das machte die Entwicklung eindeutig schneller" Außerdem, so sagt er, wurde es ihm in dieser Zeit mit seiner größenwahnsinnigen Idee ernst, ein „besseres Minix zu entwickeln als Minix selbst". Linus verwendete Minix als eine Art Gerüst für seine Arbeit an dem späteren Linux. Aber dieser Ansatz hatte einen Nachteil. Wie Linus sich erinnert: „Ich musste die Maschine neu booten, um mit meinem tollen Newsreader Nachrichten lesen zu können. Das war mehr als unpraktisch." Es war zeitaufwendig und bedeutete, dass Linus die anderen Fähigkeiten von Minix verlor. Er sagte sich, er könne doch versuchen, alle anderen Features von Minix aus dem „tollen Newsreader" heraus, den er geschrieben hatte, verfügbar zu machen. Linus meint, dass sich diese Entwicklung „im Grunde sehr


--------------------------------------------------------------------------------------langsam vollzog. Irgendwann einmal fiel mir auf, dass das potenziell nützlicher war, als Minix zu benutzen." Es erwies sich als viel mehr als nur „potenziell nützlich" „Bei Task Switching hat man im Grunde ein Dateisystem, und man hat Gerätetreiber - das ist Unix", erklärt er. Linux - oder jedenfalls ein entfernter Vorfahre von Linux - war geboren. Als die Universitätsferien begannen, konnte Linus sich voll seinem Projekt widmen, und das wirkte sich auf die darauf folgende Entwicklung von Linux eindeutig positiv aus. Wie Wirzenius erklärt, umfassten die Ferien „theoretisch den Juni, den Juli und den August, aber in der Praxis begannen sie Mitte Mai und dauerten bis Mitte September". Linus erinnert sich, dass er im ersten Sommer die ganze Zeit codierte. „Ich tat nichts anderes - sieben Tage die Woche, zehn Stunden am Tag." Wie Linus später in einer kurzen Geschichte von Linux schrieb, die er 1992 zusammenstellte, war die Folge dieser Programmierexzesse, dass „ich am 3. Juli über Dinge nachzudenken begann, die die Benutzerebene betrafen: Einige der Gerätetreiber waren fertig, und die Festplatte funktionierte tatsächlich. Das war eigentlich alles." Die Verlagerung seines Interesses zeigt sich in seinem nächsten Posting an die comp.os.minix Newsgroup vom 3. Juli, wo er sich über einen Standard namens Posix für „ein Projekt" erkundigt - Linux, in anderen Worten. Er schrieb: Hallo Netlander, bedingt durch ein Projekt, an dem ich arbeite (in Minis), interessiere ich mich für die Posix-Standarddefinition. Könnte mir irgendjemand ein (vorzugsweise) maschinell lesbares Format der neuesten Posix-Regeln zeigen? Posix ist ein Standard, der definiert, wie Programme auf Unix laufen das, was Linus als „Dinge auf Benutzerebene" und nicht auf Systemebene bezeichnet und was eine Art allgemeiner UnixKompatibilität definiert. Posix wurde entwickelt, um das Problem des damals stark zersplitterten Unix-Marktes zu lösen. Damals konnten Programme, die auf einer bestimmten Art von Unix liefen, nur auf dieser und auf keiner anderen verwendet werden. Wenn ein


------------------------------------------------------------------------------------Betriebssystem den Posix-Spezifikationen entsprach, war es für jede posixkompatible Applikation geeignet Wie Linus erklärt: „Ich wollte wissen, was die Standards über all die Schnittstellen - die Art, wie die Programme mit dem Kernel interagieren - sagten. Schließlich wollte ich nicht alle Programme portieren. Jedes Mal wenn ich beim Portieren eines Programms an Linux ein Problem hatte, änderte ich Linux, um das Portieren zu ermöglichen. Ich portierte nie die Programme, sondern ich portierte den Kernel, um mit den Programmen arbeiten zu können.“ „Bedauerlicherweise", so Linus, „sagte einer der Typen, die auf meine ursprüngliche Frage nach den Posix-Standards geantwortet hatten: „Tut mir Leid, sie sind nicht elektronisch verfügbar. Sie müssen sie kaufen." Aber Linus hatte eine andere Idee, „Wir hatten an der Universität SunOS." SunOS war eine frühe Version der Sun-Variante von Unix, die später auf Solaris umbenannt wurde. „Also suchte ich die Schnittstellen im SunOS-Handbuch." Was als zweitbeste Lösung begonnen hatte, „erwies sich schließlich als Glücksgriff", meint Linus, „denn die SunOS-Schnittstelle war etwa das, was Unix ein oder zwei Jahre später werden sollte." Das war nicht das erste Mal, dass sich ein Schritt, der mehr oder weniger vom Glück oder von den Umständen diktiert worden war, als Segen für das zukünftige Wachstum von Linux erwies. Aber wie sich zeigte, hatte Linus' Bitte um Informationen über Posix noch tiefgreifendere Konsequenzen: „Derselbe Typ, der mir sagte, dass die Standards nicht verfügbar waren, erklärte mir auch, dass sein lnteressensbereich Kernels und Betriebssysteme waren", sagt Linus über einen Angehörigen der Universität von Helsinki namens Ari Lemmke. „Lemmke hatte diesen kleinen Bereich auf ftp.funet.fi" - einem Internetserver der Universität, auf dem Dateien für Besucher gespeichert waren, die sie mit dem Standard File Transfer Protocol (FTP) herunterladen konnten. „Damals hieß dieser Server nic.fundet.fi. Lemmke sagte: 'Hey, ich reserviere ein Verzeichnis für dich!' So erstellte er das Verzeichnis /pub/os/linux", erinnert sich Linus. „Linux war mein Arbeitsname“, fährt Linus fort. „Ich wollte das System nie unter diesem Namen herausbringen." Er sagt, er härte Angst davor gehabt, dass ihn die Leute für größenwahnsinnig


--------------------------------------------------------------------------------------halten und das Programm nicht ernst nehmen könnten, wenn er diesen Namen zum offiziellen machte. Linus hatte ursprünglich geplant, seine sich langsam entwickelnde Software anders zu benennen. In Augenblicken der Verzweiflung fühlte er sich oft versucht, sie „Buggix" zu nennen, ein Name, der auf die vielen Fehler hinwies, die ihm oft jede Hoffnung nahmen. Das räumte er 1995 in einem FAQ-Eintrag ein. Aber er zog auch andere Namen in Betracht. „Ich hatte da diesen furchtbar schlechten Namen Freax-free + freak + x. Grauenhaft, ich weiß", gibt Linus zu. „Zum Glück gefiel der Name diesem Ari Lemmke überhaupt nicht, sodass er stattdessen den Arbeitstitel verwendete. Und später ging er nie mehr davon ab." So war Linux nun nicht nur geboren, sondern auch bereits getauft. Zuerst war das neue Linux-Unterverzeichnis auf dem Server der Universität leer. Linus wollte seinen jungen, fragilen Kernel der Öffentlichkeit noch eine Zeit lang vorenthalten. In dem Interview mit Wirzenius im Jahr 1992 sagte er: „Ich war noch nicht bereit für eine Veröffentlichung. Deshalb enthielt das Verzeichnis etwa einen Monat lang nur eine README-Datei {„Dieses Verzeichnis ist für den frei erhältlichen Minix-Klon bestimmt“ oder so ähnlich)", wie er erzählt. In diesem Stadium betrachtete Linus Linux immer noch als einen Klon von Minix und nicht als etwas Großes wie Unix. Obwohl es ihm noch widerstrebte, Linux zu veröffentlichen, wagte er doch schon, seine Existenz zu erwähnen. Am Sonntag, den 25. August 1991 schrieb er unter dem Titel: „Was seht Ihr in Minix in erster Linie?" an die comp.os.minix Newsgroup: Hallo an alle dort draußen, die ihr Minix verwendet Ich entwickle ein (freies) Betriebssystem (nur ein Hobby, wird weder groß noch professionell wie GNU) für 386(486}-ATKlone. Das Ganze läuft schon seit April und wird nun langsam fertig. Ich möchte nun ein bissehen Feedback über die Dinge einholen, die den Leuten an Minix gefallen oder nicht gefallen, da mein Betriebssystem diesem System ein wenig ähnelt (es hat unter anderem dasselbe physische Layout des Dateiensystems (aus praktischen Gründen)). ... Ich werde in einigen Monaten etwas Vorzeigbares haben,


------------------------------------------------------------------------------------und ich möchte wissen, welche Features den Leuten am wichtigsten sind. Vorschläge sind immer willkommen, aber ich kann nicht versprechen, dass ich sie implementieren werde :-) Linus ([email protected]) Die Antworten auf dieses Posting kamen postwendend. Ein finnischer Kollege schrieb nicht einmal vier Stunden später: „Erzähl uns mehr davon!", und fragte: „Welche Schwierigkeiten wird es mit dem Portieren geben?" Ein Minix-User aus Österreich schrieb: „Ich bin sehr interessiert an diesem Betriebssystem. Ich habe bereits daran gedacht, selbst ein Betriebssystem zu schreiben, aber festgestellt, dass ich nicht die Zeit habe, alles von Grund auf neu zu schreiben. Aber ich nehme an, dass ich bei der Aufzucht eines Baby-OS behilflich sein könnte :-)". Diese Mail war ein Vorbote der riesigen Welle an Hackereifer, die Linux bald ins Rollen bringen sollte. In seiner Antwort auf die Frage zum Portieren gab sich Linus pessimistisch: „Ich würde schlicht und einfach sagen, dass das Portieren nicht möglich sein wird. Das Ganze ist hauptsächlich in C geschrieben, aber die meisten Leute würden das, was ich schreibe, nicht als C bezeichnen. Es verwendet jedes vorstellbare Feature des 386, dessen ich habhaft werden konnte, da es sich auch um ein Projekt zur Erforschung des 386 handelt." Abschließend beschreibt Linus den aktuellen Stand seines Projekts detailliert: „Um es wirklich klar zu sagen - ja, ich kann GCC darauf verwenden und Bash und die meisten GNU-Utilities, aber beim Debuggen bin ich noch nicht wirklich weit. Es unterstützt noch nicht einmal Disketten. Bis zur Veröffentlichung ist es noch ein paar Monate hin. Selbst dann wird es wahrscheinlich nicht viel mehr können als Minix, und in mancher Beziehung sogar viel weniger. Es wird jedoch frei sein," In der Geschichte von Linux, die er 1992 schrieb, erinnert sich Linus daran, dass er, nachdem er sein Hobby zum ersten Mal erwähnte, „ein paar Mails bekam, deren Verfasser sich als Beta-Tester von Linux anboten". Ein paar Wochen später, im September 1991, hatte er das erste offizielle Linux zusammengestellt, das er


--------------------------------------------------------------------------------------unter der Version 0.01 herausbrachte. Trotzdem war Linus mit dem Produkt seines anhaltenden Programmiereifers noch nicht zufrieden. „Es war nicht elegant; ich war nicht besonders stolz darauf, sagte er und entschloss sich, es in comp.os.minix nicht anzukündigen. Stattdessen, so erinnert er sich, „stellte ich eine Liste mit all den Leuten zusammen, die auf mein Posting [vom 25. April] per E-Mail reagiert hatten." Sobald er Linux 0.01 in das Verzeichnis /pub/os/ linux hochgeladen hatte, das von Ari Lemmke erstellt worden war, „schickte ich ihnen eine E-Mail, in der stand: ,So, nun könnt ihr es euch ansehen.' Ich glaube nicht, dass diese Liste mehr als zehn oder fünfzehn Leute umfasste." Der einzige Grund, warum er diese erste, nicht zufrieden stellende Version veröffentlichte, war, wie er sagt, „dass ich das Gefühl hatte, dass ich diese Site mit etwas füllen musste, da ich sie nun schon einmal besaß." Er stellte nur den Quellcode hinein. Überraschenderweise lieferte Linus zusätzlich noch eine sehr umfangreiche, etwa 1.800 Wörter umfassende Release Note. Darin wurde betont, dass „diese Version in erster Linie zum Lesen gedacht ist". Und der Code ist tatsächlich höchst lesbar. Neben dem übersichtlichen, großzügigen Layout mit systematischen Einrückungen, die die zugrunde liegende Struktur betonen, ist er auch vollständig kommentiert, etwas, was gute Hacker ansonsten gern unterlassen. Einige der Anmerkungen sind bemerkenswert heiter und vermitteln die wachsende Begeisterung, die Linus offensichtlich verspürte, als der Kernel unter seinen Fingern Form anzunehmen begann: Das ist GUTER CODE! Ja ja, er ist hässlich, aber ich weiß nicht, wie ich das verbessern kann, aber er scheint zu funktionieren ... Das meiste davon war try and error"... Urghh. Hoffen wir, dass keine Bugs drin sind, denn das hier möchte ich nicht debuggen :-) Ich bin gereizt. Ich finde es einfach toll, kein Handbuch zu haben. Nun, das war sicher nicht lustig :-(. Hoffentlich funktioniert es ... So machen es ECHTE Programmierer.


------------------------------------------------------------------------------------Für alle, deren Speicher kleiner ist als 8MB - schwierige Sache. Ich habe auch nicht mehr, warum solltet ihr mehr haben :-). Der Quellcode ist da. Ändert ihn. (Im Ernst - es sollte nicht allzu schwierig sein. Ändert in erster Linie ein paar Konstanten etc. Ich habe bei 8 MB aufgehört, da meine Maschine nicht darüber hinaus erweitert werden kann (schon gut, sie war billig :-) In den begleitenden Anmerkungen schreibt Linus: „Obwohl ich bereit bin zu helfen, wie ich nur kann, damit das Ding auf euren Maschinen läuft (mailt mir), kann ich es nicht wirklich unterstützen. Ich nehme oft Änderungen von und die erste "Produktions"-Version wird sich wahrscheinlich stark von dieser Vor-Alpha-Version unterscheiden" Häufige Änderungen werden durch die ganze Geschichte von Linux ein Merkmal dieses Betriebssystems bleiben. Linus wies auch auf etwas hin, was für alle Hacker der damaligen Zeit offensichtlich war, was aber weniger klar wurde, als die Bekanntheit von Linux stieg. ..Traurigerweise", so schreibt er, ..bringt einen ein Kernel (das ist es, was Linux ist und immer gewesen ist) nirgendwo hin. Um ein funktionierendes System zu haben, braucht man eine Shell, Compiler, eine Bibliothek etc." Dann weist er darauf hin. dass „die meisten Tools, die für Linux verwendet werden, GNU-Software sind und unter GNU-Copyleft stehen" - ein früher Hinweis auf die Symbiose der beiden Systeme. Und doch ist es eigenartig, dass Linus für seinen eigenen Kernel nicht Stallmans General Public Licence. Copyleft, verwendete. Stattdessen schrieb er: Dieser Kernel ist ©1991 Linus Towalds, kann aber unter folgenden Voraussetzungen zur Gänze oder teilweise weitervertrieben werden: - Der volle Quellcode muss verfügbar (und frei) sein, wenn nicht durch die Verteilung, dann wenigstens auf Verlangen. - Die Copyrightvermerke müssen intakt sein. (Wenn Ihr nur Teile davon verteilt, müsst ihr möglicherweise Copyrights hinzufügen, da es nicht in allen Teilen ©s gibt.) Kleine


--------------------------------------------------------------------------------------Teilauszüge können ohne Rücksicht auf Copyrights kopiert werden. - Ihr dürft das System nicht gegen Gebühr vertreiben, nicht einmal gegen „Handling"-Kosten. Die letzte Klausel bedeutete, dass die Leute keine Gebühr für die Herstellung von Disketten mit dem Kernel erheben durften (der in komprimierter Form nur 72K groß war). Das war eine eindeutige Bremse für den weiteren Vertrieb von Linux. In dem 1992 erschienenen Interview mit Linux News erklärte Linus, warum er sich für diese Lizenz entschieden hatte. Shareware, die frei verteilt wird, die man aber im Fall der Entscheidung, sie zu verwenden, bezahlen muss, war nie eine Option für ihn: „Ich habe eine grundlegende Abneigung gegen Shareware. Ich fühle mich schuldig, wenn ich sie nicht bezahle, weshalb ich sie nicht verwende, aber auf der anderen Seite finde ich es irritierend zu wissen, dass sie da ist. Nicht logisch, aber das ist eben mein Gefühl." Die erste Form der Lizenz, so meinte er, „war wahrscheinlich eine Überreaktion auf die Abneigung, die ich gegen das Setup von Minix spürte. Ich dachte (und denke noch immer), dass es Minix besser ergangen wäre, wäre es durch FTP oder etwas Ähnliches frei verfügbar gewesen." Linus beendete seine Release Notes zu 0.01 mit einer Phrase, die Richard Stallman zu seiner Trademark-Abschiedsfloskel gemacht hatte: „Happy hacking." Die Ergebnisse von Linus' eigenem happy hacking waren bald in der Linux-Version 0.02 zu sehen. Diesmal hatte Linus keine Hemmungen, die Welt zu informieren. Am Samstag, den 5. Oktober 1991 schickte er ein Posting an comp.os.minix, das so begann: Sehnt ihr euch nach den glücklichen Tagen von Minix 1.1 zurück, als Männer noch Männer waren und ihre eigenen Gerätetreiber schrieben? Fehlt euch ein nettes Projekt und brennt ihr schon darauf euch in ein OS zu verbeißen, das ihr an eure Bedürfnisse anzupassen versuchen könnt? Findet ihr es frustrierend, wenn alles auf Minix läuft? Keine durchwach-


------------------------------------------------------------------------------------ten Nächte mehr, um das nette Programm zum Laufen zu bringen? Dann könnte dieses Posting genau für euch sein: Wie vor einem Monat (?) erwähnt, arbeite ich an einer freien Version eines minixartigen Betriebssystems für AT-386-Compuier. Nun ist endlich das Stadium erreicht, wo es verwendbar ist (wenn auch abhängig davon, was ihr damit machen wollt), und ich bin bereit, den Quellcode zur weiteren Verteilung zu veröffentlichen. Ein weiterer Absatz im selben Posting vermittelt uns einen Einblick, wie Linus Linux im Vergleich zu den anderen, besser etablierten UnixKernels, nämlich GNU Hurd und Minix, sah: Ich kann euch (nun ja, fast) fragen hören: „Warum? Hurd wird in einem Jahr (oder in zwei, oder im nächsten Monat, wer weiß das schon) herauskommen, und ich habe ja bereits Minix/' Das ist ein Programm für Hacker von einem Hacker. Die Entwicklung hat mir Spaß gemacht, und es könnte durchaus sein, dass jemand Spaß daran hat, hineinzuschauen und es seinen eigenen Bedürfnissen anzupassen. Es ist immer noch klein genug zum Verstehen, Verwenden und Modifizieren, und ich freue mich über jeden Kommentar. Linus begann zu erkennen, dass zwischen dem fertigen, aber im Wesentlichen eingefrorenen Minix und dem viel versprechenden, aber noch unvollständigen GNU eine Lücke bestand, die er mit seinem „Programm von einem Hacker für Hacker" füllen konnte. Linux mochte noch roh sein, aber es funktionierte. Es konnte also verbessert werden, während Hurd im Wesentlichen ein Versprechen blieb. Außerdem forderte Linus im Gegensatz zu Tanenbaum Verbesserungsideen an und begrüßte die eigenen Aktivitäten der Leute in dieser Richtung. Linus erzählt, dass „die zweite Version viel näher an dem war, was ich eigentlich wollte." Das Projekt bewegte sich noch in einem ziemlich kleinen Rahmen, zehn oder zwanzig Leute, aber es weitete sich zusehends aus. In dem 1992 in Linux News erschienenen Interview sagte Linus über die Vorgängerversion (0.01): „ich glaube


--------------------------------------------------------------------------------------nicht, dass sie mehr als fünf [bis] zehn Leute zu Gesicht bekommen haben. " Er erklärte gegenüber Linux News: „Von meinem unerwarteten Erfolg beflügelt, nannte ich die nächste Version 0.10." Linus erinnert sich, dass „die Dinge eigentlich ziemlich gut zu laufen begannen14. Version 0.11 erschien irgendwann Anfang Dezember. „Das Ganze ist noch nicht so umfassend wie 386-Minix", schrieb Linus am 19. Dezember 1991 in einem Posting an comp.os.minix, „aber in gewisser Hinsicht besser." In diesem Posting finden sich einige interessante Kommentare über den gegenwärtigen Status von Linux und seine zukünftige Entwicklung: „Ich/wir halten es für besser als Minix, aber ich bin da voreingenommen. Es wird nie ein professionelles Betriebssystem sein wie Hurd es (vielleicht im nächsten Jahrhundert oder so :-)) sein wird, aber es ist ein nettes Lernwerkzeug (IMH0l1 noch mehr als Minix), und die Arbeit daran macht(e) Spaß." Das Posting vom 19. Dezember enthielt auch eine Kopie von Linus' „Plan". Dabei handelt es sich um eine Datei, die gesendet wird, wenn ein User über das Netzwerk (mithilfe eines Programms namens „Finger") „gefingert" wird. Es stellte eine wichtige Möglichkeit für die Leute dar, Informationen über Linux zu beschaffen, ohne Hunderte von Newsgroup-Postings durchzugehen. Linus' Plan zu diesem Zeitpunkt trug die Überschrift „Freies UNIX Für den 386 - es kommt 4QR 91 oder IQR92". Er beginnt so: „Die aktuelle Version von Linux ist 0.11 - sie hat fast alles, was ein Unix-Kernel braucht" Das war wahrscheinlich das erste Mal, dass Linus Linux öffentlich als ein Projekt zur Schaffung eines Unix-Kernels und nicht nur zur Entwicklung von Minix bezeichnete. Aus dem Plan ging auch hervor, dass die Linux-Software nun auch auf zwei anderen Sites zu finden war - die eine davon in Deutschland und die andere in Richard Stallmans Heimatstadt Boston am MIT. Diese wurde von Ted Ts'o (sprich: „Tscho") geführt. Er wird (unter seinem E-Mail-Namcn tytso) am unteren Rand derselben Informationsseite als eine jener Personen erwähnt, die an den neuen Features des bevorstehenden Linux 0.12 arbeiteten.

1

IMHO: In my humble opinion - meiner bescheidenen Meinung nach


------------------------------------------------------------------------------------Obwohl noch kaum sichtbar, war dies eine extrem wichtige Entwicklung; sie bedeutete, dass andere Hacker Beiträge zum LinuxProjekt leisten konnten. In diesem Posting vom 19. Dezember an comp.os.minix war auch die Rede von „Leuten", die an SCSI-Treibern arbeiteten, um Linux den Zugriff auf ein anderes Festplattensystem zu ermöglichen. Mit „Leute" war nicht Linus gemeint. Wieder ein Hinweis darauf, dass bereits andere beteiligt waren. Dies wurde durch eine Nachricht bestätigt, die am nächsten Tag von Drew Eckhardt angeschlagen wurde, dem Autor dieser SCSI-Treiber. Er hatte bereits an Version 0.11 mitgearbeitet. Sein Posting war eine Reaktion auf eine allgemeine Anfrage über Linux, in der unter anderem Folgendes stand: Könnte mir bitte jemand Informationen über [Linux] geben? Am besten, ihr bezieht euch auf diesen Artikel, denn ich glaube, dass es eine Menge potenziell interessierter Leute gibt, die diese Newsgroup verfolgen. Auffallend ist, dass es nicht Linus ist, der antwortet, sondern Eckhart, und zwar sehr detailliert. Dies ist als Hinweis darauf zu werten, dass zumindest eine andere Person bereits genug wusste, um das zu tun. Außerdem verwendet Eckhardt das Wort „wir", wenn er von Linux spricht. Was einst das „Hobby" eines Hackers gewesen war, wuchs nun zu einer Gemeinde heran. Linus war selbst in diesem frühen Stadium schon bereit, auf die Bedürfnisse dieser Gemeinde zu hören. Einige der ersten Linux-User wollten etwas, was Virtual Memory (VM) genannt wurde. Dabei handelte es sich um die Fähigkeit, Festplattenspeicher so zu verwenden, als handle es sich um gewöhnlichen RAM; das war ein Standardfeature von Unix und stellte zu einer Zeit, als Speicherchips noch teuer waren, eine große Hilfe dar. Linus war an diesem Feature nicht interessiert. Der Grund war wahrscheinlich, dass er gerade genug RAM hatte und dass seine eigene Festplatte so klein war. Aber er setzte sich über dieses Weihnachten trotzdem hin und schrieb den Code, um den Linux-


--------------------------------------------------------------------------------------Kernel um Virtual Memory zu erweitern. Dann veröffentlichte er das Ganze als Version 0.11+VM. In der Geschichte des frühen Linux, die er 1992 schrieb, erinnert sich Linus, dass 0.11+VM „nur für wenige Leute zugänglich war, die es testen wollten. Ich bin immer noch überrascht dass es so gut funktionierte." Bescheiden wie er war, vergaß er zu erwähnen, dass er diesen Code in nur einigen wenigen Tagen geschrieben hatte. Virtual Memory wurde dann zum Standardteil des Kernels der nächsten Version. Was als kleine private Anfrage begonnen hatte, war zu einem wichtigen Feature geworden. Die Release Notes von Version 0.12 sind bereits von großer Begeisterung und von Linus' wachsendem Leistungsbewusstsein getragen. Sie beginnen mit der in Großbuchstaben geschriebenen inständigen Bitte an die Benutzer, Linux auf keinen Fall zu installieren, wenn sie nicht genau wussten, was sie taten: „Wenn du weißt, was du tust, kannst du es machen. Wenn nicht, droht Chaos! Oder schreib mir, wenn du Erklärungen brauchst. Nur - installiere Linux nicht! Es ist ganz einfach, aber wenn du nicht weißt, was du tust, könnte es dir bald Leid tun. Mir ist es lieber, ein paar unnotwendige Mails zu beantworten als Mails zu bekommen, in denen steht: ,Du hast meine Harddisk ruiniert, du Idiot. Ich werde dich finden, koste es was es wolle, und dann hat dein letztes Stündlein geschlagen.'" Wie Linus erklärt, waren „die früheren Versionen eigentlich nur für Hacker gedacht". Das bedeutete, dass sich Version 0.12 für ein breiteres Publikum eignete. Das mag so gewesen sein, aber trotzdem stand in den Installationsanweisungen zum Beispiel: „Linux nochmals booten, fdisk, um sicherzustellen, dass du jetzt die neue Partition hast, und mkfs, um auf einer von fdisk gemeldeten Partition ein Dateisystem zu erstellen. Schreib ,mkfs -c/dev/hdX nnn\ wobei X die von Linux fdisk gemeldete Geräte-nummer ist und nnn die Größe - ebenfalls gemeldet von fdisk. nnn ist die Größe in /blocks/, d.h. Kilobytes, Anhand der Größeninformation solltest du feststellen können, welche Partition von welchem Gerätenamen repräsentiert wird." Das zeigt die Welten, die Linux von sagen wir Windows 3.1 trennten, das nur ein paar Monate später heraus kommen sollte.


------------------------------------------------------------------------------------Version 0.12 brachte aber nicht nur wichtige Verbesserungen des Codes, sondern auch eine überarbeitete Lizenz. Linus erklärt den Grund: Schon ziemlich früh gab es Leute, die zufällig in derselben Gegend lebten und Linux anderen zur Verfügung stellen wollten, die daran interessiert waren. Aber die Originallizenz ließ nicht einmal eine Gebühr für das Kopieren zu. Das bedeutete, dass man nicht einmal die Disketten zu einem höheren Preis als dem Diskettenpreis verkaufen konnte. Das machte natürlich keinen Sinn - irgendjemand musste viel arbeiten, denn das Kopieren von Disketten ist zeitaufwändig. Es ist zeitaufwendig, und es gibt nur sehr wenige Leute, die Zugang zu diesen automatischen Kopiergeräten haben. Ich wurde also immer wieder gebeten, eine Art Kopiergebühr zuzulassen, auch wenn sie nur gering war Nicht weil die Leute Geld verdienen wollten, sondern weil sie kein Geld verHeren wollten, indem sie Linux anderen zur Verfügung stellten und ihnen damit halfen. Am Ende entschloss sich Linus, die GNU General Public Licence (GPL) von Richard Stallman zu übernehmen. 1996 gab er zu, dass „ich eigentlich kein echter GPL-Fan bin. Sie enthält zu viel Fachchinesisch, und meiner Meinung ist sie auch ein bisschen zu streng." Aber er räumte ein, dass „die GPL andererseits sehr gut funktioniert. Ich kann nicht sagen, dass ich unzufrieden mit ihr bin." Rückblickend betrachtet erwies sich der Umstieg auf die GPL als entscheidender Schritt, vor allem im Hinblick auf die spätere Kommerzialisierung von Linux. Version 0.12 war möglicherweise der Wendepunkt für Linux. Davor war es eine Art Kuriosität gewesen: interessant, aber weder besonders nützlich noch besonders wichtig. Mit Version 0.12 begannen sich viel mehr Leute für das neue System zu interessieren. Eine neue Mailingliste, Linux-activists, hatte am 13. Januar bereits 196 Mitglieder. Linus war in der comp.os.minix Newsgroup bereits ein Unterschied aufgefallen: Innerhalb von zwei Wochen [nach der Veröffentlichung von Linux 0.12] stieg die Diskussion


--------------------------------------------------------------------------------------darüber sprunghaft an", erzählt er. „Es gab offensichtlich Leute, die bereit waren, Linux für das zu verwenden, wofür sie früher Minix verwendet hatten. Dabei handelte es sich hauptsächlich um MinixLeute, denn in diesen Kreisen, in den Minix-Newsgroups, spielten sich alle Diskussionen ab." Offensichtlich probierten viele Minix-User Linux aus und unterhielten sich darüber Aber nicht alle zeigten sich über die immer stärker anschwellende Diskussion über Linux auf comp.os.minix begeistert. Ein Teilnehmer schrieb: Ich will wirklich nichts anzünden, aber es beginnt mich zu ärgern, dass 50 Prozent der Artikel die ich in dieser Newsgroup lese, von Linux handeln. Am selben Tag, an dem diese nicht ganz ungerechtfertigte Klage gepostet wurde, meldete Linus einen amüsanten Unfall auf seiner Maschine. Er hatte versucht, eine Verbindung zum Computer der Universität herzustellen, seinem Terminalemulator-Programm aber versehentlich die Anweisung gegeben, seine eigene Harddisk anzuwählen. Das schien zwar schwierig zu sein, war aber Dank der vielleicht innovativsten Neuerung, die der Urheber von Unix je ersonnen hatte, ganz einfach: Für Unix und in der Folge auch für Linux war alles eine Datei. Das bedeutete, dass zwischen dem Senden von Daten an ein Modem oder an ein Diskettenlaufwerk kein erheblicher Unterschied bestand. Dieser Ausrutscher löschte das Minix-System, das Linus gemeinsam mit dem ständig wachsenden Linux behalten hatte. Ursprünglich war Minix ein unverzichtbares Gerüst für die Entwicklung von Linux gewesen; aber seit Linux nun ohne Minix als Krücke auskam, gab es keinen Grund mehr, Minix nach diesem Unfall nochmals zu installieren. Vielleicht war dieser Befehl, seine Harddisk anzuwählen, gar kein Fehler gewesen, sondern eher eine Freudsche Fehlleistung Linus', ein symbolisches Abschütteln eines Programms der älteren Generation. Durch einen interessanten Zufall wurde der endgültige Bruch zwischen den Welten von Minix und Linux nur zwei Wochen später vollzogen, als Andrew Tanenbaum ein Posting an comp.os.minix


------------------------------------------------------------------------------------schickte, das zu einer der berühmtesten Botschaften in der Geschichte des Usenet werden sollte: In der Betreffzeile hieß es provokant „Linux ist obsolet", und es begann so: Ich war ein paar Wochen in den USA und hatte deswegen nicht viel Zeit, LINUX zu kommentieren (nicht, dass ich viel dazu gesagt hätte, wenn ich hier gewesen wäre). Aber um zu sagen, was zu sagen ist, habe ich nun einige Kommentare: Wie die meisten von euch wissen, ist MINIX ein Hobby für mich, etwas, was ich am Abend mache, wenn mir das Bücherschreiben langweilig wird und wenn auf CNN gerade keine Kriege, Revolutionen oder Senatshearings übertragen werden. Mein eigentlicher Job ist der eines Professors und Forschers im Betriebssystembereich. Aufgrund meiner Tätigkeit glaube ich ein wenig über die Richtung zu wissen, in die sich Betriebssysteme im nächsten Jahrzehnt bewegen werden. Dabei kristallisieren sich zwei Entwicklungen heraus: Tanenbaum geht im Weiteren auf diese beiden Entwicklungen ein, Mikrokernels im Gegensatz zu monolithischen Kernels und Portahilität. Seine Argumente sind gut, sein Stil ist geschliffen. Über die Frage des Kerneldesigns sagt Tanenbaum Folgendes: Ich könnte mich nun natürlich lang über die jeweiligen Vorteile der beiden Designs verbreiten, aber ich denke, es genügt zu sagen, dass die Diskussion unter den Leuten, die tatsächlich Betriebssysteme entwickeln, im Grunde vorbei ist. Die Mikrokernels haben gewonnen. Dann folgte ein etwas pointierterer Angriff auf Linus' Kreation: LINUX ist ein System im monolithischen Stil. Das ist ein gewaltiger Schritt nach hinten in die siebziger Jahre. Es ist, als wollte man ein bestehendes, funktionierendes Programm in C nehmen und es in BASIC neu schreiben.


--------------------------------------------------------------------------------------Das war eine echte Beleidigung für jeden Hacker, wie Tanenbaum sicher wusste. Zur Portabilität bemerkte Tanenbaum: Ich halte es für einen groben Fehler, ein Betriebssystem für eine bestimmte Architektur zu entwerfen - so lang ist seine Lebensdauer wahrscheinlich nicht. MINIX war so ausgelegt, dass es einigermaßen portierbar war, und es wurde portiert -von der Intel-Linie bis zu 680x0 (Atari, Amiga, Macintosh), SPARC und NS32016. LINUX ist ziemlich eng an den 80x86 gebunden. Das ist der falsche Weg. Entgegen seinen Erwartungen wurde die Intcl-Chipfamilie so stark, dass die Bedeutung der meisten anderen Chips stark abfiel; aber abgesehen davon hatte Tanenbaum insofern Recht, als Linux zu diesem Zeitpunkt „ziemlich eng" an die Intel-Architektur gebunden war. Der Grund lag aber einfach darin, dass es aus Experimenten heraus gewachsen war, die dazu gedient hatten, einen Chip dieser Familie zu erforschen. Wie die späteren Ereignisse zeigen sollten, war Linux keineswegs dazu verdammt, ein ausschließliches Jntel-System zu sein, Linus konnte Tanenbaums Kommentare auf keinen Fall ignorieren. Er hatte Linux in den letzten neun Monaten einen immer größeren Teil seines Lebens gewidmet, und er war natürlich zu Recht stolz auf die Tatsache, dass die Gemeinde der Linux-User rasant wuchs. Und dann kam irgendein hergelaufener alter Wissenschaftler, der alles für nichtig erklärte. Wirzenius: „Linus hat dieses Riesenego. Wenn jemand etwas sagt, was ihn in seinem Stolz verletzt, dann schlägt er zurück." In diesem Fall brauchte Linus für den Gegenschlag ganze elf Stunden. Seine Worte lassen spüren, dass er vor Zorn bebt. Man kann förmlich sehen, wie er sich die Ärmel hochkrempelt und sich zum Kampf rüstet: Nun, ich fürchte, dass ich bei einem Thema wie diesem antworten muss. Ich entschuldige mich bei allen Minix-Usern, die bereits genug über Linux gehört haben. Ich wäre froh, wenn


------------------------------------------------------------------------------------ich diesen Fehdehandschuh ignorieren könnte, aber ... Ich nehme an, es ist Zeit für eine ernsthafie Auseinandersetzung! Er beginnt mit einem allgemeinen Seitenhieb auf die Qualität von Minix. „Linux lässt Minix in fast jeder Hinsicht dumm dastehen", und setzt mit einem Tiefschlag nach: „Gar nicht zu reden von der Tatsache, dass der meiste gute Code für PC-Minix offensichtlich von Bruce Evans geschrieben worden ist." Linus ist wütend über Tanenbaums Behauptung, dass Minix sein Hobby sei, und er stellt seine ursprüngliche Motivation für das Schreiben von Linux in ein interessantes Licht: Schaut doch, wer mit Minix Geld verdient, und wer Linux frei verteilt Erst dann können wir über Hobbys reden. Macht Minix frei verfugbar, und eines meiner größten Ärgernisse wäre damit ausgeräumt. Dann beginnt Linus wieder auf Minix einzuschlagen. Indem er sich auf Tanenbaums Bemerkung bezieht, dass er eigentlich Professor und Forscher sei, schreibt Linus: Das ist eine ausgezeichnete Entschuldigung dafür, wie hirnverbrannt Minix in vieler Hinsicht ist. Ich kann nur hoffen (und annehmen), dass Amoeba nicht so daneben ist wie Minix. (Das Betriebssystem Amoeba ist Tanenbaums Hauptforschungsprojekt und damit sein „eigentlicher Job".) Wie er es neun Monate vorher getan hatte, begann Linus auch hier fast sofort, seine Attacken abzuschwächen. „PS: Es tut mir Leidt wenn ich manchmal zu brüsk rüberkomme: Minix ist durchaus in Ordnung, wenn man nichts anderes hat. Amoeba könnte auch in Ordnung sein, wenn man 5-10 überflüssige 386er herumstehen bat, aber die habe ich nicht. Ich werde normalerweise nicht ungehalten, aber ich bin ein bisschen empfindlich, wenn es um Linux geht:-)" Am nächsten Tag, vielleicht nachdem er die Sache überschlafen hatte, war er noch reuiger:


--------------------------------------------------------------------------------------Er schrieb: Nun, bei einem solchen Thema fürchte ich, dass ich antworten muss. Und das tat ich, vollkommen unbedacht und ohne jedes Gefühl für guten Geschmack und Netiquette. Ich entschuldige mich bei [Andrew Tanenbaum] und bedanke mich bei John Null für seinen freundlichen „So-macht-man-das-nicht'-Brief. Ich habe überreagiert, und ich schreibe nun einen (viel weniger scharfen) persönlichen Brief an [Andrew Tanenbaum]. Ich hoffe, dass sich niemand von Linux abgewendet hat, weil es (a) möglicherweise vollkommen obsolet ist (ich glaube immer noch, dass das nicht der Fall ist, wenn auch ein Teil der Kritik berechtigt ist) und (b) von einem Hitzkopf geschrieben wurde :-}. Linus „mein erster und hoffentlich letzter Ausbruch" Torvalds Sein „letzter Ausbruch" war es sicher nicht, aber der Ton der Diskussion wurde ein wenig moderater, als Tanenbaum und er nun über einige technische Details diskutierten. An dieser Diskussion beteiligten sich andere Teilnehmer, die die Situation von einem unabhängigen Standpunkt betrachtet zusammen fassten: Viel, wenn nicht die meiste Software, die wir verwenden, ist gemessen an den aktuellsten Designkriterien veraltet Den meisten Usern ist es vollkommen egal, wenn der Inhalt des von ihnen verwendeten Betriebssystems obsolet ist. Sie sind zu Recht hauptsächlich an seiner Leistung und an seinen Fähigkeiten auf Benutzerebene interessiert. Ich würde im Allgemeinen zustimmen, dass Mikrokernels wahrscheinlich die Sache der Zukunft sind. Es ist meiner Meinung nach allerdings leichter einen monolithischen Kernel zu implementieren. Es ist aber auch leichter, ihn beim Modifizieren im Nu in ein Chaos zu verwandeln. Grüße Ken


------------------------------------------------------------------------------------„Ken" ist Ken Thompson, der Erfinder von Unix. Die Diskussion zwischen Linus und Tanenbaum wurde mit der Zeit fast spielerisch. Zu den beiden Hauptthemen, dem Kerneldesign und der Portabilität, schrieb Tanenbaum: „Ich vertrete immer noch den Standpunkt, dass die Entwicklung eines monolithischen Kernels im Jahr 1991 ein grundlegender Fehler ist. Sei froh, dass du nicht mein Student bist Du würdest für ein solches Design keine gute Note bekommen :-)." Über die Portabilität sagte er: „Im Jahr 1991 ein neues Betriebssystem nur für den 386er zu schreiben, bringt dir das zweite „Nicht genügend“ für dieses Semester ein. Aber wenn du bei der Abschlussprüfung wirklich gut abschneidest, kannst du noch immer ein positives Zeugnis für diesen Kurs bekommen." Darauf antwortete Linus humorvoll: Tja, ich werde wahrscheinlich auch ohne dich keine tollen Noten bekommen: Ich hatte einen Streit (ganz ohne Zusammenhang mit Linux - es ging nicht mal um Betriebssysteme) mit dem Typen, der hier an der Universität OS-Design unterrichtet Ich frage mich, wann ich einmal klüger sein werde :-). Kurz nach dem „Linux-ist-obsolet"-Streit hörte Linus mit den Postings in der comp.os.minix Newsgroup vollkommen auf. Der Grund war nicht, weil er es unpassend fand, Linux dort weiter zu propagieren, und auch nicht, dass er sich von Tanenbaum beleidigt fühlte. Der Grund war einfach, dass er jetzt eine andere Newsgroup hatte: alt.os.linux. Sie befand sich in der „inoffiziellen" Alt-Usenet-Hierarchie, aber nach einiger Zeit wurde sie zum „offiziellen" comp.os.linux, vollkommen gleichwertig mit Tanenbaums comp.os.minix. Nichts symbolisierte besser, dass Linus, nachdem er gegen den alten Löwen rebelliert hatte, wie es alle jungen Löwen tun müssen, nun daran war, sich selbstständig zu machen. Später, in seinem 1992 in Linux News erschienenen Interview, sagte er: „Ich muss ein schändliches (aber verständliches, wie ich hoffe) Gefühl der Schadenfreude zugeben, wenn ich sehe, dass [comp.os.linux] jetzt mehr Leser hat als [comp.os.]minix. Mehr


--------------------------------------------------------------------------------------Leser also als eine Newsgroup, die einst von 40.000 Leuten mit großem Interesse gelesen wurde." Und trotzdem behält Linus eine Schwäche für Minix und die comp.os.minix Newsgroup. Noch im Juli 1999 las er sie regelmäßig und schickte sogar Postings. Jemand erkundigte sich nach GCC für Minix und genau dort hatte in dieser ersten Nachricht vom 29. März 1991 alles begonnen: „Wie schaffte es Linus, dass die GCC Library mit Minix funktionierte, und eigene Systemaufrufe unterstützte und dergleichen?“ fragte der Autor. Linus konnte offensichtlich der Versuchung nicht widerstehen, auf diesen Sirenenruf aus der Vergangenheit zu antworten. Seine Antwort holt zeitlich weit aus, und er beschreibt, wie alles begann. Abschließend schreibt er: Ein Großteil dieser Arbeit müsste eigentlich noch verfügbar sein. Ich veröffentlichte meinen 1.40 Port [von GCC], aber ich muss zugeben, dass ich nicht weiß, wo er gelandet ist. Das ist acht Jahre her... In diesen Worten ist ein Hauch von Sehnsucht nach diesen fernen, hoffnungsfrohen Zeiten der Jugend zu spüren, als Linus das Programm, das seinen Namen trägt, Schritt für Schritt aufbaute; als er die Saat zu etwas legte, was zu dem Kernel eines vollständigen Betriebssystems werden sollte, das von Dutzenden Millionen Menschen verwendet werden würde und eine Bewegung auslöste, deren Auswirkungen immer noch nicht zu Ende sind.

(Leerseite)

4

Der Faktor X

FAST UNMITTELBAR NACHDEM ER UND TANENBAUM über die jeweiligen Vorteile von Linux und Minix diskutiert hatten, ließ Linus die Nummer der neuen Version seines Betriebssystemkernels, die am 7. März 1992 heraus kam, von 0.12 auf 0.93 springen. Dieser Sprung beruhte wahrscheinlich auf dem ehrlichen, wenn letzten Endes auch überoptimistischen Glauben, dass die erste „echte" Version von Linux nahe sein könnte (in Wahrheit war sie noch zwei Jahre entfernt). Wahrscheinlich spiegelte er auch das psychologische Bedürfnis wider, der Welt und vielleicht auch sich selbst zu demonstrieren, dass der Code nun so gut wie fertig war. Viele Minix-User blieben skeptisch. So fragte zum Beispiel Tim Murphy, Direktor der Computerabteilung der Irischen Universität, im Januar 1991 in comp.os.minix: „Stimmt es, dass Linux von einer einzelnen Person entwickelt wird, und kann mir irgendjemand sagen, welche Vorteile es gegenüber 386-Minix hat?", und


------------------------------------------------------------------------------------weiter: „Es erscheint mir beim ersten Ansehen einigermaßen unwahrscheinlich, dass jemand in so kurzer Zeit von der Pike auf ein zuverlässiges Betriebssystem schreiben kann." Murphy erklärt dazu heute: „Ich fand, dass Minix ausgezeichnet geschrieben wan Es war meiner Ansicht nach besser geschrieben, als Linux es heute ist" Murphy stand mit seiner Meinung nicht allein. Derek Lieber, Systemprogrammierer in einem großen Computeruntemehmen und Minix-User, sagte, er fände den Minix-Code „gut geschrieben und in überschaubare Subsysteme geordnet. Natürlich war Minix mit Absicht auf diese Weise geschrieben worden", fügt er hinzu, „weil es als Lehrmittel gedacht war. Was die Qualität des Code [des frühen Linux] anbelangt, denke ich, dass sie eher mittelmäßig war." Aber mittelmäßig oder nicht - er fügt hinzu: „Ich wunderte mich, dass das Ding funktionierte. Ich hatte erwartet, dass es abstürzen würde, sobald ich es installiert hätte. Aber das verdammte Ding lief und lief. Ich glaube nicht, dass ich es übermäßig stark beanspruchte, aber ich erinnere mich an keinen einzigen Absturz. Nicht einmal in den frühen Tagen." Nicht genug damit, war Linux auch außergewöhnlich praktisch. „Es lief auf einem einfachen 386er-Laptop mit 5 MB Speicherund einer 40 MB Harddisk", erinnert sich Lieber. „Aber ich konnte den gesamten [Kernel], seinen Quellcode und den Quellcode aller GNU-Tools hineinkriegen und hatte noch immer 10 MB für mein eigenes Zeug frei. Das war der Programmiererhimmel." Es überrascht nicht, dass dieser „Programmiererhimmel" bald eine wachsende Schar begeisterter und begabter Codierer anlockte. Unter ihnen waren Ted Ts'o und Drew Eckhard, die Linux bereits 1991 erweitert hatten. So hatte Ts'o einige „wichtige Änderungen sogar an 0.10" vorgenommen, wie Linus es in einer seiner Diskussionen mit Tanenbaum in der ersten hitzigen „Linux-ist-obsolet"-Zeit ausdrückte. In ähnlicher Weise erinnert sich Eckhardt, dass er Version 0.10 heruntergeladen hatte und dass sie nicht ordentlich funktionierte. „Also überlegte ich mir, was funktionieren würde", sagt er und schickte Linus ein Patch oder eine korrigierte Version jenes Teil des Linux-Quellcodes, der das Problem verur-

4. Der Faktor X

--------------------------------------------------------------------------------------sacht hatte. Bald danach brachte Linus „Version 0.11 und 0.12 heraus, und zwar mit meinen Änderungen", erinnert sich Eckhardt. Nach Version 0.95 begannen viel mehr Leute, Linux zu verwenden, und manche begannen, ihre eigenen Beiträge zum Kernelcode einzusenden. Für diese Beiträge wurde eine Mailingliste eingerichtet, die es ihnen ermöglichte, mit den Entwicklungen Schritt zu halten und Ideen auszutauschen. Einer dieser frühen „Kernelhacker" war Rieh Sladkey. „Mein erster installierter Kernel war 0.95b" - ein geringfügiges Upgrade gegenüber Version 0.95, die im Frühling 1992 herausgekommen war „aber ich hatte schon ein paar Monate davor begonnen, Linux zu verfolgen", erinnert er sich. „Ich wartete auf eine 200 MB Harddisk, damit ich Windows 3.1, das ich für [Applikationen] mit Linux brauchte, multibooten konnte." Multibooting bedeutete die Möglichkeit, beim Hochfahren des PC zwischen Windows und Linux wählen zu können. Die Erwähnung dieser Funktion an dieser Stelle ist wichtig. Obwohl Sladkey in der Arbeit Unix verwendete, wird deutlich, dass er auch mit der Welt von Microsoft vertraut war und Linux und Windows auf derselben Maschine verwenden wollte. Das war bei immer mehr Linux-Hackern so. Die Wahl zwischen Windows und Linux wurde ihnen durch eine Designentscheidung ermöglicht, die Linus bereits in einem frühen Stadium getroffen hatte und die zum Teil von dem Spiel „Prince of Persia" inspiriert war, das er auf seinem PC gespielt hatte, bevor er mit dem Linux-Projekt begonnen hatte. Damit er dieses Spiel während der Arbeit an Linux spielen konnte, musste er einen Teil seiner Festplatte für MS-DOS formatiert haben. Wie Linus in seinem Interview mit Linux News 1992 sagte: „Als Minix schließlich kam, hatte ich PoP (Prince of Persia) gelöscht Also installierte ich Minix (wobei ich ein bisschen Platz fur PoP auf einer DOS-Partition ließ) und zu hacken begann." Linus schrieb Linux, damit es wie Minix neben dem Betriebssystem von Microsoft verwendet werden konnte, nicht als ausschließlicher Ersatz. So konnten später alle, die neugierig auf Linux waren, es ausprobieren, ohne DOS vollkommen wegzuwerfen. Das wäre ein schwerwiegender Schritt gewesen, der die frühe Akzeptanz von Linux mit Sicherheit beträchtlich verzögert hätte.


------------------------------------------------------------------------------------Matt Welsh, Autor eines der ersten Bücher über GNU/Linux, Running Linux und damals Undergraduate-Student an der Cornell University, war typisch fur diese zögerlichen PC-User. Er sagt: „Am Anfang war ich sehr skeptisch, was Linux betraf. Ich hatte ein schönes Setup mit MS-DOS und den meisten der GNU-DOS-Utilities installiert" Versionen von Stallmans GNU-Programmen, die so portiert worden waren, dass sie auf MS-DOS liefen, „sodass sich meine DOS-Maschine ein bisschen wie ein Unix-System verhielt Warum sollte ich das alles wegwerfen und mich mit diesem unausgegoren, kaum funktionierenden Unix-Klon herumschlagen?" Der Grund, warum Sladkey den Schritt schließlich wagte, war einfach. „Die Vorstellung eines freien Compilers in der Qualität von GCC, das zu der damaligen Zeit bereits gut etabliert war, und eines freien Hosting-BS [Betriebssystem], das eine vollwertige Unix MultitaskingUmgebung unterstützen würde, war sehr verlockend. So verlockend, dass ich sie ausprobieren musste, um zu sehen, ob sie real war", sagt er. Trotz dieser Attraktivität entschloss sich Sladkey, MS-DOS auf seiner Maschine installiert zu lassen, was auch Linus gemacht hatte. Sladkey konnte ebenfalls nicht umhin festzustellen, dass „Linux von der allerersten Installation an weit stabiler war als mein ebenfalls installiertes Windows 3.1 neben MS-DOS 5" Wieder hatte Stallmans GCC eine Schlüsselrolle bei der Annahme von Linux gespielt. Weniger offensichtlich war, dass das „freie HostingBS", auf das sich Sladkey bezog, aus Linux plus mehreren anderen unverzichtbaren GNU-Programmen bestand. Im Endeffekt konnte Linux die Lücke schließen, die der lang verzögerte Hurd-Kernel im GNU-Projekt hinterlassen hatte. So konnte es Stallmans Traum eines vollständigen und freien Unix-Klons erfüllen. Statt nur als „Linux" könnte man das resultierende Betriebssystem richtiger als „GNU/Linux" beschreiben, um beide Komponenten zu erwähnen. Welsh erinnert sich, dass er, als er GNU/Linux schließlich installierte, „ebenfalls vom Fieber befallen wurde. Es ging darum, dass man nun Dinge selbst machen konnte", erklärte er. „Man

4. Der Faktor X

--------------------------------------------------------------------------------------konnte neue Features hinzufügen und ständig mehr darüber lernen, wie Computer und Betriebssysteme funktionieren." Sladkey ist ein gutes Beispiel für die praktischen Vorteile des „Selbstmachens", und er zeigt, warum GNU/Linux bereits in diesem frühen Stadium Vorteile gegenüber Windows hatte. „Es gab durchaus Bugs", erinnert er sich, „aber der wesentliche Unterschied lag in ihrer Offensichtlichkeit, ihrer Wiederholbarkeit und der Möglichkeit Bugs selbst zu beheben. In dieser Umgebung waren Bugs nur vorübergehende Verzögerungen für etwas, was ansonsten exzellent und stabil war." „Windows hingegen", fährt er fort, „war schrecklich unzuverlässig. Es wurde von mysteriösen Abstürzen und unerklärlichen Hängern heimgesucht und zeichnete sich durch eine Fragilität aus, die es einem austrieb, auch nur mit den beworbenen BS-Features irgendetwas Ausgefallenes zu tun. Man erkannte bald, dass es der Belastung nicht standhalten würde. Die einzige Möglichkeit, Windows stabiler zu machen, bestand darin aufzuhören, Dinge zu tun. Anderenfalls musste man sich bis zur Erschöpfung mit der Konfiguration herumschlagen und dann einfach warten und sehen, ob sich etwas verbesserte oder nicht." Sladkey erinnert sich an das erste Mal, als er in Linux einen Bug fand und Linus auf ihn aufmerksam machte. „Mein erster Beitrag bestand darin, irgendein Programm zu portieren, wahrscheinlich eines meiner kleineren persönlichen Projekte. Ich entdeckte einen Bug. Da Linux mit Quellcode geliefert wurde, warf ich als Hacker zunächst einmal einen Blick unter die Oberfläche und sah nach, ob ich das Problem nicht lösen konnte. Ich stellte fest, dass ich, obwohl ich noch nie mit einem Kernel gearbeitet hatte, ziemlich gut in der Lage war, in dem Code zu navigieren und einen kleinen Patch zur Behebung des Bugs zu schreiben. Mit klopfendem Herzen und schweißnassen Händen schrieb ich die professionellste Nachricht, die ich zustande brachte, und sandte sie an [email protected]. Darin beschrieb ich den Bug und machte einen Vorschlag zu seiner Behebung. Minuten später antwortete Linus etwa: 'Ja, das ist ein Bug. Gut untersucht. Danke. Behoben.' Ich war hingerissen"


------------------------------------------------------------------------------------Diese Ereignisse sind charakteristisch für die gesamte Entwicklung von Linux. User, die ein Programm verwenden - vielleicht ein außergewöhnliches, das bislang unvermutete Probleme offen legt -, stoßen auf Bugs. Betriebssystemcode kann so gestaltet werden, dass er gut mit den meisten gängigen Programmen funktioniert und trotzdem weitere subtile Bugs enthält, die erst mit dem Lauf der Zeit ans Licht kommen. Da Linux mit dem Quellcodc geliefert wird (im Gegensatz zu MS-DOS oder Windows, die nur als „Black Boxes" verkauft werden, die nicht geöffnet werden können), kann sich ein Hacker im Inneren des Programms umtun. Egal welche Vorbehalte einige Minix-User gegen die Qualität des Linux-Code gehabt haben mögen: Er war so geschrieben, dass Hacker Probleme finden und die Ursache dieser Probleme beheben konnten. Dank Internet konnten die Lösungen dieser Probleme direkt an Linus gesendet werden, der das Medium auf dieselbe Weise für seine Antwort verwenden konnte. Manchmal dauerte der ganze Vorgang nur ein paar Minuten. Linus' eigene Offenheit für das Debuggen und die Tatsache, dass er seinen Code nicht zu schützen versuchte, war an der Durchführbarkeit dieses Prozesses maßgeblich beteiligt. Linux erklärt seine Einstellung zu diesen frühen Problembehebungen. „Sie begannen so klein, dass in mir nie das Gefühl entstand: Wie können sie es wagen, an meinem System herumzu-pfuschen. Stattdessen sagte ich mir, o.L, das stimmt, offensichtlich haben sie Recht, und so flössen die Beiträge [in den Kernel] ein. Das nächste Mal war es viel leichter, denn damals gab es nicht besonders viele Leute, die sich damit beschäftigten, und so lernte ich die Leute, die mir die Änderungen sandten, mit der Zeit kennen. Auch hier breitete sich das Ganze schrittweise aus, und deshalb hatte ich zu keiner Zeit das Gefühl, die Kontrolle zu verlieren." Diese vernünftige Einstellung spricht Bände über den Reifungs-prozess, den Linus seit seinen frühen und etwas pubertären Ausbrüche gegenüber der Minix-Newsgroup durchgemacht hatte. Die Tatsache, dass er nun angedeutete Kritik so freundlich entgegennahm, zeigte, dass nicht nur Linux seit 1992 Fortschritte gemacht hatte.

4. Der Faktor X

--------------------------------------------------------------------------------------Auch Sladkeys Erfahrung ist ein gutes Beispiel für die Vorteile, die diese Offenheit für Vorschläge brachte. Wie er erklärt: „Ursprünglich behob ich Bugs überall, wo ich sie fand. Ich fand ein Problem, erforschte es, überlegte, welches Verhalten wünschenswert war, behob das Problem, testete meine Lösung und schickte dann eine Beschreibung des Bugs mit dem von mir für den Kernelcode angefertigten Patch." Obwohl das Suchen und Beheben von Bugs eine extrem nützliche Tätigkeit war, tat Sladkey bald mehr: „Ich wurde Linux gegenüber immer loyaler, und deshalb war jede negative Publicity über einen Bug oder ein fehlendes Feature genügend Motivation für mich, einem Problem auf den Grund zu geben und es zu beheben. Das tat sich auch dann, wenn es mich nicht persönlich betraf, weil ich dieses Feature des Betriebssystems überhaupt nicht verwendete." Gipfel dieses Altruismus war seine Arbeit am Network File System (NFS). Obwohl Sladkey das NFS als „altes und hirnverbranntes Protokoll" - ein Protokoll ist nichts anderes als eine Gruppe von Regeln - beschreibt, „dessen Nutzen hauptsächlich in der Verbindung mit veralteten Unix-Systemen bestand", hatte es für ein Unix-artiges Betriebssystem einen wichtige Vernetzungskapazität zu bieten. „Ich schrieb den NFS-Client" - die Software, mit der ein Benutzer auf ein Unix-System zugreifen kann, das den NFS-Server verwendet - „zum Teil als Herausforderung für mich selbst." Bemerkenswerter ist, dass er ihn, wie er sagt, zum Teil deshalb schrieb, „ weil die Leute, die Linux kritisch gegenüber standen, das Fehlen des NFS als Fehler betrachteten", der gegen das System seiner Wahl ins Treffen geführt werden konnte. ,Als ich meinen NFS-Client das erste Mal auf der Kernel-Mailingliste ankündigte, gab es großes Interesse", erinnert sich Sladkey. „Viele Leute waren bereit, den ersten Alpha-Code auszuprobieren, weil sie dieses Feature unbedingt haben wollten." Auf viele Benutzer zurückgreifen zu können, „war ein ganzes Modell, das in der Minix-Wclt entwickelt und von Fehlern befreit worden war", erklärt Tanenbaum. Dass Linus selbst sich dessen früh bewusst war zeigt sein Posting an die Minix-Newsgroup vom


------------------------------------------------------------------------------------19. Dezember 1991. Darin ging er auf die Vor- und Nachteile von Minix und Linux ein und stellte fest, dass „Minix immer noch viel mehr Benutzer hat", und das bedeutete, dass Minix „bessere Unterstützung" genoss als Linux. Linus merkte an, dass sein Kernel „noch nicht jahrelang von Tausenden Leuten getestet worden ist, und dass er deshalb wahrscheinlich noch einige Bugs hat" Als Linus später eine weitere Version des Kernels vorstellte, brachte er eine Bitte vor, die inzwischen zu einer Standardbitte geworden war: Bitte probiert alles aus, setzt es ein, wie ihr wollt, und schickt mir Kommentare/bugs-reports an meine Adresse. Die Änderungen sind etwas umfangreicher, als es mir lieb wäre. Deshalb können wir versuchen, eventuelle Probleme umso schneller zu lösen, je mehr Tester es ausprobieren." Je besser Linux wurde, desto mehr Leute verwendeten es; und je mehr Leute mit dem Debuggen beschäftigt waren, desto schneller wurde es besser: ein positiver Kreislauf, der immer noch bewirkt, dass Linux sich in einem Schwindel erregenden Tempo ausbreitet. Linux nutzte das, was man „Minix-Methode" nennen könnte, besser als Minix, weil Tanenbaum dafür sorgte, dass sein Betriebssystem nur langsam und nur auf bestimmte Weise wachsen konnte. Linus war bereit Verbesserungen an seinem Kernel anzunehmen und sie sogar zur Grundlage einschneidender Veränderungen zu machen, wie Sladkeys Erfahrung mit NFS zeigen sollte. „Der NFS Client Patch etablierte sich schnell als ein nützlicher, wenn auch nicht allzu schneller Zusatz zum Linux-Kernel", erklärt Sladkey. „Ich war zu schüchtern, um den Patch direkt an Linus zu schicken, aber jemand anderer schlug Linus vor, ihn zu integrieren, und so trat Linus an mich heran und fragte mich, ob er meinen Patch in den Hauptkernel integrieren könne," Linus war immer offen für die Bitten der Benutzer. Er sagte später: „Ich mochte die Einstellung ,Von Hackern, für Hacker´ eigentlich nie." Dabei hatte er dies zum ursprünglichen Konzept von Linux gemacht, vielleicht um die Minixgemeinde auf seine Seite zu ziehen, „Ich wollte immer, dass Linux für die Benutzer da sein sollte."

4. Der Faktor X

--------------------------------------------------------------------------------------Sladkey sagt, dass der NFS-Code, als Linus nach ihm fragte, einfach blind in den Kernel hätte integriert werden können, da er von vielen Leuten erfolgreich verwendet wurde und deshalb die meisten Bugs eliminiert waren. „Aber Linus evaluierte meine Patches und schlug vor, einige Dinge anders zu machen, bevor er sie in seinen Quellcode einfügte. Ich hatte einige vorsichtige Änderungen an anderen Teilen des Kernels vorgenommen, gerade ausreichend für das, was ich brauchte", sagt Sladkey. „Ich hatte Größe und Ausmaß dieser Änderungen absichtlich so klein wie möglich gehalten. Nach Meinung von Linus gab es bessere, invasivere Möglichkeiten zur Unterstützung der neuen Features - das Richtige - die der einfachen Vermeidung von Bugs - dem Einfachsten - vorzuziehen waren". „In meinem Fall verbesserte Linus also den Kernel so, dass er und ich auf kurze Sicht mehr Arbeit hatten, was den Kernel aber auf lange Sicht klarer, sauberer und wartungsfähiger machte. Diese Lektion, den schweren Weg zu wählen und die Dinge von Anfang an richtig zu machen anstatt den Weg des geringsten Widerstands zu gehen, machte zu dieser Zeit großen Eindruck auf mich und wurde in der Folge zu einem wichtigen Bestandteil meiner Programmierphilosophie.' Linus' Entscheidung in diesem Fall war wichtig und typisch. Wenn man ihm einen Code vorlegte, der den Kernel um wichtige neue Funktionen erweiterte, integrierte er ihn nicht auf die schnellstmögliche Weise. Stattdessen verwendete er die Erkenntnisse aus dem neuen Code dazu, den bestehenden Kernel für zukünftige neue Entwicklungen zu erweitern und zu stärken. Obwohl das mehr Arbeit bedeutete, stärkte es nicht nur die Arbeitsgrundlage, sondern trug (im Gegensatz zu vielen kommerziellen Softwareprogrammen, die durch das Hinzukommen neuer Features immer spaghettiartiger und überladener wurden) dazu bei, dass die Struktur von Linux immer besser wurde, je mehr solcher Funktionen hinzugefügt wurden. Denselben Ansatz verwendete Linus für den Port von Sladkey von GNU Emacs für GNU/Linux, einen wichtigen Zusatz zur Applikationssammlung. Sladkey beschreibt dies als „ein klassisches Beispiel für die Schwächen und die Inkompatibilitäten von Linux,


------------------------------------------------------------------------------------die weniger durch das Portieren des Programms an den Host, sondern eher durch die Anpassung des Host bekämpft wurden, was bedeutete, dass am Programm weniger Änderungen vorgenommen werden mussten". Linus hatte sich früh für diesen Ansatz entschieden, „ich holte sogar GNU-Quellen aus dem Netz und kompilierte sie unter Linux. Dann überprüfte ich, ob sie so arbeiteten, wie ich es wollte, obwohl ich sie nicht persönlich verwendete", erinnert er sich. „Nur um sicherzugehen, dass ich diesen Teil richtig hatte." Damit baute er wieder auf der jahrelangen Arbeit von Richard Stall man auf. Stallman hatte sich zur Entwicklung eines Unix-artigen Systems entschlossen, das in keiner Weise auf AT&T-Quellcode basierte. Stattdessen verwendete er die Features von Unix als Vorlage und implementierte sie eigenständig. Da er so erfolgreich war, wurde die GNU-Programmsuite zu einem Testfeld für die Kompatibilität des Unix-Kernels, an der Linux gemessen werden konnte, ohne dass die teure kommerzielle Unix-Software verwendet oder, was ebenso wichtig war, gekauft werden musste. Dieser Ansatz, den Kernel so anzupassen, dass er allen Applikationen gerecht wurde, zahlte sich bestens aus, als es ans Portieren eines der später strategisch wichtigsten Zusätze zum Portfolio der GNU/LinuxProgramme ging: des X-Window-Systems. Für Drew Eckhardt, der Linux seit den Anfangszeiten verfolgte, stellte die Einführung von X einen der drei wichtigsten Meilensteine in der Geschichte von Linux dar. Die beiden anderen waren die Virtual Memory (VM)-Fähigkeit, die Linus im Dezember 1991 hinzugefügt hatte, und die Vernetzung. Zuerst war Linux durch eine einfache Shell wie GNU Bash kontrolliert worden. Das war einer der Gründe, warum das gesamte Betriebssystem GNU/Linux genannt wurde. Diese Shell funktioniert eher wie MS-DOS: Der User gibt Befehle ein, die den Kernel veranlassen, auf eine bestimmte Weise zu reagieren. Die Welt von Apple Macintosh oder Microsoft Windows in der damaligen Version 3.1 stand im völligen Gegensatz dazu. Hier erfolgte die Kontrolle durch die Auswahl von Optionen in Pull-down-Menüs aus verschiedenen überlappenden Fenstern auf dem

4. Der Faktor X

--------------------------------------------------------------------------------------Bildschirm, oder direkter durch das Anklicken grafischer Symbole auf dem Bildschirm. Viele Jahre lang hatte sich Unix durch einen ähnlichen grafischen Grundansatz ausgezeichnet. Der Name X kam daher, dass es sich um den Nachfolger eines Fenstersystems namens Windows und eine Standardkomponente kommerzieller Unix-Programme handelte. Im Gegensatz zu den Macintosh- oder Microsoft-Windows-Systemen bestand sein Hauptzweck nicht darin, die Kontrolle zu erleichtern (X selbst hatte weder Menüs noch Symbole), sondern darin, das gleichzeitige Ansehen und Kontrollieren mehrerer Programme durch mehrere X-Fenster zu ermöglichen, die zur selben Zeit offen waren. Sobald GNU/Linux mehr anzubieten hatte als die grundlegendsten Unix-Funktionen, katapultierte sich X auf der Wunschliste vieler User weit nach oben. Da Linus aber alle Hände voll mit der Verbesserung des Kernels zu tun hatte und Windowing-Systeme in Unix-Systemen nicht Teil des Kernels sind (im Gegensatz zu Microsoft Windows, wo die grafische Schnittstelle fest in den grundlegenden Betriebssystemcode integriert ist), musste jemand anderer einspringen. Die Linux-Bewegung hatte - und hat - keine formelle Hierarchie, über die wichtige Aufgaben wie diese verteilt werden können. Eine scheinbare Schwäche, die eigentlich eine Stärke ist. Stattdessen findet eine Art automatischer Selektion statt: Jeder, dem es wichtig genug ist, ein bestimmtes Programm zu entwickeln, kann es versuchen. Da diejenigen, die hier das größte Interesse zeigen, oft auch die Fähigsten sind, produzieren sie hochwertigen Code. Wenn sie erfolgreich sind, wird ihre Arbeit aufgegriffen. Aber auch wenn sie scheitern, kann jemand anderer ihre Arbeit aufgreifen oder einfach von vorn beginnen. Und so kam es, dass Orest Zborowski Anfang 1992 begann, X für GNU/Linux zu portieren. Dirk Hohndel, der später die Verantwortung für den ganzen X Bereich für Linux übernahm, erklärt, dass „es nicht allzu schwer war, X zu portieren, da X von sich aus ganz gut portierbar ist. Der Großteil der Arbeit, die [Zborowski] leistete, bestand darin, den Linux-Kemel um zusätzliche Features zu erweitem." Um dieses wichtige Feature für Systeme, die mit dem


------------------------------------------------------------------------------------Linux-Kernel arbeiteten, verfügbar zu machen, war Linus ein weiteres Mal bereit, Änderungen zu akzeptieren. Aber im Gegensatz zu anderen Ports fur Linux wurde X bald Teil eines großen unabhängigen Softwareprojekts, das in seinen Ursprüngen und darauf folgenden Entwicklungen interessante Parallelen zu Linux aufwies. Der X Window Standard wurde vom X Consortium gemanagt, einer Körperschaft, deren Ziel es war, angesichts der vielen Spaltungen in der Unix-Welt zumindest das Windowing zu vereinheitlichen. Um sicherzustellen, dass kein Hersteller unfaire Vorteile aus seiner Arbeit zog, wurden die X Window Standards unter der MIT X Lizenz frei verfügbar gemacht, was bedeutete» dass man mit dem Code praktisch alles anstellen konnte, was einem einfiel. Das war eine gute Nachricht für alle, die außerhalb des Consortium standen, weil es bedeutete, dass sie den Code für X verwenden und ihn an andere Plattformen portieren konnten. So hatte zum Beispiel Thomas Roell den X386 entwickelt, der für Unix auf dem Intel 80386 ausgelegt war, jenem Chip, den Linus in seinem PC hatte. „Alle sagten, dass die Intel-Unix-PCs nur Spielzeug sein würden", erinnert sich Roell, „aber ich legte Wert auf die Grafik." Großzügig stellte Roell die aktualisierte Version seines Code, X386 1.2, dem X Consortium für die Aufnahme in die nächste Version von X Window, X11R5, die im Oktober 1991 herauskam, zur Verfugung, Einer der User von X386 1.2 war David Wexelblatt. Er erinnert sich, dass „der X11R5-Server im Grunde selbst voller Bugs war, ein riesiger Schritt rückwärts gegenüber dem X11R4-Zeug". Noch bedauerlicher war laut Wexelblatt, dass Roell „das [X386Server-] Zeug kommerzialisiert hatte, [so-] dass es keine freien Verbesserungen mehr geben würde, mit denen er diese Probleme beheben konnte." Die Folge war, dass Wexelblatt gemeinsam mit einer Gruppe anderer Leute begann, eigene Patches für den X386-Server zu schreiben. Zwei von ihnen, „Glenn Lai und Jim Tsillas", erinnert sich Wexelblatt, „arbeiteten beide unabhängig voneinander an den Leistungsproblemen", einer der Hauptbereiche, der Patches für den

4. Der Faktor X

--------------------------------------------------------------------------------------X386-Code erforderte. „David Dawes in Australien", fährt Wexelblatt fort, „hatte begonnen, an einigen der verschiedenen anderen Bugs des R5-Servers zu arbeiten, und er verteilte ebenfalls Patches." Mittlerweile arbeitete Wexelblatt an seiner eigenen Lösung. „Und wir waren alle dort draußen, wir taten alle diese Dinge und veröffentlichten über das Netz winzige Teile und Bruchstücke", sagt er und bezog sich dabei auf die Usenet-Newsgroups, die zu dieser Zeit allgemein für die Weitergabe von Code verwendet wurden. „Nachdem ich das ein paar Wochen lang gemacht hatte, hatte ich die brillante Idee: Das ist wirklich dumm, da gibt es vier Leute, die diese Arbeit machen, und manches davon arbeitet gegeneinander und manches überschneidet sich - warum tun wir uns nicht alle zusammen und produzieren ein einheitliches Paket?" „Wir begannen im April "92", erinnert sich Wexelblatt. Einen oder zwei Monate später fingen sie an, ihre kombinierten Patches zu veröffentlichen. „Wir nannten das, was wir herausbrachten, einfach X386 1.2e", eine verbesserte Version des damaligen X386 1.2. Danach benannten Wexelblatt und seine Hackerkollegen ihre Software um: Die meisten Leute heute wissen es nicht [merkt Wexelblatt an], aber dieses Ding hier entwickelte sich aus dem X386, der kommerzialisiert worden war. Da wir uns mit Freeware beschäftigten, nannten wir unser Projekt Xfree86. Wir hatten eigentlich zu dieser Zeit keine großen Pläne. Aber als wir mit diesem Debuggen fertig waren, begannen Wünsche nach anderen Dingen bei uns einzutrudeln. Wie etwa: Wir brauchen einen Treiber für diese Videokarte, oder da gibt es dieses Betriebssystem, das unterstützt werden sollte. Zu dieser Zeit, etwa im Juni oder Juli 92, begannen die Linux-Leute sich mit uns zu unterhalten. In der Linux-Community schien von Anfang die Philosophie zu herrschen, nun, da wir dies von der Pike auf definieren, können wir es ebenso gut nach dem definieren, was einem Standard möglichst nahe kommt. Diese Anpassung des Kernels an Standards machte es der Xfree86Gruppe viel leichter, GNU/Linux zu unterstützen. Außerdem stellte


------------------------------------------------------------------------------------sie eine Fortsetzung des Ansatzes dar, für den sich Linus bei der Modifikationen seines frühen Kernels entschieden hätte, um die Kompatibilität mit der GNU Software zu verbessern. Die Beziehung zwischen den Xfree86- und GNU/Linux-Bewe-gungen wurde auf positive Weise symbiotisch: Xfree86 für GNU/ Linux hatte Letzteres attraktiver gemacht und ihm mehr Benutzer gebracht während die Ausbreitung der Systeme auf GNU/Linux -Basis Xfree86 die perfekte, freie Plattform bescherte. Dirk Hohndel erinnert sich, darüber mit Linus gesprochen zu haben: „Wir unterhielten uns über die Synergie zwischen beidem. Xfree86 wäre ohne Linux niemals zu dem geworden, was es ist. Und umgekehrt." Dass dieses Xfree86 just zu der Zeit entstand und florierte, als Linux entwickelt wurde und wuchs, ist kein Zufall. Beide Systeme verdankten ihren Aufstieg der Kostensenkung bei den PCs, die dem Intel Chip 386 zu verdanken war. Als Antwort auf ein Posting in comp.os.minix im Dezember 1992, in dem der Autor geschrieben hatte: „Ich habe nie einen 386 verwendet. Und ich werde nie einen verwenden, wenn mir nicht eine Pistole an den Kopf gesetzt wird", schrieb Linus: Da entgeht dir etwas. Ich programmierte eine 68k-Maschine [einen Sinclair QL, der den Motorola-Chip 68008 hatte], bevor ich mir einen PC anschaffte, und ja, ich hatte mir einige Sorgen über die IntelArchitektur gemacht. Das Ganze erwies sich als o.k., und, was wichtiger war: Es ist das Billigste, das es überhaupt gibt. Minix hatte auf dem früheren 8086-Chip erfolgreich einen Unix-Klon geschaffen, dem aber einige Features fehlten, wie zum Beispiel Virtual Memory, das Feature, das Linus vor Weihnachten 1991 in einigen Tagen geschrieben hatte, oder irgendein X Window Port. Und obwohl es 386-Minix gab, war Tanenbaum nicht bereit, es so weit entwickeln zu lassen, dass es seinen Wert als Lehrmittel verlor, denn damit hätte es seine Eignung als Lehrmittel verloren. So waren viele Minix-User frustriert und nur allzu gern bereit, auf ein beweglicheres und ambitionierteres Projekt wie GNU/Linux umzusteigen, als es sich anbot.

4. Der Faktor X

--------------------------------------------------------------------------------------Ein Teil des Erfolgs von GNU/Linux kann daher der Hardware zugeschrieben werden, die stark genug war, um die Annahme der vollständigen Unix-artigen Features zu ermöglichen, und doch so billig, dass viele Leute sie kaufen konnten. Die Einführung des 386-Chip reichte in keinem Fall aus, um die GNU/Linux-Revolution in Gang zu bringen. Das zeigte sich an der Geschichte des 386BSD, eines weiteren freien Unix-Betriebssystems, das entwickelt worden war, als Linux auf den Plan trat, um die Leistungsfähigkeit des Intel-Chips zu nutzen. Das Projekt war von Bill und Lynne Jolitz ins Leben gerufen worden. Die Idee war, die höchst beliebte Unix-Variante von Berkeley Systems Distribution (BSD), die an der University of California in Berkeley entwickelt worden war, an den PC zu portieren und auf diese Weise den Bedürfnissen von eingefleischten Berkeley-Fans gerecht zu werden. Sie bombardierten Tanenbaum täglich mit Hunderten E-Mails, um ihn dazu zu bringen, Minix zu etwas Ähnlichem zu machen. Der Linux-Hacker aus Anfangszeiten, Richard Sladkey, sagt, dass er eine Zeit lang überlegte, welches System er installieren sollte: „Ich las sowohl die Linux- als auch die 386BSD-[News~] groups. Die meisten, die in irgendeiner Weise mit Unix vertraut waren, wussten, dass [der weithin verwendete Editor] vi und das Networking aus Berkeley kamen und nicht von AT&T. Deshalb nötigte einem das Akronym BSD automatisch Respekt ab. Eine Menge Leute nahmen einfach an, dass der 386BSD das Rennen machen würde [vor GNU/Linux]. Linus sagt: „Ich wusste von Jolitz von dem 386BSD-Projekt, weil er darüber in Dr Dobb's [Journal] geschrieben hatte." Dabei handelte es sich um eine umfangreiche Artikelserie, die ab Januar in diesem Magazin - der damaligen fuhrenden Publikation für Programmierer erschien. Linus sagte 1992 zu Linux News, dass „386BSD mir einige Ideen gebracht hat", räumt aber ein, „wenn 386BSD ein Jahr früher herausgekommen wäre, hätte ich wahrscheinlich nicht mit Linux begonnen. Aber es verzögerte sich, und dann verzögerte es sich wieder. Zu dem Zeitpunkt, an dem es dann wirklich herauskam, hatte ich bereits ein System, das für mich funktionierte. Und zu dieser Zeit war ich schon so stolz darauf, dass


------------------------------------------------------------------------------------es von mir war, dass ich nicht mehr umsteigen wollte." Darüber hinaus, so meint er, „hatte ich bereits einige User, vielleicht ein paar hundert" Das war Anfang 1992. Zusätzlich zu der Verzögerung gab es noch eine Reihe anderer Faktoren, die dafür sorgten, dass GNU/Linux in seinem Kampf um Benutzer wichtige Vorteile hatte. Sladkey erinnert sich, dass „Linux zu Multibooting mit anderen Betriebssystemen fähig war, während 386BSD eine ganze Festplatte benötigte, [die so formatiert war], dass sie nicht mit [MS-DOS kompatibel war. Ich entschied mich schon aus diesem Grund für Linux, weii ich mir keinen zweiten Computer leisten konnte." In Anbetracht der enormen Zahl der Geräte, auf denen MS-DOS installiert war, war Sladkey sicher nicht der Einzige, der auch DOSProgramme verwenden wollte. Der 386BSD-Ansatz kostete zweifellos Benutzer, vor allem, als Microsoft Windows nach der Veröffentlichung von Version 3.1 an Beliebtheit gewann. Es ist ironisch zu sehen, wie der Erfolg von Microsoft am Desktop dazu beitrug, dass GNU/Linux schon früh Fuß fassen konnte. Andere waren abgeschreckt, weil 386BSD einen leistungsstärkeren PC erforderte als GNU/Linux. Lars Wirzenius erinnert sich, dass 386BSD „einen 387 Coprozessor brauchte, den ich nicht hatte. Also gab es für mich überhaupt keine Möglichkeit, dieses System auch nur in Betracht zu ziehen." Der Intel 80387 war ein Mathematik-Koprozessor, der gemeinsam mit dem 80386 verwendet wurde, um die numerischen Routinen zu beschleunigen. Linus hatte sich im Gegensatz dazu entschieden, den 387 in Software zu emulieren (oder zumindest einen Teil davon; die volle Kompatibilität mit dem 387 wurde von dem Australier Bill Metzenthen erreicht). Das bedeutete, dass Linux-User den damals kostspieligen 387er-Chip nicht anzuschaffen brauchten. Wieder einmal - sei es durch Glück oder Intuition - traf Linus lauter richtige Entscheidungen. Dazu kam, dass der 386BSD noch von einer rechtlichen Wolke überschattet war. Sladkey erklärt, dass „zur damaligen Zeit ein Rechtsstreit zwischen AT&T und Berkeley tobte". Gegenstand dieses Rechtsstreits war die Frage, ob BSD Unix urheberrechtlich geschütztes Material des AT&T Unix enthielt. „Und obwohl alle im Usenet für UCB [University of California at Berkeley, die Eigentü-

4. Der Faktor X

--------------------------------------------------------------------------------------merin von BSD war] waren", war man besorgt, dass möglicherweise einige undurchsichtige Dinge passiert waren, „und selbst wenn das nicht der Fall gewesen war", wie Sladkey sagte, würde „AT&T wahrscheinlich gewinnen, was alles, was von BSD abgeleitet war, infrage stellen würde", und dazu gehörte auch der 386BSD. „Also erwiesen sich diese rechtlichen Zweifel über das Ergebnis des Verfahrens als positiv für Linux, das eine saubere Implementierung war", fugte er hinzu. Sladkey ist der Meinung, dass Linux alle Vorteile, die es zur damaligen Zeit hatte, nur zu gut gebrauchen konnte, „weil BSD ein vollständiges Betriebssystem war, das nur [an den 386] portiert zu werden brauchte, während Linux ein Kernel war, der auf der Suche nach ein paar guten Utilities war, die ihm das Ansehen eines echten Betriebssystems geben würden". Diese Utilities sollten im Großen und Ganzen vom GNU Projekt beschafft werden. Linus bestätigte diese Sichtweise im Interview in Linux News. Über den 386BSD sagte er: „Es ist ein bisschen beängstigend, dass das große und bekannte Unix eine ähnliche Nische wie Linux füllt." Es bestand also die Möglichkeit, dass 386BSD den Sieg über GNU/Linux davontragen würde, sobald der Port fertig war und der Preis des 387er-Chip sank. Aber wie Sladkey anmerkt: „Nachdem ich mich mit Linux zu beschäftigen begonnen hatte, las ich weiterhin beide Newsgroups, und es wurde mir klar, dass ich die richtige Entscheidung getroffen hatte. Neue Versionen [von 386BSD] kamen nur selten heraus, und Patches schafft es nicht zu vollständigen Versionen, wenn es überhaupt welche gab" Drew Eckhardt bestätigt diese Sichtweise: „Bill Jolitz kümmerte sich nicht um die Bedürfnisse der User. Er sagte: ,Dies hier ist ein Forschungssystem' und meinte: Wir akzeptieren keine Patches, und es muss auf niemandes Hardware funktionieren, während Linus sehr wohl Patches akzeptierte. Ich schickte ihm welche und hatte binnen Stunden eine Version." Ein Großteil des Erfolgs von Linux ist direkt auf die charakterlichen Eigenschaften von Linus und seine Art der Projektführung zurückzufuhren. Wichtig war, dass er die Leute ermutigte, Patches einzusenden, und dass er bereit war, sie zu akzeptieren. Günstig wirkte sich auch seine flexible Einstellung zu Projekten wie


------------------------------------------------------------------------------------Xfree86 aus. Neben seiner Offenheit hatte sich Linus auch eine neue Art der Veröffentlichung von Updates angeeignet, die zu einem Markenzeichen von Linux wurden und zu seiner rasanten Verbesserung beitrug. Im Gegensatz zu den „seltenen" Versionen von 386BSD beschleunigte Linus den Revisionszyklus so, dass mehrere Versionen pro Monat heraus kamen, manchmal mehr als eine pro Woche. Eine von Riley Williams verfasste Versionsgeschichte des LinuxKernels gibt auch die komprimierte Größe aller Dateien innerhalb dieser Version an. So war zum Beispiel der letzte Datumsstempel von Version 0,01 des Kernels Dienstag, 17. September 1991, 17.30 Uhr. Die Größe des komprimierten Kernels betrug rund 63 Kilobyte (zum Vergleich: der Code von Windows 2000 hat zig Millionen Byte). Die Kernelversion, die „es schaffte", wie Linus es ausdrückte, Version 0.12, erschien Anfang Januar 1992 und war fast doppelt so groß wie die Vorgängerversion, nämlich 108K. Trotz des großen Sprungs in der Versionsnummer ist Linux 0.95 mit 116K nicht viel größer, aber es gibt eine bemerkenswerte Lücke im Zeitstempel: Die letzte Datei stammt vom 8. März 1992. Der Grund ist nicht schwer zu erraten: In dieser Zeit fiel der „Linux-ist-obsolet'-Streit, und die Lücke repräsentiert möglicherweise einen Augenblick des Innehaltens von Seiten Linus', der eine Bestandsaufnahme der Situation vornahm und sich auf die Entwicklung von Linux 1.0 vorbereitete. Das Tempo wurde immer schneller. Nach Version 0.95 gab es einige geringfügigere Updates mit amüsanten Versuchen, die richtigen Abstufungen zu finden. Auf Version 0.95 folgt 0.95a und dann 0.95a.a. Zwischen 0.95c und 0.96a liegen 0.95c+ und pre0.96. Version 0.96a, deren letzter Datumsstempel der 25. Mai 1992 ist, fällt als erste Version auf, die Kernelunterstützung für X beinhaltet. Das war ein ebenso wichtiger Sprung wie es die Vergrößerung des komprimierten Kernels von 131K auf 174K gewesen war. In einem Posting an comp.os.minix am 27. April hatte Linus erwähnt, dass X „bereits funktioniert, aber noch nicht für den .Massenmarkt verfügbar ist". Einen Monat später war es draußen. Danach ging Linus in Sommerurlaub. Er war wieder voll im Hackermodus, wie er es zwölf Monate davor gewesen war, als er

4. Der Faktor X

--------------------------------------------------------------------------------------Linux zu codieren begonnen hatte. Fünf Versionen tragen irgendeine 0.96-Bezeichnung. Sie kamen zwischen Mai und Ende Juni heraus. Version 0.96b erschien Ende Juni, zwei Tage später gefolgt von 0.96b.1, worauf nur zwei Tage später 0.96b.2 erschien. Im Juli und im August wurden jeweils drei Versionen veröffentlicht, und im September waren es nicht weniger als fünf. Sie kulminierten in Version 0.98, die eine komprimierte Größe von 320K hatte und damit mehr als viermal so groß war wie Version 0.01, die fast ein Jahr davor herausgebracht worden war. Diese Zahlen sollen verdeutlichen, wie viel Codierarbeit zu dieser Zeit in die Entwicklung von Linux gesteckt wurde, und vor allem das furiose Tempo, in dem neue Versionen herausgebracht wurden. Dieses Tempo war in der Geschichte der Softwareindustrie ohne Beispiel. Diese Codierwut hatte ihre Wurzeln zweifellos in der zunehmenden Entschlossenheit von Linus, Linux zu etwas zu machen, was nicht nur gleichwertig mit Minix war, sondern auch mit den kommerziellen UnixKernels. „Gefüttert" wurde das Projekt auch von den vielen Hackerkollegen, die ständig Vorschläge und Code beisteuerten. So wurde die Entwicklung noch weiter beschleunigt. Die ständige Veröffentlichung immer aktuellerer Kernels bedeutete, dass die Hacker immer mit dem neuesten Code arbeiten konnten, anstatt sich mit Problemen herumzuschlagen, die bereits gelöst waren. So konnten Duplikationen vermieden werden. Die Tatsache, dass immer der neueste Kernel zur Verfügung gestellt wurde, hatte auch die Nebenwirkung, die Codierer an das System zu binden. Sie hatten das Gefühl, Teil des Entwicklungsteams zu sein und fast täglich zu „Schnappschüssen" des Quellcodes Zugang zu haben. Wie die Entwicklung von NFS durch Sladkey zeigt, steigt die Wahrscheinlichkeit, dass Hacker wichtige Beiträge leisten, mit ihrem Zugehörigkeitsgefühl zu dem Projekt. „Bei Linux habe ich viele richtige Designentscheidungen getroffen", sagte Linus 1996, „aber die beste, die ich je traf, war die, es über FTP zur Verfügung zu stellen." Das bedeutet, dass die Entscheidung, den Code auf diese Weise zur Verfügung zu stellen, keinesfalls selbstverständlich war, wie sie es heute wäre, wo alles routinemäßig auf einen Netzserver hochgeladen wird.


------------------------------------------------------------------------------------Das Internet motivierte nicht nur Linus, sondern auch viele andere Hacker, die sich für seine Arbeit zu interessieren und an ihr teilzunehmen begannen. Dank Internet konnten Hacker auf der ganzen Welt am Linux-Projekt mitarbeiten und ein neuartiges verteiltes Entwicklungsmodells schaffen. Wie ironisch, dass das letzte wichtige Feature, das zum Linux-Kernel hinzugefugt wurde, die Unterstützung für TCP/IP war, jene Kommunikationsprotokolle, die dem Internet zugrunde liegen - der dritte von Eckhardts Linux-Meilensteinen. Und wie ironisch, dass die bis dahin eng zusammengeschweißte Linux-Gemeinde durch die Hinzufügung dieser Verbindungsfähigkeit Sprünge bekam.

5

Patches ohne Ende

ES MAG EIGENARTIG ERSCHEINEN, DASS LINUX, ein System, das im Internet geboren und groß geworden war, während der ersten achtzehn Monate seines Lebens keine Verbindungsfähigkeit zu diesem Medium hatte. Die Erklärung ist, dass Linux entstand, als das heutige Internet noch in den Kinderschuhen steckte, in einer Zeit, als sich das neue Medium eben erst anschickte, aus den wissenschaftlichen Sphären hervorzutreten und sich dem Mainstream zu öffnen. Diese Situation spiegelt sich in einem Kommentar von Andrew Tanenbaum aus der „Linux-ist-obsoler-Zeit wider. Am 3. Februar 1992 schrieb er: „Ich glaube, dass vielen nicht hinreichend klar ist, dass der Weg zu einer möglichst breiten Verteilung von etwas nicht unbedingt darin besteht, es über FTP verfugbar zu machen. Die Internetteilnehmer sind immer noch eine höchst elitäre Gruppe. Die meisten Computer sind NICHT ans Internet angeschlossen." Linus sagte im Gegensatz dazu: „Die


------------------------------------------------------------------------------------beste Designentscheidung, die ich je traf, war, das System über FTP verfügbar zu machen." Es konnte von einem in Helsinki stehenden, mit dem Internet verbundenen Server heruntergeladen werden. Tatsächlich kam Linux zum richtigen Zeitpunkt heraus, um das rasch anschwellende Interesse am Internet nutzen zu können. Der Grund, warum frühe Computer, die mit GNU/Linux betrieben wurden, nicht ans Netzwerk angeschlossen werden mussten, wird von Olaf Kirch erklärt, Autor von Linux Network Administrator's Guide und eine der Schlüsselfiguren der Linux-Netzwerkwelt. „Es waren ja schon alle im Internet", sagt er. „Ansonsten hätten sie sich nicht an der Entwicklung von Linux beteiligen können. Ich glaube, dass die meisten Leute an Universitäten arbeiteten und deshalb ohnehin eine ordentliche Verbindung halten." Dieser Kommentar wirft ein interessantes Licht darauf, wo und wie GNU/Linux in jenen frühen Tagen verwendet wurde. Nach Kirchs Ansicht arbeiteten die meisten Leute an Universitätscomputern, die über gute Internetverbindungen verfügten. Ihre GNU/Linux-Maschinen standen im Gegensatz dazu meist zu Hause, wo sie keine Internetverbindung hatten. Deshalb vermissten sie die TCP/lPFunktionen, die als eine Art Softwarebrücke zwischen Betriebssystem und Netzwerk fungierten, nicht. Dieses Bild bestätigt sich durch andere Berichte. So erinnert sich zum Beispiel ein Linux-Hacker der Anfangszeit. Alan Cox, aktualisierte Versionen von Linux beschafft zu haben, „indem ich mit einem Stapel Disketten zur Universität marschierte", um GNU/ Linux mithilfe der dortigen Internetverbindung herunterzuladen. „Dann kehrte ich mit dreißig Disketten nach Hause zurück, fütterte den PC damit und musste meist feststellen, dass drei von ihnen nicht funktionierten", was bedeutete, dass er zurückkehren und sich diese Dateien nochmals holen musste. Viel praktischer wäre es natürlich gewesen, sie direkt herunterzuladen. In einem Posting an die comp.os.minix Newsgroup am 21. September 1992 hatte Linus in seiner Antwort auf eine Frage über Linux eine Zusammenfassung des aktuellen Status des Systems gegeben. Drei wichtige Features wurden gerade hinzugefügt, waren aber zum Zeitpunkt des Postings erst als Patches verfügbar. Dabei

5. Patches ohne Ende

--------------------------------------------------------------------------------------handelte es sich um einen Treiber für die SoundBlaster-Soundkarte, die Multimedia unter Linux ermöglichte, eine Methode zum Lesen von CDROMs, die wichtig zur Erleichterung des Installieren der immer größer werdenden Palette von Linux-Software war, und TCP/IP-Unterstützung, die, wie Linus sagte, „in der nächsten größeren Version, die voraussichtlich nächste Woche herauskommen wird, enthalten sein wird". Die nächste Version war Version 0.98, die am 29. September erschien. Am 18. Oktober 1992 brachte Linus ein kleineres Update dieser Version namens 0.98.2 heraus. Darin waren „einige TCP/IP-Patches" enthalten. Linus machte jedoch darauf aufmerksam, dass „TCP/IP immer noch die Alphaversion ist" - ein frühes Entwicklungsstadium. „Sie wurde noch nicht umfassend getestet und ist wahrscheinlich noch nicht wirklich verwendungsfähig." In einem weiteren Posting an die comp.os.minix-Newsgroup vom 12. Dezember 1992 schreibt Linus als Antwort auf die xte Frage, ob Minix nun „viel besser sei als Linux": „Ganz klar: NEIN", und nennt einige Gründe. Am Ende muss er aber zugeben, dass 386BSD andererseits „ein reiferes Netzwerksetup hat, und auch den Vorteil, das 'echte McCoy' zu sein", da es vom ursprünglichen TCP/ IP-Netzwerkcode abgeleitet war, der in Berkeley geschrieben worden war. 38ESBSD war also immer noch eine Konkurrenz für GNU/Linux, was seinen Grund zum Teil in den überlegenden TCP/ IP-Fähigkeitcn dieses Systems hatte. Detailinformationen darüber, wie diese Fähigkeiten in Linux integriert wurden, finden sich in der Netzwerkanleitung für Linux, einem der vielen halb offiziellen Linux-Texte, die allgemein verfügbar sind; sie sind Teil einer enormen Menge freien, aber hochwertigen Materials, das von Freiwilligen rund um die Welt in einer gemeinsamen Initiative geschrieben wurde. Gemeinsam ist dieses Material als Linux Documentation Project bekannt. In der Netzwerkanleitung schreiben die Originalautoren Terry Dawson und Alessandra Rubini: „Der erste Freiwillige, der mit der Entwicklung des Netzwerkcodcs des Kernels begann, war Ross Biro. Ross produzierte einfache und unvollständige, aber im Großen und Ganzen verwendbare Implementierungsroutinen. Das reichte aus, um viele Leute dazu zu motivieren, mit der Software zu experimen-


------------------------------------------------------------------------------------tieren, und manche schafften es sogar, Maschinen mit dieser Konfiguration über lokale Netzwerke an das Internet anzuschließen". Olaf Kirch meint dazu, dass der Grund, warum sich die Linux-Hacker entschlossen, ihre Vernetzung selbst in die Hand zu nehmen anstatt einen Code zu adaptieren, der in BSD Unix frei zur Verfügung stand, die AT&T-Klage gegen BSD war „Das Ergebnis dieses Verfahrens lag völlig im Dunkeln", erinnert sich Kirch. „Das allgemeine Gefühl in den Linux-Mailinglisten der damaligen Zeit war, dass es nur eine Möglichkeit gab, etwas Derartiges zu vermeiden: die Finger von jedem Code zu lassen, den wir nicht selbst gesehrieben hatten." Kirch hat auch interessante Ansichten darüber, warum der Netzwerkbetrieb zu dieser Zeit ausgebaut wurde: „Soweit ich mich erinnere, war die Triebfeder dahinter die Tatsache, dass die Leute mit X arbeiten wollten", und nicht, dass sie eine direkte Verbindung zum Internet anstrebten. Natürlich begann die Arbeit an der Vernetzung etwa um die Zeit, in der X Window portiert wurde; und - was vielleicht überraschend war - das X Window System und der Netzwerkbetricb waren eng miteinander verbunden. In einer Hinsicht war X viel leistungsstarker als das Apple-Macintoshoder das Microsoft-Windows-System. Der Inhalt eines X Windows beschränkte sich nicht auf Programme, die auf der Maschine liefen, die sie anzeigten; X war als ein vernetztes Fenstersystem ausgelegt, das es zuließ, dass Programme, die auf anderen Maschinen liefen und über ein Netzwerk mit dem eigenen Rechner verbunden waren, auch auf diesem angezeigt und ausgeführt werden konnten. Der X-Windows-Ansatz erforderte eine Art Netzwerk im Betriebssystem. Deshalb stand Orest Zborowski beim Portieren von X für GNU/Linux unter anderem vor der Aufgabe, einen einfachen Netzwerkcode zu schreiben. Linus akzeptierte diese Zusätze, weil die Hinzufügung dieses Codes neben der Tatsache, dass sie X verfügbar machte, auch wesentliche andere Vorteile mit sich brachte. Wie die Netzwerkanleitung sagt, war Zborowskis Arbeit „ein großer Schritt nach vorn, da er das Portieren vieler bestehen-


--------------------------------------------------------------------------------------der Netzwerkapplikationen für Linux ermöglichte, ohne dass dazu ernsthafte Modifikationen notwendig gewesen wären" Dieser kleine Ausblick auf die Möglichkeiten motivierte die Linux-User dazu, auf Verbesserungen des Netzwcrkcodes zu drängen. Wie Kirch sich erinnert, „war Ross' erste Arbeit ganz in Ordnung, und sie funktionierte auch irgendwie". Natürlich war Vieles noch ungeschliffen - das ist immer so, wenn man TCP/IP von Grund auf neu schreibt. Die Netzwerkanleitung sagt dazu: „Der Druck innerhalb der LinuxGemeinde, die Entwicklung für die Netzwerkunterstützung voranzutreiben, wurde stärker und schließlich waren die Kosten, die durch unfairen Druck auf Ross einerseits und seine eigenen persönlichen Verpflichtungen andererseits entstanden waren, höher als der Vorteil, den er von dem Ganzen hatte. Also trat er als Chefentwickler zurück." Kirch erinnert sich, dass die Lage dann unangenehm wurde. „Als Nächstes begann eine Gruppe von Leuten, Ross sehr heftig anzugreifen. Warum genau, weiß ich nicht mehr. Die Folge war, dass Ross die Entwicklungsarbeiten für Linux einstellte. Es ist traurig, aber wahr: Viele langjährige Linuxhacker neigen dazu, die Anfangszeiten in den Mailinglisten in einem ziemlich rosigen Licht zu sehen. Natürlich war die Intimität damals größer, aber wahrscheinlich bewirkte das auch, dass Beleidigungen viel mehr schmerzten", meint er. Alan Cox ist davon überzeugt, dass „Biro aus verschiedenen Gründen aufhörte, darunter deshalb, weil sein Professor der Meinung war, dass er endlich seinen Doktor machen sollte" Ein weiterer Beobachter der Entwicklungen war Fred van Kempen. Kirch erinnert sich: „Nachdem Ross das Handtuch geworfen hatte", erzählt er, „trat Fred oder FvK, wie er von vielen genannt wurde, auf den Plan. Eigentlich übernahm er die Netzwerkentwicklung. Ich erinnere mich an eine Nachricht von ihm, in der er schrieb, dass er lange mit Linus telefoniert und ihn davon überzeugt hätte, dass er der Richtige für den Job sei. Um ehrlich zu sein", fahrt Kirch fort, „war FvK, wenn man nach seinen Codierfähigkeiten geht, tatsächlich ein guter Kandidat für diesen Job. Davor hatte er Netzwerkapplikationen für Minix geschrieben." FvK hatte ehrgeizige Pläne. „Fred hatte anfangs eine große Vision", sagt Kirch. „Er versuchte, eine geschichtete Architektur zu


------------------------------------------------------------------------------------implementieren, bei der man Netzwerkprotokolle übereinander stapeln konnte." Ein solcher Schichtenansatz ermöglichte den Zugriff auf andere Netzwerke als jene, die auf dem TCP/IP des Internets basierten. Das war zu einer Zeit, in der es in keiner Weise klar war, dass TCP/IP die Netzwerke dominieren würde, eine gute Idee, „Er verbesserte auch Ross' Code ein wenig", erklärt Kirch. „Um seinen Code von dem von Ross unterscheiden zu können, begann er seine Netzwerk-Patch es Ner-2 zu nennen. Dann kam Net-2b. Ab Net-2b wurde der Code dann ziemlich brauchbar." Trotzdem zeigten sich bald Auflösungserscheinungen. Kirch erinnert sich, dass es „mehrere Probleme mit FvK gab. Er wollte mit niemandem über die Dinge sprechen, die er gerade tat. Dazu kam, dass er hinter einer furchtbar langsamen Netzwerkverbindung saß, die es fast unmöglich machte, die von ihm veröffentlichten Netzwerkpatches herunterzuladen. Manchmal war seine Verbindung so wackelig, dass er tagelang keine Mails bekam." Noch schlimmer war vielleicht, dass er „manchmal Patches für einen modifizierten Kernel entwickelte" statt für den Standardkernel, Die Folge war, so Kirch, „dass die Leute Probleme hatten, sie auf ihre Systeme anzuwenden" - sogar Linus. Die Netzwerkanleitung benennt das grundlegende Problem mit der Arbeit van Kempens. „Fred konzentrierte sich auf die Erneuerung von Standard-Netzwerkanwendungen. Das dauerte. Die Benutzergemeinde wartete immer ungeduldiger auf etwas, was zuverlässig funktionierte und 80 Prozent der User zufrieden stellte. So kam es, dass der Druck auf Fred als Entwicklungschef wie bei Ross stieg." Die fortgesetzten Probleme im Netzwerkbereich wurden für Linus zu einem gröberen Problem. Rich Sladkey, der in den Anfangszeiten eine Reihe wichtiger Beiträge zum Kernelcode geleistet hatte, ist davon überzeugt, dass „der unzuverlässige Netzwerkbetrieb vor Net-2 das Vertrauen in Linux fast umgebracht hätte" Mittlerweise führten die Probleme mit Net-2 zu weiteren Zweifeln darüber, ob sich GNU/Linux, zu einem ernst zu nehmenden Betriebssystem entwickeln würde.


--------------------------------------------------------------------------------------Extremsituationen erfordern Extremrezepte, und so setzte Linus den außergewöhnlichen Schritt, einer Parallelentwicklung von Netzwerkcode durch Alan Cox zuzustimmen. In der Netzwerkanleitung liest man dazu: Cox „schlug vor, Freds Net-2-Code zu nehmen und ihn zu debuggen, um ihn zuverlässig und stabil zu machen. Damit könnte man die ungeduldigen User zufrieden stellen und gleichzeitig den Druck von Fred nehmen, sodass er seine Arbeit fortsetzen konnte", indem er sich wieder auf den komplizierteren Code mit seiner Schichtenarchitektur konzentrierte. Dieser Ansatz war gefährlich, weil er zu etwas führen konnte, was in der Hackerwelt „Code forking" genannt wird - die Entstehung zweier separater Entwicklungsstränge. Das bedeutete, dass Linux-Entwickler einen Netzwerkansatz verwenden und ihn verbessern würden, während andere an einem Konkurrenzansatz arbeiteten und beide davon überzeugt waren, dass „ihre" Methode die beste sei. Solche Verdoppelungen verwirren die Benutzer und spalten sie in zwei gegnerische Parteien, was wiederum den Fortschritt verlangsamt. Eine solche Zersplitterung hatte die Unix-Welt befallen und führte zu der schnellen Akzeptanz von Microsoft Windows NT 3.5, als dieses System 1993 heraus kam. Am Ende erwies sich das riskante Spiel als überaus lohnend: Endlich wurde eine stabile und verwendbare Netzwerkverbindung zu einem Standardteil des Kernels, und die Zerwürfnisse, die eine Zeit lang aus dieser zweigleisigen Arbeit entstanden, brachten eine wichtige und notwendige Verfeinerung für das gesamte Linux-Entwicklungsmodell. Sie führten auch dazu, dass Alan Cox de facto zur Nr. 2 von Linux aufstieg und eine der talentiertesten und produktivsten Personen der Linux-Gemeinde wurde. Alan Cox wurde ein Jahr vor Linus 1968 in Solihull, einer Vorstadt von Birmingham, der zweitgrößten Stadt Englands, geboren. Cox war der ältere von zwei Brüdern. Sein Vater war Forscher bei British Gas, der nationalen Gasgesellschaft, die die britischen Haushalte mit Gas versorgt. Seine Mutter war Lehrerin. Cox studierte an zwei Universitäten in Wales Computerwissenschaften, zuerst in Aberystwyth im Norden und dann in Swansea an der Südküste. Cox meint, er habe die wichtigsten Dinge nicht wegen, sondern trotz seiner Computerstudien gelernt. „Jch las die


------------------------------------------------------------------------------------meisten offiziellen Lehrbücher nicht; sie waren langweilig", sagt er. „Das meiste war nicht von Leuten geschrieben, die sich tatsächlich hingesetzt und richtige Betriebssysteme geschrieben hatten" - ein Bereich, der ihn damals bereits interessierte. Neben seinen offiziellen Studien befasste sich Cox mit Unix und TCP/IP; er hackte auch auf einem Amiga-Mikrocomputer, den er in seinem Studentenzimmer stehen hatte. „Ich hatte nur ein kleines Zimmer", erzählt er. „Darin gab es einige feste Bücherstapel, auf die man treten konnte, um zum Computer oder ins Bett zu gelangen." Er überlegte, ein vollkommen neues Betriebssystem für den Amiga zu schreiben, räumt aber ein, nicht mutig genug gewesen sein, um es tatsächlich zu versuchen: „Ich fand, dass es für eine Einzelperson zu schwierig sei, Dinge wie Dateisysteme zu schreiben." Cox stieß durch Linus' frühe Postings in comp.os.minix auf Linux. Er las diese Newsgroup, so sagt er, weil er sich für die Arbeit interessierte, die die Leute an Minix machten, und weil es in dieser Newsgroup viele interessante Diskussionen über Betriebssysteme gab. „Es war eine der wenigen Newsgroups, in denen die Leute wirklich diskutierten und über die Implementierung von echten Betriebssystemcode stritten." Nicht dass er Minix gehabt hätte. „Nein", erklärt er, „Minix kostete damals £ 100, und das war ein zu großer Brocken für mich." Alan Cox erinnert sich an die Zeit Ende 1991. „[Linux] 0.11 war eben herausgekommen", sagt er, „und kurz darauf bildete sich die alt.os.linux-Gruppe. Das bedeutete mehr oder weniger den Tod der Minix-Newsgroup, weil alle, die versucht hatten, an Minix zu arbeiten, sich jetzt auf Linux stürzten." Das war ein klares Zeichen für den enormen Nachholbedarf, den Linux ausgelöst hatte. Ursprünglich fühlte sich Cox von 386BSD stärker angezogen als von GNU/Linux. „Ich beschäftigte mich nicht besonders mit Linux, weil mir BSD eins viel vollständiger erschien. Kurz bevor Linus Version 0.11 ankündigte, kam die allererste 386BSD-Ankündigung heraus." Beflügelt von all diesen Aktivitäten im Betriebssystembereich entschloss er sich, einen 386er-PC zu kaufen. „Die nächste Frage war: Was soll ich hinauf tun?" Am Ende entschied er sich für GNU/Linux; die Ergebnisse seiner damaligen Beurteilung der beiden Rivalen bestätigen, dass es zwei kritische Faktoren gab, die


--------------------------------------------------------------------------------------gegen 386BSD sprachen: die Tatsache, dass es einen 387erMathematik-Koprozessor brauchte, und seine Unfähigkeit, eine Festplatte mit DOS oder Windows zu teilen. Obwohl er die Universität in Swansea schon vor einiger Zeit verlassen hatte, blieb Cox in Verbindung mit seinen dortigen Freunden und half ihnen mit der Maschine, die von der Computergemeinde der Universität verwendet wurde. Man entschloss sich, den vor kurzem herausgekommenen Netzwerkcode von Ross Biro auszuprobieren. „Wir stellten den PC in das Campusnetzwerk" erzählt er, „wir steckten ihn an und wir booteten den neuen, wunderbaren TPC/IP-Code - und er brach zusammen." „Also begannen wir, neuere Versionen hinaufzuspielen, aber die Maschine brach mehr oder weniger regelmäßig zusammen", erzählt er. Das tat sie, wie Cox sich erinnert, trotz des aktualisierten Codes. Der Grund war wichtig: „Wir waren eigentlich einige der wenigen Leute, die, wie sich herausstellte, eine Linux-Box auf einem stark frequentierten Multiprotokollnetzwerk hatten." Das bedeutete, dass sie den Code in einer neuen und extremen Situation testeten. „Die Sache mit stark frequentierten Netzwerken ist, dass man große Datenmengen und auch interessante Timings bekommt", erklärt Cox. „Eines der großen Probleme des Debuggens eines Netzwerk-Setups besteht darin, dass viele Zeit verschlingende Bugs nur auf sehr aktiven Netzwerken sichtbar werden. Die Leute betrachteten diesen Code als instabil, weil er alle paar Tage zusammenbrach. Wir hingegen waren damit konfrontiert, dass derselbe Bug alle paar Minuten zum Absturz führte." Cox war bewusst, dass das, was auf den ersten Blick Pech war (dass das stark beanspruchte Netzwerk bewirkte, dass der Netzwerkcode schnell zusammenbrach), in Wahrheit ein Glück für Linux war, weil „wir so ein großartiges Testfeld dafür hatten". Die Folge war, wie er sagt, „dass ich Ross Fixes zu senden begann" Ross Biro hörte bald auf, an dem Netzwerkcode zu arbeiten, und Fred van Kempen wurde sein Nachfolger. Cox verbirgt seine Skepsis bezüglich der Pläne von van Kempen nicht. „Fred hatte beschlossen, für seine großartige, atemberaubende Vision, alles neu zu schreiben. Alle Dinge aus Fred Brooks [berühmten Buch The Mythical Man-Month], die man auf keinen


------------------------------------------------------------------------------------Fall tun sollte. Mittlerweile, während er damit beschäftigt war, begann ich Patches herauszubringen, die im Grunde nichts anderes waren als eine Ansammlung von Fixes." Laut Netzwerkanleitung tat er das „mit ziemlichem Erfolg, und seine erste Version des Linux-Netzwerkcodes wurde "Net-2D(ebugged)" genannt. Der Code arbeitete in vielen typischen Konfigurationen ziemlich zuverlässig, und die Benutzergemeinde war glücklich. Alan verfügte eindeutig über Ideen und Fähigkeiten, die er zu dem Projekt beitragen konnte, und es folgten viele Diskussionen darüber, in welche Richtung sich der Net-2 Code wohl entwickeln würde. Diese Diskussionen intensivierten sich, bis „sich zwei verschiedene Schulen in der Linux-Netzwerkgemeinde entwickelt hatten, eine mit der Philosophie Lasst es uns zuerst zum Funktionieren bringen und dann verbessern, und eine andere, die verlangte: Lasst es uns zuerst verbessern'", wie aus der Netzwerkanleitung hervorgeht. Man konnte nicht von einem kleinen Meinungsunterschied über obskure technische Fragen sprechen, sondern es handelte sich um einen fundamentalen ideologischen Kampf, bei dem es nicht nur um das Netzwerk, sondern um den gesamten Linux-Entwicklungsprozess ging. Im Zentrum der Diskussion stand die Frage, wie es mit Linux weitergehen sollte; welche Mechanismen verwendet werden sollten, um den Kernel um wichtige neue Features zu erweitern, und, was am wichtigsten war, wie das wachsende Entwicklungsteam geführt werden sollte. Andrew Tanenbaum hatte die meisten dieser Fragen unausgesprochen in einem der Argumente aufgeworfen, die er während der „Linux-istobsolet"-Diskussion vorgebracht hatte. Am 3. Februar 1992 hatte er geschrieben: Eine interessante Frage ist, ob Linus bereit ist, LINUX „frei" von seiner Kontrolle werden zu lassen. Können die Leute es modifizieren (und ruinieren)? Und es verkaufen? Danach hatte er eine hypothetische Frage gestellt, die von einem erstaunlichen Scharfblick zeugt, weil sie Monate vor dem Zeitpunkt


--------------------------------------------------------------------------------------kam, an dem Linus' Probleme mit dem Netzwerk und Fred van Kempen akut wurden: Nehmen wir an, Fred van Kempen ... möchte das Steuer übernehmen und Freds LINUX und Linus' LINUX schaffen, beide nützlich, aber anders. Ist das o.k.? Die Feuerprobe kommt, wenn eine nennenswerte Gruppe von Leuten LINUX auf eine Weise evaluieren will, die Linus ablehnt. Tanenbaum erläuterte seine Gedanken einige Tage später weiter: Das Problem liegt in der Koordination. Projekte wie GNU, MINIX oder LINUX können nur zusammen gehalten werden, wenn es jemanden gibt, der die Dinge in der Hand hat. In den siebziger Jahren, als das strukturierte Programmieren eingeführt wurde, wies Harlan Mills daraufhin, dass ein Program-miererteam wie ein Chirurgenteam organisiert sein sollte - ein Chirurg oder eine Chirurgin und seine oder ihre Assistenten, nicht ein ganzes Schlächterteam, bei dem allen eine Axt in die Hand gedrückt und ihnen gesagt wird, sie sollten nur nach Herzenslust daraufloshacken. Tanenbaum zeichnet ein grafisches Bild des verteilten Sortwareentwicklungsprozesses, den Linux anwendete: Ich glaube, 1000 Soflwareprimadonnen zu koordinieren, die über die ganze Welt verteilt leben, ist ungefähr so einfach, wie einen Sack Flöhe zu hüten. Linus schickte seine Antwort am nächsten Tag, den 6. Februar 1992 an die Newsgroup: Hier ist mein Standpunkt zum Thema „Kontrolle behalten" in fünf Worten: Ich werde es nicht tun. Die einzige Kontrolle über Linux, die ich effektiv in der Hand habe, besteht darin, dass ich es besser kenne als irgendjemand


------------------------------------------------------------------------------------sonst und dass ich meine Änderungen auf FTP-Sites etc. zur Verfügung gestellt habe. Diese Änderungen sind zu effektiven offiziellen Versionen geworden, und ich glaube nicht dass sich das in absehbarer Zeit ändern wird: Nicht weil ich glaube, einen moralischen Anspruch darauf zu haben, sondern deshalb, weil ich nicht allzu viele Klagen höre und weil es einige Monate dauern wird, bevor ich damit rechnen kann, Leute zu finden, die dasselbe „Gefühl" für das haben wie ich, was im Kernel passiert. (Nun, vielleicht bewegen wir uns in diese Richtung: Ted Ts'o hat sicher ernsthafte Änderungen sogar an 0.10 durchgeführt, und ändert haben ebenfalls daran gearbeitet.) Tatsächlich habe ich meine Fühler bezüglich einer „Linux-Kernel"Mailinglisie ausgestreckt, die Versionsentscheidungen treffen würde, da ich nicht alle Features, die hinzugefügt werden sollen/müssen, zur Gänze unterstützen kann: SCSI etc, denn dafür habe ich nicht die notwendige Hardware. Es gab so gut wie keine Reaktion: Die Leute scheinen es mit dem Wechsel noch nicht so eilig zu haben ... wenn Fred van Kempen ein Super-Linux schreiben will, denn soll er es gern tun. Er schloss mit einem wichtigen Argument: Ja, die Koordination ist ein großes Problem, und ich denke nicht, dass Linux mir als „Chefchirurgen" in nächster Zeit aus den Händen kommen wird. Der Grund liegt zum Teil darin, dass die meisten Leute über diese Probleme Bescheid wissen. Aber das Copyright ist ein Thema: Wenn die Leute das Gefühl haben, dass ich schlecht arbeite, können sie es selbst machen. Wie Linus im selben Posting an comp.os.mink sagte, hatte er sich aus folgendem Grund für die GNU General Public Liccnse (GPL) entschieden: ... Das Einzige, was das Copyright verbietet (und ich meine, dass das durchaus vernünftig ist), ist, dass andere Leute


--------------------------------------------------------------------------------------beginnen, Geld mit dem System zu verdienen und den Quellcode nicht zur Verfügung stellen etc. ... Das mag keine Frage der Logik sein, aber ich hätte ein sehr schlechtes Gefühl, wenn irgendjemand kommen und meine Arbeit gegen Geld verkaufen könnte, wenn ich sie ausdrücklich frei zur Verfügung stelle, damit die Leute mit einem persönlichen Projekt herumspielen können. Die GNU GPL gestattet es anderen, den Linux-Quellcode zu nehmen und ihn zu modifizieren, vorausgesetzt, dass sie die Modifikationen öffentlich zur Verfügung stellen; das bedeutet, dass Linus, wenn jemand anderer ein „Super-Linux" entwickelt, selbst nichts tun kann, um diese Person davon abzuhalten, solange der Quellcode veröffentlicht wird. Der Vorteil dieses Ansatzes liegt darin, dass Linus die Änderungen, die ihm gefallen, von einem solchen „Super-Linux" nehmen und sie in „sein" Linux integrieren kann. Der Nachteil ist, dass die GNU GPL solche Divergenzen überhaupt möglich macht. Linus' Antwort auf die zunehmende Spaltung des Netzwerkcodes in die Arbeit von Fred van Kempen einerseits und die von Alan Cox andererseits sollte dieselbe sein wie die, die er in einer Antwort auf Tanenbaums Posting im Februar gegeben hatte. Obwohl er niemandem verbieten konnte, bestimmte Entwicklungsarbeiten durchzuführen, konnte er seine Autorität (die, wie er zu Recht sagte, darauf basierte, dass er das System besser kannte als irgendjemand sonst und weil er mit dem Management der Kernelentwicklung vertraut war) dazu benutzen konnte, einen Zweig des Code zu genehmigen und ihn damit zu einem Teil der „effektiv offiziellen Versionen" zu machen. Vorausgesetzt, dass genügend Leute in der Linux-Benutzergemeinde diesem Entschluss zustimmten, was sie die Benutzung dieser „effektiv offiziellen Versionen" zeigten, würde die von ihm gewählte Codebasis florieren, und die Rivalen würden wegen mangelnder Unterstützung erschlaffen. Die Netzwerkanleitung erklärt, warum dies im Fall des im Kernel integrierten Netzwerkes zutraf. „Linus fungierte letzten Endes als Schiedsrichter und bot Alan Hilfe bei seiner Entwicklungsarbeit an.


------------------------------------------------------------------------------------Er nahm Alans Code auch in die Standarddistribution des Kernelquellcodes auf. Das brachte Fred in eine schwierige Lage, Jede weitere Entwicklung würde darunter leiden, dass es keine große Benutzerbasis gab, die den Code aktiv verwendete und testete, und das würde bedeuten, dass die Fortschritte nur langsam und schwer zu bewerkstelligen sein würden. Fred setzte seine Arbeit kurze Zeit fort, zog sich aber schließlich zurück. Dann übernahm Alan die Entwicklungsarbeiten für den neuen Linux-Netzwerkkernel. Kirch sagt: „ich weiß nicht, ob es je eine öffentliche Aussage von Linus gegeben hat, ob er nun Alan oder Fred bevorzugte. Was irgendwann einmal passierte, war, dass Linus keine Patches von Fred mehr akzeptierte, sondern nur noch von Alan. An diesem Punkt übernahm Alan effektiv die Wartung des Netzwerkcodes." Alan Cox betont, dass „es reiner Zufall war. Ich wollte einfach, dass der Netzwerkcode funktionierte." Das stimmt zweifellos, aber auf Linus' Seite bedeutete der Schritt eine Absichtserklärung. Linus sagte später: „Ich war nie so intensiv mit dem Design befasst. Ich habe da eine sehr pragmatische Einstellung: Was funktioniert und was die Leute verwenden wollen, ist gut. Wen interessiert schon das Design, wenn die Leute es nicht verwenden wollen?" Indem er der Alan Cox, ebenfalls Pragmatiker, den Vorzug gegenüber Fred van Kempens „großer Vision" gab, wie Kirch sie nennt, signalisierte er allen LinuxEntwicklern, welche Art Code er bevorzugte und welche allgemeine Philosophie er fortan verfolgen wollte: jene des „Lasst uns zuerst sehen, dass es funktioniert, und dann lasst es uns verbessern", wie es in der Linux Netzwerkanleitung ausgedrückt wird. Das war schließlich die Methode, die Linus beim Schreiben von Linux angewendet hatte. Das erste Linux, das er postete, 0.02, war kaum zu verwenden, aber es funktionierte. Wichtiger war, dass es ein Ausgangspunkt war, den andere dann verwenden konnten, um Verbesserungen hinzuzufügen, von denen sich zeigte, dass Linus sie bereitwillig annahm. Alan Cox' darauf folgende Arbeit am Netzwerkcode folgte demselben Weg. Kirch erinnert sich, dass „Alan ganz im Gegensatz zu seinem Vorgänger nichts sofort wegwarf. Dabei hatte er immer gesagt, dass sein letztendliches Ziel darin bestünde, FvKs Schichten


--------------------------------------------------------------------------------------loszuwerden, weil sie alles verkomplizierten und verlangsamten und obwohl er nicht viele Funktionen hinzufügte. Er begann, indem er die Sache einfach zum Funktionieren brachte." Alan Cox erinnert sich: „Das Erste, was ich in vielen Fällen tat, war, einfach mit Aufräumen zu beginnen ... auf Protokollebene gab es eigentlich kaum Fehler", was die grundlegenden TCP/IP-Standards anbelangte, „die von mir behoben wurden. Die Protokolle waren zum größten Teil in Ordnung, nur alles, was darunter war, war ein wenig schütter oder hatte Löcher." Code, der „ein wenig schütter war oder Löcher hatte" zu reparieren, war eine der Stärken von Cox. „Ordnung in chaotische Code zu bringen, schien eines der Dinge zu sein, in denen ich gut war", sagt er, und er erwies sich bald als einer der besten Linux-Debugger. „Ich stelle mir die Bugs sogar oft im Traum vor", bekennt er. Neben dem Debugging und dem Schreiben von neuem Code begann Cox auch, die wichtige zusätzliche Rolle eines der „Vertrauensleutnants" von Linus, wie sie oft genannt wurden, anzunehmen. Dabei handelt es sich um höherrangige Hacker, die für bestimmte Bereiche des Kernels zuständig sind. Ihre Arbeit besteht darin, die Patches anderer Hacker zu filtern, sie zu überprüfen und sie dann an Linus weiterzugeben. Alan Cox erinnert sich: „Die Leute fingen schon relativ früh an, mir Dinge für den Netzwerkcode zu senden. Wenn es irgendetwas gibt, dessen sie sich nicht sicher sind, sagt jemand: ,lch glaube, das könnte ein Fix sein, aber ich bin mir nicht sicher - was meint ihr?" Linus hatte die Integration dieser entscheidenden Entwicklungsinfrastruktur nie geplant - sie ergab sich aus der Situation heraus. Wie er sagte: Ich traf nie bewusste Entscheidungen darüber, wie ich in Zukunft arbeiten wollte. Alle Änderungen waren automatische Reaktionen auf verschiedene Umstände. Zuerst schickten mir die Leute ihre Patches einfach direkt In der Folge fasste ich Vertrauen zu einigen, mir denen ich E-Mails ausgetauscht hatte. Ich wusste, sie kannten sich technisch aus und taten das Richtige [ein Schlüsselkonzept für Hacker], Andere Leute begannen wiederum, diesen Hackern, denen ich vertraute,


------------------------------------------------------------------------------------Patches zu senden. Das entlastete mich in meiner Arbeit ein bisschen, weil die Leute meines Vertrauens diese Patches überprüften. Das funktionierte ziemlich gut. Manchmal sage ich zu den Leuten, die mir E-Mails schicken, direkt: „Könnt ihr das dieser oder jener Person zur Überprüfung schicken?" Ein Grund kann sein, dass ich nicht die notwendige Hardware habe. Dann ist die andere Person für diesen Teil zuständig. Und danach geht es irgendwie automatisch den richtigen Weg. Es gibt also vielleicht zehn oder zwanzig Leute, die für bestimmte Teile des Kernels wie Netzwerk, SCSI-Treiber-Subsystem oder was immer verantwortlich sind. Und dann gibt es jede Menge Leute, die einen bestimmten Treiber haben, für den sie zuständig sind. Normalerweise sind es die ursprünglichen Autoren dieser Treiber, aber in manchen Fällen haben sie vielleicht eine neue Maschine bekommen und jemand anderer hat diesen Treiber übernommen. Solche Dinge wende ich normalerweise direkt an, weil ich sie nicht testen kann. Ich muss einfach den Leuten vertrauen, die sie ursprünglich geschrieben haben. Einer der Gründe, warum diese schrittweise Aufteilung des Kernels „ziemlich gut funktionierte", wie Linus sagte, bestand darin, dass .,die Art und Weise, wie das ganze [Linux] System aufgesetzt ist -was sich auch irgendwie von selbst ergeben hat - darin besteht, dass eigentlich nichts Besonderes passieren sollte, wenn man einen Treiber ändert, weil er so lokalisiert ist". Anders ausgedrückt ist das Design des Kernels hochgradig modular mit klaren Schnittstellen zwischen den Teilen. „Das muss so sein, wenn es Leute auf der ganzen Welt gibt, die am System arbeiten", merkt Linus an. „Es gibt keine wöchentlichen Brainstorming-Sessions, bei denen alle zusammenkommen und über die Probleme sprechen." Dieses Modell hatte sich schon klar herauskristallisiert, noch bevor Cox die Verantwortung für den Netzwerkcode übernahm. Im Allgemeinen war jedoch der Showdown zwischen rivalisierenden Entwicklungssträngen, wie er in diesem Fall startgefunden hatte, vermieden worden. Der Fall eines anderen Leutnants, Ted Ts'o, ist typisch.


--------------------------------------------------------------------------------------Wie Cox wurde Ts'o 1968 geboren, aber eine Drittel Erdumdrehung weiter, in Kalifornien. Sein Vater war Arzt und seine Mutter war ebenfalls in der Familienpraxis beschäftigt. Es waren die Forschungsaktivitäten seines Vaters, die Ts'o das erste Mal in Kontakt mit Computern brachten. „Ich begann relativ früh mit dem [Digital] PDP-8 und PDP-15 meines Vaters zu spielen", erinnert sich Ts'o. „Tatsächlich waren das die einzigen Computer, die mir bis zur Highschool zum Spielen zur Verfügung standen," Er programmierte diese Digitalmaschinen nicht in einer Hochsprache wie Basic, sondern in „unbearbeitetem Assembler". Als Ts'o 1986 ans MIT ging, studierte er Computerwissenschaften und schloss dieses Studium 1990 ab. Bald danach, im Herbst 1991, stieß er auf GNU/Linux. Dabei handelte es sich wahrscheinlich um Version 0.02 oder 0.03, weil Ts'o schon bei Version 0.10, die im Dezember 1991 herauskam, zum Kernel beigetragen hatte. Er fügte neuen Code hinzu, der den Benutzern zusätzliche Methoden zur Kontrolle der Programme zur Verfügung steüte, die auf dem Computer liefen. Das Motiv dafür, dass er diesen Code an Linus sandte, ist interessant. „Einer der Gründe, warum ich es tat", so Ts'o, „war einfach, dass es getan werden musste und dass es das System für mich selbst viel nützlicher machen würde." Aber, so sagt er, „irgendwann kam mir der Gedanke, hey, wenn ich das tue, wird Linux sicher für viel mehr Leute nützlicher". „Ich glaube, einige Leute wussten instinktiv, dass es so etwas wie eine kritische Masse gab, und wenn man genügend Leute dazu brachte, auf [Linux] zu arbeiten, konnte wirklich etwas Interessantes herauskommen." Dazu kam, dass Ts'o und die anderen diese Theorie bereits anderswo in die Praxis umgesetzt hatten: Es gab viele Leute, die wirklich wussten, dass man Änderungen zu [freien Programmen] beitragen konnte und dass sie entweder akzeptiert wurden oder nicht, dass aber das Endergebnis auf jeden Fall ein viel besseres Produkt war." So fuhr Ts'o nicht nur damit fort, Patches einzusenden, sondern er leistete auch einen anderen wichtigen Beitrag zur GNU/LinuxBewegung der frühen Tage, indem er die erste Site in den Vereinigten Staaten einrichtete, auf der der Linux-Kernel und die


------------------------------------------------------------------------------------dazugehörige Software zu finden war, Ts'o erklärt den Hintergrund dieses Schritts so: „Mir fiel auf, dass der einzige Ort, an dem man Linux in jenen Tagen bekam, ftp.funet.fi war - die finnische Hauptsite, die von Ari Lemmke eingerichtet worden war. „Die war manchmal furchtbar langsam. Wieder kam mir der Gedanke, dass die Leute Linux einfach viel leichter verwenden könnten, wenn ich eine FTP-Site einrichtete." Die Site wurde bald als TSX-11-Repository bekannt. Ts'o erklärt, dass „TSX-11 zufällig einfach die Workstation war, die auf meinem Schreibtisch stand," Eine US-Site für GNU/Linux zu entwickeln, erwies sich als wichtiger Schritt für die Bereitstellung des Systems auf dieser Seite des Atlantiks. Und wieder war die Motivation für diesen Schritt, dass er etwas Gutes für die ganze Gemeinde bewirken würde. Nach und nach begann Ts'o, einen größeren Teil seiner Arbeit in nur einen oder zwei Bereiche zu stecken. „Im Allgemeinen war es so, dass sich die meisten Leute auf alle Teile des Kernels konzentrierten, dass sie aber mit der Zeit weniger mit den Fragen oder Fixes von Teilen beschäftigten, auf die sie sich nicht wirklich konzentrierten, weil sie keine Zeit hatten oder weil der Kernel so groß wurde, dass es nicht mehr möglich war, mit allen seinen Teilen vertraut zu sein." Als der Kernel größer wurde und immer mehr Features bekam, war es durch die daraus resultierende Spezialisierung nicht mehr für jeden Hacker möglich, zu allem und jedem Beiträge zu leisten. Sobald Leute für ihre Arbeit an bestimmten Bereichen bekannt wurden, begannen sie einige der Aufgaben zu übernehmen, die ursprünglich ausschließlich von Linus bearbeitet worden waren. Ein weiterer wichtiger Faktor trug dazu bei, diese Änderung anzukurbeln. „Was immer öfter passierte, war, dass die Leute zunehmend Bug-Reports oder Bitten um Hilfe schickten und weniger richtige Patches", erklärt Ts'o. Das bedeutet, dass GNU/ Linux nun so einfach zu verwenden war, dass es nicht länger nur den Hackern vorbehalten war. Diese Nichthacker schickten keinen Code ein, sondern Bug-Reports, was trotzdem einen wesentlichen Beitrag darstellte. Als Folge begannen einige der wichtigsten Hacker, die Bug-Reports oder die Bitten um Hilfe zu beantworten, anstatt selbst Patches zu schreiben. Wie Ts'o sich erinnert, „war ich


--------------------------------------------------------------------------------------schlicht und einfach derjenige, der sich um die Beantwortung der Fragen kümmerte". Dann begann ein Schneeballeffekt einzusetzen. „Das alles spielte sich auf einer öffentlichen Mailingliste ab, sodass die Leute sahen, dass ich derjenige war, der die Antwort mit dem Fix und dem Patch zurückschickte, wenn Soundso um Hilfe bat", erzählt er. „Und deshalb ergab es sich, dass andere Dinge an mich weiterleiteten und mir Patches schickten, weil sie wussten, dass ich ohnehin aktiv in diesem Bereich arbeitete." Das letzte Stadium dieses Entwicklungsprozesses, so Ts'o, war dass „die Leute ab einem bestimmten Punkt Patches an Linus schickten, und er schickte den Patch an mich und fragte: ,Was meinst du dazu?" Die Folge war, dass Ts'o die Kontrolle über bestimmte Teile des Kernels übernahm und überarbeitete Patches an Linus zur Begutachtung weiterleitete. Die Verantwortung für ein wichtiges Gebiet, nämlich jenes des LinuxDateisystems ext2, teilt er mit einem anderen der langjährigsten LinuxHacker Stephen Tweedie. Tweedie wurde 1969 in Edinburgh, Schottland geboren. Beide seiner Eltern arbeiteten in der Computerindustrie, und Tweedie sagt: „Ich kann mich an keine Zeit erinnern, in der ich nicht von Computern umgeben gewesen wäre." Als er vierzehn war, entwickelte er bereits Betriebssystemerweiterungen für seinen Mikrocomputer Sinclair ZX-81, eine Maschine, die Alan Cox als Junge ebenfalls verwendet hatte. Tweedie studierte Computerwissenschaften an der Universität Cambridge; nach Studienabschluss kehrte er als Forscher an die Universität der schottischen Hauptstadt zurück. Dort entdeckte er etwa um den Anfang 1992 GNU/Linux. „Ich ging nicht speziell dorthin, um darauf zu hacken", sagt er, „aber ich tat es trotzdem schon sehr bald.' Tweedie beschreibt die Art und Weise, wie die Leute zu ihren Verantwortungsbereichen kamen, gleich wie Ts'o. „Es geht ganz einfach darum, wer an etwas arbeitet", sagt Tweedie, „und wer dafür bekannt ist, dass er gute Entscheidungen trifft. Und wenn man an etwas arbeitet und man in den Augen anderer, die das


------------------------------------------------------------------------------------ebenfalls tun, Glaubwürdigkeit genießt, besteht die Wahrscheinlichkeit, dass andere Patches zu einem weitergeleitet werden." „Es gibt Leute, die allgemein dafür anerkannt sind, dass sie nicht Eigentümer bestimmter Bereiche sind, sondern einfach Experten. Die Gemeinde nützt das aus und setzt diese Leute ein, um die Arbeit in diesen Bereichen voranzubringen." Anders ausgedrückt: „Es ist wirklich eine Meritokratie, in der man sich seine Stellung selbst erarbeitet", erklärt er. Er selbst scheint eine Art logische Wahl der Gemeinde zu sein. Linus' Bereitschaft, Arbeit an seine Leutnants zu delegieren und ihnen Verantwortung für große Teile des Kernels zu übertragen, hatte eine andere wichtige Auswirkung, Alan Cox, Ted Ts'o und Stephen Tweedie, die ein Jahrzehnt lang alle ständige Beiträge leisteten, blieben der Linux-Bewegung viele Jahre lang verbunden, obwohl jeder von ihnen ganz einfach seine eigene Konkurrenzgruppe hätte gründen und leiten können - denn das hätte die Lizenz von Linux ermöglicht. Diese grimmige Loyalität zu einem Entwicklungsstrang steht im krassen Widerspruch zu anderen freien Projekten mit Unix-artigen Kernels. So wurde zum Beispiel NetBSD gestartet, nachdem 386BSD seinen Schwung verloren hatte. Laut Ankündigung von NetBSD 0.8 im April 1993 durch seinen Initiator, Chris Demetriou, basierte NetBSD „hauptsächlich auf 386BSD 0.1" mit mehreren hinzugefügten Patches und neuen Programmen. In ähnlicher Weise erlebte FreeBSD „seine Genesis Anfang 1993, zum Teil als Nachkomme des "Unofficial 386BSD Patchkit" wie Jordan Hubbard, einer seiner Urheber, in seiner Geschichte der Software schreibt. Ein weiterer Sprössling von 386BSD ist das OpenBSD Project unter der Leitung von Theo de Raadt, der besonderen Wert auf Sicherheit legt. Die Existenz dreier höchst ähnlicher Projekte führte dazu, dass sich die Codierarbeit aufspaltete und sich die Benutzerbasis für jedes dieser Projekte stärker verkleinerte, als es der Fall gewesen wäre, hätte es nur einen solchen 386BSD-Abkömmling gegeben. Die Schwäche der gespaltenen Welt freier BSD-Abkömmlinge ließ die entsprechenden Stärken der vereinheitlichten Linux-Fntwicklung hervortreten.


--------------------------------------------------------------------------------------Als Linux zu einem Patchwork von Bereichen geordnet wurde, die von Linus' Leutnants bearbeitet wurden, begannen die wichtigen Nebenwirkungen dieser Entwicklung auf Wachstum und Entwicklung von Linux nur nach und nach spürbar zu werden. Linus' Entscheidung, Alan Cox zu stützen, hatte jedoch unmittelbarere Folgen. Cox' intensiver Hackerstil versetzte Linus in die Lage, Öfter überarbeitete Kernels zur Bereinigung des TCP/IP-Codes herauszubringen, der sich als so problematisch erwiesen hatte. Wie Olaf Kirch sagt: „Ich glaube, dass Alans Arbeit mit dem Ziel, die Netzwerkschicht stabiler zu machen, einer der wichtigsten Punkte war, warum Linus die Veröffentlichung von 1.0 so lange hinauszögerte. Er wollte einen funktionierenden TCP/IP [-Modul] haben, bevor er die Version 1.0 nannte." Einzelheiten der Versionsgeschichte des Linux-Kernels spiegeln diese Änderung wider. Version 0,98 des Code, als TCP/IP in Form von Ross Biros anfänglichen Patches für den Kernel verfügbar war, trägt das Datum 29. September 1992. Version 0.99 - quälend nahe an der lang ersehnten Linux-Version 1.0, zumindest, was die Nummerierung anbelangte - kam am 13. Dezember 1992 heraus. Im Jahr 1993 waren Kernelversionen noch langsam, jedenfalls im Fall von Linux: drei im Januar, jeweils zwei im Februar, im März und im April, eine im Mai und keine im Juni. Im Juli und August gelang es Linus nur, eine einzige Version zu veröffentlichen - es schien, als waren die Sommerferien dieses Jahres nicht besonders produktiv. Offensichtlich hemmten die Kämpfe innerhalb der aufstrebenden Linux-Gruppe den Fortschritt der Bewegung. Dann plötzlich, Ende September 1993, gab es eine entscheidende Wendung. Version 0.99.13 wurde am 20. Deptember veröffentlicht, gefolgt von elf Versionen in nur etwas mehr als einem Monat, kulminierend in Version 0.99.13k, die am 25. Oktober erschien. Auch die komprimierte Größe des Kernels wuchs: von 320K von Version 0.98 über 420K für Version 0.99 auf fast 800K für Version 0.99.13k, Linus und seine Codiererkollegen wuchsen über sich selbst hinaus. Im Dezember 1993 erschienen zehn Versionen, im Januar 1994 nicht weniger als vierzehn, im Durchschnitt jeden zweiten Tag eine. Im Februar 1994 kamen sogar elf neue Versionen heraus.


------------------------------------------------------------------------------------Schließlich, mit dem letzten Datumsstempel vom 13. März 1994, 22:38 Uhr, wurde der Welt endlich ein Megabyte komprimierter Code als Linux 1.0 übergeben. Fast drei Jahre nach dem Tag, an dem Linus seine Minix-Kopie erhielt, war die erste offiziell vollständige Version von Linux fertig gestellt worden, eine Version, die einem ernsthaften Vergleich mit anderen Unix-Kernels standhalten konnte. Gleichzeitig war die GNU/LinuxBenutzerbasis von einem einzigen Hacker auf Tausende von Leuten auf der ganzen Welt angewachsen. Die Gruppe hatte eine überaus anstrengende Zeit interner Uneinigkeit hinter sich gebracht. Schließlich war sie aber Dank ihrer immer besser definierten Entwicklungsmethoden und einer Kerngruppe begabter Codierer, die Linus in seiner Arbeit unterstützen konnten, stärker geworden und besser für die Zukunft gerüstet. Ihre neue Flexibilität versetzte sie in eine gute Position, einer weiteren großen Veränderung, die inzwischen ungebremst im Gang ist, nicht nur standzuhalten, sondern sogar von ihr zu profitieren: der Kommerzialisierung von GNU/Linux.

6

Erst Boot, dann Root

DlE ERSTE VERSION VON LINUX war nur zum „Lesen" gedacht. Da es aber wenig Sinn machte, einen neuen Kernel zu produzieren, den niemand verwenden konnte, begann Linus, neben dem Quellcode Binärcode anzubieten, kompilierte Versionen, die auf einem PC liefen. Ein System zum Laufen zu bringen, war eine komplizierte Sache, zu der nur die eingefleischtesten Hacker imstande waren. Um den Leuten zu helfen, erstellte Linus zwei Disketten namens Boot und Root. Lars Wirzenius erklärt dieses Verfahren. „Auf der Bootdiskette war der Kernel." Man legte die Diskette in den PC ein und schaltete ihn ein. „Wenn der Computer dann bootete, wurde man aufgefordert, die andere Diskette einzulegen, auf der sich das gesamte Dateisystem für das Linux-System befand", erzählt Wirzenius. „All das Zeug, das man heute auf einer Harddisk speichern würde, befand sich damals auf einer Diskette. Aber es war ein


------------------------------------------------------------------------------------winzig kleines Dateisystem, sehr wenige Programme, gerade genug, um es ein unabhängiges Unix-System nennen zu können", sagt er. Sobald das System lief, konnte man seinem Ehrgeiz die Zügel schießen lassen. „Wenn man wusste, was man tat", so Wirzenius, „konnte man eine Festplatte oder eine Partition der Festplatte formatieren und die Programme auf die Festplatte kopieren. Dann konnte man die Bootdiskette modifizieren, um den Kernel stattdessen von der Festplatte zu laden." Das ging viel schneller als das Laden von der Diskette, Nun konnten die Benutzer beginnen, das System zu erforschen und einige der wenigen, separat erhältlichen Programme auszuprobieren, das für es portiert waren, wie zum Beispiel Stallmans GCC. Linus speicherte Kopien der Boot- und der Root-Disketten auf dem Server in Helsinki, wo er auch den Quellcode gespeichert hatte. Da sowohl der Quellcode als auch der Binärcode frei verteilt werden konnten, begannen mehrere andere Sites auf der ganzen Welt, diese Codes zu „spiegeln" oder zu kopieren. Eine dieser Sites war die des Manchester Computing Centre (MCC), das zur Universität Manchester in Großbritannien gehörte. Nachdem das MCC anfangs Linus' frühe Boot- und Root-Disketten einfach gespiegelt hatte, entschloss es sich, seine eigene Distribution oder Dateisammlung zusammenzustellen, die zur Installation von GNU/Linux verwendet werden konnte. Die erste Interimsversion des MCC, die die Kernelversion 0.12 verwendete, erschien im Februar 1992, Die Readme-Datei, die sie begleitete, ermöglichte faszinierende Einblicke in das, was nötig war, um GNU/Linux in jenen Pioniertagen zum Laufen zu bringen. In der Readme-Datei steht; „Die MCC-Interimsversionen von Linux sind dazu ausgelegt, es auch Personen, die keine Unix-Experten sind, zu ermöglichen, eine Version des Linux-Betriebssystems auf einem PC zu installieren. Das installierte System sollte in sich geschlossen sein, ist aber leicht zu erweitern." Das deutet daraufhin, dass es zu diesem Zeitpunkt bereits Leute gab, die keine Unix-Experten waren, die aber eine Distribution haben wollten, die es ihnen gestatten würde, GNU/Linux auf ihren PCs zu installieren.

6. Erst Boot, dann Root

--------------------------------------------------------------------------------------Weiter heißt es in der Readme-Datei: „Unsere Versionen werden 'Interimsversionen' genannt, weil sie nicht als endgültige oder offizielle Versionen gedacht sind. Sie sind klein, harmonisch und wurden nur beschränkt getestet." Der letzte Punkt war wichtig: Man musste den Linux-Kernel nicht nur debuggen, sondern, wenn man zusätzliche Komponenten zu einer Distribution hinzufügen wollte, auch überprüfen, ob sie alle zusammen funktionieren, also „harmonisch" sein würden. Diese Art von Fehlerbereinigung im großen Stil wurde eine der Schlüsselaufgaben der Leute, die Distributionen zusammenstellten. Wie die MCC-Readme-Datei erklärt: „Sehr kurz nachdem die erste MCC-Interimsversion von Linux erschien, brachten andere Leute ähnliche Versionen heraus: Auf Dave Saffords TAMU [Texas A&M University] Versionen und Martin Junius' MJ Versionen folgten schließlich Peter MacDonalds massive, umfassende SLS-Versionen und H. J. Lus kleine Basissysteme. Peter MacDonald war einer der ersten Linux-Hacker, der Linus Patches geschickt hatte. Wirkliche Bekanntheit erlangte er aber dafür, dass er die Softlanding Linux System (SLS) Versionen zusammengestellt hatte. Wie die MCC-Readme-Datei erklärt, waren diese Versionen „massiv" und „umfassend". Das bedeutet, dass sie nicht nur versuchten, den Kernel und grundlegende Utilities bereitzustellen, sondern auch viele der GNU/Linux-Ports, die herauszukommen begannen. Dazu gehörten so wichtige neue Elemente wie X Window und TCP/IP. Der Nachteil dieses Ansatzes bestand darin, dass die Aufgabe, alles auf dem neuesten Stand zu halten und dafür zu sorgen, dass alle Komponenten harmonisch zusammenarbeiteten, immer schwieriger wurde, je komplexer der Linux-Kernel wurde und je reichhaltiger die Palette der Applikationen wurde. Das bedeutete, dass die SLSDistribution, so bewundernswert ihre Ambition, eine vollständige Lösung zu bieten, auch war, das dringende Bedürfnis nach etwas Stabilem, das Neulinge der Linux-Welt leicht installieren konnten, letzten Endes nicht erfüllen konnte. Jemand, dessen Ungeduld mit SLS ständig größer wurde, war lan Murdock, der damals an der Purdue Universität Betriebswirtschaft studierte. Er schrieb später einen Artikel für die erste


------------------------------------------------------------------------------------Ausgabe des damals neuen Linux Journal, erschienen im Mai 1994, in dem er meinte, dass SLS „vielleicht die am stärksten mit Bugs verseuchte und am schlechtesten gewartete Linux-Distribution ist, die es gibt; leider ist es wahrscheinlich auch die populärste". Das sind typische Worte eines jungen Mannes; Murdock war damals Anfang zwanzig. „Heute bedaure ich meinen brüsken Ton", sagt er, „der Typ hatte ja nur versucht, mir etwas Gutes zu tun." Trotzdem gab es eine Menge Probleme mit SLS, und ich war wirklich nicht der Einzige, der dieses Gefühl hatte. Was ich geschrieben hatte, war damals eigentlich mehr oder weniger die Ansicht der Gemeinde." Murdock hatte erkannt, dass die Probleme von SLS „von der Tatsache herrührten, dass der Typ, der daran arbeitete, versuchte, alles selbst zu machen. Also schaute ich mir das an und dachte, na ja, wenn Linux uns irgendetwas gelehrt hat, dann das, dass diese Art von Modell nicht optimal ist", erinnert er sich. „Am besten wäre es zu versuchen, das Modell, das Linux vorgegeben hat - ob mit Absicht oder nicht -, zu nehmen und für den Aufbau des umgebenden Systems dieselben Vorteile daraus zu ziehen." Das war eine wichtige Erkenntnis für Ende 1993, als Murdoch die Idee hatte. Sie zeigt, dass in diesem Stadium zumindest schon einigen Leuten bewusst war, dass Linux nicht nur ein Stück Software war, sondern eine ganze Entwicklungsmethode. Das „Modell", das Murdock erwähnt, bedeutet die Verwendung eines verteilten Teams, dessen Mitglieder via Internet miteinander verbunden sind, bei dem kleinere Elemente durchgegeben werden, die dann gemeinsam das Ganze - in diesem Fall eine Distribution - bilden. Das System wird dann von den Benutzern von Bugs befreit. Murdock entschloss sich, seine neue Distribution Debian zu nennen. „Der Name ist sehr einfach zu erklären", sagt er. „Meine Frau heißt Deb, und ich heiße Ian. Es ist also nur eine Kombination der beiden Namen." Er fahrt fort: „Es war im August 1993, als ich [Debian] zum ersten Mal auf einem öffentlichen Forum erwähnte, ich hatte ein bisschen daran herumgebastelt und eine Nachricht mit folgendem Inhalt gepostet: ,Hey, ich arbeite da an diesem Projekt, gibt es irgendjemanden, der mir dabei helfen will?' Ich konnte nicht ahnen, welche Flut an Reaktionen dieses Posting auslösen würde."


--------------------------------------------------------------------------------------Das sollte er bald feststellen. „Die Reaktionen waren überwältigend", erzählt Murdock. Er ist davon überzeugt, dass es dafür zwei Hauptgründe gibt. „Linux hatte offensichtlich viel zu bieten, und die Tools, die rund um das System gebaut worden waren, ebenfalls. Aber das, was noch fehlte, war die Präsentation [die Art des Vertriebs]", sagt er. „Auch die Idee, ein System zu bauen, an dem die Leute mitarbeiten konnten, erwies sich als überaus populär." Dasselbe galt für die Idee, dass jeder an der Entwicklung eines Kernels mitarbeiten konnte, die Linus gehabt hatte, als er sein Projekt öffnete. Die Parallelen zwischen Linux und Debian gehen aber tiefer. Wie Linux zum Teil aus einer Frustration mit Minix heraus entstanden war, hatte Debian seinen Ursprung in der Unzufriedenheit mit SLS: Beide Projekte verwendeten das Internet als Medium der Zusammenarbeit, und beide waren ausdrücklich offen, während Minix und SLS eher kontrolliert und geschlossen waren. Dazu kam, dass sich das Debian-Projekt auch Linus' Idee zunutze machte, einzelne Bereiche vertrauenswürdigen „Leutnants" zu übertragen. Wie Murdock erklärt: „Debian sollte auf der Idee eines Pakets basieren, und jeder, der daran arbeiten wollten, konnten dann die Verantwortung ein solches Paket übernehmen." Er fügt hinzu: „Das Konzept, dass andere Leute untergeordnete Aufgaben übernehmen, entsprach der Funktionsweise von Linux ziemlich genau." Um diesen Ansatz zu verwirklichen, ging er so vor: „Wir definierten Standards und Regeln, die dafür sorgen, dass ein aus einer beliebigen Quelle stammendes Paket gut in das System passt. Das heißt, dass man, wenn man alle diese Pakete nimmt und sie installiert, ein ganzes System bekommt, das aussieht, als wäre es von einem einzigen, eng zusammengeschweißten Team entwickelt worden. Dabei ist das gar nicht die Art, wie es zustande kam." Selbst der Entscheidungsfindungsprozess von Debian orientierte sich an Linux. .Typischerweise war es so, dass wir irgendwann einmal an einen Entscheidungspunkt kamen", erklärt Murdock. „Dann fragte ich die Leute, die an Debian arbeiteten: ,Was meint ihr, was wir tun sollen?' Das fachte üblicherweise die Diskussion an, und oft auch Meinungsverschiedenheiten. Dann traf ich eine Entscheidung", sagt er. „Oft spiegelte sie das wider, was die Gruppe


------------------------------------------------------------------------------------wollte, und manchmal nicht. Genau so funktioniert Linux eigentlich auch." Unter mit der enormen Flut an Reaktionen von Leuten, die daran interessiert waren, am Debian-Projekt mitzuarbeiten, erhielt Murdock im Herbst 1993 eine E-Mail von Richard Stallman zu diesem Thema, „Darin stand: ,Wir lernen mehr über Linux und wir denken daran, es selbst zu vertreiben', denn zur damaligen Zeit dauerte die Entwicklung des GNU-Kernels länger als erwartet", erklärt Murdock. „Sie sahen, wie Linux auf der Bildfläche erschien und einen ziemlich großen Teil des restlichen Systems in Anspruch nahm, das sie zusammengestellt hatten." Das bedeutet, dass die neuen Distributionen den Linux-Kernel mit vielen Elementen des GNU-Projekts zu einem vollständigen Betriebssystem zusammenstellten. „Er sagte im Grunde: „Ich bin interessiert", erinnert sich Murdock. Stallmans Ansatz erwies sich als wichtig für Debian. „Stallmans früh bekundetes Interesse war wichtig - und zwar nicht nur, weil es mir das Selbstbewusstsein gab, um die Sache anzupacken, sondern weil es meiner Arbeit auch eine Aura der Legitimität verlieh", sagt Murdock. „Ich glaube wirklich, dass das in dieser Zeit ausschlaggebend dafür war, dass die Leute Notiz von meinem Projekt nahmen und sich daran beteiligten." Aber Debian war auch für das GNU-Projekt und für Stallman wichtig. „Er lernte Linux im Grunde durch seine Beteiligung an Debian kennen", ist Murdock überzeugt. Es gab zwei Konsequenzen: Erstens kristallisierte sich die Möglichkeit heraus, dass der Linux-Kernel das zehn Jahre davor begonnene GNUProjekt, das zu dieser Zeit durch Verzögerungen bei der Fertigstellung des Hurd-Kernels aufgehalten war, vervollständigen würde. In gewissem Sinn ermöglichte das Debian-Projekt die formelle Vollendung von Stallmans Traum eines frei verfügbaren, unixartigen Betriebssystems. Die andere Folge war, dass Stallmans Free Software Foundation in der Anfangszeit die Entwicklung von Debian sponserte. Murdock erklärt, warum: „Wir brauchten eine Weile, um unsere ersten Versionen herauszubringen. Ein Teil des Problems hatte mit der Tatsache zu tun, dass wir zur Gänze von Freiwilligen abhängig waren und dass wir einen so großen Brocken Arbeit vor uns hatten. Das bedeutet also in einem allgemeineren Sinn, dass ich Geld auftreiben musste, um weiter an


--------------------------------------------------------------------------------------Debian arbeiten zu können, weil die Arbeit, die ich in meiner Freizeit darin investieren konnte, einfach nicht ausreichte" Zum Glück erkannte Stallman diese Notwendigkeit und bot an, Murdock für die Arbeit an Debian über die Free Software Foundation (FSF) zu bezahlen - ein weiteres Beispiel für Stallmans Großzügigkeit, wenn es um die Finanzierung anderer ging, und für die Tatsache, dass er die Bedeutung der Distributionen auf Linux-Basis erkannt hatte. Aber die Beziehung zu dem idealistischen und kompromisslosen Stallman erwies sich als alles andere als einfach. Murdock erklärt die Situation so: „Zu diesem Zeitpunkt war Debian viel größer als ich selbst", sagt er, „und während ich bestimmte Vorstellungen darüber hatte, was Debian eigentlich sein sollte, war meine Meinung längst nicht mehr die einzige. Es gab eine Menge Leute, die mit den Zielen der FSF nicht übereinstimmten." Die Folge war, dass „die FSF Debian sponserte und daher bestimmte Erwartungen an mich hatte; und zu derselben Zeit verlangte ich von den Leuten, in ihrer Freizeit zu arbeiten, und so hatten sie natürlich bestimmte Erwartungen an mich. Manchmal passten diese Erwartungen nicht besonders gut zusammen. Genau genommen waren sie oft ziemlich widersprüchlich", schließt er. Murdock entschloss sich zum Teil wegen dieser Konflikte, im März 1996 die Leitung des Debian-Projekts zurückzulegen. An seiner Entscheidung waren aber noch weitere wichtige Faktoren beteiligt. „Ich wollte mein Studium abschließen", sagt er. „Außerdem hatte ich vor kurzem geheiratet und wollte mehr Zeit mit meiner Familie verbringen. Ich hatte nun drei Jahre lang an dem Projekt gearbeitet, und ich glaube, dass ich auch bereit für etwas Neues war." Sein Nachfolger war Bruce Perens. „Bruce war eigentlich die logische Wahl", sagt Murdock. „Er hatte sich seit langer Zeit mit Debian befasst und er hatte seine Durchsetzungskraft und seine guten Fähigkeiten im Umgang mit Menschen unter Beweis gestellt." Perens erzählt einige weitere Details über die Probleme mit Stallman. „Richard wollte Einfluss auf die technische Richtung nehmen, während die Entwickler, die mit dem Projekt befasst waren, eigentlich keinen Chef wollten", sagt er. „Sie waren allesamt


------------------------------------------------------------------------------------Freiwillige. Wenn sie bereit waren, Anweisungen entgegenzunehmen, dann mussten sie von jemandem kommen, der mit ihnen an dem Projekt arbeitete." Darüber hinaus, so Perens, „hatten wir Einwände gegen manche seiner technischen Anweisungen, weil wir das Gefühl hatten, sie würden die Leistung des Systems mindern und mehr Platz auf der Festplatte verbrauchen. Wir entschlossen uns, nicht einfach damit zu leben, dass die FSF sich das Recht herausnahm, uns Anweisungen zu geben, und so spalteten wir uns ab und gründeten unsere eigene Organisation. Wir dachten, dass wir allein mit Spenden so viel Geld verdienen würden, wie wir brauchten, und das war auch der Fall." Aber die Streitigkeiten hatten damit kein Ende. Einer der DebianEntwickler der frühen Tage war Linus' Freund und Studienkollege Lars Wirzenius. Er erklärt, was passierte: „Als Richard Stallman auf Linux aufmerksam zu werden begann, machte er viel Aufhebens um die Beziehung zwischen der Free Software Foundation und dem GNUProjekt einerseits und der Linux-Gemeinde andererseits," „Er argumentierte, dass die Linux-Gemeinde ohne all die freie Software, die die Free Software Foundation produzierte, gar nicht existieren würde", sagt Wirzenius. „Er hatte auch Recht damit, sein Argument stimmte." Aber aus diesem richtigen Argument zog Stallman laut Wirzenius einen unzulässigen Schluss: „Er entschied, dass Linux auf LiGNUx umbenannt werden sollte." Stallman fand dieses Wortspiel zweifellos unwiderstehlich, weil es sowohl Wortwitz als auch, wie er es sah, Gerechtigkeit widerspiegelte. „Das war einfach schrecklich", erinnert sich Wirzenius, „weil eine starke Bindung unter anderem durch das Recht entsteht, dass die Leute den Namen des Dings bestimmen können, das sie entwickelt haben. Und das GNU-Projekt hatte keinen direkten Beitrag zum Kernel selbst geleistet. Die GNU-Leute hatten nur die Tools dafür gemacht, und die Tools, die gebraucht wurden, um den Kernel zu erweitern. Die Art und Weise, wie Stallman versuchte, seine Wünsche durchzudrücken, war ziemlich unangenehm, und man hatte fast das Gefühl, als würde er alle Mitglieder seiner Gemeinde verraten." Es fühlte sich deshalb an wie Verrat, so Wirzenius, „weil das Match bis zu diesem Zeitpunkt ,Die Leute der


--------------------------------------------------------------------------------------freien Softwaregemeinde gegen die Bösen' lautete, die ihren Quellcode nicht öffentlich zur Verfügung stellten. Aber dann begann Stallman, die Linux-Gemeinde zu bekämpfen, weil er eine Umbenennung von Linux erreichen wollte - oder zumindest hatte es diesen Anschein. „Meine Reaktion war zum Teil dadurch beeinflusst, dass Debian ursprünglich von der FSF finanziert worden war", sagt er, „und das war schließlich sehr nett von ihnen gewesen." Vielleicht wegen dieser früheren Hilfe und trotz dieses hässlichen Vorfalls einigte sich das Debian-Team darauf, seine Distribution Debian GNU/Linux zu nennen. „Der Grund war, dass sich die Debian-Leute mit Stallman darüber einig waren, dass GNU einen so großen Teil des Betriebssystems ausmacht", meint Wirzenius. Perens erklärt: „Richard bat mich, das zu tun, als ich noch Projektleiter von Debian war, und es klang fair für mich. Tatsächlich glaube ich nicht, dass damals irgendjemand [bei Debian] etwas dagegen hatte." Linus hielt sich aus solchen Streitigkeiten meist heraus. „Ich ließ mich nicht allzu sehr darauf ein", sagte er 1996, fügte aber hinzu: „Ich persönlich glaube nicht, dass GNU/Linux ein zündender Name ist; das sollte er aber sein." Und er wies darauf hin, dass „es nicht nur GNUProgramme sind, die wir verwenden." Die X-Windowsoftware kommt zum Beispiel aus der Xfree86-Gruppe. „Deshalb ziehe ich persönlich es vor, es einfach Linux zu nennen und den Leuten Dank auszusprechen, bei denen es angebracht ist. Beim GNU-Projekt ist das sicher der Fall. Der Großteil der [Software-]Literatur von Linux läuft unter dem GNU Copyleft, und ich versuche eindeutig klarzustellen, dass der Kernel nicht alles ist und dass ein Großteil davon GNU ist." Wie auch immer GNU-Software macht auf jeden Fall den Löwenanteil der meisten Distributionen aus, und viele meinen, dass GNU/Linux, auch wenn es als Name nicht „zündend" ist, dieser Tatsache jedenfalls Rechnung trägt. Ebenso wie das Debian-Team hegt lan Murdock keinen Groll gegen Stallman wegen dessen Versuchen, den Entwicklungsprozess zu beeinflussen oder Linux umzubenennen. „Ohne ihn und seine Kompromisslosigkeit, die in den letzten fünfzehn Jahren um keinen Millimeter wankte, gäbe es unser derzeitiges Konzept freier Software nicht", meint Murdock „Ich finde, das muss einmal


------------------------------------------------------------------------------------gesagt werden." Aber er weiß auch, dass „manche Leute nicht meiner Meinung sind" - Stallman neigt dazu, Menschen zu polarisieren. Die Tatsache, dass Murdock Stallman so positiv sieht, überrascht nicht; eines der wichtigsten Motive für die Entwicklung der DebianDistribution bestand von vornherein darin, das zu vereiteln, was er als eine unverantwortliche Kommerzialisierung von GNU/Linux betrachtete: „Ich sah, dass Linux eines Tages ein kommerzielles Produkt werden würde", sagt er, „und ich machte mir Sorgen darüber, wie das vor sich gehen würde." Eines der Probleme mit SLS war, dass es anfing, ein bisschen kommerzialisiert zu werden", fährt er fort. „Man sah Anzeigen in Magazinen, in denen von Linux die Rede war, und einige der Features, die dort beworben wurden, waren schlicht und ergreifend falsch." Er betont: „Es war nicht der Typ, der SLS entwickelte, sondern es waren Leute, die einfach auftauchten und Disketten verkauften." Das war eine wichtige neue Entwicklung, in der erstmals erkennbar wurde, dass Leute außerhalb der GNU/Linux Bewegung in diesem schnell wachsenden Markt eine Geschäftschance sahen. Und es waren diese bescheidenen und nicht nur löblichen Anfänge, die die Grundlage für diese riesige GNU/Linux-und Open-Source-Industrie von heute bildeten. Auch wenn Murdock sich Sorgen über neue, auf SLS basierende Distributionen machte, war es Slackware, der Nachfolger von SLS als die am häufigsten verwendete Distribution, das wirklich an der Entstehung der kommerziellen Linux-Welt beteiligt war. Murdock erinnert sich: „Slackware und Debian hatten im Wesentlichen denselben Ursprung - nämlich den, dass wir beide mit SLS unzufrieden waren. Beide wussten von Anfang an vom anderen, und sobald wir festgestellt hatten, dass es den jeweils anderen gab, meinten wir, nun, vielleicht sollten wir unsere Arbeit zusammen legen. Daraus wurde eigentlich nie etwas, vielleicht zum Teil deshalb, weil wir verschiedene Ziele hatten. Ich wollte den Weg der verteilten Entwicklung einschlagen, und [der Mann hinter Slackware] war daran nicht besonders interessiert. Er meinte, dass es unweigerlich in die Katastrophe führen würde zu versuchen, Dutzende Leute in dieselbe Richtung zu polen. Das war eine


--------------------------------------------------------------------------------------ziemlich schwierige Aufgabe." Offensichtlich teilte er Tanenbaums Ansicht dass es so schwierig sein würde, wie einen Sack Flöhe zu hüten. Während Debian sich zur reinsten Distribution entwickelte, entstanden auf dieselbe Weise wie der Linux-Kernel, übernahm Slackware die Stelle als führende Distribution zunächst von SLS, das Peter MacDonald nicht mehr unterstützte. In der Folge brachte es selbst eine breite Palette neuer Distributionen hervor. In der Ausgabe des Linux Journal vom Juni 1994 - in dem zweiten Interview des neuen Magazins - (das erste wurde mit Linus geführt), sagte der Urheber von Slackware, Patrick Volkerding: „Es wäre schön, mit [Slackware] Geld zu verdienen, aber nicht durch den Verkauf des eigentlichen Pakets." Das zeigt, dass Slackware durchaus zu der früheren, nicht kommerziellen Tradition der GNU/ Linux-Distributionen gehörte, deren Zweck es hauptsächlich war, der Benutzergemeinde zu dienen. Das offizielle Slackware wurde nicht von Volkerding verkauft, sondern von Walnut Creek, das viele populäre CD-ROMs mit freier Software produzierte. Die Einführung der billigen CD-ROM-Technologie Anfang der neunziger Jahre spielte vielleicht eine ebenso entscheidende Rolle für die Kommerzialisierung der GNU/Linux-Distributionen wie es die Einführung der billigeren PCs mit dem 80386 bei der Genesis von Linux selbst getan hatte. Wäre dieses neue Medium nicht zum richtigen Preis verfügbar gewesen, hätten nicht plötzlich Unternehmen floriert, die auf billigen CD-ROMs basierende Distributionen verkauften. Dieser Aufstieg der CD-ROM als verwendbares Verteilungsmedium ist zum Teil Microsoft zugute zu halten. Schon 1987 war Microsoft Bookshelf in dieser Form ausgeliefert worden. Diese Applikation wurde von Microsoft als erste Allzweckanwendung beschrieben, die die Vorteile der CD-ROM-Technologie für Personal Computer zugänglich machte." CD-ROMs als Verteilungsmedium für GNU/Linux waren nicht nur deshalb wichtig, weil sie billig und praktisch waren. Je mehr Programme für GNU/Linux portiert und infolgedessen auf CDs gepresst wurden, desto anregender wirkten sie auf die sich herausbildenden Gemeinde von GNU/Linux-Benutzern. Sie lieferten nicht nur die bitter benötigten Tools und Applikationen,


------------------------------------------------------------------------------------ermöglichten dieselbe verteilte Softwareentwicklung auch über den Linux-Kernel hinaus, wo sie perfektioniert worden war. Schon damals ließ die Attraktivität von GNU/Linux einen Nachmarkt von Applikationen entstehen, die das Betriebssystem ihrerseits noch attraktiver machten. Die Verdrängung der Diskette durch die CD muss einem anderen Unternehmen zugute gehalten werden, das wie Slackware in der Welt von Linux einst in aller Munde war, das aber seit damals in Vergessenheit geraten ist: Yggdrasil Computing, benannt nach dem Weltenbaum der nordischen Mythologie. Der Gründer von Yggdrasil, Adam Richter, hatte am 18. Februar 1993 eine formale Presseaussendung über die erste Betaversion seiner CD-ROM herausgegeben, kaum ein Jahr nach dem Erscheinen der entscheidenden Linux-Version 0.12. Die erste Alphaversion war zwei Monate davor veröffentlicht worden, am 8. Dezember 1992. Der Name dieser Distribution war LGX, eine Ableitung von Linux/GNU/ X, seinen Hauptkomponenten. In der Presseaussendung stand: „Die Yggdrasil-Betaversion ist der erste PC-UNIX(R)-Klon, der im Rahmen seiner Basiskonfiguration Multimediafunktionen beinhaltet. Die Betaversion enthält auch X Window, eine Netzwerkfunktion ... einen einfachen Installationsmechanismus und die Möglichkeit, direkt von der CD-ROM aus zu laufen." Laut Presseaussendung war die Integration von Multimedia, Audio und Video als Teil der Basiskonfiguration ebenso eine Neuheit wie die Möglichkeit, von der CD-ROM aus zu laufen. Das bedeutet, dass man GNU/Linux zunächst nicht zu installieren brauchte; das System konnte nämlich, wenn auch langsam, direkt von der CD-ROM geladen werden, die als eine Art entfembare Read-only-Festplatte fungierte. Ein „einfacher Installationsmechanismus" war ebenfalls eine willkommene Neuerung. Obwohl Yggdrasil Computing ein kommerzielles Unternehmen war (die Betaversion kostete 60 US-Dollar und die endgültige Produktionsversion 99 US-Dollar), ignorierte es die Anhängerschaft der freien Software nicht wie viele andere Unternehmen. Wie in der Presseaussendung erklärt wurde: „Yggdrasil ist den vielen Entwicklern freier Software, deren Arbeit diese Version möglich gemacht hat, sehr verbunden. Als Zeichen unserer Anerkennung erhält jeder, der


--------------------------------------------------------------------------------------einen wesentlichen Beitrag zur LGX-Betasoftware geleistet hat, eine freie Kopie mit CD, Handbuch und Bootdisketten." Eine Yggdrasil-Presseaussendung vom 17. Mai 1994 wies auf einen weiteren Beitrag des Unternehmens zur Welt der freien Software hin: „Fünf Dollar pro Kopie des von Yggdrasil gekauften Motif fließen in die Entwicklung eines freien Motif-Klons." Motif war ein Toolkit für Programmierer, das es ermöglichte, dass das Unix-System einige Merkmale der grafischen Benutzerschnittstellen anbot, die Apple und Microsoft für ihre Betriebssysteme verwendeten. Doppelt auffällig war, dass Yggdrasil Motif führte. Mit einem Preis von 149,95 US-Dollar war es ein teures Stück Software für ein Betriebssystem, das im Wesentlichen frei war. Darüber hinaus war es urheberrechtlich geschützt: Es durfte nicht kopiert werden, und der Quellcode wurde nicht mitgeliefert. Die Tatsache, dass urheberrechtlich geschützte Software zur Verwendung auf einem GNU/Linux-System verkauft wurde, war für Richard Stallman ein rotes Tuch; für ihn bedeutete sie die Sabotage all seiner Arbeit, die er in die Entwicklung von GNU investiert hatte, war es doch sein Ziel gewesen war, es den Benutzern zu ermöglichen, auf die Verwendung urheberrechtlich geschützter Software völlig zu verzichten. Dass Motif nun für GNU/ Linux-User verfügbar gemacht wurde, eröffnete ihnen die ganze Welt der auf Motif basierenden Software. Obwohl diese Software zum größten Teil geschützt und teuer war, wurde damit doch eine weitere Barriere gegen die Verwendung der GNU/Linux-Systeme in traditionellen Geschäftsumgebungen niedergerissen. GNU/Linux konnte ausschließlich auf seinen sich rasant verbessernden technischen Fähigkeiten im Vergleich zu anderen, kommerziellen Unix-Versionen beurteilt werden. Fast zu derselben Zeit, als Yggdrasil diesen schwer wiegenden Schritt setzte, schickte sich auch ein anderes Unternehmen an, freie und geschützte Software miteinander zu vermählen, wenn auch auf andere Weise. 1994 versuchte Mark Bolzern, ein Unix-Datenbankprodukt namens Flagship zu verkaufen, das von dem deutschen Unternehmen Multisoft hergestellt wurde. „Eines der Probleme, mit denen wir konfrontiert waren, war, dass es zu viel kostete, ein Unixsystem aufzusetzen, nur um es auszuprobieren", erklärte er.


------------------------------------------------------------------------------------Dann stieß Bolzern auf GNU/Linux. Es schien die perfekte Lösung zu sein: Er konnte es verwenden, um Flagship fast kostenlos zu demonstrieren. „Also überredete ich Multisoft, einen Port von Flagship für Linux herzustellen, und das war das erste kommerzielle Produkt, das auf Linux veröffentlicht wurde", sagt Bolzern. Aber die Verwendung des freien Betriebssystems brachte auch ihre eigenen Probleme mit sich. „Die Leute hatten immer Schwierigkeiten bei der Installation von Linux", erinnert sich Bolzern, „und dann lief Flagship nicht richtig, weil sich irgendetwas an der CD geändert hatte." Das Problem war, dass sich GNU/Linux ständig veränderte: Jede Distribution war anders. „Ich kam zu dem Schluss, dass eine professionelle Distribution gebraucht wurde, die das Beste herauspickte und die Version dann ein Jahr lang oder so stabil hielt, bevor die nächste herauskam", erklärt Bolzern. Auf diese Weise konnte er sichergehen, dass Flagship leicht zu installieren sein würde. „An diesem Punkt sicherte ich mir den Namen Linux Pro", sagt er, „und suchte mir eine spezifische Distribution von Slackware. Dann führte ich verschiedene Tests durch, um sicherzugehen, dass ich das hatte, was ich für eine gute, solide und stabile CD hielt, und dann spielte ich auch Flagship auf diese CD. Bevor ich überhaupt richtig zum Denken kam, stellte ich fest, dass wir mehr Linux verkauften als Flagship, nicht nur was die Zahlen anbelangt, sondern auch gemessen am Wert. Es waren Hunderte [Kopien von GNU/Linux] pro Monat", die Ende 1994 verkauft wurden. Bolzern war ins GNU/Linux-Vertriebsgeschäft eingestiegen. Laut GNU GPL konnte Bolzern Slackware nicht nur zur Grundlage seiner Distribution nehmen, sondern er konnte es auch problemlos fallen lassen. Bolzern sagt dazu: „Als zum Beispiel die Red-Hat-Distribution herauskam, erkannte ich, dass sie die bessere Lösung war", und so stieg er einfach um und verwendete sie ab diesem Zeitpunkt als Grundlage für Linux. Red Hat war 1993 von Marc Ewing gegründet worden. „Ich begann mit Red Hat, um ein Entwicklungstool zu schaffen, von dem ich überzeugt war, dass die Welt es brauchte", sagte er 1996. „Linux wurde damals eben erst verfügbar, und ich verwendete es als meine Entwicklungsplattform. Ich stellte jedoch bald fest, dass ich mehr


--------------------------------------------------------------------------------------Zeit für das Management meiner Linux-Box aufwendete als für die Entwicklung meiner Software, und daraus schloss ich, dass es eine gute Linux-Distribution war, die die Welt wirklich brauchte. Zu diesem Zeitpunkt gab es nur SLS." Zu dem außergewöhnlichen Namen erklärt Ewing: „Im College pflegte ich den Lacrosse-Hut meines Großvaters zu tragen, der rot und weiß gestreift war. Das war mein Lieblingshut, den ich leider im letzten Jahr irgendwo in Philadalphia verlor. Ich benannte die Firma nach dem Hut. Nun wäre Red and White Hat Software kein besonders zündender Name gewesen, und deshalb änderte ich ihn ein wenig ab." Ewing hatte feste Vorstellungen davon, was den damals aktuellen Distributionen fehlte. „Es war klar, dass Linux viel Hilfe in den Bereichen Installation, Konfiguration und Paketmanagement brauchte", erklärt er. „Bis zu Red Hat gab es eigentlich kein Upgraden auf eine neue Linux-Distribution; man musste jedes Mal neu installieren. Das war ein enormer Nachteil. Es war auch schwer, eine Maschine Schritt für Schritt nachzurüsten. Man hatte entweder den Quellcode und konfigurierte und baute ihn selbst neu auf - wozu manchmal nur eingefleischte Hacker imstande waren. Oder man ging mit vorkonfiguriertem Binärcode ein Risiko ein. Paketmanagement löst solche Probleme." Was an diesen Bemerkungen interessant ist, ist die Tatsache, dass Ewing versuchte, Lösungen für Benutzerprobleme anzubieten. Von Anfang an konzentrierte er sich auf den neuen Markt der technisch weniger versierten Benutzer. Er erklärt dazu: „Linux wird so populär, dass viele Leute ohne Unix-Erfahrung es verwenden, und sie verfügen im Allgemeinen nicht über die geheimnisvollen UnixAdministrationsfähigkeiten, und das brauchten sie unserer Meinung nach auch gar nicht." Das war eine wichtige Entwicklung, weil sie zeigte, wie der Kommerz GNU/Linux in Bereiche bewegte, die Linus und seine Kernelhacker zum Beispiel nicht direkt ansprechen konnten. Das war keine Frage des Programmierer, sondern der Verpackung, und neue Finnen wie Red Hat waren ideal geeignet, um sich dieser Frage zu widmen. Im Gegensatz zu anderen, opportunistischeren Unternehmen glaubte Red Hat uneingeschränkt an die neue Art der Entwicklung


------------------------------------------------------------------------------------und Verteilung von Software. „Die gesamte Software, die wir schreiben, ist GPL-Software", sagte Ewing 1996. Das heißt, dass die Firma, wenn sie das GNU/Linux-System um neue Features erweiterte, diese Features unter GNU GPL frei verfügbar machte, auch für Konkurrenten. Das war etwas Neues und ein frühes Anzeichen für die allgemeineren Auswirkungen, die die Bewegung der freien Software auf die gesamte Computerwdt haben würde. „Unsere Beziehungen zu den Entwicklern freier Software rund um die Welt sind absolut entscheidend", sagt Ewing und räumt ein, dass sein Unternehmen für den nachhaltigen Fortschritt des von ihm verkauften Produkts von ihnen abhängig war. „Wir helfen den Entwicklern, indem wir Hardware und Geld zu Organisationen wie der Free Software Foundation, dem Linux Documentation Project, dem Xfree86 Project und anderen beitragen. Wir bekennen uns absolut zur freien Softwaregemeinde.“ Aber es reichte nicht aus, dass Red Hat sich zur Entwicklergemeinde bekannte. Es musste auch das Vertrauen der Benutzer gewinnen, insbesondere jenes der Unternehmenswelt, die gerade begann, GNU/Linux als Option zu erforschen; das Fehlen direkter Unterstützung von den Entwicklern war eine der Hauptsorgen des Unternehmens. Eine Stärke des GNU/Linux-Entwicklungsmodells bestand darin, dass praktisch jeder Softwareautor direkt via E-Mail oder indirekt via Usenet-Newsgroups kontaktiert werden konnte. Es gibt jede Menge Geschichten über Leute, die Fragen über Softwarebugs posteten und innerhalb von Stunden einen Fix vom Originalautor erhielten. Aber für Unternehmen war dieser neue und ein bisschen improvisiert wirkende Ansatz nicht ausreichend; sie brauchten jemand Zuverlässigen, an den sie sich wenden konnten. Infolge dieser Nachfrage begannen Red Hat und andere GNU/Linux-Distributionen, freie und bezahlte Unterstützung für ihre Produkte anzubieten. „Wir bieten kostenlose Installationsunterstützung für Red Hat Linux an, und wir bieten jenen, die auf langfristige Sicherheit Wert legen, Unterstützungsverträge", sagte Ewing 1996. Ein anderes Argument war, dass sich das Angebot von Unterstützung für GNU/Linux als Schlüsselentwicklung erweisen würde.


--------------------------------------------------------------------------------------Auf der einen Seite bot sie den Unternehmen, die die Verwendung von freier Software in einem geschäftlichen Kontext in Betracht zogen, Sicherheit; auf der anderen - was genauso wichtig war - bot sie Unternehmen eine lebenswichtige neue Einnahmenquclle, die allgemein auch frei verfügbare Software verkaufen. Trotz des wachsenden Erfolgs von GNU/Linux war sich Ewing 1996 immer noch nicht sicher darüber, wie Red Hat letzten Endes in der Wirtschaftswelt abschneiden würde. „Als Lösung, die man einer Sekretärin auf den Schreibtisch knallen konnte, ist Linux im Augenblick sicher nicht geeignet", räumt er ein. „Unsere Applix-ware Produkte" geschützte Software von Apptix und eine der frühestens Geschäftsapplikationen für GNU/Linux - „bereichert Linux um eine qualitativ hochwertige Office Suite, aber ansonsten gibt es nicht viele andere Endbenutzerapplikationen. Wie sich das über die Jahre hinweg entwickeln wird, bleibt abzuwarten." Zusammenfassend beschreibt er die Frage, wie wichtig GNU/ Linux in einem Geschäftskontext werden wird, als die „Millionen-Dollar-Frage". Ewing lag um einen Faktor von 1000 daneben: Nur drei Jahre später betrug der Wert von Red Hat mehrere Milliarden Dollar. Und doch war 1996 das Unternehmen, von dem fast alle erwarteten, dass es der Toplieferant von GNU/Linux an Unternehmen sein würde, nicht Red Hat, sondern Caldera. Selbst Linus sagte 1996, dass Caldera Red Hat beim Ansprechen des Firmenmarktes „irgendwie einen Schritt voraus ist". Er fuhr fort: „Ich glaube, das Interessante an Caldera ist, dass ihre Sachen hauptsächlich auf Red Hat basieren und dass sie sie dann um einen irgendwie kommerziellen Ansatz erweitern." Caldera begann als Projekt innerhalb von Novell, dem damaligen Führer im Bereich Firmennetzwerkprodukte und Unix-Eigentümer. Der Mann hinter dieser Arbeit, die ursprünglich den Codenamen „Expose" trug und später „Corsair" genannt wurde, war Bryan Sparks. „Wir führten bei Novell im letzten Jahr, in dem ich dort war, ein Forschungsprojekt durch und verwendeten dabei Linux, um Technologien mithilfe nicht traditioneller Entwicklungsmittel herauszubringen", erinnerte er sich 1996, als er CEO von Caldera geworden war.


------------------------------------------------------------------------------------„Leider gab es im Management von Novell einige Veränderungen. Ray Noorda [der Gründer von Novell] ging, und ein neuer Präsident kam." Die Prioritäten änderten sich: „Wie auch immer, das Projekt verlief irgendwie im Sand", sagt Sparks, Aber an diesem Punkt hatte er bereits Feuer gefangen. „Ich war von der Idee besessen, dass wir hier etwas wirklich Interessantes machen konnten. Also wendete ich mich an Ray, der nun nicht mehr bei Novell war, und fragte, ob er diese Idee extern finanzieren würde. Ich bin dankbar, dass er Ja sagte." Es ist interessant, wie Sparks die Ziele des von Noorda finanzierten Start-up-Unternehmens beschreibt: „Unser Ziel ist es, Linux möglichst gut voranzubringen", sagt er. „Wir wollen ein Teil der Linux-Gemeinde sein, aber was für uns vielleicht noch wichtiger ist: Wir wollen auch kommerzielle Produkte in der Linux-Umgebung anbieten und ein Produkt schaffen, das kommerziell attraktiver ist." Caldera, wie dieses Produkt genannt werden sollte, wurde eigens zu dem Zweck entwickelt, Linux mit kommerziellen Produkten zu „umgeben", um seine Attraktivität für Firmen zu steigern. Caldera wurde im Oktober 1994 gegründet, und Betaversionen des ersten Produkts der Firma, des Caldera Network Desktop (CND), kamen 1995 heraus. Die endgültige Version wurde im Februar 1996 veröffentlicht und verfügte über einen neuartigen grafischen Desktop, der an Windows 95 erinnerte. Dieser „spiegelartige" Desktop, wie er genannt wurde, war ebenso urheberrechtlich geschützt wie mehrere andere Applikationen, die Caldera in einem Bündel mit dem Paket lieferte. Da es nicht leicht war, sie zu trennen, war es problematisch, legale Kopien der Caldera-Distribution anzufertigen, ein gefährlicher Präzedenzfall für die neue Welt des kommerziellen GNU/Linux. Caldera gewann auch keine Freunde, als es entschied, sein Produkt auf OpenLinux umzutaufen, weil damit irgendwie suggeriert wurde, dass alle anderen GNU/Linux-Distributionen nicht offen waren. Manche verglichen diesen Schritt mit Stallmans Versuch, Linux auf „LiGNUx" umzubenennen. Es gab drei Versionen von OpenLinux. „Wir entwickeln ein extremes Low-end-Produkt für die Linux-Gemeinde, für die Hacker im Netz", erklärt


--------------------------------------------------------------------------------------Sparks. „Dann gibt es zwei andere Produkte, die für Wiederverkäufer und für die kommerzielle Umgebung gedacht sind. Sie haben viel mehr kommerzielle Komponenten, Features, Managementfähigkeiten und so weiter." Die kommerziellen Komponenten wurden auf einer separaten SolutionsCD geliefert und waren Ports von Applikationen großer Softwareanbieter wie der deutschen Software AG, die die schwergewichtige Adabas D Datenbank produzierte. Wie Sparks feststellte: „Eines der schwierigsten Dilemmas, vor denen wir und alle stehen, die ein neues Betriebssystem oder Produkte auf Systemebene einfuhren wollen, besteht darin, dass man die Applikationsbasis haben muss. Ein Betriebssystem an und für sich bietet nur eine bestimmte Gruppe von Lösungen, eine ziemlich enge Nische, aber wenn man es mit Produkten Dritter bündeln kann, ist die Palette von Lösungen, die es anbieten kann, ziemlich breit." Die Ports für kommerzielle Software entstanden oft auf eigenartige Weise. Sparks erklärt: „Die Partnerschaft mit der Software AG rührte irgendwie von der Tatsache her, dass viele Leute innerhalb der Software AG, vor allem die Ingenieure, zu portieren begonnen hatten, ohne dass irgendjemand davon wusste - das ist nicht ungewöhnlich, wie wir meinen. Wir riefen vor nicht allzu langer Zeit eine Firma an und sagten, wir mächten mit Ihnen über Ihren Linux-Port sprechen, und sie bestanden darauf, dass sie keinen hätten, obwohl wir wussten, dass das nicht stimmte. Also sagten wir, gut, vielleicht sollten Sie bei Ihren Ingenieuren nachfragen, denn in Wirklichkeit haben Sie natürlich einen Port." Die Einführung dieser urheberrechtlich geschützten kommerziellen Pakete ermöglichte es, dass GNU/Linux-Systeme in vielfältigen Applikationen als Lösungen angeboten wurden. Aber Caldera neigte dazu, sich auf einen Bereich zu konzentrieren, in dem GNU/Linux nicht besonders stark war. Wie Sparks meinte: „Viele Leute halten Linux für eine Art Hacker-Unix, und dann kommen wir und sagen, ja, stimmt schon, aber wisst ihr eigentlich, was es in Wahrheit ist? Linux ist ein Verbindungsprodukt. Wenn Sie eine Verbindung zu Ihrem entfernten Büro oder zum Internet haben wollen oder wenn Sie eine Verbindung zu diesem oder jenem


------------------------------------------------------------------------------------Peripheriegerät wollen, dann kann Linux das für Sie bewerkstelligen." Das war in mehrerlei Hinsicht ein kluger Schritt von Caldera. Zur damaligen Zeit begannen immer mehr Unternehmen, das Internet zu verwenden, und viele IT-Abteilungen mussten zwei anscheinend widersprüchlichen Anforderungen gerecht werden: erstens ihre Firma schnell und mit zuverlässiger Software online bringen und das zweitens ohne zusätzliches Budget. Die GNU/ Linux-Systeme boten dafür die perfekte Lösung. Sie waren inzwischen robust und doch extrem kostengünstig. Die Folge war, dass viele Unternehmen GNU/Linux verwendeten, ohne es auch nur zu wissen. Sparks beschreibt eine typische Situation: „Wir riefen verschiedene Unternehmen an", erzählt er. „Ein Typ von der MIS-Abteilung [Management Information Systems] einer großen Firma hier in den Vereinigten Staaten sagte: ,Wir verwenden Linux für Gateways und andere Dinge, um alle unsere Internetsites anzuhängen. Mein MISLeiter stellte eben erst fest, dass ich unsere Firma mit Linux fahre.' Und er fuhr fort: ,Mein MIS-Leiter sagte, nein, das ist nicht möglich, wir können die Firma nicht mit freier Software fahren.' Also wandte er sich an mich um Hilfe, und ich sagte: ,Doch, natürlich können Sie das.' Wir beriefen eine Sitzung ein, und ich trat vor und sagte: ,Ja, Linux ist frei, aber wir sind ein echter Lieferant. Wenn ihr Probleme habt, werden wir die Schuld auf uns nehmen. Wir werden die Sache für euch reparieren und für mehr Mehrwert sorgen, als ihr erwartet hättet.' Und es ist sehr typisch, dass wir diese Art Präsentation hier in den Vereinigten Staaten inzwischen Dutzende Male gemacht haben." Das ist ein interessanter Beweis dafür, dass GNU/Linux in den Unternehmen bereits weit verbreitet war, dass sich aber nur wenige zu seiner Verwendung bekannten. Mark Bolzern bestätigte das. Etwa um dieselbe Zeit, 1996, sagte er: „Fast alle Fortune-500-Unternehmen haben unser Produkt gekauft und verwenden es auf vielfältige Weise. Aber in den meisten Fällen ist das Management noch nicht darüber informiert und bestreitet es." Er fügt hinzu: „Selbst Microsoft verwendet unser Linux intensiv und hat Hunderte von Kopien gekauft."


--------------------------------------------------------------------------------------Neben dieser Flut verborgener kommerzieller Aktivitäten, die direkt auf GNU/Linux-Software basierten, begannen sich Hilfssektoren herauszukristallisieren. So schossen zum Beispiel Unternehmen aus dem Boden, die fertige Systeme anboten, die für GNU/Linux optimiert waren. Eines der frühesten davon war VA Research, eine Firma, die sich zu einem der wichtigsten Marktteilnehmer der GNU/ Linux-Welt entwickeln sollte. Ihr Gründer war Larry Augustin, 1962 geboren in Dayton, Ohio. „Ich war damals gerade dabei, mein Elektrotechnikerstudium in Stanford zu beenden", erzählt er. „Einen Großteil unserer Arbeit erledigten wir zu dieser Zeit auf Workstations von Sun. Ich dachte, wenn ich zu Hause eine Unix-Workstation hätte, würde ich viel effizienter arbeiten und mein Studium früher abschließen können. Nun, eine Sun SparcStation die damals rund 7.000 Dollar kostete - konnte ich mir nicht leisten, aber ich hatte da dieses Ding namens Linux gesehen." Er entschloss sich, sein System selbst zusammenzustellen und es mit GNU/Linux zu betreiben. „Es gelang mir, eine Maschine für etwa 2.000 Dollar zusammenzubauen, die anderthalb Mal schneller war als die 7.000 Dollar teure Sun-Maschine." „Als andere Leute sahen, was ich da zusammengebaut hatte, sagten sie: „Gee, könntest du nicht für mich auch so eine Maschine zusammenstellen?", erinnert sich Augustin. „Also begann ich Geld damit zu verdienen, dass ich diese Systeme zusammenstellte." Am Anfang verkaufte Augustin die Systeme über eine bereits bestehende Firma namens Fintronic. Obwohl sein Geschäft bald ins Rollen kam „etwa ein Jahr später hatte ich drei Vollzeitangestellte, die nur damit beschäftigt waren, Systeme zusammenzubauen", erzählt Augustin -, nahm sein Leben bald eine andere Wendung. In seiner Studienzeit hatte er zwei Kollegen kennen gelernt, Dave Filo und Jerry Yang, „Dave und Jerry harten damit begonnen, ein Verzeichnis von Internetsites zu erstellen", sagt Augustin, „und in Stanford wurde es ihnen langsam zu eng." Zur damaligen Zeit hatte Augustin das Internet ebenfalls bereits entdeckt. „Ich hatte diese Webseite im November 1993 eingerichtet, und das war etwas wirklich Neues. Damals hatte noch nicht einmal Intel eine Website, die diesen Namen verdiente, Intel listete auf seiner Homepage fünf


------------------------------------------------------------------------------------Unternehmen auf, die Systeme [mithilfe von Intel-Prozessoren] über das Internet verkauften. Wir waren eine davon." Die Folge ihres gemeinsamen Interesses war, wie Augustin sich erinnert: „Dave Filo, Jerry und ich sagten: ,0h, in diesem Internet scheinen sich interessante Dinge zu tun. Wir sollten darüber nachdenken, wie wir ein einschlägiges Unternehmen gründen können. Ich richtete eine ziemlich gute E-Commerce-Firma über das Internet ein, sie hatten dieses Verzeichnis zusammengestellt, und so begannen wir gemeinsam, einen Businessplan zu erstellen, in dem wir festlegten, wie wir Unternehmen rund um das Internet aufbauen konnten." Trotzdem beschlossen sie letzten Endes, „mit diesem Internetverzeichnis, das sie zusammengestellt hatten, etwas zu tun", erklärt Augustin. „Ich überlegte und sagte; ,Hm, das ist nur Marketing.' Ich will doch Computer bauen, oder? Also trennte ich mich von den beiden und baute weiterhin Systeme rund um Linux zusammen." Was er als „nur Marketing" beschreibt, würde bald das dominante Internetunternehmen Yahoo! sein und einen Wert von Milliarden US-Dollar haben. Aber Augustin bedauert nichts, nicht zuletzt deshalb, weil es auch seinem eigenen Unternehmen gut ging. VA Research wurde im Februar 1995 aus Fintronic ausgegliedert. „VA" stand für Vera und Augustin: „James Vera hatte die Firma ursprünglich mit mir gegründet, als wir noch in Stanford waren", erklärt Augustin. Die Börseneinführung von VA Research im Jahr 1999 erzielte den größten Kursgewinn aller Zeiten, auch wenn das nur wenige geglaubt hätten, wenn sie das schmuddelig aussehende Schwarz-Weiß-Inserat einer komischen Firma namens „VA Resarch" betrachteten, das in der Juli-Ausgabe des Linux Jounal im Jahr 1993 erschienen war. Das dort angebotene Topsystem war ein 90 MHz Pentium mit 16 Mbytes RAM und 1 Gigabyte Harddisk für 3.755 US-Dollar mit 17-Zoll-Monitor. Augustin sagt: „Wir waren einer von vier Inserenten in der ersten Ausgabe des Linux Journal", das im Mai 1994 erstmals erschien. Der Mann hinter der ersten Papierpublikation über die GNU/Linux-Welt war Phil Hughes, „1993 begann ich mich mit Freunden über die Idee zu unterhalten, ein Magazin über Freie


--------------------------------------------------------------------------------------Software zu gründen", erinnert er sich. „Wir stellten schnell fest, dass wir es uns nicht leisten konnten, etwas Derartiges zu starten, weil es, um objektiv sein zu können, keine Werbung enthalten durfte. Ich schlug ursprünglich im Scherz - vor, dass wir ein Magazin gründen sollten, das sich ausschließlich mit Linux befasste." Nach verschiedenen Problemen wurde das Linux Journal schließlich mithilfe des in Kanada geborenen Unternehmers Bob Young gestartet. Zu dieser Zeit gab Young einen lokalen Newsletter namens New York Unix heraus und führte den ACC Bookstore, der viele GNU/LinuxDistributionen und -Bücher verkaufte. Young fusionierte sein Unternehmen später mit Red Hat und bereicherte Ewings technisches Wissen mit seinem wertvollen Verkaufs- und Marketingwissen. Hughes sagt: Wir begannen mit vier Leuten: Bob als Herausgeber, ich als Chefredakteur, jemand für das Layout und ein TeilzeitAnzeigenverkäufer. Wir hatten zwei Büros: Verlag und Layout in einem Extrazimmer in Bobs Haus, Redaktion und Anzeigenverkauf in meinem Keller. Von den ersten beiden Ausgaben druckten wir 20.000 Exemplare. Als die zweite Ausgabe gerade in Druck gehen sollte, erkannten sowohl Bob als auch ich, dass diese Konstellation nicht funktionieren würde. Ich beschloss, dass das Linux Journal in SCC [einen Verlag, den wir 1983 gegründet hatten], eingebracht werden sollte, damit Bob und ich die Verluste, die zu dieser Zeit anfielen, aufteilen konnten. Außerdem steifte ich einen Redakteur ein, Michael Johnson [ein Linux-Hacker der ersten Zeit] und übernahm die Verlegerpflichten. Zum damaligen Zeitpunkt hatten wir 926 Abonnenten. Nun gab es nicht nur ein Magazin über GNU/Linux, es begannen auch die ersten Bücher zu erscheinen. Einer der Pioniere auf diesem Gebiet waren O'Reilly et Associates, damals bestens bekannt für ihre Bücher über Unix. Titel wie Running Linux und Linux Network Administrator's Guide erwiesen sich nicht nur als unschätzbares


------------------------------------------------------------------------------------Referenzmaterial für GNU/Linux-User, sondern brachten den jeweiligen Autoren, Matt Welsh und Olaf Kirch, auch einige Einnahmen für ihre mehrjährige Arbeit an der Dokumentation von GNU/Linux. Linux Journal, ACC Bookstore, O'Reilly & Associates und andere trugen dazu bei, die GNU/Linux-Botschaft durch verschiedene Aktivitäten und durch Werbung zu verbreiten. Weitere Marketingaktivitäten kamen von einer Gruppe, die mit dem Ziel einer nicht kommerziellen Verkaufsförderung gegründet worden war. Gründer von Linux International war Patrick D'Cruze, der damals Student in Australien war. Wie er in einem Posting an die Mailingliste der LinuxAktivisten am 2. März 1994 geschrieben hatte, war es „eine neue, nicht gewinnorientierte Organisation", deren Hauptziel „internationale Vermarktung und Unterstützung von Linux sind. Es ist vorgesehen, eine geeignete Marketingkampagne zu lancieren und die ,Linux-Lösung' in den allgemeinen Medien und bei potenziellen Kunden zu propagieren." Trotz dieses Marketingschwerpunkts waren es hauptsächlich Tophacker wie Alan Cox und Ted Ts'o, die ursprünglich bei Linux International aushalfen. Aber als die junge Linux-Industrie wuchs, wurden immer mehr ihrer Teilnehmer eingebunden. Bob Young war einer davon, und bei der Comdex im Herbst 1994 unterhielt er sieh zufällig mit Mark Bolzern über Linux International. Bolzern erinnert sieh: „Ich sagte: ,Oh, wenn es eine Firma gibt, deren Zweck es ist, GNU/Linux bekannt zu machen, dann lasst sie uns doch nach unseren Wünschen umgestalten, statt eine neue zu gründen." Nachdem er eingeladen worden war, zu Linux International zu gehen, sagte Bolzern: „Damals wurde ich irgendwie automatisch zum Marketingmann hinter Linux International." Als Linux International aktiver begann, sich der Werbung für GNU/Linux zu widmen, wurde Bolzern zur halboffiziellen Marketingkraft hinter der gesamten Bewegung, Bolzern erklärt sein Ziel zur damaligen Zeit: „Ich dachte, die beste Möglichkeit, das Ziel von Linux International, die Entwicklung von Linux und seine kommerzielle Promotion wohlwollend zu fördern, bestünde darin, die Händler einzubinden." Das war eine wichtige Änderung des anfänglichen Ansatzes von Linux lnterna-


--------------------------------------------------------------------------------------tional, eine Änderung, die die Kräfteverschiebung in der Welt von GNU/Linux widerspiegelte. Der Grund, den Bolzern nannte, war einfach: „Die Händler waren diejenigen, die Grund hatten, Geld für die Werbung für Linux auszugeben", sagt er. Bolzern kam zu dem Schluss, dass die beste Möglichkeit zur Einbindung der Händler -und damit zur Kooperation anstelle von Konkurrenz - darin bestand, GNU/Linux bei großen Messen bekannt zu machen, damit die Firmen über Linux International damit in Zusammenhang gebracht werden wollten. Bei der nächsten großen Messe, der UniForum, die im März 1995 in Dallas, Texas stattfand, setzte er seine Pläne um. „Ich kam zu dem Schluss, dass die beste Methode zur Lancierung von Linux International darin bestand, auf größeren Messen Pavillons oder Bereiche einzurichten", erklärt Bolzern, „wo wir von einer Gruppe kleinerer Linux-Lieferanten gemeinsam viel mehr Aufmerksamkeit bekamen, als jeder von uns einzeln hätte bekommen können." Bolzern organisierte auch die so genannten „Bird of a Feather"Sitzungcn - informelle Gespräche - die auf der Messe über GNU/ Linux geführt wurden. „Schließlich platzten wir bei den ,Birds of a feather'Sitzungen aus allen Nähten, und das fiel Softbank Comdex - dem Organisator der Messe - auf." Das war genau das, was Bolzern wollte, weil Softbank Comdex, wie er sich erinnert, „loslegte und uns für die [Comdex] im Herbst 1995 beauftragte, einen Pavillon mit sechs Ständen zusammenzustellen, und ihr Beitrag war der Stand von Linux International." Diese Arbeit der Linux-Bewusstseinssteigerung wurde 1995 gekrönt, als Bolzerns eigene Distribution Linux Pro für Best of Comdex nominiert wurde. Das gab Bolzern in Anbetracht der Tatsache, dass GNU/Linux in der weiteren Computerwelt zu diesem Zeitpunkt noch fast unbekannt war und dass die Comdex die führende Fachmesse der Computerwelt war, gewaltigen Auftrieb. Wie Bolzern sich erinnert: „Als uns dieser Preis zuerkannt wurde, ging [den GNU/Linux-Verkäufern] plötzlich ein Licht auf: Hey, wenn wir uns zusammentun, können wir mehr Aufmerksamkeit erregen als jeder von uns einzeln". Das war sein ursprüngliches Ziel gewesen.


------------------------------------------------------------------------------------Bolzern betrachtet diesen Preis als Wendepunkt von Linux International; vielleicht war er auch ein Signal für die junge Händlergemeinde, wenn diese erkannte, dass in ihrem Kampf, GNU/ Linux zu einer akzeptablen Alternative für Unternehmen zu machen, im Wesentlichen alle auf derselben Seite kämpften und dass es mehr gab, was sie verband, als was sie trennte. Die Entwicklung von Linux International zu einer auf Verkäufern basierenden Organisation, die Geld für die Werbung für GNU/ Linux ausgeben konnte, zeigte, dass sich in der Welt der freien Software nicht nur eine neue Kraft herauskristallisiert hatte, sondern auch, dass diese in einer symbiotischen Beziehung zu Hackern und Benutzern stand. In dieser Hinsicht spiegelt sie Linus' eigene Position in der LinuxGemeinde wieder, wo seine fuhrende Position, wie er Tanenbaum 1992 erklärte, davon abhängt, ob er dieser Gemeinde dient und sich ihren Respekt erhalten kann. Aber die interessanteste und weitreichendste Auswirkung von all dem war, dass nun, da die Unternehmen in die Welt von GNU/ Linux eintraten und es drastisch zu verändern begannen, das, was als reine Hackerbewegung begonnen hatte und aus einer neuen Methode des Schreibens und Verteilens freier Software geboren worden war, nun seinerseits begann, die Grundlagen des Betriebs von Unternehmen zu verändern. Die zunehmende Kommerzialisierung bedeutete, dass die Welt von GNU/Linux nie mehr so sein würde wie früher - aber dasselbe galt auch für die Welt der Unternehmen.

7

Linus 2.0

VERÄNDERUNGEN GAB ES NICHT NUR BEI LINUX, sondern auch bei Linus. Es stimmte zwar, dass er sich vom „User Space", wie er ihn nannte von allem, was nicht direkt mit dem Kernel zu tun hatte, von Endbenutzeranwendungen bis hin zu den Distributionen -weiterhin fernhielt. „Ich bin eigentlich gar nicht auf dem Laufenden", sagte er 1996. „Ich bin so auf den Kernel fixiert, dass mir andere Dinge wie Packaging sogar aus technischer Sicht egal sind." Das ist typisch für die leise Verachtung, die Hacker für die Distributionen haben. Das, was ihn an der zunehmenden Kommerzialisierung seines Kernels am ehesten interessierte, waren die technischen Vorteile, die sie möglicherweise mit sich bringen würde. „Der Markt an sich interessiert mich überhaupt nicht", sagte Linus, „aber ich finde es sehr interessant zu beobachten, dass Linux


------------------------------------------------------------------------------------an verschiedenen Einsatzorten verwendet wird. Das ist meiner Meinung nach gut. Es sollte nicht unbedingt kommerziell eingesetzt werden, aber auch das sollte möglich sein. Ich denke, dass man, wenn ein System auf immer mehr Märkten erprobt wird, mehr über die Schwächen dieses Systems erfährt. Davon erwarte ich mir interessantes Feedback." Obwohl er weiterhin jede Möglichkeit nützte, um seinen Code zu verbessern, begann sich auch er mit Gedanken über eine Marketingkampagne zu tragen. Immer mehr Leute bekundeten ihr Interesse an GNU/Linux - und Linus selbst -, und so fing er an, Vorträge bei Messen und Konferenzen zu halten. Das Reden in der Öffentlichkeit fiel ihm nicht leicht. „Ich musste mich beim ersten Mal wirklich dazu zwingen. Ich war wahnsinnig aufgeregt und ängstlich. Das Ganze war mir schrecklich unangenehm, aber ich wusste, dass ich es tun musste, weil ich immer mehr Einladungen bekam." Die erste dieser Einladungen hatte Linus abgelehnt. „Ich sagte Nein zu einer Einladung nach Madrid", sagt er. Das war eine UnixKonferenz im Frühling 1993 gewesen. „Linux war damals noch nicht besonders bekannt", sagt er, „aber es begann langsam zu einem Thema für die Leute zu werden." Und trotzdem: „In Wirklichkeit wollte ich gern fahren", sagt er. Jen war noch nie in Spanien gewesen, aber ich hatte zu viel Angst, dort vor Publikum sprechen zu müssen." „Das Ganze war mir so unangenehm, dass ich mich entschloss, bei der nächsten Konferenz nicht mehr zu kneifen. Also hielt ich in Holland meinen ersten Vortrag vor fünfhundert Leuten." Das erforderte beträchtliche Selbstüberwindung. „Ich hatte noch nie einen Vortrag gehalten", erklärt er. „Diesen musste ich noch dazu in einer fremden Sprache - auf Englisch - halten. Ich war schrecklich nervös, die Nacht davor tat ich kein Auge zu, allen fiel auf, wie zerschlagen ich war. Aber es war eine Art Schockbehandlung, das Eis war gebrochen und das Reden fiel mir in Zukunft leichter." Eine der ersten Veranstaltungen, bei denen er sprach, war das Treffen der DECUS, der Digital Equipment Corporation User's Society, das im Frühjahr 1994 in New Orleans stattfand. Er war von Jon „Maddog" Hall, Senior Marketing Manager der Unix Software Group von Digital eingeladen worden. Hall hatte bis zu diesem

7. Linus 2.0

--------------------------------------------------------------------------------------Zeitpunkt noch nie von GNU/Linux gehört, aber ein Kollege namens Kurt Reisler hatte ihn überredet, Linus die Reise zu bezahlen. Wie Hall in einem Artikel schrieb, der in der Oktoberausgabe 1995 des Linux Journal erschien: „Ich hatte meine Zweifel gehabt, ob ich diese Reise wirklich finanzieren sollte, als ich sah, wie Kurt sich mit der Installation von Linux auf diesem ersten PC abmühte. Aber mit etwas Hilfe von Linus bekam er ihn hin. Da sah ich das Betriebssystem zum ersten Mal in Aktion, und in weniger als zehn Minuten hatte ich mich davon überzeugt, dass dies ,Unix genug für mich' war." Das Ergebnis war, dass Hall Digital überredete, Linus einen starken PC zu überlassen, der auf dem Alpha-Mikroprozessorchip des Unternehmens basierte. Die Idee war, dass Linus Linux für diese Architektur portieren würde, die vollkommen anders war als die Architektur der Intel-Chips normaler PCs. Unix war zum portierbaren Betriebssystem par excellence geworden einer der Gründe, warum Richard Stallman es zum Modell seines GNUProjekts gemacht hatte. Linux hatte sich im Gegensatz dazu aus der schrittweisen Erforschung des 80386-Prozessors entwickelt; die ersten Linux-Versionen enthielten sogar Code, der für diesen Chip in Assembler geschrieben worden war. Aus diesem Grund hatte Linus in seiner ersten offiziellen Ankündigung des Linux-Projekts am 25. August 1991 gesagt, dass es nicht portierbar sei. Später erklärte er dazu: „Der Grund, warum Linux zuerst eigentlich nicht portierbar war, war nicht, dass ich die Portierbar-keit schlecht konzipiert hatte, sondern dass ich sie für irrelevant hielt. Deshalb glaubte ich nicht, dass irgendjemand ein Interesse daran hätte. Da die PC-Plattform so gut ist, was das Preis-Leistungs-Verhältnis betrifft, erschien es mir nicht besonders sinnvoll, ein Linux zu entwickeln, das für irgendetwas anderes portierbar war. Vor allem wo die meisten anderen Architekturen bereits perfekte Betriebssysteme hatten. Das änderte sich erst in den letzten paar Jahren, weil Linux so gut wurde, dass es plötzlich auch dann Sinn machte, wenn es Alternativen gab." Obwohl Linus das Gegenteil behauptete, war die Möglichkeit, Linux auf anderer Hardware zu verwenden, zu attraktiv für die


------------------------------------------------------------------------------------Hacker, um ihr widerstehen zu können. Die Folge war, dass viele Projekte begonnen wurden; Linux würde letzten Endes für eine riesige Bandbreite von Architekturen verfügbar sein, von solchen, die von Mikrocomputern wie dem Amiga und dem Atari (beide basierend auf der Motorola-Prozessorfamilie 68000) oder der PowerPC-Plattform (verwendet von Apple und IBM) bis hin zu solchen, die von leistungsstarken Workstations der Industriekategorie mit MIPS-R4000Prozessoren verwendet wurden. Eines der wichtigsten Portierungsprojekte war jedoch ohne Zweifel der Spare Prozessor von Sun. Der Spare ist nicht nur deshalb von großer historischer Bedeutung, weil er GNU/Linux auf einem der leistungsstärksten Hardwaresysteme, das in der Geschäftswelt weithin verwendet wurde, verfügbar machte, sondern auch, weil er von Dave Miller initiiert und entwickelt wurde, der zu einem der wichtigsten Linux-Leutnants werden sollte. Miller wurde 1974 in New Jersey geboren. Der fünfjährige Altersunterschied zwischen ihm und den anderen Spitzenhackem wie Linus, Alan Cox, Ted Ts'o und Stephen Tweedie bedeutete in der Hackerwelt fast eine ganze Generation. Millers Vater machte bereits „irgendetwas mit Computern", wie Miller sagt, und seine Mutter führte mehrere Einzelhandelsgeschäfte. Als Junge hatte Miller mit AtariMikrocomputern gespielt, die aber nicht zu seiner großen Leidenschaft wurden. Nachdem er eine Zeit lang mit Computern gearbeitet hatte» „wendete ich mich anderen Dingen zu, bis ich zu studieren begann", erzählt er. „Ich fuhr Skateboard, spielte drei Jahre lang Gitarre und profilierte mich dann gegen Ende der Highschool etwa zwei Jahre lang als Partytiger." 1991 ging er an die Penn State University, wo er das erste Mal mit GNU/Linux in Kontakt kam. Ich glaube, das erste Mal, dass ich Linux verwendete, war an einem der C-Login-Terminals im Computerlabor der Penn State", erinnert er sich. „Ich bootete es im Einzelbenutzermodus von einer Diskette aus und spielte einfach ein bisschen am Shellprompt herum. Das war nicht viel, aber für mich war es damals etwas Neues, was mir Spaß machte. Wenn ich mich recht erinnere, wurde ich an diesem Tag aus dem Labor geworfen, weil ich nur herumspielte. An nächsten Tag kam ich einfach wieder und spielte weiter." Im Gegensatz zu seinen Hackerkollegen hatte

7. Linus 2.0

--------------------------------------------------------------------------------------Miller noch kaum Vorerfahrung mit der Unix-Kultur. „Ich glaube, ich hatte zweimal mit Unix gearbeitet, bevor ich Linux herunterlud", sagt er. „Als ich mir den Quellcode anzusehen begann, hatte ich überhaupt keine Vorstellung, was ich da eigentlich vor mir hatte", erklärt Miller. „Ich kannte nicht einmal C." Trotz seiner mangelnden Erfahrung mit Unix hackte Miller schnell am Kernelcode und schickte Linus seine Ergebnisse, „An diesem Punkt kannte ich C zwei Tage lang", erzählt er, „und ich hatte keine Vorstellung von dem, was ich da tat. Ich glaube, dass mir Linus in etwa antwortete: ,Wahrscheinlich wäre es eine bessere Idee, dies oder jenes zu versuchen ...' Man stelle sich das vor: Ich hatte keine Ahnung, überhaupt keine Vorstellung von dem, was ich tat, und trotzdem schickte er mir Vorschläge, als wüsste ich, wovon ich redete.' Miller betont: „Es ist wahrscheinlich dieser Charakterzug von Linus, der uns dorthin gebracht hatt wo wir heute stehen. Wenn man mit so viel Achtung behandelt wird, steigt die Motivation, an einem solchen Projekt mitzuarbeiten." Miller blieb nur ein Semester lang an der Penn State University. Nachdem er erkannt hatte, dass er „dort nicht hin gehörte", ging er nach Rutgers. Dort startete er seine Karriere als GNU/Linux-Hacker, aber nicht die eines Wissenschaftlers, obwohl er Computerwissenschaften studierte. „Ich hatte eine Zeit lang auch ein Chemiestudium in Betracht gezogen, aber bald entschloss ich mich, lieber mit Linux herumzuspielen als mir irgendein Zeug anzuhören, von dem irgendein Besserwisser erwartet, dass ich es bei einem Test wieder ausspucke", erzählt er. „Mein letztes Semester war Perfektion in Reinkultur Ich fiel in allen Kursen durch." Zum Glück hatte sich Miller neben seinem Studium einen Job als Student System Administrator im Center for Advanced Information Processing (CAIP) am Campus der Universität zugelegt. „Meine Arbeit im CAIP-Forschungszentrum war der Anfang von allem", sagt er. „Durch sie hatte ich Zugang zu jeder Menge toller Computer der verschiedensten Typen. Da gab es zum Beispiel Sun-Maschinen, alte und neue, einige HP Workstations, ein paar PC-Systeme, SGI Server und Workstations, was immer man wollte. Ich war der Computerfreak im Eldorado."


------------------------------------------------------------------------------------„Mir war aufgefallen, dass da einige ältere Sparc-Systeme herumstanden, die schon Staub ansetzten", fährt er fort. „Ich hatte viel mit Linux auf Intel-Maschinen herumgespielt. Also fragte ich mich, welche Art Arbeit hier notwendig war, um das System auf diesen Sun-Kisten zum Laufen zu bringen. Programmiert hatte ich schon früher. Wie schwierig würde das hier sein?" Das ist der klassische Gedankengang eines jungen Hackers, der zum Teil von Arroganz und zum Teil von Naivität zeugt - eine Einstellung, die zu den elegantesten Ergebnissen des freien Codierens geführt hat. „Etwa zwei oder drei Monate, nachdem ich im CAIP angefangen hatte, begann ich mit dem Portieren von Linux für den Sun Spare herumzuspielen." Das war 1993, wie sich Miller erinnert. „Ich glaube, dass es ungefähr drei Wochen dauerte, bis ich einen ganz einfachen Mikrokernel zum Funktionieren brachte. Er tat nichts weiter als “Hallo“ zu sagen. Die Mühe, die es mir gemacht hatte, etwas so Simples auf die Beine zu stellen, gab mir einen Vorgeschmack auf das, worauf ich mich da eingelassen hatte." Sein Motiv, so Miller, „war wahrscheinlich Langeweile. Ich meine, nachdem ich die Backups gemacht, Papier in die Drucker eingelegt und die anderen Systemadministratorarbeiten erledigt hatte, die von mir erwartet wurden, hatte ich noch Zeit übrig." In einem etwas ernsthafteren Ton fügt er hinzu: „Da ich mich nun also in einem gewissen Maß auf Linux eingelassen hatte, verspürte ich irgendwie den Wunsch, etwas Wichtiges zu machen. Dabei ging es mir hauptsächlich darum herauszufinden, ob ich dazu überhaupt imstande war. Ich hatte da diese alten Sparcs stehen, und Linux lief nicht auf Sparcs. Hey, probieren wir es doch, dachte ich mir, wer weiß, was passieren wird, und vielleicht kann ich sogar etwas lernen." Miller tat mehr, als nur „etwas zu lernen" Er stellte ein größeres Projekt auf die Beine, dessen Ergebnis der Port von GNU/Linux für die vermutlich führende kommerzielle High-End-Plattform war; das war Welten von dem Intel-80386-Prozessor entfernt, auf dem Linux zuerst erschienen war, und der für viele kaum mehr als ein Spielzeug war. Die Veröffentlichung der ersten vollständigen Arbeitsversion von GNU/Linux auf dem Spare im November 1995 war ein wichtiger Meilenstein und stellte eine wichtige Schwerpunktverlagerung in Richtung Unternehmensumgebung dar.

7. Linus 2.0

--------------------------------------------------------------------------------------Den zweiten wichtigen Portierungsfortschritt erzielte Linus. Vielleicht von Millers Arbeit und den zunehmenden Aktivitäten auf anderen Plattformen angespornt, hatte Linus sich entschlossen, den ersten offiziellen Port von GNU/Linux für eine neue Chiparchitektur (Millers Sparc-Port sollte später nur ein Teil des offiziellen Linux-Kernels werden) herzustellen. Es gab aber auch noch einen anderen, persönlicheren Grund. Linus sagt dazu, dass „ich bei Linux nun ein Stadium erreicht hatte, in dem ich das Gefühl hatte, o.k., das ist erledigt. Es gab nie ein Stadium, in dem ich nichts zu tun hatte, aber es gab einige, in denen ich mich fragte, ob es wirklich noch irgendetwas Interessantes zu tun gab. Als nun also [Digital] den Alpha herausbrachte, dachte ich, hey, das könnte es sein!" Wieder einmal erwies sich Linus' Suche nach der nächsten Hackerherausforderung als eines der wichtigsten Motive für seine Entscheidung. Es gab noch weitere zwingende Gründe, den Alpha zum ersten offiziellen Port zu machen. „Der Alpha hatte einiges, was für ihn sprach", sagt ert „hauptsächlich 64 Bit und eine radikal andere Architektur als die Intel-Chips. Deshalb war er in gewissem Sinn das perfekte Portierungsobjekt, weil es ganz anders war als wenn ich einen Intel-Port und einen Alpha-Port gehabt hätte. O.k., ich konnte es also beweisen, Linux kann für mehr oder weniger alles portiert werden." Das war etwas vollkommen anderes als der „nicht portierbare" Code, den er als Erstes produziert hatte. Die Entscheidung, den Alpha-Chip zu wählen, der die Daten in 64-BitEinheiten und nicht mit den vom Intel 80386 verwendeten 32 Bits verarbeitete, erwies sich als ein weiterer kluger Schritt von Linus. Vor allem verlieh er seinem Kernel damit einen enormen Vorsprung gegenüber Microsoft Windows NT, als das Unternehmensrechnerprogramm ein paar Jahre später auf 64-Bit-Chips umstieg. Linus' außergewöhnliches Talent. Lösungen für bestimmte Herausforderungen in größere, langfristige Vorteile zu verwandeln, manifestierte sich hier wie anderswo. Anstatt den Code auf die einfachste mögliche Weise zu portieren, ergriff er die Chance, seine ganze Arbeit zu revidieren und alles neu zu schreiben und zu ordnen.


------------------------------------------------------------------------------------„Dabei musste ich wirklich viel Code aufräumen", erklärt er, „vor allem im Speichermanagement, weil der Code ganz speziell auf eine Architektur zugeschnitten war und ich einen vollkommen anderen Ansatz wählen musste. Ich wollte nie zwei verschiedene Versionen haben, sondern ein Linux, das auf Intel und Alpha und auf allem anderen funktionierte. Also musste ich all die Hardwareabhängigkeiten wegabstrahieren und ein spezielles Unterverzeichnis für hardwarespezifisches Zeug schaffen. Das führte zu erheblichen organisatorischen Veränderungen im Kernel." Die Veränderungen waren drastisch. „Als ich das mit der Portierbarkeit auf dem Netzwerkcode machte, hatte ich etwa drei Wochen lang keinen funktionierenden Kernel, weder auf Alpha noch auf Intel", erklärt Linus. „Da ich alles neu strukturierte und dabei schrittweise vorging, hatte ich das Problem, dass es erst funktionierte, wenn alles perfekt war. Deshalb musste alles stimmen, bevor man es auch nur testen konnte." „Mit dem Portieren verbrachte ich im Wesentlichen ein Jahr [von 1994 bis 1995]. Obwohl ich den Großteil meiner Zeit mit dem Schreiben und Lesen von E-Mails verwendete, um mich über Linux auf dem Laufenden zu halten, codierte ich, wenn ich codierte, hauptsächlich für den Alpha." Die Hauptarbeit der Kernelentwicklung hatte nun den typisch gleichmäßigen Rhythmus angenommen. Aber es gab auch einige Neuigkeiten. So brachte Linus zum Beispiel nicht einmal einen Monat nachdem Linux 1.0 herausgekommen war, im März 1994, eine Version heraus, die er 1.1 nannte. Aber das war mehr als ein einfaches Punkt-Upgrade - es war der Anfang einer bedeutenden Erweiterung der Linux-Entwicklungsmethode. Eines der Schlüsselelemente der Methode war der dichte Veröffentlichungszyklus neuer Kernelversionen - manchmal kam alle paar Tage eine neue heraus. Das trieb die Entwicklungsrate mit atemberaubender Geschwindigkeit voran, erwies sich aber als nicht geringes Problem für die wachsende Zahl der Nichthacker, die mit Linux arbeiteten. Neue Kernels waren oft nichts anderes als Fixes für Bugs, aber manchmal kamen auch wichtige neue Features hinzu, die nur Betacode waren. Das brachte die Benutzer in eine Zwickmühle: Sollten sie versuchen, mit jeder neuen Version Schritt

7. Linus 2.0

--------------------------------------------------------------------------------------zu halten, oder sollten sie bei den älteren, oft stabileren Versionen bleiben und sich dabei neue, vielleicht wichtige Features entgehen lassen? Die Spannung wurde durch den Höhenflug des kommerziellen GNU/Linux-Sektors noch angeheizt. Da es nicht möglich war, bei jeder Neuveröffentlichung eines Kernels die ganze Distribution zu überarbeiten, waren die GNU/Linux-Firmen gezwungen, „Schnappschüsse" des Entwicklungsprozesses herzustellen. Es war unvermeidlich, dass verschiedene Anbieter verschiedene Schnappschüsse erstellten, was zu einer zunehmenden Zersplitterung des Marktes führte. Linus' Lösung war brillant: sowohl den Hackern als auch den „normalen" Benutzern zu dienen, indem er die Kernelentwicklung in zwei Stränge teilte: Die Versionen mit geraden Punktnummern -z.B. 1.0, 1.2 - waren die stabilen Versionen. In Aktualisierungen wurden Bugs behoben, statt dass neue Features hinzugefügt wurden. Versionen mit ungeraden Zahlen - 1.1, 1,3 - waren experimentelle Versionen, die oft neue Elemente beinhalteten. Sie waren für die Hackergemeinde zum Ausprobieren und zum Debuggen gedacht. An einem bestimmten Punkt wurde der Code für die Entwicklungsversion eingefroren: Es wurden keine neuen Features mehr hinzugefügt, und die darauf folgende Arbeit beschränkte sich auf das Debuggen dieses Codes. Sobald er von Fehlern bereinigt war, kam die nächste Version für den stabilen Strang. So wurde zum Beispiel 1.1.x eingefroren, bereinigt und wurde dann zu 1.2.0 etc. und beim neuen 1.3.0-Strang konnten neue Features hinzugefügt werden. Auf diese Weise wurden Benutzern und Verkäufern langsamere, größere Sprünge zwischen den stabilen Versionen ermöglicht, und die Hacker konnten die ständigen Erweiterungen des Kernels fast täglich verfolgen. Linux 1.2 kam im März 1995 heraus, fast ein Jahr nach Version 1.0. Zu diesem Zeitpunkt war die Computerwelt von der bevorstehenden Veröffentlichung von Windows 95 fasziniert, das noch seinen eigenen Betatestprozess durchlief. Dieser Prozess unterschied sich stark von dem Prozess, der von der GNU/Linux-Welt angewendet wurde.


------------------------------------------------------------------------------------Das brachte Linus dazu, extrem detaillierte Release Notes für Version 1.2 zu schreiben: O.k., die endgültige Version von Linux'95r unter Wissenden auch als „v 1.2.0" bekannt, ist nun da. Nach der umfassenden Betaphase ist Linux'95 nun Realität geworden. Bevor Sie sich Linux'95 besorgen, möchte ich über die Lizenz sprechen und Sie daran erinnern, dass eine Copyrightverletzung eine Straftat ist. Nach diesem überraschenden Beginn listet Linus detailliert verschiedene Lizenzarten auf, deren Plausibilität ständig abnimmt. Die letzte sieht so aus: *Die „Ich-habe-zu-viel-Geld“-Lizenz Kontaktieren Sie uns, wenn Sie sich für die Einzelheiten dieser exklusiven Lizenz interessieren - wir werden uns etwas einfallen lassen. Wenden Sie sich bitte direkt an [email protected]. In seiner Ankündigung von Linux 2.0, die er am 9. Juni 1996 gepostet hatte, war Linus weniger schnoddrig. Er kündigte drei entscheidende Neuerungen an, von denen er zwei für so wichtig hielt, dass er in der Nummerierung der Kernelversionen von 1.2 nicht auf 1.4, sondern gleich auf 2.0 sprang. Die erste von ihnen war ziemlich außergewöhnlich: Linux hat nun dank des künstlerischen Talents von Larry Ewing ein Logo, und eine Version (die „hübsche") ist dem Kernel beigefügt. Manche Leute sagen, sie glauben nicht, dass ein dicker Pinguin die Eleganz von Linux richtig rüberbringen kann, aber das sagt mir nur, dass sie noch nie einen wütenden Pinguin gesehen haben, der mit über 100 km/h auf sie zu rast. Hätten sie einen gesehen, würden sie ihre Worte sorgfältiger wählen.

7. Linus 2.0

--------------------------------------------------------------------------------------Was Linus nicht erwähnte, war die Tatsache, dass seine Entscheidung, den Pinguin für das Linux-Logo zu wählen, auf eine Begegnung auf einer seiner Auslandsreisen zurückging. Auf einer Australienreise im Jahr 1993 war er in Canberra bei seinem Hackerkollegen Andrew Tridgell zu Gast. „Wir besuchten das Aquarium in Canberra", erklärt Tridgell. „Es handelt sich dabei um ein Aquarium mit einem kleinen Zoo. Dort gibt es unter anderem eine kleine Gruppe von Fairy-Pinguinen. Das sind ziemlich kleine Tiere, nicht viel höher als 30 cm, sehr süß. Und da war ein kleines Schild, auf dem steht, dass man seine Hand nicht ins Gehege strecken sollte. Linus ignorierte das natürlich, steckte seine Hand hinein und einer der Pinguine biss ganz zärtlich hinein - nur so auf die Art „Möchte wissen, wie die wohl schmeckt.“ „Ich dachte mir gar nichts dabei", sagt Tridgell. Später, als Linus nach einem Maskottchen für Linux Ausschau hielt, entschied er sich dann für den Pinguin. „Offensichtlich waren ihm diese Tiere schon vorher sympathisch gewesen", so Tridgell. Aber Tridgell sagt, dass Linus als Grund für seine Wahl auch diesen Pinguin in Canberra nannte, der ihn attackiert hatte - in seinen Erzählungen war er schon auf die imposante Größe von 1.80 Meter angeschwollen. Er sandte seine Geschichte an die Linuxkernel-Mailingliste, und ich schrieb zurück und meinte, dass sie wohl stark übertrieben sei. Er beanstandete, dass mir jeder Sinn für Dramatik fehle." Der Pinguin erwies sich übrigens als bemerkenswert kluge Wahl. Die Tatsache, dass er so gar nicht businesslike ist, wird dem Geist der Linux-Bewegung sehr gut gerecht. Irgendwie ist es passend, dass Software, deren Urheber aus dem schwedischen Ententeich in Finnland stammt, einen Vogel als Maskottchen hat. In seiner Ankündigung von Version 2.0 beschrieb Linus die beiden wichtigsten Zusätze seit 1.2: Multiarchitekturunterstützung. Der Standard-Linuxkemel 2.0 unterstützt direkt sowohl Intel-x86- (und Klon) als auch Digital-Alpha-Maschinen, Auch einige andere Architekturen sind nahe daran, „offiziell" zu sein.


------------------------------------------------------------------------------------Multiprozessorunterstützung. Ja, man kann eines dieser dualen Pentium (oder Pentium Pro) Motherboards kaufen, und Linux nützt tatsächlich mehrere CPUs. Das waren dramatische Entwicklungen. Die neue Multiarchitekturunterstützung verwandelte GNU/Linux von einem an die Intel-Plattform geketteten System in eine weithin portierbare Lösung und vergrößerte seine Reichweite sozusagen auch in der horizontalen Dimension. In ähnlicher Weise ermöglichte die neue Fähigkeit, mehr als einen Prozessor zu verwenden, größere Prohleme in Angriff zu nehmen und seine Reichweite vertikal in Richtung Minicomputer-, Großrechner- und sogar Supercomputerleistungsklassen auszudehnen. Sinn des zweiten Features war es, eine der größten Beschränkungen des Linux-Kernels zu beheben: die Tatsache, dass er in der Leistung nicht „skalierbar“ war, wenn weitere Chips hinzukamen. Multiprozessorunterstützung, wie rudimentär sie auch war, war eine entscheidende Weichenstellung für die Zukunft und gleichsam die Erklärung, dass GNU/Linux in Zukunft nicht länger als einfaches PCSystem zu betrachten war, sondern als vollwertiger Unix-Klon. Ein Klon, der darüber hinaus potenziell gleichwenig mit kommerziellen Systemen war, die Tausende US-Dollar kosteten, und der dadurch stillschweigend zu seinem stärksten Rivalen in der Unternehmenswelt, Windows NT von Microsoft, aufschloss. Dieser entscheidende Schritt war dem Mann zu verdanken, der sich als der vielleicht vielseitigste Kernelhacker überhaupt erwies und inzwischen de facto zur Nummer zwei der Linux-Bewegung aufgestiegen war. Sein Name war Alan Cox. Nachdem er den TCP/ IP Code bewältigt hatte, hielt er Ausschau nach einer neuen Herausforderung. Die komplexe Aufgabe, Linux um Multiprozessorkapazitäten - genau genommen Symmetrie Multi-Pro-cessor (SMP) - zu erweitern, war die perfekte Gelegenheit für ihn, etwas Neues auszuprobieren. Die Ausrüstung wurde von Caldera im Rahmen der Bemühungen dieses Unternehmens zur Verfügung gestellt, Linux um weitere kommerzielle Features zu erweitern. „Sie schickten mir das Motherboard, zwei CPUs und 8 MB RAM dafür", erinnert sich Cox. „Genau

7. Linus 2.0

--------------------------------------------------------------------------------------genommen war es noch mehr Speicher, aber ich wollte ausdrücklich nur 8 MB, weil man viele Bugs nicht findet, wenn die Maschine nicht wirklich stark beansprucht wird." Darüber hinaus, so sagt er, „lud ich alles, was ich hinauf packen konnte", im Sinne von ungewöhnlichen Peripheriegeräten. Wieder einmal kristallisiert sich etwas heraus, was man die LinuxMethode nennen könnte: Anstatt zu versuchen, die Software in der bestmöglichen Umgebung auszuprobieren - ein schneller Prozessor, viel Speicher, keine seltsamen Peripheriegeräte -, wird eine leistungsschwache Maschine mit jeder Menge Extras eingesetzt, um gut verborgenen Bugs auf die Spur zu kommen. Das war der Grund, warum Cox sich überhaupt mit dem TCP/IP von Linux eingelassen hatte. Die enormen Anforderungen, die sein Netzwerk-Setup an den Code stellte, ermöglichte es ihm, Bugs zu finden und zu beheben, von denen niemand geglaubt hätte, dass es sie überhaupt gab. Mittlerweile hatte Linus ein dringlicheres Projekt: die Diplomarbeit für sein Masters Degree. Nach seinen frühen Jahren als einfacher Student war Linus Assistent an der Universität geworden. 1996 erzählte er, wie sich seine Karriere an der Universität entwickelt hatte. „Ich hatte als Assistent begonnen und auf diese Weise schon sehr früh unterrichtet, wenn auch nicht meinen eigenen Kurs. Das ist für gute Studenten irgendwie normal, weil sie an der Universität immer Leute brauchen, die Prüfungsarbeiten durchsehen und mit den Kleingruppen die wöchentlichen Übungen machen." Es war in einer dieser Kleingruppen gewesen, in der Linus ein paar Jahre davor so eindrucksvoll geblufft hatte, als der Professor eine Hausarbeit von ihm verlangte, die er unter den Tisch hatte fallen lassen. „So ,richtig‘ zu unterrichten begann ich 1993 und 1994", erzählt er, „als ich den Kurs Einführung in EDV auf Schwedisch hielt. Keine große Sache, und die Klassen waren auch ziemlich klein -aber hey! Ich kann das in meinen Lebenslauf aufnehmen, wenn ich will. In den letzten beiden Jahren [1995 und 1996] konnte ich bedingt durch die Umstände nicht viel unterrichten. Deshalb konzentrierte ich mich auf die Forschung - Linux in diesem Fall.


------------------------------------------------------------------------------------Linus wählte als Thema für seine Diplomarbeit die Portabilität von Linux - die Ergebnisse seiner Erfahrungen mit dem Alpha-PC von Digital. „Es ging hier vorrangig um die Probleme und die Lösungen. Das Portieren von Linux nicht nur für den Alpha, aber der Alpha war jedenfalls eines der Beispiele", erklärte Linus 1996, als er immer noch an der Diplomarbeit arbeitete - etwas, das ihm, wie er zugab, wenig Spaß machte. Linus schrieb seine Arbeit auf Englisch. „Ich würde nicht sagen, dass das normal ist, aber vollkommen ungewöhnlich ist es auch nicht. Für mich ist es viel leichter, weil mir die Begriffe alle auf Englisch geläufig sind", sagt er. Sein Englisch ist erstklassig, und er hat nur diesen ganz leichten Singsang-Akzent, wie er für Schweden in dieser Sprache typisch ist. Englisch war auch für die beiden Betreuer seiner Arbeit praktisch, die sie lesen und genehmigen mussten. Wie Linus 1996 sagte: „Meine Muttersprache ist Schwedisch, und es wäre wahrscheinlich schwieriger für sie gewesen, Leute zu finden, die ihnen die Sprache hätten erklären können, als mein Englisch zu kommentieren." Linus verwendet die englische Sprache auch in anderen Situationen. „Beim Programmieren denke ich meistens englisch", sagt er. Seine Art zu codieren ist der von Richard Stallman ähnlich. „Ich verwende nie Papier", erklärt Linus. „Wenn ich mich mit etwas Schwierigem beschäftige, wo ich sehr detailliert denken muss, notiere ich mir gelegentlich Zahlen und Ähnliches. Aber im Allgemeinen mache ich alles direkt auf der Maschine. Wenn es etwas Größeres ist, denke ich einfach ein paar Wochen lang nach, bevor ich zu codieren beginne, und ich versuche, es gleich von Anfang an richtig zu machen. Papier brauche ich dazu überhaupt keines. Wenn ich an etwas arbeite, ist es mir egal, was rund um mich passiert. Ich denke im Bus darüber nach und im Bett vor dem Einschlafen. Wenn mir etwas einfällt, nehme ich mir Papier und einen Stift und schreibe meine Gedanken nieder. Dann hoffe ich, dass es am Morgen Sinn macht. Aber das ist sehr selten", räumt er ein. Linus schreibt sich nicht nur sehr selten etwas auf, und er druckt auch nie Teile des Codes aus, um etwas zu finden, sagt er.

7. Linus 2.0

--------------------------------------------------------------------------------------„Ich verwende auch keine anderen elektronischen Hilfsmittel zum Indizieren. Ich habe immer einen Index des Kernels im Kopf." Die Diplomarbeit mag wenig angenehm für ihn gewesen sein, aber zumindest wusste er, was von ihm verlangt wurde. Weniger klar war die Antwort auf die ewige Studentenfrage, die sich danach stellte: Was würde er nach dem Abschluss seines Studiums tun? In seinem Leben hatten sich einige größere Veränderungen vollzogen, die seine Situation nicht einfacher machten. Er war von zu Hause im Osten Helsinkis, wo er mit seiner Mutter und seiner Schwester gelebt hatte, in eine kleine Zweizimmerwohnung in einem aus dem neunzehnten Jahrhundert stammenden Gebäude im Westen der Stadt gezogen. Linus teilte das Haus nicht nur mit einer, sondern mit zwei Katzen, und mit einer Mitbewohnerin, die er 1996 als seine „rechtmäßige Ehefrau" bezeichnete: Tove Monni, eine ehemalige finnische Karatemeisterin. Linus ernannte Tove zu seiner „Managerin", wie er in einer ironischen Presseaussendung kundtat, die er am 8. Dezember 1996 in der comp.os.linux.announce-Newsgroup postete: Helsinki, 5. Dezember, 6:22. Zur sofortigen Veröffentlichung. Um Ängste um die Kontinuität des Linux-Projekts zu zerstreuen, hat Linus Torvalds gemeinsam mit seiner Managerin Tove Monni „Linus v2.0" herausgebracht, auch bekannt unter dem Kosenamen „Kernelhacker Die nächste Generation". Linus 2.0 war Patricia Miranda Torvalds, geboren am 5. Dezember 1996 um 6:22, dem Zeitstempel der Presseaussendung. Zu einem ihrer Paten wurde John „Maddog" Hall erkoren. Da Linus sein Privatleben immer geheim gehalten hatte, war die Mitteilung, dass er nicht nur eine Frau, sondern nun auch eine Tochter hatte, für viele Mitglieder der Linux-Gemeinde ein Schock. Außerdem stellte die Nachricht die gängigen Vorurteile über Hackerpersönlichkeiten infrage. Aber wenn die Überraschung über „Linus 2.0" groß war, war ein anderes Posting, das Linus ein paar Monate davor abgesandt hatte, eine noch größere Überraschung, weil es ein unmittelbar bevorstehendes Ereignis ankündigte, das nicht mit


------------------------------------------------------------------------------------derselben ungetrübten Freude aufgenommen werden konnte wie die Nachricht über Familienzuwachs. Vielleicht weil das Thema in den letzten zwei Jahren im Mittelpunkt von Linus' Hackeraktivitäten gestanden hatte, tauchte es auf einer Mailingliste über Linux für den Alpha-Prozessor auf. In Beantwortung einer „2.1.4 Ausnahmefrage" am Vormittag des 16. Oktober 1996 beendete Linus sein Posting nach langen Ergüssen der technischen Art wie folgt: Ich werde am Sonntag für eine Woche in die Staaten fahren (Haussuche), und ehrlich gesagt würde ich die oben genannten fünf „kritischen" Punkte zuerst gern klären. Es versteht sich von selbst, dass das in Klammer gesetzte Wort „Haussuche" seine Wirkung nicht verfehlte. Ein paar Stunden später fragte jemand, ob das bedeutete, dass Linus in die Vereinigten Staaten ziehen wollte und dass er jetzt einen Job hätte, Linus antwortete noch am selben Tag mit einem charakteristischen Posting, das so begann: Schon gut, Leute, KEINE PANIK. [Inline: Linus herumlaufend und sich die Haare raufend] Nun, es muss einmal gesagt werden. Ich habe dort einen Lebenszweck. Da habt ihrs. Ich habs geschafft. Ich habe mich für das Outing entschieden. Es ist traurig, es ist schockierend, aber es ist wahr. Ich habe sogar eine Freundin [kollektive FASSUNGSLOSIGKEIT], aber es läuft alles auf das Folgende hinaus: Ich habe einen echten Job, (RealJobTM). Und er schloss: P.S.: Die Firnia heißt Transmeta. Macht euch nicht die Mühe zu recherchieren, sie machen keine Werbung. Sie holen sich die besten Köpfe der Branche und machen coole Dinge, von denen ich euch nichts erzählen werde. Sie verkaufen Linux nicht und sind daher keine unfaire Konkurrenz auf diesem Gebiet.

7. Linus 2.0

--------------------------------------------------------------------------------------Wie üblich verbargen sich hinter dem scherzenden Tonfall ein paar ernsthafte Punkte. Der erste war, dass Linus sich der Wirkung, die seine Entscheidung haben würde, durchaus bewusst war. Der Entwicklungsprozess der letzten fünf Jahre hatte sich so sehr auf ihn konzentriert, dass selbst seine kleinsten Entscheidungen für die ganze Bewegung spürbar wurden. Das machte die Wahl der Firma, für die er arbeiten würde, so wichtig, wie seine abschließende Bemerkung beweist. Ende 1996 erklärte er: „Ich wollte etwas tun, was in keiner direkten Verbindung zu Linux stand. Eigentlich boten mir LinuxDistributoren Arbeit an, aber ich wollte nicht für sie arbeiten, denn ich wollte durch meine Arbeit in einer Firma keiner bestimmten Distribution meinen stillschweigenden Genehmigungsstempel aufdrücken. Mir war etwas Neutrales lieber." Seine Lösung war wie immer schlau. „Obwohl Transmeta kein Linux verkauft", erzählte er, „steht in meinem Vertrag, dass ich dort zum Teil an Linux arbeiten werde. Das ist formal festgehalten. Ich will nicht in die Lage kommen, dass ich die Stunden, die ich mit Linux verbringe, zählen muss. Manchmal werde ich nur an Linux arbeiten, und zu anderen Zeiten an dem, was Transmeta gerade macht." Aber Transmeta hatte Linus noch ein anderes attraktives Angebot gemacht: „Ich wollte einfach eine interessante neue Arbeit", sagte Linus. „Der Grund, warum ich mich zum Umzug entschloss, war, dass ich nun etwa sieben Jahre lang an der Universität gearbeitet hatte. Zum Teil hatte ich gleichzeitig studiert und gearbeitet. Es schien mir ein guter Zeitpunkt, um mir die andere Seite der Welt" - die Geschäftswelt „ anzusehen, nicht nur die akademische Seite." Sein ganzes Leben lang hatte Linus immer Ausschau nach Herausforderungen gehalten. Als Teenager wollte er unbedingt seinen VC-20-Mikrocomputer gegen einen anderen austauschen, weil er ihn schon so gut kannte. Später hatte er mit dem Alpha-Port begonnen, weil er gedacht hatte: „Hey, das könnte es sein!" Aber nach einiger Zeit begann er sich zu fragen, ob es noch „irgendetwas wirklich Interessantes" zu entdecken gab. Ähnlich war es 1996 ungefähr zu der Zeit, als er den Job bei Transmeta annahm. Er erzählt: „Ich würde nicht sagen, dass die


------------------------------------------------------------------------------------technischen Probleme [von Linux] alle geklärt waren. Schließlich gibt es immer viele Details - es wird immer neue Gerätetreiber, neue Hardware, neue Ports, neue Arbeitsmethoden geben. Aber selbst wenn sie mich interessieren, sind sie inkrementell, was bedeutet, dass ich, obwohl ich mich gern mit ihnen befasse und obwohl ich Linux weiterhin unterstützen werde, sichergehen muss, dass ich daneben etwas anderes Interessantes zu tun habe." Die Firma, die ihm diese „Nebenarbeit" anbot, war Transmeta. Sie hatte ihren Sitz in Santa Clara im Herzen von Silicon Valley. Der Job war nicht nur deshalb so attraktiv, weil er ihn mitten ins Zentrum des Computing fuhren würde, sondern auch aus einem anderen Grund: „Der Ort interessierte mich vor allem wegen anderer Aspekte wie zum Beispiel wegen des Wetters", sagte er kurz vor seinem Umzug. Über Transmeta sagte Linus nichts anderes, als dass das Unternehmen moderne Computerchips herstellte. „Sie werben nicht", war ein Understatement. Selbst die Website bestand nur aus einer einzigen Zeile: „An dieser Webseite wird noch gearbeitet!" Jene, die im zugrunde liegenden Code nach geheimen Botschaften suchten, fanden Folgendes: Der Welt von Linux wurde ein Mysterium hinterlassen, das über drei Jahre lang im Dunkeln bleiben sollte. Aber ihr blieb auch eine erstaunliche Leistung: Der Linux-Kernel war seit Version 0.01, einer 80K-Stu-dentenübung in C und 386 Assembler, um einen Faktor von fast 100 auf Version 2,0 gewachsen, die fast 5 Mbytes komprimierten Code umfasste. Er hatte sich von einem System, das kaum auf einem PC lief, zu einem fast vollständigen Unix-Klon entwickelt; er unterstützte X Window, TCP/IP Networking, mehrere vollkommen verschiedene Architekturen und Multiprozessormaschinen, wenn auch auf eine sehr rudimentäre Art.

7. Linus 2.0

--------------------------------------------------------------------------------------Es hatte sich eine ultraschnelle Entwicklungsmethode entwickelt, die in ihrer Art einzigartig war. Sie zog Tausende von Usern auf der ganzen Welt an, die über Internet miteinander verbunden waren und einander Berichte über Bugs lieferten. Oft schickten sie „älteren" LinuxCodierern - den „Leutnants" - Fixes, damit die nächste experimentelle Version des Kernels erscheinen konnte. Gleichzeitig wurde eine langsamere, stabilere Version für die User herausgebracht. Dieser doppelte Entwicklungsansatz war einzigartig. Die Folge war, dass die Linux-Gemeinde noch schneller wuchs als der Kernel. Ende 1991 schätzte Linus die Zahl der User auf unter hundert; Anfang 1992 waren es schon Hunderte. Danach wurde es aufgrund des außergewöhnlichen Vertriebssystems und der Lizenzbedingungen von Linux immer schwieriger, die genaue Zahl festzustellen. Die Leute konnten sich die Software frei von Onlinesites herunterladen, und jeder konnte CD-ROMs kopieren, die das GNU/Linux-Betriebssystem enthielten. Es gab keine Beschränkungen. Das machte konventionelle Kennzahlen wie Umsatzziffern so gut wie sinnlos. Aber die neuen GNU/Linux-Firmen, die Mitte der neunziger Jahre aus dem Boden schossen, mussten ihre Benutzerbasis zumindest schätzen können, wenn sie in der Lage sein wollten, Prognose für ihre Unternehmen zu erstellen. Das führte dazu, dass untersucht wurde, wie groß der Linux-Markt nun wirklich war. So sagte Bryan Sparks von Caldera 1996: „Wir haben sowohl selbst als auch über Dritte vorläufige Forschungen durchgeführt und dabei festgestellt dass es sich um über eine Million handelt - manche sagen, dass es derzeit schon zwei Millionen User gibt. Mir ist wohler in meiner Haut, wenn ich sage, dass wir bei über einer Million liegen." Marc Ewing von Red Hat war da forscher: „Wir glauben, dass es weltweit irgendwo zwischen drei und fünf Millionen Linux-User gibt", sagte er damals. Wie hoch die genaue Zahl nun tatsächlich gewesen sein mag, war es doch außergewöhnlich, dass es nur fünf Jahre nachdem Linus mit seiner Arbeit an seinem Kernel begonnen hatte, bereits Millionen von GNU/Linux-Usern gab. Die hohe Zahl zeugte vor allem von den Ergebnissen des GNU/LinuxEntwicklungsprozesses: Code, dessen „Qualität oft einsame Spitze ist", wie Ewing es 1996 ausdrückte.


------------------------------------------------------------------------------------Bryan Sparks von Caldera hatte keine Zweifel, warum der LinuxProzess so gut geeignet war, Software von so hoher Qualität zu produzieren. „Linus war der perfekte Typ für den wohlwollenden Diktator der Linux-Gemeinde", sagte er. „Wäre er konfliktfreudiger gewesen oder hätte er einen anderen Charakter gehabt, wäre Linux nicht halb so populär geworden." Ewing stimmt aus ganzem Herzen zu: „Linus ist wirklich brillant, und er ist auf jeden Fall der richtige Mann für den Job." Und nun ging dieser „perfekte Typ" einen Schritt weiter. Selbst Linus schien sich zu diesem Zeitpunkt nicht ganz sicher zu sein, was dieser Schritt tatsächlich bedeutete. „Ich will auf jeden Fall Kontinuität", sagte er 1996. „Natürlich wird es Veränderungen geben, aber ich weiß noch nicht einmal, worin sie bestehen werden. Wahrscheinlich mehr wegen des Familienzuwachses als wegen des Umzugs, aber natürlich auch wegen des Umzugs." Eine neue Tochter, ein neuer Job, ein neues Land: ein neuer Linus. Die Frage, die sich alle in der Gemeinde der freien Software stellten, lautete: Bedeutete das Ende dieser ersten, finnischen Phase auch das Ende des goldenen Zeitalters der Linux-Entwicklung?

8

Lernen von Berkeley

1969 WAR EIN WICHTIGES JAHR, weil es das Geburtsjahr von Unix war - und das von Linus. In diesem Jahr wurden auch die ersten Schritte zur Schaffung eines Netzwerks gesetzt, das irgendwann einmal zum Internet werden sollte. Ursprünglich ARPAnet genannt, wurde es von der Defense Advanced Research Projects Agency (DARPA) eingerichtet, die zum USVerteidigungsministerium gehörte. In gewisser Weise war das ARPAnet dem Internet ähnlich: Zum Beispiel verwendete es etwas, was man Datenpaketvermittlung nennt. Das bedeutet, dass Daten in kleine Pakete unterteilt werden, die einzeln über das Netzwerk geroutet und dann bei ihrer Ankunft wieder zusammenfügt werden. Die Datenpaketvermittlung steht im Gegensatz zur Leitungsvermittlung, die für normale Telefonverbindungen verwendet wird, zum Beispiel, wo zwischen Anfangs- und Endpunkt für die Dauer der Verbindung ein einzelner Schaltkreis besteht.


------------------------------------------------------------------------------------Der entscheidende Schritt vom ARPAnet zum Internet war der Schritt zur offenen Netzwerkarchitektur. Wie eine Geschichte des Internets, die von seinen Urhebern zusammengestellt wurde und auf der Website der Internet Society zu finden ist, erklärt: „Bei diesem Ansatz war die Wahl einer individuellen Netzwerktechnologie nicht von einer speziellen Netzwerkarchitektur vorgegeben, sondern sie konnte von einem Provider frei gewählt und mit den anderen Netzwerken verbunden werden." Das bedeutete, dass das Wesen des Internets von Anfang an Offenheit war und dass seine weitere Entwicklung eng mit den Kernspezifikationen verbunden war, die durch die freie Software implementiert worden waren. Eine der wichtigsten Personen in dieser Geschichte ist Eric Allman, der dazu beitrug, dass das Internet zu dem wurde, was es heute ist. Er ist einer der Väter der Bewegung der freien Software, die so viel Kraft aus der Verfügbarkeit eines globalen Netzwerks schöpft. Allman wurde 1955 in Kalifornien geboren und begann im Alter von elf Jahren mit Computern zu arbeiten. Er sagt, dass er einfach an einem dieser „Wahlgegenstände in der Schule" teilnahm. Aber bald begann er sich zu langweilen, und schon ein paar Jahre später wandte er sich einer interessanteren Herausforderung zu: „Ich entwickelte ein Interesse an Betriebssystemen", sagt er. „Deshalb hackte ich eigentlich in diese Richtung." Das Studium der Computerwissenschaften an der University of California in Berkeley sollte sich als wichtigster Baustein seiner Karriere erweisen - und doch wäre es um ein Haar nichts damit geworden. „Ironischerweise glaubte ich, ich sei nicht intelligent genug für Berkeley", erzählt Allman. „Ich wollte mich nicht einmal bewerben. Aber zum Glück hatte ich einen Lehrer, der darauf bestand, dass ich es tat", erklärt er, „und ich wurde tatsächlich aufgenommen." Berkeley wurde später zu einem Synonym für eine bestimmte Art von Unix, die oft als eine der Schriften der heutigen freien Software bezeichnet wird. Aber als Allman zu studieren begann, gab es noch gar kein Unix. „Als ich an die Universität kam, stand da dieser große CDC 6400 - ein Supercomputer für die damalige Zeit, hergestellt von der Control Data Corporation. Man

8. Lernen von Berkeley

--------------------------------------------------------------------------------------gab Karten ein und man erhielt seinen Zeilendrucker-Ausdruck. Mit der Maschine kam man gar nicht in Berührung", erinnert er sich. Was Allman bei Erscheinen von Unix auffiel, war die Dokumentation: „Eines der großartigsten Dinge an der Unix-Dokumentation zur damaligen Zeit war, dass darin stand: ,Wir werden die Bugs genauso dokumentieren wie die Features." Allman findet, dass das „eine unglaubliche Neuigkeit" war, und sagt über diese neue Offenheit: „Ich glaube, dass dieses Konzept des Weitergebens und des freien Bereitstellens, das eigentlich die Quintessenz des späteren OpenSource-Konzepts ist, aus dieser Zeit stammt. Damals, in den frühen Tagen, als man noch keinen Zugang zum Quellcode hatte und irgendwie raten musste, was ein Programm machte, plötzlich alles sehen zu können, war erstaunlich - fast möchte ich sagen erhebend." In dieser neuen, „erhebenden" Umgebung schrieb Allman sein erstes wichtiges Programm namens Delivermail. Zu dieser Zeit arbeitete er als Systemintegrator für das Ingres-Datenbankprojekt in Berkeley. Allman erinnert sich: „Ingres bekam einen Link zu ARPAnet. Und alle in der Abteilung wollten Zugang zu dieser Maschine, ob sie nun etwas mit dem lngres-Projekt zu tun hatten oder nicht - sie wollten nämlich ARPAnet-Mail senden und empfangen können. Das ist interessant", merkt er an, „weil sogar damals schon alles über E-Mail lief." „Ich wollte mich aus verschiedenen Gründen nicht mit dem Management all dieser Benutzerkonten herumschlagen. Aher wir hatten in Berkeley bereits ein lokales Netzwerk. Und ich erkannte, dass ich einfach ein Programm schreiben konnte, das Mails von einem Netzwerk zum anderen weiterleitete, und dann brauchte man keinen Account", sagt Allman und fügt mit der für ihn so typischen Bescheidenheit hinzu: „Wissen Sie, da wird gesagt dass alle Innovationen von faulen Leuten kommen. Ich bin im Grunde genommen ein fauler Mensch. Denn wenn ich weniger faul wäre, hätte es mir nichts ausgemacht, all diese Benutzerkonten zu managen."


------------------------------------------------------------------------------------Aber es machte ihm etwas aus, und so entwickelte er Delivermail, ein Programm für die automatische Wciterleitung der Mails über etwas, was man heute einen Gateway nennen würde, zwischen dem BerkeleyNetzwerk und dem ARPAnet. „Ich schrieb dieses Programm, seine Konfiguration war kompiliert", erklärt er. Das bedeutete, dass man, wenn man das Programm für die einzelnen Maschinen des Netzwerks aufsetzte, jedes Mal am Quellcode herumbasteln musste. Das war akzeptabel, so Allman, „weil es damals nur etwa fünf oder sechs [Computer] im Berkeley-Netzwerk gab. Das Rekompilieren auf fünf oder sechs Maschinen war kein Problem. " „Delivermail war eine interessante Sache, weil es eigentlich nicht mein Ziel war, etwas zu produzieren, was jemand anderer verwenden würde. Ich wollte nur dieses Problem auf eine möglichst unkomplizierte Weise lösen," Trotzdem begannen andere Leute, Delivermail zu verwenden, sobald das Programm in die Berkeley-Distribution von Unix, BSD, inkludiert war. Das war ab BSD-Version 4.1, die 1981 herauskam, der Fall. Sobald Allmans Programm andere User hatte, erhielt er auch Feedback. „Ich bekam ziemlich viel Feedback, obwohl das Ganze erst so richtig explodierte, als das Internet kam. Wir bekamen jedoch einiges aus Berkeley. Berkeley war seit jeher sehr gut darin gewesen, sich Input von der Außenwelt, seiner Benutzerbasis, wenn man so will, zu holen und diese Dinge dann zu integrieren", sagt er. „Wir hatten diesen Ethos", so Allman, „Informationen von Leuten in der Außenwelt aufzugreifen und sie wieder zu integrieren, was meiner Meinung nach ein wichtiger Bestandteil des Open-Source-Modells ist. So konnten die Implementiere anstatt sich mit Informationen der Benutzer begnügen zu müssen, die durch fünf oder sechs Schichten gefiltert wurden, bevor sie zu ihnen gelangten, wie es in der konventionellen Softwareentwicklung in Firmen oft der Fall war, direkt mit den Benutzern sprechen und feststellen, was sie genau brauchten." Allman betont, dass es im Bereich der freien Software „um viel, viel mehr geht als nur um die rechtliche Lizenz. Es geht um eine Methode des Entwickeins, um einen Prozess der Einbindung der Benutzer in die Entwicklung in einem


--------------------------------------------------------------------------------------sehr frühen Stadium." Für ihn ist diese Vorgehensweise tief in der Tradition von Berkely verwurzelt. Bald reichte Delivermail jedoch nicht mehr aus. „Berkeley wuchs sehr schnell, und das Netzwerk weitete sich auf etwa zwanzig Maschinen aus. Deshalb wurde das Rekompilieren für jede Maschine bald sehr aufwändig", erinnert er sich. Der Mehraufwand an Arbeit war eine Sache, aber da gab es noch ein anderes, schwierigeres Problem. „Die andere Sache war, dass die Netzwerkkonfiguration immer komplizierter wurde", sagt Allman. „Wir bekamen andere Netzwerkverbindungen." Nun war es nicht mehr einfach, Universitäts-E-Mails an den richtigen Ort zu schicken, und das von Delivermail angewendete System war von den verschiedenen Netzwerkarten, die mit Berkeley verbunden waren, überfordert. Allman kam zu dem Schluss, dass er Delivermail so umschreiben musste, dass alle Maschinen konfiguriert werden konnten, ohne dass man an der Software selbst rühren musste. Außerdem wollte er das Programm intelligenter machen, sodass es aus den E-MailAdressen herauslesen konnte, wohin die Nachrichten geschickt werden sollten. Das Ergebnis dieser Erneuerungsarbeit nannte er Sendmail. Seinen Erfolg verdankte es größtenteils der neuen Flexibilität, das es bot. „Wenn man ein neues Netzwerk hatte, konnte man es schneller in Sendmail integrieren als in die anderen", erklärt Allman. „Das war lange vor der Zeit, als alle das Internet verwendeten, und die neuen Netzwerke sprossen wie Pilze über Nacht aus dem Boden." Ein weiterer Faktor kam ihm rein zufällig zu Hilfe. „DARPA hatte sich entschlossen, BSD [Unix] zu ihrem standardmäßigen Forschungsbetriebssystem zu machen", sagt Allman. „Und BSD wurde mit Sendmail geliefert. Das bedeutete, dass ich zumindest in dieser Hinsicht zur richtigen Zeit am richtigen Ort war." Aber nun, da das Internet geboren war, arbeitete es in einem vollkommen anderen Rahmen als das frühere ARPAnet. „Es gab jede Menge Aufregung", erinnert sich Allman. „Es war vollkommen klar, dass immer mehr Leute am Internet teilnehmen würden. Das ARPAnet hatte nur Kapazität für 256 Hosts, und die Internetleute erkannten, dass das viel zu wenig war. Also nahmen


------------------------------------------------------------------------------------sie ein 32-Bit-Feld [für Adressen] und erweiterten die Zahl der möglichen Hosts dadurch auf vier Milliarden. Außerdem erkannten viele Leute plötzlich, dass sie Internetzugang haben konnten. Das führte dazu, dass das Internet ziemlich schnell explodierte. Natürlich spielte sich das alles noch im Forschungsbereich ab, aber es bedeutete, dass es möglich sein würde, Zugang zu immer mehr Computerabteilungen, immer mehr Forschungslabors etc. zu haben. Diese Leute waren ziemlich ambitionierte User von Internet und Sendmail." Wenn Sendmail das enorme Wachstum des Internets zur damaligen Zeit beflügelte, könnte man auch sagen, dass es zur Schaffung jenes globalen Netzwerks beitrug, das wir heute kennen. Denn im Zentrum von Sendmail, so Allman „stand das Konzept, dass man E-Mails zwischen verschiedenen Netzwerkarten senden konnte, und zwar auch dann, wenn sie nicht für eine Zusammenarbeit gedacht waren". Das war zur damaligen Zeit ziemlich revolutionär: „Andere Leute sagen mir, dass Sendmail diese Pionierleistung vollbrachte. Ich weiß nicht, ob das stimmt. Es ist durchaus möglich, dass es schon früher etwas Derartiges gegeben hat. Natürlich war es eines meiner Ziele, und ich glaube, dass ich in dieser Hinsicht gute Arbeit geleistet habe." Tatsächlich schuf Sendmail aus den heterogenen Netzwerken der damaligen Zeit eine Art virtuelles Internet. So war es zumindest beteiligt daran, den Leuten die Vorteile eines homogenen globalen Netzwerks nahe zu bringen, das viele verschiedene Dienste ermöglichen würde, nicht nur E-Mail Das ist die heutige Situation: Das Internet wurde zu einer Ansammlung kleinerer Netzwerke desselben Standards, während Sendmail es ermöglichte, dass Ansammlungen verschiedener Netzwerke zusammen arbeiteten, aber nur im Bereich E-Mail. Der Vereinheitlichung des heutigen Internet ist TCP/IP (Transport Control Protocol/Internet Protocol) zu verdanken - jenen fundamentalen Regeln, die festlegen, wie Kommunikationsvorgänge ablaufen. Wie Sendmail leitet sich die Software, die diese Protokolle im so genannten Stack implementiert, hauptsächlich von Arbeiten aus Berkeley ah. Die Schlüsselfigur war hier Bill Joy. Wie Allman sagt: „Keine Geschichte von Berkeley ist vollständig,


--------------------------------------------------------------------------------------wenn Bill nicht erwähnt wird. Er war nicht nur ein unglaublich brillanter, fleißiger Typ, sondern - und das war vielleicht seine wichtigste Eigenschaft - er regte die Menschen in seiner Umgebung dazu an, gute Arbeit zu leisten. Er sog Informationen auf wie ein Schwamm, und ein guter Teil dieser Informationen kam von den Benutzern" - wie es in Berkeley Tradition ist. Joys TCP/IP-Implementierung war ebenfalls in der Unix-Distribution von Berkeley enthalten. Die liberale Berkeley-Lizenz, unter der TCP/IP und andere Komponenten wie Sendmail herausgebracht wurden, ließ im Wesentlichen die Nutzung der Software unter der Voraussetzung zu, dass das Copyright der Urheber von der University of California anerkannt wurde. Das bedeutete, dass viele kommerzielle TCP/IPStacks von dieser Arbeit abgeleitet wurden. Linux beinhaltet eine der wenigen TCP/lP-Implementierungen, die nicht auf Berkeley-Arbeit basieren. Der Grund liegt darin, dass zu der Zeit, als der Linux-Stack geschrieben wurde, eine Klage von AT&T gegen das Berkeley-Unix anhängig war und die Linux-Gemeinde beschlossen hatte, rechtliche Probleme zu vermeiden, indem sie den TCP/IP-Code von Grund auf neu schrieb. Ein Teil der TCP/IP-Protokollsuiten beschreibt, wie die einzelnen Datenpakete mithilfe von Intemetadressen in der Form 123.45.67.89 von ihrem Ursprung zu ihrem Ziel geroutet werden; es ist aber zweifelhaft, ob das Internet seinen Höhenflug als Massenmedium je angetreten hätte, wenn die User anstelle von www.yahoo.com 204.71.200.66 hätten eingeben müssen. Dass diese leicht zu merkenden Namen verwendet werden können, ist dem Domain Name Service (DNS) zu verdanken, das zwischen den beiden Formen konvertiert. Es wurde von Paul Mockapetris erfunden, der dazu erklärt: „Die Spezifikationen des DNS wurden 1983 veröffentlicht, und die ersten Implementierungen waren Jeeves auf einem TOPS-20 System [einem Digital-Großrechner], eine UnixVersion aus Stanford, und eine Version für Unix aus Berkeley." Mockapetris' Jeeves-Software (für den Namen hatte der Butler von P.G. Wodehouse Pate gestanden) „war grundsolide, wenn auch nicht besonders reich an Features", sagt er. Auf ihr liefen am Anfang alle Toplevel-DNS-Verzeichnisse und sie „bewirkte, dass


------------------------------------------------------------------------------------die Leute vom DNS abhängig wurden", was sie immer noch sind. Da Jeeves jedoch an den TOPS-20 gebunden war, kam mit dem Ende der Hardware auch das Ende von Jeeves. Die Berkeley-Software wurde Berkeley Internet Name Domain oder BIND genannt. Wie Sendmail wurde sie bald zum De-facto-Standard. Der Grund lag zum Teil darin, dass auch sie standardmäßig in der Berkeley-Unix-Distribution enthalten war und unter der BerkeleyLizenz herausgebracht worden war. „Von den beiden Unix-Versionen", sagt Mockapetris, „war die Stanford-Version überlegen, aber die Leute von Berkeley hatten den Vertriebskanal. Deshalb behielten sie die Oberhand." Wie Sendmai] war auch BIND freie Unix-Software, die sich durch die Vorschläge und Bugberichte seiner wachsenden Benutzergemeinde auf der ganzen Welt entwickelt hatte. Seine Existenz verdankte sie zum Großteil den selbstlosen Bemühungen eines Mannes - Paul Vixie. Wie heute nur den wenigsten bewusst ist, dass ihre E-Mail hauptsächlich Dank freier Softwareprogramme wie Sendmail und BIND so effizient gesendet und empfangen wird, wird auch oft vergessen, dass der andere große Erfolg des Internets, das World Wide Web, von Anfang an frei zur Verfügung gestellt wurde. Wie Tim Berners-Lee, der Urheber des Web, in seinem Buch Weaving the Web erzählt, ging er sogar von der ursprünglichen Idee ab, die gesamte Webtechnologie 1993 mittels Richard Stallmans GNU GPL zum öffentlichen Eigentum zu machen, um sicherzustellen, dass sie die breitestmögliche Verwendung finden würde. Eine der ersten Institutionen, die die neue Technologie von Berners-Lee verwendeten, war das National Center for Supercomputing Applications (NCSA), Teil der University of Illinois in Urbana-Chapaign, wo Rob McCool einen Webserver namens HTTPd schrieb. Dieses Kürzel stand für HyperText Transport Protocol daemon: http war das Protokoll oder das Regelwerk, das Berners-Lee für den Transport von Webseiten über Netzwerke hinweg entwickelt hatte, und ein Daemon war der Name für einen bestimmten Softwareprozess, der im Hintergrund unter Unix ablief. Der HTTPd-Server des NCSA, der frei war, dominierte den Sektor bald.


--------------------------------------------------------------------------------------Der Aufstieg des NCSA als führender Player im Webbereich kam erst zu einem Stillstand, als in einer auffallenden Parallelentwicklung zum Schritt von Symbolics, die Spitzencodierer des MIT AI Lab abzuwerben, ein Start-up-Unternehmen den Großteil der besten Softwareentwickler der Universität in diesem Bereich engagierte. Das neue Unternehmen wurde später als Netscape Communications bekannt. Da die Webserver von Netscape Tausende US-Dollar kosteten, zogen es viele Leute vor, die freie NCSA-HTTPd-Serversoftware weiter zu verwenden. Einer derjenigen, die dies taten, war Brian Behlendorf. Wie Allman in Kalifornien geboren, aber fast zwei Jahrzehnte später im Jahr 1973, ging Behlendorf ebenfalls nach Berkeley, wo er sich mit dem Internet zu beschäftigen begann. „Als ich nach Berkeley kam, verwendeten dort alle E-Mail", erzählt er. „Also schrieb ich mich in verschiedene Musikdiskussionsforen und Ähnliches ein und begann, an verschiedene Leute E-Mails zu schicken. Bald stellte ich fest, dass mir das Spaß machte." Behlendorf vertiefte sich in die Sache und stieß auf die damals neue Welt des World Wide Web. Mitte 1993 unterhielt er sich zufällig mit einem Freund, der beim Magazin Wired arbeitete und sich mit dieser neuen Technologie beschäftigte. „Sie hatten einen E-Mail-Robot", erinnert sich Behlendorf. „Man konnte von ihm Artikel anfordern, und diese Artikel wurden einem dann zugeschickt. Ich kam hinein und upgradete auf einen Gopher Server, der zufällig auch etwas namens HTTP konnte, eine Sache, von der damals kaum jemand etwas wusste," Gopher, im Gegensatz zu den Hypertext-Links des Web eine Reihe von verschachtelten Menüs, war eine alternative Methode, um durch die Informationen des Internets zu navigieren. In seinem Buch meint Berners-Lee, einer der Gründe dafür, warum das Gopher-System kein ebenso durchschlagender Erfolg war wie das Web, lag darin, dass die University of Minnesota, wo die Gopher entwickelt worden waren, beschlossen hatte, von den Benutzern eine Lizenzgebühr zu verlangen, anstatt sie frei zur Verfügung zu stellen, wie er es getan hatte. Dieses „Ding namens HTTP" war ein Webserver. Behlendorf erinnert sich: „Dort kam eine Menge Verkehr auf, und schließlich war ein Punkt erreicht, wo die Gopher-Site keinen Sinn mehr


------------------------------------------------------------------------------------machte. Wir hatten zwischen 3.000 und 5.000 Zugriffe täglich." Das war Ende 1993. „Etwa Mitte 1994 war klar, dass das etwas Interessantes werden könnte", fährt Behlendorf fort. „Wir begannen damals, HTML [HyperText Markup Language] zu entwickeln" - neue Webseiten -, „die zusätzliche Inhalte enthielten, die nicht im Magazin waren. Es begann sich herauszukristallisieren, dass dies eine Plattform für eine einzigartige Marke oder eine einzigartige Publikation werden könnte. Das war die Geburtsstunde von HotWired", einem der ersten Onlinemagazine. Obwohl es sich letzten Endes nicht als unabhängiges, profitables Unternehmen etablieren konnte, fand HotWired bald Anerkennung als Schaufenster für Webtechnologien. Behlendorf wurde zum Chief Engineer von HotWired ernannt und wählte für seine Site den NCSA-HTTPd-Server. „Ich hatte begonnen, ihn ziemlich intensiv zu benutzen", sagt er, „und dann zeigte sich da dieses Sicherheitsloch, das geschlossen werden musste. Jemand brachte zu diesem Zweck einen Patch heraus, und bald kursierten auch andere Patches. Einige von ihnen waren leistungsbezogen, und ein paar andere waren nach dem Motto gestrickt: ,Das hier ist dumm, es muss verbessert werden.'" Diese Patches wurden auf einer Mailingliste namens WWWTalk gepostet. Sie wurde von CERN, dem europäischen Kernforschungszentrum in Genf, gehostet, das der Geburtsort des Web gewesen war. In der Vergangenheit waren diese Patches vom Entwicklungsteam des NCSA aufgegriffen und dann zur Verbesserung des Code verwendet worden. Dann änderten sich die Dinge. Behlendorf erinnert sich, dass „da jemand war, der an WWW-Talk postete: .Wird das NCSA jemals auf die Patches reagieren, die wir ihm schicken?' Niemand hatte irgendeine Rückmeldung vom NSCA erhalten, und deshalb gab es kein ausdrückliches ,Nein, danke'. Es gab einfach gar nichts." Seiner Meinung nach ist die Erklärung einfach: „Sie reagierten zum Teil deshalb nicht, weil sie Rob McCool und ein paar andere Leute an Netscape verloren hatten. Wahrscheinlich waren sie durch die Zahl der Leute, die schrieben, um Hilfe baten, Dinge einsendeten und Ähnliches mehr einfach überfordert. Vielleicht wussten sie gar nicht, wie sie ihnen antworten sollten."


--------------------------------------------------------------------------------------Angesichts dieses Mangels an Reaktionen fanden die Leute der WWWTalk-Mailingliste eine einfache Lösung. Behlendorf erinnert sich: „Jemand anderer schlug vor, sich zusammenzutun, um die Lücke zu schließen, die das Team der NCSA hinterlassen hatte. Ich stellte dann freiwillig Ressourcen zur Verfügung, damit wir das tun konnten." Diese Ressourcen waren ziemlich rudimentär. „Es war ein ganz einfacher Kasten", erklärt Behlendorf. „Also 16 Mbytes, 486, nichts Besonderes. Aber er war mehr als stark genug, um eine oder zwei Mailinglisten und eine Website, eine FTP-Site und ähnliche Dinge zu betreiben. Er war auf einer privaten Maschine, die ich im Netzwerk bei HotWired stehen hatte, die mich unabhängig von irgendeiner Firma machte." Neben seiner Maschine brachte Behlendorf noch etwas anderes in das Projekt ein: einen Namen. Der Name, den er im Sinn hatte, war einer, den er bereits für ein anderes Projekt verwendet hatte. „Ich hatte Freunde in einer Firma namens EIT Enterprise Integration Technologies", erklärt Behlendorf „Dort unterhielten wir uns darüber, was in einem kommerziellen Webserver enthalten sein sollte, wenn jemand einen schreiben sollte. Also erstellte ich aufgrund einiger verschiedenen Features eine Seite und gab ihr einfach einen Namen - Apache. Da ich diesen Namen interessant fand, endlich etwas ohne Web-dies oder Spider-das, oder Arachnid oder irgendeine dieser Metaphern, die [damals] gern verwendet wurden. Es war ein abstrakter Name, der sich auf nichts Spezifisches bezog, sondern einfach für einen leistungsstarken Server stand." Aus dem kommerziellen Webserver Apache wurde nie etwas, und so entschloss sich Behlendorf, diesen „interessanten Namen" zu recyceln. Er erinnert sich: „Als ich mich schließlich mit ein paar Leuten zusammensetzte und begann, mit ihnen Patches [für HTTPd] auzutauschen, tauchte die Frage auf: .Sollen wir unsere eigene Distribution herausbringen?' Ich schlug den Namen ,Apache' vor, und er schien sehr gut anzukommen. So entstand dieser Name, Als ich ihn zur Verfügung stellte, fanden ihn die Leute ziemlich komisch, weil der neue Apache-Server tatsächlich ein ,patchreicher Server' war, da er aus Patches des NCSA Code zusammengesetzt war.


------------------------------------------------------------------------------------Die Apache-Mailingliste wurde schnell zum Erfolg. „Ich glaube, dass sie am ersten Tag zwischen 30 und 40 Abonnenten hatte", erinnert sich ßehlendorf, „und nach drei oder vier Monaten waren es schon etwa 150. Sie war ziemlich populär. „Wir gingen eigentlich ohne Plan und Schritt für Schritt vor. Es gab niemanden, der zu Beginn erklärt hätte: ,So werden wir es machen. Alle vergruben sich in das Projekt und verwirklichten es schließlich", erinnert er sich. „Die Leute begannen, diese Patches auf den Listen zu posten, und jemand meldete sich und sagte: ,Ich melde mich freiwillig für die Integration in einen Standard, den wir herausbringen können. Die Leute leisteten ihre Beiträge zu verschiedenen Zeitpunkten. Wir würden eine Release herausbringen. Ich meldete die Domain Apache.org an und linkte sie auf diese Maschine." Da sich die Apache Group zur Gänze auf Freiwillige auf der ganzen Welt stützte, von denen die meisten Vollzeitjobs etwa im Bereich Websitebetrieb hatten, wurde beschlossen, ein außergewöhnliches Modell für die Mailingliste und die Softwareentwicklung zu verwenden. Behlendorf beschreibt, wie sie zu diesem Beschluss kamen: „Wir wählten neun oder zehn Leute aus, von denen wir meinten, dass sie am meisten beigetragen hatten", erklärt er, „und sagten: Lasst uns diese Leute zur Kerngruppe ernennen. Wir können die Kerngruppe später ja jederzeit erweitern." Diese Kerngruppe legte dann ziemlich komplizierte Abstimmungsregeln fest. Außerhalb der Gruppe gab es Leute, die Bugreports und Patches einsendeten, wie es auch bei Linux und anderen Projekten im Bereich Freie Software der Fall war. Behlendorf fasst die Philosophie dieses Ansatzes so zusammen: „Wir streuen die Verantwortung für den Code unter Leuten, denen wir vertrauen, möglichst breit, und wir bringen mehr zustande, als eine Person allein es vermag." Inspiriert wurde die Philosophie durch die Art und Weise, wie das Internet geführt wurde und sich entwickelte. „Ich glaube, das war etwas, was viel mit dem IETF-Prozess gemeinsam hatte", erklärt Behlendorf. „Man stützt sich auf einen groben Konsens und laufenden Code." IETF ist das Akronym von Internet Engineering Task Force. Die spezialisierten Arbeitsgruppen dieser Task Force, die allen Interessierten offen stehen, veröffentlichen das, was als RFC (Requests for Comments -


--------------------------------------------------------------------------------------Einladung zu Kommentaren) bekannt ist. Diese Dokumente enthalten die vorgeschlagenen technischen Standards. Obwohl es keine Körperschaft gibt die diese Standards durchsetzen könnte, bewirkt der „grobe Konsens" zwischen den Mitgliedern der Arbeitsgruppe gemeinsam mit der hart erkämpften Autorität der IETF, dass die meisten RFC von der Internetgemeinde meist in angemessener Zeit angenommen werden. Behlendorf hält diese Methode nur für teilweise erfolgreich, weil die Dinge in der Softwarewelt „entweder funktionieren oder nicht funktionieren. Wenn es darum geht, welcher Algorithmus [mathematische Technik] besser für die Lösung eines Prohlems geeignet ist oder welcher das bessere Sicherheitsmodell ist etc., ist die Sache meistens ziemlich eindeutig." Der IETF-Ansatz „grober Konsens und laufender Code" konnte ebenso gut das Motto für Apache, Linux und all die anderen Projekte im Bereich der freien Software sein, Apache hatte HTTPd 1.3 des NCSA als Ausgangspunkt genommen und dann für die Produktion der ersten offiziellen Version Apache 0-6.2 im April 1996 Patches hinzugefügt. „Wir entschieden uns für eine Lizenz, die der BSD-Lizenz ziemlich ähnlich war", sagt Behlendorf. Ausschlaggebend waren die Ähnlichkeit und die engen Verbindungen zwischen den Entwicklungsgemeinden von Apache und Berkeley Unix. Die Arbeit ging weiter, aber bald wurde das völlige Neudesign beschlossen. „Wir profitierten davon, dass jemand [Robert Thau], einer der Entwickler, das Ganze von Grund auf neu geschrieben hatte. Er hatte einen Großteil der Funktionen des Servers vom Kern getrennt und in eine Reihe von Modulen gepackt." Behlendorf meint, dass dieser Ansatz, den Code modular zu gestalten, ähnlich dem Ansatz war, den Linus für den Linux-Kernel gewählt hatte; er eignete sich gut für das verteilte Entwicklungsmodell, das den meisten Aktivitäten im Bereich der freien Software zugrunde lag. Apache 1.0 mit der neuen Architektur kam im Dezember 1995 heraus. Ein paar Monate später, ein Jahr nachdem die Apache Group gegründet worden war, wurde Apache zum meistverwendeten Webserver im Internet, wie eine von Netcraft durchgeführte Studie besagt. Seit damals steigt sein Marktanteil von Monat zu


------------------------------------------------------------------------------------Monat, und im Jahr 2000 lag er bereits weit über dem von Netscape und Microsoft. Behlendorf schreibt diesen außerordentlichen Erfolg teilweise dem Timing zu, weil Netscape und Microsoft es versäumt hatten, das moderne Netz bereitzustellen, das die Benutzer zu dem Zeitpunkt, an dem Apache auf der Bildfläche erschien, bereits haben wollten. Apache bekam auch Auftrieb von den neuen Webhosting-Diensten, die von den Internet Service Providern (ISP) angeboten wurden. Neben der Netzverbindung, die sie seit jeher angeboten hatten, boten sie nun auch Webserver an, auf denen Firmen ihre Sites billiger aufsetzen konnten als firmenintern. Apache war für das Webhosting deshalb so beliebt, ist Behlendorf überzeugt, weil die ISP „Bedürfnisse hatten, die von einer Einzelfirma nicht leicht abgedeckt werden konnten". Als Beispiel nennt er die „Möglichkeit, in einer Box 10.000 verschiedene [Web-] Domänen zu hosten". Da der Code von Apache zugänglich war, konnten die ISP ihn so anpassen, dass er diesen Anforderungen entsprach, ohne warten zu müssen, bis kommerzielle Unternehmen wie Netscape oder Microsoft sich dazu herabließen, verschiedene Features anzupassen. Obwohl das Apache-Team weder Netscape noch Microsoft bekämpfte, war es eine wichtige Überlegung, ob man Apache als ernsthafte Alternative zu kommerziellen Servern positionieren sollte. Behlendorf erklärt den Grund: „Hätte es Apache nicht gegeben", sagt er, „hätten die Leute auf jeden Fall begonnen, Microsoft-spezifische Websites zu entwickeln, die auf Microsoft-Servern gehostet waren, um damit Microsoft-Kunden zu erreichen, und dann Netscape-Server, um damit Netscape-Kunden zu erreichen, und sie hätten im Grunde zwei verschiedene Arten von Wehsites unterhalten müssen, um mit diesen beiden verschiedenen Kundengruppen kommunizieren zu können." Ohne Apache hätten also die Browserkriege, die 1996 ausbrachen, mit großer Wahrscheinlichkeit auf die Welt der Serversoftware übergegriffen. Dies hätte wiederum zu einer ernsthaften Spaltung des World Wide Web geführt, da die Unternehmen gezwungen gewesen wären, sich entweder an Microsoft oder an Netscape anzupassen. So wären ihnen ganze Heerscharen potenzi-


--------------------------------------------------------------------------------------eller Kunden entgangen oder sie hätten zwei Arten von Websites schaffen müssen, um den ganzen Markt bedienen zu können. In diesem Sinn war Apache maßgeblich daran beteiligt sicherzustellen, dass die einheitlichen Standards des Web eingehalten werden. Und das ermöglichte wiederum den Höhenflug des E-Commerce. Auch wenn es paradox erscheint - die Dotcom-Welt mit ihren volatilen Börsengängen und wahnwitzigen Bewertungen hat dieser freien Software viel zu verdanken. Apache hat noch eine weitere wichtige Auswirkung. Behlendorf erklärt: „Ab seiner ersten Version wurde es auf Sites wie HotWired und vom MIT verwendet. Yahoo! verwendet es glaube ich schon seit drei oder vier Jahren. Das heißt, es wurde sehr schnell zu einem Produkt erster Wahl - auf derselben Ebene wie der Internet Information Server von Microsoft oder der Webserver von Netscape." Er fährt fort: „Das Wichtigste, was wir bewiesen haben und wahrscheinlich erfolgreicher als die anderen, ist, dass man Open Source in einer missionskritischen Situation verwenden kann." Freie Softwareprogramme wie Sendmail und BIND waren in einem ähnlichen unternehmenskritischen Kontext schon viel länger verwendet worden, litten aber unter dem Nachteil, fast unsichtbar zu sein, nicht zuletzt deshalb, weil sie so gut funktionierten. Mit dem messbaren Erfolg von Apache, deutlich sichtbar in den monatlichen NetcraftBerichten, aus denen hervorging, wie viele öffentliche Webserver welches Programm verwendeten, wurde den Leuten immer stärker bewusst, dass freie Software von vielen Unternehmen eingesetzt wurde, aber auch, dass sie auf der wichtigsten neuen Entwicklung lief, die die Computerwelt seit Jahrzehnten hervorgebracht hatte: dem World Wide Web. Apache hatte eine entscheidende Rolle in der Bereitung des Bodens für den späteren und anhaltenden Erfolg von GNU/Linux und in dem gewaltigen Aufschwung der Open-Source-Programme und Methoden der späten neunziger Jahre gespielt. In einer Hinsicht hält Apache unter den freien Softwareprojekten auch heute noch eine führende Stellung. Während immer noch heftig diskutiert wird, ob es denkbar ist, dass Open-Source-Software wie GNU/Linux Microsoft je überflügeln wird, hat Apache das bereits geschafft.


------------------------------------------------------------------------------------Und trotzdem wurde sogar diese Leistung übertroffen - von Perl, einer frei verfügbaren Programmiersprache, die universell für System Verwaltungsaufgaben und für den Betrieb komplexer E-CommerceSites verwendet wird. Apache mag Microsoft und Netscape um Längen schlagen, aber Perl hat im kommerziellen Sektor überhaupt keine ernsthaften Rivalen. Sein Urheber, heute allgemein als „Perl God" bekannt, ist Larry Wall, neben Richard Stallman und Linus einer der bekanntesten und einflussreichsten Entwickler freier Software. Wall wurde im Jahr 1954 in Kalifornien geboren. Sein Vater war Geistlicher, und seine religiöse Erziehung beeinflusste sein Leben und seine Arbeit stark. Anders als bei vielen anderen Hackern der Spitzenklasse spielten Computer in der Frühzeit seines Lebens keine besondere Rolle: „Der erste Computer, den ich je zu Gesicht bekam, war der programmierbare Rechner, den wir in meinen letzten Schuljahren in unserer Highschool hatten", erzählt Wall. „Davor hatte ich kaum mit Computern zu tun. Aber als sie in meiner Umgebung auftauchten, erwachte mein Interesse schnell." Mit „echten" Computern arbeitete er das erste Mal an der Universität. Wall studierte an der Seattle Pacific Universäty, wo er eine außergewöhnliche - und für ihn charakteristische - Fächerkombination wählte. „Zuerst waren meine Hauptfächer Chemie und Musik", sagt er. „Ich hatte etwa ab der fünften Klasse Geige gespielt. Eigentlich war ich ziemlich gut darin. Andererseits hatte ich mich seit jeher für Naturwissenschaften interessiert. Das lag mir einfach. Mein Problem ist, dass mich zu viele Dinge interessieren" - ein Charakterzug, der Jahrzehnte später Früchte tragen sollte, als Wall die außergewöhnlich reichhaltige und vielgestaltige Welt von Perl schuf, deren Motto unter anderem lautet, dass es „nicht nur eine Art gibt, etwas zu tun". Am Anfang machte ihm diese Vielseitigkeit jedoch das Leben schwer. „Das Problem sowohl in der Musik als auch in der Chemie ist, dass von einem erwartet wird, dass man das und eben nur das macht", erklärt er. „Aber das war nichts für mich." Wall versuchte es auf andere Weise. „Eine Zeit lang schrieb ich mich in die Vorbereitung für das Medizinstudium ein, aber das war nur eine Ausrede, um jede Menge naturwissenschaftlicher Kurse belegen zu


--------------------------------------------------------------------------------------können", gibt er zu. Wall graduierte acht Jahre nach seinem Eintritt ins College, von denen er drei als Chefprogrammierer im Computerzentrum der Universität verbracht hatte. Er graduierte in einer weiteren exzentrischen Fächerkombination: natürliche und künstliche Sprachen. Er war dabei ziemlich pragmatisch vorgegangen. „Es sah aus, als hätte ich genügend Linguistik- und Computerkurse, um zu graduieren", sagt er, „wenn ich sie nur irgendwie kombinierte." Was die natürlichen Sprachen betraf, sagte er, „hatte das Ganze mehr mit der Erforschung der Funktionsweise von Sprachen zu tun - in dem Sinn, dass man einen Datensatz aus einer willkürlichen Sprache nimmt und nach Mustern darin sucht." Muster zu finden sollte ein immer wiederkehrendes Thema von Walls Karriere als Programmierer werden. Die Linguistik hatte durchaus auch einen praktischen Nutzen, wenn auch einen außergewöhnlichen. „Einer der Gründe, warum ich Linguistik studiert hatte, bestand darin, dass meine Frau und ich darüber nachdachten, in die Mission zu gehen", sagt Wall, „und uns einer Gruppe namens The Wycliffe Bible Translators anzuschließen." Diese Gruppe machte es sich zur Aufgabe, in Gebiete zu gehen, die eher weiße Flecken auf der Landkarte waren, eine bis dahin noch nicht studierte lokale Sprache zu erlernen und dann die Bibel zu missionarischen Zwecken in diese Sprache zu übersetzen. Wieder hätte es Wall diese Berufswahl ermöglicht, mehrere seiner Interessen zu kombinieren. „Wir meinten, dass uns das einerseits Spaß machen und andererseits nützlich sein würde - auf jeden Fall das Thema meines Lebens. Leider bekam ich während des Studiums eine Lebensmittelallergie, und so musste ich mir den Gedanken an eine missionarische Tätigkeit aus dem Kopf schlagen." In den Jahren 1980/1981 war er dabei, sein Studium in Berkeley abzuschließen. Der florierenden Hackergruppe dort hatte er sich nie angeschlossen. Wall leistete sich den Luxus nicht, Zeit mit Nachdenken darüber zu verschwenden, was er als Nächstes tun wollte. „Wir erwarteten ein Baby", erklärt er. „Meine Frau wollte in der Zeit der Geburt in der Nähe ihrer Mutter sein. Also wechselten wir an die UCLA [University of California Los Angeles], bevor wir dann die Entscheidung trafen, vollkommen auszusteigen. In diesem Sommer


------------------------------------------------------------------------------------brauchte ich also einen Job. Mein Schwiegervater arbeitete für eine Firma namens Systems Development Corporation (SDC), Er verschaffte mir dort Arbeit, wie ich hoffe, ohne allzuviel Nepotismus." Walls Arbeit bei SDC war als geheim eingestuft (DARPA), aber daneben fand er Zeit zum eigenständigen Programmieren. „Wir hatten einen Newsfeed", erzählt er. „Dazu gehörte ein Newsreader, der aber wirklich schlecht designt war. Ich dachte, dass ich das wohl ein bisschen besser könnte." Wall entwickelte rn - benannt in memoriam des ursprünglichen Readnews-Programms, das ihn so wenig beeindruckt hatte. „Ich glauhe, ich entwickelte es '83 und brachte es '84 heraus", sagt er. „Und ich stellte fest, dass es den Leuten gefiel." Als er seine freie Software der Computergemeinde vorstellte, entdeckte er noch etwas anderes. „Die Leute fanden Bugs, und ich produzierte Patches und Verbesserungen für sie", sagt er. „Ich versendete diese Patches, aber die Leute verwendeten sie nicht. Oder noch schlimmer sie verwendeten sie irgendwie, ohne bestimmte Reihenfolge, und das machte die Wartung zu einem Albtraum. Es war schrecklich zu versuchen, all dieses verteilte Zeug im Netz zu machen." Wall hatte sich hier mit einer Gruppe neuer Probleme herumzuschlagen, die von diesem neuen Distributionsmedium namens Internet aufgeworfen waren, das erst kurz vorher im Jahr 1982 das Licht der Welt erblickt hatte. Die Folge war, so Wall, dass „ich mehr oder weniger zur Selbstverteidigung das Patch-Programm schrieb". Dabei handelte es sich um ein ziemlich kleines Programm, dessen Aufgabe es war sicherzustellen, dass die Programmkorrekturen, die Patches, genau richtig angewendet wurden. Wall weist darauf hin, dass sein kleines Patchprogramm, so banal es auch klingt, „in irgendeiner Weise die Kultur des Computing stärker veränderte, als Perl es später tun sollte". Walls Patch kann als kleiner, aber wichtiger Sprung vorwärts betrachtet werden, der das Modell der verteilten Entwicklung vorantrieb und in der Folge zu jenem Höhenflug der freien Software führte, der bis auf den heutigen Tag anhält. Wall konzentrierte sich einige Jahre lang auf die Entwicklung seiner beiden Hauptprojekte, rn und Patch. Dann bewogen ihn aber die praktischen Erfordernisse seines täglichen Lebens als System-


--------------------------------------------------------------------------------------administrator, eine neue Herausforderung anzunehmen, die zur Schaffung von Perl führte. Sein Arbeitgeber SDC hatte ein Problem: „Die Hälfte unseres geheimen Projekts war in Santa Monica [Kalifornien] angesiedelt und die andere Hälfte in Paoli, Pennsylvania", erklärt WalL „Wir mussten die Konfigurationskontrollinformationen austauschen, aber sie waren alle geheim. Deshalb hatten wir eine verschlüsselten Verbindung zwischen Santa Monica und Paoli mit einer Geschwindigkeit von etwa 1200 Baud - irgendetwas in dieser Größenordnung." „Was das Netzwerk anbelangte, konnten wir nicht voraussagen, wann das Ding laufen würde und wann nicht", fährt Wall fort, „und deshalb mussten wir eine Möglichkeit finden, das Zeug automatisch hinüberzuschieben, wenn das Ding funktionierte, ohne dass wir intervenieren und den Befehl „den Prozess starten“ geben mussten. Nun, das ist etwas, was das Usenet-News-System die ganze Zeit macht. Ich sagte: Nehmen wir einfach Usenet-News und passen wir es ein wenig an. Dann wird es [die Kontrollinformationen] automatisch hinüberschicken, wenn die Verbindung steht." „Genau das tat ich", sagt Wall, „und es funktionierte großartig. Aber dann waren unsere ganzen Informationen in vielen kleinen Artikeldateien unterwegs." Diese konnten mithilfe des rn-Newsreader gelesen werden, aber Walls Vorgesetzte wollten nicht, dass seine Informationen in einem Haufen „kleiner Artikeldateien" herumschwirrten. „Sie wollten Berichte", sagt er. Wall musste eine einfache Methode finden, all die kleinen Dateien, die über die Verbindung kamen, automatisch zu einem Bericht zu kombinieren, der für das Management geeignet war. „Also sah ich mir die Tools an, die mir zur Verfügung standen“, erinnert sich Wall „Ich begann zu versuchen, irgendetwas zusammenzubasteln. Aber ich erkannte bald, dass es nicht ordentlich funktionieren würde. An diesem Punkt begann mir zu dämmern, wo das Problem der Toolbox-Philosophie von Unix lag." Diese Philosophie besagte, dass jedes Tool eine bestimmte Sache gut machen sollte. Sie hatte dazu geführt, dass viele kleine, leistungsstarke Tools entwickelt worden waren, aus denen sich Unix zusammensetzte; das stellte einen großen Bruch gegenüber vorhergehenden Betriebssystemen dar und hatte das gesamte GNU-


------------------------------------------------------------------------------------Projekt erst möglich gemacht. Wall stellte jedoch fest, dass diese Stärke auch eine Schwäche sein konnte. „Da jedes Tool ein Prozess für sich ist", sagt er, „sind sie irgendwie kompliziert, und es gibt jede Menge Optionen. Aber sie sind beschränkt, und wenn man versucht, sie über ihre Kapazitäten hinaus zu beanspruchen, scheitert man." Ein beliebtes Tool ist zum Beispiel die Unix Shell. Wall sagt dazu: „Shells waren gut geeignet um die Dinge zu beschleunigen -da war also die Dimension der Beschleunigung - und der schnellen Erstellung von Prototypen. Trotzdem war [die Sprache] C gut geeignet, wenn es um die Manipulation auf ganz niedriger Ebene ging. Aber das ist eine andere Dimension. Beide waren sehr gut in einer Sache und schlecht in der anderen. Dort draußen gab es also diese große Kluft, die geschlossen werden musste", sagt er und fügt hinzu: „Deshalb hatte ich von allem Anfang an vor, sozusagen die Welt zu übernehmen." Die geplante Übernahme war ausschließlich freundlicher Natur. Sie wurzelte in dem alten Wunsch, Tools zu entwickeln, die so nützlich wie möglich sein sollten. Mit seinem neuen Tool wollte Wall etwas schaffen, was so nützlich war, dass es von vielen Leuten übernommen werden würde. Aufgrund seiner bisherigen Erfahrungen mit rn und Patch, die bereits weithin verwendet wurden, hatte er eine ziemlich gute Vorstellung davon, wie er vorgehen wollte. „Mir war von Anfang an klar, dass ich es wahrscheinlich vertreiben würde", sagt er, „und dass die Leute es wahrscheinlich gern verwenden würden. Viele sind überrascht, wenn ich das sage. Die meisten Leute behaupten ja, sie hätten die Entwicklung ihres Tools nicht erwartet. Aber dazu muss man wissen, dass ich bereits Sprachen geschrieben hatte, die von anderen Leuten verwendet wurden. Und ich hatte bereits Programme wie rn und Patch vertrieben und hatte deshalb eine leise Ahnung, dass Dinge, die ich mochte, wahrscheinlich auch für andere attraktiv waren." Als er mit dem Entwerfen seiner neuen Sprache begann, nahm er seine Lieblingsfeatures von bereits bestehenden Sprachen. „Ich weiß, was ich an den verschiedenen Sprachen mag und was nicht -am besten weiß ich, was ich nicht mag", sagt er. „Was mich an manchen Sprachen stört, ist zum Beispiel, wenn sie einen Punkt


--------------------------------------------------------------------------------------nehmen und ewig darauf herumreiten." Es gab jedoch noch eine weitere Quelle der Inspiration, die genauso wichtig war. „Ich wollte mir Ideen von den natürlichen Sprachen leihen", erklärte er. Das war ein ziemlich radikales Vorhaben, das von seinen persönlichen Interessen und seiner Ausbildung herrührte. „Es war schon früher darüber diskutiert worden", erklärt er, „aber es war bis zu diesem Zeitpunkt, soweit ich wusste, noch nie gemacht worden. [Die Business-Programmiersprache] Cobol war angeblich selbstdokumentierend, weil sie englisch war, aber das bedeutete nichts anderes, als dass man pseudoenglische Phrasen nahm und Dinge hineinsteckte anstelle von Worten. Das heißt, dass es sich eigentlich um Englisch auf einer sehr einfachen Ebene handelte. Ich wollte etwas, was auf einer viel tieferen Ebene funktionierte", sagt er. Vor allem wollte er seine neue Computersprache um ein entscheidendes Feature erweitern. „Ich wollte Ausdrucksfähigkeit". erklärt er. „Ich wollte keine Sprache, die einem diktierte, wie man ein Problem lösen sollte. Es gibt so viele Sprachen, die die Idee des Minimalismus verfechten - das liegt zum Teil am mathematischen Hintergrund der meisten Leute, die sich mit Computerwissenschaften beschäftigen." Wall weist darauf hin, dass die Leute, wenn sie natürliche Sprachen verwenden, „ausdrucksstarke Worte verwenden wollen; das heißt, dass sie sich nicht auf eine rudimentäre Sprache beschränken." Seiner Meinung nach sollte es bei Programmiersprachen nicht anders sein. „Mein alles übergreifendes Lebensthema ist eigentlich, Leuten zu helfen", erklärt er. „Das heißt, dass es irgendwie natürlich für mich ist, eine Sprache auf eine Weise zu öffnen, von der ich glaube, dass sie den Leuten am meisten bringt." Das Öffnen der Sprache bedeutet, „dass ich es anderen erleichtern will, das zu tun, was sie tun wollen, und nicht das, von dem ich glaube, dass sie es tun sollten", sagt er. Zwischen Walls Ansatz für seine neue Sprache und der Open-SourceSoftware ergibt sich eine interessante Parallele. Wo Letztere es den Benutzern ermöglicht, die Dinge auf ihre Weise zu tun -indem sie bei Bedarf den Quellcode ändern -, ermöglicht es ihnen Walls Schöpfung, die Sprache auf eine Weise zu verwenden, die ihrer Art zu denken und zu arbeiten besser entspricht. Was als Perl


------------------------------------------------------------------------------------bekannt wurde, bietet dieselbe Freiheit wie Open Source, ist aber diesmal ausdrücklich in die Struktur der Sprache eingebaut und keine implizite Konsequenz der Verfügbarkeit des Quellcodes. Walls Namenswahl und die Art und Weise, wie er nach dem Namen Ausschau hielt, war charakteristisch. „Auch daran, dass ich nach einem Namen mit einer positiven Konnotation suchte, erkennt man, dass ich mir ziemlich sicher war, dass es von vielen Leuten verwendet werden würde", sagt er. Dank seiner linguistischen Ausbildung legte er auf diesen Aspekt großen Wert. „Ein Wort in einer natürlichen Sprache kann auf die verschiedensten Arten interpretiert und verwendet werden. Es hat viele verschiedene Bedeutungsschattierungen, und man kann über ein Wort, das negative Konnotationen hat, nur negativ denken, sogar dann, wenn man es in einem positiven Kontext verwendet", merkt er an. Er erklärt, wie der Name „Perl" zustande kam: „Also ging ich das Onlinewörterbuch durch und sah mir alle Wörter mit drei oder vier Buchstaben an, um zu sehen, ob ein geeigneter Name für eine Sprache darunter war. Aber mir gefiel keines der Wörter mit drei oder vier Buchstaben. ,Perl' als solches stand ja nicht im Wörterbuch. Ich dachte an verschiedene andere Dinge und entschied mich schließlich für ,Perl', weil das Wort meiner Meinung nach positive Konnotationen hatte." Rückblickend rechtfertigte er seine Wahl, indem er ihr das Akronym „Practical Extraction and Report Language" zuwies. „Das ,and' steht noch für das ursprüngliche ,a' in dem Wort", sagt er. Der Name stimmt. Während seiner gesamten Programmiererkarriere war Wall daran gelegen, praktische Dinge zu entwickeln, die von möglichst vielen Leuten verwendet werden konnten. Die Extraktion war auch zu einem ständigen Thema für ihn geworden: Bei seinem Newsreader rn ging es unter anderem um die Extraktion von Informationssträngen aus dem undifferenzierten Strom der UsenetPostings, und Patch war rund um die Idee entwickelt worden, nur jene Änderungen zu extrahieren, die auf den Quellcode angewendet werden mussten. Perl als Textverarbeitungstool par excellence zeigt wieder einmal die Faszination, die Manipulation und Analyse der Wörter- und Zeichenströme, aus denen natürliche und künstliche Sprachen bestehen, auf Wall ausüben.


--------------------------------------------------------------------------------------Obwohl er passend war, musste der Name „Pearl" geändert werden, so wie „Monix", Tanenbaums ursprünglicher Name für Minix, geändert werden musste. „Ich hatte Gerüchte von einer anderen Sprache namens Pearl gehört, irgendeiner obskuren Grafiksprache", sagt Wall „Also beschloss ich, die Schreibweise zu ändern. Ich fand, dass es wohl am besten war, das Wort zu verkürzen, denn ich bin faul beim Tippen. Ich wollte einen Namen mit positiven Konnotationen, [aber] ich wollte auch einen, der kurz war, weil ich glaubte, dass ihn die Leute ständig tippen würden." So wurde „Pearl" zu „Perl". 1986 begann Wall, an dem zu arbeiten, was Perl werden sollte. Die erste Version wurde nach etwa sechs Monaten Arbeit fertig gestellt. Die offizielle Version Perl 1.0 kam im Oktober 1987 heraus. Wie Wall sagt, programmierte er oft über lange Strecken und schrieb kaum etwas nieder: „Das Einzige, wofür ich Papier verwende, sind Notizen, die mich daran erinnern, was ich tun muss - aber nichts Langatmiges. Ein kurzes ,das reparieren' oder jenes implementieren', mehr ist es nicht", erklärt er. Wall erinnert sich, dass Perl, nachdem es herausgekommen war, ziemlich schnell erfolgreich wurde. „Natürlich gibt es immer die Pioniere, die sich sofort auf alles Neue stürzen", sagt er. Er weist jedoch daraufhin, dass es ,.Dinge gab, die ich bewusst tat, um Perl den Start zu erleichtern". Auch dies ist ein Hinweis darauf, dass Wall wollte, dass sein Programm weithin verwendet werden würde. So stellte er zum Beispiel Benutzern anderer Programmiersprachen Übersetzungsprogramme zur Verfügung, die ihren Code automatisch in Perl konvertierten. Wall sagt, dass er das machte, „weil ich dachte, dass die Leute die Möglichkeit haben sollten, das aufzugeben, was sie hatten, und eine Vorstellung davon zu bekommen, wie die Entsprechung in Perl aussehen würde" Diese Vorgehensweise war ziemlich bemerkenswert, vor allem für eine nicht kommerzielle Sprache, die sich sehr leicht als belanglos für alle hätte erweisen können. Wall musste dazu üher die Entwicklung von Perl hinaus noch weitere Arbeit leisten. Aher wieder ergab sich sein Handeln natürlich aus seinem Wunsch, den Benutzern zu helfen. „Mein Leben wird komplizierter, damit das Leben anderer einfacher wird", sagt er und fügt mit einer gespielten Arroganz, die


------------------------------------------------------------------------------------gleichzeitig selbstironisch ist, hinzu: „Ich spreche davon, den Leuten zu helfen, aber die andere Seite der Medaille ist, dass ich die Welt übernehmen will. Vielleicht bin ich größenwahnsinnig, aber ich möchte meinen Fußabdruck in der Welt hinterlassen." Diese Aussage beleuchtet Walls komplexen Charakter, aber es ist auch faszinierend, dass es genau dieses Verhalten war, das Linus einige Jahre später an den Tag legen sollte, als er seinen Kernel entwickelte. Auch er nennt die „Weltbeherrschung" oft als sein Ziel, und wie Wall ist er bestrebt, seine eigene Wichtigkeit herunterzuspielen. Wall ist sich dieser Parallele natürlich durchaus bewusst und versucht, für seine Weltbeherrschungspläne eine Art Vorrangstellung zu sichern. „Ich war vor ihm da", pflegt er über den jungen Senkrechtstarter Linus zu sagen. Walls Werbung für Perl war gleichermaßen vorgeplant. So richtete er zum Beispiel anders als andere es vielleicht getan hätten keine UsenetNewsgroup ein. um Unterstützung für Perl zu schaffen. Noch einmal zeigt seine Vorgehensweise ein kluges Verständnis des Prozesses, durch den Informationen über freie Software verbreitet werden. „Ziemlich bald, nachdem [Perl] herausgekommen war, gab es Anfragen wegen einer Perl-Newsgroup", erinnert er sich. „Ich lehnte das aber ab, weil ich mir kein Getto schaffen wollte. Das Usenet zeichnete sich zumindest damals durch die Dynamik aus, dass man etwas postete, was nicht zum Thema der betreffenden Newsgroup gehörte, und dann schrieben die Leute: ,Bring das doch in dieser anderen Newsgroup zur Sprache", erklärt er. „Ich wollte nicht, dass die Leute das über Perl sagen konnten. Deshalb machten wir die Shell-Programmier-Newsgroup unsicher, und jedes Mal wenn jemand fragte: ,Können wir dieses oder jenes tun?, antworteten wir ganz höflich: ,Nun, man könnte es in einer Shell so machen, aber in Perl ist es leichter, da macht man es so." Es ist interessant wie Wall hier missionarisch arbeitet. Er lebt unter Leuten, die in fremden Zungen wie in den Shell-Sprachen sprechen, und er konvertiert diese Sprachen, indem er ihre Probleme durch seine eigene linguistische Frohbotschaft löst. Wall richtete letzten Endes doch eine Newsgroup von Perl ein. Das half ihm, ein Gemeinschaftsgefühl zu erzeugen. Außerdem bot


--------------------------------------------------------------------------------------die Newsgroup ein ausgezeichnetes Forum für Feedback. Neben den Berichten über Bugs und Fixes gab es eine Art Feedback, die besonders wichtig war. „Es gibt da eine Botschaft, die ich immer und immer wieder verschicke", sagt Wall. „Jemand schickt mir ein Dankeschön oder was immer, und ich antworte: .Danke, ich lebe von dieser Art Ermutigung." Die Ermutigung erwies sich als ausreichend, um Wall in seinem eigenen Tempo viele Jahre lang an Perl weiter hacken zu lassen. „Ich machte die ganze Wartung für die ersten vier Versionen", erinnert er sich, „und schließlich stellte ich fest, dass mir das Ganze eigentlich über den Kopf wuchs. Der Druck, die Sprache zu erweitern, stieg immer stärker, und mir wurde bewusst, dass der Grund im Fehlen eines Erweiterungsmechanismus lag. Das war es, was das Wachstum blockierte." Wall traf eine wichtige Entscheidung. „1993 begann ein Prozess, der zur Folge hatte, dass ich im Grunde den Prototyp wegwarf, sagt er, „und das ganze Ding neu schrieb. Irgendwie erkannte ich, dass es meine erste und letzte Chance war das zu tun. Deshalb ging ich eine Liste aller Schlüsselwörter durch, die ich drinnen haben wollte, und schrieb, indem ich sie mir vor Augen hielt." „Die letzte Version von Perl 4 kam im Sommer 1993 heraus", erinnert er sich. „Ich arbeitete damals bereits an Perl 5, und Perl 5 erschien dann am 18. Oktober 1994. Dabei stellte ich fest, dass ich auch lernen musste zu delegieren. Deshalb übergab ich den Quellcode, schon während wir entwickelten und die Alphaversionen von Perl 5 durchgingen, verschiedenen Leuten", erklärt er. So befasste sich Wall etwa zu der Zeit, als Linus sein eigenes Delegationssystem schuf, mit demselben Problem. Einem Problem, vor dem alle erfolgreichen Projekte der freien Software eines Tages stehen. Aber wie zu erwarten war, entwickelte Perl seinen ureigenen Ansatz. Am Anfang war alles informell. „Irgendjemand sagte: ,Ich möchte an diesem oder an jenem arbeiten'", erinnert sich Wall. „Und ich sagte: ,O.k., du kannst anfangen, du hast die Stafette.' Diese Person entwickelte dann eine Version, und ich nahm sie zurück. Das entwickelte sich zu etwas, was wir das Kürbishaltersystem nannten. Der Kürbis ist im Wesentlichen die


------------------------------------------------------------------------------------Stafette, Chip Salzenberg" - einer der Perl-Leutnants - „erfand diesen Ausdruck", sagt Wall. „Schließlich lief es darauf hinaus, dass wir einen Chefintegrator haben, der Kürbishalter genannt wird", erklärt er. Für diese Integration muss man die genehmigten Patches nehmen und sie in den Hauptquellcode von Perl einbauen. „Wir haben die Mailingliste namens Perl 5 Porters, auf die ein Großteil der Diskussion entfällt, und dann gibt es da mich." Das bedeutet, dass Wall die letztendliche Kontrolle hat, dass er aber den tagtäglichen Betrieb von Perl an den Kürbishalter delegiert. Nicht zuletzt Dank dieser Änderungen floriert Perl, vor allem im Bereich der Webserver. „Das war etwas, was mich wirklich überraschte," räumt Wall ein. Ich sagte bereits, dass ich mir schon dachte, dass Perl florieren würde, aber ich dachte, es würde vor allem als Systemverwattungs- und als Textverarbeitungssprache erfolgreich sein. Ich sah das Web nicht voraus, aber [Perl] eignete sich ganz natürlich dafür Was ich sehr wohl voraussah, war dass die Leute eine Sprache wollten, die über zwei Qualitäten verfügte: dass sie Text gut editieren konnte und dass sie Dinge gut miteinander verbinden konnte. Wenn man bedenkt, was ein Webserver können muss: Er muss Text verarbeiten [um Webseiten zu manipulieren] und er muss Daten von irgendwoher bekommen. Das heißt, dass eine Sprache, die zu Textverarbeitung fähig ist und mit allem anderen verbunden werden kann, genau das Richtige ist Ich wollte, dass Per! in dem Sinn eine bescheidene Sprache ist, dass es durch seine Fähigkeit zur Zusammenarbeit konkurrieren kann. Dank seiner Bescheidenheit und Einfachheit ist Perl die heute wahrscheinlich am weitesten verbreitete „Klebstoffsprache" des ECommerce, die von Riesen wie Yahoo! und Amazon.com (die Perl beide intensiv einsetzen) abwärts verwendet wird. Wenn Wall schätzen soll, wie viele Perl-User es gibt, sagt er: „Eine Million ist glaube ich die richtige Größenordnung", und fügt hinzu: „Ich sage meistens eine Million, mehr oder weniger eine Million."


--------------------------------------------------------------------------------------Walls Leistung ist viel größer, als nur eine großartige Sprache geschrieben zu haben. Perl war eine der Technologien, die die erste Welle der interaktiven Websites und damit den E-Commerce selbst ermöglichten. Außerdem ebnete es den Weg für einen weiteren Bereich - den der Programmiersprachen -, wo der netzbasierte Prozess der offenen Entwicklung bessere Ergebnisse zustande gebracht hatte als die Prozesse, die die Softwareunternehmen traditionell für die Schaffung ihrer Black-Box-Produkte verwendeten. Es ist interessant, dass der Erfolg von Perl kein Zufall war, wie er es etwa bei Sendmail oder Linux gewesen war. Obwohl Perl sich aus Walls eigenen Bedürfnissen heraus entwickelte, legte er es von Anfang an so an, dass es nicht nur allgemein anwendbar war, sondern auch eine breite Benutzerschicht ansprach. Diese ungewöhnliche Strategie funktionierte, weil Wall genau wusste, was er tat und welche Prozesse er anwenden musste, um sein Ziel zu erreichen - ein Bewusstsein, das seine Wurzeln zweifellos in seiner Persönlichkeit hat und das durch seine doppelte Sprachausbildung gestärkt wurde. Dieses Bewusstsein zeigt sich in Walls unterhaltsamen Äußerungen in den „State of the Onion"-Gesprächen bei den jährlichen PerlKonferenzen. Diese Gespräche finden seit 1997 statt und werden von O'Reilly & Associates veranstaltet, die auch zahlreiche Bücher über Perl veröffentlicht haben (darunter eines von Wall). In diesen Gesprächen äußert sich Wall ganz nebenbei, aber in einer äußerst erhellenden Weise über die Ideen, die im Herzen der Programmierung von Perl liegen. Diese analytische und theoretische Seite hebt ihn in gewisser Weise von den anderen führenden Persönlichkeiten der Welt der freien Software ab, die eher intuitiv an das Codieren herangehen und praktischer orientiert sind. Nicht zuletzt durch diesen höchst persönlichen intellektuellen Ansatz, den er für seine Vorträge wählt, konnte Wall einen weiteren wichtigen Beitrag zur Bewegung der freien Software leisten. Er ist das Beispiel eines Spitzenprogrammierers, der sich ausgezeichnet artikulieren kann, witzig ist und dem die allgemeinen Auswirkungen seiner Arbeit ein tiefes Anliegen sind. Walls sanfte Stimme, seine Freundlichkeit und seine Ruhe bei Konferenzen und in Pressegesprächen haben das Image der Hacker als ungefestigte,


------------------------------------------------------------------------------------asoziale Typen mit zweifelhafter Moral und ohne Sinn für Humor korrigiert. Wenn Richard Stallman der Vater der freien Softwarebewegung von heute ist, kann Larry Wall zu Recht als sein Lieblingsonkel bezeichnet werden.

9

Die Kunst des Codierens

LANGE BEVOR LARRY WALL darüber nachdachte, wie er Perl zum Erfolg führen könnte, hatte Richard Stallman sich überlegt, warum die Hackergemeinde im AI-Lab des MIT so gut funktioniert hatte. Daraufhin begann er, diese Gemeinschaft wieder aufzubauen, und er setzte bewusst Schritte, um die Chancen ihres Überlebens zu maximieren. Da GNU/Linux und die freien Softwareprojekte wie Perl, Apache und andere nicht nur immer reifer, sondern auch immer bekannter wurden, stellten auch andere fest, dass es sich hier um einen größeren Trend handelte, und begannen zu erforschen, was dahinter steckte. Einen der ersten formalen Versuche, das GNU/Linux-Phänomen zu analysieren, unternahm Larry McVoy. Er wurde 1962 in Concord, Massachusetts geboren und war um einiges älter als andere LinuxSpitzenhacker wie Linus, Alan Cox oder Ted Ts'o. McVoy war tief in der Unix-Tradition verankert. Er hatte zuerst für


------------------------------------------------------------------------------------die Santa Cruz Operation (SCO) gearbeitet - die später Unix von Novell kaufte - und danach für Sun, sowohl im Software- als auch im Hardwarebereich. Die Erfahrung, die er durch diese Arbeit gewann, vermittelte ihm so viel praktisches Wissen über die Funktionsweise der Softwarebranche, wie nur wenige andere in der GNU/Linux-Bewegung aufzuweisen hatten. in der Zeit, in der er bei Sun arbeitete - im September und Oktober 1993 -, stellte McVoy etwas zusammen, was er später Sourceware Operating System Proposal nannte. Darin schlug er vor, dass Sun den Quellcode der SunOS 4 Version von Unix zur Verfügung stellen sollte, damit eine einheitliche Unix-Plattform geschaffen werden konnte, die imstande sein würde, es mit der rasant aufsteigenden Macht Microsoft aufzunehmen. McVoys Alternativvorschlag war, dass die UnixIndustrie GNU/Linux als gemeinsame Plattform annehmen sollte. Das war 1993, als Linux noch kaum zwei Jahre alt war, ein außerordentlich kühner Vorstoß. McVoys Sorge galt nichts Geringerem als der Zukunft von Unix. Anfang der neunziger Jahre, so sagt er, „war die Unix-Industrie ganz aus dem Häuschen über ihre Aktivitäten, und sie waren überzeugt, dass sie sich durchsetzen würden und blablabla. Aber in Wirklichkeit war es ganz anders: Wenn man als Ingenieur ein paar Jahre in die Zukunft blickte, konnte man ganz klar sehen, dass sie Selbstmord begingen" aus Gründen, die er in seinem Papier darlegte. Er hatte auch einen speziellen Anlass für seinen Vorschlag: Die Entscheidung von Sun, ab sofort eine andere Unix-Version seiner Hardware mitzuliefern. Bis zu diesem Punkt hatte sich das Betriebssystem namens SunOS auf die BSD-Version von Unix gestützt, die zum Großteil von Hackern der University of California in Berkeley entwickelt worden war. SunOS war ein starker Konkurrent der kommerziellen Produkte von AT&T, die damals UnixWare genannt wurden. Selbst innerhalb von Sun setzte sich diese Hackertradition fort. „SunOS war eine Sourcebasis, in die die Ingenieure aus Liebe zur intellektuellen Correctness und Perfektion investierten, und nicht so sehr wegen meines Gehalts oder meiner Aktienoptionen", erklärt

9. Die Kunst des Codierens

--------------------------------------------------------------------------------------McVoy. „Sieben oder acht Jahre lang waren die Ingenieure an den Wochenenden im Büro gewesen und hatten an dem Ding gearbeitet." Trotzdem gab der CEO von Sun, Scott McNealy, bekannt, dass sich das Unternehmen von diesem einzigartigen Wert trennen und auf die „offizielle" AT&T-Version von Unix umsteigen wolle. „Ich glaube, es gab keinen einzigen Ingenieur oder auch nur Manager, der nicht in die Höhle des Löwen - Scotts Büro - gepilgert und gesagt hätte: ,Sie sind verrückt, lassen Sie das." Aber am Ende, so McVoy, „zog McNealy das als Geschäftsentscheidung durch." Die Folge war, so erinnert sich McVoy: „Ich kochte vor Zorn. Ich war wirklich wütend." Er war davon überzeugt, dass das Unternehmen mit dem Umstieg von SunOS auf das, was unter dem Namen Solaris bekannt werden sollte, nicht nur ein großartiges Produkt verlor, sondern auch eine einzigartige Umgebung. „Als Systemingenieur, als jemand, der sich mit OS [-Betriebssystemen] beschäftigt, hätte man alles getan, um in diese Organisation aufgenommen zu werden", sagt er. „Die besten Köpfe der Branche waren dort versammelt. Wer mit den Besten arbeiten und möglichst viel lernen wollte, ging zu Sun, das war gar keine Frage." Aber der Umstieg auf Solaris würde nicht nur die Früchte der Arbeit all jener zunichte machen, die diese einzigartige Organisation ausmachten, sondern den dort herrschenden Geist zerstören. Das bedeutete im Endeffekt, dass McVoy genauso aus dem Unix-Paradies bei Sun vertrieben werden würde, wie Stallman aus dem Hackereden am MIT vertrieben worden war. Wie StaHman ent~ schloss sich McVoy zum Kämpfen: „Das [Sourceware-] Papier war in gewisser Weise ein Versuch, McNealy dazu zu bringen, seine Entscheidung rückgängig zu machen." McVoy begann sein Sourceware-Weißbuch mit einem klugen und anklagenden Bericht über den chaotischen Zustand, in dem sich die Unix-Welt zur damaligen Zeit befand. Es analysierte, warum Microsoft mit seinem damals neuen Windows NT so erfolgreich war, und erklärte auch, warum GNU Linux später von so vielen Unix-Usern begeistert aufgenommen wurde. „Unix braucht unsere Hilfe, denn Unix stirbt. Unix ist längst nicht mehr wettbewerbsfähig." So begann sein Weißbuch. Dann zählte er alle Übel auf, mit denen die Unix-Welt damals behaftet


------------------------------------------------------------------------------------war. Seiner Schätzung nach gaben die Unix-Distributoren gemeinsam eine Milliarde US-Dollar für das aus, was sie Entwicklung nannten. Dazu merkte er an, dass „ein großer Teil dieser Ausgaben redundant ist". Das bedeutete, dass jeder Unix-Distributor seine eigene Lösung für ein und dasselbe Problem entwickelte, was dazu führte, dass ständig doppelt gemoppelt wurde. Microsoft hingegen, so führte er aus, „gibt viel weniger Geld aus und hat ein besseres Produkt. Ihr Produkt ist besser, was Benutzerfreundlichkeit, Installation und Administration anbelangt". McVoy ist davon überzeugt, dass die Unix-Programmierer an dieser Verschwendung genauso schuld waren wie die Chefs der Firmen, in denen sie arbeiteten. „Es ist lächerlich", sagt er, „man bedenke, eine ganze Milliarde Dollar, und alles, was sie taten, war ... dieser riesige Pool von OS-Engineering-Talenten. Diese Typen ermutigten ihre Vorgesetzten ja noch zu dieser Art Doppelgleisigkeit. Es war gar nicht ihr Wunsch, von dem OS-Geschäft wegzukommen. Es gefiel ihnen, dass sie die Könige, die Kernelgenies waren. Sie hatten gar nichts dagegen, dass jeder OS-Distributor seine eigene Unix-Version entwickelte und die Kernelingenieure von Firma zu Firma gehen und die tollen Hechte sein konnten." Das Ergebnis war eine alles lähmende Zersplitterung, Wie McVoy schrieb: „Die großen Unix-Distributoren haben jeweils ihre eigene Unix-Version, was dazu führt, dass mindestens zehn große UnixSysteme um etwa drei Prozent des Computermarkts konkurrieren. Dieser Mangel an direktem Wettbewerb führte zu hohen Kosten für die Endbenutzer. „Die Lizenzen kosten zwischen 20 und 100 Dollar pro Arbeitsplatz, mit einem Verkäuferaufschlag für den kostspieligen ,Mehrwert'. Insgesamt läuft es für den Kunden auf Arbeitsplatzkosten zwischen 600 und 3000 Dollar hinaus. Microsoft dagegen verkauft Windows NT für rund 150 Dollar." Die Gegenleistung, die die Kunden für diese hohen Kosten erhielten, ließ zu wünschen übrig, wie das Sourceware-Papier hervorhob. „Unix stagniert. Unix ist nicht mehr die Plattform der Wahl für Entwicklung und Anwendung innovativer Technologien." McVoy nannte auch einen Grund dafür: „Ein guter Teil der anfänglichen Entwicklung von Unix beruhte darauf, dass Unix für die Forscher problemlos verfügbar war." Das bedeutet, dass Unix


--------------------------------------------------------------------------------------innovativ war, solange es offen war. Nun war es „geschlossen" und dem Tod geweiht. McVoy stellte in seinem Papier fest, dass „die Unix-Probleme nicht in Angriff genommen werden". Die Distributoren glauben, dass ,Standards' die Antwort wären. Leider, so McVoy, meinten die Distributoren in Wirklichkeit etwas anderes, wenn sie von ,Standards' sprachen, „Es war so unglaublich krank", sagt er. „Jeder dieser UnixDistributoren sagte, er wolle eine Vereinheitlichung, aber schon der nächste Satz war: ,O.k., Sie lassen Ihre Version fallen, und wir verwenden meine.' Irgendwie war klar, dass es auf diese Weise kein Weiterkommen gab. Da McVoy vermeiden wollte, dass auf die „Kundenlösung" NT zurückgegriffen wurde, blieb den Programmierern nur eine Wahl: freie Software oder „Sourceware", wie er es nannte. McVoy schrieb: „Immer mehr traditionelle Unix-Entwickler geben die Implementierungen mit dem geschützten Unix auf und konzentrieren sich auf Sourceware." Zu den „Erfolgen ihrer Labors", zählten laut McVoy die GNU-Software (GCC und GNU Emacs), das X-WindowSystem und GNU/Linux, von dem er sagte, dass es „viele Features hat, die man nur in reifen, offenen Systemen findet", und anmerkte, dass es „reich an Features ist, dass ihm aber Qualität und Stabilität eines kommerziellen Produkts fehlen" - eine gerechte Beurteilung des Zustands von Linux im Jahr 1993. McVoy wies darauf hin, dass „fast alle guten Features der heutigen Computerbetriebssysteme, darunter die meisten Features von DOS, Windows und Windows NT irgendeinem Hackerkopf entsprangen. Normalerweise wurde die Arbeit nicht von einer Firma in Auftrag gegeben." Er meinte, es sei katastrophal, dass „die Geschäftswelt die Hacker als ,verrückt' abtut", und meinte vorausblickend, dass es viel besser sei, „nach einer Methode Ausschau zu halten, die der Geschäftswelt und den Hackern die Koexistenz ermöglicht, sodass sie voneinander profitieren können. Wenn die Unternehmen die beste Technologie wollen, sollten sie auf Sourceware übergehen." McVoys Sourceware-Vorschlag zur Lösung der Unix-Probleme, die in Zersplitterung, hohen Kosten und Stagnation lagen, verlangte von der Distributorengemeinde, sich für eine einzige Unix-


------------------------------------------------------------------------------------Version zu entscheiden, deren Quellcode frei verfügbar sein sollte. Im Idealfall würde das sein geliebtes SunOS sein, aber wenn das nicht möglich war, wäre auch GNU/Linux ein „Sieg auf der politischen Front", wenn auch „ein Verlust, was die Reife anbelangt", wie er es ausdrückte. „Ich veröffentlichte es nie, aber es machte irgendwie die Runde", sagt McVoy von seinem Papier. „Und ich bat, es an Leute weiterzugeben, die Einfluss nehmen konnten. Dadurch hoffte ich, Druck auf McNealy und die anderen Führungskräfte zu erzeugen. Ich sprach mit den meisten von ihnen und investierte viel Zeit in diese Gespräche." Die Reaktion war ermutigend: „Alle, die es lasen, waren ganz begeistert", erinnert er sich. „Ich galt als eine Art Unix-Retter." Sogar viele Führungskräfte unterstützten ihn - insgeheim. Letzten Endes half jedoch nichts davon. „Natürlich passierte nichts", sagte McVoy. „Für mich war das alles sehr enttäuschend."' Rückblickend versteht McVoy heute, was vor sich ging. „Die Rolle, die ich bei Sun spielte, war die des Hofnarren, der zu sagen wagte, dass der Kaiser keine Kleider an hatte", erklärt er. „Ich war der Typ, der genügend Idealismus und Leidenschaft aufbrachte, um das zu tun. Damit schadete ich meiner Karriere nachhaltig. Ich meine, das Wort ,Dummkopf war mir auf die Stirn geschrieben." MeVoys Sourceware-Vorschlag war rückblickend gesehen prophetisch. Er legte die Schwächen in der Unix-Distributorengemeinde offen, die zu ihrer zunehmenden Marginalisierung und zum entsprechenden Aufstieg von Windows NT als Unternehmensbetriebssystem führten. Wichtiger aber war, dass der Vorschlag GNU/ Linux und Sourceware - freie Software - als wichtige neue Kraft erkannte, der einzige Lichtblick in einem ansonsten düsteren Szenario. Die Rolle des Cheftheoretikers in der entstehenden Open-Source-Welt wurde schließlich von einem Mann übernommen, der später ebenfalls zu einer Schlüsselfigur werden sollte. Wie McVoy ist Eric Raymond mit einer scharfen, analytischen Verstand und exzellenter verbaler Ausdrucksfahigkeit gesegnet - aber in anderen Bereichen könnten die beiden verschiedener nicht sein. Hatten sich McVoys Aktivitäten als Befürworter der freien Software zufällig ergeben und waren nicht sein Hauptanliegen, so hatte Raymond


--------------------------------------------------------------------------------------diese Rolle bewusst übernommen. Dass er es tat, war angesichts seiner vorhergehenden Laufbahn in der Computerwelt fast unvermeidlich. Raymond wurde wie McVoy in Boston, Massachusetts, geboren, allerdings schon 1957, etliche Jahre früher. Er war das älteste von fünf Kindern. Sein Vater war Anfang der fünfziger Jahre einer der ersten Computerprogrammierer und Manager bei Sperry-Univac, einem der ersten Großrechnerdistributoren. Wie Raymond sagt: „Ich sehe mich als einen Hacker der zweiten Generation." Bedingt durch die Arbeit seines Vaters verbrachte Raymond seine Kindheit nicht in den USA, sondern in Venezuela, Italien und England. Wie er es in seiner typischen blumigen Sprache ausdrückt: „Bevor ich dreizehn war, hatte ich auf drei Kontinenten gelebt und zwei Sprachen vergessen." Die Familie zog zurück in die Vereinigten Staaten, als er dreizehn war. Sie siedelte sich in Pennsylvania an, wo Raymond auch heute noch lebt. Abgesehen von den Resten der vergessenen Sprachen scheinen ihn die Auslandsaufenthalte nicht besonders beeinflusst zu haben. „Das gehörte einfach irgendwie zu meiner Umgebung, und ich hatte keine Meinung dazu", sagt er. Aber es gab etwas anderes, was tiefe Eindrücke hinterließ. „Ich litt unter einer spastischen Lähmung, wenn auch in einer extrem müden Form", erklärt er. „Das führte dazu, dass ich mein linkes Bein nicht voll unter Kontrolle hatte. Die Krankheit ist im Wesentlichen statisch. Sie wird nicht besser, aber sie wird auch nicht schlechter. Was sich verändert, ist meine Fähigkeit, mich anzupassen." Raymond beschrieb sich selbst später als „ängstliches, zorniges, frustriertes Kind". Er erklärt: „Die anderen machten mir das Leben schwer. Es gibt bestimmte Dinge, die ziemlich schwer zu verdauen sind, wenn man in seiner physischen Koordination gestört ist. Deshalb verließ ich mich mit der Zeit lieber auf meine geistigen Ressourcen. Er beschreibt, wie er sich auf Computer verlegte: „Ich begann mich am College daneben für Computer zu interessieren, und außerdem hatte ich von der Mathematik irgendwie genug". Mathematik war sein ursprüngliches Hauptfach gewesen. „Nun, die Computer standen da." Raymond war lupenreiner Autodidakt. „Bücher gab es damals nicht", erklärt er. „Das war nur ein paar


------------------------------------------------------------------------------------Jahre zur Verfügung, nachdem an der Universität das Studium der Computerwissenschaften eingerichtet worden war. Der Großteil des Lernapparats, wie wir ihn heute kennen, war damals noch unbekannt. Die damaligen Programmierer waren im Grunde wie ich; sie kamen von anderen Bereichen herein und brachten sich alles selbst bei." Ein weiterer Autodidakt, der ursprünglich Mathematiker war, war Richard Stallman. Raymond sagt, er habe Stallman nicht nur sieben Jahre, bevor er mit dem GNU-Projekt begann, gekannt, sondern noch bevor er sich seine typische Mähne und seinen Bart zulegte. Wie er erklärt: „Ich stehe gelegentlich neben ihm und sage, ja, ich kannte Richard, noch bevor er langes Haar hatte und aussah wie Jesus. Ich muss Richard allerdings zugute halten, dass er lacht, wenn ich das sage." Über Stallman lernte Raymond die Kultur des MIT kennen, die er so beschreibt: „Sie baute auf PDP-10, Assemblersprache und LISP auf." Er kannte die Kultur von Unix und C bereits, was bedeutete, dass „ich beide Seiten dieser [Hacker] Szene seit ziemlich langer Zeit kannte", sagt er. Schon in den frühen Achtzigern war Raymond also ein privilegierter Beobachter vielfaltiger Codierungsaktivitäten. Er betont gern, dass ein Großteil dieser Aktivitäten unbeachtet voneinander stattfanden oder dass ihre Urheber ihre Erfahrungen nur von Zeit zu Zeit untereinander austauschten. Es gab noch keine einheitliche Hackerkultur. „Diese Zeit war ganz anders als die Open-Souree-Kultur, wie wir sie heute kennen", sagt er, „weil die technologische Infrastruktur, die man braucht, um Software weiterzugeben, wie wir es heute tun, einfach noch nicht da war. Die einzige Möglichkeit, die man damals hatte, um Software weiterzugeben, waren Magnetbänder. Deshalb tat man es nur sehr sporadisch. Die Kulturen, die es doch taten, waren sehr klein und vollkommen isoliert voneinander." „Es gibt eine bestimmte Schule der geschichtlichen Interpretation, die die freie Software von heute als Rückkehr in ein goldenes Zeitalter ohne Beutejäger preist Aber dieses goldene Zeitalter hat es nie gegeben", insistiert Raymond. „Ich war dabei, und ich muss es wissen. Von 1977 bis Anfang der neunziger Jahre existierte die


--------------------------------------------------------------------------------------Kultur der freien Software oder die Open-Source-Kultur, wie wir sie heute nennen, nur in dem Sinn, dass es ein paar Leute gab, die Dinge taten, die sich nicht fundamental von dem unterschieden, was wir heute tun." „Aber die Leute halten kein Gruppenbewusstein", erklärt er. „Die kulturelle Identität fehlte. Es gab niemanden, der sich gedacht hätte: ,Lasst uns diese Dinge tun, denn es gibt bestimmte Gründe dafür.' Es waren nur ein paar Leute, die Lösungen für Probleme entwickelten und Fehler behoben, die einander zufällig kannten und Informationen untereinander weitergaben. Einer von Richards Beiträgen war, dass er dafür sorgte, dass diese Kultur sich ihrer selbst besser bewusst wurde." Einer von Raymonds Kernbeiträgen sollte darin bestehen, dass er dieses Bewusstsein stärkte und dazu beitrug, die Gemeinde, die es verkörperte, zu mobilisieren. Er begann, an einer neuen Ausgabe des Jargon File zu arbeiten, einer wichtigen Sammlung von Hackerwissen, die als Wörterbuch von Ausdrücken und Gebrauchsweisen konzipiert war. Sie wurde erstmals 1975 zusammengestellt und dümpelte in den achtziger Jahren vor sich hin. Der Grund lag zum Teil zweifellos darin, dass die Hackergemeinschaft des MIT, eine der wichtigsten Eintragsquellen für Jargon File, zerschlagen worden war. „Ich stolperte 1990 über eine Ausgabe des Jargon File", erinnert sich Raymond, „und dachte min wow - das ist (a) zwar ein wenig veraltet, aber es gibt Vieles in der neuen Kultur, was hier eingetragen sein sollte, und (b) ich bin erfahren genug, um jetzt aktiv zu werden. Davor halte ich einfach nie daran gedacht, dieses Dokument zu verändern ... ich verbrachte ein Wochenende mit dem Hinzufügen von Einträgen, und ich stellte fest, dass das ganz schön interessant war. Der Jargon File war es wert, abgestaubt und aktualisiert zu werden. Und als ich den Typen, der damals verantwortlich dafür war, fragte, [sagte er]: ,Tja, weißt du, es gibt eine gewisse Nachfrage nach der zweiten Auflage des Wörterbuchs. Warum machst du sie nicht?"" Die zweite Auflage kam 1991 unter dem Titel The New Hacker's Dictionary heraus. Raymond hatte wichtige Motive für die Inangriffnahme dieses umfangreichen Projekts.


------------------------------------------------------------------------------------Ich erkannte, dass ein Buch wie dieses eine Reihe interessanter Dinge vollbringen konnte. Eines meiner wichtigsten Motive war, dass ich wie Richard - aber unabhängig von ihm - der Meinung war, es wäre wichtig, das Selbstbewusstsän der Leute zu heben, die Beiträge zu dem Wörterbuch leisteten, ihr kulturelles Bewusstein, wenn man so will.Ich hatte zum Teil andere Motive als Richard, Er war damals bereits zu seinem moralischen Kreuzzug zur Abschaffung der urheberrechtlich geschützten Software aufgebrochen; fünf Jahre lang engagierte er sich nun schon dafür. Ich machte mir Sorgen, dass das öffentliche Image der Hackerkultur - die sich damals noch im. Embryonalstadium befand Schaden nehmen könnte. Ich befürchtete, dass wir politische Bedingungen schaffen könnten, unter denen das Internet und andere neue Kommunikationsmedien von politischer Seite aus ernsthaften Beschränkungen unterworfen werden könnten. Ich wollte, dass sich Hunderttausende Leute der Mainstreamkultur mit meinen Leuten identifizierten, sodass wir Verbündete haben würden, wenn die Politik unangenehm zu werden begann. Außerdem war ich schon damals der Meinung, dass das Internet viel schneller wachsen würde, als es das in der Mitte oder Ende der siebziger Jahre getan hatte, als ich mich das erste Mal damit zu befassen begann. Und ich machte mir Sorgen, dass das Wachstum des Internets uns in unserer Fähigkeit überfordern könnte, neue Leute in unsere Kultur aufzunehmen. Und genau das wollte ich erleichtern. Jemand, der auf diese Weise zumindest zum Teil „akklimatisiert" war, war Linus. „Als wir uns 1996 das erste Mal trafen", erinnert sich Raymond, wollte er ein Autogramm von mir. Schließlich war das New Hacker's Dictionary, wie Raymond es ausdrückt, „eine Möglichkeit für mich, meinen Wurzeln Tribut zu zollen". Schon Ende der achtziger Jahre hegann er die globale Hackergemeinde nicht nur als eigenständigen, genau abgegrenzten Stamm zu betrachten, der sich durch eine bestimmte Kultur und bestimmte Überzeugungen auszeichnete (beides Dinge, die das New Hacker's Dictionary einerseits festhalten und andererseits fördern


--------------------------------------------------------------------------------------wollte), sondern als etwas noch Spezifischeres - als seinen eigenen Stamm: einen Stamm, der die Leute nach ihren Leistungen im Hacken beurteilte, und für den banale Fragen, wie wer man war oder ob man unter zerebraler Lähmung litt, irrelevant waren. Abgesehen von diesen neuen Motiven war das New Hacker's Dictionary auch in der Art seiner Zusammenstellung außergewöhnlich. „Ich ging an das Ganze bewusst als einen großen kooperativen Prozess heran", erklärt Raymond, „ich war darin zwar die zentrale Schaltstelle, wollte aber nicht jenes Maß an Kontrolle über den Prozess ausüben wie dies ein konventioneller Herausgeber tut." Das New Hacker's Dictionary wurde - wie passend - von der MIT Press herausgebracht und entwickelte sich zu einer Art Bestseller. Dadurch konnte Raymond eines seiner wesentlichen Ziele erreichen - die Kunde von seinem Stamm und dessen Wissen zu verbreiten. Das dadurch entstehende Interesse half Raymond auch, seine Fähigkeiten im Umgang mit den Medien zu entwickeln, eine extrem seltene Eigenschaft unter Hackern, und verlieh ihm „etwas spontane Glaubwürdigkeit bei den Journalisten", wie er es ausdrückte. Diese Glaubwürdigkeit würde ihm später sehr zugute kommen. Das New Hacker's Dictionary hätte fast eine weitere dramatische Konsequenz gehabt, wie Raymond erzählt. „1991 arbeitete ich an der ersten Auflage von The New Hacker's Dictionary. Dabei schickte mir ein Typ namens Ray Gardner einen interessanten Brocken Code. Es war das, was wir heute als einen Hypertext-Viewer für Jargon File betrachten würden." Das heißt, dass man mithilfe von im Text enthaltenen Links wie mit einem Webbrowser zu anderen Einträgen springen konnte. „Ray hatte das Ding für MS-DOS geschrieben", fährt Raymond fort „Er schickte mir den ersten Build, und ich fand, dass es eine coole Idee war. Ich schrieb es von Grund auf neu, verallgemeinerte es und portierte es für Unix, und dann machte ich es zu einem kleinen Hypertext Reader, den ich VH oder VolksHypertext nannte." Den etwas eigenartig anmutenden Namen erklärt er so: „Zum damaligen Zeitpunkt kannte ich das Xanadu-Projekt, diesen riesigen Cadillac eines Hypertext-Systems." Raymond war 1980


------------------------------------------------------------------------------------eingeladen worden, am Xanadu-Projekt mitzuarbeiten. „VH war ein ganz einfaches, ahgeschlanktes, leichtgewichtiges Hypertextsystem, das ich im Vergleich zum Cadillac von Xanadu als eine Art Volkswagen betrachtete. Kein Chrom, keine Heckflossen, aber es erfüllte seine Funktion. Deshalb nannte ich es VolksHypertext." Xanadu war nicht das einzige Hypertextsystem, das in dieser Zeit entwickelt wurde. „Es war Ende '91, glaube ich, als ich eine Mail von Tim Berners-Lee bekam - von dem damals noch niemand gehört hatte -, in dem stand: ich höre, dass Sie interessante Dinge mit Hypertext tun. Vielleicht sollten wir zusammenarbeiten?' Und so schickte ich ihm eine Antwort, in der etwa stand, sicher, Standards sind etwas Gutes. Und dann hörte ich nichts mehr von ihm. Ich weiß noch immer nicht warum." Zum Glück ist Raymond noch für viele andere Dinge berühmt als nur dafür, dass er fast das World Wide Web mit erfunden hätte. Seine vielleicht wichtigste Leistung, der Essay The Cathedral and the Bazaar, in dem er den Erfolg von Linux und der Open-Source-Software analysierte, gründet sich zum Teil auf eine CD-ROM, die Ende 1993 zu ihm gelangte. Die CD-ROM stammte vom GNU/ Linux-Distributor Yggdrasil, und Raymond erinnert sich, dass es „die erste verfügbare Linux-Distribution auf CD-ROM war. Sie wurde mir zugesandt, weil ich bereits so viel freie Software geschrieben hatte, dass einiges von dem Zeug, das ich geschrieben hatte, auf dieser CD zu finden war." Wie bereits erwähnt, war das das „Zeichen der Anerkennung", das Yggdrasil den „vielen Entwicklern freier Software", die zu dieser Distribution beigetragen hatten - oft wie in Raymonds Fall unfreiwillig - gesendet hatte. Er gibt zu, dass er Linux skeptisch gegenüber gestanden hatte, bis er es ausprobierte. Und vielleicht hätte er es nie ausprobiert, hätte er dazu sein bestehendes System löschen müssen, wie es bei jeder anderen GNU/Linux-Distribution außer bei Yggdrasil notwendig gewesen wäre. Aber „Yggdrasil hatte ein interessantes Feature", erklärt Raymond. „Man konnte Linux als Demo laufen lassen, ohne irgendwelche Partitionen auf der Festplatte zu ändern" - in anderen Worten, ohne dass man irgendetwas löschen oder installieren musste. „Damit beschäftigte ich mich paar Stunden lang, und ich staunte über das, was ich sah. Ich gab meine Pläne für den Rest des


--------------------------------------------------------------------------------------Tages auf, löschte das kommerzielle [AT&T-] System V, das ich verwendet hatte, von meiner Festplatte und installierte Linux." Raymond war, wie er sagte, mehr als verwundert: „Ich war total von den Socken, könnte man sagen. Weil es meiner Meinung über die Qualität eines solchen Projekts völlig widersprach. Ich war immer noch Anhänger der klassischen brooksschen Idee, dass man mit einem Mob keine hochwertige Software herstellen konnte", wieder eine Bezugnahme auf Brooks' Arbeit Mythical Man-Month. Raymond machte sich daran, dieses interessante Phänomen zu studieren, um es zu verstehen. „In meinem Bestreben, die Leute der Kultur besser kennen zu lernen, erlebte ich 1996 einen Wendepunkt. Damals saß ich in dem Ausschuss, der das Programm für die erste Freely Redistributable Software Conference zusammenstellen sollte." Diese Konferenz wurde vom 3. bis 6. Februar in Boston abgehalten. Sie war von Peter Salus unter der Leitung der Free Software Foundation organisiert worden. „Ich war mir ziemlich sicher, dass [Linux] meine persönliche Heimstätte war", sagt Raymond, „und der angemessene Standort der Hackerkultur in einer sich verändernden Welt. Die Konferenz verstärkte eindeutig mein Gefühl, dass es dort draußen eine Menge Leute mit viel Energie gab, die begannen, daran zu arbeiten." Die Konferenz hatte noch eine weitere und unerwartete Auswirkung auf Raymond: Er lernte dort Linus persönlich kennen. „Zum Zeitpunkt dieser Konferenz wurde mir das erste Mal bewusst, dass die Führungsrolle in der Kultur von RMS und dem alten Team vom AI Lab des MIT nun auf die Linux-Leute überging", sagt er. Es wurde klar, dass eine neue Hackergeneration das Steuer übernommen hatte. Es war etwas Subtiles, erinnert sich Raymond, das „in allem offenkundig wurde, über das die Leute sprachen, und in den Leuten, an denen sie sich orientierten". Fs war auch in dem wahrnehmbar, was der Höhepunkt der Konferenz und die Krönung von Stallmans GNU-Projekt hätte sein sollen. „Eines der eintägigen Tutorials bestand in der ersten öffentlichen Präsentation des Hurd Designs, das natürlich nichts anderes war als der Versuch der Free Software Foundation, einen freien Kernel herauszubringen", erinnert sich Raymond, In den zwölf


------------------------------------------------------------------------------------Jahren, nachdem Stallman das GNU-Projekt initiiert hatte, hatte sich der Hurd-Kernel eine Art mythischen Status erworben, der dazu führte, dass sein Erscheinen noch eifriger erwartet wurde, als es sonst der Fall gewesen wäre. Damit wuchs aber auch die Gefahr, dass seine Präsentation dann umso enttäuschender wurde. Raymond beschreibt den Augenblick so: „Ich weiß noch, dass Keith Bostic - der ja auch einer der wichtigsten BSD-Leute war -fragte, was ich von der Präsentation hielt. Und ich erinnere mich, zu ihm gesagt zu haben: ,Es ist elegant, es ist schön. Es ist aufwendig' und es wird sich durch seine Leistung gleich selbst umbringen." Keith nickte düster. Der Grund für seine Bedrücktheit war laut Raymond, dass er „wie alle von uns wollte, dass es ein Erfolg werden sollte. Aber Keith und ich und andere Leute dort sahen uns an und meinten: ,Es ist wunderschon, aber es wird nie abheben. Es ist einfach zu kompliziert." Dieser Augenblick der Erkenntnis, so subtil und flüchtig er auch war, markierte doch das Ende einer Hackerära. Und den Beginn der nächsten. „Dem Stamm als Ganzem war noch nicht klar, dass sich der Linux-Kernel durchsetzen würde", sagt Raymond, „aber ich glaube, ich wusste es bereits." Raymond war durch die Erfahrung auf der Konferenz nicht mehr der, der er vorher gewesen war. Heute sagt er, dass diese Konferenz wohl der endgültige Anstoß war, seine Theorie über Linux und seine Entwicklungsmethode in dem Buch niederzuschreiben, das den Titel The Cathedra! and the Bazaar tragen sollte. Bevor er das tat entschloss sich Raymond zu etwas Außergewöhnlichem: die Theorie zuerst zu überprüfen. „Ich habe die geistige Einstellung eines Wissenschaftlers", sagt er. „Wenn man Wissenschaftler ist und sich eine Theorie zurechtlegt, überprüft man sie durch Experimente. Das ist ganz normal." Sein Test verlangte Software, an der er einen Linuxartigen Entwicklungsansatz anzuwenden versuchen konnte. Raymond wollte herausfinden, ob die Anwendung der Methode selbst ausreichend sein würde, um rund um die Software eine Gemeinde zu schaffen, die an ihrer ständigen Verbesserung arbeiten würde. „Ich war ganz bewusst auf der Suche nach etwas Geeignetem", sagt er. Da bot sich eine Software namens Popclient an. Raymond


--------------------------------------------------------------------------------------startete das Projekt im Juni 1996; im Oktober brachte er die erste Betaversion eines Programms heraus, das er Fetchmail nannte. Wie der Name schon sagt, besteht die wichtigste Aufgabe von Fetchmail darin, Mails von Mailservern zu holen - im Gegensatz zu Allmans bekannterem Programm Sendmail, das sie weiterleitet. Durch seine Erfahrung mit Fetchmail stellte Raymond seine Vorstellungen darüber, wie man „Qualitätssoftware mit einem Mob machen konnte, erstmals in Zweifel und begann zu differenzieren. Das Ergebnis war sein Essay The Cathedral and the Bazaar, den er Ende 1996 geschrieben und Anfang 1997 vollendet hatte. Der Essay ist nicht nur online frei verfügbar, sondern wurde von O'Reilly & Associates gemeinsam mit anderen Essays von Raymond auch in Buchform veröffentlicht. The Cathedral and the Bazaar beginnt mit einer Provokation der Softwarewelt: „Linux ist subversiv." Raymond erklärt in der Folge die grundlegenden Metaphern seines Essays: „Ich war der Meinung, dass die wichtigste Software (Betriebssysteme und wirklich große Tools wie Emacs) wie Kathedralen erbaut werden müssten, sorgfaltig konstruiert von einzelnen Magiern oder kleinen Gruppen von Zauberern, die in vollkommener Abgeschiedenheit arbeiteten, ohne dass vor der Zeit eine Betaversion herauskam." Raymond schreibt weiter: „Linus Torvalds' Entwicklungsstil -frühzeitig und oft Versionen herausbringen, delegieren, was man kann, offen sein bis zur Promiskuität - kam vollkommen überraschend ... die LinuxGemeinde schien einem brodelnden Basar verschiedener Vorhaben und Ansätze zu gleichen ... aus denen sich anscheinend nur durch eine Reihe von Wundern ein kohärentes und stabiles System entwickeln konnte." Der Rest des Essays besteht aus einer Reihe kommentierter Aphorismen über den Open-Source-Prozess. Die Form ist typisch für Raymonds literarischen Stil: Der Aphorismus - ein kurzes, markiges Statement - ist der perfekte Schaukasten für seine schriftstellerische Begabung. Ais selbst ernannter Vorkämpfer der Freien Software setzt Raymond Mark Bolzerns Pionierarbeit als Defacto-Marketingdirektor für GNU/Linux fort, und auch er bekommt keinen anderen Lohn als die Hochachtung seiner Kollegen.


------------------------------------------------------------------------------------Raymonds erster Aphorismus lautet: „Jede gute Softwarearheit wurzelt darin, dass sich ein Entwickler an einer Stelle kratzt, die ihn juckt." „Sich zu kratzen, wo es einen juckt" ist eine interessante Beschreibung für die Anfänge eines Stücks freier Software. Allerdings sieht sie darüber hinweg, dass es auch andere komplexe Gründe gibt, warum Spitzenhacker wie Linus mit dem Codieren beginnen, wie die Entstehungsgeschichte von Linux zeigt. Sein zweiter Aphorismus „Gute Programmierer wissen, was sie schreiben müssen. Großartige wissen, was sie neu schreiben (und wieder verwenden) müssen" ähnelt einem Satz, der Pablo Picasso zugeschrieben wird: „Gute Künstler borgen, großartige Künstler stehlen." Raymond sagt, dass „die Parallele bewusst gewählt war". Der entscheidende Punkt ist natürlich, dass traditionelle, geschlossene Black-Box-Software ein solches Neuschreiben und Wiederverwenden nicht zulässt und deshalb nicht von den Vorteilen einer solchen Vorgehensweise profitieren kann. „Nimm dir vor, eines wegzuwerfen; du wirst es ohnehin tun", ist ein direktes Zitat, in diesem Fall von Fred Brooks. Brooks ist nicht nur in Raymonds Essay die graue Eminenz, sondern in der gesamten Bewegung der freien Software. Obwohl Brooks vor Jahrzehnten über die Entstehung von Großrechnersoftware schrieb, enthalten die Essays, in denen er vor den Fallen groß angelegter Entwicklungsprojekte warnte, indirekt auch Hinweise, wie sie sich umgehen lassen: Man muss die Dinge einfach radikal anders anpacken. In dem Essay The Cathedra! and the Bazaar geht es in erster Linie um das Verständnis, wie sich dieser Unterschied praktisch umsetzen lässt Die nächsten drei Aphorismen, die das Kernstück von Raymonds Aufsatz bilden, lauten: „Der problemloseste Weg zu einer schnellen Verbesserung des Codes und zur effektiven Bereinigung besteht darin, deine Benutzer als Mitentwickler zu behandeln", schreibt er, „Bring frühzeitig die erste Version heraus. Bring viele Versionen heraus. Und höre auf deine Kunden." Und: „Mit einer ausreichend großen Betatestund Mitentwicklerbasis kann fast jedes Problem schnell festgemacht werden, und irgendjemand wird den logischen Fix finden."


--------------------------------------------------------------------------------------Raymond formuliert dieses letzte seiner drei Statements plakativer um: „Wenn genügend Augen hinschauen, schwimmen alle Bugs im flachen Wasser", und nennt es Linus' Gesetz. In vielerlei Hinsicht kann diese Aussage als Lösung für das scheinbare Rätsel gelten, das als Brooks' Gesetz bekannt ist: „Einem verspäteten Softwareprojekt mehr Leute zuzuteilen, sorgt für zusätzliche Verspätung." Linus' Gesetz besagt gemeinsam mit den beiden vorhergehenden Aphorismen, dass die Stärke von Open Source in seiner Fähigkeit liegt, sich eine riesige Benutzergemeindc zunutze zu machen, insbesondere über Internet. Raymond nennt Linus' Gesetz zu Recht den „Kernunterschied" zwischen dem Modus des Kathedralenerbauers und dem des Bazars. Er schreibt: „Wenn man vom Standpunkt des Kathedralenerbauers ausgeht, sind Bugs und Entwicklungsprobleme für den Programmierer schwierige, heimtückische und tiefgehende Phänomene. Es braucht Monate sorgfältigster Arbeit, bis die paar Unentwegten sicher sein können, dass alle Bugs draußen sind. Daher die langen Intervalle zwischen den Versionen und die unausweichliche Enttäuschung» wenn lange erwartete Versionen nicht perfekt sind." „Wenn man jedoch vom Bazarstandpunkt ausgeht", fährt er fort, „betrachtet man Bugs im Allgemeinen als flache Phänomene - oder man meint jedenfalls, dass sie bald ziemlich flach werden, wenn sie den Augen von tausend Mitentwicklern ausgesetzt sind, die sich eifrig auf jede neue Version stürzen. Das heißt, dass man nur deshalb so oft neue Versionen herausbringt, um mehr Korrekturen zu bekommen. Außerdem gibt es noch einen nützlichen Nebeneffekt - es ist kein so großes Unglück, wenn von Zeit zu Zeit ein Blindgänger hinausgeht." Anders ausgedrückt, schließt Linus' Gesetz die beiden anderen Aphorismen mit ein, und gemeinsam repräsentieren sie den OpenSource-Prozess in seiner Quintessenz. Raymond sagt etwas Interessantes über die Formulierung dieses Schlüsselabschnitts. Linus, so erklärt er, „sah sich die Entwürfe an und tat zwei wichtige Dinge: Eines war, dass er sagte, er dächte, dass ich es im Allgemeinen richtig gemacht hätte. Und das zweite war, dass er meine Version von Linus' Gesetz entscheidend veränderte. Meine ursprüngliche Version des Gesetzes hatte gelautet: ,Wenn genügend Augen hinschauen, schwimmen alle Bugs im


------------------------------------------------------------------------------------flachen Wasser', und er änderte sie um auf: ,Wenn genügend Augen hinschauen, können alle Bugs charakterisiert werden', und das ist ein bisschen anders. Zum Glück ist das Charakterisieren das Schwierige. Sobald ein Bug charakterisiert ist, ist er im Allgemeinen leicht zu beheben." Raymond hat auch eine interessante Meinung zu der Frage, inwieweit er mit The Cathedral and the Bazaar etwas neu formulierte, was Linus bereits wusste: „Mein Eindruck zum damaligen Zeitpunkt war, dass ihm diese Schlussfolgerungen latent bewusst waren, dass ich ihm aber half, dieses Wissen in seinem Denken in klare Formen zu bringen. Ich glaube also, dass ihm, nachdem er meinen Entwurf gelesen hatte, im Wesentlichen etwas bewusst wurde, was er ohnehin irgendwo gewusst hatte." Auf viele andere Hacker hatte der Essay ähnliche Auswirkungen. Als er zum Beispiel der Philadelphia Linux User Group Anfang 1997 das erste Mal vorgelesen wurde, sagt Raymond, dass das für viele war, „als hätte man ein brennendes Streichholz in ein Pulverfass geworfen. Diese Erfahrung wiederholte sich 1997 ständig. Die Leute hörten oder lasen den Essay, und ihre ganze Sicht der kulturellen Welt, die sie geerbt hatten, änderte sich von einem Augenblick auf den anderen." Eines seiner Ziele beim Verfassen von The New Hackers Dictionary war es gewesen, den Mitgliedern seines Stammes ein besseres Bewusstsein für das zu vermitteln, was sie taten. „Immer wieder beobachtete ich, was passierte, wenn die Leute mit diesem Papier konfrontiert wurden", sagt er. „Plötzlich ging ihnen ein Licht auf über das, was sie seit Jahren getan hatten. Und ihr Energiepegel stieg explosionsartig." Obwohl The Cathedral and the Bazaar unmittelbarere Auswirkungen hatte, war es eine Leistung für sich, der Hackergemeinde neue Energie eingehaucht zu haben. Mit einem Streich verlieh Raymond einer ohnehin bereits eindrucksvollen Bewegung neuen Schwung und spielte in der Folge eine wesentliche Rolle in der Vorbereitung ihres weiteren Erfolgs. Raymond präsentiert diese wachsenden Erfolge so, dass die Mainstream-Medien sie verstehen und positiv auf sie reagieren können. „Ich nenne mich gern Linus' Propagandaminister", sagt er.


--------------------------------------------------------------------------------------Ein Nebeneffekt ist, dass viel mehr traditionell denkende Mitglieder der Softwaregemeinde glauben, dass Raymond eher für sich selbst als für den Stamm wirbt. Das ist bei diesen seltensten aller wilden Tiere, der extrovertierten Hackers, ein natürlicher Argwohn. Aber den Kritikern entgeht der wichtigste Punkt: Jene, die gut darin sind, müssen mit den Medien interagieren. Von ihnen einerseits zu verlangen, erfolgreich zu sein, und andererseits, das Licht der Öffentlichkeit zu scheuen, ist einfach ein Widerspruch. Raymond wird seiner Rolle nicht nur deshalb gerecht, weil er in der Lage ist, zitierfähige Sound-Bytes von sich zu geben, sondern auch wegen seiner breiten und außergewöhnlichen Interessen, die ihn zu dem machen, was den Journalisten am besten gefällt: zu einer „farbigen" Figur. Raymond ist Besitzer des schwarzen Gürtels der Kampfsportart Taekwondo und beschreibt sich selbst als „Waffennarren" Es gelang ihm sogar, so unterschiedliche Leute wie Linus und Stallman dazu zu überreden, an seinen Schießveranstaltungen teilzunehmen. Ein Hacker, der sich mit Feuerwaffen befasst, ist wahrscheinlich auffällig genug, aber Raymond verstärkt diesen Eindruck noch, indem er sich einen „Neoheiden" nennt. „Ich bin Hexer dritten Grades" der Wicca-Religion - der höchsten Stufe, wie er sagt. „Wicca ist ein entspannter, naturzentrierter Polytheismus, der großen Wert auf die direkte Erfahrung und wenig Wert auf Dogmatik legt", erklärt er. „Mein Glaube hat nur wenig mit dem zu tun, was man einen traditionellen religiösen Glauben nennen würde." Wie auch immer - er fügt hinzu: „Ich praktiziere ihn nicht besonders intensiv." Aber Raymond ist davon überzeugt, dass „die Techniken und Einstellungen, die ich von Zen und vom Neopaganismus gelernt habe, viel zu meiner Öffentlichkeitswirkung beitragen." Sie passen übrigens auch gut zu den anderen Überzeugungen, die er in seinem Leben hoch hält: freie Software, keine Beschränkung des Waffenbesitzes - oder ein „bewaffnetes und eigenständiges Bürgertum", wie Raymond es am liebsten ausdrückt. Außerdem sind ihm liberale Werte wichtig, die er als die „ursprüngliche Ideologie des Individualismus, der staatlichen Nichteinmischung, des freien Handels und der Herrschaft der Marktkräfte anstelle von Zwang"


------------------------------------------------------------------------------------beschreibt. Genauer beschreibt er sich als Angehöriger einer Gruppe namens „Marktanarchisten", denen es am liebsten wäre, „die Regierung vollkommen abzuschaffen" Es ist nicht schwer zu erkennen, wo diese tief gehende Abneigung gegen zentralisierte Macht - sei es im Bereich der Software, der Religion oder der Politik - ihre Wurzeln hat: „Ich hasste als Kind das Gefühl der Machtlosigkeit", sagt Raymond. „Und es war nicht nur die Lähmung: Selbst wenn ich die nicht gehabt hätte, wäre ich nicht gern Kind gewesen, einfach deshalb, weil ich mich in einem Zustand der Abhängigkeit befand. Manche Leute können damit sehr gut leben; ich konnte es nicht. Ich nehme an, dass ich das in gewissem Sinn verallgemeinert habe; ich will, dass alle das Gefühl haben, eigenständig handeln zu können." Sein neuestes Projekt, den Leuten zu diesem Gefühl zu verhelfen, nennt sich The Art of Unix Programming. „Das ist ein Buch, das zeigt, wie Unix-Gurus denken", sagt er. „Sie können es als Fortsetzung eines Themas betrachten, das mich in meiner Arbeit seit jeher begleitet: Wie man unbewusstes Wissen an die Oberfläche bringt." „Das spezielle Motiv in diesem Fall", sagt er, „ist, dass es Tausende eifriger junger Linux-Programmierer gibt, die diese Fragmente der Unix-Tradition in sich tragen, die aber das Ganze nicht sehen. Ihnen fehlt der synthetische Überblick, die Philosophie, und sie werden einfach besser, wenn sie das haben." Wie das New Hacker's Dicüonary betrachtet Raymond dieses Anliegen als gemeinsames Projekt. In Anbetracht der eher exklusiven Natur von The Art of Unix Programming meint er, dass „die Zahl der Leute, von denen ich annehme, dass sie sich damit befassen, eher beschränkt ist", sagt er. Raymond ist davon überzeugt, dass das Programmieren von Unix eine Kunst ist, denn „wenn man es auf einer ausreichend hohen Ebene macht, bezieht man daraus eine starke ästhetische Befriedigung, wie man sie eben erhält, wenn man ein elegantes Programm schreibt. Wenn einem eine solche Befriedigung aber nicht zuteil wird, findet man nie in die Kultur hinein. So wie es keine Komponisten gibt, die nicht musikalisch sind, gibt es keine Hacker, die aus dem Schreinen von Programmen keine ästhetische


--------------------------------------------------------------------------------------Befriedigung beziehen." Dieses Element der ästhetischen Befriedigung ist vielleicht der Schlüssel zur Erklärung eines der fehlenden Stücke in Raymonds ansonsten vollständiger Erklärung des Open-SourceProzesses. In einem Nachfolgeessay von The Cathedral and the Bazaar mit dem Titel Homesteading the Noosphere erforscht Raymond ein scheinbares Paradoxon, das im Herzen der Open-Source-Software liegt: Wenn es jedermann freisteht, den Code zu modifizieren, wie kommt es dann, dass sich große Projekte wie Linux oder Apache nur selten spalten oder gabeln, wie es die Hacker nennen, was auch mit dem alten, kommerziellen Unix passierte? Er meint, dass die Erklärung in der Wertschätzung der Kollegen liegt, denn sie ist die Triebfeder für die Leute, die in der Welt der freien Software arbeiten. Er zeigt, dass die Dynamik einer solchen „Geschenkökonomie", in der das Prestige nicht an dem gemessen wird, was jemand besitzt, sondern an dem, was jemand verschenkt, die Drohung einer Gabelung abschwächt. Diese Analyse erklärt eingehend, warum so viele Codierer rund um die Welt freiwillig Beiträge zu diesen Projekten leisten, obwohl sie dafür mit keinen unmittelbaren materiellen Belohnungen rechnen können. In einer Hinsicht ist seine Analyse aber unzureichend: Sie erklärt nicht, warum Hacker der Spitzenklasse wie Linus oder Larry Wall mit ihren Projekten begannen und dann so viel Arbeit hineinsteckten. Raymonds Erklärung, dass sie „eine juckende Stelle kratzten", ist auch nicht ausreichend: Die juckenden Stellen hätten sie auch durch viel weniger ambitionierte - und viel weniger eindrucksvolle - Projekte kratzen können als durch das, was später etwa Linux oder Perl werden sollte. Es gibt Präzedenzfalle von Begabten, die riesige Projekte in Angriff nehmen und an ihnen arbeiten, ohne viel Hoffnung auf finanzielle Belohnung oder auch nur auf Anerkennung zu haben. In anderen Bereichen werden diese Leute Künstler genannt, und ein Großteil der Kunstgeschichte ist die Geschichte jener, die Meisterwerke aus der inneren Notwendigkeit heraus schufen, weit hinausgehend über das, was sie in Anbetracht der Bezahlung hätten schaffen müssen.


------------------------------------------------------------------------------------Zwischen den Lebensgeschichten der Spitzenhacker und jenen berühmter Künstler gibt es auffallende Parallelen. So konnte sich zum Beispiel Ludwig van Beethoven dank der großzügigen finanziellen Unterstützung aristokratischer Gönner dem Schaffen von Werken von so großer Originalität widmen, dass sie seinen Zeitgenossen oft unverständlich waren, und gleichzeitig die damals als radikal geltenden Ideale von Freiheit vertreten, an die er glaubte. Ebenso konnte sich Richard Stallman seiner Programmiertätigkeit und seinen Kampagnen widmen, weil er Unterstützung wie zum Beispiel in Form eines Fellowship der McArthur Foundation genoss. Johann Wolfgang Goethe war Staatsminister des deutschen Hofes zu Weimar, und er nahm seine diesbezüglichen Pflichten genauso ernst wie seine Arbeit an Meisterwerken wie Faust, einem riesigen Flickenteppich der Dichtkunst, der ihn jahrelang beschäftigt hielt. Neben diesen umfangreichen Pflichten gelang es Goethe (im Gegensatz zu Beethoven), ein Familienleben zu führen. Das tut auch Linus (im Gegensatz zu Stallman), der einer Vollzeitbeschäftigung bei Transmeta nachgeht und gleichzeitig an seinem Lebenswerk arbeitet, das ständig wächst. Als der kluge Analytiker, der er ist, ist sich Raymond dieses Aspekts sehr wohl bewusst. In seinem Essay Homesteading the Noosphere („Die Noosphäre zur Heimstätte machen") schreibt er: „Durch diese Analyse in Form eines ,Reputationsspiels' wollte ich die reine künstlerische Befriedigung, die man daraus bezieht, schöne Software zu schaffen und sie zum Funktionieren zu bringen, weder abwerten noch ignorieren. Wir alle erleben diese Art von Befriedigung, und wir leben on ihr." Trotzdem neigt er dazu, das Ganze herunterzuspielen und es im „Reputationsmodell" zusammenzufassen. Unterstützung für die Ansicht, dass die künstlerische Befriedigung eine bessere Erklärung ist, zumindest was die Hauptinitiatoren der Bewegung der freien Software anbelangt, kommt von jemandem, den Raymond durch seine Wahl des Titels The Art of Unix Programing für sein nächstes Buch eine Hommage erwies: „Es war ein bewusster Hinweis auf Donald Knuths The Art of Computer Programming", sagt er.


--------------------------------------------------------------------------------------Knuth wurde im Jahr 1938 in Milwaukee, Wisconsin geboren. Im Zuge seiner brillanten Karriere als junger Physiker und Mathematiker am Case Institute of Technology, wo er gleichzeitig mit seinem B. S. in Naturwissenschaften auch einen Master-Titel erwarb, begann er sich für die eben erst entstehende Welt der Computerwissenschaften zu interessieren. Im Jahr 1962 begann er an einem Buch zu schreiben, das sich ursprünglich mit der Entwicklung von Compilern befassen sollte - jener Programme, die Quellcode in Binärcode konvertieren. Das Projekt florierte und wuchs zu dem vielbändigen Werk The Art of Computer Programming an. Der erste Band erschien 1968, der zweite 1969 und der dritte 1973. Obwohl diese drei Bücher bereits über 2.000 Seiten stark sind, plant Knulh mehrere neue Bände. In diesem Riesenwerk geht es nicht um das Programmieren in einer bestimmten Sprache, sondern um den theoretischen Hintergrund aller solcher Programme. Knuth ist der anerkannte Experte für Algorithmen, die für die Durchführung grundlegender Computervorgänge wie Anweisungen, Suchen etc. verantwortlich sind. Er erklärt, warum er in einem Vortrag, den er 1974 hielt, als er den A. M. Turing Award der Association for Computing Machinery erhielt für seine Arbeit das Wort „Kunst" verwendete. Knuths Vortrag wurde später in dem Buch mit dem Titel Literate Programming veröffentlicht. „Wenn ich über das Programmieren von Computern als Kunst spreche", sagte er, „meine ich damit vor allem eine Kunstform im ästhetischen Sinn. Das Hauptziel meiner Arbeit als Lehrer und Autor besteht darin, den Leuten beizubringen, schöne Programme zu schreiben." Später erklärte er: „Meinem Gefühl nach kann die Erfahrung beim Programmieren der des Komponierens oder des Dichtens vergleichbar sein." Knuth ging noch einen Schritt weiter. Das Programmieren war nicht nur eine künstlerische Aktivität, sondern eine Kunstform, die auch von anderen genossen werden konnte. „Wenn wir die Programme anderer lesen, können wir in einigen von ihnen das Wirken echten künstlerischen Genies erkennen." Das setzt voraus, dass der Quellcode verfügbar ist, wie es bei Open-Source-Software der Fall ist. Der daraus resultierende ästhetische Eindruck ist weder unerheblich noch zufällig: „Ich behaupte, dass es möglich ist,


------------------------------------------------------------------------------------großartige, edle, ja wahrhaft überwältigende Programme zu schreiben!“ (Die Hervorhebungen in diesem und den vorhergehenden Absätzen stammen von Knuth.) Knuth fasst seine Ansichten so zusammen: „Das Programmieren von Computern ist eine Kunst, weil es angesammeltes Wissen der Welt zur Verfügung stellt, weil es Fähigkeiten und Erfindungsreichtum verlangt und vor allem, weil es Objekte der Schönheit produziert. Programmierer, die sich unbewusst als Künstler sehen, genießen ihre Arbeit und werden immer versuchen, es noch besser zu machen." Knuths eigenes Streben nach Schönheit beschränkte sich nicht auf das Programmieren. Wie er in einem Vortrag sagte, den er anlässlich der Verleihung eines weiteren Preises, des Kyoto Prize for Advanced Technology des Jahres 1996, hielt: „Ich war vom Anblick dieser Bände [von The Art of Programming] nicht nur deshalb begeistert, weil mir die in ihnen enthaltene Information gefiel, sondern auch wegen ihres schönen Satzes und ihres Layouts." Die Bände sind auch Klassiker der mathematischen Schreibkunst und des subtilen Witzes, der vor allem in den vielen Textzitaten offenkundig wird, die von Knuths breiter literarischer Bildung zeugen. Dem Vorwort zu Band 2 von The Art of Computer Programming, der sich mit „seminumerischen Algorithmen" be-fasst, stellt Knuth ein Zitat aus Shakespeares Hamlet voran: „O liebe Ophelia, es gelingt mir schlecht mit dem Silbenmaße; ich besitze die Kunst nicht, meine Seufzer zu messen ..." Als Satz und Layout späterer Ausgaben aufgrund der minderen Qualität der fotooptischen Satztechnologie, die in den siebziger Jahren eingeführt wurde, schlechter wurden, tat Knuth das, was jeder echte Hacker tun würde: Er setzte sich hin und schrieb ein bisschen Code, um das Problem zu beheben. Das Ergebnis war TEX, „ein neues Satzprogramm für schöne Bücher", wie Knuth es im Vorwort zu seinem Buch The TEXbook -dem von ihm verfassten Handbuch für das Programm - schreibt. Er schrieb es, um den Benutzern die absolute Kontrolle über das Erscheinungsbild der Zeichen zu geben. Mit TEX konnte die Wirkung des alten Bleisatzes wieder hergestellt werden, der für die


--------------------------------------------------------------------------------------ersten Ausgaben dieses Buches verwendet worden war, der in der Zwischenzeit aber so gut wie nicht mehr verwendet wurde. Der Name TEX leitet sich von dem griechischen Wort tecne (tekhne) ab, das „Kunst" bedeutet, aber auch die Wurzel der Wörter „Technologie" und „Technik" ist. Angesehen von seiner eigenen idiosynchratischen Form hat TEX auch eine eigene Aussprache: Das „X" in TEX wird wie „ch" ausgesprochen. Obwohl Knuth TEX für seine eigenen Zwecke geschrieben hatte - „Ich wollte es zuerst nur für mich und für meine Sekretärin", sagt er -, verbreitete es sich bald, als bekannt wurde, wie leistungsstark und nützlich es war. Knuth hatte im März 1978 mit dem Codieren begonnen. Ein paar Jahre später, 1989, schrieb er in einem Artikel mit dem Titel The Errors of TEX: „Im August 1978 hatten andere Leute begonnen, TEX zu verwenden, und es überraschte mich, wie schnell sich das System verbreitete." Wie bei anderen freien Softwareprojekten wurden umso mehr Bugs gefunden, je mehr Benutzer TEX hatten. Schon einige Zeit bevor Eric Raymond die Idee formuliert hatte, hatte Knuth entdeckt, dass „neue Benutzer neue Bugs finden", wie er es später ausdrückte. „Die Software, die ich davor für eine hreite Konsumentengruppe geschrieben hatte, bestand hauptsächlich aus Compilern, und deshalb war die Benutzerfamilie nicht so groß", erklärt Knuth. „So kam es, dass ich die Einsicht über die Benutzer und die Bugs erst viel später gewann, weil TEX eine viel größere, vielfältigere Benutzergruppe hatte." Diese wachsende Gemeinde veranlasste Knuth, mehr Zeit in das Projekt zu investieren als ursprünglich beabsichtigt Dass es diese Benutzer gab, war aber kein reiner Segen: „Es war einerseits ein Anreiz", sagt Knuth, „und andererseits war es schrecklich." Ermutigend, so erinnert er sich, war die große Benutzerzahl „in dem Sinn, dass ich sehen konnte, dass ich hier wirklich etwas Nützliches bewirken konnte". Er freute sich darüber, dass etwas, was als privates Projekt begonnen hatte, nun so allgemein anwendbar war - genau wie Linux es später sein würde. Heute, so schätzt Knuth, gibt es rund eine Million TEX-User, und „es wird für 95 Prozent aller Publikationen in den Bereichen Physik und Mathematik verwendet"


------------------------------------------------------------------------------------Es gab aber auch eine Kehrseite: „Ich wollte nicht, dass TEX mein gesamtes Leben kontrollierte. Schließlich habe ich ja nur ein Leben", erklärt er, „und der Inhalt dieses Lebens stand zu diesem Zeitpunkt bereits fest: Die Kunst des Programmierern. Ich wollte [TEX] in einem Jahr fertig haben." Statt dessen sah es so aus, als würde er Jahrzehnte seines Lebens damit zuzubringen, „die besten Satzsysteme der Welt zu entwickeln". Um einen Kompromiss zwischen diesen widersprüchlichen Anforderungen zu finden, fragte er sich: „Wie kann ich die Arbeit auf ein Minimum beschränken und mich dann wieder The Art of Computer Programming widmen, ohne vollkommen verantwortungslos zu sein?" Er kam zu folgendem Schluss: „Anstatt das zu patchen, was ich habe, lasst mich das tun, was ich von Anfang an hätte tun sollen. Ich werde mein absolut Bestes geben und dann werde ich es abschließen. Es wird gut genug sein, um 98 Prozent der Bedürfnisse der Leute abzudecken, und dann werde ich es auf Eis legen." Nachdem er TEX78 geschrieben hatte, begann Knuth mit einer neuen Version, die er TEX82 nannte. Dabei baute er nicht nur auf dem auf, was er über das Schreiben des Programms selbst gelernt hatte, sondern er konnte auch eine Methode effizienter nutzen, die später als LinuxMethode bekannt werden sollte. Wie er in The Errors of TEX schrieb: „Von Anfang an hatte es Hunderte Benutzer gegeben ... aber nun war eine neue Dimension hinzu gekommen: Mehrere Dutzend Leute lasen auch den Code und gaben Kommentare darüber ab wie man ihn verbessern könnte." Er begann eine klassische Open-Source-Strategie zu verfolgen; Knuth hatte sogar seine eigenen TEX-Leutnants. „Ich traf mich regelmäßig mit Freiwilligen, die die verschiedensten Ansichten vertraten", schrieb er. „Dadurch hatte ich die einzigartige Möglichkeit, diese Ideen aufzugreifen, um einen neuen Grad der Perfektion zu erreichen" -genau das, was Linus später mithilfe seines inneren Beraterkreises tun sollte. Knuths Streben nach Schönheit und Perfektion ist zielstrebiger als die von Linus und anderen Open-Source-Größen. So führt er nicht nur ein Logbuch über alle Bugs, die in TEX gefunden wurden, sondern schrieb auch den oben erwähnten Artikel, in dem die ganze Entwicklung genauer dargestellt wurde. Um die Bereinigung


--------------------------------------------------------------------------------------weiter zu fördern, setzte Knuth den noch nie da gewesenen Schritt: Er bot allen, die Fehler in seinen Büchern oder in seiner Software entdeckten, eine finanzielle Belohnung an. Der Einstellungsunterschied zwischen Knuth und den Anbietern urheberrechtlich geschützter Software ist bemerkenswert: Letztere zahlen den Benutzern nicht nur nichts, wenn diese Bugs in ihren Produkten finden, sondern sie verlangen für das Privileg, diese Bugs zu melden, sogar Geld - denn schließlich besteht die einzige Möglichkeit, das zu tun, oft im Abschluss teurer Supportverträge. Zum Glück für Knuth wurden nur wenige dieser Schecks eingelöst weil ihre Eigentümer sich mehr über die Tatsache freuten, dass sie sie bekamen, als über ihren finanziellen Wert. Der Grund, warum TEX möglicherweise die erste und einzige völlig bereinigte Software ist, die je geschrieben wurde, liegt vielleicht in dieser Liebe zur Perfektion, und darin, dass das Programm inzwischen eingefroren ist. Derzeit arbeitet Knuth an den restlichen Bänden von The Art of Computer Programming. Er bringt sie in 128-Seiten-Einheiten heraus, vielleicht inspiriert durch das Beispiel Charles Dickens', dessen Romane auf ähnliche Weise veröffentlicht wurden. Der Hauptvorteil der Veröffentlichung in Serien besteht darin, dass Knuth „unterwegs" Feedback von seinen Lesern bekommt und der Bereinigungsprozess daher schneller vonstatten geht. Knuths Meisterwerk wäre nicht möglich gewesen, hätte er nicht Zugang zur Arbeit seiner Wissenschaftlerkollegen und zu der Tradition gehabt, der sie angehörten. Dank der schnellen Verfügbarkeit ihrer Ergebnisse konnte er Ideen aus vielen verschiedenen Quellen beziehen. „Man kombiniert einfach zwei Ideen, die man in zwei verschiedenen Journalen findet", sagt er. „Vielleicht kennen die Autoren einander gar nicht. Ich bin dann der Erste, der weiß, dass diese Leute an demselben Projekt arbeiten. Das ist gang und gäbe." Durch diese Art zu kombinieren erzielte Knuth oft interessante Ergebnisse, und zwar viel schneller und effizienter, als wenn er auch die Vorbereitungsarbeiten hätte leisten müssen. In diesem Sinn ist The Art of Computer Programming ein großartiges Monument der Offenheit und des Weitergebens, die nicht nur die


------------------------------------------------------------------------------------Quintessenz der Open-Source-Software sind, sondern der gesamten wissenschaftlichen Tradition. Knuth, der sich der Größe der Aufgabe, die immer noch vor ihm liegt, bewusst ist, verwendet seit 1990 kein E-Mail. Mit dieser extremen Entscheidung, sich von der Außenwelt zu isolieren, um während des Kreativprozesses Ablenkungen zu vermeiden, steht er allein auf weiter Flur. In den frühen Jahren des zwanzigsten Jahrhunderts war Marcel Proust ähnlich intensiv in ein Werk vertieft, das sein Leben dominieren sollte: in seinen dicken, autobiographischer Roman Auf der Suche nach der verlorenen Zeit. Um sich besser konzentrieren zu können, ließ Proust das Zimmer in Paris, in dem er arbeitete, mit Kork auskleiden, um die Geräusche der Außenwelt auszuschalten. Es gibt wohl keinen besseren Vergleich für Knuths Entscheidung, offline zu bleiben. Die Ähnlichkeit zwischen Proust und Knuth geht aber noch tiefer. Auf der ersten Seite von The Art of Computer Programming steht: „Diese Bücherreihe ist dem Computer des Typs 650 gewidmet, der einst im Gase Institute of Technology stand - in freundlicher Erinnerung an viele vergnügliche Abende." Das ist, wie Knuth sagt, ein bewusster Hinweis auf den Titel der englischen Standardübersetzung von Prousts Meisterwerk Remembrance of Things Fast. Es scheint nur natürlich, dass jemand, der am Anfang seiner Karriere mit dem damals neuen IBM-650-Computersystem arbeitete, nun ein ehrenwürdiges und verehrtes Mitglied der heutigen Computeravantgarde ist der Open-Source-Bewegung. In Anbetracht seiner persönlichen Tradition der Offenheit und des Verteilens von Software überrascht es kaum, dass er ein so eifriger Verfechter der freien Verfügbarkeit des Quellcodes ist: „Ich bin mehr als ein Befürworter davon; ich bin fest davon überzeugt, dass das für den Fortschritt unerlässlich ist", sagt er. Knuth verwendet für seine eigene Computerarbeit GNU/Linux, und eines der Programme, die er am häufigsten verwendet, ist Emacs: „Das ist meine Lieblings-Open-Source-Software", sagt er. Knuth hat Stallman sogar Vorschläge für Emacs geschickt. „Er hat sie noch nicht integriert", sagt er, räumt aber ein, dass „ich sie nicht per E-Mail geschickt habe", weil er nie E-Mail verwendet. Das


--------------------------------------------------------------------------------------spielte möglicherweise eine Rolle. Trotzdem ist Stailman so etwas wie sein persönlicher Held. „Er steht in dem Kreuzzug auf der richtigen Seite", sagt Knuth. Knuth, der nicht nur ein angesehener Wissenschaftler und produktiver Autor wichtiger Bücher und Arbeiten auf seinem Gebiet ist, kann nur als einer der langjährigsten Protohacker beschrieben werden. Aber damit nicht genug, ist er auch noch ambitionierter Musiker. Er überlegte sogar, an der Universität anstelle von Physik Musik zu studieren. Vor einiger Zeit ließ er sich in einem Zimmer seines Hauses, das er eigens für diese Zwecke benützt, eine gute zweimanualige Orgel einbauen. Knuth teilt seine Liebe zur Musik mit vielen Programmiererkollegen im Bereich Freie Software: Larry Wall ist ausgebildeter Musiker, Richard Stallman nimmt auf alle seine Reisen Musik und Instrumente mit, Ted Ts'o und Stephen Tweedie singen in Chören (und Tweedie dirigiert auch), Dave Miller spielt Gitarre, Schlagzeug und Klavier, und Eric Raymond hat sich auf zwei Alben als Querflötist verwirklicht. Der Kunsthistoriker und Theoretiker der viktorianischen Zeit, Walter Pater, schrieb in seinem 1877 erschienenen Essay „The School of Giorgione", dass „jede Kunst letzten Endes dem Zustand der Musik zustrebt" Vielleicht gilt das auch für die Kunst des Codierens. Aber wie eng die Verbindung zwischen Codieren und künstlerischem Schaffen auch sein mag, es wäre ein Fehler, das Hacken als eine Tätigkeit zu betrachten, die im Elfenbeintum durchgeführt wird und die nur für einen inneren Kreis von Eingeweihten von Interesse ist. Knuth selbst schrieb in seinem Essay Computer Programming as an Art: „Die Idealsituation tritt dann ein, wenn die Dinge, die wir als schön betrachten, von anderen Leuten für nützlich befunden werden." Er fügt hinzu: „Ich schreibe besonders gern Programme, die in einem gewissen Sinn das Beste bewirken" - ein klares Echo von Stallmans Bemerkung darüber, wie stolz er anfangs darauf war, dass seine Programme nutzbringend für die Leute waren. Wie der beste Quellcode immer die Existenz eines verwendbaren Binärcodes voraussetzt, scheint unter den Hackern die Meinung vorzuherrschen, dass die beste Software - die schönste, wie Knuth


------------------------------------------------------------------------------------und andere sagen würden - impliziert, dass sie den Benutzern bestmöglich dient. Immer wieder sprechen die Spitzenhacker vom Gefühl der Zusammengehörigkeit, das durch ihre Arbeit entsteht. Dieses Gefühl, etwas zu schaffen und einer Gemeinde zu dienen, ist wahrscheinlich die wichtigste Triebfeder für die großen Hacker. Bei Stallmans GNU-Projekt war die Entstehung einer Gemeinschaft Ziel, nicht nur zufälliges Ergebnis. Der Urheber von Sendmail, Eric Allman, sagt, dass freie Software für ihn „etwas mit der Gesellschaft" zu tun hat, und fügt hinzu: „Ich nehme an, das klingt ein bisschen weit hergeholt, aber für mich ist es so." Brian Behlendorf, der für die Kernmitglieder der Apache Group spricht, drückt es so aus: „Für uns bestand der wichtigste Vorteil der Verwendung von Apache darin, es als Teil der allgemeinen Gemeinde und nicht nur als die Einsen und Nullen zu verwenden, aus denen es besteht." Wie wichtig die Gemeinschaft für Open Source ist, drückt vielleicht Larry Wall am genauesten aus: Er sagt, dass er den Leuten mit Perl dienen möchte und dass er erkannt hat, dass „dazu eine Kultur rund um die Sprache" erforderlich ist. Und Kulturen entstehen durch die Gemeinschaft von Benutzern. „Ich stellte fest, dass mit der Feedbackschleife alles klein anfangt", sagt er, „aber ich erkannte auch, dass es da nicht nur die primäre Feedbackschleife gibt, sondern auch die Interaktionen zwischen den Leuten, und dass das, was die anderen Leute untereinander über Perl austauschen, wahrscheinlich wichtiger ist als das, was sie mit mir besprechen. Der Grund liegt darin, dass die sekundäre Feedbackschleife in die Kategorie ,Viele zu vielen' fällt, während die Kommunikation mit mir von der Art ,Einer zu Vielen' ist." Man könnte sagen, dass Wall Perl schrieb und frei verteilte, um den Mitgliedern der Gemeinschaft, die sich rund um das Programm zu entwickeln begann, eine ähnliche Großzügigkeit in ihren Interaktionen zu ermöglichen dank des Netzwerkeffekts, aber in einem noch größeren Maßstab. „Im Großen und Ganzen glaube ich, dass meine diesbezüglichen Wünsche in Erfüllung gegangen sind", sagt Wall. „Die Leute helfen einander wirklich nur um der Sache willen."


--------------------------------------------------------------------------------------Für Wall, einen praktizierenden Christen, ist diese erhoffte Wirkung nicht geringer als „theologisch" Wall sieht deutliche Parallelen zwischen seiner Entwicklung von Perl, dem künstlerischen Schaffen im Allgemeinen und der Schöpfung an sich. „Die Metapher der messianischen Obertöne ist sicher da", gibt er zu und fügt mit seiner charakteristischen Ambiguität hinzu: „Ich versuche gleichzeitig, sie ernst und nicht ernst zu nehmen." Es ist sicher kein Zufall, dass auch Knuth ebenso wie andere Spitzenhacker - Ted Ts'o ist ein Beispiel - ein zutiefst religiöser Mann ist und dass selbst jene, die sich nicht als religiös bezeichnen, wie Richard Stallman oder Linus, starke ethische Werte vertreten. Das bedeutet, dass die freien Softwareprojekte im Gegensatz zur kommerziellen Software, die im Bestfall materielle Belohnungen zu bieten hat, den Menschen etwas viel Wertvolleres, wenn auch nicht Greifbares, auf der menschlichen Ebene versprechen. Sie verlangen von den Menschen das Beste in vielerlei Hinsicht, nicht nur was die Qualität des Code anbelangt. Nach 1996 begannen selbst die zynischsten und abgestumpftesten Beobachter der Technologieszene, von der neuen Bewegung Notiz zu nehmen. Freie Software, das bestgehütete Geheimnis des Internets, stand vor seinem Eintritt in den Mainstream.

(Leerseite)

10

Dort unten im Tal

ES

SOLLTE LÄNGER ALS DREI JAHRE nach seinem Weggang aus Finnland dauern, bis die Welt entdeckte, was Linus dort unten im Silicon Valley bei Transmeta machte. Das Geheimnis wurde schließlich am 19. Januar 2000 bei einer Produkteinführung gelüftet, die zu den am ungeduldigsten erwarteten und meistkommentierten der jüngeren Computergeschichte zählt. Der Gründer und CEO von Transmeta, Dave Ditzel, kündigte die Crusoe-Prozessorchipfamilie für mobile Computer an. Bei diesem Design, so Ditzel, hatte Transmeta „den Mikroprozessor neu erfunden". Diese Meinung war nicht ganz unberechtigt. In der Erkenntnis, dass die aktuelle Chipgeneration wie die Intel-Pentium-Familie für die leichten, mobilen Geräte, die immer mehr Benutzer wollten, zu kompliziert zu entwickeln und von Fehlern zu bereinigen, zu teuer zu bauen und im Betrieb viel zu heiß waren,


------------------------------------------------------------------------------------bot Ditzel nun ein Chipdesign an, das keines dieser Eigenschaften aufwies. Transmeta hatte die neuesten technologischen Fortschritte genutzt und eine Familie schneller Low-Power-Prozessoren entwickelt, die die Daten in 128-Bit-Einheiten verarbeiteten - verglichen mit den 32 Bit des Intel Pentium. Aber es gab ein Problem: Solche Chips waren nicht für die unzähligen PC-Programme geeignet, die für die IntelProzessorfamilie vom 80386 (dessen Erscheinen Linus schließlich mit der Intel-Palette versöhnte) bis zum Pentium, allgemein als x86Prozessoren bekannt geschrieben worden waren. Die Lösung, die Transmeta für dieses Problem anbot, war innovativ und einfach: die Herstellung der Kompatibilität zu x86 mithilfe von Software. Wenn also ein normales PC-Programm auf einem TransmetaChip lief, würden die für die x86-Chipfamilie geschriebenen Programme mithilfe von spezieller Software in eine Version konvertiert, die für den 128-Bit-Crusoe-Chip entwickelt worden war. Die Chips waren so schnell, behauptete Transmeta, dass der Übersetzungsprozess die Leistung praktisch nicht verlangsamte. Das war also das große Geheimnis von Transmeta: Das Unternehmen wollte sich mit dem mächtigsten Hardwarehersteller des PC-Geschäfts, Intel, anlegen, wie GNU/Linux den stärksten Anbieter von Software für den PC, Microsoft, angegriffen hatte. Die Folge war, dass sich Linus, einer der friedfertigsten Menschen überhaupt, plötzlich im Mittelpunkt nicht nur von einem, sondern von zwei Frontalangriffen auf die Hauptbastion der Computerindustrie des zu Ende gehenden zwanzigsten Jahrhunderts fand: das Duopol Wintel (Windows-Intel). Transmeta verkauft die auf seinen Chips basierenden Computer nicht direkt, sondern verkauft Chips und Software an Originalgerätehersteller, so genannte OEM (Original Equipment Manufacturers). Trotzdem zeigte Transmeta, um seine Behauptungen zu untermauern, bei der Einführung einige mobile Computer, die mit seinen Chips arbeiteten. Einer, ein leichtes Notebook, das mit Microsoft Windows betrieben wurde, basierte auf dem TM5400-Chip. Präsentiert wurde auch ein kleineres, mobiles Internetgerät, das auf einem anderen Mitglied der Crusoe-Familie basierte, der TM3120. Dieses Gerät wurde mit einem System betrieben, das sich Mobile Linux nannte.

10. Dort unten im Tal

--------------------------------------------------------------------------------------Wie Ditzel sagt, ist „der TM3120 voll kompatibel mit allen x86PCApplikationen und -Betriebssystemen, obwohl wir festgestellt haben» dass das größte Konsumenteninteresse den mobilen Internetgeräten gilt, die mit einer Version des Betriebssystems Linux betrieben werden". Diese Erklärung bestätigt, was Linus 1996 gesagt hatte. Er hatte darauf bestanden, dass seine Arbeit bei Transmeta in keinem direkten Zusammenhang mit Linux stand und dass Transmeta in keiner Weise ein Linux-Unternehmen sei. Das Erscheinen von Mobile Linux ist ein eher neues Element der Strategie des Unternehmens, ein Element, das seine Existenz der zunehmenden Präsenz von GNU/Linux in mobilen Geräten und der Nachfrage nach diesen Geräten verdankt. Nach den Hauptpräsentationen stellte sich Linus einer Frage-undAntwort-Stunde mit der Presse. Der blasse und dünne junge Mann aus Finnland war nach seinem Umzug in die Vereinigten Staaten merklich fülliger geworden: Bald erwähnten alle Journalisten, die Interviews mit ihm führten, seinen kleinen Bauchansatz. Linus gab einige Hintergrundinformationen über die Entwicklung der GNU/LinuxDistribution von Transmeta. „Mobile Linux ist im Wesentlichen ein Standard-Linux", sagte er. „Wir wollten die Technologie zeigen, und deshalb entwickelten wir firmenintern eine An kleine Distribution für die OEMs, damit sie etwas Lauffähiges hatten" Zu den Auswirkungen, die seine Arbeit an Mobile Linux auf den Hauptkernel von Linux haben könnte, sagte er: „Mein Interesse galt seit jeher der Entwicklung des Kernels, und das wird sich auch nicht ändern. Ich bin tatsächlich ein überzeugter Anhänger der Mobilität. Ich stelle fest, dass ich meinen Laptop öfter verwende als meinen 8-fach-PentiumXeon" - einen Super-PC, der über nicht weniger als acht Intel-XeonProzessoren verfügt, die selbst Superversionen des Pentium-Chips sind. „Ich bin von dem Achtfach-Pentium begeistert, aber das Booten dauert eine Ewigkeit, und ich kann ihn nicht mit mir herumtragen." Dann führte Linus ein wesentliches Argument ins Treffen. Die Transmeta-Plattform sei auch „ein cooles Vehikel zum Debuggen'', sagte er, weil „man jede Menge interessante Dinge tun kann, wenn man den ganzen Chip unter Kontrolle hat" Da der x86-Prozessor


------------------------------------------------------------------------------------von der neuen Code-Morphing-Software von Transmeta - an deren Entstehung Linus beteiligt gewesen war - entwickelt worden war, konnte er nämlich in den Prozessor hineingehen. Er konnte die Funktionsweise der Intel-Familie untersuchen und sogar daran herumhacken. Das war eine noch nie da gewesene Möglichkeit für Softwaredesigner. Selbst Ditzel hatte diesen Aspekt heruntergespielt und sich darauf beschränkt, eine interessante Anekdote zu erzählen. Sie betraf einen Transmeta-Kunden in Japan, der einen Fix für einen Bug im Prozessor selbst brauchte (Chips sind in gewisser Weise nichts anderes als Silizium gewordene Software, die wie ein Programm bereinigt werden muss). „Normalerweise", erklärte Ditzel, dauert es Wochen, um eine neue CPU [einen Prozessorchip] herzustellen, zu testen und zu liefern." Das Design des Chip würde modifiziert werden müssen, und dann würde man die Umsetzung in Silizium produzieren, testen und per Luftfracht nach Japan senden müssen. „Was Transmeta tat, war innovativ: Wir schickten ihnen eine neue CPU über das Internet Genau genommen schickten wir sie einfach per EMail", erklärte Ditzel. Das war möglich, weil die Bugs im Silizium umgangen werden konnten, indem man die Code-Morphing-Software modifizierte. Updates für die Code-Morphing-Software zu schicken war genauso leicht wie einen Patch für irgendein Softwareelement zu schicken. „Crusoe ist die einzige CPU, für die ein Software-Upgrading über das Internet möglich ist", fuhr er fort. Das war die eigentliche Innovation, die Transmeta zustande gebracht hatte: Dem Unternehmen war es gelungen, den geschlossenen BlackBox-Chip von Intel zu einem hackbaren Stück Technologie zu machen. Nun war es fast gelungen, einen Chip herzustellen, der nach Wunsch geändert werden konnte. Man würde der Code-Morphing-Software nur den Quellcode bekannt geben müssen, und jeder würde den Chip neu programmieren können - wie auch jeder den Linux-Kernel für eine bestimmte Erfordernis neu programmieren konnte. Transmeta stand mit der Erwägung eines solchen Schrittes nicht allein. Eine der Ironien von Linus' Umzug nach Silicon Valley


--------------------------------------------------------------------------------------bestand darin, dass er dort für ein unglaublich geheimniskrämerisches Unternehmen arbeitete, das Produkte mit geschlossenen Sourcen herstellte. Und nun hatte dieses Unternehmen einen radikal neuen Ansatz entwickelt, der den Open-Source-Chip als Möglichkeit in Betracht zog. Linus' Begeisterung für seinen neuen Job war wahrscheinlich einer der Gründe dafür, dass die Entwicklung des Kernels nun langsamer voranschritt. 1996, bevor er zu Transmeta gegangen war, waren bereits über hundert Versionen des Kernels veröffentlicht worden, darunter allein im April nicht weniger als sechzehn. 1997, in dem Jahr, in dem Linus mit seiner Frau Tove und ihrer gemeinsamen Tochter nach Silicon Valley gezogen war, waren es knapp sechzig - immer noch erstaunlich viele, würde es sich nicht um Linux handeln. 1997 hätte also ein relativ ruhiges Jahr für GNU/Linux werden können. Aber unter der Oberfläche tat sich viel, insbesondere was die Bewusstseinsarbeit in der Öffentlichkeit anbelangte. Ein wichtiger Katalysator für diese Veränderungen war das Erscheinen von Eric Raymonds Essay The Cathedral and the Bazaar, den er im Januar 1997 fertig geschrieben hatte. „Eine der ersten Personen, denen ich den Essay zeigte, war Erik Troan", erklärte Raymond. „Er war ein wichtiger Entwickler von Red Hat und ein guter Freund von mir" „Und er sagte: ,Oho, da habt ihr ja etwas wirklich Interessantes. Das solltet ihr bei der nächsten Konferenz präsentieren. Ich weiß zufällig, dass die Leute vom Linux-Kongress nach gutem Material Ausschau halten.' Also schickte ich ihnen den Essay", erklärt Raymond, „und sie sagten: ,Wow, ja, wir wollen nach Bayern kommen und einen Vortrag halten." Der Linux-Kongress war eine der ehrwürdigsten Veranstaltungen im Linux-Kalenderjahn und als Raymond im Mai 1997 dort seinen Vortrag hielt fand er bereits zum vierten Mal statt. Er wurde in Würzburg abgehalten, und zu den Vortragenden zählten Spitzenhacker wie Dave Miller, Ted Ts'o, Stephen Tweedie und der Herausgeber Tim O'Reilly. Als ich Erics Vortrag hörte", erklärt O'Reilly, „sagte ich, das ist ja fantastisch, und ich lud ihn ein, den Keynote-Vortrag bei unserer


------------------------------------------------------------------------------------Perl-Konferenz in diesem Sommer zu halten. Ich war zu dem Schluss gekommen, dass wir unter anderem die Bekanntheit einiger dieser Programme [wie Perl] heben mussten", sagt er. „Aber in meinem Inneren war ich ziemlich irritiert über die Tatsache, dass die Computerindustrie diese unglaublich wichtigen Leute und Programme einfach ignorierte." O'Reilly war durch einen Umsatzanstieg der von ihm veröffentlichten Perl-Titel auf den Höhenflug der freien Software aufmerksam geworden. „Erics Denkart schärfte die meine zu diesem Zeitpunkt sicherlich", sagt O'Reilly. „Wir sprachen viel miteinander, und so kam es, dass ich bei der Organisation der Konferenz einige seiner Ideen verwendete. Im Zentrum dieser ersten Perl-Konferenz standen in vielerlei Hinsicht Erics Ideen." Die Konferenz fand am 20. August 1997 in San Jose, Kalifornien, statt. Larry Wall hielt seinen ersten eigenen Keynote-Vortrag, der den scherzhaften und doch aussagekräftigen Titel „Perl Culture" trug, und Raymond las The Cathedral and the Bazaar. Diesmal war die Reaktion, wie Raymond anmerkt, etwas anders, als es die des Publikums in Deutschland gewesen war. „In den dazwischen liegenden Monaten", erklärt er, „hatte sich der Essay so schnell in der Community verbreitet, dass die Perl-Konferenz zu einer Art Feier geriet, die sie in Bayern noch nicht gewesen war". Aber auch dort war er schon mit „heftiger Begeisterung" aufgenommen worden, wie er sich erinnert. O'Reilly fiel bei der Konferenz etwas auf. „An dieser ersten PeriKonferenz nahmen sechs- oder siebenhundert Leute Teil, und es war das erste Mal, dass viele dieser Leute einander persönlich kennen lernten", obwohl „so viele von ihnen seit Jahren über das Internet zusammengearbeitet hatten. Das war ein sehr, sehr starkes Erlebnis“, erinnert er sich. O'Reilly entschloss sich, ein weiteres Treffen zu organisieren. „Im Spätherbst [1997] begann ich ein Treffen für den Frühling zu organisieren, diesen Gipfel, den wir den Freeware Summit nannten. Und ich dachte: O.k., lasst mich sehen, ob es mir gelingt, die Leiter all dieser bekannten Projekte ... zusammenzubringen, damit sie einander kennen lernen können." Zu diesen Leuten zählten Linus, Larry Wall, Brian Behlendorf, Eric AHman, Paul Vixie und Eric


--------------------------------------------------------------------------------------Raymond. Ursprünglich als Treffen von Hackern geplant, die an der Westküste der Vereinigten Staaten lebten, wurde später eine breitere Teilnehmerschaft zu dem Gipfel eingeladen. Auffallend war, dass ein Kaliber wie Richard Stallman fehlt. Das war aber nicht die einzige Lücke der Versammlung - so war zum Beispiel kein Vertreter der freien BSD-Varianten anwesend. „RMS war nicht eingeladen", erklärt Raymond. „Ich hatte mich dafür eingesetzt, es zu tun, wurde aber überstimmt Tim O'Reilly und die anderen Mitorganisatoren dachten, dass er bei der Bildung eines Konsenses, von dem aus wir weiter arbeiten könnten, stören würde." Die Ausschließung sollte sich als symbolisch erweisen. Der Freeware Summit ermöglichte es den anderen nicht nur, einander kennen zu lernen und ihre Erfahrungen auszutauschen, sondern er signalisierte auch eine Verschiebung innerhalb dieser Welt und machte eine Spannung deutlich, die sich his heute nicht aufgelöst hat. Bei dem Begriff „freie Software" geht es in erster Linie um das Wort „frei". Für Stallman steht die Freiheit absolut im Mittelpunkt von allem, was er tut, und deshalb würde er nie einen anderen Begriff wählen. Aber selbst seine Bewunderer haben Probleme mit dem Wort, wenn auch nicht mit der Idee. So beschreibt zum Beispiel Bruce Perens die GNU GPL als „eines der revolutionärsten Dokumente unseres Jahrhunderts". Aber er merkt an: „Das Wort „frei" ist für Unternehmen insofern ein bisschen einschüchternd, indem sie denken, sie könnten kein Geld mit etwas verdienen, was frei ist. Im Englischen gibt es das Problem, dass wir, wenn wir „frei“ sagen, meistens kostenlos meinen, aber so, wie Richard Stallman das Wort verwendet, meint er es im Sinn von „Freiheit". Er sprach also über Rechte, nicht über den Preis, aber das kam nicht wirklich hinüber." Einige Monate vor dem Freeware Summit begann Raymond nach einem neuen Namen Ausschau zu halten, der weniger zweideutig sein würde als „freie Software". Der Auslöser für seine Suche war die Ankündigung von Netscape im Januar 1998 gewesen, den Quellcode für seine Communicator Browsersuite freizugeben (darauf kommen wir im 11. Kapitel zurück). Am Anfang dachte Raymond, dass dies der Free Software Community


------------------------------------------------------------------------------------die einzigartige Chance geben würde, das von ihr geschaffene Medieninteresse zu nützen. Nachdem er Netscape in seiner Zentrale in Mountain View, Kalifornien besucht hatte, berief Raymond für den 3. Februar 1998 in den Büroräumlichkeiten der GNU/Linux Hardwarefirma VA Research, die zu dieser Zeit ebenfalls in Mountain View ansässig war, ein Meeting ein. „Ich erklärte, dass wir meiner Meinung nach einen neuen Begriff brauchten, der für den Mainstream weniger bedrohlich klang", erinnert er sich. „Also veranstalteten wir ein Brainstorming und kamen dabei auf ,Open Source'." Zu den Teilnehmern des Meetings zählten Raymond, Larry Augustin, der CEO von VA Research, John „Maddog" Hall, der an einem Teil des Meetings per Konferenzschaltung teilnahm, Sam Ockman von der Silicon Valley Linux User Group und Christine Peterson, Präsidentin des Foresight Institute. Raymond erklärt dazu: „Das Forsight Institute besteht aus einer Gruppe von Denkern, die sich mit Nanotechnologie befassen." Sie bauen Maschinen im molekularen Maßstab. „Wir versuchen, sie zu entwickeln und sie zu kontrollieren, um sie richtig verwenden zu können." Es war Christine Peterson, so sagt er, „die den Begriff ,Open Source' prägte". Eines der wichtigsten Anliegen des Freeware Summit, der von O'Reilly organisiert worden war und am 7. April in Palo Alto stattfand, bestand darin, eine Alternarive für den Begriff „freie Software" zu finden, von dem sich alle anwesenden Führungskräfte einig waren, dass er aufgegeben werden sollte. Zu den Vorschlägen zählten nicht nur das frisch gebackene „Open Source", sondern auch „Freeware", „Sourceware" und „Freed Software". Nach einigen Diskussionen wurde abgestimmt, und „Open Source" gewann. Neben der Idee, einen neuen Namen zu finden, stammte auch die Idee, Open Source zu definieren, von Raymond. Er wollte etwas, was andere Lizenzen als die GNU GPL zuließ, aber trotzdem die wichtigsten Ideen der freien Software verkörperte. Ein Jahr davor hatte sich die DebianGruppe mit derselben Frage auseinandergesetzt. Wie Perens, ein führender Debian-Kopf der damaligen Zeit, anmerkte: „Wir wollten, dass Debian zu 100 Prozent freie Software war. Damals wussten wir irgendwie von der Philosophie Richard


--------------------------------------------------------------------------------------Stallmans und von der Free Software Foundation her, was freie Software war. Aber wir wollten in der Lage sein, mehr Lizenzen zu akzeptieren als nur die von GNU, und wir hatten bereits ein System zusammengestellt, von dem wir glaubten, dass es nur aus freier Software bestünde. Dabei hatten wir noch gar nicht formell festgelegt, was unter freier Software überhaupt zu verstehen war." „Also setzte ich mich hin und schrieb den ersten Entwurf des Debian Social Contract", erzählt Perens. „Ich legte den ersten [Entwurf] Anfang Juni [1997] vor. Wir diskutierten einen ganzen Monat lang auf der privaten Mailingliste, und dann stimmten wir ab und er wurde Teil der Projektrichtlinie." Ein wichtiger Teil des Social Contract bestand in den Debian Frce Software Guidelines, die, wie Perens hinzufügt, im Wesentlichen das umrissen, „was wir der Free Software-Community als Gegenleistung für all die großartigen Programme zurückgeben würden, die wir von ihr bekamen". Perens erklärt, wie die Definition von Open Source zustande kam. „Eric Raymond rief mich an dem Tag nach dem Meeting an, bei dem der Begriff Open Source geprägt worden war. Raymond erklärte die Denkweise, die hinter dem neuen Namen stand und sagte, er suche nach einer Definition dafür. Als Eric mich anrief, sagte ich: O.k., klingt gut, lassen wir Open Source als Warenzeichen schützen und den Namen an die Debian Free Software Guidelines binden; wir werden das die Open Source Definition nennen." Es brauchte kaum etwas geändert zu werden: „Ich nahm keine wesentlichen Veränderungen an dem Dokument vor", sagt Perens. „Ich änderte nur das Debian und verallgemeinerte es." Die Open Source Definition legt neun Kriterien fest, welche die Distributionslizenz der Software erfüllen muss, um das Produkt „Open Source" nennen zu dürfen. Die ersten drei dieser Kriterien - die Möglichkeit, die Software frei zu verteilen, die Bereitstellung des Quellcodes und das Recht, durch Modifikationen abgeleitete Arbeiten zu schaffen - verkörpern jene grundlegenden Charakteristika, die im Zentrum der neuen Softwareentwicklungsmethode stehen. Die anderen beschreiben weniger wichtige Erfordernisse; sie stellen zum Beispiel sicher, dass die Lizenz weder Personen noch Gruppen oder Unternehmungsbereiche (wie Pirmen) diskriminiert und dass


------------------------------------------------------------------------------------Schlupflöcher geschlossen werden, die ansonsten genutzt werden könnten. In einer Presseaussendung, die kurz vor dem Freeware Summit herauskam, wurden die Projekte, um die es ging, noch „Freeware" genannt. Nach dem Gipfel wurden sie in einer anderen Presseaussendung „Open Source" genannt (auch „Sourceware" wurde erwähnt). Der Grund, der für diese Änderung angegeben wurde, ist signifikant: „Während diese Art Software in der Vergangenheit oft ,Freeware' oder ,freie Software' genannt wurde, kamen die Entwickler überein, dass die kommerzielle Entwicklung der Software Teil des Bildes ist und dass die Begriffe ,Open Source' oder ,Sourceware' die Entwicklungsmethode, um die es hier geht, am besten beschreiben." Das heißt, dass das Meeting ein bewusster Versuch war, den Softwarefirmen eine Aktivität verständlich und akzeptabel zu machen, was bis dahin zersplittert und marginal gewesen war. Das war eine wichtige Neupositionierung. Die beim Freeware Summit anwesenden Führungskräfte waren übereingekommen, dass sie, um die Akzeptanz ihrer Software noch weiter zu erhöhen, einen unternehmensfreundlicheren Ansatz wählen müssten. Dazu gehörte auch ein einprägsamer und leicht verständlicher Name - in anderen Worten eine Marke. Richard Stallman stand dieser Veränderung von Anfang an mit großer Skepsis gegenüber. „Die Open-Source-Bewegung ist Eric Raymonds Versuch, die Bewegung der freien Software von ihrem Hauptanliegen, der Freiheit, wegzubringen", sagt er. „Er hält die Freiheit zur Weitergabe von Software nicht für eine ethische oder soziale Frage. Also entschloss er sich, den Begriff ,freie Software' durch einen anderen zu ersetzen, durch einen Begriff, der keinerlei Hinweis auf diese Aspekte enthält." „Beim GNU-Projekt", so Stallman, „geht es um Freiheit, und deshalb nennen wir unsere Software auch weiterhin ,freie Software'. Den Begriff ,Open Source' verwenden wir nicht. Raymond hofft, dass die Verwendung des Begriffs ,Open Source' die bestehenden Softwareunternehmen dazu bringen wird, nützliche Programme als freie Software herauszubringen. Das ist gut, wenn es funktioniert, aber was unsere Gemeinde am meisten braucht, sind


--------------------------------------------------------------------------------------viele, viele User, die ihre Freiheit zu schätzen wissen und nicht leichtfertig von ihr ablassen." Stallman konnte kaum etwas tun, um die anderen davon abzuhalten, nach einer neuen Marke zu suchen. Dieser Marketingaspekt des Gipfels war schon bei seiner Planung eine der Hauptüberlegungen gewesen. „Als wir darüber nachdachten", erinnert sich O'Reilly, „sagten wir, oho, da haben wir ja eine großartige PR-Möglichkeit - wir sind eine Firma, die gelernt hat, die Dinge aus dem PR-Blickwinkel zu betrachten. Das heißt, dass ein Tagesordnungspunkt für den Gipfel darin bestand, uns einfach zusammenzusetzen und herauszufinden, was wir gemeinsam hatten. Und der zweite Punkt war, eine Art Erklärung darüber zustande zu bringen, dass es sich hier um eine Bewegung handelt und dass alle diese Programme etwas gemeinsam haben." Am Ende des Gipfels wurde eine Pressekonferenz abgehalten. Nichts hätte den neuen Ansatz besser symbolisieren können als diese Phalanx von Spitzenhackern, die wie der Vorstand eines konventionellen Unternehmens in Reih und Glied vor die Presse traten. O'Reilly erinnert sich, dass „die grundlegende Botschaft lautete, dass [ihr Presseleute] uns fragt, ob wir ,Microsoft schlagen werden'. Und ich sagte: ,Schaut euch die Open-Souree-Leute doch an: Sie alle verfugen über einen dominierenden Marktanteil und haben kein Geld. Sie haben nichts als die Kraft ihrer Ideen und dieses neue Modell'. Und dann ging ich die Liste durch und sagte: ,Seht her, hier sind all diese Programme, die Marktführer sind. Ich sagte, ihr könnt doch nicht sagen, dass das kein Gewinnermodell ist.'" Der Freeware Summit war ein entscheidender Augenblick in der Geschichte der freien Software. Wie Eric Raymond sagte: „Eines der Dinge, die interessant daran waren, war, dass es der erste bewusste gemeinsame Schritt der Community war." Die wichtigen Akteure -außer Stallman - hatten nicht nur vereinbart, gemeinsam vorzugehen, sondern hatten auch die Strategie ausgearbeitet, um diese neue Gemeinschaft wachsen zu lassen. Der Gipfel und diese Entscheidungen sollten wichtige langfristige Auswirkungen haben, aber sie führten sogar auf kurze Sicht zu einer Bewusstseinshebung in den Medien. Dieses Bewusstsein wurde bei einem weiteren Meeting, das drei Monate danach in


------------------------------------------------------------------------------------Silicon Valley abgehalten wurde und das ebenfalls direkte und wichtige Auswirkungen haben sollte, noch weiter gestärkt. Das Meeting mit dem Titel „Future of Linux" wurde am 14. Juli 1998 von der Silicon Valley Linux User Group (SVLUG) im Convention Center von Santa Clara abgehalten. Unterstützt wurde es von Taos, einer Zeitpersonalagentur für die Bereiche Unix und Windows NT, und von VA Research. Wie dem Bericht auf der Website der Benutzergruppe später zu entnehmen war, nahm es die Form einer Paneldiskussion an, auf der „offen über die Dinge gesprochen wurde, die Linux zu bewerkstelligen imstande sein muss, und über die Barrieren, die Linux durchbrechen muss". Dem Panel gehörte unter anderem Linus an, der an solchen Meetings nun, da er in Santa Clara wohnte, offensichtlich leichter teilnehmen konnte. Ebenfalls anwesend war Larry Augustin von VA Research. „Es war ein unglaubliches Erlebnis", erinnert er sich. „Der Raum fasste um die 800 Leute. Man konnte nur stehen, da sich ungefähr 1.000 Leute hineingezwängt hatten. Für mich war das der Punkt, an dem wir viele Leute davon überzeugen konnten, dass dies hier Realität war und dass es dort draußen schon jede Menge Benutzer gab. Dieses Ereignis war der Katalysator für viele Dinge." Überraschend an dem Meeting war nicht nur die große Zahl der Hacker, die daran teilnahmen, sondern es gab auch großes Aufsehen in der Presse. Im August brachte die San Francisco Gate einen Bericht über das SCLUG Meeting vom 14. Juli und ein Interview mit Linus, das in der darauf folgenden Woche geführt worden war. Im August 1998 wurden noch mindestens drei wichtige Features gebracht: in Computerworld in Sun World und und in keinem geringeren Wirtschaftsmagazin als Forbes. Der Artikel mit dem Titel „For the Love of Hacking" (Aus Liebe zum Hacken) war der bis dahin wichtigste Bericht über die Bewegung, und Linus war sogar auf dem Titelblatt abgebildet. Der Artikel befasste sich nicht nur mit Linux, sondern auch mit Apache, Sendmail, Perl, Richard Stallman und Eric Raymond. Time brachte in einem prominent platzierten Feature namens „The Mighty Finn" im Oktober 1998 einen eigenen Beitrag. Im Vergleich zu der Situation sechs Monate davor war diese Vielzahl von Presseberich-


--------------------------------------------------------------------------------------ten eine deutliche Veränderung - aber wie sich zeigte, musste Linus seine neue Berühmtheit teuer bezahlen. Als Linus nach Silicon Valley zog, wurde Besorgnis laut, ob es ihm gelingen würde, das Entwicklungstempo, an das sich die LinuxGemeinde inzwischen gewöhnt hatte, aufrechtzuerhalten. Schließlich war er umgezogen, um einen Job in einem Start-up-Unternehmen anzunehmen, und außerdem war er vor kurzem Vater geworden. Sicher, so fürchteten viele, würde es ihm nun nicht mehr möglich sein, Linux so viel Zeit zu widmen wie früher. Es stimmt, dass sich die Entwicklung ein wenig verlangsamte, aber es gab keine Anzeichen dafür, dass Linus Anpassungsschwierigkeiten hatte. Er war nicht nur ein großartiger Codierer und eine großartige Führungspersönlichkeit, sondern er verstand es auch virtuos, einen bemerkenswert anstrengenden und facettenreichen Lebensstil zu führen. Nun wurden jedoch zusätzliche Anforderungen an seine ohnehin stark beanspruchte Energie und Zeit gestellt. Nachdem er eine gewisse Medienberühmtheit erlangt hatte, musste er mehr Zeit für lange Interviews oder für die Beantwortung der Fragen der Journalisten aufwenden, die versuchten, dieses (für sie) eigenartige und fremde Linux-Phänomen zu verstehen. Als ob das alles nicht genug gewesen wäre, bekamen Linus und Tove im Frühling 1998 ihr zweites Kind, Daniela. Wie viele Eltern mit mehreren Kindern bestätigen werden, ist die Ankunft des zweiten Kindes oft - anders als die des ersten - ein Schock. Angesichts dieses stetig steigenden Drucks wäre es ein Wunder gewesen, hätte Linus so reibungslos weiterarbeiten können wie davor. Wie sich herausstellte, bewegte er sich an der Grenze seiner Belastbarkeit, und 1998 stand die Linux-Gemeinde vor einer noch schwereren Krise, als es bei den Netzwerkkriegen des Jahres 1993 der Fall gewesen war; diese Krise drohte tatsächlich, den Pioniergeist der Zusammenarbeit zu ersticken, der Linux so schnell so weit vorangebracht hatte. Im September 1998 tauchte die schreckliche Bedrohung einer Gabelung am Horizont auf. Eine richtiggehende Gabelung gilt im Allgemeinen als eine Art Bruderkrieg, das Schlimmste, was einer Hackergemeinde zustoßen kann, und etwas, was es um jeden Preis zu vermeiden gilt. Eine


------------------------------------------------------------------------------------Gabelung ist etwas ganz anderes als die ideologischen Differenzen, wie sie etwa zwischen den Unterstützern der ursprünglichen Free-SoftwareBewegung und der neueren Open-Source-Gruppe herrschen; es ist nicht nur möglich, sondern normal, dass Vertreter beider Seiten bei einem bestimmten Projekt zusammenarbeiten. Bei einer Gabelung geht es hingegen um Entweder-oder, und wenn es den beiden gegnerischen Gruppen nicht gelingt, einen Prozess einzuleiten, der „healing the fork" (die Gabelung heilen) genannt wird, ist davon auszugehen, dass die Differenzen zwischen ihnen weiter wachsen und die Kluft immer größer und bald unüberbrückbar wird. Eine der berühmtesten Gabelungen in der Welt der freien Software gab es 1993, und zwar nicht bei Linux, sondern bei Emacs, als eine Gruppe von Hackern beschloss, separat von der Arbeit Richard Stallmans mit einer eigenen Emacs-Entwicklungslinie zu beginnen. Zu den Führungspersönlichkeiten dieser Gruppe zählte Jamie Zawinski, der viele Jahre lang in der Bewegung der freien Software mitgearbeitet hatte und beim Freeware Summit im April 1998 einer der langjährigsten anwesenden Akteure war. Aus bitterer Erfahrung sprechend, sagte er: „Gabelungen sind etwas wirklich Furchtbares." Es war eine Entscheidung, die er und andere Hacker nur äußerst ungern trafen. „Wir hatten das Gefühl, alle unsere Optionen ausgeschöpft zu haben", erklärt er. Leider sieht Zawinski kaum Chancen, die Emacs-Gabelung zu heilen. „Das Ganze ist zu weit auseinander gedriftet, und die kulturellen und technischen Differenzen sind nicht verschwunden." Die „kulturellen und technischen Differenzen" wurden durch die langsame Entwicklung von GNU Emacs 19, die manche Emacs-User verärgert hatte, noch weiter verstärkt. Verschiedene Leute versuchten den Prozess zu beschleunigen, indem sie Beiträge zur Entwicklung leisteten. Aber wie Zawinski auf seiner Website sagt, „waren unsere Versuche, der FSF bei der Fertigstellung ihres Emacs 19 Projekts zu helfen, ein ziemliches Desaster, und wir erreichten den Punkt, an dem wir nicht länger warten konnten. Also bündelten wir unsere Arbeit in Emacs 19, nannten es Lucid Emacs und veröffentlichten es." Richard Stallman hat die Episode anders in Erinnerung. „Zawinski und andere schrieben große Änderungen


--------------------------------------------------------------------------------------von [Emacs], ohne es uns auch nur zu sagen. Als ich das herausfand und Zawinski anrief, sagte er mir, dass ihre Pläne schon zur Hälfte implementiert seien und dass es zu spät sei, irgendwelche Beiträge von uns entgegenzunehmen. Er sagte, er erwartete, dass wir alle ihre Änderungen genau so verwendeten, wie sie uns geliefert würden, und weigerte sich, sie in irgendeiner Weise so zu adaptieren, dass sie das taten, was wir wollten. Wenn sie uns hätten helfen wollen, hätten sie uns von Anfang an sagen müssen, was sie vorhatten." Die Ereignisse, die Linux in die gefährliche Nähe einer Gabelung brachten, wiesen interessante Parallelen zu der Emacs-Situation auf. Die Ereignisse im Herbst 1998 begannen ihren Lauf zu nehmen, als es Linus nicht gelang, mit der Flut von Patches Schritt zu halten, die ihm zugeschickt wurde; wie bei der XEmacs-Gabelung entstanden zwischen den beiden Hauptfraktionen „kulturelle und technische Differenzen1. Die Anfänge waren ganz unschuldig. Am 28. September 1998 postete Michael Harnois, ein Kernelhacker, in der Linux-Kernel Mailingliste, die seit langem das wichtigste Diskussionsforum des inneren Kerns der Spitzenhacker war, eine einfache technische Frage. Sie lautete: Bin ich der Einzige, bei dem „2.1.123 fbcon.c" nicht kompiliert?" Das heißt, dass er wissen wollte, warum ein kleines Stück Code in Version 123 des Enrwicklungskernels 2.1 nicht funktionierte. Wie üblich, schickte ihm bald jemand eine Erklärung für das Problem und fugte einen Patch bei, der es beheben sollte. Aber dann schaltete sich ein anderer Hacker, Geert Uytter-hoeven, ein und schrieb: Bitte verschwendet eure Zeit nicht mit dem Schreiben dieser Patches. Diese Dinge funktionieren im „vger"-tree. „Vger" hat Eingang in die Linux-Mythologie gefunden. Der Begriff bezieht sich auf einen Computer in der Rutgers University, auf dem


------------------------------------------------------------------------------------unter anderem die Linux-Kernel-Mailingliste lief. Sie war von Dave Miller eingerichtet worden, als er dort studierte und arbeitete. Miller erklärt, wie sie zustande kam. „Die [Mailing]listen, die es gab, als ich kam, stammten aus Finnland", erinnert er sich, „und sie traten langsam in eine Phase ein, in der sie nicht mehr gewartet wurden. Die Leute begannen sich zu beschweren, die Listen funktionierten nur jeden zweiten Tag, man erhielt keine Reaktion, um sich austragen zu lassen, wenn man Probleme hatte, etc." „Also fragte ich meine Kollegen [in Rutgers]: ,Kann ich hier auf dieser alten Maschine, die nicht mehr viel benutzt wird, ein paar kleine Mailinglisten einrichten?" Die Antwort lautete so in etwa: ,Teste eine, und wenn es keine Probleme gibt, kannst du die anderen dazunehmen." Ich glaube, sie wurden innerhalb der nächsten zwei Wochen oder so alle nach Rutgers verlegt", fährt Miller fort, „Der Name der Maschine in Rutgers war seit jeher vger. Vger klingt irgendwie komisch, nicht wahr? Kennen Sie die Stelle in Star Trek, wo das Raumschiff namens ,Voyager' über den Bildschirm fliegt, und einige der Buchstaben sind nicht mehr lesbar? Die verbleibenden Buchstaben ergeben das Wort VGER. Nun war ich sicher kein Star-Trek-Fan und ich hatte dieser Maschine nicht ihren Namen gegeben, aber es ist wohl, wie ich annehme, ein interessantes Puzzleteilchen in der Linux-Geschichte." Vger wurde auch für ein Programm namens Concurrent Version System (CVS) verwendet. Dabei handelt es sich um ein spezielles Programm, das für das Management der Softwareentwicklung verwendet wird. Im Wesentlichen ermöglicht es, den aktuellen Zustand eines Projekts zu verfolgen, zum Beispiel, welche Patches angewendet wurden. Das Programm wird weithin verwendet und eignet sich ausgezeichnet, um den Überblick über ein komplexes und schnell beweglichen Projekt wie Linux zu behalten. Uytterhoevens Botschaft, dass die „Dinge im vgerTree funktionieren", bedeutete nichts anderes, als dass die Patches auf den Code im CVS-System auf der vger-Maschine angewendet worden waren. Es gab nur ein einziges Problem: Linus verwendete CVS auf vger nicht.


--------------------------------------------------------------------------------------Die Folge war, dass Linus als Antwort auf die vorhergehenden Nachricht, derzufolge man keine Zeit mit dem Schreiben neuer Patches verschwenden sollte, folgende Antwort: Er verschwendet keine Zeit. Ich habe vor langer Zeit aufgehört, mit vger zu synchronisieren. Alle, die immer noch glauben, dass vger für den Standardkernel von irgendeiner Bedeutung ist irren sehr. Linus machte sich nicht länger die Mühe nachzusehen, ob der Schnappschuss des Linux-Kernels auf vger mit dem übereinstimmte, an dem er arbeitete. Einer der Leute, die die vger Site führten, Cort Dougan, schrieb: Das ist uns schmerzlich bewusst. Wir synchronisieren uns nämlich mit dir, und deshalb hat der vgcr-tree das, was er braucht, und auch deine Änderungen. Darauf antwortete Linus: Bitte bedenkt, dass es vollkommen hirnverbrannt ist zu sagen: „Es ist in vger, deshalb verschwenden Sie Ihre Zeit." Die Tatsache, dass es in vger ist. hat überhaupt nichts zu sagen, insbesondere da es jede Menge Zeug in vger gibt, das es wahrscheinlich nie bis zu 2.2. schaffen wird. Das bedeutet, dass Patches in das vger-CVS-System eingefügt wurden, die Linus mehr übernahm. Deshalb stimmte der Schnappschuss des Kernels trotz der Bemühungen Dougans und anderer nicht mit dem seinem überein. So kam es, dass der dortige Kernel Elemente enthielt die in der offiziellen Version der bevorstehenden Linux Version 2.2. nicht verwendet werden würden. Nach Linus' Bemerkungen, dass er sich nicht mit vger synchronisiere, stellte Kurt Garloff die bedrohliche Möglichkeit einer Gabelung ins Fenster.


------------------------------------------------------------------------------------Und du meinst, es ist eine gute Idee zuzulassen, dass sich die LinuxGemeinde in zwei Teile teilt - die Linus-Partei und die vger-Partei? Eines der Probleme der freien Software ist doch, die Leute dazu zu bringen, eine Standardversion zu akzeptieren und ihre Fixes daran und nicht an ihrer hochgradig individualisierten Version anzubringen. Tu das nicht! Diesmal ging Linus ein bisschen genauer auf die Frage ein. Er begann so: Nein. Ich habe versucht, das den vger-Leuten zu sagen. Das Problem ist, dass manche Leute glauben, dass sie, sobald sie in vger sind, über alles erhaben sind und sich über nichts mehr den Kopf zu zerbrechen brauchen. Diese Leute sind mir egal, ich will nichts von ihnen hören, und ich weigere mich, mit ihnen zu diskutieren. Einige Stunden später warf Martin Mares die Frage des Ignorierens von Patches auf: Vor einiger Zeit hast du versprochen, vor Version 2.2 einen einzelnen großen Videopatch zu akzeptieren. Ich habe ihn dir geschickt, aber du hast ihn ignoriert. Dave Miller wies Linus dann daraufhin, dass es sich um den großen Videopatch handelte, um den sich vger von Linus' Code unterschied. Jeder, der die Videotreiberschicht wartet, sagt dir: „Sieh dir Martins Patch an", nichts weiter Wenn du ihn ständig ignorierst, blockierst du alles. Anstatt also alles zu blockieren, sag einfach, dass du nicht willst dass Martin versucht, seine Sachen mit deinen zu fusionieren.


--------------------------------------------------------------------------------------Dann beschrieb Miller, was er als das zentrale Problem betrachtete: Hör auf mit dem Finger auf „vger" zu zeigen. Die Leute schicken dir ständig Patches. Du ignorierst sie und sagst ihnen nicht einmal warum. Das tust du sogar, nachdem du ihnen erzählt hast, du würdest einen Patch für das Videosubsystem akzeptieren. Garloff äußerte Linus gegenüber seine wachsende Besorgnis darüber, wohin all das führen würde: Ich verstehe, es ist nicht deine Schuld. Ich glaube noch immer, dass du, Dave M und ein paar andere aufpassen solltet, damit es keine Gabelung gibt. Es ist die Mühe sicher wert. Wir alle wissen, dass es Gabelungen gibt und immer geben wird. Das Problem ist, dass vger irgendwie wichtig ist, weil es von ein paar wirklich starken Leuten verwendet wird (Dave M...) Es scheint einigen der vger-Leute schwer zu fallen zu akzeptieren, dass es noch immer du bist der die offizielle Version wartet. Aber bemühe dich bitte ein bisschen, das beizulegen. Und informiere uns bitte über das Ergebnis und sage uns, ob wir vger beim Schreiben von Fixes berücksichtigen sollen. Aber der Satz „Ich verstehe, es ist nicht deine Schuld" machte Miller wütend: So ein Unsinn, Niemand hat ihm gesagt: „Linus, sieh dir vger an und nimm diesen Code." Das ist völlig blödsinnig, und ich verlange, dass sofort aufgehört wird, so etwas zu behaupten. Er wiederholte, dass das grundlegende Problem seiner Ansicht nach darin bestand, dass Linus Patches, die ihm geschickt wurden, nicht aufgriff.


------------------------------------------------------------------------------------Die Leute versuchen immer wieder, ihm einen Patch zu schicken, der einen Bug behebt und die Treiber/Videoverzeichnisse treibermäßig für andere Architekturen synchronisiert. Er sagt, er wird ihn aufnehmen, und dann muss der Verfasser feststellen, dass der Patch von Linus ständig ignoriert wird. Linus schrieb folgende Antwort an Martin Mares: Der Grund meiner Enttäuschung besteht darin, dass sich insbesondere vger als „Puffer" zwischen mich und Bugfixes drängt. Das heißt, dass wir jetzt in der Situation sind, dass es offensichtlich Bugs und Fixes für diese Bugs gibt - aber als solche bekomme ich sie nicht zu sehen, sondern ich sehe nur diesen homogenen Patch. Er schloss: Ich werde David noch einmal bitten, vger einfach zu schließen, weil diese Probleme nicht aufhören. An diesem Punkt schaltete sich Ted Ts'o, der vielleicht langjährigste Linux-Leutnant und eine Figur, die in der Bewegung große Achtung genoss, mit einigen klugen, an Linus gerichteten Worten zu einem Thema ein, das er mit „eingeschränkte Bandbreite" umschrieb. Damit meinte er Linus' Unfähigkeit, angesichts der Flut der auf ihn einströmenden Patches auf dem Laufenden zu bleiben. Um gegenüber den vger-Leuen fair zu bleiben, muss man sagen, dass eines der Probleme, die der vger CVS tree zu lösen versucht, darin besteht, dass du beim Übernehmen der Patches nicht besonders schnell bist. Es gibt mindestens eine Gruppe von ... Patches, die ich dir zwei oder drei Mal schicken musste, bevor du sie endlich annahmst - und dabei waren das kurze Patches (1-3 Zeilen Änderungen in 4 Dateien), denen eine vollständige Erklärung dessen beigefügt war, was sie bewirken. Im letzten Fall hatten Alan [Cox], du und ich sogar


--------------------------------------------------------------------------------------über verschiedene Ansätze zur Lösung dieses Problems gesprochen, bevor ich mit dem Codieren des Patches begann. Wir haben also ein Problem, und vger ist vielleicht nicht die beste Lösung ... Aber bevor du die vger Leute wegen dieses Patchstapelungseffekts, den du nicht magst, prügelst, wäre es nett, wenn du zur Kenntnis nehmen könntest dass deine Bandbreitenbeschränkungen vielleicht teilweise zu dem Problem beigetragen haben und dass sie einfach versuchen, sie zu umgehen. Was vierzig Stunden davor als einfache Frage über einen obskuren Bug begonnen hatte, entwickelte sich bald zu einer hitzigen Diskussion, die über zwei Kontinente und zehn Zeitzonen hinweg tobte. Auf einmal hatte Linus genug. Als Erstes feuerte er einen Schuss direkt auf Dave Miller ab: Wenn ich ganz ehrlich sein soll, habe ich von einer Menge Leute einfach die Schnauze voll. David, wenn ich zurückkomme, erwarte ich von dir eine öffentliche Entschuldigung. Und dann fugte er für alle anderen hinzu: Ihr anderen, schaut euch in den Spiegel und fragt euch, ob ihr euch sicher seid, ob ihr die Wartung besser machen könntet als ich. Wenn ja, sagt es mir. Vielleicht kommen wir zu einer Einigung. In einer letzten Nachricht ein paar Stunden später erklärte er zuerst, warum er Ted Ts'os Patches fallen ließ (und damit indirekt auch die aller anderen), um dann in einen ziemlich übertriebenen Wutanfall zu verfallen: Nehmt zur Kenntnis, dass ich von jemandem, den man nicht damit belästigen kann, einen Patch ein zweites Mal zu schicken, keinen Patch WILL. Jeder, der nicht bereit ist, auf seine Patches so gut aufzupassen, dass er sie solange


------------------------------------------------------------------------------------aufbewahrt, bis ich sie akzeptiert habe, soll wissen, dass ich von ihm ohnehin keine Patches will. Im Grunde will ich sagen, dass ich jede Menge Patches bekomme und dass ich in meiner Arbeit Prioritäten setzen muss. Das heißt, dass sich die Leute, die mir Patches schicken, eben so lange gedulden müssen, bis sie in den Kernel aufgenommen werden. Ganz ehrlich gesagt, macht mich diese spezielle Diskussion hier (und andere davor) einfach wütend, und sie macht den Druck noch STÄRKER. Stattdessen würde ich vorschlagen, dass ihrr wenn ihr eine Beschwerde über meinen Umgang mit Patches habt, darüber nachdenkt, mit wie viel Zeug ich mich fünf Minuten lang herumschlagen muss. Lasst mich in Ruhe, Leute. Oder schickt mir wenigstens keine Ccs mehr. Es interessiert mich nicht, ich gehe in Urlaub, und ich will nichts mehr von der Sache hören. Kurz gesagt, verpisst euch aus meiner Mailbox Angesichts dieser Korrespondenz konnte niemandem der traurige Zustand der Beziehungen zwischen den Spitzenhackern auf der KernelMailingliste verborgen bleiben. Einige Stunden nach Linus' letztem Posting gab Eric Raymond seinen Kommentar über die Situation ab: Leute: Das sind die ersten Warnsignale für einen möglichen Burnout. Nehmt sie euch zu Herzen und seid gewarnt. Linus Durchhaltevermögen war erstaunlich, aber es ist nicht grenzenlos. Wir alle (ja, auch du bist gemeint, Linus) müssen zusammenarbeiten, um den Druck auf den entscheidenden Mann in der Mitte zu „verrringen" anstatt ihn zu verstärken. Er weist auf etwas Zentrales für den Entwicklungsprozess von Linux hin: Linus ist so lange der liebe Gott, bis „er" etwas anderes sagt. Punkt. Wütend zu werden ist nicht hilfreich, und fair ist es auch nicht - und ihr miisst einmal der Schlüsselmann in der


--------------------------------------------------------------------------------------Entwicklung eines Stücks Software, das nie ausfallen darf gewesen sein, bevor ihr überhaupt wagen könnt, an so etwas zu "denken". Aber Raymond ist auch in seiner Analyse der breiteren Auswirkungen der Geschehnisse schonungslos. Patches gehen verloren. Patches werden nicht übernommen. Patches gehen irgendwo unter. Das ist schlecht und eine Verschwendung, aber es hat einen Sekundäreffekt, der noch schlimmer ist: Es wertet die Feedbackschleife ab, die dafür sorgt, dass der ganze Prozess funktioniert ... Die Folge der wachsenden Unsicherheit darüber, ob gute Arbeit überhaupt aufgenommen wird, ist ganz sicher noch schlimmer. Alle, die glauben, dass gute Arbeit den Ausguss hinuntergegossen wird, werden bald „weg" sein. Wenn das zu oft passiert, werden wir bald Geschichte sein. Anders ausgedrückt: Die Tatsache, dass Linus zu oft Patches ignorierte, war nicht nur störend, sondern unterminierte genau den Mechanismus, der die Triebfeder des Open-Source-Entwicklungsmodells war. Raymond schließt mit einer Warnung in der für ihn charakteristischen anschaulichen Ausdrucksweise: Die Risiken werden mit der Zeit größer werden, weil nicht nur die Komplexität der Systeme wächst, sondern auch der Entwicklerpool. Und der wichtigste Mann in der Mitte - die lebensentscheidende Schraube in unserem Hubschrauber - hat ein Stresslimit Wir werden dieses Limit eines Tages erreicht haben. Vielleicht stehen wir schon jetzt knapp davor. Er schließt: Ich zerbreche mir über dieses Problem schon seit Monaten den Kopf. (Ich bin der Anthropologe unserer Gruppe, wisst ihr nicht mehr? Es ist Teil meines Jobs festzustellen, wie die


------------------------------------------------------------------------------------soziale Maschinerie funktioniert und wo der Fehlermodus liegt.) Es widerstrebte mir, irgendetwas zu sagen, solange alles noch Theorie war, aber ich nehme das Obige als Warnung in Leuchtfarbe, die mir sagt, dass es das verdammt noch einmal nicht mehr ist. Raymond war nicht der Einzige, der diese Entwicklungen mit Besorgnis betrachtete. „Es gibt einige von uns - ich gehöre dazu , die sich darüber schon eine Zeit lang Gedanken machen und an einer Lösung arbeiten", schrieb Larry McVoy, Autor des ursprünglichen Sourceware-Dokuments und mittlerweile einer der engagiertesten Linux-Hacker, am Tag nachdem Linus bekannt gegeben hatte, seinen „Urlaub" antreten zu wollen. Wie Raymond beschrieb McVoy die Situation sehr anschaulich: „Das Problem liegt darin, dass Linus nicht skaliert", schrieb er in seinem Posting an die Linux-Kernel-Liste. Das war eine Anspielung auf eine der üblichen Beschuldigungen gegen Linux: dass es sich einfach nicht für Aufgaben auf Unternehmensebene skalieren lässt. McVoy schrieb weiter: „Wir können nicht erwarten, dass der Kernel, der von Tag zu Tag komplexer und größer wird, weiterhin in derselben Geschwindigkeit wächst, und wir können auch nicht erwarten, dass Linus immer Schritt hält. Aber wir wollen auch nicht, dass Linus die Kontrolle und die endgültige Autorität über den Kernel verliert. Er hat doch immer wieder bewiesen, dass er gut darin ist." McVoy war davon überzeugt, nicht nur eine Analyse, sondern auch eine Lösung zu haben - oder zumindest die Blaupause dafür. Er hatte die Idee, ein neues Stück Software zu schreiben, das die zunehmenden Probleme der Kerneleentwicklung in Angriff nehmen würde. Er erklärt, warum er damals im Herbst 1998 bereit war, sich mit der Lösung des Problems solche Mühe zu geben. „Wenn ich daran dachte, wie sich die Unix-Anbieter zersplitterten", schreibt er in seinem Sourceware-Vorschlag, „und wie schlecht das allgemein für die Quellcodebasis und für das Produkt selbst war, kam ich zu der Meinung, dass einem Projekt nichts Negativeres zustoßen kann als


--------------------------------------------------------------------------------------dass sich der Quellcodestrom spaltet. Es gibt nichts Schlechteres. Zwei führende Köpfe - das funktioniert nicht." McVoy geht noch ein wenig näher auf die Umstände ein, die um ein Haar dazu geführt hätten, dass das bei Linux der Fall gewesen wäre. „Linus hat einen Überlastungsnotschalter", sagt er. „Und wenn sich der umlegt, fängt er an, Mails oder Patches oder was ihm zugesendet wird, einfach zu ignorieren. Er löscht sie, ohne sie zur Kenntnis zu nehmen - keine negativen Kommentare, keine positiven -, das Zeug wird einfach aus der Mailbox gelöscht, nach dem Motto, ich habe jetzt keine Zeit, mich damit zu befassen. „Das Ergebnis war, dass sich die Leute über [Linus] zu ärgern begannen, weil er ihre Patches nicht beachtete. Das ging so weit, dass erstmals eine Gabelung drohte. Diesmal war es aber noch viel schlimmer. Alan Cox und Dave Miller, die beiden langgedientesten Leutnants, erwogen diesen drastischen Schritt ernsthaft, weil ihre Frustration bis ins Unerträgliche gestiegen war. Sie mussten etwas tun. „Da begann mir klar zu werden", sagt McVoy, „dass ein Weg zur Lösung des Skalierungsproblems darin bestünde, Tools zur Verfügung zu stellen, die dem Entwicklungsprozess eine Art Sternform verleihen würden. In der Mitte würde Linus sitzen, umgeben von einem Ring von Leutnants. Diese Leutnants würden ihrerseits von einem Ring von Lakaien umgeben sein, um die sich ihrerseits ein Ring von Lakaiendienern scharen würde. Aber die Information würde durch diesen Stern fließen, und es würde Filter geben. Das heißt, dass Linus letzten Endes Material bekommen würde, an dem er normalerweise nicht besonders viel zu tun brauchte, weil es von einer Person seines Vertrauens bereits gefiltert worden wäre." Das war im Großen und Ganzen eine Entwicklung, wie sie schon ein paar Jahre lang zu beobachten war. Aber McVoy betont: „Alles war sehr informell, und es waren die Leutnants, die die ganze Arbeit machten. Linus musste die Arbeit nur noch irgendwie durchsehen. Einen festgelegten Mechanismus gab es nicht." McVoy meinte, er könnte bessere Ergebnisse erzielen, indem er eine von ihm vorgeschlagene Sourcemanagementsoftware verwendete, die er BitKeeper nannte. Aber zuerst musste er die Idee den betroffenen Hauptbeteiligten verkaufen.


------------------------------------------------------------------------------------„Ich hatte also diese Vision", erklärt McVoy, „dass das Sourcenmanagement alle Probleme dieser Welt lösen könnte. Also nahm ich mir vor, diese Leute zusammenzutrommeln. Es war zwar schwer, aber letzten Endes kamen alle eines Abends zu mir zum Essen. Sie lebten weit verstreut im Bereich der Bay von San Francisco, aber das war bei allen so." Da Linus nun in Silicon Valley lebte, war ein solches Treffen möglich, wenn auch immer noch außergewöhnlich. „Miller war am Zustandekommen dieses Treffens maßgeblich beteiligt", erinnert sich McVoy. „Es ist sehr schwer, Linus dazu zu bewegen, sich auf etwas zu konzentrieren, außer er betrachtet es als sehr wichtig. Er war frustriert und ein wenig ausgebrannt, und Miller sagte einfach, komm zu diesem Treffen, oder wir spalten den Tree. Ich weiß nicht, ob er genau das sagte, aber jedenfalls übte er Druck aus. Es würde mich nicht überraschen, wenn er genau diese Formulierung gewählt hätte." Miller fügt hinzu: „Ich war sehr frustriert und aufgewühlt wegen der ganzen Sache. Ich war außer mir und hatte meinen gesunden Menschenverstand verloren. Die Dinge bewegten sich nur langsam. Wir beschäftigten uns hier schon zwei Jahre mit der Entwicklungsserie eines Kernels, und es war kein Ende in Sicht, Linus war überanstrengt und wahrscheinlich genauso frustriert wie wir wegen seiner abwehrenden Haltung und seiner Überarbeitung. Linux ist sein Baby, deshalb kann ich das mit ziemlicher Sicherheit sagen. Ich bin mir ziemlich sicher, dass er zu diesem Zeitpunkt einfach keine Zeit hatte, so viel Arbeit in Linux zu investieren, wie es notwendig gewesen wäre. In seinem Leben taten sich so viele andere Dinge." Miller führt dann etwas Interessantes ins Treffen: „Wenn [Linus] die nötige Zeit hat, kann ihm niemand das Wasser reichen. Letzten Endes ging es also weniger darum, dass Linus nicht skaliert, als darum, dass sich ,in Linus' Leben derzeit so viele andere Dinge tun: seine Arbeit bei Transmeta, seine wachsende Familie und die immer fordernder werdenden Journalisten - alles kam zusammen." „Das Treffen fand am Abend statt", sagt McVoy über diese entscheidende Zusammenkunft. „Sie trafen so zwischen 5 und 7 Uhr ein. Linus war ziemlich frustriert und ausgebrannt. Es war eine schwierige Zeit für ihn. Und das war wohl kein Wunder, oder? Alle


--------------------------------------------------------------------------------------betrachteten ihn als ein übermenschliches Wesen, und alle wollten, dass er, wenn sie ihm einen Patch schickten, sofort alles liegen und stehen ließ, um sich darum zu kümmern. Niemand hatte noch erkannt dass dieser Typ auch nur ein Mensch war und dass seine Möglichkeiten Grenzen hatten. Denn bis dahin hatte er keine Grenzen erkennen lassen." „Ich glaube, wir redeten über fachliche Dinge, bevor wir uns zum Essen setzten", fügt McVoy hinzu, „und dann, nach dem Abendessen, unterhielten wir uns noch ein paar Stunden." Miller erinnert sich: „Am Anfang waren die Gespräche sehr förmlich. Sie drehten sich darum, was wir als Entwickler taten, was Linus Arbeit machte und wie wir ihm seine Arbeit erleichtern konnten." „Dann begann ich zu beschreiben, wie dieses [BitKeeper-]Zeug meiner Meinung nach funktionieren konnte", fährt McVoy fort. Jen nahm dazu mehrere Anläufe. Es muss ein paar Stunden gedauert haben. Ich beschrieb die Architektur, und ich beschrieb, wie die Informationen durchfließen würden und wie das die Probleme lösen würde." Miller unterstützte ihn: „Dave war an allem interessiert, was den Prozess unterstützen würde", sagt McVoy. „[BitKeeper] hat viel von dem, was wir brauchen", erklärt Miller. „Und ich will eines sagen: Larry hörte Linus wirklich zu, als der erklärte, was er für den Fall haben wollte, dass er BitKeeper je für das Management derLinux-Kernelsourcen verwenden würde." Zu der Frage, ob Linus das System tatsächlich für die tagtägliche Arbeit an dem Kernel verwenden wird, sagt McVoy: „Ich habe den Eindruck, dass er es tun wird - das hat er jedenfalls gesagt." Aber unter einer wichtigen Bedingung: ,.Er wird es verwenden, wenn es das Beste ist", merkt McVoy an. „Das Beste ist seiner Meinung nach nicht nur besser als das, was andere haben. Das Beste ist das Allerbeste, das Bestmögliche eben. Die Frage ist: Wie hoch liegt seine Latte? Ziemlich hoch, würde ich sagen. Wie nahe bin ich daran, diese Latte zu überspringen? Nun, ich glaube, dass ich noch nicht ganz dort bin, aber ich bin verdammt nahe." Im September 1998 lag BitKeeper 1.0 noch in weiter Zukunft. Mittlerweile wurden andere Maßnahmen gesetzt, um zumindest einen Teil des Drucks von Linus zu nehmen. Alan Cox sagt: „Sobald wir den richtigen Weg gefunden hatten, dafür zu sorgen, dass die


------------------------------------------------------------------------------------Patcheinreichungen reibungslos Funktionierten, war wieder alles in Ordnung." Im Verlauf des Jahres 1999 begann Linus nach und nach, der Presse weniger Zeit zu widmen, bis er im Herbst des Jahres fast überhaupt keine Interviews mehr gab. Eric Raymond sagt dazu: „Einer der Gründe, warum ich die Rolle des ,Propagandaministers' übernahm, lag darin, dass Linus sie dadurch teilweise abgeben konnte." Vor diesem Hintergrund betrachtet ist es bemerkenswert, dass niemand außerhalb der Linux-Welt Notiz von der „Linus-skaliert-nicht"-Episode nahm. Obwohl es einen ziemlichen Machtkampf gab - der eine potenziell fatale Schwäche im Linux-Phänomen offen legen hätte können -, entging der Mainstream-Presse diese heiße Story im Wesentlichen. Das war wahrscheinlich deshalb der Fall, weil sie innerhalb der Mailingliste des Linux-Kernels ausgetragen wurde. Obwohl diese Liste öffentlich zugänglich ist, war sie kaum ein Forum, das Journalisten, die Open Source eben erst entdeckt hatten, genau verfolgten, obwohl sie in gewissem Sinn den inneren Dialog im „Gehirn" des Linux-Organismus repräsentierte. Die Folge war, dass die Mailingliste des Linux-Kernels eher wie der Ankdammen oder der Ententeich der schwedischen Gemeinde in Finnland war, wo jeder jeden kannte, wo die Gruppe als Ganzes aber meist für sich blieb." Der andere wichtige Grund, warum die nationale und allgemeine Fachpresse das fesselnde Drama, das sich in dieser obskuren, wenn auch wichtigen Arena entspann, übersah, lag darin, dass 1998 immer mehr Computerriesen GNU/Linux und Open Source zu verwenden begannen. Die Journalisten hatten viel zu viel damit zu tun, auf dem Laufenden zu bleiben und sich ein Bild von den enormen kulturellen Veränderungen zu machen, die da vor sich gingen, als sich über ein paar unbeachtete Patches den Kopf zu zerbrechen.

11

Lasst die Eidechse los

ALS NETSCAPE AM 22. JANUAR 1998 ankündigte, den Quellcode für die nächste Generation seiner Webbrowsersoftware freizugeben, war das nicht nur ein Wendepunkt in der Geschichte der kommerziellen Software, sondern auch die endgültige und symbolische Vereinigung zweier Strömungen im Computerbereich: Internet und Open Source. Wie bereits beschrieben, basieren die wichtigsten Internetdienste auf Serverseite fast zur Gänze auf freier Software: BIND für den Domain Name Service, Sendmail für E-Mail und Apache und Perl für das Web. Der Aufstieg des World Wide Web führte in dem immer wichtiger werdenden Bereich des Clients - jener Browsersoftware, die im Zuge der Annahme des Web durch Firmen und Endbenutzer bald auf Millionen Desktops laufen sollte - zu einem Kampf zwischen offener und geschlossener Software.


------------------------------------------------------------------------------------Dieser stumme Kampf begann im Oktober 1991 etwa um die Zeit, als Linus Version 0.02 von Linux gepostet hatte. Am Ende dieses Monats hatte Tim Berners-Lee eine Mailingliste namens WWW-Talk für alle eingerichtet die sich für dieses neue World Wide Web interessierten, das erst vor kurzem für die Öffentlichkeit freigegeben worden war. Am nächsten Tag teilte Berners-Lee den Abonnenten der Liste mit, dass ein Mann namens Dan Connolly an einem X11 Browser arbeitete, also an Software für den Webzugang, die sich auf das X-Window-System, auch als X11 bekannt, stützen würde. Berners-Lee hatte einen Zeilenbrowser geschrieben, der in der Lage war, Textzeilen gemeinsam mit allen Hypertext-Links, die sie enthielten, anzuzeigen. Dieser Ansatz war in den Anfangszeiten ausreichend, weil es auf den Wehseiten noch keine Grafiken gab. Sein Programm lief auf dem NeXT Computer -jener Maschine, die Steve Jobs entwickelt hatte, nachdem er bei Apple hinausgeworfen worden war. Diese Maschine hatte eine kleine Anhängerschaft und verwendete idiosynkratische Software. Bemers-Lee wollte deshalb unbedingt eine Version entwickeln, die auf dem X11 System lief; dieses System wurde in der ganzen Unix-Gemeinde weithin verwendet, und ein solcher Browser würde die Anhängerschaft des Web beträchtlich vergrößern. Aber es gab ein Problem mit Connollys X11 Browser: Da Connolly für die Softwarefirma Convex arbeitete, war der Code nicht frei verfügbar, Berners-Lee versuchte, Convex dazu zu überreden, den Quellcode ihres Browsers freizugeben, wie Netscape es sechs Jahre später tun sollte. Am 8. November 1991 hielt Berners-Lee ein eloquentes Plädoyer für „offene Standards und freie Implementierung". Dann listete er einige Vorteile auf, die Convex erwachsen würden, wenn sie sich entschlössen, Connollys Webbrowser X11 der Webgemeinde zur Verfügung zu stellen, und er schloss: „Ich weiß nicht, ob Ihre Firma über einen Mechanismus zur Freigabe von Code verfügt (oder über eine General Public Licence). Sollte so etwas politisch unmöglich sein, wäre es jammerschade," Offensichtlich war es „politisch unmöglich". Das berichtete er einen Monat später der Mailingliste:

11. Lasst die Eidechse los

--------------------------------------------------------------------------------------Dan Connolly (Convex Inc.) hat einen W3-Browser für X zusammengestellt, kann aber den Code nicht freigeben. Eine Gruppe von Studenten in Finnland wollte mit einem ähnlichen Projekt beginnen - den Status dieser Arbeit kenne ich nicht. Wer immer einen guten X11W3-Browser zustande bringt, wird große Popularität erlangen. Die „Gruppe von Studenten" war nicht nur in Finnland ansässig, sondern stand unter der Leitung von Ari Lemmke, jenem Mann, der Linus dazu überredet hatte, seinen Kernel „Linux" anstatt „Freax" zu nennen. Neben der finnischen Software, die Erwise genannt wurde, gab es mindestens noch zwei anderen X11-Browserprojekte - Viola WWW und MidasWWW, Aber es war eine andere Software, die, wie BernersLee es ausgedrückt hatte, „große Popularität erlangen" sollte: Mosaic. Mosaic war im National Center for Supercomputing Applications (NCSA) geschrieben worden, das zur University of Indiana in UrbanaChampaign gehörte. Das Mosaic-Projekt wurde von einem jungen Mann namens Marc Andreessen geleitet, der nicht nur einer der Gründer von Netscape werden sollte, sondern auch beim Zustandekommen des Web, wie wir es heute kennen, eine Schlüsselrolle spielte. Andreessens erster Auftritt in der WWW-Talkliste war mehr als unauffällig. Am 16. November 1992 fragte er: Hat irgendjemand Code für die Erstellung von HTML-Dateien in Emacs geschrieben? Ich hacke da an etwas; lasst mich wissen, wenn ihr interessiert seid. Diese Nachricht ähnelt im Geiste Linus' früher Bitte um Informationen über die Posix-Standards. Obwohl niemand Geringerer als Dan Connolly auf Andreessens Frage antwortete und etwas Code schickte, der helfen sollte, hatte Andreessen bereits seine eigene Lösung gefunden. Nur einen Tag, nachdem er seine erste Nachricht gepostet hatte, schrieb er:


------------------------------------------------------------------------------------O.k., hier ist der erste Versuch eines html-Modus für Emacs. Kommentare, Bugreports und Verbesserungen sind willkommen. Der html-Modus für Emacs war eine Möglichkeit, Richard Stall-mans unendlich anpassungsfähiges Tool in etwas zu verwandeln, was man heute einen HTML-Editor nennen würde. Tatsächlich war Andreessen einer der besten Emacs-Hacker des NCSA. Als Emacs-Erweiterung wurde sein html-Modus natürlich unter der GPL herausgebracht, wie es auch mit Connollys X11-Browser hätte geschehen müssen, wäre es nach den Wünschen von Berners-Lee gegangen. Nach diesem wenig Aufsehen erregenden Beginn begann Andreessen bald regelmäßig zu posten. Sein Name wurde in der WWW-Talkliste nach Connolly und Berners-Lee bald zu dem am dritthäufigsten erscheinenden Namen, Am 1. Dezember erschien ein Posting von Berners-Lee, das sich als ungeheuer vorausblickend erweisen sollte. Es klang einigermaßen alarmiert: Ich bin ... ein wenig besorgt über die Explosion der Implementierungen. (Schon klar, natürlich freue ich mich auch darüber! :-) Danach warnte er vor etwas, was bereits begonnen hatte: Wenn ihr über ein smartes Extra ENTWEDER für http ODER für HTML nachdenkt, definiert es bitte und diskutiert es hier auf www-talk. Versucht nicht einfach, es vor dem anderen herauszubringen. Er wird wahrscheinlich dasselbe tun, und zwar anders. Das sind alles spannende Ideen, die davon profitieren, wenn im Netz auf ihnen herumgehackt wird. Wie er im vorhergehenden Jahr betont hatte, „ist es wichtig, dass jeder, der Zugang [zu einem Webdokument] hat, es lesen und einen Link dazu machen kann". Wenn sich die Standards nun aber zersplitterten, könnte das unmöglich werden; es bestand die Gefahr, dass anstelle eines einheitlichen Meeres Kompatibilitätsinseln entstehen könnten.


--------------------------------------------------------------------------------------Obwohl es zum damaligen Zeitpunkt niemand vermutet hätte, steckte die Saat dieser Zersplitterung bereits in einem Posting, das Andreessen am 1. Januar 1993 mailte, als er an die WWW-Talk Liste schrieb: Die Leute, die sich für Alpha- und Betatests eines neuen WWWBrowsers auf Motif-Basis in seinen verschiedenen Entwicklungsstadien interessieren, sollen sich mit mir in Verbindung setzen ... am Anfang ist es nur Hypertext, aber bald wird es auch Multimediafähigkeiten geben. Motif stellte eine Gruppe urheberrechtlich geschützter Bibliotheken bereit, die eine nette grafische Benutzerschnittstelle für Unix schufen. Aber Andreessens letzte Bemerkung war die wichtigste. Eine der Fragen, die zum damaligen Zeitpunkt für die größte Irritation in der Webgemeinde sorgten, lautete, wie zu den in HTML geschriebenen Seiten Bilder hinzugefügt werden konnten. Berners-Lee trat für eine sorgfältige Erforschung der Möglichkeiten der Verwendung von Bildern und der Implikationen der angewendeten Technologie ein. Wie aus seinem Posting vom 14. Januar hervorgeht, hatten Adreessen und das NCSA-Team ihren Entschluss, die Sache durchzuziehen - wenn nötig allein - bereits bekannt gegeben. Mosaic Version 0.5, das am 23. Januar 1993 herauskam, bestand nur aus Text. Aber es dauerte nicht lang, bis Andreessen den Ansatz andeutete, den NCSA für die Anzeige von Grafiken innerhalb des Browsers verfolgen würde. Am 25. Februar schrieb er: Ich möchte ein neues HTML-Tag vorstellen: IMG. Obwohl Bilder heute genau auf diese Weise verarbeitet werden, war die Methode damals umstritten, weil sie ein neues HTML-Tag hinzufügte, und Berners-Lee war dabei, HTML formal zu definieren. Das Letzte, was er wollte, waren neue, aus den Nichts auftauchende Tags, wo er doch damit beschäftigt war, die alten dingfest zu machen. Außerdem bestand die Gefahr, dass sich die


------------------------------------------------------------------------------------Gruppe jener verbreiterte, die mit ihren eigenen Lösungen ankamen, was zu einer Zersplitterung der Webstandards führen würde. Aber wie Andreessen erklärte: Indem ich IMG vorschlage, will ich, dass der Punkt erreicht wird, wo einige Browser dieses Feature irgendwie implementieren, auch wenn es nicht Standard ist - einfach, weil es der nächste logische Schritt ist und weil es großartig wäre, von Anfang an einheitlich vorzugehen. Anders ausgedrückt: Angesichts der Tatsache, dass andere drauf und dran war, eigene Ansätze zu implementieren, wollte Andreessen mit seiner Lösung frühzeitig den Fuß in die Tür setzen und die Arbeit anderer vorwegnehmen. „Es wäre großartig, von Anfang an einheitlich vorzugehen", war eine euphemistische Umschreibung für „Wir wollen, dass alle unseren Standard übernehmen." Am 12. März steckte Andreessen die Ansprüche seines Teams genauer ab, indem er die unmittelbar bevorstehende Veröffentlichung des neuen Browsers bekannt gab: Um noch einmal auf den inlined image thread zurückzukommen - ich bin kurz davor, Mosaic Version 0.10 zu veröffentlichen, die wie bereits erwähnt eingebundene GIF und XBM Bilder/Bitmaps unterstützen wird. Mosaic Version 1.0 für X folgte ziemlich bald danach - am 21. April 1993 - und konnte sich schnell als führender Browser für diese Plattform etablieren. Versionen für Microsoft Windows und Apple Macintosh kamen später in diesem Jahr hinzu, und je stärker sich Mosaic durchsetzte, desto schwieriger wurde es für Berners-Lee, dem neuen IMG Tag für HTML zu widerstehen. Es ist interessant, dass der vollständige Quellcode für die X-WindowVersion von Mosaic, wie es der normalen akademischen Tradition entsprach, „nur für den persönlichen Gebrauch, für die Verwendung in akademischen Institutionen oder für den internen geschäftlichen Gebrauch" verfügbar war, für PC-Plattformen aber


--------------------------------------------------------------------------------------nur „für akademische Institutionen und Regierungsbehörden der Vereinigten Staaten für die interne Verwendung". Die kommerzielle Nutzung des Mosaic-Codes wurde später im Namen des NCSA von einer Firma namens Spyglass übernommen, die ebenfalls in Illinois ansässig war. Sie war von Absolventen der University of Illinois gegründet worden. Der Vertrag zwischen der Universität und Spyglass wurde am 19. Mai 1994 unterzeichnet. Ausschlaggebend für sein Zustandekommen war zweifellos die Gründung einer Firma, der man den eher kühnen Namen „Mosaic Communications" verpasst hatte. Mosaic Communicarions war im April 1994 von Jim Clark, dem Gründer des Workstationherstellers Silicon Graphics, Inc. (SGI) und Marc Andreessen ins Leben gegründet wurden, um der Geschäftswelt Webtechnologic zu verkaufen. Das Unternehmen hatte seinen Sitz in Mountain View, Kalifornien. Es hatte sich nicht nur den Namen vom Pionierbrowser des NCSA geliehen, sondern auch die meisten Programmierer abgeworben, die an diesem Browser und am zugehörigen Webserver gearbeitet hatten. Am 13. Oktober 1994 kam von Marc Andreessen die historische Ankündigung, dass die erste öffentliche Betaversion des Produkts von Mosaic Communications nun verfügbar war. „Die Mosaic Communications Corporation bringt eine öffentliche Version von Mosaic Netscape 0.9 Beta für anonyme FTP heraus. Mosaic Netscape ist ein von Grund auf neu gebauter Intenetnavigator, mit einer für 14.4 Modems optimierten Leistung, native JPEG-Unterstützung und mehr." Von Anfang an waren Versionen für X Window, Microsoft Windows und den Apple Macintosh erhältlich. Das zeigte, wie weit die PCPlattformen bereits mit dem ursprünglichen Mosaic X11 Browser gleichgezogen hatten. In ähnlicher Weise war die Leistungsoptimierung (für Modems mit 14.400 Baud) ein Signal, dass Mosaic Netscape für die Benutzer außerhalb der Universitäten gedacht war, da Universitätsangehörige und Studenten normalerweise über schnellere Internetverbindungen verfügten und nicht auf Modems angewiesen waren. Der revolutionärste Aspekt dieser Ankündigung ist wahrscheinlich nicht einmal heute deutlich. Es war noch nie da gewesen, dass


------------------------------------------------------------------------------------ein Unternehmen ein Programm nicht nur frei zur Verfügung stellte das Herunterladen der Netscape-Version 0.9 war kostenlos, und das Programm stand „Einzelpersonen zur freien Verwendung zur Verfügung -, sondern dass es auch den gesamten Betatestprozess der Allgemeinheit überantwortete. Diese neue Vorgehensweise zeugte davon, dass Netscape seine Ursprünge an der Universität und in der Welt der freien Software hatte, wo diese Art des öffentlichen Debuggens Standard war. Die Ankündigung rief Mosaic Communications zum Pionier einer neuen Firmenart aus, die bald Net Companies genannt werden sollten. Die Entscheidung, es jedem zu erlauben, Nescape gratis herunterzuladen, hatte nicht nur ein Betatestprogramm in einem noch nie da gewesenen Umfang zur Folge, sondern noch eine weitere wichtige Auswirkung: die Idee, Marktanteile durch das Verschenken von Software zu erringen. Dabei ging es darum, durch die Zahl der installierten Programme andere Einnahmen zu generieren. Anders ausgedrückt: Mit der Veröffentlichung von Mosaic Netscape trat zum ersten Mal die neue Internetwirtschaft in Erscheinung, die seit damals die Softwarewelt und weitere Bereiche dominiert. Das war zum damaligen Zeitpunkt niemandem klar. Der Univer-sity of Illinois war jedoch bewusst, dass sie drauf und dran war, den Namen ihres Browsers und dessen führende Stellung im Browsersektor einzubüßen. Da ihr die meisten Programmierer den Rücken gekehrt hatten, gab es kaum noch etwas, was sie tun konnte, um sich der wachsenden Erfolgswelle von Netscape in den Weg zu stellen. Eines konnte sie aber tun: sich gegen den Namen „Mosaic Communications" zur Wehr zu setzen. Die Folge war, dass sich die Firma am 14. November 1994 in „Netscape Communications" umbenannte, „um ihre einzigartige Identität in der Branche weiter zu festigen und die von der University of Illinois geäußerten Bedenken zu entkräften", wie es in der Presseaussendung hieß. Einen Monat später veröffentlichte Netscape Communications Version 1.0 ihres Flaggschiffnavigatorbrowsers und legte den Einzellizenzpreis für die kommerzielle Nutzung mit 39 US-Dollar fest. Das Unternehmen brachte auch zwei Webserver seiner Netsite Commerce Server Linie heraus. Der Netsite Communications Server


--------------------------------------------------------------------------------------kostete 1.495 US-Dollar, und der Netsite Commerce Server, der mittels der von Netscape erfundenen neuen Technologie sichere Transaktionen anbot, 5.000 US-Dollar. Unter anderem, weil Netscape Detailinformationen über seine Technologie für sichere Transaktionen schlauerweise im Internet platziert hatten, damit andere sie übernehmen - und als de facto Standard einfuhren - konnten, bezeichnete es seine Produkte stolz als „offene Software" Damit war nicht gemeint, dass es sich um OpenSource-Software handelte, sondern dass es in Bezug auf das Urheberrecht eher nach offenen als nach geschlossenen Standards geregelt war. Da Microsoft die Internetrevolution zunächst verschlafen hatte, eroberte Netscape den Browsermarkt im Sturm. Noch 1995, als Microsoft den Launen des geschützten Microsoft Network (MSN), dem ein düsteres Schicksal beschieden sein sollte, vorbereitete, tat es das Internet ab, weil es angeblich in der Nutzung zu kompliziert und nur für Wissenschaftler von Interesse war. Die frühen Betaversionen von Windows 95 enthielten keinen Browser ein weiteres Zeichen dafür, dass Microsoft in diesem Sektor zu kämpfen hatte. Schließlich schaffte es Microsoft doch -rechtzeitig zur Einführung von Windows 95 am 25. August 1995 -, einen Browser herauszubringen, indem es einfach den NCSA-Code über Spyglass lizenzierte und den Browser in die Windows-Plus!-CD-ROM aufnahm, die separat verkauft wurde. Bis auf den heutigen Tag beginnt der Text des Informationskastens „Über den Internet Explorer' mit den Worten „Basierend auf NCSA Mosaic". Der Internet Explorer 1 war ein schwaches Produkt, und obwohl Microsoft später, zur Zeit der ersten Klage des US-Justizministeriums, in schamloser Weise behauptete, dass er in Windows 95 „integriert" sei, handelte es sich in Wahrheit nur um einen Zusatz in letzter Minute. Wenn die Geschichte von Microsoft von etwas zeugt, dann von der grimmigen Entschlossenheit des Unternehmens, seine oft inadäquaten ersten Softwareschreibversuche zu verbessern - der Internet Explorer ist da keine Ausnahme. Dazu kam, dass Microsoft inzwischen aufgewacht war und die Auswirkungen der Internetrevolution in ihrem vollen Ausmaß erkannt hatte - die atemberaubende Börseneinfiihrung von Net-


------------------------------------------------------------------------------------scape am 9. August 1995 war wohl auch kaum zu übersehen. Nach einem Eröffnungskurs von 28 US-Dollar schnellte der Kurs schon am ersten Tag auf 58,25 US-Dollar nach oben, was dazu führte, dass Netscape keine achtzehn Monate nach seiner Gründung 3 Milliarden US-Dollar wert war. Es war die erfolgreichste IPO der Geschichte und wohl der Zenit der Macht und Reputation von Netscape als führendes Internetunternehmen. Die neue Microsoft-Strategie sollte diese Macht und Reputation infrage stellen und attackieren. In seiner berühmten Pearl-Har-bour-Day-Rede vom 7. Dezember 1995 verkündete Bill Gates, dass Microsoft in Zukunft alle seine Aktivitäten am Internet orientieren würde. Diese Rede stellte den Internet Explorer in den Mittelpunkt der gesamten Microsoft-Strategie und machte seine Weiterentwicklung zur obersten Priorität. Die Rede markierte auch den Beginn von Kämpfen, die „Browserkriege" genannt wurden, als Microsoft und Netscape versuchten, einander mit schnell aufeinander folgenden Versionen ihrer Websoftware für Endbenutzer auszustechen. Der erste Verlust in diesem Kampf war nicht so sehr die Wahrheit, als es die Standards waren - die Fortsetzung einer traurigen Tradition, die mit der ersten Version von Mosaic begonnen hatte. Der Traum von Berners-Lee von einem einheitlichen, universell zugänglichen Web schien in weiterer Ferne zu liegen als je zuvor. Der Internet Explorer 2, der am 27. November 1995 veröffentlicht wurde, war nicht viel besser als die ersten Versionen, aber Version 3, die am 12. August 1996 erschien, hatte den Netscape Navigator schon fast eingeholt. Da der Internet Explorer kostenlos verteilt wurde, während die Firmen für den Navigator bezahlen mussten, stieg der Marktanteil des Internet Explorer unaufhaltsam, und mit ihm die Glaubwürdigkeit von Microsoft als Net Company. Ende 1996 war den Leuten von Netscape klar geworden, dass die Firma Probleme hatte. Einer derjenigen, die sich intensiv mit diesen Problemen und den mit ihnen verbundenen Fragen befassten, war Eric Hahn. Hahn war erst kurz davor, im November 1995, in die Firma eingetreten, nachdem Netscape sein Start-up-Unternehmen Collabra gekauft hatte. „Ich verbrachte die ersten vier Monate mehr oder weniger damit, Collabra in Netscape zu integrieren", erinnert


--------------------------------------------------------------------------------------sich Hahn. „Aber danach begann ich mit Jim [Barksdale]" - dem Präsidenten und CEO von Netscape, der das Ruder im Januar 1995 von Jim Clark übernommen hatte -, „über Sonderprojekte zu sprechen, da ich zusätzliche Zeit und eigentlich nichts anderes zu tun hatte", erinnert sich Hahn. Diese Zusammenarbeit führte zu mehreren White-Papers (Konzepten), in denen die zunehmende Malaise von Netscape analysiert und radikale Lösungen vorgeschlagen wurden. „Jedes Dokument nahm sich ein relativ schmales Themengebiet vor und bot eine vollkommen andere Sichtweise an als die geltende", sagt Hahn. „Deshalb nannten wir diese Dokumente die „Häresiedokumente". Der Name wurde gewählt, weil diese Dokumenten „ernsthafte Herausforderungen für die Denkweise des Unternehmens" waren. In Anbetracht ihrer umstrittenen Natur waren die Häresiedokumente vertraulich und wurden nur auf höchster Ebene diskutiert. „Sie waren nur für den inneren Kern bestimmt", erklärt Hahn. „Sie waren vollkommen frei und offen geschrieben, es wurde niemand verschont." Der innere Kern bestand aus dem Executive Committee: Jim Barksdale, Marc Andreessen, Mike Homer, der den Bereich Verkauf und Marketing leitete, der Verwaltungschef Peter Currie und Hahn selbst. Das erste Häresiedokument setzte sich mit der Java-Strategie von Netscape auseinander. Java von Sun machte es möglich, dass ein Programm geschrieben werden und dann ohne Modifikationen auf vielen verschiedenen Hardwaresystemen verwendet werden konnte. Das machte es perfekt für die Verwendung im Internet und unterminierte auch die dominierende Stellung der Microsoft-Windows-Plattform. Ursprünglich hatte Netscape Java-Software nur selbst geschrieben, aber nun schlug Hahn vor, die Implementierungen von Sun direkt in den Netscape Browser einzufügen. „Das war ein äußerst kontroversielles Dokument", erinnert sich Hahn, „und die Reaktionen darauf waren großteils negativ." Der Grund lag darin, dass viele Leute bei Netscape in dem plattformunabhängigen Java eine Waffe gegen Microsoft gesehen hatten. Noch am 26, August 1997 hatte Netscape eine Presseaussendung herausgegeben, in dem es seine Absicht zur Entwicklung einer „100 % reinen Java-Version" seines Navigator „bis 1998" ver-


------------------------------------------------------------------------------------sprach - eine Version seines Browsers, der ausschließlich in Java geschrieben sein würde. Diese Version, später mit dem Namen „Javagator" versehen, sollte nie das Licht der Welt erblicken. Die Idee, so viel Arbeit einfach wegzuwerfen, war alles andere als populär. „Aber sechs Monate später taten wir genau das", merkt Hahn an, „und das gab mir den Anstoß, das zweite Häresiedokument zu verfassen." Mehrere andere sollten folgen. Einige der wichtigsten dieser Dokumente und zweifellos jenes, das die dramatischsten Auswirkungen auf Netscape und auf die Außenwelt haben sollte, befasste sich mit der Frage des sinkenden Marktanteils von Netscape auf dem Browsermarkt. Es schlug vor, das Flaggschiffprodukt des Unternehmens, den Communicator (eine erweiterte Version des ursprünglichen Navigator Browsers), ebenfalls zu verschenken, um es Microsoft gleichzutun, und gleichzeitig auch den Quellcode zu veröffentlichen. „Mir ist kein bestimmtes Ereignis und auch keine Eingebung von oben bewusst, die diese Idee ausgelöst hätten", sagt Hahn, „Aber wir mussten feststellen, dass der Marktanteil unseres Browsers von Tag zu Tag zurückging. Deshalb war die Frage für alle beunruhigend und von vorrangiger Bedeutung." Hahn hatte über das Problem nachgedacht, und Schritt für Schritt kam er zu der Idee. „Mir gefiel die Entwicklung von Linux", sagt er. „Überhaupt hatte ich begonnen, mich für diese Dinge zu interessieren. Eric Raymonds Essay The Cathedral and the Bazaar beeinflusste mich stark." Aber der Essay war nur ein Beeinflussungsfaktor von vielen. Wie bei seinem Java-Häresiedokument stießen auch die Ideen dieses Papiers anfangs auf großen Widerstand. „In dem [Häresiedokument], in dem es um die Browserkriege ging, stand, dass jeder, der glaubte ... wir könnten es uns leisten, den Browserkrieg nicht zu gewinnen, falsch lag. Das klang für einige Leute ganz oben offensichtlich wie eine Anklage", merkt Hahn an - für Marc Andreessen zum Beispiel 1997. so Hahn, „gab Marc seiner Überzeugung lautstark Ausdruck, dass der Browser keine Rolle spiele und Netscape nicht daran interessiert sei, den Browserkrieg auszukämpfen. Etwa sechs Monate lang herrschte die falsche und kurzlebige Überzeugung, dass wir in Browserfragen


--------------------------------------------------------------------------------------Agnostiker sein könnten, und dass das, was wirklich zählte, unsere Server seien. Ich hatte diese [Server-] Division schon eine Zeit lang geführt und ich wusste verdammt gut, dass den Servern im Bewusstsein der Kunden kein großartiger Platz beschieden sein würde, wenn wir keine Browser am Desktop hätten. Wir würden es im Vergleich zu allen anderen, die Server verkauften, sehr schwer haben. In Wahrheit war es die Verbindung Browser plus Server, die den strategischen Vorteil brachte." Hahn brauchte beträchtlichen Mut, um die lebenswichtige Bedeutung des Browsers für die Strategie von Netscape hervorzustreichen, denn seine Beziehung zu Andreessen war durchaus harmonisch. „Marc und ich waren miteinander befreundet, und wir hatten eine großartige Beziehung", betont Hahn. „Sie war in dieser ganzen Zeit von gegenseitigem Respekt und von Unterstützung getragen." „Ich sagte zu Marc", berichtet Hahn, „dass ich meine Rolle als Technologiecher - ein Posten, den Hahn am 10. Oktober 1997 von Andreessen übernahm, dem die nebulöse Funktion eines Executive Vice President of Products übertragen wurde - „oder die Veröffentlichung dieser Dokumente nie dazu verwenden würde, seine Entscheidungen zu unterminieren. Ich fand, dass es für die Firma im Fall von Meinungsverschiedenheiten besser war, sich an Marcs klare Aussagen zu halten, als es auf eine Spaltung in den Führungsrängen ankommen zu lassen. Wenn er und ich uns also nicht einig waren, wie es eine Zeit lang in den Bereichen Linux, Open Source und ein paar andere Themen der Fall war, mussten diese Dokumente sorgfältig geheim gehalten werden, weil sie ein Hinweis auf einen ziemlich großen Meinungsunterschied waren." In einer solchen Situation hätten nur die wenigsten Führungskräfte daran festgehalten, ihre brutal offenen Analysen der Situation fortzusetzen. Zum Glück für Netscape befand sich Hahn in einer einzigartigen Position. „Ich hatte nichts zu verlieren", sagt en „Meine Aktien waren nun" - nach dem Kauf von Collabra -„endgültig unverfallbar geworden. Ich hatte mich immer ein bisschen als Außenseiter gefühlt, weil ich durch eine Übernahme in die Firma gekommen war. Deshalb brauchte ich mich auch an keine Firmenagenda zu hatten und keine Karriereleiter im Auge zu


------------------------------------------------------------------------------------haben. Ich hatte die besten Voraussetzungen, um mich ein bisschen in Szene zu setzen." Wie Hahns Entscheidung, seinem Vorstandskollegen zu widersprechen, indem er auf die entscheidende Bedeutung des Browsers hinwies, zwar persönlich problematisch, aber unvermeidlich war, war dies auch die Maßnahme, die nun ergriffen werden musste: die Freigabe des Quellcodes des Netscape-Browsers. „Wenn man logisch dachte", so Hahn, „war es eine direkte Schlussfolgerung, glaube ich." Die Schlussfolgerung mochte zwar logisch gewesen sein, aber für das Unternehmen war es trotzdem ein enormer Schritt. Zum Glück stellte sich heraus, dass Hahn nicht der Einzige war, der auf diese radikale Lösung drängte. „Wenn ich es zusammenfassen soll, würde ich sagen, dass es nicht irgendein einzelnes Dokument oder eine Sitzung war, wo das sozusagen entschieden wurde. Wenn ich mich recht erinnere, waren drei Faktoren an der Entscheidung beteiligt." „Jamie Zawinski und all die Leute, die dort draußen in den Schützengräben gearbeitet hatten, hatten schon eine Zeit lang darüber nachgedacht und waren offensichtlich aus mehreren Gründen fasziniert", setzt Hahn fort. Es gab da auch noch „einen Herrn namens Frank Hecker, [der] den großen Vorteil hatte, außerhalb des Einflussbereichs der Zentrale zu stehen. Er arbeitete im Außendienst, mit echten Kunden und Verkäufern, und ich glaube, er war schon viele Jahre bei der Firma und genoss große Glaubwürdigkeit." Bevor er als 20. Mitarbeiter zu Netscape gekommen war hatte sich Jamie Zawinski schon lange Zeit mit freier Software beschäftigt. „Ich nehme an, man kann sagen, dass ich mich mit freier Software beschäftigte, seit ich mich üherhaupt mit Software beschäftigte", erklärt er. Zawinski war 1993 federführend in der schmerzlichen Entscheidung beteiligt gewesen, den Emacs-Code zu spalten. Zawinski trat Netscape im Jahr 1994 bei. „Das war etwa einen oder zwei Monate nach der Gründung der Firma. Es war noch so gut wie kein Code geschrieben." Seine Aufgabe bestand darin, die X-WindowVersion des späteren Netscape zu entwickeln. Dazu hatte er nur ein paar Monate lang Zeit. Auf seine persönliche


--------------------------------------------------------------------------------------Website stellte Zawinski Auszüge aus seinem Tagebuch, das er zu der damaligen Zeit führte, in Form eines Stücks namens „Netscape Dorm". Dort schreibt er: „Dies sind die Tage, die traditionell als die „gute alte Zeit" bezeichnet werden. Aber die Zeit lindert den Schmerz und lässt die Dinge angenehmer erscheinen, als sie es in Wirklichkeit waren. Doch wer sagt, dass alles angenehm sein muss? Schmerz stärkt den Charakter (manchmal übrigens auch die Produkte)." „Netscape Dorm" zeichnet ein lebhaftes Bild dieser stürmischen frühen Tage bei Netscape. „Ich habe gestern schon wieder in der Firma geschlafen - zweieinhalb Stunden zusammengerollt auf einer Decke unter meinem Schreibtisch, ungefähr von elf bis halb zwei am Nachmittag." Und: „Bin gerade nach Hause gekommen. Das letzte Mal schlief ich vor - Moment mal - 39 Stunden." Es war um diese Zeit, dass Zawinski neben seiner fieberhaften Codierarbeit einen weiteren wichtigen Beitrag zum Unternehmen leistete: „Wir saßen um einen Konferenztisch - das war etwa im Juli 1994 - und dachten über Produktnamen nach", erinnert er sich. „Plötzlich sagte jemand: ,Wir müssen das NCSA wie ein Insekt zermalmen', denn damals war es unser wichtigstes Ziel, dem NCSA den Mosaic-Marktanteil abzujagen. Ich dachte an Godzilla. Die Netscape Communications Corporation hieß damals noch immer Mosaic Communications Corporation. So wurde ,Mosaic Godzilla' zu ,Mozilla'." Obwohl letzten Endes das geschäftsmäßigere „Netscape" zum Produktnamen gewählt wurde, lebte „Mozilla" im Unternehmen weiter, vor allem als Name des dinosaurierartigen Maskottchens von Netscape, und feierte schließlich im Open Source Browser Project eine glorreiche Auferstehung. Da Zawinski über praktische Erfahrung mit Open Source verfügte, spielte er eine wichtige, wenn auch außergewöhnliche Rolle, als es darum ging, diesen Entwicklungsprozess in der technischen Abteilung von Netscape populär zu machen. Das Interesse des dritten Mannes, der an der Veröffentlichung des Communicator beteiligt war, war durch Zawinskis Erklärungen in den privaten Newsgroups im Intranet von Netscape geweckt


------------------------------------------------------------------------------------worden, in denen diskutiert wurde, warum die Öffnung der Softwareentwicklung beträchtliche Vorteile mit sich brachte. Frank Hecker hatte für die Computerhersteller Prime und Tandem gearbeitet, bevor er im Februar 1995 zu Netscape ging. Dank seines Unix-Hintergrunds war er nicht nur mit dem GNU-Projekt vertraut, sondern er hatte auch Teile davon selbst portiert. Er wurde zum technischen Leiter der Verkäufergruppe ernannt, die für den Verkauf an staatliche Behörden zuständig war, und arbeitete von einem Büro in Bethesda, Maryland aus. Im Herbst 1997, etwa um die Zeit, als Netscape die Produktion des Javagator - der reinen Java-Version des Communicator - ernsthaft in Erwägung zog, las Hecker die internen Newsgroups, in denen die Techniker über die verschiedenen Tagesthemen diskutierten. „Eines der Dinge, die in den Newsgroups angesprochen wurden", erinnert sich Hecker, „war, dass wir, wenn wir Java als Entwicklungssprache verwendeten, einen Weg finden mussten, um die Bytecodes zu verschleiern, weil die Leute ansonsten das Java einfach zerlegen und den ursprünglichen Quellcode wieder herstellen konnten." Die Bytecodes waren eine spezielle Art von Binärcode, den Java produzierte. Der Punkt war, dass es leicht war, von den Bytecodes ausgehend den ursprünglichen Quellcode in der Java-Sprache wieder herzustellen - etwas, was bei kompilierten Programmversionen, die zum Beispiel in C geschrieben sind, schwierig ist. Wie Hecker erklärt: „Wir gingen irgendwie davon aus, dass wir, wenn wir etwas als javabasierte Systeme herausbrachten ... irgendeine Möglichkeit finden würden, den Quellcode im Wesentlichen zu verschleiern oder ihn anderweitig vertraulich zu halten," Schließlich herrschte allgemein die Überzeugung, dass die Hersteller kommerzieller Software den Quellcode vor Dritten immer geheim hielten. „Worauf andere, darunter Jamie Zawinski, sagten: Warum geht ihr uns damit auf die Nerven? Warum geben wir nicht einfach den Quellcode für dieses Zeug frei? Das würde uns den Vorteil bringen, dass andere Leute damit arbeiten, uns Fixes senden und uns beim Verbessern helfen und so weiter", fährt Hecker fort. „Das erschien mir als ein irgendwie interessantes Argument", sagt er. Er wusste, dass sich Leute wie Zawinski schon einige Zeit lang für diese Idee einsetzten, „Jamie und viele andere bei Netscape


--------------------------------------------------------------------------------------hatten es in den letzten Jahren, so um 1994, 1995, mehrmals vorgeschlagen." Aber trotz all ihrer praktischen Erfahrung auf diesem Gebiet war der Vorschlag nie aufgegriffen worden. Hecker glaubt zu wissen, warum. „Eines der Probleme, die ich sah, war, dass die Freigabe des Quellcodes traditionell von den Entwicklern vorgeschlagen wurde", merkt er an. Für sie lag es auf der Hand, warum das wichtig war. Auf der Ebene des leitenden Managements war es nicht wirklich klar, warum die Freigabe des Quellcodes nützlich sein konnte, denn schließlich war noch nie ein Business Case entwickelt worden." Das versuchte Hecker in einem umfassenden Dokument zu tun, das er „Netscape Source Code as Netscape Product" nannte. Er begann im August 1997 daran zu arbeiten. Dieser „etwas obskure Titel", sagt Hecker, „spiegelte meine Meinung wider, dass Netscape versuchen sollte, den Quellcode als Produkt zu behandeln, das den NetscapeKunden geliefert wurde, im selben Sinn wie Binärversionen als Produkte galten. Ich hatte das Gefühl, dass die Distributoren geschützter Software den Quellcode als etwas Magisches, Mystisches betrachteten als eine Art „Kronjuwelen" oder „Zaubertrank" - und dass sie deshalb negativ reagierten, wenn das Thema der Freigabe von Quellcode zur Sprache gebracht wurde." „Wenn es der Fall war, dass die geschäftlichen Vorteile der Freigabe des Quellcodes schwerer wogen als die Geheimhaltung, sollten die Unternehmen ernsthaft überlegen, ob, wann und wie sie ihren Quellcode veröffentlichen wollen." Auch wenn dieser Standpunkt logisch war, war er für die damalige Zeit revolutionär. Das Dokument listet auch detailliert die Möglichkeiten auf, wie mit Open-Source-Software Geld verdient werden konnte. Diese Betonung der kommerziellen im Vergleich zu den technischen Vorteilen der Freigabe von geschütztem Code erwies sich für Hahn zweifellos als starke Hilfe, als er seine Argumente dem Netscape-Board vortrug. Die gemeinsamen Bemühungen von Hahn, Heckerund Zawinski gipfelten in einem Treffen, das im Herbst 1997 bei Barksdale zu Hause stattfand. Anwesend waren die Mitglieder des Executive Committee und Roberta Katz, die Firmenanwältin von Netscape. Es


------------------------------------------------------------------------------------wurde eine Marathonsitzung, und Open Source war sicher nicht der einzige Punkt auf der Tagesordnung. Obwohl bei diesem Meeting keine formelle Entscheidung getroffen wurde, war es trotzdem sehr wichtig. „Ich glaube, dass die Dinge zwischen Jamie und der Arbeit seiner Gruppe, Frank Heckers Arbeit und diesem Meeting irgendwie übersättigt waren. Bei diesem Meeting gab es Leute, die noch nicht realisiert hatten, was Open Source wirklich bedeutete, und es war unrealistisch zu glauben, dass sie, wo sie das ganze Modell nicht wirklich verstanden oder nicht genau wussten, was es bedeutete, mit einem Schlag ihre Meinung ändern und sagen würden: ,Ja, lasst uns das tun.' Aber ich glaube, die Sitzung brachte uns auf den richtigen Weg, sodass wir in den darauffolgenden Wochen alle irgendwie in Schwung kamen." Barksdales Herangehensweise an eine Entscheidung, die möglicherweise über Leben und Tod des Unternehmens entscheiden würde, ist äußerst bemerkenswert. „Jim spielte nie eine aktive Rolle bei der Festlegung der Strategie", erinnert sich Hahn, „und zwar weder bei der Produktstrategie noch bei der Geschäftsstrategie. Er überließ alles seinen Managern, die darüber brüteten, und er wartete, bis sich eine Gewinnermeinung herauskristallisierte. Dann klemmte er sich dahinter und half der Firma, sie auch wirklich umzusetzen. Mir ist nicht bekannt, dass er zu irgendeinem dieser Themen je eine besonders starke Meinung gehabt hätte. Wenn er sie hatte, artikulierte er sie nie." Barksdale war nicht der Einzige, der sich hinter die Entscheidung klemmte, sobald sie einmal getroffen war. „Es war sehr schwierig, den Schalter umzulegen", erklärt Hahn. „Aber sobald er umgelegt war, gab es keinen Widerstand mehr. Die Firma war zu der Pilgerreise in Richtung Open Source aufgebrochen, und Marc, Jim und Mike Homer und alle anderen - sogar Leute, die am Anfang von der Idee nicht so begeistert waren - waren unterstützend und ermutigend." Obwohl diese „Pilgerreise" enorme positive Auswirkungen auf ein Unternehmen hatte, das angesichts der zunehmenden Erfolge von Microsoft immer deprimierter wurde, ließ sich Hahn von der Begeisterung rund um ihn nicht allzu sehr mitreißen. Er wusste nur


--------------------------------------------------------------------------------------zu gut, was die Firma in Wahrheit tat. Um seine Position anderen gegenüber zu verdeutlichen, pflegte er eine Geschichte zu erzählen: „Zwei Typen gehen campen. Sie sind barfuss, und sie begegnen einem Bären. Der eine Typ bleibt stehen und zieht sich die Schuhe an. Der andere schaut ihn an uns sagt: ,Was machst du denn da? Du kannst doch unmöglich schneller laufen als der Bär.' Und der Erste antwortet: Ich brauche nicht schneller zu laufen als der Bär. Ich brauche nur schneller zu laufen als du."' Hahn erklärt dazu: „Ich glaube, das ist die Sichtweise, die ich in der Frage Open-Source-Strategie und Netscape vertrat. Ich bin mir nicht sicher, ob allen klar war, dass Open Source eine magische, Wunder wirkende Denkweise war. Aber es wandte sich bald niemand mehr dagegen, weil es besser war als das, was wir vorher [auf der Browserseite] gemacht hatten." Er merkt jedoch an, dass Netscape „im Bereich der Server, wo der Quellcode der Produkte ausschließlich geheim gehalten wurde, nie dorthin kam". Hahn sagt auch: „Wir haben es vielleicht noch nicht ganz kapiert, aber das Internet ermutigte uns weiterzumachen. Das war eine ungeheuer starke Kraft." Die positiven Reaktionen aus der Internetgemeinde waren eines von Hahns stärksten Argumenten gewesen, mit denen er dafür eingetreten war, dass Netscape den Communicator zu einem OpenSource-Programm machen sollte. „Eines der im Häresiedokument genannten Motive, ihn als Open Source herauszubringen", sagt er, „war die Beobachtung, dass sich Netscape auf dem Markt immer viel erfolgreicher geschlagen hatte, wenn es von der Allgemeinheit als Underdog im Reich des Bösen wahrgenommen wurde." „Unseren Underdog-Status hatten wir zweifellos eingebüßt. Wir waren arrogant, unangenehm und regelrecht unsensibel gegenüber dem technischen Backbone des Internet gewesen, das eigentlich von vornherein gefunden hatte, dass der Browser eine coole Sache sei. Dieser Schritt diente also im Wesentlichen dazu, uns wieder bescheidener zu präsentieren. Es ging darum kundzutun, dass wir bereit waren, Teamplayer zu sein, und dass wir die Hilfe der Leute brauchten, um den Kampf der Gerechten gegen Microsoft auszufechten. Und das funktionierte ausgezeichnet. Noch am Tag der


------------------------------------------------------------------------------------Ankündigung erhielten wir vom Markt eine Flut von positiver Verstärkung." Die Presseaussendung kam am 2. Januar 1998. Sie begann so: „Die Netscape Communications Corporation kündigte heute den kühnen Plan an, den Quellcode für die nächste Generation ihrer höchst populären Netscape Communicator Client Software zur freien Lizenzierung im Internet zur Verfügung zu stellen. Das Unternehmen plant, den Quellcode ab der ersten Entwicklerversion des Netscape Communicator 5.0, die bis zum Ende des ersten Quartals 1998 veröffentlicht werden soll, freizugeben. Dieser aggressive Schritt wird Netscape in die Lage versetzen, die kreative Kraft Tausender Programmierer im Netz zu nutzen, indem es in zukünftige Versionen der Netscape-Software ihre besten Verbesserungen integriert." Die Presseaussendung enthielt eine Idee, die von den Computerunternehmen bis dahin mit großer Skepsis betrachtet worden war: die Idee des verteilten, globalen Entwicklungsprozesses, der die Quintessenz von GNU/Linux und anderen wichtigen Open-SourceProjekten ist, als ob er die logischste und natürlichste Sache der Welt wäre. Dass sich ein so bekanntes Unternehmen wie Netscape auf diese Weise dazu bekannte, war außergewöhnlich. Es war vollkommen logisch, dass ausgerechnet Netscape diesen Schritt setzte. Das Unternehmen hatte bereits bei seinem ersten Produkt, Netscape 0.9, die Regeln geändert. Indem es einen freien Download anbot, erhoffte es bereits damals, dass die Onlinewelt den Bereinigungsprozess beschleunigen und die Kunde in einem der ersten Beispiele von Viral Marketing verbreiten würde. Die Öffnung des Communicator 5.0 war der nächste logische Schritt: Ein Produkt, das wirklich frei war und bleiben würde, so hoffte man jedenfalls, würde in Partnerschaft mit der gesamten Netzgemeinde entwickelt werden. Die Presseaussendung von Netscape bewerkstelligte all das -zumindest theoretisch. Aber die Entscheidung zu treffen, den Quellcode des Communicator 5 frei zur Verfügung zu stellen, war schon für sich allein schwierig genug; ein funktionierendes Programm zu schaffen - dazu noch eines, das in der Lage war, es


--------------------------------------------------------------------------------------mit dem zunehmend besser werdenden Webbrowser von Microsoft aufzunehmen - war noch schwieriger. Einer der wichtigsten Bereiche, die in Angriff genommen werden mussten, betraf die Lizenz. Die Presseaussendung, in der die Freigabe des Quelkodes angekündigt worden war, hatte versprochen, dass „das Unternehmen die Free Source Distribution mit einer Lizenz versehen wird, die bestimmte Modifikationen am Code sowie die Weiterverteilung erlaubt und für die freie Verfügbarkeit der Quellcodeversionen sorgt. Damit baut sie auf dem Erbe der GNU Public Licencc (GPL) auf, die den Entwicklern im Netz vertraut ist." Netscape hatte ganz richtig verstanden, dass die Open-SourceEntwicklung im Netz nur dann funktioniert, wenn die Lizenzbestimmungen so angelegt waren, dass andere zu Beiträgen ermutigt wurden. Die Heranziehung der GNU General Public Licence, der bis dahin bestbekannte der verschiedenen Lizenzen in diesem Bereich, war ein weiteres Signal für die guten Absichten von Netscape. Eine Lizenz zu wählen, die sowohl den Bedürfnissen von Netscape als auch jenen der Hackergemeinde, deren Hilfe es sich zu sichern versuchte, entsprach, erwies sich jedoch als Herausforderung. Die Frau, die mit dieser Aufgabe betraut wurde, war Mitchell Baker, die damals Rechtsberaterin des Unternehmens war. „Ich nahm an der Sitzung der Netscape-Spitze Teil, bei der es um die Entscheidung ging, ob wir das nun machen sollten oder nicht", erinnert sie sich. Das war im Januar 1998, nur einige wenige Tage vorder öffentlichen Ankündigung. Die Folge war, dass Netscape bereit war, diesen bahnbrechenden Schritt zu tun, jedoch noch ohne zu wissen, welche Form eines der Schlüsselelemente - die Lizenz, unter der der Code veröffentlicht wurde - haben würde. Baker bestätigt das: „Netscape war die logische Wahl für Leute, die in dieser Umgebung komfortabel leben konnten," In die Formulierung der Lizenz band Netscape viele Open-SourceGranden wie Linus, Richard Stallman, Eric Raymond und Bruce Perens ein. Raymond beschreibt das Meeting mit Netscape zu diesem Zeitpunkt als „ungeheuer beeindruckende Erfahrung", weil darin klar wurde, dass sie „wirklich verstanden, worum es ging". Er


------------------------------------------------------------------------------------beschreibt die Leute, die er traf, als „intelligent" und „hip", was die Fragen anbelangte. Am meisten beeindruckte ihn, dass es kein „eitles Posieren" gab, wie er es in einer solchen geschäftlichen Umgebung befürchtet hatte. Die GNU GPL war keine praktische Option. Hätte Netscape Mozilla einfach unter dieser Lizenz herausgebracht, wäre sämtliche Software, die nur mit einem Teil davon in Verbindung gestanden hätte, aufgrund der Funktionsweise der GNU GPL automatisch unter die GPL gefallen. Das hätten weder Netscape noch Dritte akzeptieren können. Am Ende wurden zwei neue Lizenzen erstellt, die Netscape Public Licence (NPL) und die Mozilla Public Licence (MPL). Mozilla war nun zum offiziellen Namen des neuen Projekts gemacht worden, wie eine weitere Presseaussendung vom 23. Februar 1998 erklärte: „Die Netscape Communications Corporation hat heute die Gründung von Mozilla.org bekannt gegeben. Dabei handelt es sich um ein spezielles Team innerhalb von Netscape mit einer zugehörigen Website, dessen Aufgabe es sein wird, den offenen Dialog und die Entwicklung des Client Source Code von Netscape zu fördern, voranzutreiben und zu leiten." Jamie Zawinski erinnert sich: „Meine erste Reaktion, ein paar Stunden nachdem ich die Ankündigung [den Quellcode von Communicator 5 zu öffnen] gehört hatte, bestand darin, die Domain mozilla.org registrieren zu lassen." Die Entwicklung einer eigenen Identität für das Projekt war ein wichtiger Schritt, um potenziellen Entwicklern die Sicherheit zu geben, dass es sich hier nicht um ein reines Schaufenster handelte und dass Mozilla wirklich unabhängig sein würde. Es war auch logisch, dass für diese Rückkehr zu den Wurzeln von Netscape der Originalname des Codierers gewählt wurde. Trotz der Komplikation, die sie verursachten, waren zwei Lizenzen notwendig, um ein unentwirrbares rechtliches Problem zu lösen. Ein Teil des Codes des Communicator wurde von Netscape anderswo verwendet, und ein Teil war auch an Dritte lizenziert worden. Die Netscape Public Licence wurde für die Programmierung von Netscape verwendet und war in vielerlei Hinsicht GPL-ähnlich. Sie verlieh dem Unternehmen aber spezielle Rechte, die es


--------------------------------------------------------------------------------------gestatteten, den Code Dritten bereitzustellen, ohne seine GPL-artigen Eigenschaften weiterzugeben. Sie versetzte Netscape auch in die Lage, den ursprünglichen Communicator-Quellcode in andere Produkte einzufügen, die zwei Jahre lang nicht den Open-Source-Vorschriften unterliegen würden. Durch neu geschaffene Newsgroups, die für alle für die Diskussion über Lizenzierung und andere Fragen geöffnet wurden - wieder ein Pionierschritt für ein Softwareunternehmen -, versuchte Netscape den potenziellen Beitragenden zu erklären, warum es Sonderrechte beanspruchen musste. „Wir hatten eine Diskussion in den Newsgroups", erinnert sich Baker, „und wir erklärten, o.k., das ist der Grund, warum diese Rechte bei NPL-Sachen wichtig sind und warum wir glauben, dass wir sie haben müssen." „Und viele Leute sagten, gut, ich verstehe das irgendwie für den Code, den ihr da freigebt, erinnert sie sich. „Und wenn ich einen Fix für einen Bug schreibe oder irgendeinen anderen kleinen Beitrag zu dem Code leiste, dann ist es vielleicht in Ordnung, wenn Ihr Sonderrechte an einem bestimmten Element meiner Arbeit habt. Es gefällt mir zwar nicht, aber ich kann es irgendwie verstehen. Aber wenn ich jemals irgendetwas Wichtiges mache, was neu für mich ist und was ich zu eurem Projekt beitragen will, werde ich das auf keinen Fall unter der Netscape Public Licence tun." „Das machte also Sinn", fährt Baker fort. „Deshalb fingen wir noch einmal von vorn an und sagten: ,O.k., wir glauben, dass wir für die Dinge, die wir freigeben, die Netscape Public Licence brauchen, aber wir werden die Mozilla Public Licence entwickeln, die genau identisch ist, außer dass sie keine Sonderrechte vorsieht. Und wenn ihr Code zu unserem Projekt beitragen wollt - und wir hoffen, dass ihr das wollt -, gibt es da eine Lizenz, die Netscape keinerlei Sonderrechte zuerkennt.‘ Das schien das Problem in den Augen der meisten Leute zu lösen." Netscape entwickelte die NPL, die eng mit GPL verwandt ist, weil „wir letzten Endes zu dem Schluss kamen, dass wir eine Lizenz haben sollten, die die Gemeinschaft förderte", erklärt Baker. Das zeigte nicht nur, wie genau sich Netscape des Prozesses bewusst war, den es da zu nutzen versuchte, sondern auch die wichtige Funktion, die der Gemeinschaft in der Open-Source-Bewegung


------------------------------------------------------------------------------------zukommt. Außerdem zeigte sich, wie Recht Stallman damit gehabt hatte, von Anfang an auf diesem Element zu bestehen. Trotz dieser Lizenzen konnte Netscape nicht den gesamten Code freigeben, den es von Dritten lizenziert hatte. Wenn der Eigentümer nicht bereitwillig akzeptierte, dass er als Open Source veröffentlicht wurde, musste dieser Code aus Mozilla entfernt werden. Das hinterließ natürlich beträchtliche Lücken. Im Netscape FAQ (Frequently Asked Questions)-Teil über den Quellcode von Mozilla wurde erklärt: „Diese Version beinhaltet nicht den Quellcode von Version 5.0 der Messenger-, Collabra- oder Calendar-Komponenten des Communicators. Sie beinhaltet auch nicht den Quellcode Dritter, die nicht bereit waren, der Veröffentlichung ihres Quellcodes gemäß den Bestimmungen der Netscape Public Licence zuzustimmen (wie zum Beispiel Java). Darüber hinaus enthält der Quellcode keine Elemente, deren Export gemäß US-Gesetz illegal ist (wie Versehlüsselungsquellcode)." Das waren wichtige Elemente, die herausgenommen worden waren. Der Messenger beinhaltete alle E-Mail-Funktionen, und Collabra wurde für das Lesen von Newsgroups verwendet. Die Folge war, dass die ursprüngliche Version des Mozilla-Codes am 31. März 1998 überall dort, wo Funktionen herausgerissen worden waren, klaffende Löcher aufwies. Das dämpfte die Begeisterung bei einer Veranstaltung am nächsten Tag, die „Mozilla Dot Party" genannt wurde und deren Motto „Lasst die Eidechse los" lautete, keineswegs. Die Party war von Zawinski eigenständig organisiert worden, und er übernahm auch einen großen Teil der Kosten. Der Eintritt war frei. Sie fand in der Sound Factory, einem der größten Nachtclubs von San Francisco, statt. Zu den DJs der Nacht zählte unter anderem Brian Behlendorf, der eine wichtige Figur der Rave-Musikszene und ein wichtiger Akteur in der Apache Group war. Eine weitere Ikone der Open-Source-Bewegung, Eric Raymond, war ebenfalls anwesend, und er gesellte sich in der zweiten Spielzeit der Kofy Brown Band, die für die Veranstaltung engagiert worden war, sogar mit seiner Flöte zu der Gruppe, Wie der Freeware Summit der nicht einmal eine Woche später, am 7. April 1998, stattfinden sollte, war die Mozilla Dot Party


--------------------------------------------------------------------------------------ebenfalls eine Zusammenkunft der verschiedenen Open-SourceGruppen von hohem symbolischem Wert. Aber wo der Freeware Summit ein Treffen der Clanchefs war, nahmen an der Moziall Dot Party auch die unteren Reihen Teil. „Open Source, Open Party", lautete das Motto, das Zawinski in seinem FAQ zur Mozilla Dot Party gepostet hatte. Wie der Freeware Summit wurde auch die Party mit nützlichen Presseberichten über das bedacht, was zunehmend als Bewegung wahrgenommen wurde. Am 16. April 1998 gab Netscape eine Presseaussendung heraus, in der Tom Paquin, ein Netscape-Angehöriger, der mozilla.org managte, wie folgt zitiert wird: „Seit Netscape den Quellcode seines Communicator 5.0 vor zwei Wochen über mozilla.org veröffentlicht hat, haben wir überwältigende positive und zustimmende Reaktionen von den Entwicklern rund um die Welt erhalten." Er nannte einige statistische Zahlen: „Bis heute wurden über 100.000 Downloads des Quellcodes von mozilla.org allein verzeichnet, und geschätzte 100.000 Downloads auf den über hundert gespiegelten Sites rund um die Welt. Darüber hinaus wurde schon vierundzwanzig Stunden nach der Freigabe des Codes am 31. März die erste Änderung von einem Entwickler an mozilla.org geschickt." Die Presseaussendung erwähnte auch die Spende eines Softwareelements, das für die eXtensible Markup Language (XML), eine Art verallgemeinerter Version der HTML-Sprache des Web, die sich seit der Einführung des Web rasch als wichtigste Internettechnologie etablierte, von entscheidender Bedeutung war. James Clark, der technische Kopf der XML Hauptarbeitsgruppe, hatte sein ExpatProgramm für das Mozilla-Projekt zur Verfügung gestellt. Damit wurde nicht nur eine wesentliche Verbesserung der Funktionen erreicht, sondern es war auch ein Publicity-Coup. Ein weiterer folgte nur wenige Stunden nach der Veröffentlichung des Quellcodes. Eine in Australien und Großbritannien beheimatete Gruppe namens Cryptozilla hatte die Verschlüsselungselemente, zu deren Entfernung Netscape aufgrund der US-Exportgesetze gezwungen war, wieder eingefügt. Das schien wie eine Rechtfertigung der Prognosen der Open Source Community, dass sich die Codiererreihen rund um die Welt geschlossen erheben und die Löcher füllen würden. Cryptozillas Bravourstück „war


------------------------------------------------------------------------------------eigentlich keine Überraschung", sagt Paquin. „Es war sonnenklar, dass es auch ohne den Code überhaupt nicht schwer sein würde, das Loch zu stopfen." Am 15. Mai 1998 skizzierte Brendan Eich, der für die architektonische und technische Richtung von Mozilla verantwortlich war, etwas, was er das Mozilla Stabilisierungsprogramm nannte - eine Art Roadmap (Plan, wie die zukünftige Entwicklung aussehen soll) für Mozilla. Er nannte den 1. September 1998 als das Datum, an dem „keine Features mehr hereinkommen und die aggressive Stabilisierung beginnt", um den Code in den richtigen Zustand für die Veröffentlichung als Produkt zu bringen. Am 26. Oktober 1998 postete Eich jedoch einen neuen Entwicklungsplan, der eine radikale Änderung ankündigte. Anstatt eine wichtige Browserkomponente namens Layout Engine von der aktuellen Netscape-Entwicklung zu nehmen - den Code, der HTML verarbeitet und es auf dem Bildschirm des Benutzers anzeigt -, warfen sie sie weg und begannen von Grund auf mit etwas, was Eich NGLayout (Next Generation Layout) und später „Gecko" nannte. Wie er erklärte, war er aufgrund seiner Position als „technisches mozilla.org-Genie" unter Berücksichtigung „der Meinung der Moduleigentümer" - der MozillaLeutnants - und, was am wichtigsten war, „der brennenden Wünsche der Autoren der Webinhalte", wie Eich es ausdrückte, zu dieser Entscheidung gekommen. In erster Linie wollten die Web-Content-Autoren, dass die Standards eingehalten würden, die das World Wide Web Consortium (W3C) - die unabhängige Körperschaft unter der Leitung von Tim Berners-Lee - im Lauf der letzten drei Jahre ausgearbeitet hatte. Diese Standards beinhalteten Dinge wie Cascading Style Sheets, das eine saubere und konzeptuell einfache Konstruktion komplexer Webseitendesigns ermöglichte, und Document Object Model (DOM), im Wesentlichen eine Methode, die auf einer Webseite Dinge wie den Zugriff und die Manipulation von Überschriften, Tabellen etc. zuließ, als würde es sich um separate Elemente handeln. Alle diese Standards waren gut definiert, und ihre Vorteile waren allgemein akzeptiert. Aber Netscape und Microsoft boten nur eine teilweise Unterstützung für die W3C-Standards, und in gewisser


--------------------------------------------------------------------------------------Weise war dies eine unglückliche Folge der Browserkriege. Das bedeutete, dass eine Webseite, die sich an Standards hielt, anders aussehen würde, manchmal sogar vollkommen anders, je nachdem ob sie mit dem Browser von Microsoft oder dem von Netscape betrachtet wurde. Das war ein Albtraum für die Webdesigner und widersprach allem, wonach Berners-Lee in seiner Arbeit für das Web strebte. Die Webbenutzer hatten schon vorher die Einhaltung von Webstandards gefordert, aber dies Mal war etwas anders. Mit der Öffnung der Mozilla-Entwicklung hatte Netscape auch den Entscheidungsfindungsprozess geöffnet. „So soll es sein", erklärt Hecker. „Wenn man andere Leute einlädt, am eigenen Entwick-lungsprozess teilzunehmen, muss man damit rechnen, dass sie eigene Meinungen haben, die nicht unbedingt mit der eigenen Überzeugung übereinstimmen." Im Fall von Mozilla, so Hecker, „waren viele der Beteiligten der Meinung, dass es nicht das Richtige sei, einfach nur ein Produkt zu liefern." Stattdessen meinten sie, „es sei ein besseres Ziel, ein Produkt zu liefern, das auf neuem Code basierte, der zur Gänze den Standards entsprechen konnte" Ein Mann, den die Entscheidung, neuen Code zu schreiben, nicht überraschte, war Eric Hahn. „Ich bin Programmierer", sagt er. „Beim Schreiben der Häresiedokumente bestand mein Entschei-dungsprozess zum Teil darin, dass ich den gesamten Quellcode [für den Communicator] auf meiner Maschine speicherte und ihn kompilierte, damit herumspielte und ihn mir ansah. Ich lebe heutzutage nicht mehr vom Codieren, aber natürlich kann ich noch Quellcode lesen. Und ich sah ihn mir an und sagte, das wird eine bittere Pille sein, die wir da schlucken müssen." Er erklärt auch, warum die alte Layout Engine nicht einfach so angepasst werden konnte, dass sie mit den Standards voll kompatibel war „Netscape traf eine Menge technischer und Codierungsentscheidungen, die sehr kurzsichtig waren", sagt er. „Und sie waren kumulativ. Es lag nicht daran, dass die Techniker nicht klug gewesen wären oder so oder dass sie schlechte Programmierer waren." Das Problem war etwas viel Grundsätzlicheres. „Die Kultur verlangte es, so vieles in einem unglaublich rohen Zustand


------------------------------------------------------------------------------------auszuliefern - und später kam man dann nie mehr dazu, die Fehler zu beheben." Die Entscheidung, nur etwas mehr als sechs Monate nach der Veröffentlichung riesige Brocken des Codes neu zu schreiben, war ein enormer Schlag für viele Mitglieder der Mozilla-Gemeinde. Das bedeutete nicht nur, über ein halbes Jahr Arbeit einfach wegzuwerfen, sondern es bedeutete auch unweigerlich, dass monatelang kein Produkt ausgeliefert werden konnte. Für einige Personen war das inakzeptabel. Die stimmgewaltigste unter ihnen war Jamie Zawinski. Zawinski hatte sich wegen der Übernahme von Netscape durch den Onlineriesen AOL, die am 24. November 1998 bekannt gegeben worden war, bereits Sorgen gemacht. Er betrachtete sie als weiteren Schritt in Richtung jener Art von seelenlosem Unternehmen, der er nicht angehören wollte. Er hatte wieder einmal einen seiner deutlichen und ausdrucksstarken Artikel für die mozilla.org-Site verfasst, diesmal mit dem Titel „Angst und Verbitterung auf dem Weg zur Fusion". Dieser Artikel hatte einen positiven Effekt: Er entlockte Steve Case, dem Gründer und CEO von AOL, eine E-Mail, in der er betonte: „Wir unterstützen mozilla.org mit ganzer Kraft." Trotz Cases Beschwichtigungsversuch wuchs Zawinskis Unruhe immer stärker, je weiter das Lancierungsdatum eines Produkts auf Mozillabasis in die Ferne rückte. Am Ende erwies sich die Symbolik des Datums 31. März 1999, des ersten Jahrestags der Freigabe des Mozilla-Codes, als zu stark, und Zawinski postete auf seiner persönlichen Website einen seiner bislang besten und leidenschaftlichsten Essays mit dem Titel: „Resignation und Nachruf." Er beginnt so: „Der 1. April 1999 wird mein letzter Arbeitstag bei der Netscape Communications Division von America Online sein, und mein letzter Arbeitstag bei mozilla.org." Er weist auf den seiner Meinung nach größten Fehler von mozilla.org hin: „Das Projekt wurde von der Außenwelt nicht akzeptiert ... In Wahrheit gehörte das Projekt angesichts der Tatsache, dass jene, die einen Beitrag zum MozillaProjekt leisteten, etwa hundert Vollzeit-Netscape-Entwickler und etwa dreißig Teilzeit-Außenseiter waren, immer noch zur Gänze Netscape. Schließlich können nur jene, die den Code schreiben, das Projekt wirklich kontrollieren."


--------------------------------------------------------------------------------------Zawinski weist auch auf die zweifellos größte Leistung von Mozilla hin. „Einfach indem wir waren, wer wir waren, und indem wir taten, was wir taten, leisteten wir einen großen Beitrag zu dem Projekt, das ganze Open-Source-Entwicklungsmodell der Welt nahe zu bringen. Es waren nicht wir, die das Interesse der Mainstream-Medien an Open Source anfachten (das war in erster Linie Linux), aber ich glaube, dass wir Open Source in den Augen vieler legitimierten und dass wir die Geschichte sehr gut erzählten. Die Tatsache, dass diese Softwareentwicklungsstrategie unter dem Namen Netscape verwirklicht wurde, machte viele Leute auf sie aufmerksam, die sie sonst vielleicht nicht zur Kenntnis genommen hätten." Aber das war für Zawinski nicht genug. „Für mich ist die Auslieferung das Entscheidende", merkte er in seinem Rücktrittsschreiben, „Vielleicht waren meine Ziele unvernünftig; vielleicht hätte mir, als wir dieses Projekt in Angriff nahmen, klar sein müssen, dass wir viel länger als ein Jahr brauchen würden, um diese Ziele zu erreichen, falls es uns überhaupt je gelänge. Aber das war mir damals nicht klar." Da diese Dinge sowohl für Hahn als auch für Hecker offensichtlich waren, stellte sich die Frage, warum Zawinski trotz der offenkundigen riesigen Softwarelöcher und der, wie Hahn sagt, „störrischen" Natur eines Großteils des verbleibenden Codes an seinen „unvernünftigen" Zielen festhielt. Die Antwort liegt wahrscheinlich im kulturellen Unterschied zwischen dem Codieren in der kommerziellen Welt und dem Codieren in der Open-Source-Welt. Zawinskis Tagebuch aus der Zeit vor dem Launch von Netscape, als er verrückte Dreißig-, Vierzig-Stunden-Schichten hinlegte, ist durchdrungen von dem elektrischen Gefühl der surrealen Atmosphäre, die in der Firma herrschte. Es vermittelt sehr gut, wie faszinierend es für ihn war, im Mittelpunkt dieses ganzen verrückten Unterfangens zu stehen. Zawinski beschrieb seine Einstellung zu GNU/Linux in bemerkenswerter Weise als „Hassliebe ohne Liebe", und wahrscheinlich könnte man seine Gefühle über die kommerziellen Entwicklungszyklen in ähnlicher Weise als „Hassliebe ohne Hass" beschreiben.


------------------------------------------------------------------------------------Mozilla und damit auch die anderen großen Open-Source-Projekte funktionierten nicht so. Das verteilte Entwicklungsmodell bedeutet, dass große Fortschritte in kurzer Zeit erzielt werden können, dass sie normalerweise aber konzentriert in Schüben erfolgen. Man hat nicht das Gefühl einer Frist, wie es bei der Entwicklung kommerzieller Software immer vorhanden ist. Der ständige Druck, rechtzeitig zu liefern, entfällt, und die oft langen Zeiträume zwischen zwei großen Linux-Versionen zeigen es: Der Übergang von Version 2.0 zu Version 2.2 dauerte mehr als zweieinhalb Jahre. Mozilla scheiterte nicht an realistischen Kriterien. Es fehlte einfach eines der Schlüsselelemente, die Zawinski zu einem so guten Programmierer machten: die Dringlichkeit, die entsteht wenn man im Kampf gegen die Uhr codiert. Rückblickend gibt Zawinski zu: „Ich war es gewöhnt, schnell zu arbeiten. Netscape arbeitete immer schnell. Mozilla.org nicht. Ich fühlte mich bald ausgebrannt und ineffektiv", sagt er. Zawinskis großes Lamento im Web macht das Paradoxon deutlich, das im Zentrum des Open-Source-Prozesses steht. Open Source gilt zu Recht als etwas, was bei den Beteiligten viel Begeisterung auslöst Aber diese Begeisterung hat eine ganz andere Qualität als das Motto „um jeden Preis die Frist einhalten", das in der Welt der geschützten Software mit ihrem enormen Wettbewerbsdruck gang und gäbe ist. Die kreative Begeisterung, die für Open Source typisch ist, ist nachhaltiger, wenn auch vielleicht weniger extrem. Der Aufstieg und letztendliche Fall von Netscape sind zum Teil ein Sinnbild des Versagens des kommerziellen Codierungsmodells und ein Hinweis auf die grundlegenden Schwächen anderer Unternehmen, die dabei bleiben. Wie Hahn sagt: „In der lnternetzeit" - an deren Definition Netscape maßgeblich beteiligt war -„hatten wir nie Zeit, um etwas sorgfältig zu überarbeiten. In ähnlicher Weise waren es kommerzielle und nicht technische Überlegungen, die dazu führten, dass die Standards auf sehr selektive Weise, wenn überhaupt befolgt wurden. Deshalb ist es vollkommen logisch, dass Mozilla, der spirituelle Erbe sowohl des offenen Mosaic-Browsers als auch des geschlossenen NetscapeBrowsers, der immer stärker von der Netzgemeinde, aus der heraus


--------------------------------------------------------------------------------------er entstanden war, beeinflusst wurde, der erste Browser war, der die wichtigsten Webstandards uneingeschränkt unterstützte." Zawinski schließt seinen Rücktrittsessay wie folgt: „Meine größte Angst und mit ein Grund dafür, dass ich so lange durchhielt besteht darin, dass die Leute die Mängel von mozilla.org auf die Open-Source-Bewegung im Allgemeinen übertragen. Lassen Sie mich Ihnen versichern, dass Mozilla alle Probleme, mit denen es möglicherweise behaftet ist, nicht deshalb hat, weil Open Source nicht funktioniert. Open Source funktioniert, aber es ist auf keinen Fall ein Allheilmittel Wenn hier ein Warnhinweis anzubringen ist, dann der, dass es nutzlos ist ein todgeweihtes Projekt mit dem Zaubermittel „Open Source" zu besprengen. Da löst sich nichls auf wundersame Weise. Die Software ist ein schwieriger Bereich. Die Probleme sind nicht so einfach zu lösen." Seine Erkenntnis, dass Open Source kein „Allheilmittel" ist, hat sich sicherlich als zutreffend erwiesen, aber seine Sorgen bezüglich der möglichen Auswirkungen auf das angebliche Versagen von Mozilla erwiesen sich als unbegründet. Die unentrinnbare Logik, die NetscapeAngehörige aus drei Bereichen - Zawinski im Engineering, Hecker im Verkauf und Hahn im Management - dazu gebracht hatte, auf das hinzuarbeiten, was später Mozilla werden sollte, war 1998 bereits in anderen großen Computerunternehmen zu spüren. Die Bekanntgabe ihrer Unterstützung würde den Aufstieg von Open Source nicht nur unübersehbar, sondern auch unaufhaltsam machen.

(Leerseite)

12

Ein fester Stand

DlE ANKÜNDIGUNG VON NETSCAPE IM JANUAR 1998, sein Flaggschiffprodukt, den Communicator, als Open-Source-Produkt herauszubringen, hätte für sich allein nicht ausgereicht, die Unternehmen von der Glaubwürdigkeit der freien Softwareprogramme zu überzeugen. Der Schritt war so radikal und gewagt, dass er für viele Beobachter den Beigeschmack der Verzweiflung hatte. Ihrer Meinung nach war Mozilla kein Beweis für die Brauchbarkeit des Open-SourceAnsatzes, sondern die letzte Zuflucht eines Unternehmens, dem keine andere Wahl mehr blieb. Das dramatische Experiment von Netscape mochte die Geschäftswelt auf Open Source aufmerksam gemacht haben, aber erst die Unterstützung einer etablierteren und konservativeren Computerfirma würde es zu einer glaubwürdigen Option machen. Diese Unterstützung kam, und zwar auf die eindeutigste Weise, von einem der renommiertesten Blue-Chip-Unternehmen der Welt: IBM


------------------------------------------------------------------------------------gab am 22. Juni 1998 bekannt, mit dem IBM WebSphere Application Server, einer Schlüsselkomponente der WebSphere-Produktfamilie des Unternehmens, den Apache Web Server auszuliefern. Für die freie Software sollte „kommerzielle Unterstützung auf Unternehmensebene" angeboten werden. Für Eric Hahn, damals CTO von Netscape, war dieser kühne Schritt deprimierend. Es war, so sagte er, „ein schwarzer Tag für mich bei Netscape". Bin paar Monate davor, im letzten seiner Häresiedokumente, hatte er den schockierenden Vorschlag gemacht, „den Netscape Enterprise [Web-]Server auslaufen zu lassen und auf einen ApacheKern umzusteigen. Alles, von dem wir dachten, dass es auf geheimer Soße basierte, hätten wir dann auf Apaehe aufbauen können." „Als IBM diese Presseaussendung herausgab", fährt er fort, „erkannte ich, dass IBM, diese riesige, notorisch langsame Firma, das Ganze schneller kapiert hatte als Netscape." Das zeigte, dass er selbst daran gescheitert war, Netscape so umzumodeln, dass es so schnell wie IBM erkannte, „wo es langging", abgesehen vom Mozilla-Experiment. Die IBM-Entscheidung war sicher der wichtigste Auftrieb, auf den die Befürworter freier Software gehofft haben konnten. Mit einem Schlag wurde damit ein Open-Souree-Programm auf die gleiche Ebene wie kommerzielle Software gehoben und so offiziell im Unternehmen verankert. Auch der frühere Schritt von Netscape verwandelte sich damit rückblickend von einem allein stehenden Schritt eines tollwütigen Unternehmens in eine vorausblickende Vorwegnahme des kommenden Trends. Nun hatte jedes Softwarehaus, das GNU/Linux oder eine andere Open-Source-Software unterstützen wollte, guten Grund, das zu tun. Einer der wichtigsten Akteure in dieser Geschichte war James Barry. Barry war kein langjähriger IBM-Mitarbeiter. Bevor er in die Firma eingetreten war, hatte er seine eigene Firma, das Start-up-Unternehmen ResNova, an Microsoft verkauft. Das ResNova-Team hatte den Großteil des wichtigsten Microsoft Webserver-Produkts für Windows NT, den Internet Information Server (IIS) und den Personal Web Server für Windows 95 geschrieben. Da Barry von

12. Ein fester Stand

--------------------------------------------------------------------------------------außerhalb kam, hatte er bessere Möglichkeiten, kühne neue Ideen vorzuschlagen. „Man hatte mich geholt, um einen Blick auf die Webserverreihe von IBM zu werfen", erklärt Barry. Das Problem dort war, dass „IBM zum damaligen Zeitpunkt vierzig oder fünfzig verschiedene Produkte hatte", sagt er. „Man hat eine Commerce Suite, man hat Zahlungssuiten, man hat Geschäftskataloge und man hat Dinge, die [Webserver]logs interpretieren und einem sagen, woher die Besucher kommen, Dinge, die mit Großrechnern verbunden sind. Und das waren alles separate Softwareelemente auf Serverseite." „Also verfasste ich einen Bericht, in dem im Grunde stand, dass es da einige Projekte gibt, die keinen Sinn machten. Viele davon taten fast das Gleiche, aber sie liefen unter anderen Marken." Barrys erster Bericht, der im Dezember 1997 herauskam, enthielt den Vorschlag, dass er alles, was er behalten wollte, unter einer neuen Produktlinie namens WebSpere herausbringen wollte. Im Zuge seiner Analysen hatte er noch etwas anderes erkannt: „Was passiert als Erstes, wenn die Leute eine Website besuchen? Der Server stellt ihnen eine Webseite bereit", erklärt er. Dazu brauchte man einen Webserver, und IBM hatte einen. „Als ich zu arbeiten begann, gab es den Internet Connection Server, 1CS, wie wir ihn nannten", erinnert sich Barry. „Und dann wurde der Markenname Domino Go festgelegt." Der Webserver-Ansatz von IBM, alles allein zu machen, brachte ein großes Problem mit sich: „Wir hatten so um die 0,2 Prozent von einem Prozent Marktanteil", sagt Barry. „Im Grunde konzentrierten sich 90 Prozent des Marktes auf drei Webserver" - die von Microsoft, Netscape und Apache. Ein zu vernachlässigender Marktanteil bedeutete, dass es schwierig - und teuer - sein würde, Personal zu finden, das für IBMLösungen geschult war. Das bedeutete wiederum, dass das breitere Webangebot von IBM, das sich zur WebSphere-Produktlinie entwickelte, angesichts der Konkurrenzlösungen, die auf populäreren Webservern basierten, schwer zu verkaufen sein würde. Daraus zog Barry den logischen Schluss: „Der Bericht kam zurück mit dem Vermerk, dass wir uns an einen der von den drei Marktführern angebotenen Webserver anhängen müssten. Also


------------------------------------------------------------------------------------sahen wir uns die drei Möglichkeiten näher an", erzählt er. „Als Erstes war Netscape an der Reihe. IBM sprach mit ihnen über eine Übernahme, aber die kam aus mehreren Gründen nicht zustande. Microsoft - ein bisschen teuer zu kaufen. Also blieb nur Apache übrig." Dieselbe unausweichliche Logik, die Hahn und andere zu dem Schluss geführt hatten, dass Netscape den Communicator zu einem OpenSource-Produkt machen sollte, hatte auch Barry zu einer Erkenntnis gebracht, die etwas ebenso Revolutionäres nach sich zog: dass IBM die Entwicklung seines eigenen Webservers fallen ließ und Apache übernahm. Das überstieg die Vorstellungskraft vieler IBM-Angehöriger. Das war ein Problem, weil IBM, wie Barry erklärt, „sehr konsensorientiert ist, wenn es um politische Veränderungen geht. Wenn es weiter unten in der Hackordnung jemanden gibt, der von der Entscheidung betroffen ist, sagen sie: ,Nein, das geht erst dann, wenn der Betreffende seine Zustimmung gibt.“ Barry blieb stecken. Er versuchte ein zweites Mal, seine Idee durchzusetzen, aber erfolgreich war er erst beim dritten Mal zum Teil deshalb, weil er sich mit einem IBM-Angehörigen zusammengetan hatte, der von sich aus zu der Überzeugung gelangt war, dass Apache der Weg der Zukunft war - und der genauso hartnäckig war wie Barry. Sein Name war Yen-Ping Shan. Über die Qualitäten, die seiner Meinung nach notwendig waren, um bei IBM einen Durchbruch zu erreichen, sagte er: „Man braucht eine sehr dicke Haut, vor allem im Rücken. Man muss die Schläge einstecken und einfach weitermachen. Am besten, man konzentriert sich auf die Sache und auf das, was für die Firma und für die größere Allgemeinheit gut ist. Die Hiebe sollte man ignorieren, so gut es geht." Shan erklärt, wie seine Beteiligung am Apache-Projekt zustande kam. „Anfang 98“, so erzählt er, „arbeitete ich an der E-Business-Strategie von IBM, und später übernahm ich die Hauptverantwortung für die Architektur der E-Business-Tools. Angesichts der allgemeinen Situation erkannte ich, dass wir dringend einen größeren Marktanteil im Webserverbereich brauchten, wenn wir wollten, dass der ganze Bereich erfolgreich werden sollte." Das war dieselbe Erkenntnis, die Barry gehabt hatte. Shan merkt an: „Natürlich ist das keine einzigartige Erkenntnis. Vor mir waren


--------------------------------------------------------------------------------------schon viele zu diesem Schluss gekommen, und sie hatten sogar ein paar Mal probiert, Apache zu pushen, aber keiner von ihnen hatte Erfolg." Barry dazu: „Shan war derjenige, der dafür sorgte, dass sich die Idee im IBM-Prozess durchsetzte." Shan stimmt dem zu, bescheiden, wie er ist, verweist er aber auch auf die Rolle anderer, „ich glaube, ich war derjenige, der herausfand, wie es gehen konnte. Aber ich hatte viel Unterstützung von Freunden, und gemeinsam gelang es uns, den Bürokratiekoloss von IBM in Bewegung zu setzen. IBM ist ja wie ein großer Elefant", sagt Shan. „Sehr schwer in Bewegung zu bringen. Wenn man es aber einmal geschafft hat ihn in die richtige Richtung zu drehen und in Gang zu setzen, lässt er sich nur sehr schwer aufhalten. Bei IBM kursiert deshalb der Scherz, dass es nur zehn Prozent der Arbeit ist, herauszufinden, was das Richtige ist, und 90 Prozent, herauszufinden, wie man den Hebel an die Bürokratie am besten ansetzt." Shan erklärt seinen Ansatz. „Zuerst... ging ich herum und fragte die Leute, was sie taten und warum sie bei ihren früheren Versuchen, Apache zu adaptieren, gescheitert waren." Offensichtlich hatten es vor Barrys eigenen erfolglosen Versuchen schon andere probiert. „Dabei stellte sich heraus, dass alles mit dem Timing zu tun hatte und auch mit den Beteiligten, über die man sich einigen muss. Man braucht Übereinstimmung zwischen Marketing-, Rechts- und Entwicklungsabteilung. Wenn die nicht vorhanden ist, kommt man nirgendwo hin." „Also begann ich im Februar dieses Jahres, mir die Situation anzusehen, und ich kam zu der Erkenntnis, dass wir die Chance hatten, das durchzudrücken", erzählt er. Vertraulichkeit war oberste Priorität. „Stellen Sie sich vor ... Sie haben ein Team von sechzig, siebzig Entwicklern, die im Labor an einem Produkt arbeiten", sagt Shan. „Und da kommen Sie und suchen nach Möglichkeiten, das Produkt zu killen und Open Sourcc einzuführen. Wenn sich diese Nachricht verbreitet, gibt es eine Flut von Kündigungen. Man kann sich vorstellen, wie schwer es ist, die Entwickler davon zu überzeugen, dass das das Richtige ist." Nicht nur das: „Man will schließlich, dass die Entwickler hinter der Sache stehen. Man will, dass sie Open Source akzeptieren und als etwas Positives betrach-


------------------------------------------------------------------------------------ten, und man will, dass sie einen Beitrag zur Open-Source-Bewegung leisten", erklärt Shan. Wenn das nicht gelänge, würde der ganze Vorstoß vergeblich sein. Er erinnert sich, gedacht zu haben: „Wenn man die Entwickler überzeugen muss, muss man auch ihre Vorgesetzten überzeugen. Also holte ich mir zwei von ihnen und bat sie, mir beim Analysieren von Apache zu helfen." „Ich bat sie, zu vergleichen und die Elemente gegenüberzustellen", erinnert sich Shan. „Als sie sich richtig hineingearbeitet hatten, waren sie von der Eleganz der Architektur ganz überrascht. Natürlich dauerte es eine Zeit lang, bis sie offener geworden waren und die Dinge in ihrem größeren Zusammenhang sehen konnten. Aber sie taten es. So erkannte ich, dass die Sache aus technologischer Sicht durchführbar war und dass wir der Marketing- und der Rechtsabteilung ein bisschen Dampf machen mussten." Die Marketing- und die Rechtsabteilung wurden von Barry geleitet. Er und Shan hatten schon früher zusammengearbeitet. „Ich traf ihn bei verschiedenen Meetings", sagt Shan, „und ich dachte mir immer, das ist ein Typ, der viel weiß, und der sagt, was er denkt und der zu seiner Meinung steht. Und er seinerseits hatte großen Respekt vor meinen Entwicklern." Barry und er verbrachten viel Zeit mit dem Apache-Projekt, indem sie die verschiedenen IBM-Abteilungen abklapperten und versuchten, Akzeptanz für die Idee zu finden. Barry wurde nicht müde, allen IBMAngehörigen zu erklären: „Wir können das Ganze nicht halbherzig anpacken. Wir können nicht einfach hingehen und sagen, so, nun übernehmen wir Apache, aber unseren Webserver behalten wir. Wir sagten also, dass Apache auf allen Systemen laufen würde." „Bei IBM gibt es wahrscheinlich mehr VIPs als andere Firmen Mitarbeiter haben. Es ging also darum, die Sache richtig zu verkaufen", erklärt Barry. Er war für die Aufgabe gut geeignet. „Ich hatte schon in einigen Unternehmen Erfahrung in der Führungsetage gesammelt, deshalb wusste ich, wie man mit solchen Leuten spricht", erklärt er. Seine Gesprächspartner waren mitunter sehr hochrangig. Ein Beispiel war Steve Mills, der Geschäftsführer der Softwaregruppe war. Mills war John M. Thompson unterstellt,


--------------------------------------------------------------------------------------der Senior Vice President war. Möglicherweise wurden noch größere Kaliber einbezogen. Barry glaubt, dass Thompson die Sache an Lou Gerstner herantrug, den Vorsitzenden und CEO von IBM. Aber die wichtigste Person war Mills: „Sobald Steve Mills und seine Leute davon überzeugt waren, dass wir auf Apache umsteigen mussten", sagt Barry", „war das Rennen im Großen und Ganzen gelaufen." An diesem Punkt, Mitte März 1998, wurden Barry und Shan ermächtigt, den Kontakt zur Apache Group herzustellen. Sie setzten sich mit Brian Behlendorf in Verbindung. Er hatte seinen Job bei HotWired verlassen, wo er den offiziellen Titel „Unix-Sherpa" getragen hatte. Jetzt hatte er einen Vollzeitjob bei Organic, einer Webdesignfirma, deren Mitbegründer er gewesen war. Davor hatte er dort in seiner Freizeit ohne Gehalt gearbeitet. Die Funktion eines technischen Leiters hatte er im Januar 1995 übernommen, als Organic in der Lage war, ihn zu bezahlen. Bevor Behlendorf sich mit Barry und Shan zusammensetzen konnte, musste etwas geklärt werden. „Wir riefen Brian bei Organic an", erinnert sich Barry, „und sagten: ,Wir wollen, dass Sie einen Vertraulichkeitsvertrag unterzeichnen. Wir möchten gern mit Ihnen reden.‘ Er hatte keine Ahnung, was wir von ihm wollten. Also unterzeichnete er den Vertraulichkeitsvertrag, und Shan und ich setzten uns ins Flugzeug, um mit ihm zu sprechen." Shan erinnert sich: „Das Meeting fand am 20. März um sechs Uhr abends in einem kleinen italienischen Restaurant statt, gleich gegenüber von Organic in San Francisco." Shan und Barry ließen die Bombe im Restaurant platzen. Barry erinnert sich, zu Behlendorf gesagt zu haben: „Wir möchten Apache gern zu unserem offiziellen Webserver machen." Er schaute uns fassungslos an und sagte: ,Was soll das?‘ Ich antwortete: ,Nun, wir wollen uns am Entwicklungsprozess beteiligen. Wir werden unseren eigenen Webserver fallen lassen und Apache für alle Plattformen adaptieren. Und wir möchten sehen, wie gut wir mit Ihnen zusammen arbeiten können." Behlendorf erinnert sich: „Ich war zunächst erstaunt, und irgendwie dachte ich mir auch, aha, jetzt haben sie es endlich kapiert. Aber ich würde nicht sagen, dass ich überrascht war. Wir hatten schon immer gedacht, dass die Unternehmen ganz sachte


------------------------------------------------------------------------------------anfangen würden, indem sie ein paar Ingenieure damit beauftragten, Apache zu beobachten und vielleicht hier und da einen Beitrag zu leisten, und dass sie es nie groß hinausposaunen würden. Wahrscheinlich würden wir nur still für uns feststellen, aha, sie verwenden es intern. Aber offensichtlich wollte IBM ein umfassenderes Bekenntnis ablegen, und das passte ausgezeichnet zu unseren Plänen." Shan erzählt: „Während einige interne Rechtsfragen innerhalb von IBM geregelt wurden, bestand Brians nächste Aufgabe darin, die Labors in Raleigh zu besuchen [wo der aktuelle Webserver von IBM entwickelt wurde]. Dieser Besuch wurde für den 9. April angesetzt, nur ein paar Tage nach unserem Meeting." Dieses Meeting würde zeigen, ob die Entwickler des IBM-Webservers - die Leute, die mit der Apache Community zusammen arbeiten würden - bereit waren, es zuzulassen, dass ihre Arbeit durch den viel, viel erfolgreicheren Open-SourceRivalen ersetzt wurde." ..Ich rief die Architekten aller Webserver zusammen," erinnert sich Shan. „Brian ging auch hin. Sie redeten über Technologie und über die Zusammenarbeit. Als Brian herauskam, sagte er: „Wow, es wäre nett, wenn eure Leute da mitmachten", erzählt Shan. „Genau so wichtig war aber, dass mein Architckturchef sagte: „Junge Junge, der Typ kennt sich aus. Er hat mich beeindruckt." Behlendorfs Erinnerungen an das Meeting sind ähnlich warmherzig. „Ich verbrachte einen ganzen Tag dort ... zum Teil mit den Ingenieuren, zum Teil mit den Marketingleuten, zum Teil mit den Geschäftsleuten. Ich erklärte ihnen, wie Apache funktionierte, welche Ziele wir als Gruppe verfolgten, wie wir organisiert waren und Ähnliches mehr. Ich hatte erwartet, dass sie zu 20 oder 30 Prozent im Bilde sein würden, aber sie waren es eher zu 90 oder zu 95 Prozent, denn sie hatten uns eine ganze Zeit lang beobachtet. Schließlich liegt ja alles offen, was wir tun" - ein weiterer Vorteil des öffentlichen Entwicklungsprozesses. Barry und Shan sind noch immer überrascht von ihrer Leistung. „Ich fand das Ganze ziemlich erstaunlich", erinnert sich Barry. Und Shan sagt: „IBM hatte so etwas noch nie gemacht. Als ich begann. mir das anzusehen, hätten die meisten Leute die Möglichkeit, das


--------------------------------------------------------------------------------------durchzusetzen, mit nicht einmal einem Prozent eingeschätzt. Es ist ein kleines Wunder." Wie die Netscape-Ankündigung fünf Monate davor zog das „kleine Wunder" große Aufmerksamkeit der Presse auf sich. Barry erinnert sich: „Wir hatten fast tausend Artikel. Wenn es ablehnende Stimmen gab, dann verstummten sie angesichts dieser Flut positiver Presseartikel schnell." Wie Hahn den Mozilla-Schritt zur Neupositionierung von Netscape als „bescheidenes" Unternehmen setzte, wurde IBM durch die Umstellung auf Open Source mit einem Schlag zu einem der „Guten", zu einem Unternehmen, das „wusste, wo es langging" Diese Lektion ging an anderen Softwareunternehmen, die den vielbeachteten PR-Sieg von IBM zuerst ungläubig und dann mit wachsendem Interesse beobachteten, nicht spurlos vorbei. Wie bei Mozilla kam nach der Hochstimmung die nüchterne Frage der Implementierung. „Bei IBM wussten die Führungskräfte jetzt, was Sache war", erinnert sich Barry, ,.und die Programmierer auch. Aber die starke Schicht des mittleren Managements hatte es noch nicht kapiert. Sie werden nach den von ihnen erwirtschafteten Gewinnen und Verlusten beurteilt. Das sind metrische Zahlen, in denen das Verschenken von Produkten einfach nicht vorgesehen ist." Die Folge war, so sagt er. dass „Apache einen fulminanten Start hinlegte und dann innerhalb von IBM irgendwie im Sand verlief. Das Problem war, dass „wir es nicht separat vermarkten konnten", erinnert sich Barry. „Wir mussten es mit den Produkten bündeln, für die wir Geld verlangten. Vom Marketing-Standpunkt betrachtet hätten wir einen enormen Voneil erringen können, aber das taten wir nicht. Gegen alles wurde Einspruch erhoben, weil wir ja Geld verdienen mussten. Wir mussten es mit WebSphere bündeln. In allem und jedem musste zuerst WebSphere erwähnt werden, und Apache nur nebenbei. „Ührigens, wir verwenden Apache." Deshalb kam das Ganze nicht so gut in Schwung, wie ich gehofft hatte." Aber trotzdem gab es auch in dieser enttäuschenden ersten Phase konkrete Erfolge. Shan dazu: „Wir erkannten, dass Apache ordentliche Unterstützung brauchte, wenn es als ernsthafter Webserver betrachtet werden wollte. Also mussten wir die Leute dazu bringen, ein Rund-umdie-Uhr-IBM-Unterstützungsteam aufzubauen."


------------------------------------------------------------------------------------Dieses Rund-um-die-Uhr-Unterstützungsteam war absolut entscheidend, wie seine Erwähnung in der IBM-Presseaussendung vom Juni 1998 bezeugt. Es beseitigte die Besorgnis über Apache (zumindest die der IBM-Kunden) und war für andere Unternehmen ein Beispiel. Die Entscheidung von IBM, seinen eigenen Webserver durch das Open Source Apache zu ersetzen, war ein Wendepunkt, aber bei weitem nicht das Ende der Geschichte. Obwohl das Unternehmen alle seine Beiträge zum Apache-Projekt als Open-Source-Produkte herausbringen würde (was es auch musste, wenn es an dem Prozess teilhaben wollte), verzichtete es noch auf den kühnen Schritt, seine eigenen geschützten Produkte zu Open-Source-Produkten zu machen, wie Netscape es getan hatte. Aber dieser Schritt folgte gleich auf den Apache-Schritt und war zum Teil seine Folge. Der Mann, dem das zu verdanken war, hieß David Shields. Er war 1987 zur Forschungsabteilung von IBM gestoßen, nachdem er zwanzig Jahre lang für die New York University gearbeitet hatte. „Für Akademiker, die bei IBM in der Forschung arbeiten", sagt er, „gibt es im Wesentlichen nur drei Jobtitel: Mitglied des Forschungsteams, IBMFellow und Nobelpreisgewinner." Anfang 1996 begann Shields mit Philippe Charles an einem wichtigen Projekt namens Jikes zusammenzuarbeiten. Dabei handelte es sich um einen Java Compiler, der in der Sprache Java geschriebene Programme nahm und speziellen Code produzierte, der auf allen Systemen laufen konnte, die Java unterstützten - die Grundlage der viel gerühmten Plattformunabhängigkeit. Als Forschungsprojekt war Jikes auf der alphaWorks-Website von IBM frei zugänglich, aber nur als Binärcode für bestimmte Betriebssysteme und nicht als Quellcode. Am Anfang gehörte GNU/Linux nicht zu den unterstützten Plattformen. „Im Mai '97 bekamen wir die erste Anfrage für eine LinuxBinärversion", sagt Shields. „Aus verschiedenen Gründen verfolgte ich sie jedoch nicht weiter. Im Juni 98 bekamen wir immer mehr Anfragen für eine Linux-Binärversion, und ich entschloss mich, noch einen Anlauf zu unternehmen." Im Juli war Jikes für GNU/Linux fertig gestellt, aber immer noch nur als Binärcode verfügbar.


--------------------------------------------------------------------------------------„Die Reaktion darauf war begeistert", erinnert er sich. „Viel begeisterter, als wir es erwartet hatten. Im Zuge dessen fragten uns Benutzer nach dem Quellcode, wobei ich mir nicht ganz sicher war, was ich in dieser Angelegenheit tun sollte." Schließlich hatte IBM den Quellcode seiner Programme noch nie preisgegeben. „Ich sagte: ,Nun ja, ich werde es versuchen"', aber er gibt zu, „dass ich zum damaligen Zeitpunkt selbst nicht glaubte, dass es gehen würde." Ein Jikes-User schlug vor, dass Shields mit Brian Behlendorf sprechen sollte, der den Kontakt zwischen ihm und James Barry herstellte. „Rückblickend betrachtet", so Shields, „war es wahrscheinlich das Wichtigste, dass IBM im Juni [1998] mit Apache begonnen hatte." Das ebnete den Weg für Shields' eigene Arbeit. Nun hatte er auch jemanden, bei dem er praktischen Rat fand. „Ich verfasste den Vorschlag im August, und er wurde Anfang September angenommen", sagt er. Wie bei der Entscheidung von Netscape, Mozilla zu einem Open-Source-System zu machen oder beim Schritt von IBM, zu Apache überzugehen, wurden die Dinge auch hier durch die Tatsache erleichtert, dass es keinen Gewinnausfall geben würde: „Es war nichts, was IBM je zu verkaufen hätte hoffen können, also brauchten wir nicht über verlorene Einnahmen zu sprechen", erklärt Shields. Er sagte: „Warum nicht auf guten Willen setzen und zeigen, dass wir uns zu Java, offenen Standards und alldem bekannten?" „Am längsten dauerte es, eine akzeptable Open-Source-Lizenz zu bekommen." Auch hier spielte der Konsens eine wichtige Rolle, weil alle etwas dazu zu sagen hatten: die Forschungsanwälte, die Anwälte der Softwaredivision, die mit Java zu tun hatten, die Warenzeichenanwälte, die Patentanwälte und die Vertragsanwälte. Einer der Gründe für das vorsichtige Vorgehen bestand darin, dass „allen involvierten Rechtsanwälte sehr genau bewusst war, dass sie hier die erste Open-Source-Lizenz für IBM schrieben", sagt er. Wenn diese Lizenz von vorn herein fehlerlos wäre, würde es in Zukunft leichter sein, andere Software als Open-Source-Software herauszubringen. Die erste Open-Source-Lizenz für Jikes erschien im Dezember 1998. Sie wurde später verallgemeinert und im Juni zur IBM Public Licence gemacht.


------------------------------------------------------------------------------------Die zunehmende Unterstützung von IBM für Open Source und später für GNU/Linux war zweifellos ein wesentlicher Katalysator für die spätere Durchsetzung von beidem. Die Übernahme von Apache im Juni 1998 und die Veröffentlichung von Jikes als Open-Source-Programm konnte den vielleicht schwerwiegendsten Mangel, unter dem GNU/Linux zur damaligen Zeit litt, jedoch nicht beheben: den Mangel an Unternehmenssoftware. Neben den schlagzeilenträchtigen Schritten von Netscape und IBM kam 1998 auch die Portierung aller wichtigen Backend-Applikationen für GNU/Linux. Das erste erstrangige Unternehmenssoftwarepaket, das unter GNU/Linux lief, wurde einige Monate vor der Apache-Ankündigung von IBM veröffentlicht. Computer Associates, eines der größten Softwarenäuser der Welt, präsentierte auf der CA World im April 1998 die Betaversion einer Ingres-II-Datenbank. Ingres II basierte auf dem ursprünglichen Ingres-Projekt von Berkeley, an dem der Autor von Sendmail, Eric Allman, beteiligt gewesen war. Schon 1992 hatte es einen Port dieses ersten Ingres gegeben. Am 24. November 1992 berichtete Linux News, dass „Zeyd M. Ben-Halim eine neue Version seines Ports von Ingres, dem relationalen Datenbankmanager, für GNU/Linux bekannt gegeben hat". Das war kaum ein Jahr nach der Veröffentlichung von Linux. Das ursprüngliche Ingres-Projekt verwandelte sich in das Open Source PostgreSQL, dessen Entwicklung immer noch nicht abgeschlossen ist, Computer Associates veröffentlichte seine offizielle Betaversion erst im Oktober 1998, und die kommerzielle Version, die letzten Endes unterstützt wurde, erblickte das Licht der Welt erst im Februar 2000. Bis dahin war die Betaversion über 3.500 Mal heruntergeladen und 4.000 Mal auf CD verteilt worden. In der Zwischenzeit kündigten die anderen großen Datenbankanbieter in einer peinlichen Kehrtwende ihre Unterstützung für GNU/Linux an. Eine Meldung in Infoworld vom 6. Juli 1998 mit dem Titel „Datenbankanbieter meinen, dass Linux die kritische Masse noch nicht erreicht hat" zitiert einen Vertreter von Oracle, dem führenden Datenbankunternehmen, wie folgt: „Derzeit ist die Nachfrage unserer Kunden nicht so, dass eine Unterstützung


--------------------------------------------------------------------------------------gerechtfertigt wäre." Weiter hieß es, dass IBM, Sybase und Informix ebenfalls „nicht beabsichtigen, Versionen ihrer Datenbanken auf Linux herauszubringen". Und doch: Zwei Wochen später, am 21. Juli 1998 kündigte Oracle an, seine OracIe8-Datenbank für GNU/Linux zu portieren. Einen Tag nach diesem überraschenden Schritt von Oracle ging Informix noch weiter und brachte eine GNU/Linux-Version seiner Informix-SE-Datenbank heraus, gemeinsam mit freien Entwicklungslizenzen. Wie Oracle verkündete Informix, diesen Schritt „in Reaktion auf die Benutzernachfrage" zu tun. Die Maßnahmen von IBM und Sybase stimmten nicht mit ihren Ankündigungen vom Juli überein. IBM brachte im Dezember 1998 eine Betaversion seiner DB2-Datenbank heraus, und Sybase blieb äußerst skeptisch, was GNU/Linux betraf. Das Unternehmen wartete bis Februar 1999, bevor es den Port seiner SQLAnywhere-Datenbank ankündigte. Die Ankündigung von Oracle war zweifellos der entscheidende Schritt, durch den sich GNU/Linux als ernst zu nehmendes Geschäftssystem zu etablieren begann. Die Kehrtwendung in der Politik von Oracle wurde von vielen Hackern als Erleichterung empfunden. Eric Raymond sagt, er hätte mit Nervosität „eine massive Anti-Open-Source-PR-Offensive von Microsoft" erwartet. Er sagt dazu: „Mir und einigen anderen gelang es, die Öffentlichkeit auf die Marke ,Open Source' aufmerksam zu machen. Aber solange Netscape allein dastand, wusste ich, dass uns eine Investitionen von ein paar Millionen Dollar in Werbung ziemlich dumm dastehen lassen würde. Durch die Ankündigung von Oracle änderte sich das mit einem Schlag. Jetzt war es unmöglich geworden, das Open-Source-Projekt durch reine PR zu killen." Der Verantwortliche für den Launch der GNU/Linux-Version vonOracle8 war Allen Miner. Er merkt an: „Mein offizieller Jobtitel zu Beginn war ,Vice President of Microsoft Alliance‘. Wenn ich jemandem meine Geschäftskarte überreichte, sagte ich immer: ,Das ist mein Jobtitel, aber in Wirklichkeit ist es meine Aufgabe herauszufinden, wie wir Microsoft schlagen können.‘" „Als es sich langsam herauszukristallisieren begann, dass die Zusammenarbeit mit der Open-Suurce-Bewegung viel interessanter für Oracle und für mich werden würde, als nur herauszufinden, wie


------------------------------------------------------------------------------------wir Larry [Ellison, CEO von Oracle] und Bill [Gates] dazu bewegen könnten, sich freundlich miteinander zu unterhalten", wurde sein Jobtitel diplomatischer und lautete nun „Vice President of Strategie Alliances". Oracle hatte schon lange vor der Ankündigung im Juli 1998 über einen GNU/Linux-Port nachgedacht. „Schon anderthalb Jahre davor", so Miner, „hatte ich auf den internen Mailinglisten gesehen, dass mehrere Leute, vor allem Magnus Lonnroth, meinten, dass wir uns diese Sache ansehen sollten." Lonnroth sieht seine Rolle bescheiden: „Ich war schon früh ein Linux-Benutzer, und ich war der Meinung, dass Oracle schon 1995 Linux-Ports herausbringen hätte sollen", sagt er. „Es wäre aber falsch, mich als internen Propheten zu bezeichnen." Jedenfalls wurde - zum Teil dank seiner Befürwortung - „ein Projekt zur Entwicklung von Ports sowohl für Linux als auch für FreeBSD eingerichtet", sagt Miner. „Und Oracle lief schon ein Jahr vor der Ankündigung auf der Plattform." Aus technischer Sicht war es also kein Problem, eine Version für GNU/Linux herauszubringen. „Da sagten Magnus und andere, es gäbe Kunden, die ihr Interesse ausgedrückt hätten, und sie meinten, dass hier ein großes Potenzial läge. Der Grund, warum wir es nicht sofort unterstützten, lag darin, dass nicht klar war, ob das Geschäft ausreichend sein würde, um ein ständiges Wartungsteam zu rechtfertigen und die technischen Unterstützungsfähigkeiten und alles andere auszubauen, was man braucht, um Oracle auf einer Plattform zu unterstützen. Sobald wir einen Port auf einer Plattform herausbringen, verpflichten wir uns praktisch, ihn ewig zu unterstützen." Diese schwer wiegenden Folgen bedeuteten, dass die Ankündigung des bevorstehenden Ports von Oracle ein klares Bekenntnis zur Überlebensfähigkeit von GNU/Linux in der Geschäftswelt war -und das von einem Unternehmen, dass es besser wusste als die meisten anderen. In Anbetracht der Bedeutung dieses Bekenntnisses ist es kein Wunder, dass Oracle gegenüher einem solchen Schritt anfangs skeptisch war. „Ein paar wichtige Dinge, die Anfang 1998 passierten, veränderten diese Umgebung direkt", erinnert sich Miner.


--------------------------------------------------------------------------------------„Zuerst war da etwas ganz Simples: Der Begriff ,Open Source' war geprägt worden", sagt er. „Jetzt kam das ganze Marketing-Know-how zum Einsatz, das uns half, GNU/Linux als attraktive Alternative zu traditionellen Betriebssystemen und als Gegenstück zur radikaleren Bewegung der freien Software als neue Methode der Softwareentwicklung zu positionieren. Die Bemühungen der OpenSource-Gemeinde, Netscape zur Initiierung des Mozilla-Projekts zu überreden, war ein enormer Durchbruch", fügt er hinzu, „Dasselbe gilt für die Entscheidung von IBM, Apache zu lizenzieren, mit der Apache Group zusammenzuarbeiten und das Ganze in ihr Web-Sphere zu integrieren." „Das alles bewirkte eine enorme Steigerung der Glaubwürdigkeit von GNU/Linux", erinnert sich Minen „Dadurch wurde es vielen Leuten von Oracle klar, dass es sich hier um mehr handelte als nur um eine weitere Freewareplattform und dass dies die nächste heiße Sache werden könnte. Dann ging es meiner Meinung nach eher darum, welches der richtige Zeitpunkt für die Ankündigung war, nicht darum, ob wir die Ankündigung machen sollten. Soweit ich mich erinnere, gab es im Mai schon eine Gruppe von Leuten bei Oracle, die erkannt hatte, dass es nur eine Frage der Zeit war, obwohl wir in der Öffentlichkeit sagten, dass wir noch keine diesbezüglichen Pläne hätten." Miner betont, „dass an dieser Entscheidung viele Faktoren beteiligt waren". Im Juli wurde sie schließlich getroffen. Aber Larry Augustin, Leiter von VA Research, meint zu wissen, was ausschlaggebend war. Er sagt, dass das „Future-of-Linux"-Meeting, das am 14. Juli 1998 in Santa Clara stattfand, „der Katalysator für die Entscheidung von Oracle war, seine Absicht bekannt zu geben, für Linux zu portieren." Miner erinnert sich, dass „die Leute von Oracle vollkommen überwältigt waren", als sie sahen, wie viele Leute zu dem Meeting gekommen waren und welche Begeisterung dort herrschte. „Alle sahen uns nur an und sagten: ,Hier passiert etwas Wichtiges'", sagt er. Miner erklärt dazu: „Der Zeitpunkt des Meetings war kein reiner Zufall." Selbst an diesem Punkt war der CEO von Oracle, Larry Ellison, „skeptisch, ob dies eine ernsthafte kommerzielle Plattform werden würde", ist Miner überzeugt. „Aber er wusste, dass wir schon eine


------------------------------------------------------------------------------------Zeit lang Produkte hatten, die auf Linux oder FreeBSD liefen, und es ist ihm zugute zu halten, dass er die Entscheidung traf, es zu kommerzialisieren und zu unterstützen. Einige Oracle-Konkurrenten verschenkten es einfach als nicht unterstütztes Produkt. Wir hingegen boten es als kommerzielles Produkt mit Preis und voller Unterstützung an." Miner fährt fort: „Eine Zeit lang überlegten wir uns sogar ernsthaft, dass Oracle das Linux-Betriebssystem selbst unterstützen könnte. Wir meinten, dass wir damit sowohl unser Linux-Geschäft als auch das allgemeine Linux-Geschäft ankurbeln könnten." Oracle kam schließlich zu dem Schluss, dass dieses Ziel durch die wachsende Unterstützung anderer Firmen erreicht werden würde. Miner und die anderen Befürworter des Ports konnten von Glück reden, dass die Reaktion auf die Oracle-Ankündigung überwältigend war. „Ich war erstaunt über die Reaktion auf die Vorversion der Produktions-CD, die wir im Oktober herausbrachten. Noch bevor die CDs hergestellt waren, trafen schon Tausende Bestellungen ein. Niemand konnte sich erinnern, dass eine neue Oracle-Plattform jemals so schnell akzeptiert worden wäre." Miner sagt, dass „uns das die Zuversicht gab, dass das Potenzial und der Markt viel größer waren, als wir uns das vorgestellt hatten. Außerdem zeigte es, dass die Linux-Bewegung ziemlich groß war. Es war nicht alles Hype und PR, sondern dort draußen waren echte, lebendige Leute, die damit arbeiten wollten," Das war erfreulich für Oracle, denn schließlich bedeutete seine Entscheidung, Oracle8 für GNU/Linux zu portieren, auch, dass in absehbarer Zeit andere wichtige Firmenprodukte folgen würden. Man wollte schließlich keine halben Sachen machen. Als Oracle am 7. Oktober 1998 die letzte Version seiner Oracle8-Datenbank für GNU/Linux auslieferte, lancierte es auch den Oracle Application Server. Im folgenden Jahr veröffentlichte das Unternehmen unter anderem sein WebDB-Produkt, „ein datenbankgesteuertes WebPublishing-Tool für Endbenutzer" für GNU/Linux, entwickelt von einer ganzen Geschäftseinheit, deren Aufgabe „Entwicklung, Vermarktung und Unterstützung von Linux-Software" waren. In einer Presseaussendung wurde erklärt, dass die Oracle-Produkte ein auf dem Linux-Markt phänomenales Echo hatten, wodurch sich Oracle


--------------------------------------------------------------------------------------mit über 50.000 Entwicklern und 800 Kunden als führender Anbieter von Unternehmenssoftware auf Linux etablieren konnte. Wie die Schritte von Netscape und IBM verliehen das viel beachtete Bekenntnis von Oracle zu der Plattform sowie die Portierung aller anderen führenden Datenbanken dem GNU/Linux-System weitere Glaubwürdigkeit für Serveranwendungen. Diese Glaubwürdigkeit wurde noch weiter gestärkt, als die deutsche SAP im März 1999 ankündigte, sie würde ihre ERP1) -Software R/3 portieren. In der Presseaussendung von SAP wurde Hasso Plattner, KonstruktionVorsitzender und CEO von SAP, wie folgt zitiert: „Wir haben im letzten Jahr eine signifikante Zahl von ernsthaften Kundenanfragen über R/3 auf Linux erhalten. Nach umfassenden hausinternen Tests und Diskussionen mit unseren Partnern und Kunden sind wir zuversichtlich, dass Linux unseren Standards entspricht." Obwohl dies der allgemeinen Öffentlichkeit kaum bewusst ist, ist R/3 von SAP das, was einem globalen Standard für Unternehmenssoftware am nächsten kommt. Über der grundlegenden R/3-Plattform laufen Softwaremodule, die generische Unternehmensaufgaben wie Lohnverrechnung und Personalwesen abwickeln, aber auch Spezialaufgaben von Industriesektoren wie Luftfahrt, Automobil, Banking, Chemie, Öl und Gas etc. Laut Firma „verfügt SAP über zehn Millionen lizenzierte Benutzer, mehr als 20.000 Installationen in über 100 Ländern und unterstützt 28 Sprachen. Über die Hälfte der 500 Topunternehmen der Welt verwenden Software von SAP." Microsoft mag die Verkaufsbüros mit seiner Office-Suite dominieren, aber in den Büroräumen sind es SAP-Produktc, die dafür sorgen, dass die Unternehmen laufen. Die Ankündigung des Ports von SAP R/3 für GNU/Linux war in vieler Hinsicht der Höhepunkt der zunehmenden Unterstützung für Open Source. die mit dem drastischen Schritt von Netscape kaum ein Jahr davor begonnen hatte. Die erste Auslieferung an R/3-Kunden erfolgte am 24. August 1999.

1)

ERP: Enterprise Resource Planning


------------------------------------------------------------------------------------Wie sehr SAP von Open Source überzeugt war, wurde durch klare Aussagen in einem FAQ-Dokument über SAP auf Linux auf der SAPWebsite deutlich. Ein Teil der Antwort auf die Frage „Was ist Linux oder Open Source?" lautet: „Open Source ist eine Entwicklungsmethode, die gute Chancen hat, die ganze Softwareindustrie zu revolutionieren." Die Antwort auf die Frage: „Warum tut SAP das?", ist ebenfalls eindeutig: „Wir gehen davon aus, dass Open Source das Softwaremodell der Zukunft ist, und dass Linux in Low-und in HighEnd-Installationen erfolgreich sein wird." Die Antwort auf die unvermeidliche Frage: „Wenn Open Source so gut ist, warum geht SAP nicht selbst dazu über?" lautet: „Wir überlegen tatsächlich, ausgewählte Komponenten des R/3-Kernels von Anfang an als Open Source herauszubringen." Unter den vielen eindeutigen Statements in dem FAQ-Dokument findet sich eine Antwort, die etwas undurchsichtiger ist, auch wenn sie sich unschuldig gibt. In der Antwort auf die Frage „Wo kann ich Linux für R/3 bekommen?" wird erklärt, dass der Linux-Kernel zwar Standard ist, die darum herum entwickelten Distributionen aber nicht. Daher: „Da wir mit Linux vollkommenes Neuland beschreiten, haben wir uns entschlossen, uns zu Beginn auf eine Distribution zu konzentrieren, nämlich auf Red Hat. Wir hoffen, in Zukunft mehrere Distributionen unterstützen zu können." Obwohl es nicht die erste derartige Vorzugsbehandlung für Red Hat war, war es angesichts der zentralen Rolle von SAP in IBM sicher eine der wichtigsten. Wie die Ankündigung von SAP, R/3 zu portieren, die Krönung der GNU/Linux-Bewegung insgesamt war, kam die Entscheidung von SAP für Red Hat einer offiziellen Unterstützung als bevorzugte Distribution für Unternehmenszwecke nahe. Die Wurzeln dieser Entwicklung gehen auf Ende 1998 zurück. Mitten in das Crescendo der Unterstützung der Softwareanbieter für GNU/Linux fiel die dezente Ankündigung von Intel, in Red Hat investieren zu wollen. Das Unternehmen machte nicht viel Aufhebens um diese Entscheidung, die Medien aber sehr wohl. Ganz zu Recht sahen sie sie als großen Schlag gegen Microsoft, den „Partner" von Intel im WintelDoppel, das die Computerwelt so viele Jahre lang beherrscht hatte.


--------------------------------------------------------------------------------------Microsoft hatte bisher die Oberhand in der Beziehung gehabt, indem es immer dann, wenn es sich gezwungen sah, den Chiphersteller in seine Schranken zu weisen, geschickt Allianzen mit Intel-Konkurrenten einging. Intel hatte kaum Möglichkeiten, sich dagegen zu wehren - bis GNU/Linux auf der Bildfläche erschien. Die Beteiligung von Intel an GNU/Linux war das erste Signal, dass sich die Machtverhältnisse in der Branche zu verschieben begannen und dass nicht mehr alle nach der Pfeife von Microsoft tanzen würden. Ein Unternehmen, das sich frühzeitig einschaltete, war Netscape, indem es zur gleichen Zeit in Red Hat investierte wie Intel. Das mochte angesichts der Geschehnisse ein kluger Schachzug gewesen sein, aber leider hatte sich Netscape eine noch größere Chance entgehen lassen. Schon im Frühjahr 1998, gleich nach der viel beachteten Ankündigung des Unternehmens, die nächste Generation seines CommunicatorBrowsers in Open Source herauszubringen, schlug Eric Hahn vor, auch den nächsten logischen Schritt zu tun. Wie er sagt, ging es in seinem damaligen Häresiedokument „hauptsächlich um Linux und Open Source" und dass es „einige Forderungspunkte enthielt". „Der erste", erinnert er sich, „lautete, dass wir die Arbeit an Windows NT sofort einstellen sollten, weil es nicht vorstellbar war, dass unsere NT-Produkte die von Microsoft schlagen könnten. Wir sollten unsere Anstrengungen stattdessen auf Linux konzentrieren." Und schließlich eines der interessantesten „Was-wäre-gewesen-wenn"-Spiele in der Geschichte des Computing - stand darin: „Wir sollten diese kleine Firma namens Red Hat in North Carolina kaufen." Stattdessen kaufte Netscape - ebenso wie Intel und zwei Risikokapitalfirmen namens Greylock und Benchmark Partners - nur einen kleinen Anteil von Red Hat. Der erwies sich als ausgezeichnete Investition: Nach nicht einmal einem Jahr, einen Tag nach der Börseneinführung von Red Hat, war „diese kleine Firma in North Carolina" auf einmal über drei Milliarden US-Dollar wert. Ein schwacher Trost für Netscape, das im November 1998 von AOL geschluckt worden war. Trotzdem bestätigte der überwältigende Erfolg der ersten Open-Source-IPO, dass alle Recht behalten


-------------------------------------------------------------------------------------

hatten, die auf Red Hat und seine Position als führendes GNU/ Linux-Unternehmen gesetzt hatten.

13

Allianzen und Börsengänge

AUFFALLEND AN DEN GNU/LINUX-ANKÜNDIGUNGEN des jahres 1998 war, dass alle von Softwareunternehmen kamen. Das allein hätte jedoch nicht ausgereicht, GNU/Linux für Unternehmen voll akzeptabel zu machen. Die Unterstützung der Hardwareanbieter war unverzichtbar - nicht weil sie bedeutete, dass die freien Betriebssysteme bereits fix auf den neuen Computern installiert sein würden, sondern weil die Unternehmen in diesem Fall davon ausgehen können, dass solche Systeme voll unterstützt werden würden. Der Mangel an formaler Unterstützung seitens anerkannter Unternehmen war wahrscheinlich die letzte ernsthafte Barriere gegen die allgemeine Akzeptanz der GNU/Linux-Plattform. Die Firma, die diese Barriere durchbrechen und mit diesem Schritt das nächste atemberaubende Jahr für die GNU/Linux-Gemeinde einläuten sollte, war Hewlett-Packard (HP), In einer Presseaussendung vom 27. Januar 1999 hieß es: „HP wird seinen


------------------------------------------------------------------------------------Kunden Internetdienste und -lösungen auf Linux-Basis anbieten." Es folgte die Ankündigung „einer Allianz mit Red Hat zur Unterstützung des offiziellen Red Hat Linux 5.2 auf der HP-NetServer-Familie auf Intel-Basis". Der Mann, der die Unterstützung von GNU/Linux bei HP forcierte, war Wayne Caccamo, der damalige Zuständige für strategische Planung. „Im Sommer '98 begann ich, mich mit GNU/ Linux zu beschäftigen, weil es meine allgemeine Aufgabe war, über unseren Tellerrand zu blicken." Er beschreibt das freie Betriebssystem „als eines der Ärgernisse, die damals auf unserem Radarschirm aufgetaucht waren, das wir aber auch als Chance erkannten". Eine solche Chance zu nutzen war wichtig für sein Unternehmen. „HP hatte damals ein paar wichtige technologische Revolutionen wie das Internet an sich vorbeiziehen lassen, und davor schon das Web", erinnert sich Caccamo. „Wenn wir das frühere Image von HP als innovatives, visionäres Unternehmen wieder herstellen wollten, mussten wir zeigen, dass wir die Nase bei den Schlüssel-trends vorn hatten." Das bedeutete nicht nur, das Open-Source-Risiko einzugehen, sondern auch, dabei schneller zu sein als Andere. Caccamo begann, die Situation von HP unter die Lupe zu nehmen. „Ich sah mir verschiedene Aktivitäten an, die einen Linux-Bezug hatten oder in direkter Verbindung zu Linux standen. Mir wurde bald ziemlich klar, dass da einiges im Gange war. Deshalb empfahl ich die Einrichtung einer Open-Source-Solutions-Abteilung", sagt er. Die Aufgabe dieser Abteilung würde darin bestehen, „einige der Aktivitäten, die sich im Inneren des Unternehmens abspielten, an die Oberfläche zu bringen und zu konsolidieren, sodass wir sie unseren Kunden präsentieren konnten." Open Source Solutions Operations (OSSO) wurde am 1. März 1999 offiziell gegründet. Damals hatte HP bereits begonnen, einige seiner GNU/Linux-Aktivitäten „an die Oberfläche zu bringen" Neben der Allianz mit Red Hat, die im Januar bekannt gegeben worden war, hatte HP auch seine Peripheriemanagementsoftware Web JetAdmin portiert. Am 17. März wurde die Öffentlichkeit informiert, dass HP seine Kayak PC Workstations für das Linux-Betriebssystem optimiert hatte.

13. Allianzen und Börsengänge

--------------------------------------------------------------------------------------Am wichtigsten aber war die Ankündigung vom 20. April 1999, derzufolge HP seinen Kunden eine „weltweite 24-Stunden-Unterstützung von Linux- und HP Linux-Applikationen anbieten wird. Im Rahmen der neuen Unterstützungsdienste von HP wird es eine Reaktionszeit von maximal zwei Stunden und sofortige Reaktion auf kritische Anrufe für Plattformen verschiedener Hersteller auf Intel-Basis geben." Diese Plattformen waren, wie sich später herausstellen sollte, Red Hat, Caldera, Pacific HiTech und SuSE. Ihre Erwähnung war wahrscheinlich die erste offizielle Anerkennung ihres Status als die vier wichtigsten GNU/Linux-Distributionen, die auf Servern von HP und „anderen Herstellern" - Compaq, Dell und IBM - liefen. Trotz des enormen Symbolgehalts dieses Schritts - eine der führenden Unterstützungsorganisationen der Welt bot etwas an, was man als Sicherheitsnetz für die Verwendung von GNU/Linux in Unternehmen bezeichnen konnte - meint Caccamo: „Ich kann mich nicht erinnern, dass irgendjemand vom höheren Management besonders konsterniert deswegen gewesen wäre." Überraschenderweise war auch die mögliche Reaktion von Microsoft auf die Defacto-Anerkennung von GNU/Linux als unternehmenstaugliches Betriebssystem und implizit auch als ernst zu nehmender Rivale von Windows NT kein großes Thema. Die dezente Reaktion von Microsoft war zum Teil der genauen Überwachung durch das US-Justizministerium zuzuschreiben, unter der das Unternehmen infolge der Antitrust-Klage stand. „Die Situation, in der sich Microsoft befand, ließ es einfach nicht zu, dass sie zum Hörer griffen", meint Caccamo. „Das hätten sie in der Vergangenheit sicher getan. Sie hätten einfach gesagt: ,HP, wir wären euch sehr verbunden, wenn ihr diese Produkteinführung unterlassen würdet' - unglaublich frech. Aber so waren sie wirklich." Caccamo ist davon überzeugt, dass der Schritt von HP „ziemlich wichtig", wenn auch Teil eines allgemeineren Schneeballeffekts war. Vor den großen Ankündigungen 1998 und Anfang 1999, stand „Linux in den Unternehmen noch mehr oder weniger am Anfang". Die Unterstützung kam damals hauptsächlich von den Technikern. „Was IBM, HP, SAP und alle anderen taten, war, die


------------------------------------------------------------------------------------oberen Managementebenen auf diese Basisbewegung aufmerksam zu machen. Als diese beiden Enden zusammenkamen, begannen die Funken zu sprühen." Das war der Fall, als fast alle großen Hardwareanbieter ihre Unterstützung bekundeten. Fast alle von ihnen wählten zumindest anfangs anstelle anderer Distributionen oder GNU/Linux Red Hat als Partner. So wagte Dell kurz nach der HP-Ankündigung einer ersten Allianz mit Red Hat einen vorsichtigen Vorstoß in Richtung GNU/ Linux. Am 4. Februar stellte Red Hat fest, dass es „bestimmte Server- und Workstationkonfigurationen von Dell gibt, die als mit Red Hat Linux kompatibel zertifiziert sind." Die Hardwarekompatibilität war schon immer eine problematische Frage für GNU/Linux gewesen, vor allem weil viele Hersteller von Peripheriegeräten sich geweigert hatten, Einzelheiten ihrer Hardware zu veröffentlichen, auf deren Grundlage Softwaretreiber hätten geschrieben werden können. Die Presseaussendung enthielt auch die interessante Information von Dell, dass „wir Red Hat Linux schon eine Zeit lang vorinstallieren, wenn die Kundenspezifikationen es verlangen", obwohl das nicht allgemein bekannt gemacht worden war. Ein paar Wochen später trat IBM in den Hardwareklub ein. In einer Presseaussendung hieß es, dass „ein Entwicklungslabor eingerichtet werden wird, um Leistung, Zuverlässigkeit und Sicherheit von Red Hat Linux auf IBM Server- und Clientsystemen zu maximieren." IBM ließ kurz darauf die Ankündigung einer viel breiteren Unterstützung für GNU/Linux folgen. In einer Presseaussendung vom 2. März wurde hinausposaunt: „IBM lanciert größte Linux-Reihe aller Zeiten." Es hieß darin, dass IBM „wichtige Linux-Versionen global unterstützen" und „mit vier kommerziellen Linux-Distributoren zusammen arbeiten" würde - mit demselben Quartett Caldera, Pacific HiTech, Red Hat und SuSE, das HP einen Monat später noch umfassender unterstützen würde. Ziel war es, „den Weg für die gemeinsame Vermarktung, Entwicklung und Schulung sowie für die Unterstützung von Initiativen zu ebnen, die den Kunden bei der Anwendung von Linux helfen." IBM kündigte auch einige wichtige Ports für Linux an. Sie umfassten WebSphere-Produkte (jene Familie, deren Entwicklung


--------------------------------------------------------------------------------------James Barry empfohlen hatte, als er an der Apache-Ankündigung arbeitete), Lotus Domino, den führenden Messaging- und Collaboration Server und auch einen Port von GNU/Linux für einige der IBM RS/6000-Maschinen. Am selben Tag schaltete sich auch Compaq ein, indem es ankündigte, auf einigen ProLiant-Servern GNU/Linux vorzuinstallieren. Obwohl es nicht angab, welche Distribution es verwendete, wurde seine Präferenz eine Woche später klar: Compaq, IBM, Novell und Oracle investierten in Red Hat und trugen damit beträchtlich zu dem Aufschwung bei, der durch die ersten Investitionsrunde von Intel und Netscape im September 1998 initiiert worden war. Getrennt davon beteiligte sich SAP am 30. März 1999 ebenfalls in Red Hat. HP, IBM, Dell und Compaq bildeten die Hauptgruppe der Hardwareanbieter, die 1999 viel beachtete Unterstützungsstatements für GNU/Linux abgaben und strategische Partnerschaften mit Red Hat eingingen. Zwei andere Unternehmen kamen später hinzu; dabei handelte es sich um SGI, das am 2. August einen Vertrag ankündigte, demzufolge es auf seinen Intel-basierten Produkten Red Hat anbieten würde, und Gateway, das ab 7. September an dem Programm für autorisierte Red-Hat-Fach-händler teilnahm. Der Grund, warum die großen Hardwareanbieter - Intel, IBM, HP, Dell, Compaq, SGI und Gateway - sich für Red Hat und nicht etwa für Calerda entschieden, liegt vielleicht in den Erfahrungen, die Allen Miner in der Zeit machte, als er GNU/Linux bei Oracle koordinierte. „Red Hat war zweifellos am stärksten am Aufbau der Linux-Industrie beteiligt", erinnert er sich. „Sie betrieben Marketing, traten von sich aus an potenzielle Partner heran und schöpften alle Möglichkeiten aus, um Linux und andere Open-Source-Produkte auf den Markt zu bringen." Der CEO von Red Hat, Bob Young, ein Kanadier mit ständigem Wohnsitz in den Vereinigten Staaten, war hauptsächlich für die Formulierung dieser Strategie verantwortlich. Schon bevor er sich Ende 1994 mit dem Gründer von Red Hat, Marc Ewing, zusammentat verfolgte er einen ähnlich direkten Geschäftsansatz.


------------------------------------------------------------------------------------1990 arbeitete Young für eine Computervermietungsfirma. „Unser damaliges Ziel war es, in das Geschäft mit der Vermietung und Verleasung von Unix-Workstations einzusteigen", erklärt er. Aber es gab heftige Konkurrenz. „Ich musste gegen Milliarden Dollar schwere Konkurrenten kämpfen", sagt er. „Also konzentrierte ich mich auf die technischen Benutzer, die Unix User Groups in Boston, New York City und Washington D. C. Dabei setzte ich darauf, dass die Systemadministratoren und Programmierer wussten, wann sie neue Ausrüstung brauchen würden, noch bevor das den Einkaufsabteilungen mitgeteilt wurde. Auf diese Weise würde ich die Informationen über die Ausrüstungserfordernisse von den Insidern bekommen." Sich den Benutzern anzunähern hatte eine unvorhergesehene Nebenwirkung. „Ich verbrachte viel Zeit mit diesen User Groups", erinnert sich Young. „Ich half ihnen, indem ich einen kleinen UnixNewsletter für das Ostküstenpublikum veröffentlichte, mit dem ich weitere Mitglieder anzulocken versuchte, denn ich wollte natürlich, dass diese User Groups möglichst erfolgreich sein sollten. Ich brauchte eine Nische, und so fragte ich sie, welche Artikel, die in den großen nationalen Magazinen nicht zu lesen waren, ich in diesem New York Unix Newsletter bringen sollte. Dabei fiel immer wieder das Stichwort ,freie Software‘.“ Trotz seiner späteren Begeisterung stand Young dieser neuen Welt der freien Software ursprünglich skeptisch gegenüber. Aber mit der Zeit änderte er seine Einstellung: „Immer wenn ich mich umsah, war die Gruppe der Leute, die Betriebssysteme auf Linux-Basis verwendeten, wieder ein Stück größer geworden, und der allgemeine Begeisterungspegel stieg." Damals kehrte Young dem Vermietungsgeschäft den Rücken. Aufbauend auf seinen Erfahrungen im Unix-Markt, stieg er im März 1993 in das Versandgeschäft ein. „Ich führte eine kleine Unix-SoftwareVertriebsfirma namens ACC Bookstore. Damit verdiente ich mir meinen Lebensunterhalt", erzählt er. „Unser Katalog bei ACC hieß ACC PC Unix and Linux Catalog. Ich wollte einen Teil dieser Begeisterung für Linux und freie Software für den Aufbau einer Mailingliste von Kunden nutzen, denen ich ,echte Technologie‘ verkaufen konnte. Das Problem war,


--------------------------------------------------------------------------------------dass meine Geschäfte mit dem Verkauf dieser echten Technologie, SCO Unix und solcher Dinge, nie richtig ins Rollen kam. Aber stattdessen wuchs der Umsatz mit Linux-Produkten - das war hauptsächlich primitive Low-End-Technologie wie die Slackware-CDs von Walnut Creek und Linux Professional von einer kleinen Firma namens Morse Communications - wie wild." „Ich begann mich also intensiv mit der Sache zu beschäftigen, und ich sagte mir, dass ich etwas falsch gemacht hahen musste. Hier ging etwas vor sich, das mir nicht einmal die Leute, die ich um Rat fragte, erklären konnten." Charakteristischerweise bestanden Youngs Nachforschungen darin, bei seinen Kunden nachzufragen. „Damals versuchte ich herauszufinden, welche Leute die Hauptbenutzergruppe von Linux stellten." Seine Erkenntnisse verblüfften ihn immer mehr. Je mehr Benutzer er kennen lernte, desto vielfältiger schien sein Zielmarkt zu sein. „Ich glaubte am Anfang, meine Zielgruppe seinen Raketentechniker bei der Nasa oder blauhaarige Kunststudenten in Toronto", sagte er, auf zwei ausgefallenere User anspielend, auf die er traf. „Ich verstand nicht, bis der Groschen dann irgendwann im Lauf des Abends fiel, während ich ein Kreuzworträtsel löste." Young hatte plötzlich erkannt, „dass der einzigartige Vorteil, der diese Begeisterung auslöste, nicht darin besteht, dass dieses System besser oder schneller oder billiger ist als andere, obwohl viele argumentieren, dass es das ist. Der einzigartige Vorteil für den Kunden ist, dass er zum ersten Mal selbst die Kontrolle über die Technologie hat, in die er investieren soll." Anders ausgedrückt: Open Source gibt den Benutzern Freiheit - wie Richard Stallman es von Anfang an geplant hatte. Youngs Ausgangspunkt mag meilenweit von dem Stallmans entfernt gewesen sein, aber den Fanatismus für die Verteidigung der Freiheit des Benutzers haben beide gemeinsam. Young erkannte auch, dass das eigentliche Geschäft mit GNU/ Linux und Open Source nicht im Verkauf des Produkts, sondern von Dienstleistungen lag. Er wusste, dass er eine Grundlage für diese Dienstleistungen brauchte. „Ich hielt Ausschau nach Produkten, die ich zu Marken machen konnte", sagt er. Auch hier half ihm seine Kundennähe, .ich löcherte meine Stammkunden immer


------------------------------------------------------------------------------------wieder: .Welche anderen Produkte soll ich in meinen Katalog aufnehmen, welche anderen Dinge» die es so gibt, wollen Sie drinnen haben?'" sagt er. „Und ein paar Leute antworteten: „,Na ja, Sie sollten sich ansehen, was Red Hat so (reibt.'" Young wollte sich nicht damit begnügen. Red Hat als eine Distribution von vielen zu verkaufen. „Ich hielt Ausschau nach einem Produkt, das ich in meinem Katalog exklusiv anbieten konnte", erklärt er. Zum Glück brauchte Marc Ewing „dringend jemanden, der ihm bei Verkauf dieser Linux-Distribution half, die er zusammengestellt hatte, denn er war nahe daran, im Schlafzimmer seiner kleinen Wohnung in der Nähe der Duke University in Durham zu verhungern." „Also rief ich Mark an und sagte: „Wenn meine Kunden Recht haben, ist Ihr Linux besser als Slackware. Ich verkaufe derzeit Tausend LinuxKopien pro Monat, hauptsächlich Slackware, aber auch einen gewissen Prozentsatz Yggdrasil. Eigentlich sollte es mir gelingen, zehn Prozent meiner Kunden zum Umsteigen zu bewegen. Schicken Sie mir dreihundert Kopien.' Schweigen am anderen Ende der Leitung. Wie sich herausstellte, grübelte er nur darüben wie er dreihundert Kopien monatlich herstellen sollte." „Nach diesem Gespräch erkannten wir, dass wir perfekt zueinander passten“, sagt Young. „Er brauchte damals Hilfe beim Verkauf des Produkts, und ich brauchte ein Produkt für eine Marke. Etwa zwei Monate danach legten wir unsere beiden kleinen Firmen zusammen. Meine kleine ACC Corp kaufte von Marc für ein Bündel Aktien alle Rechte an Red Hat ab und änderte ihren Namen in der Folge auf Red Hat Software." Das war im Mai 1995. Endlich hatte Young die Marke, nach der er gesucht hatte. Dank Youngs Geschäftssinn und Ewings technischen Talenten wurde Red Hat in eingeweihten Hackerkreisen rasch bekannt. Es begann auch Preise und Auszeichnungen zu gewinnen. 1996 wurde es zum Beispiel von Infoworld's zum „Produkt des Jahres" gekürt. Young sagt, niemand war so überrascht davon wie er und seine Kollegen. Sie mögen zwar überrascht gewesen sein, aber sie waren auch entzückt, weil sie nun hoffen durften, die nächste Stufe zu erklimmen: die Akzeptanz in der Unternehmenswelt und größere


--------------------------------------------------------------------------------------Umsätze. Aber diese Hoffnung wurde nicht erfüllt. „Als wir den Infoworld-Preis für 1997 gewannen", erklärt Young, „erkannten wir, dass wir ein Problem hatten." Die Branche hatte zwar erkannt, dass wir die bessere Technologie hatten - im zweiten aufeinander folgenden Jahr hatten wir gegen Microsoft gewonnen -, aber trotzdem entschieden sich alle für Microsoft. Das Problem war, dass wir -fünfunddreißig einsame Hacker - damals in den Tabakfeldern von North Carolina saßen. So ist es eben: Wenn ein Unternehmen sich überlegt, welche Infrastruktur es für seine OracleAnwendungen verwenden will, wird es sich nicht für fünfunddreißig Typen in North Carolina entscheiden, wenn auch das profitabelste, erfolgreichste Technologieunternehmen der Welt zur Wahl steht, das eine angeblich viel bessere Alternative hat. Egal wie groß wir wurden doppelt so groß oder zehnmal so groß -, das Problem würde uns erhalten bleiben. Wir erkannten also, dass wir uns einen Partner suchen mussten. Wir konnten zwar nicht groß genug werden, aber wir konnten uns mit der Branche zusammentun, die langsam Notiz von uns zu nehmen begann [Dank dem Mozilla-Projekt von Netscape, der ApacheAnkündigung von IBM und Ähnlichem mehr]. Wenn wir einen Partner hätten, würde es nicht länger ,Red Hat Linux von der kleinen Firma Red Hat‘ heißen, sondern ,Red Hat Linux von Dell auf dem OracleDatenbanken laufen und das vom globalen Supportteam von IBM unterstützt wird'. Und plötzlich würden die Kunden sagen: ,Aha, das macht Sinn für mich.‘ Diese Überlegungen waren es, die uns in Verhandlungen mit Intel und Netscape eintreten ließen. Ich wollte mit etwa zehn Topunternehmen dieser Branche sprechen. In der ersten Gesprächsrunde im September 98 nahmen wir uns auf der Hardwareseite Intel vor, weit das das einflussreichste Unternehmen war. Auf der Softwareseite war es viel schwieriger, weil die Softwareunternehmen alle noch irgendwie in den Kinderschuhen steckten. Schließlich entschieden wir uns für


------------------------------------------------------------------------------------Netscape, aus dem einfachen Grund, weil sie damals am stärksten und einflussreichsten waren. Außerdem hatten sie den Quellcode ihrer Browsertechnologie öffentlich verfügbar gemacht, und das werteten wir eindeutig als Bekenntnis in unsere Richtung. Die Verbindung mit Intel brachte Red Hat in der Unternehmenswelt mehr als Geld und Glaubwürdigkeit, wie Young sich erinnert. Intel war damals im März '98 ein Unternehmen, das ein bestimmtes Konzept hatte. Intel vertrat die Meinung, dass der Erfolg von Technologieplattformen relativ wenig mit den Leuten zu tun hatte, die das Betriebssystem verkauften, aber viel mit dem Aufbau eines ,Ökosystems' rund um dieses Betriebssystem, Anders ausgedrückt: Microsoft mag der profitabelste Anbieter auf dem Windows-Markt sein, aber wenn man alle Supportorganisationen berücksichtigt, die es gibt, alle Anwendungsanbieter von Oracle oder Corel bis hin zu Computer Associates oder Symantec, streifen sie nur einen relativ geringen Prozentsatz des Gesamtertrags ein. Wenn man dann an all die Hardwaredistributoren in dieser Art Ökosystem denkt, erkennt man, dass man deshalb fast alles mit einem Computer auf Windows-Basis machen kann, weil es irgendwo einen Distributor gibt, der einem dabei hilft. Es gab noch etwas, wofür Intel eintrat und was auch wir erkannt hatten: dass wir dieses Ökosystem ausbauen mussten. Uns begann diese Erkenntnis zu dämmern, nachdem wir zum zweiten Mal den InfoworldPreis als Produkt des Jahres gewonnen hatten. Heute investieren wir viel Zeit in die Zusammenarbeit mit den größten Technologiedistributoren [wie Miner anerkennend bemerkte]. Warum? Nun, weil sich die kleineren von ihnen eher an die Oracles, die Computer Associates und die IBMs halten. Young bringt immer noch den Großteil seiner Zeit bei Distributoren und Unternehmen zu, wo er die Vorteile dieses Ökosystems von


--------------------------------------------------------------------------------------Open Source anpreist. In vieler Hinsicht ist das der perfekte Job für jemanden, der es liebt, endlose und unterhaltsame Vorträge über ein Thema zu halten, das ihm am Herzen liegt. Sein Unternehmen macht überraschend wenig Werbung, obwohl er sich für Fotositzungen noch immer gern den roten Hut aufsetzt. „Auf meiner Geschäftskarte steht Red Hat Spokesmodel", sagt er in leiser Selbstironie. Aber hinter seiner scheinbar selbstlosen Hingabe an die gute Sache steht harte Geschäftslogik. „In dem Augenblick, in dem wir vermitteln können, dass die Marke Red Hat für das Bekenntnis steht, dem Markt Open-Source-Technologie zu bringen, können wir enorme Chancen für das Verkaufsteam von Red Hat schaffen", sagt er. „Wenn uns das nicht gelingt werden die Kunden sagen: ,Ich kann bei dem kleinen Red Hat kaufen oder bei dem großen, sicheren Sun oder Microsoft', und dann verlieren wir das Spiel." Das „kleine" Red Hat ist aber gar nicht mehr so klein -jedenfalls gemessen an der Börsenkapitalisierung, die Youngs erfolgreichen Ansatz widerspiegelt. Am 11. August 1999, dem Tag der Börseneinführung waren die Red-Hat-Aktien zu Geschäftsschluss von 14 US-Dollar auf 52 US-Dollar explodiert. Die Leute „dort unten in den Tabakfeldern in North Carolina" hatten plötzlich einen Marktwert von 3,5 Milliarden US-Dollar. Das war ein beträchtlicher Erfolg, nicht nur für Red Hat. Wie die Investition von Intel und Netscape die erste, viel beachtete Aufwertung von Red Hat und dadurch von GNU/Linux gebracht hatte, war auch der starke Wertzuwachs der Red-Hat-Aktie ein Vertrauensbeweis der Investoren in GNU/Linux und Open Source. Die Siege und Leistungen von Red Hat wirkten sich positiv auf die gesamte kommerzielle GNU/Linux-Welt aus. Dieser Effekt, bei dem der Erfolg eines Open-Source-Unterneh-mens auch anderen zugute kommt, ist nichts Neues. Er machte Calderas pionierhaften Versuch, GNU/Linux 1994 in die Unternehmenswelt einzuführen, so wirkungsvoll. Caldera kann sich zugute halten, den Weg für die Erfolgsserie 1998 geebnet zu haben, indem es Softwareeinzelhändler und Anbieter umwarb und Ports für GNU/Linux sponserte. Ironischerweise bewirkte die Pionierarbeit von Caldera, dass das Unternehmen von der Netscape-Ankündi-


------------------------------------------------------------------------------------gung, seinen Browser als Open-Source-Produkt anzubieten, und von den späteren Schritten, GNU/Linux als Serverplattform einzuführen, am allerwenigsten hatte. Caldera hatte 1997 in Zusammenarbeit mit Netscape verschiedene Produkte angeboten, die unter GNU/Linux liefen. Am 7. Februar 1997 kündigte die Firma an, den FastTrack-Server von Netscape, den einfachen Einstiegs-Webserver für Unternehmen, und den Navigator Gold (der später in Communicator umbenannt wurde) zu portieren. Beide Ports wurden am 18. August dieses Jahres veröffentlicht Am 15. Dezember 1997, nur einen Monat bevor Netscape das Mozilla-Projekt ankündigte, gab Caldera eine Presseaussendung über seinen „Exklusiwertrag zur Bereitstellung der Netscape-Core-Server-undClient-Software für die Linux-Gemeinde" heraus. Der Presseaussendung war auch zu entnehmen, dass dieser Vertrag Caldera das Recht verlieh, [auf seiner Distribution] Open-Linux-NetscapeSoftware an andere Linux-Bereitsteller zu lizenzieren. Ransom Love, der Bryan Sparks im August 1998 als CEO von Caldera ablöste und der wie Sparks früher bei Novell gearbeitet hatte, erklärt die Situation: „Der einzige Grund, warum wir eine Exklusivlizenz bekamen, war, dass Netscape wollte, dass wir ihnen Millionen Dollar zahlten, weil sie zum damaligen Zeitpunkt nicht glauhten, dass Linux eine Zukunft haben würde. Und wir sagten: ,Nun, wenn wir euch tatsächlich Millionen Dollar zahlen sollen, müssen wir eine Möglichkeit haben, das Geld hereinzubekommen.' Und dann drehten sie sich um und brachten den Client gratis heraus - praktisch nur Wochen, nachdem sie den Vertrag unterzeichnet hatten." Zu diesem Zeitpunkt kündigte Netscape seine Pläne an, den Quellcode des Communicator zu veröffentlichen. Dieser Schritt machte es Caldera unmöglich, ClientLizenzen an andere GNU/Linux-Distributionen zu verkaufen. Das war nicht das erste Malt dass Caldera bezahlen musste, weil es mit seinen innovativen Ideen zu früh dran war. Als es sein erstes Produkt auf den Markt brachte, hatte es das damals sehr einfache GNU/Linux um eine grafische Benutzerschnittstelle erweitert. „Der Caldera Network Desktop war ein Cisix-Desktop-Produkt", erklärt Love. „Das ist wieder eines der Elemente, um die wir Linux


--------------------------------------------------------------------------------------erweiterten, um ihm zu mehr Ansehen in der Unternehmenswelt zu verhelfen." Der Code von Visix war geschützt. „Viele dieser Technologien, die wir damals zur Entwicklung von Lösungen verwendeten, standen im Besitz von Unternehmen", sagt er. „Wir versuchten darum herumzukommen, alles von Grund auf entwickeln zu müssen. Wir wussten, dass Linux schon damals stabil genug für Unternehmenszwecke war, aber wir mussten ein Gesamtprodukt schaffen." Ein solches „Gesamtprodukt" war ein ständiges Strategiethema für Caldera, wie es das Ökosystem für Red Hat war. Bei vielen Hackern regte sich Widerstand gegen das, was sie als Kontamination der freien Software durch urheberrechtlich geschützte Software betrachteten. „Es gab viel Kritik, und die Leute machten sich Sorgen, dass Caldera versuchen würde, Linux zu einem geschützten Produkt zu machen. Falscher hätten sie nicht liegen können. Diese Absicht hatten wir nie und werden sie auch nie haben." Bob Young betrachtet diese Kompromissbereitschaft gegenüber geschützter Software um der Schaffung eines „Gesamtprodukts" willen als fatalen Fehler von Caldera und als Grund dafür, dass Red Hat mit seinem offenen Bekenntnis zu Open Source schließlich Marktführer wurde. „Bryan Sparks und Ransom Love sind Freunde von mir. Sie sind einfach tolle Menschen", sagt Young, „aber als Geschäftsleute, als Unternehmer verbrachten sie zu viele Jahre ihres Lebens bei Novell." Die Folge war, ist Young überzeugt, dass sie noch immer an der Einstellung konventioneller Softwareunternehmen festhielten. „Caldera positionierte sich selbst in einer Nische", sagt er, „weil es sich sagte: ,Na gut, wir wissen, dass Open-Source-Produkte aus technologischer Sicht besser sind. Und wir können mithilfe von Open Source ein besseres Betriebssystem entwickeln und uns mit all diesen Technikern koordinieren, aber Geld können wir nur verdienen, wenn wir dieses Ding mit urheberrechtlich geschützten Mehrwertkomponenten umgeben, die wir selbst entwickeln" - wie zum Beispiel dem Visix Desktop." Love ist mit dieser Analyse nicht einverstanden und bestreitet auch, dass Red Hat bei den Marktanteilen im Unternehmenssektor - dem Hauptschwerpunkt von Caldera - die Nase vom hat. „Wenn man sich den Marktanteil im


------------------------------------------------------------------------------------Unternehmensgeschäft ansieht, sind die Zahlen mehr oder weniger umgekehrt, da bin ich mir sicher", sagt er. Ob das nun stimmt oder nicht - mit einem hat Love sicher Recht: „Was den Einsatz von Linux in Unternehmen anbelangt, stehen wir gerade erst am Anfang, und das gilt auch für den Einsatz auf dem Massenmarkt Das heißt, dass wir uns, was die Unternehmensanwendungen betrifft, genau am Wendepunkt der Kurve befinden. Die Unternehmen fragen sich derzeit alle irgendwie: ,Also was ist das, was mache ich damit, und wie wende ich es an?' Was sie brauchen, ist eine Lösung. Sie brauchen Applikationen, Unterstützung und Schulung und sie brauchen all diese Komponenten, die das System aufwerten." Viele scheinen mit dieser Strategie zufrieden zu sein. Am 10. Januar 2000 gab Caldera bekannt, dass sich Sun und Novell gemeinsam mit anderen am Unternehmen beteiligen würden. Im März wurde Caldera an der Börse eingeführt. Die Tatsache, dass der Aktienkurs nicht so atemberaubend schnell in die Höhe schoss wie der von Red Hat - von 14 US-Dollar am Morgen auf 29 US-Dollar zu Börsenschluss, womit Caldera mit einem Schlag einen Wert von rund 1.100 Millionen USDollar hatte -, war darauf zurückzuführen, dass die Marktbedingungen nicht dieselben waren. Auch die Red-Hat-Aktien hatten gegenüber Dezember 1999 einiges an Wert verloren. Loves Beteiligung an Caldera müsste ihn eigentlich über die holprigeren Wegstrecken hinwegtrösten, die er mit dem Unternehmen bislang absolviert hat. Es scheint dass die unglückliche Eigenschaft von Caldera, die entscheidenden Trends schneller aufzuspüren als irgendein anderes Unternehmen und sie trotzdem nie für sich nutzen zu können, lange zurückreicht - bis zu diesem ersten Corsair-Projekt bei Novell Love erzählt ein bisschen genauer, was er und Bryan Sparks damals 1994 mit Linux machten. „Das war die Zeit von Mosaic Communications; Netscape hatte noch nicht einmal seinen Namen", merkt Love an. „Wir hatten eine grafische Benutzerschnittstelle entwickelt, die eine virtuelle Welt war. Mithilfe von Farbkarten konnte man im Netzwerk herumzeigen, klicken und navigieren. Man konnte innerhalb des Unternehmens von Abteilung zu


--------------------------------------------------------------------------------------Abteilung oder ins Intranet gehen, indem man auf eine Karte klickte. Und man konnte sich die Informationen holen, die man brauchte, ohne das Netzwerk in seiner ganzen Komplexität zu verstehen." Sparks und Ransom Love hatten ein Werkzeug zum Durchbrow-sen von Informationen gefunden, dessen Navigationsmodell - eine virtuelle Welt - nicht einmal von den heutigen Produkten erreicht wird, geschweige denn von denen des Jahrs 1994. „Es war komisch. Wir riefen die Leute von Mosaic, dass sie sich das ansehen sollten", sagt Love. „Sie konnten es überhaupt nicht fassen." Die Leitung von Novell hatte keine Ahnung, was sich in den Labors der Firma so tat. „Wenn sie es gewusst hätten, wären sie heute Eigentümer des Internets, sagt Love einfach. Aber stattdessen drehte Novell dem Projekt den Hahn ab. Aufgrund seiner hartnäckigen Weigerung, die offenen Netzwerkstandards von TCP/IP voll zu akzeptieren, wurde das Unternehmen vom Internet immer mehr an den Rand gedrängt. Von Besitz war keine Rede mehr. In diesem Sinn ist Caldera (das Wort bedeutet den erweiterten Krater eines erloschenen Vulkans) leider ein äußerst passender Name für ein Unternehmen, das eine Art edles Relikt noch edlerer Ideen ist, denen seine Gründer am Anfang nachgehangen waren. Novell war auch die Triebfeder hinter der Schaffung jener Firma, die schließlich zur dritten großen Distribution der GNU/Linux-Viererbande, Pacific HiTech, werden sollte. Der Gründer von Pacific HiTech, Cliff Miller, hatte bis dahin ein ziemlich abenteuerliches Leben geführt. Geboren in San Francisco, verbrachte er als Kind ein Jahr lang in Australien. Dann ging er für zwei Jahre nach Japan, wo er bei einer japanischen Familie wohnte und eine öffentliche Schule besuchte. Nachdem er in die Vereinigten Staaten zurückgekehrt war, ging er aufs College. Dann lebte er ein Jahr in Mazedonien, einem Teil des ehemaligen Jugoslawien, um sein Studium der mazedonischen Sprache zu beenden. „Ich schloss mein BA-Studium mit 19 Jahren ab", erzählt er, „und ein Jahr später hatte ich auch meinen MA in Sprachwissenschaften." Mit dem für ihn typischen Understatement fügt er hinzu: „Ich kann mich ziemlich gut konzentrieren, und in Dinge, die mich interessieren, grabe ich mich so richtig hinein."


------------------------------------------------------------------------------------Nachdem Miller sein Studium abgeschlossen hatte, nahm sein Leben eine andere Wendung. „Ich arbeitete zuerst in einer Salzfabrik und dann etwas mehr als ein halbes Jahr auf den Ölfeldern von Wyoming, wo ich einen großen Laster fuhr." Aber schließlich erlag Miller den Verlockungen Asiens, einem der Fixpunkte seiner Welt, und kehrte nach Japan zurück, um dort Englisch zu unterrichten. Als Nächstes zog er nach China, wo er an der naturwissenschaftlichen Fakultät einer Universität Englisch unterrichtete. Dort fand er auch seine Frau Iris, die in Peking geboren ist und fließend Englisch und Japanisch spricht. Als das Paar in die Vereinigten Staaten zurückkehrte, arbeitete Miller, wie er erzählt, „eine Zeit lang bei Xerox in deren mehrsprachiger Softwaregruppe. Damals wusste ich nicht besonders viel über Computer oder über das Programmieren, war aber allgemein interessiert. Ich bewarb mich bei einigen Universitäten und wurde von der University of Utah für Computerwissenschaften aufgenommen. Ein Stipendium bekam ich auch." 1992, als er mit seiner Dissertation an der University of Utah begann, wurde Millers Frau entlassen, nachdem Novell die Firma übernommen hatte, in der sie arbeitete. Anstatt nach einem anderen Job für Iris Ausschau zu halten, gründeten die beiden ein eigenes Unternehmen, Pacific HiTech, mit Sitz in ihrem Keller. „Anfangs wollten wir USoder westliche Software an den japanischen Markt verkaufen", erklärt Miller- ein Geschäft, für das sie angesichts ihrer sprachlichen Fähigkeiten und ihrer Computerkenntnisse die besten Voraussetzungen mitbrachten. „Sehr schnell begannen wir, CD-ROMs zu veröffentlichen, uns freie Software und Shareware aus dem Internet zu holen und sie auf CD-ROM herauszubringen. Wir waren eines der ersten Unternehmen, die hauptsächlich vom Internet leben konnten." Bei ihrer Suche nach freier Software, die im Internet verfügbar war, stießen sie auf GNU/Linux. „Das war etwas, was wir nehmen und zu einem Produkt machen konnten", erinnert sich Miller und fügt hinzu: „Aber es war noch viel mehr. Wir verwendeten Linux schon sehr früh intern als Entwicklungstool." Diese Entwicklungsarbeit sollte sich ein paar Jahre später auszahlen. Nachdem Miller und seine Frau freie Software und die


--------------------------------------------------------------------------------------GNU/Linux-Distributionen Dritter verkauft hatten, entschlossen sie sich, eine eigene Distribution herauszubringen - allerdings mit einem Unterschied. „Wir sagten uns, na gut, wir testen Linux bereits seit einiger Zeit und produzieren Entwicklungen dafür. Japan ist ein weiter offener Markt für Linux, weil niemand eine ernst zu nehmende japanische Version von Linux macht. Also beschlossen wir, das vor Ort zu versuchen." Das war Ende 1997. Wie das erste Produkt von Caldera enthielt die Distribution von Pacific HiTech einen bestimmten Anteil geschützter Software, wobei die Gründe hauptsächlich dieselben waren. Eine GNU/Linux-Distribution für Japan musste die japanische Sprache uneingeschränkt unterstützen; GNU/Linux war dazu in der Lage, brauchte dazu aber zum Beispiel japanische Schriften und noch einige andere spezielle Elemente. Das Produkt von Pacific HiTech bot diese in Form von kommerzieller Software an. „Es gab dort draußen in der Welt der freien Software durchaus einiges", so Miller, „aber die Qualität war nicht dieselbe. Deshalb gibt es verschiedene Versionen der Distribution, darunter eine vollkommen freie Version ohne das kommerzielle Zeug. Die grundlegende Distribution ist eine reine GPL-Distribution." Die Distribution von Pacific HiTech schlug sich in Japan ausgezeichnet, und nach Einführung einer lokalen Version im Frühling 1999 auch in China. Miller sagt, dass niemand genau weiß, wie groß ihr Marktanteil auf diesen Märkten ist, weil die Distributionen frei heruntergeladen und kopiert werden können. „Aber wir glauben, dass sie in Asien bei über 50 Prozent liegt." Angesichts dieses Erfolgs war es ganz natürlich, dass Miller daran dachte, in den US-Markt hineinzugehen. „Wir verkauften unserer Produkte immer nur tröpfchenweise. Im letzten Quartal legten wir mit Marketing so richtig los." Zu diesem Zettpunkt hatte die Firma ihren Namen auf TurboLinux geändert, auch um zu zeigen, dass sie sich nicht länger auf den asiatischen Markt konzentrierte. Es war der richtige Name für ein Unternehmen, das von dem ruhigen, aber geistig überaus regen Miller geführt wurde. „Im vierten Quartal 1999 begannen wir an Einzelhandelsgeschäfte in den Vereinigten Staaten zu verkaufen. Dabei handelte es sich in erster Linie um unser Workstation-Produkt", erzählt Miller.


------------------------------------------------------------------------------------„Dank ziemlich aggressiver Promotion gelang es uns, im Einzelhandelsmarkt einen guten Start hinzulegen. Aber der eigentliche Schwerpunkt unserer Strategie besteht darin, dem Unternehmensmarkt mit einem Serverprodukt zu dienen, das wir entwickeln. Wir konzentrieren unsere Entwicklung auf unsere Serverproduktlinie und auf Clustering." Clustering bedeutet, mehrere Maschinen auf koordinierte Weise zu betreiben. „Wir haben da etwas, was wir einen Daemon nennen", erklärt Miller. „Das ist Software, die im Hintergrund läuft und für die hohe Verfügbarkeit sorgt. Wenn also ein Computerknoten im Cluster ausfällt, meldet das der Daemon, der auf allen Knoten läuft, und routet um diesen ausgefallenen Computer herum." Die Fähigkeit, den Ausfall einzelner Maschinen zu verkraften, ohne den allgemeinen Betrieb des Systems zu stören, ist das Wichtigste an solchen High-AvailabilityClusters, wie sie genannt werden. Sie werden vor allem in betriebsintensiven Bereichen wie im E-Commerce eingesetzt. TurboLinux hat für diesen Daemon einen außergewöhnlichen Lizenzansatz. „Der Quellcode ist sechs Monate lang unzugänglich, und danach geben wir ihn frei", erkärt Miller. „Es ist also eine Art Kompromiss, um unsere Investition in die Entwicklung zu schützen." Ein derartiger innovativer Ansatz - er wurde bei einem Programm namens Ghostscript zum ersten Mal angewendet - ist deshalb möglich, weil sich die Technologie so schnell entwickelt, dass die Käufer trotz des Sechs-Monate-Fensters genügend Anreiz haben, eine Software zu kaufen, die später ohnehin freigegeben werden wird. Miller sagt dazu: „Für ein großes Unternehmen ist es wirklich günstig, ClusteringSoftware für ein- oder zweitausend Dollar zu bekommen." Miller scheint es nicht schwer zu fallen, die Investoren davon zu überzeugen, dass sein Ansatz funktioniert. Ende 1999 investierte Intel in TurboLinux, und einige Risikokapitalunternehmen folgten seinem Beispiel. Dieser Finanzierungsrunde folgte im Januar 2000 die nächste. Nun war es „ein ganzer Rattenschwanz von Unternehmen", wie Miller es formulierte. Dell war der führende Investor, und dann kamen Compaq» Seagate, Novell, NEC, Fujitsu, NTT und Legend in China insgesamt etwa fünfundzwanzig Investoren. „Es


--------------------------------------------------------------------------------------kam ganz schön viel Geld", fügt Miller hinzu. „Wir bekamen 57 Millionen US-Dollar. Aber noch wichtiger als das Geld waren die Beziehungen, die wir dadurch verbessern konnten." Trotzdem wird das Geld bei der Finanzierung von Millers ambitionierten Expansionsplänen in Europa gute Dienste leisten. Red Hat und Caldera sind dort schon eine Zeit lang präsent, aber die dominierende Distribution in dieser Region kommt von der deutschen SuSE. SuSE ist das Akronym des deutschen Namens Software- und Systementwicklung. Wie Pacific HiTech wurde das Unternehmen ins Leben gerufen, als seine Gründer noch die Universität besuchten. Einer von ihnen war Roland Dyroff, der heutige CEO von SuSE. „Anfangs war geplant, dass das Unternehmen Consulting und Softwareentwicklung rund um Unix anbieten sollte", sagt er, „Aber bevor dieser Plan so richtig umgesetzt werden konnte, erschien Linux auf der Bildfläche, und alles wendete sich Linux zu." Das Unternehmen wurde 1992 gegründet. Das erste Angebot an die Kunden erfolgte im März 1993 und bestand in der pionierhaften SLSDistribution von Peter MacDonald. Später verwendete SuSE Slackware als Grundlage für eine lokalisierte Version. Wo Japan für Pacific HiTech wegen des dortigen Mangels an GNU/Linux-Aktivitäten attraktiv war, war Deutschland ein guter Ort für den Verkauf von GNU/Linux-Distributionen - genau aus den entgegengesetzten Gründen. Damals wie heute hatte Deutschland die fortgeschrittensten Anwender von GNU/Linux. 1996 beschloss SuSE, eine eigene Distribution auf den Markt zu bringen. „Der Grund war die zeitliche Verzögerung", erklärt Dyroff. „Slackware kam heraus, und wir musslen unsere Patches anbringen", um die Software für deutsche Benutzer geeignet zu machen. Seit damals fügte SuSE viele Originalelemente hinzu. Als SuSE sich als führende europäische Distribution etabliert hatte, beschloss die Firma 1997, ein Büro in Oakland, Kalifornien zu eröffnen. Dyroff selbst beschreibt diese Entscheidung als „lächerlich". Er erklärt: „Der Grund ist, dass das Unternehmen damals sehr klein war. Wir hatten 1996 einen Umsatz von rund drei Millionen Euro, und wir waren nicht wirklich liquide genug, um in den Vereinigten Staaten investieren zu können. Wir hatten auch nicht viel Erfahrung. Aber wir taten es einfach." Als SuSE in den


------------------------------------------------------------------------------------US-Markt ging, verwendete die Firma den Einzelhandel als Strategie zur Werbung für seine Marke, wie es auch TurboLinux getan hatte. „Wir konzentrierten uns darauf, das SuSE-Box- Produkt zu verkaufen", erzählt Dyroff. Aber inzwischen streckt die Firma ihre Fühler in den Bereich Professional Services aus, in Fortsetzung dessen, was sie Anfang 1999 in Deutschland tat. Obwohl die Dienstleistungen „der bei weitem am schnellsten wachsende Sektor unseres Geschäfts sind", sagt Dyroff, liegt die traditionelle Hauptstärke von SuSE im Einzelhandel. „Einhundert Prozent unserer Kunden sind Privatkunden, weil die Leute, denen wir in den Firmen verkaufen, fast alle Techniker sind", sagt Dyroff. „Der Bereich der potenziellen Kunden ist nun größer als der der Techniker, die eine Kaufentscheidung treffen oder Linux empfehlen. Aber das ist ein ganz neuer Prozess", betont er, und als Prozentsatz des Gesamtumsatzes „noch nicht relevant". Das spiegelt Loves Bemerkungen darüber wider, dass GNU/Linux im Unternehmenssektor noch in den Kinderschuhen steckt und dass es noch viel zu früh ist, um den Sieg zu verkünden. SuSE ist wie sein Name ein Rätsel. Trotz seines soliden technischen Hintergrunds strahlt Dyroff Begeisterung aus und bricht oft in jungenhaftes Kichern aus. Vielleicht ist es neben Aktionen wie seiner „lächerlichen Entscheidung", in die USA zu gehen, das, was SuSE zu einer Art Joker in der Meute der Anbieter GNU/Linux-Distribuüonen macht. Auf jeden Fall muss SuSE als einer der größten und profitabelsten Marktteilnehmer des Sektors ernst genommen werden. Im November 1999 konnte es seine Kriegskasse dank Investitionen im Wert von 12 Millionen Euro von Intel und Apax Partners weiter aufbessern. Die vier führenden Distributionen waren nicht die einzigen etablierten Marktteilnehmer der GNU/Linux-Welt die 1998 und 1999 von der wirkungsvollen Unterstützung der Mainstream-Computerriesen und der Finanzmärkte profitierten. Ein weiterer war der GNU/LinuxHardwareanbieter VA Research, der seinen Namen im April 1999 auf VA Linux änderte. Wie Red Hat wurde VA Linux von einer Investition, die am 12. November 1998 bekannt gegeben wurde, aus seinem Dornröschenschlaf gerissen. Investor war dieses Mal Sequoia Capital, das


--------------------------------------------------------------------------------------dazu beigetragen hatte, Unternehmen wie Yahoo! auf die nächsthöhere Ebene zu heben. Nun schüttete Intel mit einer Investition am 19. Februar 1999 sein Füllhorn über VA Linux aus. Die Börseneinführung von VA Linux fand am 9. Dezember 1999 statt. Die Aktien hatten einen Anfangskurs von 30 US-Dollar und schlossen bei 239,25 US-Dollar, was einer Steigerung von fast 700 Prozent entsprach. Das war ein neuer Rekord - der bislang größte Kursgewinn einer Börseneinführung am ersten Tag. Wie es ihren Wurzeln in der Gegenkultur entsprach und in Anerkennung des entscheidenden Anteils von Open Source an ihrem Erfolg sorgten Red Hat, Caldera und VA Linux dafür, dass Hacker, die Beiträge zu GNU/Linux geleistet hatten, im Rahmen eines Programms, das „Directed-Share Schemes" genannt wurde, Aktien zum Eröffnungskurs bekamen. Leider wurden diese löblichen Versuche, die eigentlichen Urheber des Betriebssystems zu belohnen, durch Ausrutscher und praktische Probleme beeinträchtigt. Viele waren besorgt, dass die nicht unbeträchtlichen Summen, die durch diese Börseneinführungen über der Hackergemeinde ausgeschüttet wurden, die bis dahin reine Welt des Open Source besudeln würden. Eric Raymond, selbst Empfänger von nicht weniger als 150.000 VA Linux-Aktien als Gegenleistung für seine Dienste im Board des Unternehmens in einer Funktion, die er als „das offizielle Unternehmensgewissen von VA" bezeichnet, zählte nicht zu ihnen. In einem seiner charakteristischen Artikel mit dem Titel „Vom Reichtum überrascht", einer inzwischen bekannt gewordenen Mischung aus persönlicher Geschichte und akribischen Branchenanalysen, beschreibt er, wie er vom faszinierenden Debüt von VA Linux an der Börse erfahren hatte. Der Artikel beginnt mit einer klassischen Raymond-Äußerung: „Vor ein paar Stunden erfuhr ich, dass ich jetzt (zumindest theoretisch) aberwitzig reich bin." Nach einigen Ausführungen schreibt er mit seiner üblichen Nonchalance: „Ich war ohne hinzusehen rund 41 Millionen Dollar wert geworden."


------------------------------------------------------------------------------------„Sie fragen sich vielleicht, warum ich darüber in der Öffentlichkeit spreche", sagt er und erklärt dann weiter, indem er geschickt vom Einzelnen zum Allgemeinen überleitet: Die Fairness gegenüber den Hackern, die mir bei den Banken Ansehen verschafft haben, gebietet es, dass ich dieses Ergebnis öffentlich anerkenne und mich öffentlich mit der Frage auseinander setze, wie diese Situation mein Leben beeinflussen wird und was ich mit dem Geld anfangen werde. Das ist eine Frage, mit denen viele von uns konfrontiert sein werden, wenn Open Source die technologische Landschaft überrollt. Das Geld folgt dem Wert, und die MainstreamWirtschaft und die Finanzwelt erkennen in uns struppigen Hackern eben immer mehr Wert. Red Hat und VA haben nun mit ihren DirectedShares-Programmen, deren Ziel es ist, so viele einzelne Beitragende zu belohnen, wie sie finden können, einen Präzedenzfall geschaffen. Zukünftige Marktteilnehmer, die von der Community unterstützt werden und am Kopf der Tafel sitzen wollen, werden ihrem Beispiel folgen müssen. Während es also unwahrscheinlich ist, dass es viele weitere Multi-Millionen-Dollar-Glücksfälle wie den meinen geben wird, werden viele Hacker Antworten auf diese Frage finden müssen, auch wenn es um kleinere Beträge geht - denn auch diese sind für Einzelpersonen von großer Bedeutung. Zehn oder Hunderttausende Dollar sind genug, um ein Leben zu verändern oder es zu ruinieren. Dann weist er auf die Ironie hin: „Es ist doch wirklich zu komisch. Erinnern Sie sich noch an die große Frage am Anfang: ,Wie können wir damit Geld verdienen?‘ Dann geht er etwas ernsthafter auf die zentrale Frage ein, die dieser neue Reichtum aufwirft: „Wissenschaftler fragen mich dieser Tage oft, ob ich glaube, dass die Open-Source-Gemeinde durch den Einfluss des Großen Geldes korrumpiert werden wird. Ich sage dann, was ich glaube, und das ist Folgendes: Die kommerzielle Nachfrage nach Programmierern ist schon seit langem so stark, dass alle, die sich von Geld irgendwie verleiten lassen, längst weg sind. Unsere Gemeinde hat


--------------------------------------------------------------------------------------sich herausgebildet, weil ihr andere Dinge wichtig sind, wie Leistung, Stolz, künstlerische Leidenschaft und die Mitmenschen." Raymond betont, dass der wahre Hacker trotz dieses spektakulären Geldeinbruchs in die Open-Source-Welt und der Wandlung der GNU/LinuxDistributionen in finanzielle Kraftprotze weiß, dass zwischen dem Geld und der Idee der freien Weitergabe, die das Herzstück der Bewegung der freien Software bildet, Welten liegen.

(Leerseite)

14

Offen fürs Geschäft

DlE HERAUSFORDERUNG. VOR DER UNTERNEHMEN standen, deren Geschäft auf einer GNU/Linux-Distribution basierte - wie man Geld mit Software verdient, die auch frei verfügbar ist -, war keinesfalls neu. Trotzdem zeigten Überflieger wie Red Hat oder VA Linux der verwirrten Allgemeinheit erst 1999 ein Modell, das funktionierte. Einer der ersten, die Geld mit freier Software verdienten, war Richard Stallman, der I985 Magnetbänder mit seinem GNU Emacs für 150 USDollar pro Stück verkaufte. Er bot auch Beratungsdienste rund um Emacs an, und später seinen GCC Compiler, der C-Programme in Binärcode verwandelt, der von Prozessorchips verarbeitet werden kann. Geraume Zeil bevor Linux das Licht der Welt erblickte, hatte ein Unternehmen namens Cygnus Solutions eine Pionierrolle bei einigen Techniken übernommen, die später von den GNU/Linux-Distributionen angewendet wurden, die sich


------------------------------------------------------------------------------------rund um sie entwickelten. Die Firma hatte gezeigt dass der Aufbau eines Geschäfts auf der Grundlage freier Software nicht nur möglich war, sondern höchst profitabel sein konnte. Wie es in der Geschichte der freien Software so oft der Fall gewesen war, brachte GCC die Dinge ins Rollen, Als Michael Tiemann, einer der Gründer von Cygnus, 1987 auf GCC stieß, war er so beeindruckt, dass er hinging und Stallmans Manifest über freie Software las, um mehr über das GNU-Projekt zu erfahren. Tiemann erkannte nicht nur die Stärke der Stallmanschen Logik, sondern sah darin auch einen latenten Businessplan. „Wieder einmal bestätigte sich meine relativ simple Überzeugung, dass der freie Markt tatsächlich die richtige Wirtschaftsform ist", erklärt Tiemann, „und dass es jemandem, der eine bessere Methode hat, auch gelingen sollte, sie profitabel und erfolgreich zu machen." GCC war eindeutig so viel besser als jedes kommerzielle Produkt, dass Tiemann davon überzeugt war, dass er rundherum ein florierendes Geschäft entwickeln konnte. Da man mit dem Verkauf von etwas, was frei verfügbar war, kein Geld verdienen konnte, kam er zu dem für ihn logischen Schluss, dass das Geheimnis in den Dienstleistungen liegen müsse - Support und Beratung zum Beispiel. Er sprach mit Stallman über seine Pläne. „Ich wollte mir damals seinen Segen holen", erinnert sich Tiemann, Trotz der Einstellung zur kommerziellen Software, die ihm oft falschlich zugeschrieben wird, war Stallman begeistert. „Er sagte ,Ahsolut‘", erinnert sich Tiemann, „solange du dich an die GNU Public License hältst." Wenn sich Tiemanns Unterfangen als erfolgreich erweisen würde, würde das schließlich beweisen, dass Stallmans Ideale nicht unvereinbar mit der kommerziellen Nutzung waren und dass es möglich warr rund um freie Software ein Geschäft aufzubauen. Stallman sagt oft, dass Cygnus eigentlich für „Cygnus, Your GNU Support" stehen sollte, ein weiteres rekursives Akronym. Tiemann dazu: „Das ist, als ob man sagte, Emacs stünde für ,Eight Megabytes And Constantly Swapping‘". (Diese eher unfreundliche Bemerkung bezieht sich auf die Anfangszeiten, als Emacs mehr Speicher brauchte, als die meisten Maschinen zu bieten hatten. Man hatte deshalb auf Tricks zurückgreifen müssen, die zum

14. Offen fürs Geschäft

--------------------------------------------------------------------------------------Beispiel darin bestanden, dass man Teile des Programms vom Hauptspeicher auf die Festplatte auslagerte - ein Ansatz, der ungeheuer verlangsamend wirkte.) „In Wahrheit", fährt Tiemann fort, „fanden wir keinen guten Namen, der noch nicht eingetragen war. Als ich mich bei meinen Freunden aus dem Netz darüber beklagte, suchte einer von ihnen im Wörterbuch nach Wörtern, die die Silbe ,GNU‘ enthielten. ,Cygnus' schien mir das am wenigsten anstößige dieser Wörter zu sein. Aber die Leute fanden sehr schnell Definitionen für die Bedeutung von ,Cygnus‘. Ich freue mich, dass Richard eine dieser Definitionen geprägt hat." „Ich war vollkommen überzeugt davon, dass Cygnus funktionieren würde", sagt Tiemann. Aber er hatte erkannt, dass es ein Problem gab. „Ich dachte mir: Richard ist wahrscheinlich einer der klügsten Köpfe, die ich je gesehen habe, wenn es um Software geht", sagt er. Aber trotz dieser Brillanz fiel es selbst Stallman schwer, die Unternehmen dazu zu bringen, seine Vorstellungen von freier Software zu akzeptieren. Die Folge war, so Tiemann, „dass ich irgendwie das Gefühl hatte, dass es mir, wenn ich nur ein weiterer Rufer in der Wüste wäre, nicht gelingen würde, der kritischen Masse näher zu kommen als er." „Also wollte ich bewusst ein paar Mitgründer an Bord holen", sagt er, „um zu versuchen, jene kritische Masse zu erreichen, die als Katalysator für das Geschäft wirken würde. Ich unterhielt mich mit mehreren Leulen über diese Idee, und die Einzigen, die mich ernst nahmen, waren die beiden anderen Mitbegründer" - John Gilmore und David HenkelWallace. „John Gilmores Email-Handle1) ist ,gnu‘, erklärt Tiemann, „und manche behaupten, dass er dem GNU-Projekt seinen Nickname gegeben hat." Dazu kam, dass „John, die Nr. 5 bei Sun, ein renommierter Programmierer und Bürgerrechtler war. Außerdem verfügte er durch seine Sun-Aktien über eigenständiges Vermögen." Den anderen Partner, David Henkel-Wallace, hatte Tiemann getroffen, als er seine Forschungen über Compiler durchführte, »jemand, der mir ebenfalls ziemlich klug zu sein schien", wie er

1)

der erste Teil der E-Mail-Adresse vor dem @


------------------------------------------------------------------------------------sagt. „Also legten wir drei unsere Ressourcen zusammen. Ich trug mit 2.000 Dollar, die alles waren, was ich an flüssigem Geld hatte, am wenigsten bei. Ich sagte John und auch Gumby - der Spitzname von David Henkel-Wallace -, dass ich sie nicht wegen ihres Geldes an Bord holte. Also investierte jeder von uns 2.000 Dollar in die Gründung des Unternehmens." Das war im November 1989. Das neue Cygnus Solutions bot Dienste an, die auf Stallmans GNUSoftware basierten. „Im Grunde ging ich zu dem Kunden und schloss einen Vertrag mit ihnen. John und Gumby überlegten sich dann, wie wir ihm erfüllen würden", erinnert sich Tiemann. „Am Anfang funktionierte das ziemlich gut. Aber mit der Zeit wurde es komplizierter, als ich immer mehr Verträge brachte. Also brauchten wir ein Modell, das besser skalierbar war. Die Herausforderung bestand darin, dass wir wussten, dass wir Supportdienste für die Software anbieten wollten, dass wir zum damaligen Zeitpunkt aber noch kein eigenes Produkt hatten. Es sollte drei Jahre dauern, bis wir ein glaubwürdiges Supportangebot hatten", sagt er und fügt hinzu: „Wir verloren wahrscheinlich mit jedem Supportvertrag, den wir vor 1992 abschlössen, Geld." Während sie Ausschau nach einem geeigneten Produkt hielten, hatte einer von ihnen eine Idee, die rückblickend betrachtet äußerst interessant war. „John Gilmore schlug vor, dass wir einen freien Kernel für den 386er schreiben sollten", erinnert sich Tiemann. Das war 1990, ein ganzes Jahr bevor Linus sich auf seine vier Buchstaben setzte und genau das tat. „Ich hielt mich immer für einen unvoreingenommenen Menschen", erklärt Tiemann, „aber die Idee, etwas wie Unix zu nehmen und es auf einem Intel 386 zu betreiben, überforderte einfach mein Vorstellungsvermögen. Ich hatte nicht das Gefühl, dass das ein richtiger Prozessor war. Und ich hatte nicht das Gefühl, dass Benutzer, die PCs kauften, richtige Benutzer waren." Diese Aussage spiegelt die Gefühle jener Leute wider, die den Sinn des Portierens eines echten Betriebssystems für einen so lächerlichen Prozessor bezweifelten, als Linux herauskam. Das war nicht das letzte Mal, dass eine Chance in Form von GNU/Linux an die Tür klopfte. „Adam Richter, der erste Lieferant von Linux auf CD, Yggdrasil, kam zu mir und bat mich um einen geschäftlichen Rat", erinnert sich Tiemann. „Und ich schüttete ihm


--------------------------------------------------------------------------------------mein Herz aus und erzählte ihm, welche Fehler wir gemacht hatten und welche nicht. Leider war er völlig desinteressiert daran, sich mit Cygnus zusammenzutun." Auch später ließ sich Cygnus um Haaresbreite eine Chance entgehen. „1995 kam Larry McVoy" - Autor des Sourceware-Dokuments - „zu mir und sagte: ,Da ist diese Firma in North Carolina, die sich mit Linux beschäftigt. Die verdienen eine Menge Geld, gemessen an der geringen Zahl ihrer Mitarbeiter. Sie sollten sich das mal ansehen." Ich versuchte damals, meine Partner davon zu überzeugen, dass wir Red Hat kaufen müssten. Aber sie wollten nichts davon hören. 1990-91 hatte ich Nein zu John Gilmore gesagt, und 1995 war er es, der mir einen Korb gab. Da gab es also dieses lange, lange Chancenfenster, das wir einfach ignorierten." Das Problem war nicht die mangelnde Vision. Schließlich hatte Tiemann 1992 bei der Sun-Users-Group-Konferenz einen Vortrag gehalten, bei dem er nicht nur auf die Stärken der Bewegung der freien Software einging, sondern auch prognostizierte, dass sie sich in den folgenden Jahren zur dominierenden Kraft entwickeln würde. Das Problem lag auch nicht in mangelndem Ehrgeiz. Zum Teil weil Cynus so erfolgreich geworden war - „1995 verdienten wir allein in unserem Kerngeschäft mehr als 10 Millionen Dollar" -so Tiemann, beschloss das Unternehmen, bei dem zu bleiben, was es am besten konnte. „Es ist ungeheuer problematisch zu sagen, wir steigen hier und jetzt aus diesem Rennen aus und fangen bei Null wieder an." Das Produkt, dem diese eindrucksvollen Einnahmen zu verdanken waren, war GNUPro, das eine umfassendere und besser integrierte Entwicklungsumgebung bot, basierend auf freier Software wie GCC. „Wir vertraten die Theorie, dass wir ein fokussiertes Produkt brauchten, mit dem sich die Leute identifizieren konnten", erklärt Tiemann. Der Erfolg von Cygnus bewirkte, dass das Unternehmen nicht nur auf GCC aufbaute, sondern auch zum Wächter seiner Entwicklung wurde. „Stallman schrieb die Originalversion" von GCC, so Tiemann. „GCC2 kam kurz nach der Gründung von Cygnus heraus. Es basierte zu einem großen Teil auf der Arbeit, die ich vor der Cygnus-Zeit geleistet hatte", sagt er. „Aber ab 1991 arbeiteten mehr


------------------------------------------------------------------------------------Vollzeitleute an GCC als an irgendeinem anderen einzelnen Projekt, und heute haben wir, zumindest an der Größenordnung gemessen, mehr." Auch hier gab Cygnus wieder den Ansatz vor, der später von anderen Unternehmen, die sich mit freier Software beschäftigten, übernommen wurde. So übernahm zum Beispiel Red Hat viele der SpitzenKernelhacker. Die Liste ist eindrucksvoll. Sie enthält Namen von Leutnants wie Alan Cox, Dave Miller und Stephen Tweedie und anderer Hackerstars wie den des Ungarn Ingo Molnär. Das andere Unternehmen, das auf ein eindrucksvolles Portfolio großer Namen der Open-Source-Welt verweisen kann, ist VA Linux. Zu den mit dem Unternehmen assoziierten Spitzenleuten gehören Ted Ts'o, Eric Raymond und John „Maddog" Hall. Angesichts der Parallelen zwischen Cygnus und den GNU/ LinuxDistributionsfirmen, die danach kamen, und des unglaublichen Reichtums an Talenten, auf den Cygnus auf dem Gebiet der OpenSource-Tools verweisen konnte, ist es wohl kaum überraschend, dass Red Hat Cygnus am 15. November 1999 übernahm. Cygnus hatte seine Fühler bereits davor ausgestreckt - und war abgewiesen worden. „Wir redeten mit Red Hat und bekamen Anfang 1999 einen Korb", erzählt Tiemann, „weil ihnen eines ihrer Board-Mitglieder sagte, dass eine Fusion zweier kleiner Unternehmen auf keinen Fall etwas brächte." Zu dieser Zeit hatte Red Hat, wie er sich erinnert, vierzig Mitarbeiter. Die Dinge sollten sich jedoch ändern. „Nach ihrer erfolgreichen Börseneinführung", sagt Tiemann, „konnten sie beginnen, nach strategischen Partnern Ausschau zu halten. Wie sich zeigte, passten wir sehr gut zusammen. Cygnus hatte viel von dem technischen Know-how, das Red Hat brauchte, vor allem was Entwicklungstools anbelangte." Cygnus half Red Hat auch bei der Verwirklichung seiner Vision, einen größeren Anteil seiner Erträge aus Dienstleistungen zu beziehen. Zum Zeitpunkt der Übernahme bezog Cygnus 60 bis 70 Prozent seines Umsatzes aus Dienstleistungen, und bei Red Hat „machte ihr BoxProdukt wahrscheinlich mehr als 80 Prozent aus", sagt Tiemann. Obwohl die Philosophien der beiden Unternehmen - und die von Tiemann und Bob Young von Red Hat


--------------------------------------------------------------------------------------- einander ähnlich waren, brachte Red Hat Cygnus in einem Fall dazu, seinen Ansatz etwas zu ändern. Im Gegensatz zu Bob Young, der glaubt, dass die Open-Source-Natur der von ihm verkauften Produkte entscheidend für ihren Wert für die Kunden ist, hat Tiemann sich in Bezug auf die Aufnahme urheberrechtlich geschützter Elemente eine pragmatischere Einstellung zugelegt. „Man wird in einer kapitalistischen Umgebung", ist er überzeugt, „letzten Endes doch im Vergleich zur Konkurrenz beurteilt." Aber Tiemann hat erkannt, dass eines der Schlüsselmerkmale der Marke, die Red Hat aufgebaut hat, in etwas besteht, was er „das ,Versprechen der immerwährenden Offenheit‘ nennt - dass die Firma nie etwas anderes als Open-Source-Produkte herausbringen wird. „Und wie sich zeigt, sticht dieser Markentrumpf so gut wie alles." Er erklärt dazu: „Ich bin kein Befürworter davon, Open Source als Selbstzweck zu verfolgen. Aber ich bin unbedingt dafür, Open Source als Komponente einer effektiven Markenstrategie zu verwenden." Die Frage, wie - und sogar ob - kommerzielle Produkte, die auf freier Software basieren, um urheberrechtlich geschützte Elemente erweitert werden sollten, bleibt weiterhin einer der Prüfsteine für Unternehmen, die in diesem Bereich tätig sind. Es war eine Frage, mit der sich Eric Allman auseinander setzen musste, als er sich entschloss, Sendmail, Inc. zu gründen. Im Gegensatz zu Tiemann war das Motiv des ewig bescheidenen Allman nicht die Überzeugung, dass seine freie Software so gut sei, dass es möglich sein sollte, einen Gewinn aus ihr zu ziehen. „Ich gründete Sendmail, Inc. nicht, um Geld zu verdienen, obwohl das durchaus etwas Nettes ist", sagt er. „Ich tat es, um Sendmail nachhaltig zu machen, um eine großartige Innovation durchzuführen. Ich tat es, um die Welt kleiner zu machen." Diese Aussage spiegelt wieder einmal seinen zentralen Glauben an den Gemeinschaftsaspekt freier Software wider. In den Anfangszeiten wurde das Sendmail-Programm von Allman allein unterstützt - „in den Nächten und an Wochenenden" - wie er es ausdrückt. Er sagt dazu:


------------------------------------------------------------------------------------Ich bin ein leidenschaftlicher Anhänger von Open Source, aber leider wurde Sendmail zu einem Opfer seines eigenen Prozesses. Wir durchliefen eine Zeit, als die Internetstandards im E-Mail-Bereich drastisch erweitert wurden. Ich stellte fest, dass es mir nicht möglich war, die erforderlichen Ressourcen bereitzustellen, und so konnte Sendmail der Nachfrage bald nicht mehr gerecht werden. Als ich an der späteren Sendmail-Version 8 zu arbeiten begann, richtete ich eine großteils offene Mailingliste für Leute ein, die Anfang 1993 Tests durchführten. Es zeigte sich bald, dass es auf dieser Liste ein paar Leute gab, die außerordentlich gut waren. Sie stellten nicht nur gute Fragen und wiesen auf Bugs und so weiter hin, sondern sie steuerten auch Fixes bei. Deshalb richtete ich eine weitere Liste ein, die als Unterstützungsliste gedacht war. Das war nur eine Einladung, aber ich veröffentlichte diese Adresse, damit die Außenstehenden, die Fragen hatten, diese Fragen an diese Liste schicken konnten, und damit nicht nur ich es war, der antwortete. Viele Leute, die am Anfang auf dieser Liste standen, sind immer noch da. Es ist ein wirklich harter Kern. Die zweite Liste wurde Anfang 1996 erstellt, wie er sagt. „Als sich Sendmail entwickelte", erklärt Allman, „ging viel Unterstützung auf diese anderen Leute über, und ich konnte an der Entwicklung weiterarbeiten. Und ein oder zwei dieser Leute halfen mir dabei immer mehr. Aber es begann klar zu werden, dass das nicht aufrechtzuerhalten war. Das Internet explodierte, es verzeichnete Zuwachsraten von 100 Prozent jährlich oder so, und die Benutzerbasis wuchs viel schneller, als ich es konnte." So begann er, nach anderen Lösungen Ausschau zu halten. „Mein erster Versuch bestand darin, etwas zu schaffen, wofür ich Finanzierungsmittel auftreiben könnte", fährt Allman fort. „Ich hatte die Fantasie, dass ich eigentlich in der Lage sein müsste, tun zu können, was mir vorschwebte, wenn Sun, Digital, IBM und SGI und ein paar andere je 50.000 Dollar beisteuerten, etwa die Hälfte oder ein Drittel der Kosten eines guten Ingenieurs. Dann würden sie


--------------------------------------------------------------------------------------etwas Gutes bekommen, und ich auch, und alle würden zufrieden sein. Aber ich brachte es nicht zustande." Das war Fnde 1996. Anfang 1997 lebte Allman von Beratertätigkeiten - „hauptsächlich im Bereich Sendmair, sagt er. „Ich fantasierte, dass ich lächerlich hohe Beträge verlangen und dann nur noch halbtags arbeiten würde. Den Rest der Zeit könnte ich mich dann mit Sendmail beschäftigen." Auffallend ist, dass Allmans „Fantasie" nicht darin bestand, dass er durch „lächerlich hohe Beträge" reich werden wollte, sondern dass er damit seinen Lebensunterhalt bestreiten wollte, um an Sendmail arbeiten - und die Ergebnisse dann verschenken - zu können. „Dabei", so berichtet er, „stieß ich auf Greg Olson", einen alten Freund. „Er war Berater für Marktstrategien, Unternehmensentwicklung und solche Dinge", fährt Allman fort. „Olson fragte mich, was ich so tat, und ich antwortete: ,Nun, ich versuche, ein nachhaltiges Modell für Sentlmail zu finden." Und Olson sagte: ,Ich will dir etwas sagen. Du bist ein alter Freund, ich mache das normalerweise zwar beruflich, aber ich werde es mir für dich privat ansehen‘. Also fing er an. Er betrieb etwas Marktforschung und sprach mit Kunden und kam dann zurück und sagte zu mir: „Weißt du, du hast da die Grundlagen eines Dynamitgeschäfts." Die Gründe waren einfach. „Wunderbarer Markt, unglaubliche Marktpenetration. Wir sagen normalerweise, dass 75 Prozent der Mailserver im Internet Sendmail oder Sendmailvarianten sind", erklärt Allman. „Der Markt war nicht nur schon damals riesig, sondern er wuchs auch noch mit einer unglaublichen Geschwindigkeit E-Mail ist eine Killerapplikation des Internets und ist es immer gewesen." Sendmail Inc. würde bestehenden und neuen Benutzern eine umfassende Unterstützung auf Unternehmensbasis sowie kommerzielle Versionen der Software mit neuen Features anbieten. Schließlich gelang es Allman und Olson, von Leuten wie Bill Joy und dem Mitbegründer von Sun, Andy Bechtolsheim, 1,25 Millionen USDollar aufzutreiben. „Wir verwendeten einen Teil dieses Geldes, um ein wenig PR zu betreiben. Das erwies sich als kluger Schachzug, weil wir es auf diese Weise, als wir die Firma im März '98 gründeten, auf die Titelseite der New York Times schafften.


------------------------------------------------------------------------------------Dabei löste Sendmail Inc. jene Neugier aus, die die Open-SourceAnkündigung von Netscape nur ein paar Monate früher ausgelöst hatte. Das Thema freie Software wurde dadurch so lange im öffentlichen Bewusstsein gehalten, bis IBM mit seiner Annahme von Apache im Juni 1998 die Ankündigungslawine kommerzieller Unterstützung lostrat. Während Allman und Olson Ausschau nach Investoren hielten, verloren sie die Reaktionen der Hacker nicht aus den Augen. „Das war uns sehr wichtig", sagt Allman. „Und wir verbrachten viel Zeit mit Nachdenken, wie wir ihnen versichern konnten, dass wir nicht versuchten, mit Technologie schnell reich zu werden, indem wir Sendmail zu einem geschützten Programm machten." „Sowohl Greg als auch ich sind fest davon überzeugt, dass die Beiträge der Gemeinde ein wichtiger Bestandteil des Erfolgs von Sendmail sind", betont Allman. „Wenn wir diese Beiträge verlieren, verlieren wir einen großen Teil des Warum und des Wie unseres Erfolgs. Deshalb fühlen wir uns dem Open-Source-Modell weiterhin stark verpflichtet" Aber er fügt hinzu: „Das soll nicht heißen, dass alles Open Source ist - wir sind schließlich eine Hybridfirma. Aber das Konzept ist, dass das Kernmaterial, das Zeug, das man braucht, um die Innovation voranzutreiben, um damit im Wesentlichen das Internet voranzutreiben, Open Source ist." Dieser Aussage entspricht das, was Allman als „moralische Verpflichtung gegenüber unseren Investoren" bezeichnet, Geld für sie zu verdienen. „Deshalb können wir nicht alles verschenken. Wir würden zweifellos schon jetzt mehr Geld verdienen, wenn wir sagten, dass die nächste Version von Sendmail nur gegen Gebühr erhältlich ist", sagt Allman. „Aber in einem Jahr würde sich zeigen, dass das eine sehr schlechte Entscheidung gewesen wäre. Aus dem Blickwinkel eines rein kapitalistischen Modells sind wir also besser beraten, Open Source beizubehalten. Vorausgesetzt, unsere Annahme, dass es sich um ein langfristiges Spiel handelt, stimmt." Das ist ein wichtiger Punkt: Firmen, die versuchen, freie Software zu schützen - was nur gemäß einigen Lizenzen möglich ist -, schneiden sich selbst genau von der Quelle ab, die sie anzuzapfen versuchen. Damit ihr Produkt florieren kann, brauchen sie eine florierende freie Gemeinde, Wie Allman und Olson


--------------------------------------------------------------------------------------erkannten, ist die Gesundheit ihres Unternehmens eng mit der Kraft der Gemeinde verbunden, die es umgibt. Allmans Ansicht» dass Sendmail nicht gewachsen wäre, hätten nicht er oder jemand anders eine Open-Source-Firma gegründet, um es zu unterstützen und zu pflegen, wird von einem Pionierkollegen der freien Software, John Ousterhout, geteilt. Wie Allman und viele andere verfügt Ousterhout über starke Verbindungen zur University of California in Berkeley» wo er Professor für Computerwissenschaften war. Ousterhout wurde durch seine Sprache Tcl (ausgesprochen: „tickl") bekannt, die als „Toolbefehlssprache* für die Erstellung von Designtools für integrierte Schaltkreise begann, und Tk, einem Toolkit für die Herstellung grafischer Schnittstellen. Ousterhout schrieb diese Sprache ab 1988 ursprünglich für sich selbst und seine Studenten. „Tcl sickerte Ende '89 in die Außenwelt durch", erzählt er. „Ich hatte damals ein paar Kopien verschenkt, und nun trudelten die ersten Kommentare von den Leuten ein. In den Jahren '90 und '91 kam die Sache dann so richtig in Schwung." Wie bei Stallman und Wall war dieses Feedback insofern entscheidend, als es ihn dazu motivierte, mit der Entwicklung seiner Software fortzufahren. „Für mich ist das Spannendeste an der Entwicklung von Software das Wissen, dass es dort draußen Dutzende Leute gibt, die sie benutzen", sagt er. Ousterhout weist darauf hin, dass dies eine der wichtigsten Triebfedern des Open-Souree-Prozesses ist. „Es ist etwa das Gegenteil des Designs durch ein Komitee“, erklärt er. „Man hat zwar alle Vorteile eines riesigen Ideenpools, aber es ist kein demokratisches System. Meistens gibt es eine Person, die als Gottvater betrachtet wird und das endgültige Sagen darüber hat, was letzten Endes in das Paket kommt. Einer der großen Vorteile ist, dass man ein Maß an architektonischer Einfachheit und Einheitlichkeit erhält, das man nie bekommen würde, wenn das Design von einem Komitee oder von zig Leuten durchgeführt würde, die alle voll über Veränderungen am Kern des Systems bestimmen könnten." Ousterhout räumt ein, dass er es versäumt hat, eine Idee weiterzuverfolgcn, die von seinen Benutzern an ihn herangetragen wurde. „Wir begannen Geschichten über diesen verrückten Physi-


------------------------------------------------------------------------------------ker zu hören, der diese eigenartige Idee von etwas hatte, was das World Wide Web genannt wurde", erinnert er sich. „Jemand entwickelte dieses Paket namens TkWWW, das eine grafische Methode zur Anzeige dieses Webzeugs war, das von diesem Typen in der Schweiz erfunden worden war." Das war 1992, kaum ein Jahr nachdem „dieser Typ in der Schweiz" - Tim Berners-Lee - das Web veröffentlicht hatte, und einige Zeit bevor das Mosaic-Browserprojekt der NCSA an der University of Illinois gestartet worden war. Verstärkt wurde die Peinlichkeit, wie Ousterhout reumütig vermerkt, dadurch, „dass ich TkWWW nie startete. Ich fand, dass dieses World-Wide-Web-Ding ziemlich fragwürdig war. Eines der Dinge, auf die man zurückblickt und für die man sich am liebsten in den Hintern beißen würde." „Ich war damals etwa ein Dutzend Jahre in Berkeley gewesen", fahrt er fort, „und ich wollte schon immer einen guten Teil meines Berufslebens in der Industrie verbringen, nicht nur in der Wissenschaft." Der endgültige Anstoß war die Erkenntnis, dass Tcl mit zunehmender Popularität mehr Unterstützung brauchen würde als die Open-SourceStruktur zu bieten hatte. Wie Eric Allman meinte Ousterhout: „Ich glaube, dass es eine Reihe von Dingen gibt, die man in einem reinen Open-Source-Projekt sehr gut machen kann, und andere, die in einem solchen Projekt tendenziell nicht getan werden. All die zusätzlichen Dienste und Mehrwertelemente, die man braucht, wenn die Firma das Produkt für missionskritische Applikationen verwenden will Entwicklungstools, höherwertige Facilities; solche Dinge werden in einem reinen Open-Source-Projekt meist nicht entwickelt." In der Folge entschloss er sich, Berkeley zu verlassen und bei Sun an Tcl weiterzuarbeiten. Anfang 1994 trat er in die neue Firma ein. Dieser Schritt wurde kritisiert, insbesondere von Richard Stallman, der einen für ihn typisch direkten Ruf zu den Waffen mit dem Titel „Warum Sie Tcl nicht verwenden sollten" veröffentlichte. Ousterhout erklärt den Grund. „Als ich zu Sun ging, tat ich damit kund, dass es meiner Meinung nach in Ordnung war, rund um Open-Source-Software ein kommerzielles Geschäftsmodell aufzubauen", sagt er. „Das ärgerte Stallman natürlich furchtbar, und deshalb versuchte er, die Leute dazu zu bringen, Tcl als Zeichen des


--------------------------------------------------------------------------------------Protests nicht zu verwenden." Was Stallman am zornigsten machte, war die Tatsache, dass das kommerzielle Modell urheberrechtlich geschützte Software beinhalten würde. „Sie waren davon überzeugt, dass Sun versuchen würde, Tel irgendwie zu schützen", sagt Ousterhout. „In Wahrheit hatte ich mit Sun vereinbart, dass wir das Open-Source-Tcl weiterentwickeln und es frei verteilen würden. Das war meine Vereinbarung mit Sun. Aber wir würden auch kommerzielle Dinge entwickeln. Wir hatten Prototypen von einigen kommerziellen Produkten hergestellt, die wir rund um Tcl bauen wollten, und wenn alles gut ging, würde Sun diese Produkte verkaufen, während der Quellcode von Tcl weiterhin verschenkt werden würde." „Wir waren so weit gegangen, dass wir begannen, bei Sun eine neue Geschäftseinheit aufzubauen", erinnert sich Ousterhout. „Sie sollte SunScript heißen. Aber nach ein paar Monaten wurde der Beliebteste unter den Führungskräften von Sun, Eric Schmidt, CEO von Novell. Kurz nach seinem Weggang wurde mir klart dass wir einfach nicht die Unterstützung und die Begeisterung in der Führungsetage von Sun haben würden, die wir brauchten, um dieses Projekt zu einem langfristigen Erfolg zu machen." Nachdem er erkannt hatte, dass Sun sich Tcl nicht besonders verpflichtet fühlen würde, unter anderem deshalb, weil die Firma um diese Zeit mit intensiver Werbung für ihre eigene Programmiersprache Java begann, verlangte Ousterhout die Stornierung des Projekts. „Aber im Rahmen dieser Stornierung", so sagt er, „einigten wir uns darüber, dass wir die ganze Software, die wir zu kommerzialisieren beabsichtigten, im Internet freigeben würden." Damit opferte er großmütig seine eigenen Interessen zugunsten der Tcl-Gemeinde. Ousterhout stand vor einer kritischen Entscheidung: Sollte er Tel ganz aufgeben oder sollte er eine eigene Firma zu seiner Unterstützung gründen? „Anfang Sommer 97 ließen wir SunScript fallen", erinnert er sich. „Über den Sommer und Herbst machte ich dann allerlei Probeläufe, um festzustellen, ob es mir gelingen würde, genügend Geld für die Gründung eines Unternehmens aufzubringen. Es sah ganz gut aus, und so verließ ich Sun im Januar 98, um Scriptics zu gründen." Ousterhout konnte von Glück reden, dass im


------------------------------------------------------------------------------------Rahmen der Vorbereitungen für die Entwicklung von SunScript „bei Sun etliche Marktstudien durchgeführt worden waren, um herauszufinden, welche Produktarten entwickelt werden sollten und wo die Nachfrage war", sagte er. „Also hatten wir bestimmte Hinweise, dass die Gemeinde zumindest da war und dass Interesse an den Entwicklungstools bestand.“ Das erste Produkt von Scripties, TclPro, bot eine erweiterte Entwicklungsumgebung, wie es auch GNUPro von Cygnus getan hatte. Outsterhout erinnert sich, dass die meisten Tcl-Benutzer akzeptierten, dass es neben dem Open-Source-Tcl auch neue, geschützte Elemente gab. Diese Gemeinde war bereits ziemlich groß: Ousterhouts Schätzungen zufolge gab es rund eine halbe Million Tcl-User, als Scriptics gegründet wurde, und heute sind es wahrscheinlich über eine Million, „Wir schrieben '98 unsere eigenen Entwicklungstools", erklärt er. „Aber wir dachten darüber nach, welche Bereiche interessant sein könnten und wo die Leute Integrationsanwendungen brauchten, auf die wir Tcl anwenden konnten. Das Ganze lief ziemlich eindeutig auf B2B [Business-to-Business E-Commerce] hinaus." Das daraus resultierende Produkt Connect war ein ambitioniertes Stück Unternehmenssoftware, das es den Unternehmen erlaubte, ihre jeweiligen Computersysteme miteinander zu verbinden, indem sie XML (eXtensible Markup Language) als plattformunabhängiges Format für den Austausch von Informationen unter Netzwerken wie Internet verwendeten und Tcl für die Integration. Die darauffolgende Verbreitung globaler B2B-Exchanges zeigt, wie klug es von Ousterhout war, auf diesen Bereich zu setzen. Entsprechend dem neuen Schwerpunkt des Unternehmens wurde Scriptics im Mai 2000 auf Ajuba Solutions umbenannt, und Connect wurde zu Ajuba2. Ousterhouts folgende Aussage überrascht nicht besonders: „Wir bieten derzeit eine Menge Dienstleistungen an. Eine der allgemeinen Lektionen, die ich in den letzten Jahren gelernt habe, ist, dass die größten Chancen im Dienstleistungsbereich liegen, wenn man in einem Geschäft tätig ist, das ausschließlich auf Open-Source-Produkten basiert." Dem würde Dave Sifry, Mitbegründer und Technikchef von Linuxcare, einer Firma, die ausschließlich Dienstleistungen für den


--------------------------------------------------------------------------------------GNU/Linux-Unternehmensmarkt anbietet, sicher zustimmen. Das Unternehmen wurde unter ziemlich eigenartigen Umständen gegründet Sifry und die Mitbegründer Arthur Tyde und Dave Le Duke waren einem weiteren Risikokapitalgeber mit einem Businessplan in den Ohren gelegen, den sie schon früher entwickelt hatten. „Wir hatten im September 1998 diesen Augenblick der Wahrheit erlebt", erinnert sich Sifry. „Wir hatten gerade wieder einmal eine höfliche Abfuhr bekommen. Danach saßen wir ganz deprimiert am Parkplatz", fährt er fort. „Und da überlegten wir: Was können wir eigentlich am besten? Worin sind wir allen anderen in Erfahrung und Wissen zwölf Monate voraus? Und wo besteht ein echter Bedarf, den wir befriedigen können?" „Darüber zerbrachen wir uns den Kopf\ sagt Sifry, „und dann sagte einer von uns plötzlich: ,Nun, es gibt noch keine gebührenfreie 800Telefonnummer für Linux ' - niemand konnte anrufen, wenn er Unterstützung brauchte. „Das war eigentlich die Grundidee für Linuxcare." Wie richtig sie mit ihrer Idee lagen, zeigte sich darin, wie schnell sie Investoren fanden, darunter so klingende Namen wie Kleiner Perkins - der den größten Teil der Finanzierung für Netscape bereitgestellt hatte -, Michael Dell und Hasso Plattner, CEO von SAP. Linuxcare bot eine Reihe von Dienstleistungen an, darunter Support, Consulting und Training. Die Software umfasst den Linux-Kernel sowie alle Open-Source-Applikationen, die mit einer Linux-Distribution mitgeliefert wurden", sagt Sifry. Von Anfang an hatten er und seine Mitbegründer erkannt, dass mit einem derartigen Modell ein grundlegendes Problem verbunden war. „Das größte Einzelproblem bei einem Dienstleistungsgeschäft besteht darin, dass es traditionell nicht gut skalierbar ist. Zum Schluss endet man als Karosseriewerkstatt, und die Verwaltungskosten pro Mitarbeiter werden immer höher, je mehr Leute man hat". Das war das Problem, mit dem Cygnus in seinen frühen Jahren konfrontiert gewesen war. Laut Sifry kamen sie zu der Erkenntnis, die Lösung bestünde darin, „im Web eine Wissensbasis aufzubauen, wobei wir alles, was wir in dem Geschäft tun wollen, dort hineinstellen. Denn das Letzte, was man in einer solchen Situation will, ist dieselbe Frage zweimal beantworten zu müssen."


------------------------------------------------------------------------------------Wie andere Unternehmen, die im Umkreis von Open Source gegründet wurden, musste sich auch Linuxcare mit der Frage der geschützten Software auseinander setzen. „Wir sind nicht so streng, dass wir darauf bestehen, dass alles unter der GPL laufen muss", erklärt Sifry. „Wir betrachten das als Bildungsprozess. Es läuft darauf hinaus, dass wir dem Kunden sagen, hier oder dort könnte Open Source nützlich für Sie sein. Hier könnte es in einem Jahr für Sie nützlich sein. Aber hier hat es derzeit keinen besonderen Nutzen für Sie." Trotz dieses Pragmatismus - „Der Kunde kommt zuerst, keine Frage", sagt Sifry - bekennt sich Linuxcare weiterhin zu Open Source und nicht zu geschützter Software. „Aber wir zwingen unsere Leute zu nichts. Wir sagen nur, seht her, ihr könnt ruhig hier in der Firma an Open-SourceProjekten arbeiten." Sifry betrachtet diese Ermutigung als zentralen Teil der Kultur von Linuxcare und als Erfolgsrezept. „Abgesehen von der rein moralischen Seite, das Richtige zu tun", sagt er, „gibt es auch eine ganze Reihe von strategischen Geschäftsgründen, warum wir das tun." „Erstens locken wir dadurch die besten Entwickler der Welt an. Wenn wir zu den Leuten sagen, wir wollen, dass ihr in der Firma an Open Source arbeitet, dann ist das ziemlich einzigartig. Und wenn wir einige der Besten an Bord geholt haben, kommen weitere hinzu. Schließlich will jeder mit den Besten arbeiten. Zweirens verwenden umso mehr Leute dort draußen Open-Source-Software, je mehr gute Open-SourceSoftware es gibt. Und das bedeutet, dass umso mehr Leute die Dienste eines Unternehmens wie Linuxcare brauchen. Und wenn wir die Leute drittens ermutigen, während der Arbeitszeit an Open-Source-Software zu arbeiten, bekommen wir Führungskräfte und Teams von OpenSource-Techniker, die für unsere eigene Firma arbeiten. Außerdem, und das darf auf keinen Fall vernachlässigt werden, ist es ausgezeichnete PR." Diese Analyse zeigt, dass das Wichtigste für jedes Open-SourceUnternehmen, vielleicht mehr noch als für konventionelle Unternehmen, die Leute sind, die es beschäftigt. Da das „Produkt" open source und frei verfügbar ist, ist den Unternehmen zwangsweise noch etwas anderes wichtig: die Fähigkeiten der Leute, die diese Software schreiben und warten. Das erklärt zum Teil auch, warum


--------------------------------------------------------------------------------------Red Hat und VA Linux bereit sind, ihren Spitzenhackem so flexible Verträge anzubieten. Viele von ihnen arbeiten von zu Hause aus, oft außerhalb der Vereinigten Staaten. Wie Länuxcare gesehen hatte, dass es möglich war, die Dienstleistungsseite von den Produkten zu abstrahieren, die von den Verkäufern von GNU/Linux-Distributionen immer noch angeboten wurden, versuchte ein weiteres innovatives Unternehmen, einen Schritt weiter zu gehen, indem es einen Markt für diese zunehmend wertvollen Programmiererfähigkeiten schuf. Die ursprüngliche Idee kam von Hewlett-Packard, und es war der dortige Open-Source-Koordinator Wayne Caccamo, der ihre Realisierung in die Hand nahm. „Als ich bei HP mein Netzwerk von Leuten zusammenstellte", sagt er, „stieß ich auf einen Typen, der sich mit Linux exzellent auskannte. Er verfolgte irgendein Projekt, das mit der Entwicklung von Linux zu tun harte, und er war sehr frustriert, weil er externe Softwareunternehmen einbinden musste. Der Prozess bei HP ist wie in jedem großen Unternehmen sehr langatmig." „Er stellte uns das Konzept vor, einen Mittler einzuführen", erinnert sich Caccamo. Dieser Mittler sollte sich um die Einzelheiten des Findens und Engagierens von Open-Source-Unternehmen kümmern. Auf den Vorschlag des Urhebers der Idee hin beschloss Caccamo, mit O'Reilly Et Associates zusammenzuarbeiten. Er hatte festgestellt, dass „sie eine positive Rolle spielten, indem sie die Leute der LinuxGemeinde zusammen brachten" sagt er, „und sie beschäftigten auch Leute aus der Open-Source-Welt, die als Berühmtheiten galten und die hohes Ansehen genossen." Unter diesen Berühmtheiten gab es kaum jemanden, der angesehener gewesen wäre als Brian Behlendorf, der vor kurzem zu O'Reilly gestoßen war. Der Job bei O'Reilly bot sich an, so Behlendorf, „als ich gerade nach etwas Neuem Ausschau hielt. Ich setzte mich mit Tim O'Reilly hin und sprach mit ihm darüber, was man im Open-Source-Bereich tun könnte. Ich hatte das Gefühl, dass es wirklich der Mühe wert war nachzudenken, ob es ein anderes Geschäftsmodell für Open Source gab, das nicht einfach im Verkauf von Support bestand. Er sagte: ,Warum entwickelst du diese Ideen nicht einfach hier bei


------------------------------------------------------------------------------------O'Reilly?'", erinnert sich Behlendorf. „Also trat ich in die Firma ein mit der Absicht, eine Reihe von Ideen zu entwickeln und ihre kommerzielle Machbarkeit zu prüfen." Das war Anfang 1999, genau zu dem Zeitpunkt, als Caccamo O'Reilly als den Mittler ins Auge fasste, den er suchte. Das Ergebnis war SourceXchange, eine Site, auf der Unternehmen Vorschläge für Programmierarbeit posten und Angebote von OpenSource-Codierern einholen konnten. Die Site ist das erste einer Reihe von Projekten, die neue Geschäftsmodelle erforschen sollen, die auf Open Source basieren, und die gemeinsam Collab.Net bilden. Die Liste der Beteiligten liest sich wie das „Who is Who" der führenden Köpfe der Open-Source-Branche. Zu den Mitarbeitern zählen Frank Hecker, der viel dazu beitrug, Netscape davon zu überzeugen, seinen Browser freizugeben, und James Barry, der half, IBM zu Apache zu bekehren. Neben Behlendorf sind Tim O'Reilly und Marc Andreessen Boardmitglieder, und zu den Investoren, die in einer im Juni 2000 abgeschlossenen Finanzierungsrunde 25 Millionen US-Dollar beitrugen, zählen Dell, HP, Intel, Novell, Oracle, Sun und TurboLinux. „Das SourceXchange-Modell ist für größere Projekte ausgelegt", erklärt Behlendorf. „Damit sind nicht die gemeint die schnell jemanden brauchen, um einen Bug für 100 Dollar oder gegen ein Trinkgeld zu beheben. Dafür gibt es andere Sites. Gemeint sind die 5.000 bis 25.000 Dollar-Projekte, diejenigen, in die zwei oder vier Mannwochen Arbeit investiert werden müssen." Angesichts Behlendorfs eigener Geschichte überrascht es nicht, dass der gesamte produzierte Code als Open Source veröffentlicht wird - aber welche spezielle Open-Source-Lizenz angenommen wird, „ist Teil der Verhandlungen", wie er sagt. Behlendorf weist darauf hin, dass nicht nur Unternehmen von SourceXchange profitieren. „Jedes Open-Source-Projekt dort draußen beinhaltet eine Reihe unfertiger Elemente", sagt er. „Dinge, die niemand so wirklich in Angriff nehmen will, weil sie komplex sind, weil sie Spezialwissen erfordern oder weil sie aus dem einen oder dem anderen Grund einfach nicht das sind, womit sich die Leute in ihrer Freizeit gern beschäftigen. Deshalb legten wir das Design nicht für Fixes kleiner Bugs aus, sondern für größere Probleme, für


--------------------------------------------------------------------------------------solche, die verhindern, dass größere Projekte auf die nächste Ebene vordringen." VA Linux ist ein weiteres Unternehmen, dessen Ziel es ist, Hackern Arbeit zu verschaffen, die freie Software zu fördern und dabei auch noch Geld zu verdienen. Ursprünglich zu dem Zweck gegründet, Hardware zusammenzustellen, die für GNU/Linux optimiert war, erweiterte sich der Aktivitätsbereich des Unternehmens bald beträchtlich. „Wir haben unser Systemgeschäft, das darauf abzielt, die beste Hardware und die besten Systeme für Linux bereitzustellen, vor allem für Leute, die Internetsites entwickeln", sagt Larry Augustin, CEO von VA Linux. Neben dem Verkauf der grundlegenden Hard- und Software beschäftigt sich VA Linux auch mit kundenspezifischen Lösungen, und zwar auf eine neuartige Weise. „Wir gehen davon aus, dass das Internet eine großartige Forschungs- und Entwicklungsressource ist. Dort draußen im Internet gibt es unglaubliche Quellcodedepots, die wir als unsere Werkzeugkasten betrachten müssen." „Ein Kunde kommt des Weges und braucht eine Gruppe spezieller Features", erklärt Augustin. „Nun können wir uns das Quellcodearchiv dieser Internetsites ansehen und sagen: Aha, hier haben Sie ein OpenSource-Element, das Ihnen 80 Prozent dessen bietet, was Sie wollen: Wir können aber auch zu dem Kunden gehen und sagen: ,Wir verrechnen Ihnen den Aufwand, den wir investieren müssen, um von 80 Prozent auf 100 Prozent zu kommen, und alles wird Open Source sein. Unser Ziel ist es, mit den Entwicklern auf den Intemetsites zusammenzuarbeiten, um bei diesem Softwareelement tatsächlich von 80 Prozent auf 100 Prozent für den Kunden zu kommen." Augustins Bekenntnis zur Unterstützung bestehender Open-SourceProjekte bewog ihn dazu, eine der Schlüsselressourcen der Gemeinde zu entwickeln. „Im Internet gibt es eine Site namens Freshmeat (www.freshmeat.net), wo Open-Source-Softwareprojek-te angekündigt werden", erklärt er VA Linux übernahm Freshmeat, als es im Februar 2000 die Muttergesellschaft Andover.net kaufte. Zu diesem Zeitpunkt wurden auf der Site täglich rund fünfzig neue Projekte im Bereich freie Software angekündigt. Obwohl Freshmeat eine großartige Anschlagtafel ist - „alle haben es im Visier", wie


------------------------------------------------------------------------------------Augustin sagt -, ist es weniger nützlich, wenn es darum geht, den fraglichen Code zu finden. Die Links sind oft gebrochen, oder oft ist nur eine Version des Programms verfügbar. Augustin kommt zu dem Schluss, „dass wir einen Ort brauchen, wo jedes Mal, wenn etwas auf Freshmeat angekündigt wird, dieses Stück Software irgendwo gespeichert, permanent archiviert und nie gelöscht wird - alle Versionen, für alle Zeiten. Deshalb hatte ich diese Idee einer Site, die ich ColdStorage nannte; das sollte eigentlich zu Freshmeat passen, dachte ich mir." VA Linux begann ColdStorage 1998 zu entwickeln, zu derselben Zeit, als es an einer anderen Idee namens OpenProjects arbeitete. Die Idee hinter OpenProjects war, Hackern im Internet Raum zur Verfügung zu stellen, wo sie die Entwicklung von Open-Source-Software koordinieren konnten. Da das bedeutete, Webseiten, einen FTP-Bereich und Mailinglisten für jedes Projekt einzurichten, „stellten wir fest, dass wir unglaublich viel Zeit allein für die Systemadministration aufwenden mussten", sagt Augustin. „Also sahen wir uns die Sache an, und wir sagten: ,Nun nehmen wir doch die Ideen von ColdStorage und Open-Source-Projekten und legen sie zusammen." Das Ergebnis hieß SourceForge und wurde am 4. Januar 2000 als freier Dienst für Open-Source-Entwickler gestartet. Nur einige wenige Monate später hatte SourceForge bereits rund 5.000 Projekte, darunter viele der wichtigsten, und freie Software im Umfang von mehr als einem Terabyte - einer Million Mbytes, Obwohl zum Teil aus dem Geschäftsmodell von VA Linux heraus entstanden, ist die Gründung von SourceForge ein starker Auftrieb für die Open-Source-Gemeinde. Der Dienst bietet nicht nur ein historisches Depot für Code, das es den Leuten ermöglicht, die Entstehung von Programmen zurückzuverfolgen, indem sie zum Beispiel feststellen, wann ein bestimmter Bug auftrat oder verschwand, sondern stellt auch eine hochwenige, kostenlose Infrastruktur für sich ausdehnende aktuelle Projekte dar. Noch wichtiger ist vielleicht, dass er das Initiieren neuer Projekte erleichtert. Deshalb könnte sich SourceForge als Katalysator für die Entwicklung jener Programme erweisen, auf die Open Source bislang kaum Auswirkungen hatte: die Endbenutzerapplikationen.

15

Trolle und Gnome

WENN MAN BEDENKT, DASS GNU/LINUX AUS UNIX heraus entstand und am Anfang das ultimative Hackersystem war, überrascht es kaum, dass die anfangs erhältlichen Endbenutzerapplikationen wie Editoren, Compiler etc. hauptsächlich für Softwareentwickler oder als kleine Tools für einzelne Aufgaben gedacht waren. Trotzdem erwies sich das völlige Fehlen komplexer Anwendungen als störend, weil sich dadurch unweigerlich die Frage stellte, ob sich die Open - Source Entwicklungsmethode je für diese Softwareklasse eignen würde. Vor diesem Hintergrund wurde das Erscheinen eines freien Programms namens GIMP, ursprünglich ein Akronym von „General Image Manipulation Program' und später für „GNU Image Manipulation Program", mit einiger Erleichterung begrüßt. Das Programm war von zwei Studenten in Berkeley, Spencer Kimball und Peter Mattis, geschrieben worden, obwohl die Univer-


------------------------------------------------------------------------------------sität diesmal keinen Anteil hatte. Kimball und Mattis stehen für eine Welle von Codierern freier Software, die jünger sind als die Pioniere Mattis wurde 1975 in Silicon Valley geboren. Er erklärt, wie das Projekt Anfang 1995 zustande kam. „Ich war im zweiten Semester des zweiten Jahres meines Studiums der Computerwissenschaften", sagt er. „Wir überlegten, ob wir nicht irgendein Projekt anpacken sollten. Ich begann mich eben mit dem World Wide Web zu beschäftigen und wollte Webseiten entwickeln. In der Highschool war ich ein Macintosh-Fan gewesen, und ich hatte Photoshop auf einem Mac installiert." Photoshop von Adobe ist der Defacto-Bildbearbeitungsstandard und wird von vielen Webdesignern zur Erstellung von Grafikelementen für ihre Sites verwendet. Das Programm dominiert in seiner Kategorie genauso wie Excel in der Kategorie Tabellenkalkulation dominiert. „Als ich ans College kam", fährt Mattis fort, „stieg ich auf Unix um. Damals konnte man unter Unix keine coolen Grafiken erstellen. Also sagte ich mir, ich will einfach dieselben Dinge tun können, die mit Photoshop möglich sind. Das schien mir damals nicht so kompliziert. Das Vorhaben war sehr ehrgeizig, aber wir waren diesbezüglich ziemlich naiv." Auch wenn man den klassischen Schlachtruf junger Hacker -„Das kann doch nicht so schwer sein!" - kennt, ist es interessant, dass Mattis vom Apple Macintosh auf Unix umstieg und deshalb die Verfügbarkeit von Anwendungen und Benutzerschnittstellen erwartete, die GNU/Linux zur damaligen Zeit nicht bieten konnte. In gewissem Sinn ist Mattis repräsentativ für eine neue Generation von Hackern, die die unerschütterliche Stabilität und die grundlegenden Betriebssystemrunktionen als selbstverständlich betrachten und jetzt mehr fordern. Obwohl er und andere GNU/Linux weit über seine Befehlszeilenoder X-Window-Ursprünge hinaus pushen sollten, begann Mattis für sein Projekt Programme zu verwenden, die in diesen Umgebungen liefen, und sie beeinflussten ihn stark. „Wir hatten beide Linux installiert", erinnert er sich. „Ich betrachtete Linux damals als keinen wichtigen Vertreter der freien Software, obwohl es das war. Mich begeisterte es vor allem, einen freien Compiler zu haben." Dieser freie Compiler war Stallmans GCC. „Das weckte in mir das

15. Trolle und Gnome

--------------------------------------------------------------------------------------Gefühl, etwas entwickeln zu wollen und damit der Community sozusagen etwas zurückzugeben." Wieder wirkte die Existenz der freien Software als Ansporn für andere, mehr davon zu schaffen und einen Beitrag zu leisten. Angesichts seiner enormen Popularität und der wichtigen Rolle, die das GIMP-Projekt später in der Geschichte von Open-SourceDesktopanwendungen spielen sollte, ist die Erkenntnis, dass ihm ein banales Ereignis beinahe den Garaus gemacht hätte, ernüchternd. „Ich pflegte damals ständig Newsgroups zu lesen", erzählt Mattis. In einer davon fragten Leute, ob es für Unix ein Photoshopartiges Programm gäbe. „Und da war dieser Typ, der antwortete: Jen habe da ein Programm, das ich in etwa einem oder zwei Monaten herausbringen werde. Er listete alle Features auf, die das Programm haben würde. Ich sah mir die Liste an und dachte mir, mein Gott, das kann alles, was unser Programm können wird, und noch mehr." „Einen Augenblick lang dachten wir, dass wir das Ganze vielleicht am besten vergessen sollten", erinnert sich Mattis, „aber dann überlegten wir es uns anders und dachten, nein, wir können etwas daran lernen, machen wir unser Programm doch fertig und veröffentlichen wir es. Das taten wir, und ich hörte von diesem anderen Typen nie wieder etwas." Mattis sagt dazu: „Es ist irgendwie komisch, dass jemand GIMP um ein Haar schon vor seiner Geburt umgebracht hätte, ohne es auch nur zu ahnen." Neben den angekündigten Konkurrenzprojekten, die nie Wirklichkeit wurden, mussten sich die Open-Souree-Anwendungen mit einem noch größeren Problem herumschlagen. Ein Grund, warum es leichter war, serverseitige Programme zu schreiben als solche für den Desktop, lag darin, dass erstere keine komplizierten grafischen Front-End-Systeme brauchten - denn genau das war die Schwäche von Unix. Obwohl X-Window eine grundlegende Windowing-Technologie beinhaltete, bot es den Programmierern etwas nicht, was normalerweise Widgets genannt wird - die grundlegenden Bausteine von Grafikprogrammen. Sie beinhalten Dinge wie Buttons am Bildschirm, Auswahlboxen und all die vertrauten Komponenten, die man auf einem mac- oder windowsartigen Desktop findet. Will


------------------------------------------------------------------------------------man sie haben, muss man auf eines der Toolkits zurückgreifen, die Widgets enthalten, die für die Konstruktion einer grafischen Anwendung verwendet werden können. Das wichtigste Grafik-Toolkit für Unix war Motif. Aber wie Mattis sagt, „fanden wir Motif mühsam. Wir hatten keine klare Vorstellung davon, wie es intern funktionierte." Er weist auf einen Grund für ihre Schwierigkeiten hin: „Es gab keine verständlichen Beispiele dafür, wie man etwas in Motif machte. Ich wollte etwas Neues und Interessantes machen, und es war sehr schwer herauszufinden, wie das gehen sollte." Ein weiterer Grund dafür, dass das schwierig war, lag darin, dass Motif keine Open Source oder auch nur kostenlose Software war. Deshalb wurde es normalerweise gemeinsam mit geschützten Programmen angewendet, deren Quellcode nicht verfügbar war, wodurch es noch schwieriger wurde, das Programmieren zu erlernen. Trotzdem schlugen sich Kimball und Mattis weiter mit Motif herum und entwickelte Version 0.54 von GIMP, die im Februar 1996 herauskam: „Es war einigermaßen stabil und es konnte einfache Dinge", sagt Mattis. „Besonders ausgefeilt war es nicht." Er erinnert sich: „An diesem Punkt experimentierte Spencer mit der Funktion der Bildverarbeitung." Mittlerweile dachte Mattis: „Dieses Motif ist wirklich frustrierend. Wie würde ich selbst ein besseres Toolkit entwickeln? Ich begann herumzuspielen und mich zum Beispiel zu fragen: Wie würde ich einen Button - eines der grundlegendsten Widgets - machen? Das Ganze entwickelte sich irgendwie von selbst Irgendwann einmal sagte ich mir, wow, du hast ja fast alles, was man für ein echtes Toolkit braucht." So war Linux entstanden. Auch Linus hatte damals erkannt, dass das Ergebnis seines „Herumspielens" fast ein unixartiger Kernel war. Mattis nannte sein Toolkit Gtk: das GIMP Tool Kit. Als er es Kimball zeigte, sagte der: „O.k., sieht gut aus, wir werden auf Gtk umsteigen." Das brachte den beiden einige wesentliche Vorteile. „[Kimball] war frustriert, weil er bestimmte Dinge in Motif nicht verwenden konnte", sagt Mattis. „Der Grund war nicht, dass Motif es nicht zuließ, sondern dass er nicht wusste, wie man es in Motif machte. Aber wenn er etwas in Gtk machen wollte, wusste ich sofort, wie es ging. Oder ich konnte es für ihn einbauen." Gtk war


--------------------------------------------------------------------------------------für ihre Zwecke viel besser geeignet als Motif, aber es war noch immer nicht das Richtige. „Wir mussten feststellen, dass es unvollständig war", sagt Mattis. „Da gab es Dinge, die durch die ursprüngliche Programmierweise von Gtk erschwert wurden." Mattis schrieb fast sein gesamtes Toolkit neu und nannte es Gtk+. Der Umstieg auf Gtk und danach auf Gtk+ hatte einen weiteren, noch wichtigeren Vorteil. „Als wir auf Gtk umstiegen", erinnert sich Mattis, „begannen sich plötzlich jede Menge Leute mit den Innereien von GIMP zu beschäftigten, und sie sagten, o.k., wir können das jetzt modifizieren, weil wir auch Zugang zum Toolkit haben. Es war also nicht, dass man nun viel leichter etwas tun konnte, sondern dass viel mehr Leute begannen, interne Beiträge zu leisten. Das war es, was Spencer und mir letzten Endes die Freiheit gab, das Projekt in andere Hände zu legen." Anders ausgedrückt, begannen die klassischen OpenSource-Vorteile, dass Bugs behoben und Codeelemente eingesandt wurden, erst dann schlagend zu werden, als die Benutzer den gesamten Code sehen konnten - etwas, was in der Zeit, als die geschützten MotifBibliotheken verwendet wurden, nicht möglich war. Gtk sorgte somit nicht nur für die Weiterentwicklung von GIMP, sondern für sein Überleben an sich. Mattis und Kimball beschlossen nach einiger Zeit, dass sie genügend Zeit und Energie in dieses Projekt und in die Welt der freien Software investiert hatten. Sie wollten zu etwas anderem übergehen. „Ich war anfangs ein wenig verstimmt, als ich feststellen musste, dass es niemanden gab, der sich der Sache sofort angenommen härte", räumt Mattis ein. „Aber rückblickend betrachtet konnte man das auch kaum erwarten." Der Grund lag darin, dass GIMP ein komplexes Programm war und dass es sogar nach der Übernahme der offenen GtkBibliotheken eine Zeit lang dauerte, bevor andere Hacker genügend Selbstvertrauen hatten, um die Entwicklung fortzusetzen. Trotz seines zu Recht erworbenen Ruhms war GIMP nicht die einzige freie grafische Anwendung, die Anfang 1995 herauskam. Zur selben Zeit begann in der deutschen Universitätsstadt Tübingen ein weiterer Student der Computerwissenschaften, Mattias Etirich, geboren 1972, an einem ambmonierten persönlichen


------------------------------------------------------------------------------------Projekt zu arbeiten: einer Dokumentenverarbeitung für GNU/Linux namens LyX (ausgesprochen: lux). LyX war keine Textverarbeitung, sondern eine Dokumentenverarbeitung; ihr Kernstück war die Satzsprache TEX (ausgesprochen tech) von Donald Knuth, die viele Designentscheidungen automatisch traf. „TEX macht fast alles automatisch", erklärt Ettrich. „Dinge, über die man sich nicht den Kopf zerbrechen will, die Platzierung von Bildern, Zeilen- oder Seitenumbruch - all das wird ohne diese hässlichen Fehler erledigt" Ettrich begann aus Freude am Hacken mit der Entwicklung von LyX. Außerdem wollte er es zum Verfassen seiner Prüfungsarbeiten an der Universität haben. Anders als GIMP wurde LyX jedoch Gegenstand eines offiziellen Projekts eines Universitätskurses. Ettrich kündigte seinem Professor optimistisch an, dass er innerhalb von drei Wochen etwas Brauchbares würde vorlegen können. „Damit lag ich aber weit daneben", berichtet Ettrich. „Ich brauchte ungefähr drei Monate, bevor ich auch nur tippen konnte. Ich glaube, es dauerte vier oder fünf Monate, bis ich etwas herausbrachte und es auf der SunSite anbot", einem der großen Internetgeschäfte, von dem man Software herunterladen kann. Der Schritt hatte unabsehbare Folgen für Ettrich, dieselben, mit denen Linus konfrontiert gewesen war, als er sein Projekt auf einen öffentlichen Server hochgeladen hatte. „Die Post begann hereinzuströmen", erinnert sich Ettrich und fügt hinzu, dass er darauf völlig unvorbereitet war, „weil ich überhaupt nichts über freie Software und ihre Funktionsweise wusste. Mir war das Konzept, dass Leute über das Internet kooperieren, unbekannt", sagt er. „Als ich LyX herausbrachte, sagte ich, o.k., Leute, das hier ist eine Alphaversion. Sie ist nicht wirklich stabil. Das endgültige Produkt werde ich wahrscheinlich als Shareware herausbringen, weil das kenne ich von der DOS-Software her." Shareware bot eine Art Probebetrieb, bevor man kaufte: Wenn man ein Programm, das man heruntergeladen hatte, weiter verwenden wollte, musste man dem Autor eine geringe Gebühr bezahlen, „Die Grundidee war nicht, auf diese Weise reich zu werden", erklärt Ettrich. „Ich dachte mir, dass ich eine Menge Zeit in dieses Ding investiert hatte, dass ich nicht wollte, dass es einging, und


--------------------------------------------------------------------------------------dass ich etwas Zeit für seine Wartung brauchen würde. Ansonsten würde es nichts weiter sein als ein Haufen toter Code." Aber nun bot sich etwas Besseres als Shareware an. „Ich erfuhr aus all dem Feedback, das ich während der Alpha- und Betaphase bekam, dass viele Leute bei dem Projekt mitmachen und mir bei der Wartung helfen wollten. Es war also für das Projekt viel besser zu sagen, o.k., wir stellen es unter eine vollkommen freie Lizenz, wir verlangen absolut kein Geld dafür, bitte helft uns. Und das funktionierte." Die Welt der freien Software mochte unvermutete Vorteile haben, aber sie war auch mit ebenso unvermuteten Problemen behaftet. LyX wurde (ebenso wie die erste Version von GIMP) mithilfe der Bibliotheken von Motif geschrieben - „und das ist keine freie Software", wie Ettrich sagt, „Dann stieg ich auf die Bibliothek von Xforms um, das ebenfalls keine freie Software ist -ich meine, es ist vollkommen frei, man kann es herunterladen, man bekommt den Quellcode, wenn man den Wartungsmann darum bittet, aber es ist nicht frei im Sinn der Free Software Foundation." Das war das Problem. Die Leute, die Ettrich „Hardcore-Fanatiker der freien Software" nennt, waren alles andere als begeistert von der Verwendung nicht freier Software und von der Lizenz, unter der LyX herausgebracht wurde. Die Kritik war ein Schock für Ettrich. „Der Ton dieser Mails war sehr aggressiv, als ob ich ein Verbrechen begangen hätte", erklärt er. „Ich sagte: .Entschuldigt, ich habe ein Jahr da gesessen und Software geschrieben. Ihr könnt sie frei verwenden und mir Feedback geben, wenn ihr wollt, und wenn ihr nicht wollt, dann lasst es eben." Ich verstand überhaupt nicht, warum diese Leute so aggressiv waren. Das war eine ziemlich eigenartige Erfahrung für mich", sagt er. Ettrich stieß etwa um die Zeit auf Linux, als er an LyX arbeitete, aber er wurde bald zum begeisterten Experten. Das DOS-System, das er davor verwendet hatte, vermisste er sicher nicht - „Linux war so viel leistungsstarker als DOS", sagt er - und auch Windows nicht, das damals bei Version 3.1 hielt. „Windows 3.1 hatte eine ziemlich schwache graphische Schnittstelle", erinnert er sich, und er meint, dass seine GNU/Linux-Plattform keine bedeutenden Mängel aufwies.


------------------------------------------------------------------------------------Dann kamen aber zwei neue kommerzielle Programme des Weges, die Ettrichs Sicht der Dinge etwas veränderten. Das erste war das neue Betriebssystem von IBM, OS/2 Warp, das, wie er erklärt, in Deutschland dank cleveren Marketings eine viel größere Rolle spielte als anderswo. Die Einführung dieser smarten neuen grafischen Benutzerschnittstelle (graphical user interface - GUI) mitsamt Dragand-drop-Fähigkeiten, die das Arbeiten mit Dateien und Programmen für technisch nicht versierte Benutzer viel leichter machten, bewirkte, dass sich in den Leuten Zweifel am GNU/Linux-Desktop zu regen begannen. Die darauf folgenden Einführung von Windows 95 und der enorme Erfolg dieses Systems bei den Endbenutzern trug zu diesem wachsenden Unbehagen bei. Es brauchte die Erfahrung eines Nichthackers, der die LyXDokumentenverarbeitung verwendete, um Ettrich aus seiner Selbstzufriedenheit über die Überlegenheit der Methode von GNU/ Linux wachzurütteln. „Ich hatte meine Freundin dazu überredet, LyX zum Verfassen ihrer Arbeiten zu verwenden. Ich tat mein Bestes, Linux schlanker zu machen und eine hübsche Benutzerschnittstelle zu schaffen. Das waren ein paar Menüs hier und ein bisschen Drag & Drop dort. Ich versuchte einfach, etwas Nettes zusammenzustellen, von dem ich immer behauptet hatte, dass es möglich sei, wenn man es nur genug wollte." „Genau das tat ich nun, und sie konnte die Textverarbeitung von einem Icon aus starten. Aber sie entdeckte so viele hässliche Dinge: Dies funktioniert nicht, das ist inkonsistent, und wie mache ich jenes? Ich dachte: Hoppla, die Leute verwenden diese neuen grafischen Benutzerschnittstellen tatsächlich. Also sah ich näher hin und stellte fest, dass es einfach schrecklich war." Schrecklich war es, weil die Grafikprogramme, die unter GNU/Linux liefen, ein Dutzend Toolkits verwendeten, jedes mit seinem eigenen typischen Erscheinungsbild und Ansatz - ein Albtraum für technisch nicht versierte Benutzer. Ettrich begann, die Möglichkeiten zu erforschen, und suchte nach einem Weg, die Einfachheit des Ansatzes von Warp/Windows 95 zu erreichen, dessen Stärken er nun erkannte. „Ich suchte in den gespiegelten Softwaresites" - den großen Depots herunterladbarer Programme „nach Alternativen." Auf seiner Suche stieß er auf ein


--------------------------------------------------------------------------------------neues Toolkit namens Qt. „Ich lud das Ding herunter, spielte damit herum und hatte das Gefühl, oho, das ist ja ganz leicht zu programmieren. Dazu kam, dass es, obwohl es ein kommerzielles Programm war, allen frei zur Verfugung stand, die auf Betriebssystemen,, die das X-Window-System unterstützten - wie GNU/Linux es tat -, freie Software produzierten. Qt kam von einem kleinen norwegischen Unternehmen namens Trolltech, das seinen Sitz in Oslo hatte. Es war 1994 von Eirik Eng und Haavard Nord gegründet worden und hieß ursprünglich Quasar Technologies. „Qt" war das Quasar Toolkit, von den Firmenangehörigen „kjut" ausgesprochen. Der Name Trolltech rührt daher, dass die Firmengründer fanden, dass „er ein bisschen norwegisch" klinge, wie Nord erklärt. „Viele norwegische Firmen heißen irgendetwas mit Troll." Und er fügt hinzu: „Trolle sind große Wesen. Sie leben in den Wäldern oder im Inneren von Bergen. Manche von ihnen sind arglistig und böse, aber es gibt auch gute." Diese Trolle wollten auf jeden Fall Gutes bewirken. Neben den kommerziellen Lizenzen für ihr Qt Toolkit bot Trolltech auch eine freie Version für Leute, die freie Software programmierten. „Wir taten das vom ersten Tag an", merkt Nord an. Die Gründe waren halb pragmatisch, halb idealistisch. „Eine der Optionen" für die Werbung für das neue Qt bei seinem Erscheinen 1996 „bestand darin, Risikokapital aufzutreiben", sagt er, „und das Geld für Inserate auszugeben, die dazu gedient hätten, das Toolkit in Magazinen den professionellen Kunden vorzustellen. Die zweite bestand darin, einfach eine Version zu verschenken, damit die Leute es zu verwenden beginnen konnten. Trolltech entschied sich für die zweite Möglichkeit, teilweise aus einem anderen Motiv heraus. „Eirik und ich hatten von Anfang an Linux, GCC und Emacs verwendet", erklärt Nord, „und wir schätzen freie Software sehr. Auf diese Weise konnten wir der Gemeinde etwas zurückgeben." Je näher Ettrich sich Qt ansah, desto besser gefiel es ihm und desto stärker wuchs seine Überzeugung, dass es ihm jene Desktoplösung bescheren könnte, nach der er Ausschau gehalten hatte. So kündigte er im Oktober 1996 seine Idee für KDE [K Desktop


------------------------------------------------------------------------------------Environment] an: einen vollständigen, freien Desktop für GNU/ Linux, der die grundlegenden Widgets mithilfe von Qt bereitstellte. Ettrichs Ankündigung des KDE-Projekts ist eines der wahrhaft historischen Dokumente der Open-Source-Bewegung. Es ist fast nicht zu glauben, dass er sagt: „Ich schrieb es einfach, in vielleicht zwei Stunden oder so." Seine 3.000 Wörter stellen eine erkenntnisreiche Analyse aller Mängel der aktuellen grafischen Schnittstellen dar, die unter Unix verfügbar sind, sowie eine ungeheuer detaillierte Anleitung, wie man etwas Neues entwickeln könnte, um die Situation zu bereinigen. Einer der vielsagendsten Aspekte ist der Titel des zweiten Abschnitts: „Eine GUI für Endbenutzer", der den neuen Schwerpunkt zeigt, der für die bis dahin introvertierte Hackerwelt wahrhaft revolutionär war. Wie scharfsichtig Ettrichs KDE-Ankündigungsdokument war, wird nirgends offenkundiger als in seinen letzten Absätzen. Dort listet er einige der weniger hilfreichen Kommentare auf, die solche Vorschläge unweigerlich auslösen, und er schloss: „Danke, dass so etwas nicht als Follow-up zu diesem Posting gesandt wird :-) Ich weiß, dass ich ein Träumer bin ..." Er träumte allerdings, wenn er je glaubte, durch diese Worte die negativen Kommentare abwehren zu können, die sofort hereinzuströmen begannen. Ettrich dazu: „Wir wurden beschuldigt, zu windowsähnlich zu sein, oder die Leute sagten einfach, aha, ihr wollt mein Linux zerstören." Das sollte wohl durch die Umstellung von der alten, textbasierten Befehlszeile auf etwas bewerkstelligt werden, das laut Ettrich von vielen alten Hackern als dieses „überkandidelte GUIDing" bezeichnet wird. Aber neben diesen hartgesottenen Traditionalisten gab es eine andere, sich stärker artikulierende Gruppe, die Probleme mit dem KDE-Projekt hatte. Ettrich hatte in seiner Liste der voraussichtlichen Reaktionen auf seinen Vorschlag bereits prognostiziert, was diese Leute sagen würden: „Warum Qt? Ich ziehe Schnurz-purz-Widgets mit xyz-lisp-Shell vor. GPL! Nachsehen!" Das Schlüsselelement war hier die GNU GPL oder besser gesagt deren Nichtverwendung. Obwohl Qt von Hackern, die freie Software entwickelten, tatsächlich kostenlos verwendet werden konnte und obwohl der Quellcode verfügbar war (später jedenfalls anfangs wurde Qt nur als Binärcode veröffentlicht, denn „wir hatten ein wenig Angst,


--------------------------------------------------------------------------------------dass uns die Leute unsere guten Ideen stehlen könnten", erklärt Nord von Trolltech), handelte es sich nicht um freie Software in dem Sinn, wie Richard Stallman und die Free Software Foundation sie verstanden. Das neue KDE-Team ignorierte diese Protestwelle nicht. „Alle schlössen sich an und suchten nach Alternativen zu Qt", erklärt Ettrich. „Wir hatten in der Folge eine lange Diskussion: Sollen wir es mit Qt machen oder nicht? Das Ergebnis war, dass es die beste technische Lösung war, wenn wir unser Ziel erreichen wollten." So rückte das KDE-Projekt ins Zentrum eines der stärksten und polarisierendsten Kämpfe, die die Welt der freien Software je gesehen hatte, eines Kampfes, der die beiden großen Strömungen dieser Bewegung besser sichtbar macht als irgenderwas anderes. Ein Lager bildeten die Pragmatiker wie Ettrich, die sagten: „Es ist die beste technische Lösung, wenn wir unser Ziel erreichen wollen." Die Lizenzen, unter denen die Software herausgebracht wird, „sind für mich eine Frage der persönlichen Präferenz", sagt er. „Wenn jemand zu mir sagt, ich werde deine freie Software nicht verwenden, weil die Bibliothek eine Lizenz hat die mir nicht gefällt, ist mir das egal, weil ich das schon von LyX kenne. Es gibt im Grunde nur zwei Arten von Software", ist Ettrich überzeugt „gute und schlechte." Die Meinung, dass Lizenzen eine „Frage der persönlichen Präferenz" seien, bedeutet nicht, dass den Pragmatikern egal ist, was andere denken. Für Ettrich war der Linux-Kongress, der in den frühen KDETagen im Februar 1997 in Würzburg in Deutschland abgehalten wurde, ein Schlüsselereignis. Auf diesem Kongress las Eric Raymond zum ersten Mal seinen Essay The Cathedral and the Bazaar vor einem internationalen Publikum. Haavard Nord von Trolltech gab dort eine Präsentation, und das tat auch Ettrich. Ettrich sagt, er habe trotz der Kritik aus bestimmten Kreisen Mut geschöpft, sein KDE-Projekt auf Qt aufzubauen, weil sich in Würzburg „niemand über die Lizenz beklagte, kein Mensch. Also sagte ich, o.k., die Probleme sind gar nicht so groß wie sie scheinen." Sie waren aber groß genug für das andere Lager in der Welt der freien Software, die Puristen. Sie waren wie die Pragmatiker davon


------------------------------------------------------------------------------------überzeugt, dass es nur zwei Arten von Software gäbe - aber das waren für Leute wie Stallman und seine Gefolgsleute freie und urheberrechtlich geschützte. Technische Fragen waren im Vergleich mit dem Hauptanliegen der Freiheit sekundär oder sogar irrelevant. Die Tatsache, dass Qt nicht so frei war, wie sie verlangten, störte die Puristen. Viele der von der GNU GPL gewährten grundlegenden Rechte - das Recht, den Quellcode zu modifizieren und diese Distributionen weiter zu vertreiben - fehlten beim freien Qt. Das bedeutete, dass jeder Desktop, der mithilfe von Qt aufgebaut werden würde, auf nicht freien Grundfesten ruhte. Deshalb sollte Qt, wenn es nach den Anhängern der Free Software Foundation ging, an den Pranger gestellt werden. Die große Gefahr bestand in den Augen der Puristen darin, dass KDE erfolgreich sein und eine Situation schaffen könnte, in der hauptsächlich das freie GNU/Linux-Betriebssystem verwendet werden würde, damit das nicht freie Qt für KDE-Anwendungen laufen könnte - eine schreckliche Vorstellung für sie. Also versuchten die Puristen, Trolltech dazu zu überreden, die Lizenzbedingungen von Qt auf die der GNU GPL zu ändern, wenn es für freie Software verwendet würde, und allen, die Produkte für den Verkauf entwickeln wollten, eine kommerzielle Lizenz zu erteilen. Dadurch wäre das KDE Projekt wirklich freie Software geworden und hätte Trolltech Einnahmen aus kommerziellen Applikationen beschert. Aber Trolltech sah in diesem Ansatz eine Gefahr: „Es gab viele Leute in der Welt der freien Software, die nicht wollten, dass wir mit Qt erfolgreich waren", erklärt Nord. „Also drohten sie uns, sie würden alles daran setzen, irgendeine Alternatiwersion zu Qt zu produzieren." Unter den Bedingungen der GNU GPL könnte ein großes Hackerteam, das freie Software entwickelte, den Quellcode von Qt nehmen und ihn schneller entwickeln als Trolltech - und auf eine Art, die der Firma nicht gefallen könnte. Obwohl Trolltech das Recht haben würde, solche Änderungen einzubauen, würde dieser alternative Entwicklungsstrang trotzdem eine Spaltung - oder eine Gabelung - der Qt-Welt bewirken. „Die Gabelung war das, worüber wir uns die größten Sorgen machten", sagt Nord. Deshalb weigerte sich Trolltech, die GNU GPL in Betracht zu ziehen, und die


--------------------------------------------------------------------------------------Anhänger der freien Software kamen zu dem Schluss, dass der einzig mögliche Ansatz darin bestand, mit einem vollkommen neuen und freien Desktop-Projekt zu beginnen, das sicherstellen würde, dass sich KDE nicht automatisch als Standard durchsetzte. Der Mann, der dieses Projekt leiten sollte, war der junge Mexikaner Miguel de Icaza Amozurrita, wie Ettrich 1972 geboren. Er hatte zum ersten Mal von einem Freund vom GNU-Projekt gehört, als er an der National Autonomous University of Mexico in seiner Geburtsstadt Mexico City Mathematik studierte. Mit dem Sammeln praktischer Erfahrung musste er warten, bis er neben seinem Studium einen Job als Systemadministrator der Universität bekam, „Als ich meine SunMaschine an der Universität bekam", sagt er, „installierte ich dort als Erstes dieses freie Zeug, das es gab. Ich las das Manifest von RMS, und ich war fasziniert von dieser Idee, ein vollwertiges Betriebssystem zu schaffen, das völlig frei war," Der erste Beitrag, den de Icaza zum GNU-Projekt leistete, war ein Dateimanager, ein Programm, mit dem man den Inhalt von Verzeichnissen ansehen und manipulieren konnte. „Ich wollte einen guten Dateimanager haben, weil ich aus der DOS-Welt kam, wo es ein ähnliches Tool gab, das ziemlich gut war." Dieser "gute Dateimanager" aus der DOS-Welt war der Norton Commander, der auch de Icazas Programm seinen Namen verschaffte: Midnight Commander. Sein nächstes Projekt führte er auf der Sun-Maschine durch, die er für seine Arbeit als Systemadministrator verwendete. Dave Miller hatte an einem Port von GNU/Linux für die Plattform zu arbeiten begonnen, und de Ieaza bot seine Hilfe an. Miller hat über de Icaza zur damaligen Zeit etwas Interessantes zu sagen: „Ich glaube, dass der Stil seiner Arbeit als Programmierer und als Ingenieur seiner adrenalinbestimmten Persönlichkeit eher entsprach", merkt Miller an. Die außergewöhnliche Energie de Icazas, für die er in der Welt der freien Software berühmt war, kam ihm sehr zugute, als er noch weitere freie Softwareprojekte übernahm. Aber de Icaza ist nicht nur für seine phänomenale Schaffenskraft bekannt, sondern auch für sein Engagement für die GNU-Sache. So war eines der Projekte, die er beitrug, „der Linux RAID [Redundant Array of Inexpensive Discs] Code, etwas, was einem unter Linux


------------------------------------------------------------------------------------einen schnelleren, zuverlässigeren Zugang zu den Festplatten ermöglicht" De Icazas Entschluss, daran zu arbeiten, wurzelte in keinem persönlichen Bedürfnis: „Ich hatte die Hardware nicht", sagt er, „also emulierte ich die physischen Geräte, um dieses Zeug implementieren zu können." Das heißt, dass er ein Softwaremodell eines RAID-Systems einzig für den Zweck entwickelte, einen Treiber schreiben zu können, den andere verwenden würden. Nach dem RAID-Code ging de Icaza zu einem anderen GNU/ Linux Port für eine SGI-Maschine über. Auch hier baute er auf der Arbeit Dave Millers auf, der während eines Sommerjobs bei SGI, wo er für Larry McVoy arbeitete, mit dem Port begonnen hatte. Es war damals, Ende 1996, dass Ettrich das KDE-Projekt ankündigte. Anfangs freute sich de Icaza, dass jemand an einem Desktop für GNU/Linux arbeitete. „Am Anfang verstand ich nicht, was da passierte", erinnert er sich. „Also sagte ich: ,0h ja, o.k., das sind nette Beiträge, sie sind frei, sie laufen unter der GPL" - KDE selbst wurde unter der GPL herausgebracht, auch wenn es die Qt-Bibliotheken nicht wurden, „Also redete ich mit Eric Troan von Red Hat", fährt de Icaza fort. „Ich sagte: .Sieh mal, Eric, du solltest das hier vertreiben, es ist toll: Und er antwortete: ,Hm, nein, es gibt da folgendes Problem', und beide sagten dasselbe: ,Das Ergebnis ist nicht frei.' Und ich sagte: ,0h wartet, Moment mal! Das muss ich mir noch einmal ansehen.' Also las ich mir die Lizenz durch, und tatsächlich, das Problem war, dass die QtSoftware geschützt war." Nachdem anfängliche Versuche, Trolltech dazu zu überreden, die GNU GPL für die Qt-Bibliotheken zu verwenden, gescheitert waren, begannen die Leute über Alternativen nachzudenken. „Wir probierten mehrere Ansätze aus", sagt de Icaza, Aber es gab nur zwei wirkliche Optionen: Die eine war, einen freien Klon von Qt zu entwickeln, bei dem es keine Lizenzprobleme geben würde. Obwohl ein solches Projekt, Harmony genannt, später begonnen wurde, hatte de Icaza seine Zweifel über diesen Ansatz, weil er bereits anderswo ohne Erfolg ausprobiert worden war. Die andere Option war ambitioniert: einen neuen Desktop zu entwickeln, der ausschließlich auf GPL-Software basieren würde.


--------------------------------------------------------------------------------------Aber die Vertreter dieser Idee hatten immer noch ein Problem: Welches Toolkit sollten sie verwenden? Die wichtigsten wie Motif (und Qt) waren geschützt und standen daher außer Diskussion. Die Lösung war gewagt: Sie würden das Gtk+ Toolkit verwenden, das Peter Mattis für GIMP entwickelt hatte. Rückblickend betrachtet erscheint es außergewöhnlich, dass das, was zum riesigen Gebäude einer ganzen grafischen Benutzerschnittstelle für GNU/Linux geworden war, auf Grundlagen aufbaute, die einzig der Zufall bereitgestellt hatte. Wie Mattis selbst sagt: „Zur damaligen Zeit hätten die Leute gesagt, es sei dumm und verrückt, ein eigenes Toolkit zu schreiben. Wenn ich zurückschaue, glaube ich aber, dass es eine ungeheuer glückliche Entscheidung war. Es hatte enorme Auswirkungen, weil es den Leuten ein ziemlich hochwertiges Toolkit an die Hand gab, mit dem sie grafische Programme verwenden konnten. Außerdem war es auslösend für die Explosion, die die Welt der freien Software erlebte." Das neue Projekt konnte nicht nur auf ein bereits bestehendes Toolkit zurückgreifen, sondern auch einen Namen recyceln. Das neue GUISystem würde GNOME heißen, wie es GNU üblich ist. GNOME stand für GNU Network Object Model Environment, was wenig mit grafischen Benutzerschnittstellen zu tun zu haben schien. Tatsächlich war dieses „alte" GNOME-Projekt von der unwahrscheinlichsten aller Quellen inspiriert worden: Microsoft. 1997, „kurz bevor GNOME als Desktop-Ersatzprojekt in Angriff genommen wurde", erzählt de Icaza, „besuchte ich meine Freunde bei Microsoft." Sie zeigten ihm eine neue Technologie namens ActiveX, die Teil von Microsofts ambitionierten Plänen war, im Internetbereich aufzuholen. ActiveX bestand aus kleinen Programmen, die über das Internet an einen Webbrowser geschickt werden konnten, wo sie fortgeschrittene Funktionen hinzufügen würden. Bedauerlicherweise erwies sich dieser Ansatz als Sicherheitsalbtraum, und ActiveX konnte in der Internetwelt nie Fuß fassen. Aber ActiveX war Teil einer allgemeineren Komponentenstrategie, in deren Rahmen aus diesen kleineren Elementen Software zusammengestellt werden konnte. De Icaza war von diesem Aspekt beeindruckt und wollte etwas Ähnliches für GNU/Linux schaffen.


------------------------------------------------------------------------------------„GNOME wurde ursprünglich für dieses Komponentensystem entwickelt", sagt er. Dann kam KDE und die Entscheidung, ein konkurrierendes DesktopProjekt zu schaffen. Man beschloss, den ursprünglichen komponentenbasierten Ansatz zu adaptieren. Wie Ettrich erkannt hatte, dass KDE ein Metaprojekt sein müsste, das aus vielen kleineren, eigenständigen Programmen bestand, war de Icaza und seinen Freunden, die GNOME unterstützten, bewusst, dass das Komponentenmodell viele Vorteile für das Codieren freier Software brachte. „Es hilft", meint de Icaza, „weil es bedeutet dass man, wenn eine Komponente Bugs hat, nur die [kleinere] Anwendung zu verstehen braucht, die von dem Problem direkt betroffen ist, und nicht die ganze riesige Anwendung." Das heißt, dass der modulare Ansatz, wie er beim Linux-Kernel verwendet wurde, auf Applikationen höherer Ebenen angewendet wird. Das GNOME-Komponentenmodell verbrauchte mehrere Namen. „Letzten Endes wurde es nicht GNOME genannt", sagt de Icaza. „Ursprünglich hieß es Baboon, dann änderten wir den Namen auf Bonobo. Meine Freundin beschäftigte sich intensiv mit dem Verhalten von Primaten", erklärt er. „Deshalb hatte ich es privat viel mit Affen zu tun." Das ursprüngliche Baboon-Komponentensystem bekam nicht nur einen neuen Namen verpasst, sondern es wurde grundlegend überarbeitet und verbessert, bevor es zum derzeitigen Bonobo wurde. Als das GNOME-Projekt im August 1997 angekündigt wurde, „gab es viele Reaktionen, und wir begannen sofort, an dem Projekt zu arbeiten", sagt de Icaza. Einer der ersten GNOME-Codierer war Alan Cox. „Er trug viel Software bei, viele Fixes und jede Menge Patches", erklärt de Icaza. „Er arbeitete an GNOME, weil wir im Vergleich zur anderen Lizenz eine sehr saubere Lizenz hatten. Viele Leute, die an GNOME arbeiteten, waren Leute, denen die Lizenzfragen sehr am Herzen lagen." Eine Firma, die sich für die Lizenzfragen interessierte und der an einem vollkommen freien Desktop gelegen war, war Red Hat. Deshalb, so de Icaza, „stellte Red Hat etwa vier Monate nach der Initiierung des GNOME-Projekts Leute für GNOME ab". Das erwies sich als wichtiger Anstoß, wie er sagt, weil, „Red Hat nun viele der


--------------------------------------------------------------------------------------Dinge erledigte, die andere Leute nicht in ihrer Freizeit zu erledigen bereit gewesen wären. Sie verloren wegen ihres Engagements für GNOME sogar Marktanteile." Der Grund war, dass Konkurrenten wie Caldera und SuSE ihre Distribution mit dem neuen und höchst attraktiven KDE auslieferten, während Red Hat daraufwartete, dass GNOME aufholte. Trotz dieser breit angelegten Bemühungen sagt de Icaza, dass selbst die glühendsten GNOME-Befürworter hofften, dass es nicht notwendig sein würde, es fertig zu stellen. „Anfangs hofften wir, dass die Existenz des Projekts Trolltech zu einer Meinungsänderung bewegen würde, aber das war nicht der Fall. Also arbeiteten wir einfach weiter, bis wir endlich etwas Brauchbares hatten." Trolltech mochte nicht bereit gewesen sein, die Bedürfnisse der GNOME-Unterstützer zu erfüllen, aber es versuchte jedenfalls, die Situation zu verbessern. Wie Ettrich erklärte, hatte Haarvard Nord im Februar 1997 beim Linux-Kongress gesprochen, und sogar in diesem Stadium hatte er ein Angebot gemacht. „Am Ende von Haavards Vortrag sagte er: ,Wir wollen etwas wegen der Lizenzen unternehmen; wir wollen eine Rechtseinheit gründen, eine Art Stiftung, um sicherzustellen, dass es immer eine freie Ausgabe geben wird.' Er sagte das, ohne dass besonderer Druck auf ihn ausgeübt worden wäre", meint Ettrich. ,Alle sagten: Ja, das ist gut, das können wir irgendwann einmal machen', aber niemand sprang auf und sagte: ,Ja, wir müssen das tun, es ist ganz wichtig, dass wir das jetzt sofort tun." Trotz dieses scheinbaren Mangels an Interesse gründete Trolltech später die KDE Free Qt Foundation. „Wir wussten, dass die Typen von KDE ein bisschen unter Druck standen", sagt Nord, „und zwar unter Druck von anderen Leuten." Der Grund, wie er erklärt, war eine nicht unbegründete Angst: „O.k., Qt ist jetzt freie Software, aber wenn die Trolle die Lizenz in ein paar Jahren ändern, haben wir all diese KDESoftware und können sie nicht weiterentwickeln, weil Trolltech auf einmal Geld für die Lizenz will." Die KDE Free Qt Foundation, die im April 1998 gegründet wurde, sorgt dafür, dass immer eine freie Version der Qt-Bibliotheken erhältlich ist, auch wenn die Firma verkauft wird oder ihre Geschäftstätigkeit einstellt.


------------------------------------------------------------------------------------Diese Entwicklung goss Öl in das Feuer der Befürchtungen vieler, ließ aber immer noch die zentrale Frage außer Acht, die den puristischen Flügel der Welt der freien Software beschäftigte. Wie Nord erklärt: „Jetzt beklagten sich viele darüber, dass sie keine Patches schicken oder Modifikationen an Qt vornehmen konnten." Um die Situation zu verbessern, beschloss Trolltech, noch einen weiteren Schritt zu tun. Aber es war ein schmerzlicher Prozess. „Einige Leute [bei Trolltech] drohten zu kündigen, wenn wir eine Open-Source-Version von Qt herausbringen würden", berichtet North, „weil sie fürchteten, dass das eine Bedrohung unserer Einnahmen sein würde." Schließlich beschloss Trolltech, eine neue Lizenz für die QtBibliotheken zu erstellen, die Q Public License (QPL). Ransom Love „machte sich Sorgen über all die Streitigkeiten über die Qt-Lizenz", glaubt Nord, weil Caldera KDE für seine Distribution verwendete. Er brachte Trolltech in Kontakt mit Bruce Perens und Eric Raymond, die gebeten wurden, einen Blick auf die Lizenz zu werfen. „Es war ganz überwältigend", erzählt Nord, „sie halfen uns wirklich sehr." Die daraus resultierende Lizenz, die im November 1998 herauskam, schien zumindest eine Lösung für die verbleibenden Probleme mit Qt zu sein, mit der alle außer den anspruchsvollsten Befürwortern der freien Software zufrieden waren. „Viele der Leute, die gegen Trolltech und Qt waren, waren der Meinung, dass wir nun weit genug gegangen waren", sagt Nord. Am 4. September 2000 ging Trolltech noch einen Schritt weiter und fügte die GNU GPL als Alternative hinzu. Als die QPL im November 1998 herauskam, gab es GNOMH seit mehr als einem Jahr. Es hatte sich gegenüber seiner ersten offiziellen Version, die schließlich im März 1999 herauskam, erheblich verbessert. Die Aussicht, dass GNOME die Entwicklung einstellen oder mit KDE fusionieren würde, war daher geschrumpft. Ein interessanter Unterschied zwischen den beiden Projekten ist, dass eine Office-Suite nicht Bestandteil des ursprünglichen KDE-Projekts war - „hauptsächlich deshalb, weil ich die Hälfte der Pakete nie verwendete", sagt Ettrich. „Ich wusste, was eine Textverarbeitung war, aber ich hatte Microsoft Office nie verwendet." Diese Büroanwendungen wurden bald von anderen Program-


--------------------------------------------------------------------------------------mierern hinzugefügt. Für de Icaza standen sie sogar im Zentrum der Vision. „Das Ziel des GNOME-Projekts besteht darin, ein vollkommen freies System zu haben, ohne geschützte Applikationen zu verwenden. Diese Office-Suite ist also offensichtlich nur Teil dieser Bemühung. Wenn man ein vollkommen freies Betriebssystem haben will, muss man die Tools bereitstellen, die die Endbenutzer für ihre tagtägliche Arbeit brauchen." Obwohl diese endgültige Vision vollständiger war, hatte es der Puristenflügel mit der Entwicklung eines Desktops für Endbenutzer nicht eilig. Angesichts der Tatsache, dass es so ausgezeichnete Tools wie Emacs gab, mochten aufwendige GUI-Textverarbeitungen überflüssig erscheinen. Der Pragmatiker Ettrich sah, dass es im Gegensatz dazu wichtig war, GNU/Linux in neue Spähren zu tragen und den technisch nicht versierten Benutzern die Möglichkeit zu geben, die Vorteile dieses leistungsstarken Systems nutzen zu können. Es war das Pragmatikerprojekt KDE, das den bis dahin viel zu ehrgeizig erscheinenden Plan zur Entwicklung eines ganzen GUI Front-ends für GNU/Linux in Angriff nahm, das dem neuen und Aufsehen erregenden Windows 95 ähnlich sein würde. Und es war die Entscheidung der Pragmatiker, das zu diesem Zeitpunkt technisch beste Toolkit - Qt - zu verwenden, auch wenn es nicht vollkommen frei war, die die Puristen dazu trieb, ein eigenes Desktopprojekt zusammenzustellen, das in seinen Funktionen und in seiner Eignung für Endbenutzer KDE gleichkam. So ist es also der manchmal belasteten Dynamik zwischen den Pragmatikern und den Puristen zuzuschreiben, dass die Welt der freien Software einen ihrer bisher bedeutendsten Fortschritte erzielte. Ohne die Pragmatiker hätten die Dinge vielleicht um Jahre länger gedauert, und Windows hätte sich noch fester verankern können. Und ohne die Weigerung der Puristen, Kompromisse einzugehen, wäre Qt vielleicht nie zur Open-Source-QPL übergegangen, und der KDE-Desktop wäre in gefährlicher Weise beeinträchtigt worden. In einer E-Mail vom 10. Juli 1998 gab Linus einen Kommentar zu den Fragen Lizenz, KDE und GNOME ab, in dem er deutlich zu erkennen gab, wo er in dieser Sache stand.


------------------------------------------------------------------------------------Ich persönlich bevorzuge KDE derzeit gegenüber GNOME, weil es eine hübsche Benutzerschnittstelle hat und besser arbeitet. Ich verwende aber keines der beiden. Ich weiß, dass es viel dummes Gestreite wegen der Lizenz gegeben hat, und das gefällt mir nicht besonders. Meine Meinung zu Lizenzen ist, dass „derjenige, der den Code schreibt, seine Lizenz selbst wählen sollte, und niemand sollte sich darüber aufregen". Jeder, der sich über eine Copyrightlizenz beklagt, ist ein Jammerhans. Das ist natürlich die klassische Pragmatikerposition. Den KDE-Gegnern steht es frei, ihren eigenen Code zu schreiben, aber sie haben nicht das moralische Recht, sich darüber zu beschweren, dass andere Leute anderen Code schreiben. Ich verachte Jammerer, und ich lasse mich in einen derartigen Streit nicht hineinziehen. Obwohl Linus damals KDE zu bevorzugen schien, spiegelte das wahrscheinlich eher die Tatsache wider, dass er weiter war als GNOME. Er distanzierte sich später von dieser Diskussion und wies auf die Vorteile mehrerer Lösungen hin. So sagte er im September 1998: „Es ist wie in der Politik: Stabilität bekommt man nicht, wenn man nur eine Partei hat, und es erscheint mir für die Stabilität besser, mehrere Parteien zu haben, die um die Macht kämpfen, als eine Alleinherrschaft. Ich denke, dass die Frage KDE oder GNOME das System letzten Endes besser machen wird, auch wenn das bedeutet, dass noch eine Zeit lang weitergekämpft werden wird." Heute wachsen KDE und GNOME stark und konkurrieren auf gesunde Weise. Beide haben Hunderte von Entwicklern und Hunderte von Applikationen. Es gibt auch Initiativen, die beiden Ansätze kompatibler zueinander zu machen. „Wir arbeiten heute auf jeden Fall enger zusammen", sagt de Icaza. „Und wir sind uns über eine Reihe von Standards einig." Und, wie Ettrich meint, liegt einer der Gründe, dass diese Zusammenarbeit funktioniert, „darin,


--------------------------------------------------------------------------------------dass wir an allen diesen Dingen kein kommerzielles Interesse haben" Jene, die gern darauf hinweisen, dass KDE und GNOME mit ihren verschiedenen Softwaresammlungen weiter bestehen und dies als Zeichen einer grundlegenden Spaltung der GNU/Linux-Welt betrachten, vergessen meist einen wichtigen Punkt: Es ist möglich, sowohl KDEals auch GNOME-Anwendungen auf derselben Maschine zur selben Zeit laufen zu lassen, egal welcher Desktop aktiv ist. Das bedeutet, dass es keine echte Gabelung zwischen den beiden Projekten gibt, nur Unterschiede im Ansatz und im Erscheinungsbild auf dem Bildschirm. Als freie Software werden sowohl KDE als auch GNOME kommerziellen Distributionen routinemäßig beigefügt. Und die freie Wahl war schließlich seit jeher die Quintessenz der Bewegung der freien Software. Die Wege, die von den beiden Gründern seit damals besehritten wurden, stehen in einem interessanten Kontrast zueinander. Wie es seiner Rolle als Urheber des Metaprojekts entspricht, ist Ettrich von seiner Position als „Star" einen Schritt zurückgetreten. Passenderweise widmet er sich nun als Trolltech-Mitarbeiter Fragen der Technologie» insbesondere der Qt-Technologie, Sein Umzug im August 1998 dorthin ist in vielerlei Hinsicht die perfekte Lösung für alle. „Trolltech gab mir die Möglichkeit, das KDE-Toolkit zu verbessern und damit auch KDE", sagt er. „Ich kann mir aussuchen, ob ich auf KDE oder auf Qt hacken möchte. Ich habe also jede Menge Freiheit." Es ist auch die perfekte Lösung für Trolltech, das nun einen begabten Codierer beschäftigt, der eingestellt wurde, „weil er als Entwickler wirklich über erstaunliche Fähigkeiten verfügt", wie Nord sagt. Außerdem ist er jemand, der wie kein anderer geeignet ist, als Verbindungsglied zum KDE-Projekt zu fungieren. De Icaza hat sich für eine Option entschieden, die einigen überraschend zu sein scheint: Er gründete ein Unternehmen rund um die GNOMESoftware. Natürlich ist der puristische Flügel der Welt der freien Software nicht gegen kommerzielle Software als solche, sondern nur gegen geschützten Code. Und das Beispiel von Cygnus zeigte, dass es möglich ist, ein höchst erfolgreiches Unternehmen rund um GNU GPLSoftware zu gründen. De Icaza


------------------------------------------------------------------------------------sagt, er hätte mit Michael Tiemann gesprochen, einem der Gründer von Cygnus, bevor er seine Firma, Helix Code, gründete. Mitbegründer waren sein Hackerkollege Nat Friedman und Bob Young von Red Hat. Entsprechend ihrem Businessplan wurde die Firma ursprünglich International GNOME Support genannt. Ihr derzeitiger Name, Helix Code, „beruht darauf, dass wir keinen anderen Namen bekommen konnten", sagt de Icaza, aber „auch auf diesem Evolutionszeug, von dem GNOME durchdrungen ist". Abgesehen von Unterstützungsarbeit - „Wir schließen bereits Verträge ab", sagt de Icaza, hat Helix Code bereits sein erstes Produkt, Helix GNOME, herausgebracht. „Dabei handelt es sich im Grunde um eine Distribution für GNOME, die leicht zu installieren ist", erklärt er. „Es ist nur der Desktop, deshalb funktioniert sie auch auf vielen anderen Linux-Distributionen." Zu den anderen Projekten zählt Gnumeric, ein Tabellenkalkulationsprojekt unter der Leitung von de Icaza, das voll kompatibel zu Microsoft Excel ist, und zwar so weitgehend, „dass der gedruckte Output derselbe ist, was sehr wichtig ist", und der E-Mail Client Evolution, der durch die Verwendung von Bonobo-Komponenten erweiterungsfähig ist. Es überrascht nicht, dass Helix Code und das GNOME-Projekt eng miteinander verflochten sind. „Viele der Leute, die die Firma einstellte" - unter ihnen die GNOME-Spitzenhacker - „warten bestehende GNOME-Pakete", erklärt, „und sind für die Wartung dieser Pakete, für Aktualisierungen und Entwicklung zuständig. Natürlich laufen alle Entwicklungen, die wir machen, unter der GPL, und sie werden ins GNOME-Projekt integriert. So glaube ich, dass alle profitieren." Helix Code steht nicht allein, wenn es um die Schaffung einer symbiotischen Beziehung zum Projekt der freien Software geht. Eine neue Firma namens Eazel, die im August 1999 eingerichtet wurde, arbeitet ebenfalls an GNOME-Elementen - „sie überarbeiten derzeit den Desktop und den Dateimanager", sagt de Icaza - und machen sie frei verfügbar. „Sie arbeiten mit uns zusammen, weil wir beide von der Komponententechnologie abhängig sind." De Icaza ist davon überzeugt, dass diese gemeinsame Arbeit zu erheblichen Fortschritten fuhren wird. „Es geht nicht mehr darum,


--------------------------------------------------------------------------------------dass irgendjemand nur einen Desktop bereitstellt; darüber sind wir schon hinaus", sagt er. „Wir konzentrieren uns auf die Verwendbarkeit, auf die Interaktion zwischen Mensch und Maschine. Wichtig ist nicht mehr, einen Desktop für Unix-Benutzer bereitzustellen, sondern dass Leute, die noch nie Kontakt mit einem Computer hatten, sich mit einem freien Softwaresystem gut zurechtfinden." „Wir entwickeln hier eine der innovativsten Technologien", betont er. „Ich würde sagen, dass wir diesmal einen eindeutigen technischen Vorteil haben" - ein wichtiger Punkt für ein System, das von seinen Konkurrenten oft als Nachzügler eingestuft wird, was die Benutzerschnittstellentechnologie anbelangt. „Wenn Gnome 2.0 herauskommt, wird man etwas sehen, was niemand anderer hat, nicht Windows, nicht Mac, niemand." Die Erwähnung des berühmtesten Apple-Computers ist deshalb besonders pikant, weil die drei Gründer von Eazel die wichtigsten Mitglieder des ursprünglichen Macintosh-Teams waren. Michael Boich, Präsident und CEO von Eazel, rief die „Softwarepredigergruppe" von Apple für den Macintosh ins Leben; Bud Trible, Vice President für Softwareengineering, managte das ursprüngliche MacintoshSoftwareteam; und Andy Hertzfeld, dessen Jobtitel bei Eazel einfach „Software Wizard" - Softwarezauberer - lautet, designte und implementierte einen großen Teil der ursprünglichen MacintoshSystemsoftware einschließlich der Toolbox der Benutzerschnittstelle. Nichts könnte besser symbolisieren, wie weit GNU/Linux in nur wenigen Jahren von seinen hackerorientierten Befehlszeilenursprüngen abgerückt ist und wie sehr es Microsoft auf dem Gebiet der normalen Anwender - einst die heilige Rolle von Apple -herausfordert, als die Entscheidung dieser ehemaligen Macintosh-Gurus, Eazel zu gründen und an Open-Source-Software zu arbeiten. Aber der Kampf zwischen GNU/Linux und Microsoft im Desktopbereich liegt noch einige Zeit in der Zukunft, falls er überhaupt je kommen wird, was einige bezweifeln. Auf der Serverseite jedoch tobt der Kampf nun schon einige Zeit. Die offizielle Eröffnung der Feindseligkeiten geht auf einen Angriff von Microsoft im April 1999 zurück, als etwas, was als kleine,


------------------------------------------------------------------------------------verdeckte Operation begonnen hatte, furchtbar schief lief und zu einem offenen Medienkrieg ausartete.

16

Lügen, verdammte Lügen... und Benchmarks

ALS DIE EREIGNISSE DER JAHRE 1998 UND 1999 GNU/Linux bekannter und die zunehmende Zahl leistungsstarker Anwendungen immer besser als Unternehmenslösung einsetzbar machten, begann sich eine logische Frage zu stellen: Welches Betriebssystem war für den Untemehmensbereich besser geeignet GNU/Linux oder Windows NT? Anfang 1999 setzte ein Wettrennen in Form von Benchmarktests ein. Durchgeführt wurden diese Test von Computermagazinen, die für ihre Leser festzustellen versuchten, wie die beiden Betriebssysteme in ihren Rohleistungsdaten im Vergleich zueinander abschnitten. Der erste dieser Vergleiche erschien am 25. Januar in einer Ziff-DavisPublikation namens Sm@rt Reseller, einem Magazin für


------------------------------------------------------------------------------------Wiederverkäufer auf dem Computermarkt. GNU/Linux war für diese Leser potenziell von großem Interesse, weil sie ihr Geld mit dem Erstellen und Verkaufen vollständiger Lösungen für ihre Kunden verdienten. Wenn sie Windows NT gegen ein freies Betriebssystem austauschen konnten, ohne dabei Leistungseinbußen hinnehmen zu müssen, könnten sie ihre Gewinne substanziell erhöhen. Der Artikel, geschrieben von Steven J. Vaughan-Nichols und Eric Carr, war eindeutig. Er trug den Titel „Linux in Nahaufnahme: Zeit für den Umstieg", und in den ersten Absätzen wurde gleich Klartext gesprochen: „Vergessen Sie den Hype um Linux. Vergessen Sie den Marktanteil der Microsoft Corporation bei den Servern. Unsere praktischen Analysen haben ergeben, dass kommerzielle LinuxVersionen mit viel weniger Mitteln viel mehr bewirken können als Windows NT Server." Weiter hinten trugen die Autoren noch dicker auf: „Laut den Ergebnissen der ZD-Labors schlug jede einzelne der kommerziellen Linux-Versionen NT um Längen." Für die Tests wurden zwei Benchmarks verwendet, die Ziff-Davis entwickelt hatte: WebBench und NetBench. Mit dem ersten wurde die Leistung von GNU/Linux mit dem Apache Webserver im Vergleich zu Windows NT mit dem Internet Information Server von Microsoft gemessen, der mit NT frei im Paket mitgeliefert wurde. NetBench testete, wie gut die beiden Systeme darin waren, Dateien an WindowsPCs zu versenden. Die Funktion eines zentralen Fileservers für Windows-Clients war eine der Hauptfunktionen von Windows NT; für GNU/Linux, das im Wesentlichen ein Unix-System war, waren solche Aktivitäten eher fremd. Dass sie überhaupt möglich waren, war einem anderen Stück freier Software zu verdanken. Dieses Programm namens Samba ist eines der bestgehüteten Geheimnisse der Open-Source-Welt. Dank seiner Fähigkeit, eine als Fileserver agierende Windows-NT-Maschine fast perfekt nachzuahmen, bahnte es sich heimlich seinen Weg in Tausende Unternehmen, deren Führungsetage sich dessen meist überhaupt nicht bewusst ist. Der Grund ist ganz einfach der, dass die Kombination von Samba und GNU/Linux so reibungslos funktioniert. Samba ist wahrscheinlich der Hauptgrund, warum GNU/Linux-Systeme erst-

16. Lügen, verdammte Lügen... und Benchmarks

--------------------------------------------------------------------------------------mals in Unternehmen zum Einsatz kommen, die ansonsten nur geschützte Software verwenden. Als solches trägt es gemeinsam mit dem Apache Webserver entscheidend dazu bei, das Ansehen von OpenSource-Software in der Untemehmenswelt zu heben. Der ursprüngliche Autor von Samba ist Andrew Tridgell, der 1999 von Linuxcare als Star aller Stars eingestellt wurde. Er wurde 1967 in Australien geboren und war Linus' Gastgeber in Canberra, wo er indirekt zur Kür des berühmten Pinguinmaskottchens beigetragen hatte. Samba wurde wie so viele andere freie Softwareprogramme als persönliche Lösung entwickelt, und fast rein zufällig. „Das Ganze hatte im Dezember 1991 begonnen; ich schrieb damals meine Dissertation an der Australian National University of Canberra, und eigentlich hielt ich Ausschau nach einem Vorwand, um ein bisschen trödeln zu können. Da tat sich die Gelegenheit auf, einen Betatest von Etwas namens Windex durchzuführen", erinnert sich Tridgell. Windex war ein X-Server für Microsoft Windows (das damals bei Version 3.0 hielt), der es einem PC ermöglichte, Programme anzuzeigen, die auf einem Unix-Server liefen. Das war wegen der inhärent vernetzten Natur des X-Window-Systems möglich: Auf den Output eines Programms konnte über ein Netzwerk zugegriffen werden, und er konnte in einem von einem X-Serverprogramm - wie etwa Windex - erstellten Fenster angezeigt werden. Aber Tridgell hatte ein Problem: „Ich verwendete PC-NFS für den Anschluss eines Sun-Systems, um meine Dateien weitergeben zu können", erklärt er. Das hieß, dass er eine alternative Methode verwendete, um Dateien auf seinem Windows PC mit dem Hauptabteilungsserver auszutauschen. Das war problematisch, weil ein wichtiges Element der Netzwerkverbindungsfähigkeit eines PC, der TCP/IP Stack, für beide Ansätze verschieden war. Um Windex verwenden zu können, musste er dessen eigenen Stack laden. „Ich musste den von Pathworks verwenden, weil er von Digital geschrieben war, und Pathworks die Implementierung von Digital für TCP/IP für Windows war." „Also installierte ich Pathworks [auf dem PC]", sagte er, „und ich konnte nicht länger auf meinen PC-NFS-Server zugreifen", weil die


------------------------------------------------------------------------------------Stacks verschieden waren. An diesem Punkt hatte er die klassische Hackeridee: „Also dachte ich, nun ja, das kann ja nicht so schwierig sein, das Protokoll. Vielleicht sollte ich versuchen, einen Server für SunOS zu schreiben, der mir dieselben Funktionen bietet wie ein Pathworks-Server, der auf einer Digital-Unix-Box läuft." Indem er einige Software für die Sun-Maschine der Abteilung geschrieben hatte, hoffte er in der Lage zu sein, Dateien mit seinem PC auszutauschen, indem er einfach Pathworks verwendete, anstatt immer auf NFS zurückgreifen zu müssen." „Was ich nicht wusste war, dass das [Pathworks] Protokoll kein geschütztes Digital-Protokoll war", merkt er an. „Tatsächlich war das Protokoll dasselbe, das Microsoft in seinen Netzwerken verwendet. Und mir war nicht klar, dass das Protokoll SMB [Server Message Block] genannt wurde, und ich wusste auch nicht, dass es sich dabei um ein teilweise dokumentiertes Protokoll handelte. Also setzte ich mich in seliger Ignoranz hin und implementierte das Protokoll aus der Leitung" - ebenfalls eine klassische Hackertechnik - „einfach, indem ich Pakete beobachtete." Indem er sich ansah, welche Nachrichten über das Netzwerk zurückgesendet wurden, gelang es Tridgell, Software für denselben Zweck zu schreiben, obwohl er nicht einmal wusste, wie diese Nachrichten funktionierten. „[Ich] implementierte einen einfachen Server. Dazu brauchte ich im Dezember '91 über Weihnachten etwa eine Woche lang", erinnert er sich. „Es machte Spaß, in den Weihnachtsferien ein bisschen zu arbeiten." Zufällig machte das auch Linus in diesem Jahr gerade Spaß. Er erweiterte damals gerade seinen jungen Linux-Kernel, an dem er nur einige Monate vorher zu schreiben begonnen hatte, um Virtual Memory. Sobald er seinen Server fertig hatte, beschloss Tridgell festzustellen, ob es noch andere gab, die daran interessiert waren, ihn zu verwenden. „Also schickte ich diese Frage an eine Pathworks-Mailingliste. Einige Leute waren interessiert und wollten ihn ausprobieren. Ich brachte Version 0.1 heraus und dann, nur ein paar Tage später, Version 0.5", erinnert er sich. Aber dann passierte etwas, was dazu führte, dass er das Projekt fallen ließ: Seine Abteilung tauschte die Hardware aus, auf der er arbeitete, und hatte keine Verwendung mehr für sein einfaches Pathworks-Serverpro-


--------------------------------------------------------------------------------------gramm. „Also stellte ich die Arbeit an dem Projekt einfach ersatzlos ein", sagt er. „Ich stellte eine Nachricht auf die FTP-Site, in der in etwa Folgendes stand: ,Wenn irgendjemand das Projekt übernehmen möchte, habe ich nichts dagegen.'" Obwohl er einiges Feedback und sogar Patches erhalten hatte, als er die ersten Versionen herausbrachte, meldete sich niemand, der bereit gewesen wäre, die Entwicklung fortzusetzen, und es schien, als ob das Projekt gestorben wäre. GNU/Linux belebte es wieder, und das war auch gut so, weil sich das zukünftige Samba als einer seiner stärksten Verbündeten erweisen sollte. Im November 1992 schickte jemand namens Dan Shearer Tridgell eine E-Mail über seinen alten Pathworks-Server. „Dan teilte mir mit, dass ein gewisses Interesse daran bestünde, dieses Ding für Linux zu portieren", erinnert sich Tridgell. .Also schrieb ich zurück und fragte ihn: ,Was ist Linux?' Ich hatte nie davon gehört. Er erklärte es mir, ich lud es mir auf den PC herunter, den ich mir in der Zwischenzeit besorgt hatte, einen 386er, und ich verliebte mich sofort in Linux." Diese Begebenheit machte ihn nicht nur auf GNU/Linux aufmerksam, sondern hob auch sein Bewusstsein über freie Software im Allgemeinen. Obwohl Tridgell freie Software verwendete - zum Beispiel Emacs, um sich den Inhalt der Pakete anzusehen, die von Pathworks über das Netzwerk geschickt wurden -, „war ich irgendwie überrascht - aha, da ist es ja, und ich lud es herunter. Über die allgemeine Bewegung der freien Software zerbrach ich mir dabei nicht den Kopf, sagt er. Das sollte sich nach seiner Begegnung mit GNU/Linux ändern. „Nachdem ich begonnen hatte, die Mailinglisten zu lesen, verstand ich sehr schnell, was da vor sich ging, und ich wollte mich beteiligen." Zum Glück tat sich nach einem Jahr eine weitere Chance auf, die ihm zeigte, in welcher Form er das tun konnte. „Das war etwa um die Zeit, als ich zu Hause ein kleines Netzwerk aufgesetzt hatte." Inzwischen verwendete Tridgell GNU/Linux, aber die Maschine seiner Frau lief unter Microsoft Windows. Das Problem war, wie die beiden verschiedenen Systeme vernetzt werden konnten. „Da fiel mir eine E-Mail ein, die ich von jemandem bekommen hatte, in der stand, dass mein Server mit Microsoft Windows als


------------------------------------------------------------------------------------Client funktionierte", erinnert er sich. Das bedeutete, dass Tridgells Pathworks-Server auch mit PCs kommunizieren konnte, die mit Microsoft Windows arbeiteten, nicht nur mit jenen, die mit Windex von Digital liefen, das auch er ursprünglich verwendet hatte. „Ich hatte die E-Mail damals nicht weiter beachtet", sagt er, „weil ich davon ausging, dass der Betreffende nicht wusste, wovon er sprach." Schließlich, so sagt er, „hatte ich einen Pathworks-Server und keinen Windows-Server geschrieben. Und man bekommt ja jede Menge verrückter E-Mails. Aber ich lud mir den Code [für den PathworksServer] trotzdem herunter - ich musste mich tatsächlich hinsetzen und ihn mir herunterladen, weil ich keine Kopie hatte - und probierte ihn auf meinem GNU/Linux-Gerät und mit dem Windows-Gerät meiner Frau zu Hause aus." Tridgell erkannte schnell, dass das Ergebnis seines kurzen weihnachtlichen Hackeranfalls viel wertvoller war als ursprünglich gedacht: Es war eine Methode, die Unix- und Windows-Geräten die gemeinsame Verwendung von Dateien gestattete. Von dieser Entdeckung beflügelt, kündigte Tridgell am 1. Dezember 1993 ein Projekt zur Verbesserung seines alten File-Sharing-Codes an. „Darauf bekam ich Reaktionen von vielen Leuten", erinnert er sich. „Mit vielen meine ich die Größenordnung von etwa fünfzig oder hundert, was damals, wenn man ein Projekt freier Software ankündigte, eine ganze Menge war." Bei Linux hatte es anfangs schließlich nur eine Hand voll Leute der Mühe wert gefunden zu reagieren. „In diesem Stadium stellte ich den Code unter die GPL", sagt Tridgell. „Ich glaube, dass der Hauptgrund dafür Loyalität gegenüber Linux war. Ich machte das auf Linux und mir gefiel, wie sich GCC und die anderen GNUProjekten entwickelten. Ich wollte einfach dazugehören." In einer kurzen Geschichte von Samba, die er verfasste, erklärt Tridgell, wie der Name „Samba" zustande kam. „Der Code in Samba wurde anfangs einfach ,Server' genannt. Als ich dann entdeckte, dass das Protokoll SMB heißt, wurde er auf ,Smbserver' umbenannt. Dann, im April 1994, bekam ich eine E-Mail von Syntax, dem Hersteller des ,TotalNet advancecd Server', eines kommerziellen SMB-Servers. Sie sagten mir, dass sie den Namen SBMserver als Warenzeichen angemeldet hätten und dass ich den Namen ändern


--------------------------------------------------------------------------------------müsste." Also hielt Tridgell Ausschau nach Wörtern, die die Buchstaben S, M und B enthielten und kam so auf Samba (eine andere Möglichkeit war „Salmonberry" gewesen). Samba entwickelte sich im klassischen Open-Source-Stil. „Die Leute fingen irgendwie an, Patches zu schicken", sagt er, „und ich begann wie wild, das Projekt zu verbessern. Nachdem ich eine Spezifikation SMBProtokolls gelesen hatte, dauerte es nicht lange, bis ich entdeckte, dass in der Spezifikation jede Menge Löcher waren." Diese Löcher in der Spezifikation machen SMB zu einer interessanten Mischung zwischen offenem und geschütztem Standard. „Microsoft vertritt die Einstellung, dass, wenn die Spezifikation in ihrer bestehenden Form und die Implementierung in Windows NT unterschiedlich sind, NT richtig und die Spezifikation falsch ist." Das hat eine direkte Folge für Tridgell und das Samba-Team. „In der SMBWelt", sagt er, „liegt der Sinn des Protokolls heute einzig in der gemeinsamen Verwendungsfähigkeit mit Microsoft. Deshalb führen wir alle unsere Tests im direkten Vergleich zu den MicrosoftImplementierungen durch. Und wir versuchen, Bug für Bug kompatibel zu bleiben, wo das Sinn macht. In manchen Fällen macht es keinen Sinn, und ihre Bugs sind einfach lächerlich, und man sollte sie eigentlich nicht emulieren. Aber in den meisten Fällen emulieren wir die Bugs, damit wir problemlos mit der Microsoft-Implementierung arbeiten können." Tridgell führt in diesem Kontext ein wichtiges Argument über Microsoft ins Treffen. „Sie glauben, dass sie die einzige Implementierung dieses Protokolls haben, obwohl sie genau wissen, dass es nicht so ist. Aber sie kontrollieren den Server und sie kontrollieren den Client, und deshalb können sie es sich leisten, den Code einfach auf den Client und auf den Server zu werfen, und er funktioniert. Sie zerbrechen sich im Vorfeld nicht den Kopf über ein ordentliches Design." Diese Analyse klingt wie eine Warnung vor dem, was passieren könnte, sollte Microsoft jemals eine dominierende Position im Web erlangen und seine Macht auf die Client- und die Serverseite dazu gebrauchen - oder missbrauchen - können, schlechten Code zu verschleiern. Hier wird wieder einmal deutlich,


------------------------------------------------------------------------------------wie wichtig unabhängige Projekte wie Apache und Mozilla sind, die sich zu offenen Standards bekennen. Die Einstellung von Microsoft zu den SMB-Protokollen bedeutet, dass es den Basisstandard erweitert hat und dass Samba die Erweiterung nun auch verfolgen muss. Das ständige Beschatten von Samba führte zu einer gewissen Ambivalenz aufseiten des Softwareunternehmens. „Unsere Beziehung zu Microsoft ist ziemlich interessant", sagt Tridgell. „Es gibt bei Microsoft ein paar Leute, die sich sehr bemühen, uns zu helfen, weil sie der Meinung sind, dass Samba ihnen eine entscheidende Verbindung zur Unix-Welt bietet. Es ist schon vorgekommen, dass Microsoft-Ingenieure bei uns anrufen und uns beim Installieren von Samba um Hilfe bitten, weil es ihnen ermöglicht, NT auf einem bestehenden Unix-Shop zu installieren." Aber, so fügt er hinzu, „es gibt auch andere, die versuchen, uns Steine in den Weg zu legen. Microsoft ist ein großes Unternehmen, und man findet dort natürlich die verschiedensten Meinungen." Diese Meinungen trugen zweifellos noch mehr zur Polarisierung bei, als die Benchmarks 1999 ins Spiel kamen, denn diese präsentierten Samba und GNU/Linux in einem zunehmend günstigen Licht. Nach dem ursprünglichen Vergleich in Sm@rt Reseller am 25. Januar, demzufolge GNU/Linux mit Samba NT als Fileserver um Längen schlug, überprüften die Labors von PC Weck am 1. Februar den neuen Linuxkernel Version 2.2. Der ursprüngliche Sm@rt-Reseller-Test hatte Version 2.0 des LinuxKernels unter die Lupe genommen, die zu diesem Zeitpunkt bereits über zwei Jahre alt war. Es war vielleicht nicht allzu überraschend, dass der Artikel von PC Week wie folgt begann: „Achtung Microsoft: Der neue Linux 2.2.0 Kernel wurde nun zusätzlich zu der Zuverlässigkeit, der Flexibilität und dem unwiderstehlichen Preis des Betriebssystems um unternehmenskritische SMP [Symmetrie Multi-Processor]-Fähigkeiten erweitert. Ein starker Grund für Benutzer, die genug davon haben, sich mit den Verzögerungen und Mängeln von Windows 2000 herumzuschlagen, sich ernsthaft mit der Plattform zu beschäftigen." Dann, am 26. März, sah sich dasselbe Sm@rt-Reseller-Team, das den Artikel vom 25. Januar geschrieben hatte, Samba 2.0 nochmals


--------------------------------------------------------------------------------------an. Wieder waren die Kommentare eindeutig. Unter dem Titel „Samba 2.0: Eine Lizenz zum Töten von NT?" begannen sie: „Wer braucht eine NT-Lizenz? Wir nicht!", und schlossen wie folgt: „Selbst wenn Ihre Kunden fest im Microsoft-Lager verankert sind, sollten die viel schnelleren Datei- und Druckdienste von SMB - und ohne die Lizenzgebühren von Microsoft - doch ein starkes Argument sein. Bei einfachen Server-Message-Block-Datei- und Druckdiensten ist Samba unschlagbar. Ohne wenn und aber." Das Verdikt erschien einstimmig zu sein und die Niederlage atemberaubend: Die Kombination „Freies GNU/Linux und Samba" schlug das geschützte Windows NT als Fileserver in jeder Hinsicht. Aber ganz einhellig waren die Meinungen trotzdem nicht. Als für Microsoft schon alles verloren schien, erschien auf wundersame Weise ein Benchmark, in dem das Gegenteil behauptet wurde und dem Riesen aus Redmond die Munition in die Hand gab, die er so dringend brauchte. Am 13. April gab eine Firma namens Mindcraft eine Presseaussendung mit folgendem Titel heraus: „Microsoft-Studie ergibt überlegene Leistung des Windows NT Servers im Vergleich zu Linux." In der Zusammenfassung heißt es: „Der Microsoft Windows NT Server ist als Fileserver 2,5-mal so schnell als Linux und als Webserver 3,7-mal so schnell." Wieder wurden NetBench und WebBench von Ziff-Davis für die Benchmarks herangezogen. Verwendet wurde ein PC mit vier IntelXeon-Prozessoren und einem Gigabyte Speicher (fast identisch mit der Maschine von PC Week beim Test vom 1. Februar). Mindcraft war 1985 von Bruce Weiner gegründet worden. „Wir machen seit etwa vier oder fünf Jahren fast nur noch Leistungstests", erklärt Weiner. Diese Tests werden in zwei Formen durchgeführt: „Einer ist ein Leistungstest für Händler, damit sie feststellen können, ob ihre Produkte unter den vorgesehenen Umständen bestmöglich funktionieren", sagt er. „Diese Tests werden im Allgemeinen nicht veröffentlicht. Die anderen sind für das Leistungsmarketing gedacht. Sie werden fast immer veröffentlicht." Fast unmittelbar nach Erscheinen der Presseaussendung wies eine Nachricht, die Dave Whitinger an die Website Linux Today geschickt hatte, auf einen ungeheuer wichtigen Punkt in dem


------------------------------------------------------------------------------------Benchmarkingbericht hin, der in der Presseaussendung nicht erwähnt worden war. Unter der Überschrift „Mindcraft Certification", merkt Whitinger an, fand sich die folgende Passage: „Die in diesem Bericht beschriebenen Leistungstests wurden vom 10. bis 13. März 1999 von Mindcraft, Inc., durchgeführt. Die Tests wurden von der Microsoft Corporation gesponsert." Zu dieser wichtige Auslassung sagt Weiner: „Anfangs gab es in dem Vertrag eine Klausel, die es uns verbot, den Test detailliert zu besprechen. Andere Details wurden genehmigt." Weiner war sich sehr wohl bewusst, dass es besser gewesen wäre, diese Klausel von vornherein wegzulassen. „Ich schlug das vor", sagt er, und beschreibt die Reaktion von Microsoft auf diesen Vorschlag: „Sie sind ein großes Unternehmen, und ich glaube, dass das, was passiert war, irgendwo unterwegs falsch kommuniziert oder falsch verstanden wurde. Als das klar wurde, sagten sie: Aber sicher, sagt es ihnen nur.' Ich nehme an, dass irgendjemand, der an ausreichend hoher Stelle saß, von dem Lärm Notiz genommen haben muss." Der Lärm war beträchtlich. „Ich erwartete einiges: ,Sie wissen nicht, wovon sie reden' - diese Art Dinge", sagt Weiner. .Aber der Sturm, der dann einsetzte, war unvorstellbar. Es war, als hätte ich ein Baby umgebracht oder so etwas. Ich hatte es aber nicht umgebracht, sondern ihm nur eine Ohrfeige gegeben, und ich sagte: ,Nein, nein, macht das nicht, lernt Heber, wie es richtig geht.'" Aber die Open-SourceGemeinde hatte das Gefühl, dass sogar eine Ohrfeige eine tödliche Beleidigung war, und Microsoft muss über die Vehemenz der Reaktion verblüfft gewesen sein. Über den ursprünglichen Ansatz von Microsoft sagt Weiner: „Sie hatten uns kurzfristig vorher kontaktiert - nicht Monate vorher." Das setzte Mindcraft unter einen gewissen Druck, weil „für diese Tests typischerweise viele Setuparbeiten erforderlich sind", sagt er. Mindcraft und Microsoft kamen überein, die WebBench- und NetBenchProgramme zu verwenden. „Dagegen ist nichts einzuwenden", erklärt Weiner, „weil dann niemand sagen kann, man hätte den Test beeinflusst." Trotzdem sagten die Mitglieder der Open-Source-Gemeinde genau das. Der Grund lag darin, dass immer mehr Details über die Umstände des Tests an die Öffentlichkeit drangen. Passenderweise


--------------------------------------------------------------------------------------war Vaughan-Nichols vom Sm@rtreseller einer der Ersten, die auf einige interessante Fragen bezüglich der Vorbereitung der beiden Systeme hinwiesen. Wie Vaughan-Nichols in seinem Artikel vom 15. April 1998 erklärte, bekam Mindcraft beim Tunen des Systems für eine optimale Leistung Direktunterstützung von Microsoft. Beim GNU/ Linux-System war jedoch keine vergleichbare Hilfe verfügbar, weder von Red Hat, dessen Distribution fiir den Test verwendet wurde, noch von der Open-SourceGemeinde im Allgemeinen. Die Folge war, dass dem für den Test verwendeten Red-Hat-System mehrere wichtige Tweaks fehlten, die seine Leistung verbessert hätten. Weitere Nachforschungen der Open-Source-Gemeinde ergaben interessante Einzelheiten über die Versuche von Mindcraft, Tuninginformationen fiir GNU/Linux zu bekommen. Dabei wurden auch einige Hilfsappelle an Usenet-Newsgroups gerichtet. Weiner erklärt, was passierte. „Wir machten das ganz am Anfang des Tests", sagt er. „Ich glaube, wir posteten sogar selbst eine Anfrage. Wir bekamen keine nennenswerten Reaktionen, und dann wurde eine von einer anderen Partei gepostet. Zu diesem Zeitpunkt gab es eigentlich keine Reaktionen, zumindest keine, die wir hätten gebrauchen können." Zu sagen, dass es „keine Reaktionen gab, die wir hätten gebrauchen können", ist nicht fair, denn noch am selben Tag, am 11. März 1999 wurde eine Antwort mit detaillierten Kommentaren und Vorschlägen gepostet. Aber sie bezogen sich auf eine Änderung im Setup des Systems und die Verwendung eines anderen Betriebssystems und konnten deshalb nicht aufgegriffen werden. Hätte sich Mindcraft nach ernst zu nehmender Hilfe für die Benchmarktests umgesehen, hätte es natürlich erklären müssen, wozu es die Informationen brauchte. Unter diesen Umständen hätten Open-Source-Anhänger alles daran gesetzt, beim Tunen des Systems behilflich zu sein. Weiner erklärt, warum er das Gefühl hatte, er könne diesen Schritt nicht tun. „In der Open-Source-Welt", sagt er, „ist Microsoft für viele der Bösewicht. Wir wussten, wenn wir das erwähnt hätten, wäre sofort ein Feuersturm losgebrochen." Das ist nachvollziehbar,


------------------------------------------------------------------------------------lässt jedoch immer noch die Möglichkeit offen, die Benchmarkings zu erwähnen, ohne das Unternehmen zu benennen, das sie sponserte. „Es war wirklich sehr eilig, und die Ereignisse überschlugen sich", sagt Weiner. „Rückblickend betrachtet hätten wir es natürlich viel besser machen können, keine Frage. Wir haben jedoch aus der Erfahrung gelernt. Ich glaube, dass wir die Informationen bekamen, die wir für das zweite Mal brauchten." Das „zweite Mal" bezieht sich auf Weiners Entscheidung, die Benchmarks noch einmal durchzuführen, dieses Mal mithilfe der Spitzenleute der Linux- und Samba-Welt. Im Gegensatz zu Weiners Behauptung, dass sie jetzt alle Informationen hatten, die sie brauchten, war die Open-Source-Gemeinde, obwohl sie alles in ihrer Macht Stehende tat, um zu helfen, immer noch zutiefst unzufrieden mit dem allgemeinen Setup und hatte das Gefühl, den notwendigen Input nicht geben zu können. In Wirklichkeit ging es um die fortgesetzte Weigerung von Mindcraft, im zweiten Durchgang die Anwesenheit von Vertretern der OpenSource-Welt zuzulassen. Die Open-Source-Gemeinde war überzeugt davon, einen beträchtlichen Nachteil zu haben, wenn ihr kein Zugang zum Testbett gewährt wurde. Jeremy Allison, der einer der wichtigsten Akteure im Benchmarkdrama von Mindcraft werden sollte, hatte bereits eine Ahnung, warum der Open-Source-Community dieser Zugang verwehrt wurde. Allison, der 1962 in Seffield, England geboren wurde, ist nach Andrew Tridgell die Nummer zwei der Samba-Welt. „Ich bin derjenige, der das Zeug macht, das gemacht werden muss, bevor eine Version in Produktion geht", sagt er. „Ich bin also paranoid." In dieser Hinsicht spielt Allison eine ähnliche Rolle wie Alan Cox in der Linux-Welt. Allison hat eine langjährige Karriere hinter sich, im Zuge derer er bei Sun, Cygnus, SGI und in letzter Zeit VA Linux Abstecher als Softwareingenieur machte. Seine Open-Source-Geschichte ist makellos. Ende der achtziger Jahre schrieb er einen Patch für GCC, den er an Richard Stallman schickte. Der antwortete prompt und kühl: „Nein." „Das war toll", sagt Allison. „Es war, als hätte ich eine Zurückweisung vom lieben Gott persönlich bekommen."


--------------------------------------------------------------------------------------Allison entwickelte sogar einen eigenen SMB-Server, obwohl er dazu anmerkt: „Niemand hat diesen Code je gesehen." Als er auf Samba stieß, „begann ich, einfach darauf zu hacken", sagt er, und er wurde rasch zum zweitwichtigsten Entwickler neben Tridgell. Als solcher und vielleicht weil er in Silicon Valley zu Hause war und Tridgell in Australien, war Allison einer der Experten, an die sich Weiner wandte. „Bruce Weiner rief mich an, und ich gab ihm Tuning-Ratschläge für Samba", erinnert sich Allison. „Das Valley ist wie ein Dorf, und die Leute unterhalten sich viel. Ich wusste, dass er oben bei Microsoft [in Seattle] arbeitete. Und das war wirklich komisch, weil ich irgendwie versuchte, ihn dazu zu bringen, das zuzugeben. Aber er tat es nicht." Am 4. Mai antwortete Weiner in einem Artikel in Linux Today mit dem Titel „Setting the Record Straight: Where Linux Today got it right and wrong" (Zur Klärung: Wo Linux Today richtig lag und wo nicht) auf einen Artikel, der am 27. April auf derselben Website erschienen war. Darin hatten Dave Whittinger und Dwight Johnson gefragt: „Wird Mindcraft II besser sein?" In dem Artikel anerkannte Weiner unter anderem, dass die Benchmarktests von Mindcraft in Wahrheit bei Microsoft durchgeführt worden waren. Weiner schrieb: „Viele deuteten an, dass mit den Mindcraft-Tests etwas nicht stimmen konnte, weil sie in einem Labor von Microsoft durchgeführt wurden. Man sollte dazu wissen, dass Mindcraft überprüfte, ob die Clients wie in unserem Bericht dokumentiert aufgesetzt waren, und dass es Mindcraft war und nicht Microsoft, das die Serversoftware lud und sie wie in unserem Bericht beschrieben tunte. Man könnte sagen, dass wir das Labor, das wir verwendeten, übernahmen und überprüften, ob es fair eingerichtet war." Es besteht kein Grund, das anzuzweifeln; aber es ist zu erwarten, dass die Ergebnisse eines Tests mit Argwohn und Skepsis betrachtet werden, wenn seine Umstände geheim gehalten werden. Dazu kam, dass die Durchführung der Tests in den Labors von Microsoft NT in den Vorteil setzte, weil Microsoft-Techniker bei den Tests anwesend waren. Wie Weiner sagt: „Sie waren für uns immer abrufbereit. Und wir führten Vorgespräche mit ihnen über Tunings für ihre Produkte, und sie empfahlen eine bestimmte Gruppe von Tunings."


------------------------------------------------------------------------------------Weiner betont: „Die Informationen, die wir bekommen, sind dieselben wie die Informationen, die öffentlich verfügbar sind. Wir bekommen also nichts Besonderes." Er räumt jedoch ein, dass „es bequem war, den Test in den Labors von Microsoft durchzuführen". Wie auch immer, die Tatsache, dass diese Techniker „allzeit bereit" standen, steht in schmerzlichem Kontrast zu der Weigerung, auch nur ein Mitglied der Open-Source-Community zu einem der Tests zuzulassen. „Ich denke, man drückt es am besten so aus: Die Frist war zu kurz, um dafür zu sorgen, dass alles reibungslos lief, sagt Weiner und verweist damit wieder einmal auf den Zeitdruck bei der Durchführung der Benchmarks. Weiner ist sich der Wichtigkeit der Frage bewusst. „Es war unglücklich", sagt er. „Ich weiß, dass sich die Typen, die uns halfen, deshalb übers Ohr gehauen fühlten. Sie wären schon zufrieden gewesen, wenn nur einer ihrer Leute zugelassen worden wäre. Ich sagte mir: Am besten ist es, diese [zweiten] Ergebnisse noch nicht zu veröffentlichen." Da sie mehr oder weniger unter denselben Umständen zustande gekommen waren, würden dieselben Anschuldigungen erhoben werden. Weiner erkannte, dass mehr vonnöten war. Er zitiert sich selbst: ,Machen wir ein offenes Benchmarking.' Dazu überredete ich Microsoft." Der Mann, der die damaligen Mindcraft-Benchmarkings bei Microsoft überwachte, war Jim Ewel, einer der erfahrensten Marketingexperten des Unternehmens. Er war 1989 zu Microsoft gestoßen und hatte, bevor er im Januar 1999 zum General Manager für das bevorstehende Windows 2000 (der endgültige Name für Windows NT 5) ernannt wurde, eine - wie er sagte - „eklektische Mischung" von Jobs innegehabt. Er arbeitete Seite an Seite mit Mike Nash, dem General Manager für den Launch von Windows 2000. Ewel erklärt, dass die Mindcraft-Benchmarks erstmals „als Projekt in Mike Nashs Gruppe" ins Auge gefasst wurden. Das Microsoft-Team hätte die Benchmarks, wie Ewel sagt, initiiert, „weil wir feststellten, dass es unheimlich viel PR für Linux gab, jede Menge Behauptungen über die Leistung und all so etwas. Wir glaubten einfach, dass die Realität ganz anders aussah. Deshalb wollten wir ein paar Fakten klären."


--------------------------------------------------------------------------------------Weiner sagt, dass die Hacker ihre Einstellung änderten, als offenes Benchmarking vorgeschlagen wurde. „Alle sagten, o.k., Jungs, jetzt werden wir euren Bluff aufdecken", erinnert er sich. „Und plötzlich trat die Linux-Gemeinde den Rückzug an", fügt er hinzu. In einer Hinsicht war das kaum überraschend. Schließlich wurde bei der Veröffentlichung der ersten Testergebnisse mit keinem Wort erwähnt, dass die Tests von Microsoft bezahlt worden waren, und auch nicht, dass sie in einem Labor von Microsoft durchgeführt worden waren. Das Tuning war für das GNU/Linux-System nicht optimal, und auch bei der zweiten Testrunde wurde den Vertretern der Open-Source-Welt kein Zugang zu der Ausrüstung gewährt. In einer anderen Hinsicht lag Weiner jedoch möglicherweise richtig, was den von ihm wahrgenommenen Rückzug anbelangte. Nachdem der erste Schock und die erste Wut nachgelassen hatten, begannen die Spitzenhacker ernsthaft zu analysieren, was da eigentlich vor sich ging. Einer der Gründe, warum das eine gewisse Zeit dauerte, lag in der Natur der Ziff-Davis-Benchmarks. Wie Andrew Tridgell erklärt: „Das Problem an NetBench ist, dass es eigentlich ein geschlossenes Benchmark ist: Es kann zwar von jedem heruntergeladen werden, man braucht aber, um es ernsthaft anwenden zu können, ein Labor, das die Kleinigkeit von einer halben Million Dollar kostet. Man kann es nicht einfach zu Hause durchführen und ein sinnvolles Ergebnis erwarten. Es gab für die Open-Source-Gemeinde eigentlich nur einen Ort, wo sie diese Art Konfiguration testen konnte", fährt er fort, „und das war bei SGI, wo Jeremy [Allison] arbeitete. Obwohl er es also machen konnte, war die Gebundenheit an diesen Ort ein enormer Flaschenhals. Sie bedeutete, dass Leute wie Alan [Cox], Linus und David Miller die Tests nicht selbst durchführen konnten." So gesehen hoben NetBench und WebBench die Linux-Community in eine neue Sphäre, in der die Open-Source-Techniken, die auf den Beiträgen der vielen Benutzer beruhten, die die Software auf ihren PCs laufen hatten, nicht mehr ausreichten. Aber Hacker sind bestimmt keine Leute, denen nichts einfällt. Allison betrieb NetBench mithilfe der SGI-Einrichtungen für nur einen PCClient, und alle Einzelheiten der über das Netzwerk fließenden Daten wurden aufgezeichnet. Tridgell spielte diese


------------------------------------------------------------------------------------Daten dann wieder ab, um zu simulieren, dass Hunderte Clients gleichzeitig liefen. Dafür verwendete er nur zwei schnelle GNU/ LinuxMaschinen, die miteinander verbunden waren. Auf diese Weise konnte NetBench auch ohne teures Labor angewendet werden. Nun konnte endlich untersucht werden, was mit den Mindcraft-Benchmarks los war. Tridgell hatte auch eine andere wichtige Arbeit durchgeführt: „Eines der Dinge, die man beim Benchmarking macht, ist, dass man herauszufinden versucht, welches Subsystem auf dem Server der Flaschenhals ist", sagt er. „Ich tat also Folgendes: Ich erstellte drei Benchmarks", von denen jedes einen anderen Teil der GNU/LinuxSamba-Kombination testete. Das Problem trat zutage, als die NetBenchSimulierung mit diesen drei Benchmarks durchgeführt wurde. Die Schwierigkeit lag nicht bei Samba, wie Tridgell mit Freuden vermerkte. Die Tests liefen auch ohne Samba langsam. Es stellte sich heraus, dass es „ein Problem mit dem Kernel war", wie er erklärt. „Im Grunde waren wir auf four-way SMP nicht skalierbar." Das war eine neue Spielart des alten Problems, „Linux ist nicht skalierbar". Es wurzelte dieses Mal tief im Inneren des Kernels und trat nur unter den extremen Umständen des Mindcraft-Tests zutage. Sobald Tridgell klar war, wo das Problem lag, fand er einen Weg, um es zu beheben. „Es war eine sehr, sehr hässliche Hackerei", sagt er mit der typischen Verachtung, die ein Spitzenhacker für solche groben Schnelllösungen hat. „Das machte uns um einen oder zwei Faktoren schneller. Natürlich war es nichts Ordentliches, kein Patch, den man einfach in einem Produktionskernel einfügen konnte." Das Gute daran war, dass das Problem dank Tridgells Analyse und dem schnellen Fix mit ein bisschen ernsthafter Hackerei behoben werden konnte. Das Schlechte war, dass es für das offene Benchmarking, das Weiner vorschlug, keinen geeigneten Patch geben würde. Allison dazu: „Ich wusste, dass wir verlieren würden, weil ich bereits das Benchmarking auf Linux im internen SGI-Labor durchgeführt hatte. Ich wusste, wo der Flaschenhals war und dass es keine Frage von Samba war. Im Grunde ging es zu diesem Zeitpunkt einfach um eine möglichst effiziente Schadensbegrenzung."


--------------------------------------------------------------------------------------In diesem Sinn hat Weiner wahrscheinlich Recht mit seiner Meinung, dass die Open-Source-Gemeinde sich von der Idee einer Revanche zurückzog. Es war klar, wo das Problem lag, und in diesem Stadium „war es reine Politik", wie Tridgell sagt. „Mindcraft versuchte, sein Gesicht zu wahren." Aber „das Gesicht zu wahren", war auch wichtig für Weiner. Der „Feuersturm", den die Benchmarks ausgelöst hatten, hatte ein schlechtes Licht auf seine Firma geworfen. Welche Mängel die beiden ersten Benchmarkings auch gehabt hatten - Mindcraft musste klarmachen, dass es nicht geschwindelt hatte. Sollten hier irgendwelche Zweifel bestehen bleiben, würde Mindcraft in Zukunft ohne Kunden dastehen. Weiner hatte ursprünglich am 4. Mai 1998 zum offenen Benchmarking eingeladen. Danach änderte er das Datum auf den 18. Mai, um einige der aufgeworfenen Fragen klären zu können. Der ausdrückliche Zweck der ersten Testphase bestand darin, „die Ergebnisse des zweiten Tests von Mindcraft zu reproduzieren". Wie Weiner sagt: „Der Grund, warum wir das wollten, war, dass klar würde, dass Mindcraft kein einziges verdammtes Ding gefälscht hatte." Die zweite Phase war die Phase, in der „Linux-Experten alles verwendeten, was zum Zeitpunkt des zweiten Mindcraft-Tests verfügbar war. Das würde zeigen, um wie viel besser Mindcraft es damals hätte machen können." Ziel der letzten Phase war es, „die beste Leistung unter Verwendung der heutigen Software" zu bekommen. Weiner sagt zu Recht, dass es „ziemlich tapfer von Microsoft war, diese dritte Phase an diesem Punkt zuzulassen. Microsoft hatte wenig zu gewinnen und viel zu verlieren, wenn es zuließ, dass die GNU/Linux-Plattform bis an die Grenzen des Möglichen getunt wurde. Ewel erklärt, dass es „eine gemeinsame Entscheidung war. Ich redete darüber mit Mike Nash und Jim Allchin" - einem der höchsten Manager von Microsoft. „Es war ein Risiko, und das war uns bewusst." Aber „wir wussten auch, dass wir ein gutes Produkt hatten, und wir waren ziemlich optimistisch, dass [die Linux-Hacker] kein Benchmarking,Special' zusammenbringen und uns schlagen würden." Der Grund war, dass er und seine Kollegen „uns mit unseren besten Technologieexperten zusammengesetzt hatten",


------------------------------------------------------------------------------------wie er erklärt, um alle Chancen und Risiken der Beteiligung an einem solchen offenen Benchmarking abzuwägen. Der letzte Punkt ist interessant, weil er darauf schließen lässt, dass Microsoft GNU/ Linux und Samba eingehend analysiert hatte und daher wusste, wie viel Arbeit nötig war, um die Probleme zu beheben, die von den MindcraftBenchmarks zutage gefördert worden waren. Trotzdem ist es Ewel und seinem Team zugute zu halten, dass sie den Mut hatten, dieses kalkulierte Risiko einzugehen. Nicht dass Microsoft die Situation nicht auf andere Weise voll ausgenutzt hätte. Am 12. Mai postete es auf ihrer Website ein Dokument mit dem Titel „Update zu Windows NT Server vs. Linux Leistung und Fähigkeiten". In diesem wie immer gut recherchierten Microsoft-Dokument wurden die bisherigen Mindcraft-Benchmarks anderen, unabhängigen Tests gegenübergestellt - zum Beispiel Tests, die gerade erst am 10. Mai in PC Week und am 11. Mai in PC Magazine erschienen waren. Sie alle schienen die Ergebnisse von Mindcraft zu bestätigen. Die offenen Benchmarktests bezweckten nicht nur die Zulassung von Vertretern der Open-Source-Welt, sondern sprachen auch andere Probleme an. So stellte sich zum Beispiel heraus, dass Samba besser auf PCs funktionierte, die mit Windows NT betrieben wurden als auf Windows-95- und -98-Maschinen, wie sie für die beiden ersten Mindcraft-Tests verwendet wurden. „Mir persönlich war das nicht immer bewusst", sagt Weiner. Aber das offene Benchmarking würde sowohl mit Windows-95/98- als auch mit Windows-NT-Clients durchgeführt werden. Dazu kam, dass für die Tests zuerst ein Prozessor und danach vier mit entsprechenden Speichergrößen verwendet werden würden, weil GNU/Linux so ausgelegt war, dass es auf schlankeren Systemen besser lief. Weiners letzte Konzession bestand darin, die Durchführung dieser offenen Benchmarkings in einem unabhängigen Labor zu gestatten. Weiner erklärt: „PC Week und ZD Labs sagten: .Warum machen Sie es nicht hier?' Offensichtlich witterten sie eine gute Story. Und wir sagten: Ja großartig, das würden wir gern tun.'" Da die Benchmarks ursprünglich von Ziff-Davis stammten, lag in dieser Entscheidung für diese High-Noon-Szene eine gewisse Gerechtigkeit. Alle Parteien waren sich einig, auf dieser Basis


--------------------------------------------------------------------------------------teilnehmen zu wollen. Das Benchmarking begann am 14. Juni. „Wir wollten es schon viel früher", sagt Weiner, „aber [der Leiter der ZDLabors] konnte mit dem Labor keinen früheren Termin vereinbaren." Nach der Dramatik der vorhergehenden drei Monate wurde das Ergebnis als enttäuschend empfunden. Wie alle erwartet hatten, schlug Windows NT GNU/Linux, das mit Apache und Samba lief. Henry Baltazar und Pankaj Chowdhry berichteten in PC Week: „Nach quälenden fünf Testtagen, die von den besten und klügsten Köpfen von Mindcraft, Microsoft und Red Hat Software Inc. überwacht wurden, und trotz der signifikanten Verbesserungen, die auf Linux-Seite vorgenommen worden waren, schlug Windows NT 4.0 Linux mit dem Apache-Webserver und Samba in allen Leistungskategorien, obwohl Microsoft knapper gewann als in den Tests von Mindcraft. Weit interessanter ist jedoch, dass sich die Annahmen der Linux-Gemeinde in allen Bereichen, in denen sie ein Foul vermutete, als falsch erwiesen." Weiner sagt, er fühle sich von dem Ergebnis „vollkommen bestätigt", und für die Microsoft-Seite vermerkt Ewel: „Wir sind über die veröffentlichten Endergebnisse sehr erfreut." Die Mindcraft-Benchmarks läuteten für die GNU/Linux-Gemeinde eine schwierige - und wichtige - Zeit ein. Davor hatten ihre Mitglieder in ihrer erhabenen Isolation vom Rest der Computerwelt fast geschwelgt. Wie rebellischen Jugendlichen hatte es ihnen großes Vergnügen bereitet, den Autoritäten den Gehorsam zu verweigern und die Dinge auf ihre eigene Art zu machen - in der Sicherheit, dass ihr Ansatz „selbstverständlich" der bessere sei. Die Mindcraft-Benchmarks änderten alles. Sie zeigten, dass der LinuxKern trotz all seiner Stärken auch echte Schwächen hatte. Er war immer noch nicht gut skalierbar. Die Tatsache, dass er bei diesen Benchmarks nicht glänzte, erschütterte die Selbstzufriedenheit der Hackergemeinde, die davon ausgegangen war, dass Linux in allen Bereichen das Beste war. So betrachtet leitete das schlechte Abschneiden zu einer Art Übergangsritus - schmerzlich, aber notwendig - in die Erwachsenenwelt des echten Computing über. Insbesondere sorgte es für eine ziemlich unangenehme Initiation in die manchmal nicht gerade faire Geschäftswelt.


------------------------------------------------------------------------------------Die Mindcraft-Tests zeigten trotz der Aufdeckung der zweifelhaften Beziehung des Unternehmens zu Microsoft eindeutig, dass sich GNU/Linux für diese Art System auf Unternehmensebene nicht so gut eignete wie Windows NT. Open-Source-Befürworter könnten darauf verweisen, dass Testsystem und Benchmarks so gewählt wurden, dass sie ihre Software möglichst schlecht dastehen ließen; aber die Unternehmen verwenden diese Systeme nun einmal, und solche Benchmarks, mit wie vielen Mängeln sie auch behaftet sein mögen, spielen eben eine Rolle in der IT-Politik der Unternehmen. Linus selbst hatte vor kurzem die Realitäten vergleichender Tests anerkannt, als er in einem frühen Meinungsaustausch über die relative Leistung von GNU/Linux im Februar 1993 von „Lügen, verdammten Lügen und Benchmarks" geschrieben hatte. Wenn GNU/Linux auf dem Geschäftsmarkt ernst genommen werden wollte, musste es sein Abschneiden in derartigen Tests verbessern. Andrew Tridgell hatte mit seiner Arbeit bereits den Weg geebnet, und die ersten Patches trudelten bald ein. Zuerst hackte Dave Miller ein bisschen, aber „der Mann, der die eigentliche Arbeit leistete, war Ingo Molnär von Red Hat", wie Tridgell sagt. Tridgell erklärt, dass Molnär „unsere Leistung verdreifachte, in manchen Fällen sogar vervierfachte". Die Mindcraft-Geschichte bewirkte mehr als das Einsenden einiger praktischer Patches. „Sie sorgte dafür, dass wir uns wirklich fokussierten", ist Tridgell überzeugt. „Vor allem in technischer Hinsicht brachte sie uns dazu, uns auf die größeren Benchmarks anstelle der winzigen Mikro-Benchmarks zu konzentrieren. Bis dahin hatten die Kernel-Entwickler Mikrobenchmarks wie lmbench verwendet." Dabei handelte es sich um Larry McVoys Software für das Tuning auf sehr niedriger Ebene. In diesem Bereich, so Tridgell, „war Linux allen anderen Betriebssystemen unglaublich weit voraus." Aber lmbench „belastete das Betriebssystem auch nicht, wenn fünfzig Prozessoren gleichzeitig liefen," sagt er. „Ein skalierbares SMP auf Kernel-Level zu bekommen ist viel schwieriger, und niemand hatte bis dahin daran gearbeitet. Diese Episode bewirkte, dass nun intensiv daran gearbeitet wurde." In gewissem Sinn


--------------------------------------------------------------------------------------hatten die Mindcraft-Benchmarks Linux also einen großen Dienst erwiesen. Linus erkannte das schließlich auch, aber erst nachdem auch er den Gleichmut und den kühlen Kopf, die so charakteristisch für ihn waren, verloren hatte. Weiner sagt: „Ich bekam den Feuersturm zu spüren, den die Spitzen der Open-Source-Welt entfachten", und Allison erinnert sich, dass „Linus [Weiner] dieses unglaublich gemeine E-Mail schickte, in dem er ihn wütend beschimpfte". Einen Augenblick lang hatte Linus vergessen, dass Bugreports von Benutzern in neuen Situationen, die die Software auf eine neue Weise belasteten und beanspruchten, Linux immer genutzt hatten, weil sie es besser machten. Und die MindcraftBenchmarks hatten dasselbe bewirkt, indem sie zeigten, was getan werden musste, wenn GNU/Linux eine Unternehmenslösung werden wollte. Ein konkretes Ergebnis dieses Inputs war einer Ankündigung von Red Hat vom 15. August 2000 zu entnehmen, derzufolge mit GNU/ Linux betriebene Dell-Server „die schnellsten Weblösungen aller getesteten Lösungen" und doppelt so leistungsstark wie Windows 2000 mit demselben Vier-Prozessor-System waren. Die Tatsache, dass die Tests Linux zu Verbesserungen anspornten, war für Microsoft eine unerwünschte Nebenwirkung. Noch unangenehmer aber war etwas anderes, das tiefer ging. Indem Microsoft dafür sorgte, dass GNU/Linux, Apache und Samba mit Windows NT verglichen wurden, bekundete es auf die nachdrücklichste Weise, dass es diese Systeme als Rivalen betrachtete. Schließlich hätte es keinen Sinn gemacht, Benchmarkings mit Systemen durchzuführen, die nicht in irgendeiner Weise vergleichbar gewesen wären. Damit rückte Microsoft erheblich von seinem bis dahin vertretenen Standpunkt ab, dass GNU/Linux sich nicht für Aufgaben auf Untemehmensebene eigne und dass es ohnehin von niemandem verwendet würde. Die Mindcraft-Benchmarkings brachten diese Position deutlicher ins Wanken als irgendwelche Aktionen vonseiten der Open-SourceGemeinde es vermocht hätten. Mit einem Streich hatte Microsoft GNU/Linux offiziell zu seinem Rivalen ernannt. Dazu kam, dass es durch den ungeschickten Umgang mit dem entstandenen Aufruhr dafür sorgte, dass die Botschaft drei Monate lang Zeit


------------------------------------------------------------------------------------zu wirken hatte - nur für den Fall, dass jemandem die erste Ankündigung vom April entgangen war. Unbeschadet seiner öffentlichen Äußerungen änderte Microsoft seine Einstellung zu GNU/Linux in dieser Zeit auch intern. Ewel erklärt, dass wir „ein paar Techniker hatten, die sich Linux ansahen, aber es gab kein Geschäfts- oder Produktplanungsteam, das sich der Sache angenommen hätte". Etwa um die Zeit, als die Mindcraft-Benchmarkings durchgeführt wurden, wurde dieser Mangel behoben. Dieses kleine „Linux-Wettbewerbsteam", wie es innerhalb von Microsoft genannt wird, ist Ewell unterstellt. „Genau genommen gibt es bei uns nur einen Typen, der sich ausschließlich mit Linux beschäftigt", erklärt Ewel. Auf der Marketingseite sind es hingegen fünf Leute, die nicht nur Linux, sondern auch Sun und Novell im Auge behalten. Mittlerweile gibt es auf der technischen Seite, so Ewel, einen „Vollzeittypen und vier oder fünf Leute, die wahrscheinlich zehn bis 20 Prozent ihrer Zeit damit zubringen, zu sehen, was Linux so macht." Microsoft hatte inzwischen wohl erkannt, dass die MindcraftBenchmarkings insofern ziemlich schief gelaufen waren, weil sie positive Publicity für GNU/Linux erzeugt hatten. Deshalb holte es im Oktober zu einer neuerlichen Attacke aus, indem es auf seiner Website so genannte „Linux-Mythen" publizierte. Der Text begann so: „Da Linux in letzter Zeit so viel Aufmerksamkeit erregt hat, ist es nun wichtig, den Hype Hype sein zu lassen und einen Blick auf die Realität zu werfen." Der erste Teil, der sich mit der Leistung auseinandersetzt, beginnt mit den (von PC Week durchgeführten} Mindcraft-Benchmarkings und bringt dann andere unterstützende Berichte und Artikel. Im zweiten Teil geht es um die Zuverlässigkeit. Hier steht: „Linux verfügt über kein Journaling-File-System in kommerzieller Qualität." Es wird darauf verwiesen, dass „ohne ein solches System bei einem Stromausfall Datenverluste oder -schaden möglich sind." Das war seit langem ein wichtiges fehlendes Element von GNU/ Linux. Seit dem Erscheinen des Dokuments über die Linux-Mythen wurden jedoch einige Projekte zur Erstellung eines Journaling-File-Systems begonnen, zwei davon von kommerziellen Anbietern:


--------------------------------------------------------------------------------------IBM und SGI boten der Open-Source-Community ihre jeweilige Software an. Ein weiteres Projekt steht unter der Leitung von Stephen Tweedie, einem der erfahrensten Kernelhacker. Der Kommentar von Microsoft, dass es „keine kommerziell bewährten Clusteringtechnologien zur Bereitstellung von High Availability für Linux gibt", stimmte zum damaligen Zeitpunkt ebenfalls. Ein derartiges High Availability Clustering ermöglicht es, dass bei einem Ausfall einer Maschine in der Gruppe nicht sofort alles zusammenbricht. Die vielen nicht kommerziellen Clustering-Projekte, die damals existierten, wurden inzwischen viel reifer, und einige von ihnen, wie TurboLinux, wurden eine Zeit lang verkauft und voll unterstützt. Dass die höchst populäre Websuchmaschine Google von einem GNU/Linux-Cluster abhängt, der aus nicht weniger als 4.000 Maschinen besteht, ist Beweis genug dafür, dass sich diese Technologien „kommerziell bewährt" haben. Der dritte Mythos, den Microsoft zu zerstören sucht, ist der, dass „Linux frei ist". Das Unternehmen verweist zu Recht darauf, dass „die Kosten des Betriebssystems nur einen kleinen Prozentsatz der Gesamteigentumskosten (Total Cost of Ownership - TCO) ausmachen. Im Allgemeinen zeigte sich, dass Windows NT geringere Eigentumskosten als Unix hat." Aber die Aussage, dass es „keinen Grund zu der Annahme gibt, dass sich Linux in Bezug auf die TCO signifikant von anderen Unix-Versionen unterscheidet", lässt die Tatsache unter den Tisch fallen, dass die hohen Unix-Kosten zu einem großen Teil von der Zersplitterung des Sektors herrührten, die ihrerseits zu höheren Software- und Schulungskosten geführt hat. Der nächste Punkt befasst sich mit der Sicherheit. Microsoft behauptet, dass das „Sicherheitsmodell von Linux schwach ist." Aber viele glauben, dass es das Sicherheitsmodell von Microsoft ist, das mit ernsthaften Fehlem behaftet ist. Einer dieser Leute ist Bruce Schneier, Autor des klassischen Buches Applied Cryptography und eine angesehene unabhängige Autorität auf dem Gebiet der Computersicherheit. In der im September 1999 erschienenen Ausgabe seines freien monatlichen Newsletters Crypto-Gram untersucht Schneier die relative Sicherheit von geschlossener und Open-Source-Software. Er schreibt: „Als Experte für Verschlüsselung und Computersicherheit habe ich nie verstanden, warum um


------------------------------------------------------------------------------------die Open-Source-Bewegung derzeit so viel Aufhebens gemacht wird. In der Verschlüsselungswelt betrachten wir Open Source als Notwendigkeit für eine zufrieden stellende Sicherheit; das ist schon seit Jahrzehnten so." Er schlieBt: „Die Sicherheit von Linux mit der von Microsoft Windows zu vergleichen, ist nicht besonders aufschlussreich. Microsoft ist bei der Sicherheit so erbärmlich, dass der Vergleich nicht wirklich fair wäre." Der letzte Punkt in dem Microsoft-Dokument über die Linux-Mythen betont, dass „Linux als Desktop-Betriebssystem keinen Sinn macht. Ein Benutzer würde mit einem System dastehen, das weniger Applikationen hat, komplizierter in Verwendung und Management ist und weniger intuitiv ist." Das Urteil, dass GNU/ Linux weniger intuitiv ist, wurde vom rasanten Fortschritt der KDE- und GNOME-Projekte, die die meisten Vorteile von Windows bieten, großteils außer Kraft gesetzt. Trotzdem hinkt die GNU/ Linux-Unterstützung für PCHardwaretechnologien wie Plug and Play (das die automatische Konfiguration von Geräten ermöglicht), PCMCIA (Peripheriegeräte für Notebooks in Kreditkartengröße) und USB (eine weitere einfache Methode des Hinzufügens von Hardware) zweifellos noch hinter Windows her, und es stimmt sicher, dass das System dadurch schwieriger zu verwenden und zu managen wird. Auch in der Aussage über die Verfügbarkeit der Software steckt mehr als ein Körnchen Wahrheit. Zehntausende Applikationen laufen unter Windows 95/98 und NT; GNU/Linux kommt dem nicht einmal nahe. Aber die Dinge ändern sich rasch, wie die wachsende Flut von Ankündigungen auf Sites wie Freshmeat zeigt. Dazu kommt, dass sich das Bild fast mit einem Schlag ändern könnte, wenn ein seit langem laufendes Open-Source-Projekt namens Wine endlich Früchte trägt. Wine, das im Juni 1993 begonnen wurde, soll es GNU/Linux-Systemen ermöglichen, unmodifizierte Windows-Applikationen direkt zu verwenden. Wie der derzeitige Leiter des Projekts, der gebürtige Schweizer Alexandre Julliard, sagt: „Der Name hat zwei Bedeutungen." Diese sind, wie es typische Hackerart ist, rein zufällig widersprüchlich. „Die ursprüngliche Bedeutung ist WINdows Emulator, und die andere ist ein rekursives Akronym,


--------------------------------------------------------------------------------------nämlich ,Wine Is Not an Emulator'", erklärt er. „Es geht darum, dass einfach alles verwendet werden kann. Ich glaube nicht, dass wir dieses Ziel wirklich erreichen können, aber ich glaube, dass wir genügend Kompatibilität für Dinge wie Microsoft Office erreichen können." Das wäre schon ein enormer Durchbruch. Sollte das Wine-Projekt ein Erfolg werden, wäre das für die GNU/Linux-Benutzer ein ungeheurer Vorteil. Es würde ihnen den Zugang zu der ganzen Palette von Windows-Programmen ermöglichen, ohne dass sie Windows selbst installieren müssten. Ein wichtiger Nebeneffekt wäre auch, dass es Unternehmen mit Windows-Software erlauben würde, ihre Produkte an GNU/Linux-Benutzer zu verkaufen, ohne ihre Programme direkt portieren zu müssen. Interessant ist, dass sich Microsoft in diesem letzten Linux-Mythos, in dem es um die Applikationen geht, von der Serverseite, dem Schwerpunkt aller anderen Punkte, abwendet und zum Desktop übergeht. 1998 und 1999 unternahm GNU/Linux große Anstrengungen, um sich Unterstützung für signifikante serverseitige Anwendungen zu verschaffen, wie in Kapitel 12 detailliert beschrieben wird. Das zeigt sich in einer entsprechenden Zunahme der Verwendung von GNU/Linux als Serverplattform. So geht aus Zahlen der Marktanalysefirma IDC hervor, dass von allen 1999 weltweit gekauften Serverbetriebssystemen 24,4 Prozent GNU/ Linux-Lizenzen waren. 1998 waren es 15,8 Prozent gewesen. Einige der Hauptmythen über Linux sind ein ziemlich genaues Spiegelbild der ursprünglichen Ziele des Windows-NT-Projekts, wahrscheinlich weil die meisten dieser Ziele auch weiterhin Prioritäten sind. In seinem Vorwort Inside Windows NT der offiziellen Projektgeschichte von Helen Custer, nannte der NT-Architekt Dave Cutler vier Bereiche, die im Linux-Mythen-Dokument nicht angesprochen wurden: die Portabilität, die Kompatibilität mit Posix, die Erweiterungsfähigkeit und die Internationalisierung. Die Auslassungen werden später verständlich, denn in allen Bereichen bis auf einen - der Intemationalisierung - liegt GNU/Linux vor Windows NT. Auf dem Gebiet der Portabilität - der Fähigkeit, auf verschiedenen Prozessoren zu laufen - liegt GNU/


------------------------------------------------------------------------------------Linux so weit vorn, dass es für das Betriebssystem von Microsoft ein erhebliches Problem darstellt. Zu Beginn lief Windows NT auf der InteI-x86-Familie und der NHPSR4000-Familie. Die Unterstützung für die Alpha-ACP-Chips von Digital und dem Motorola PowerPC kam später hinzu, aber Microsoft ließ die MIPS und PowerPC-Chips 1996 fallen. Die AlphaUnterstützung überlebte bis zum August 1999, als der Eigentümer von Digital, Compaq, ankündigte, Windows NT auf dieser Plattform fallen zu lassen. So blieb Microsoft NT nur noch ein Prozessor, die Intel-x86Familie. Wo die NT-Vielfalt zurückgegangen ist, hat sich die Zahl GNU/Linux-Ports vervielfacht, sodass nun praktisch alle Prozessorchips für das Betriebssystem geeignet sind, selbst so ungewöhnliche wie die in Palmtops verwendeten. Aber zweifellos ist der wichtigste Port von allen der für einen Intel-Chip, der 1999 noch von einer Wolke des Geheimnisvollen umgeben war und den Phantomnamen Merced trug. Später wurde er auf „Itanium" umbenannt und wird auch oft als IA-64 bezeichnet. Der „64" war wichtig, weil er darauf hinwies, dass dies die 64-Bit-Version der verehrungswürdigen Intel-x86-Familie war. Dank der Bemühungen Larry Augustins von VA Linux übernahm GNU/Linux hier schon sehr früh die Führung. Er wandte sich mit der Idee an Intel, GNU/Linux für die IA-64-Plattform zu portieren, weil ihm aufgefallen war, dass die Open-Source-Gemeinde Hardware und Dokumentation, wie es seit jeher der Fall gewesen war, immer noch lange nach allen anderen zu Gesicht bekam. Das bedeutete, dass die Ports von GNU/Linux jenen anderer Firmen, die vertraulich - und frühzeitig - Dokumentation erhielten, hinterherhinkten. „Wir sahen uns die Sache an und sagten: ,Hm, wie wäre es, wenn wir das zu ändern versuchten"', erinnert sich Augustin. ,„Wir möchten einmal einen Vorsprung haben.' Und wir betrachteten den neuen IntelProzessor als Chance, einen neuen Entwicklungsstandard zu schaffen. Das bedeutet, dass Open-Source- und Linux-Unterstützung ab dem ersten Tag verfügbar ist, wenn Hardware herausgebracht wird. Wir stellten einen Vorschlag zusammen, wie wir uns die Entwicklung vorstellten, und die Freigabepläne an die Open-Source-Gemeinde. Das war ein äußerst wichtiger Teil, dass


--------------------------------------------------------------------------------------wir mit Linus und der Entwicklungsgemeinde zusammenarbeiten würden, um sicherzustellen, dass das, was wir produzierten, nicht VASoftware war, sondern der Standard, den jeder verwendete. Intel gefiel dieser Ansatz." Augustin ist davon überzeugt, dass für die Entscheidung von Intel, diesen Vorschlag zu unterstützen, zwei wichtige Faktoren ausschlaggebend waren. „Ich kann Ihnen sagen, dass das Panel „Die Zukunft von Linux", das im Juli 1998 in Silicon Valley abgehalten wurde, „seine Wirkung nicht verfehlte", sagt er. Diese Wirkung zeigte auch Oracle, als das Datenbankunternehmen seinen Port von Oracle8 an GNU/Linux bekannt gab. Der zweite Faktor war „rein wirtschaftlicher Natur", wie Augustin sagt. „Intel wollte im Serverbereich präsent sein, und das gelang ihm nicht besonders gut. Sie sahen in Linux eine Chance, sich in diesem Bereich zu verbessern." Der Vertrag, demzufolge VA Linux die Entwicklung des Port von GNU/Linux für IA-64 leiten sollte, wurde am 2. März 1999 bekannt gegeben. Andere Unternehmen, von denen es in der Presseaussendung hieß, dass sie die Initiative unterstützten, waren Hewlett-Packard - das beim Design des IA-64 Chip geholfen hatte -, SGI, IBM, Compaq und Dell sowie Caldera, Debian, Red Hat und SuSE. Die Folge dieser Initiative und der breiten Unterstützung, die sie von der gesamten Computerindustrie erhielt, war, dass GNU/Linux im Rennen um die Portierung für den neuen Intel-Prozessor bald führte. So hielt zum Beispiel Michael Tiemann, der zum CTO von Red Hat ernannt wurde, nachdem es Cygnus gekauft hatte, bei einer Konferenz für Entwickler auf der neuen Plattform Anfang 2000 einen Kurs über die GNU-Entwicklungstools ab, die Cygnus für den IA-64 portiert hatte. „Microsoft war auf dieser Konferenz nirgendwo zu sehen", erinnert er sich. „Und ich fragte, ob es ihnen wirklich gelungen war zu zeigen, wie Windows 2000 auf dem IA-64 bootete. Wie mir die Leute erzählten, stellten sie sich am ersten Tag der Konferenz auf die Bühne, zeigten, wie es bootete und beendeten es dann, und ihre Maschine ging zurück in das kalte Depot." „Es gab jedoch einen Stand für Drittlösungen, an dem NEC, SGI, IBM, Compaq und alle anderen den IA-64 vorführten. Diese


------------------------------------------------------------------------------------Maschinen liefen den lieben langen Tag, fast während der ganzen Konferenz, und sie liefen alle unter Linux." Microsoft äußert sich über die ruhrende Stellung von GNU/ Linux auf diesem Gebiet nicht hörbar. Stattdessen versucht es Open Source so darzustellen, als jage es hinter Hecklichtern her", wie Jim Ewel es ausdrückt. Das ist nicht ganz falsch, weil GNU/Linux-Entwicklern, wie Augustin festgestellt hatte, der zeitgerechte Zugang zu den Spezifikationen der geschützten Hardware verwehrt wurde. Inzwischen hatte Intel der GNU/Linux-Gemeinde aber nicht nur Einzelheiten über den Itanium-Chip bekannt gegeben, sondern es hatte sogar bislang streng gehütete Geschäftsgeheimnisse über die Architektur des IA-64 ins Netz gestellt, wo alle sie sehen konnten -eine verblüffende Bekehrung zur Open-Source-Idee. Tiemann sagt dazu: „Der IA-64 ist der erste Fall, in dem wir gleiche Startbedingungen hatten, anstatt sechs Monate oder ein Jahr hinterherzuhinken." Und er weist auf Folgendes hin: „Es ist der erste Launch eines wichtigen neuen Prozessors, wo Linux das Standardbetriebssystem war. Das ist für mich ein ungeheurer Meilenstein, der Linux von der Nummer zwei auf den ersten Platz katapultiert." GNU/Linux gestaltet die Landschaft der Computerwelt nicht nur auf dem neuen Markt um, der vom Intel-Itanium-Chip definiert wird. Parallel zum Umstieg auf 64-Bit-Untemehmenssysteme erfinden sich infolge von GNU/Linux und Open Source praktisch alle Sektoren der Branche neu. Und das zeigte sich nirgendwo drastischer als bei den außergewöhnlichen Ankündigungen von IBM zu Beginn des Jahrs 2000.

17

Das Treibhaus von morgen

NACH DEM BAHNBRECHENDEN SCHRITT VON IBM im Juni 1998, Apache als Webserver zu verwenden, war die Akzeptanz von GNU/Linux und Open Source nur noch eine logische Weiterentwicklung, die wenig Aufsehen erregte. Im Dezember 1998, kurz bevor IBM den Jikes Java Compiler veröffentlichte, stellte es auch eine Betaversion seiner DB2-Datenbank für GNU/Linux zur Verfügung. Anfang 1999 „spendete" es Jakarta, das fortgeschrittene Fähigkeiten in das Apache-Webserver-Projekt einbringt, sowie XMLSchlüsseltechnologien. Im Verlauf des Jahres kam dann noch GNU/Linux-Support für einige der IBM-PCs und ThinkPad-Notebooks hinzu. Nichts davon ließ jedoch auf die Bombe schließen, die das Unternehmen Anfang 2000 platzen ließ. Am 10. Januar gab IBM bekannt, „alle unsere Serverplattformen Linux-freundlich zu gestalten, darunter die Server S/390, AS/400, RS/6000 und Netfinity; die Projekte befinden sich bereits in einem fortgeschrit-


------------------------------------------------------------------------------------tenen Stadium." Weiter hieß es in der Presseaussendung: IBM hat Quellcodemodifikationen herausgebracht, die es ermöglichen, dass S/390-Server unter Linux laufen. Diese Modifikationen können kostenlos von der IBM developerWorks Website heruntergeladen werden. IBM bietet für diesen Quellcode keine Support- und Wartungsdienste. Allerdings wird derzeit eine gemeinsame Kundenstudie durchgeführt, um zu erheben, ob von Kundenseite Interesse besteht und ob es Supportbedarf für Linux auf S/390-Servern gibt." Der offizielle IBM-Support begann am 17. Mai 2000, und an diesem Tag wurde auch angekündigt, dass SuSE und TurboLinux GNU/Linux für den S/390 als Produkt anbieten würden. Es gibt kaum ein besseres Symbol für den Aufstieg von Linux, das neun Jahre davor im Schlafzimmer eines zwanzigjährigen Hackers das Licht der Welt erblickt hatte, als die Tatsache, dass es nun auf dem mächtigsten und prestigeträchtigsten aller Unternehmensgroßrechner, dem IBM S/390, verwendet werden konnte. Der Schritt von IBM war jedoch nicht nur rein symbolisch, auch wenn mit „Linux-freundlich" eine ziemlich vage Beschreibung gewählt worden war. Neben den Ports gab IBM einen Schritt bekannt, der genauso historisch war und mit dem ein Linux-König im Unternehmen installiert wurde: Irving WladawskyBerger. Trotz seines mittel-/osteuropäisch angehauchten Namens spricht Wladawsky-Berger mit einem deutlich spanischen Akzent, der von seinen kubanischen Wurzeln herrührt. Er kam als Forscher zu IBM, gründete später die Internetabteilung des Unternehmens und leitete sie mit großem Erfolg. Zu diesem Zeitpunkt setzte IBM den ersten entscheidenden Schritt in Richtung Apache: „Ich arbeitete bei dieser Entscheidung eng mit meinen Kollegen in der Softwaregruppe zusammen", sagt Wladawsky-Berger. Wladawsky-Berger lernte aus diesem Schritt eine wichtige Lektion. „Wir erkannten alle, dass wir speziell in den Bereichen, in denen Technologien wichtig waren, die Interoperabilität, Integration und Applikationsportabilität förderten, mit der Branche zusammenarbeiten mussten", sagt er. „Die Devise war: ,Lasst uns mit unseren Konkurrenten zusammenarbeiten, lasst uns mit der Open-SourceBewegung zusammenarbeiten, denn das ist, wenn

17. Das Treibhaus von morgen

--------------------------------------------------------------------------------------wir alles zusammenbringen, die Schicht, die wir letzten Endes fördern. Dabei bleiben uns immer noch jede Menge Bereiche, in denen wir uns auf Wertschöpfung und Konkurrenz konzentrieren können. Dabei geht es darum, wie gut wir unsere Kunden unterstützen, wie gut wir die Systeme zusammenstellen, und was wir zu bieten haben, wenn es Probleme gibt." Er stellt auch eine wichtige Parallele zur Welt des Internet fest. „Wir haben gesehen, wie das bei TCP/IP war ... wo die Branche TCP/IP als gemeinsames Netzwerkprotokoll akzeptierte, um die Verbindungsfähigkeit zu fördern, und das Leben ging weiter. Es war einerseits möglich, bei TCP/IP mit der Branche zusammenzuarbeiten und andererseits aggressiv bei Systemen zu konkurrieren, die über TCP/IP verbunden werden." Wladawsky-Berger erklärt, wie das Unternehmen von der GNU/ LinuxRevolution aufgeweckt wurde. „Seit Herbst '98 gab es bei IBM immer mehr Aktivitäten, die um Linux kreisten. Ich glaube, dass Linux etwa Mitte '99 eine Art Wendepunkt erreicht hatte, wo es nicht länger nur eine großartige Forschungstechnologie war und plötzlich zu einer großartigen Technologie mit potenziellem kommerziellem Wert wurde." Dann begannen verschiedene Gruppen unabhängig voneinander Druck auf IBM auszuüben, GNU/Linux zu übernehmen. Der Prozess war ein Spiegelbild der Ereignisse, die zur Entscheidung von Netscape geführt hatten, seinen Browser als Open-Source-Produkt herauszubringen. Laut Wladawsky-Berger gab es im Sommer 1999 „drei Sichtweisen, die nun alle konvergierten". „Die erste besagte, dass Linux nun eine Unix-Plattform mit ständig zunehmendem Marktanteil wurde. Unsere Softwaregruppe hatte begonnen, unsere gesamte Middleware auf Linux umzustellen: Datenbanken, Transaktionensmanager" - die zum Beispiel zur Sicherstellung der Integrität von Kundenaktivitäten im E-Commerce verwendet wurden - „Domino für E-Mail und Zusammenarbeit." „Die zweite", erinnert er sich, „war in erster Linie bei unseren Leuten in der Forschung vertreten, die Linux und die Open-Source-Bewegung studierten. Sie hatten erkannt, dass Linux und die LinuxApplikationsschnittstellen das Potenzial hatten, den Standard für


------------------------------------------------------------------------------------die Entwicklung von Applikationen und ihre Anwendung zu definieren, wie TCP/IP die Standards für Netzwerke definiert hatte." „Und die dritte Sichtweise", sagt er, „war im Supercomputingbereich beheimatet und betrachtete Linux zunehmend als Basis für den Bau riesiger Supercomputer, die mit Maschinenclustem arbeiteten". Im Rahmen eines seit langem laufenden Open-Source-Projekts namens Beowulf wurden Supercomputer zusammengestellt, die zu den leistungsstarksten der Welt zählten. Dabei wurden Hardwarekomponenten von der Stange und eine leicht modifizierte Form von GNU/Linux verwendet. Das Ganze konnte um einen Bruchteil des Geldes realisiert werden, den solche Maschinen normalerweise kosten würden. „Im Herbst 1999", so Wladawsky-Berger, „kamen diese drei Gruppen zu dem gemeinsamen Schluss, dass wir Linux in die Internet- und EBusiness-Aktivitäten von IBM integrieren und dafür sorgen sollten, dass es auf allen unseren Plattformen lief. Wir empfahlen, es zu einer der Hauptplattformen für unsere gesamte Middleware zu machen und eine zunehmende Zahl von Geschäftsdiensten rund um Linux zu entwickeln. Und schließlich fiel die Entscheidung, das zu tun - kurz vor Weihnachten '99." Der Mann, der diesen endgültigen Schritt setzte, war Sam Palmisano, der Vorgesetzte von Wladawsky-Berger. „Ich glaube, dass die endgültige Entscheidungsbefugnis bei Sam lag", sagt WladawskyBerger, „weil sie im Rahmen seiner allgemeinen Geschäftsverantwortung lag, die den ganzen Bereich der Betriebssysteme umfasst." Zu diesem Zeitpunkt war Palmisano General Manager der Enterprise Systems Group, in der Wladawsky-Berger formal für Technologie und Strategie zuständig ist. Am 24. Juli 2000 wurde Palmisano zum Präsidenten und Chief Operation Officer von IBM ernannt. Die Möglichkeit, dass Palmisano in absehbarer Zukunft das IBM-Steuer von Gerstner übernehmen könnte, erhöht die Bedeutung von Palmisanos Entscheidung zur Unterstützung von GNU/ Linux und Open Source signifikant. Hier könnte ein Mann, der seine Karriere an den Erfolg von Open Source bei IBM geknüpft hat, weil er davon überzeugt ist, dass sich dieser Ansatz durchsetzen wird, in eine Position aufrücken, in der er die Macht hat, sie


--------------------------------------------------------------------------------------zum Kernstück der Strategie des Computerriesen zu machen - eine höchst interessante Situation. Ungeachtet der übergreifenden Logik liegen die praktischen Vorteile für IBM auf der Hand. Angesichts der Tatsache, dass IBM die breitestmögliche Palette verschiedener Hardwaresysteme herstellt - von tragbaren Computern bis hin zu Supercomputern -, hat es mehr als irgendein anderes Unternehmen unter den Folgen inkompatibler Software zu leiden. Indem es dafür sorgt, dass GNU/ Linux auf seiner gesamten Hardware läuft, vereinigt es mit sofortiger Wirkung alle Systeme zu einer einzigen Familie und bietet seinen Kunden eine perfekte Skalierbarkeit. Wenn IBM sein Versprechen, alle seine Serverplattformen „linuxfreundlich" zu machen, einlöst, kann dasselbe Softwareelement, das auf einem Desktop-PC erstellt, auf einem RS/6000-System getestet und dann auf einem AS/400-Minicomputer verwendet wird, auf einen S/390 verlegt werden, wenn das Unternehmen wächst, ohne dass auch nur eine einzige Codezeile geändert werden muss. „Wir waren dermaßen auf das Paradigma fixiert, demzufolge man in der Falle sitzt, sobald man die Anwendung auf einer Plattform entwickelt hat", sagt Wladawsky-Berger. „Und das Portieren von dieser Plattform für irgendeine andere Plattform ist eine kundenspezifische Sache, die viel Arbeit erfordert. Und dann taucht da plötzlich die Möglichkeit am Horizont auf, dass das bald der Vergangenheit angehören könnte. Er betont abermals, dass dieser Ansatz zwar radikal, aber nicht unbedingt neu ist. Bevor TCP/IP auftauchte, galt es als umfangreiche Maßschneiderungsaufgabe, verschiedene Systeme miteinander zu verbinden. Man engagierte dafür hoch spezialisierte Programmierer, weil es sich normalerweise um verschiedene Systeme handelte, die verschiedene Netzwerksprachen verwendeten. Dann kam die äußerst schwierige Aufgabe, die Systeme zur Zusammenarbeit zu bewegen. Sobald TCP/IP zu einem Standardfaktor für alle Systeme geworden war, die Teil des Internet sein wollten, unterstützte plötzlich jedes System TCP/


------------------------------------------------------------------------------------IP, und die Herstellung der Netzwerkverbindung war keine Frage mehr. Man schloss den Computer einfach an. Bei Linux ist nun diese kulturelle Verschiebung zu beobachten, derzufolge man, wenn man sich auf Standards für Applikationen einigt, eine Applikation entwickeln und dann separat davon eine Einsatzplattform wählen kann, je nachdem was am besten funktioniert. Das Konzept, die Anwendungsentwicklung von der zugrunde liegenden Einsatzplattform zu trennen, war seit langem ein Heiliger Gral der Branche, weil es die Anwendungsentwickler plötzlich von der Sorge um all diese Installationen befreien würde. Und nun hatten wir mit Linux plötzlich die beste Möglichkeit dazu. Die Tatsache, dass dieses Betriebssystem keinem Unternehmen gehört, sondern ein Open-Source-Produkt ist, spielt dabei eine ungeheuer wichtige Rolle. Es ist leicht vorstellbar, was unsere Konkurrenten gesagt hätten, wenn wir gesagt hätten: Leute, IBM hat ein neues Betriebssystem entwickelt, und wir wollen nun die ganze Welt dazu bringen, es zu übernehmen. Die Pläne von IBM sind ein ebenso großer Auftrieb für die OpenSource-Bewegung wie die Entscheidung des Unternehmens für Apache. Sie werden ein enormes Echo haben, auch bei Unternehmen, die die plötzliche Begeisterung von Big Blue für GNU/Linux nicht unbedingt teilen. Ein kleines, aber wichtiges Element der IBM-Strategie besteht zum Beispiel darin, seine Unix-Spielart, AIX, um Schnittstellen für GNU/Linux-Kompatibilität zu erweitem; dadurch wird es den Benutzern ermöglicht, Programme zu verwenden, die für GNU/Linux auf den leistungsstarken IBM-Hardwaresystemen geschrieben wurden, die unter AIX laufen. Die GNU/Linux-Plattform wird für die Softwaredistributoren noch attraktiver werden. Sie werden einen größeren Teil ihrer Programme portieren und GNU/Linux dadurch interessanter für die Kunden machen. Im Gegenzug wird die Position von GNU/Linux in der Unix-Welt stärker werden, und die Position anderer, geschützter Unix-Varianten - letzten Endes einschließlich die von AIX - wird sich dadurch schwächen.


--------------------------------------------------------------------------------------SGI, einer der ersten Unterstützer dieses neuen Ansatzes, hat das bereits erkannt. Das Unternehmen setzte seinen ersten Schritt in die OpenSource-Welt nicht mit GNU/Linux, sondern mit Samba; dafür zeichnete in erster Linie die Nummer zwei von Samba, Jeremy Allison, verantwortlich. Er erinnert sich: „Im Grunde sagte SGI: .Wenn ihr zu uns kommt und für uns arbeitet, werden wir Samba zu unserem offiziellen Produkt [für Fileserver] machen.' Das war eine zu gute Chance, als dass wir oder Samba sie sich hätten entgehen lassen können. SGI gab seine Unterstützung am 8. Dezember 1998 bekannt, indem es sich selbst zum .ersten kommerziellen Unix-Distributor' proklamierte, ,der Samba-Software unterstützt'." Die Tatsache, dass SGI Samba übernahm, war ein Triumph für die Welt der freien Software und ließ hoffen, dass andere diesem Schritt folgen würden. Aber auf Allison wartete eine Überraschung, als er in die Firma kam. „Es war komisch", sagte er, „weil ich erwartet hatte, eine OpenSource-Insel in einer Firma zu sein, die nur auf geschützte Produkte setzte. Dabei hatte Linux bei SGI schon alles durcheinander gebracht. Alle kannten es, alle verwendeten es." Allison erklärt, warum der Schritt von SGI, GNU/Linux den Vorzug gegenüber seiner eigenen Unix-Variante Irix zu geben, an diesem Punkt unvermeidlich war. „Das Problem, das sie mit Irix hatten, war, dass nicht genügend Anwendungen dafür geschrieben wurden. Das bedeutete, dass der Anteil von Irix am Unix-Markt zu klein war, als dass die Kosten und Mühen, die das Portieren von Software dafür erfordert hätte, gerechtfertigt gewesen wären. „Wenn du ISV [Independent Software Vendors] dafür bezahlen musst, dass sie für deine Plattform portieren, dann hast du auf lange Sicht keinen überlebensfähigen Markt." Indem SGI das zunehmend populäre GNU/LinuxBetriebssystem übernahm, würde es in der Lage sein, den großen und ständig wachsenden Pool von Applikationen anzuzapfen, ohne den finanziellen Aderlass für spezielle Ports hinzunehmen. SGI gab sein offizielles „Linux-Debut" am 17. Mai 1999 bekannt. Obwohl es zu einem der glühendsten Befürworter von GNU/Linux werden sollte, war es auch in der Zeit, bevor sich IBM im Januar 2000 dem Klub anschloss, keineswegs isoliert in seiner


------------------------------------------------------------------------------------Unterstützung. Hewlett-Packard gab zum Beispiel am 1. März 1999 bekannt, „auf dem HP-UX System Linux-kompatible APIs" anbieten zu wollen. Das bedeutete die Bereitstellung einer Kompatibilitätsschicht, die es den Benutzern des HP-UX-Systems ermöglichen würde, GNU/Linux-Applikationen zu verwenden. Einen ähnlichen Inhalt hatte eine Presseaussendung vom 8. Juni 1999, derzufolge „die Compaq Computer Corporation und Red Hat Software, Inc. heute einen gemeinsamen Entwicklungs- und Marketingvertrag bekannt gegeben haben, der zu einer verbesserten Interoperabilität und Kompatibilität zwischen Compaq Tru64 UNIX und dem Red-HatLinux-Betriebssystem führen wird". Diese Entwicklung wurde am 17. August 1999 durch „eine neue Version von SuSE Linux 6.1 AXP" - die SuSE-Version von GNU/Linux, die auf dem Alpha ACP Chip lief- „mit verbesserten Interoperabilitäts-und Kompatibilitätsfeatures zwischen Compaq Tru64 UNIX und dem SuSE-Betriebssystem" unterstützt. Selbst Sun verspürte die Notwendigkeit, auf das Phänomen zu reagieren, dass sich GNU/Linux als De-facto-Unix-Standard zu etablieren begann. Zuerst versuchte Sun, mit seinem „Free Solaris Program", das im August 1998 herausgekommen war, auf der Preisebene gleichzuziehen, und bot für die nicht kommerzielle Verwendung auf Intel-basierten PCs eine freie Solaris-Lizenz an. Ein dramatischerer Schritt war die Sun-Presseaussendung vom 26. Januar 2000 anlässlich der Veröffentlichung von Version 8 seines Betriebssystems, in der stand, dass „Sun für das Recht, die Laufzeitversion der Software auf Systemen mit acht oder weniger Prozessoren zu verwenden, keine Endbenutzerlizenzgebühr mehr verlangen wird". Darüber hinaus „bietet das Unternehmen zur Förderung von Innovation und Verfügbarkeit den freien Zugang zum Sun-Quellcode". Bruce Weiner, langjähriger Beobachter der UnixSzene, meint dazu: „Wenn es Linux nicht gegeben hätte, hätten sie das nie gemacht." Sun beschränkte sich nicht darauf, GNU/Linux in bestimmten Marktsektoren auf der Preisebene Konkurrenz zu machen, sondern sah sich auch gezwungen, zu einer Einigung mit seinem neuen Hauptrivalen zu gelangen. So gab das Unternehmen am 8. Dezember 1998 bekannt, dass „wir uns mit der Linux-Community


--------------------------------------------------------------------------------------zusammengetan haben, um einen Port der populären Linux-FreewareBetriebsumgebung für die UltraSparc-Architekturen zu vollenden." Der aufgekratzte Ton dieser Presseaussendung - sie behauptete, dass Jede Linux-Kopie ein weiterer Sieg für Unix und offene Standards ist" steht in krassem Widerspruch zur Einstellung von Sun zu Dave Millers erstem Linux-Port für seine Maschinen, an dem er 1994 zu arbeiten begonnen hatte. Bis zu der Presseaussendung 1994, so erinnert sich Miller, erhielt er von Sun keinerlei Unterstützung. „Es war sogar so", berichtet er, „dass ich im Usenet von Sun-Ingenieuren die ganze Zeit öffentlich angegriffen wurde. Ich war damals selbst ziemlich aggressiv, und ich malte mir in den schönsten Farben aus, wie mein Linux auf Spare laufen würde." Er räumt ein, dass er „irgendwie provokant" gewesen war. Wichtiger als die Unterstützung von Sun für den Port für UltraSparc war vielleicht die Presseaussendung vom Dezember 1998, derzufolge das Unternehmen „beabsichtigte, in die Solaris-Umgebung LinuxKompatibilität einzuführen, damit die Konsumenten die neuen LinuxApplikationen in ihrer zuverlässigen Solaris-Umgebung in ihrer ganzen Breite nützen können" - ein subtiler Hinweis auf die Jugend und den relativ ungeprüften Zustand von GNU/Linux. Das Erscheinen dieses Codes, Ixrun genannt, vergrößerte die Reichweite von GNU/Linux abermals; die Softwareuntemehmen hatten nun einen weiteren Grund, für das freie Betriebssystem zu schreiben, und einen weniger, es für die geschützten Unix-Versionen zu tun. Es gibt weitere Anzeichen dafür, dass Sun sich Open Source Schritt für Schritt annähert: die Veröffentlichung des Büropaketes StarOffice, das es im August 1999 erwarb, im Oktober 2000 unter der GNU GPL, und die Einführung von GNOME 2.0 als Standarddesktop für Solaris. Auch wenn die Beziehung von Sun zu GNU/Linux und Open Source nicht friktionsfrei ist, gelang es dem Unternehmen als Hardwarehersteller doch, alternative Modelle der Ertragsgenerierung zu finden, während es sein Grundbetriebssystem Solaris 8 verschenkt. Andere Unternehmen hatten da eine weniger glückliche Hand.


------------------------------------------------------------------------------------Ein Beispiel ist Berkeley Software Design, Inc. (BSDI), das 1991 von den Hauptentwicklem des ursprünglichen Berkeley-Unix gegründet worden war. Am 14. Dezember 1998 gab BSDI bekannt, seine UnixVersion BSD/OS um Linux-Anwendungsunterstützung zu erweitem. Aber dieser Schritt, der den Kunden die Möglichkeit gab, GNU/LinuxApplikationen zu verwenden, verringerte trotz aller Stärken von BSD/OS den Anreiz, es dafür zu portieren. Die Ankündigung vom 10. März 2000, dass BSDI mit Walnut Creek CDROM, dem Distributor und Sponsor des populären FreeBSD Betriebssystems (das ebenfalls im Berkeley-Unix wurzelt), fusionieren würde, ist ein Zeichen dafür, dass BSD/OS die Auswirkungen von GNU/Linux zu spüren bekommt. Dieser Schritt ermöglicht es BSD/OS, sich die Begeisterung und Kreativität der geschickten und engagierten FreeBSD-Hacker zunutze zu machen und einen formelleren Support für FreeBSD anzubieten. Die Situation des anderen großen Distributors, der sich ausschließlich auf Unix konzentriert, SCO, war problematischer - und mit einer gewissen Ironie behaftet. Anfang der achtziger Jahre brillierte SCO fast in demselben Bereich, in dem GNU/Linux in den neunziger Jahren brillieren sollte: Unix auf Intel-Prozessoren. Der Stern von SCO erreichte 1995 den Zenit, als das Unternehmen UnixWare von Novell kaufte, das es seinerseits 1993 von ATEtT gekauft hatte. Durch den Erwerb der Rechte an Thompsons und Ritchies ursprünglichem Unix aus dem Jahr 1969 wurde SCO effektiv zur Hüterin der heiligen UnixFlamme. Aber Hacker kennen keine Gnade und kaum Mitleid, wenn es um Technologie geht; für sie waren die SCO-Produkte alte geschützte Versionen von etwas, was seinen Höhepunkt in GNU/Linux finden sollte. SCO versuchte sich zu wehren. Es hatte „Studenten, Lehrenden und Unix-Fans" einige Jahre lang freie Kopien seiner neuesten Software zur Verfügung gestellt, aber nur als Binärcode. Dann, am 12. Mai 1998, bot es kostengünstige Lizenzen für eine „alte" Unix-Version mitsamt dem Quellcode an. Aber trotz dieser Schritte setzte GNU/Linux seinen Siegeszug in die Herzen der Hacker und auf die Desktops der Unternehmen fort. Gemeinsam mit anderen Distributoren geschützter Unix-Varianten ergab sich SCO dem Unvermeidlichen und gab am 2. März 1999 „seine seit langem bestehende


--------------------------------------------------------------------------------------Unterstützung für Linux und die Open-Source-Bewegung bekannt, indem wir für unsere preisgekrönte UnixWare7-Plattform LinuxAnwendungsunterstützung anbieten." Amüsant ist die Überschrift der Presseaussendung: „Linux- und OpenSource-Bewegung rücken von Festlegung auf Einzeldistributoren ab und stellen Unix-Systeminnovation wieder in den Vordergrund. Die Versuche der Unix-Distributoren in den vergangenen Jahrzehnten, die Kunden auf ihr Produkt festzulegen, hatten zu einer so starken Zersplitterung der Unix-Welt geführt, dass sie dem Ansturm von Microsoft Windows NT machtlos ausgeliefert war. Die endgültige Demütigung der alten Garde kam am 2. August 2000, als SCO den Verkauf von zwei seiner drei Divisionen -einschließlich des ursprünglichen Unix - an Caldera bekannt gab. Die Hacker hatten über das Establishment triumphiert. Wie zögernd die Schritte der Distributoren der geschützten UnixVersionen, die Open-Source-Versionen anzuerkennen und dann mit ihnen zu arbeiten, auch waren, hatten sie doch ein eindeutiges Ergebnis: Es steht fest, dass GNU/Linux irgendwann zum De-facto-Unix-Standard werden wird. Viele sagen, dass es das bereits ist. Darüber hinaus bedeuten die ambitionierten Schritte von IBM, GNU/Linux zum universellen Programmierstandard innerhalb des Unternehmens zu machen, dass das Betriebssystem auch für High-End-Computing, insbesondere für Supercomputer, eingesetzt werden wird. Auf diese Weise wird GNU/Linux Windows 2000 den Zugang zu diesen Bereichen erschweren, indem es von unten angreift: Diese Zangenbewegung wird für Microsoft zunehmend unangenehm werden. Angesichts dieser schwer wiegenden Veränderungen in der Welt des Unix-Marktes könnte der Eindruck entstehen, dass die PC-Firma Apple relativ sicher ist. Schließlich ist die GNU/Linux-PIattform auf dem Gebiet der Endbenutzersoftware noch unausgereift und außerdem eng mit der Intel-Familie verbunden - jedenfalls historisch und emotional. Apple hingegen ist im Wesentlichen eine Desktop-Firma, die auf der Architektur des PowerPC-Chip aufhaut. Es gibt zwar Ports für GNU/Linux für den PowerPC; einer von ihnen, Mk-Linux genannt, wurde von Apple sogar gefördert. Aber es ist weniger


------------------------------------------------------------------------------------dieser direkte, nicht so ernst zu nehmende Rivale, der Apple bedroht, als das gesamte GNU/Linux-Phänomen. Die Beziehung zwischen Apple und GNU/Linux war seit jeher problematisch, weil der ursprüngliche Apple Macintosh im Gegensatz zum offenen IBM-PC bewusst als geschlossene Maschine konzipiert war. Er sollte ein Gerät sein, über dessen innere Funktionsweise die Benutzer nichts zu wissen brauchten. Das war zwar ein logischer Ansatz für den Markt, für den die Maschine gedacht war, aber es war klar, dass er den Intentionen der Hacker widersprach. Der erste Port des Apple Macintosh wurde aus reiner Blutrünstigkeit entwickelt. Einer seiner Hauptcodierer war Alan Cox, der über die Arbeit sagt, dass „das Schöne an ihr war, dass sie einerseits vollkommen nutzlos und anderseits sehr anspruchsvoll war". Als er später über die Erfahrung schrieb, dankte er den verschiedenen Leuten, die ihn in diesem kolossalen Unterfangen unterstützt hatten, hängte aber ein „Nein, danke" an „Steve Jobs an - dafür, dass du uns jede [Macintosh]-Information vorenthalten hast". Angesichts dieser Ausgangssituation und der auch später nur lauwarmen Begeisterung für die Bemühungen, GNU/Linux für jüngere MacintoshHardware zu portieren, war die Presseaussendung von Apple vom 16. März 1999 über die Einführung von Darwin, der Grundlage seines neuen Mac OS X Server Betriebssystems, als Open-Source-Produkt ein wichtiger Schritt. Mit Elementen des Berkeley-Unix und Mikrokerneltechnologien der Art, wie Andrew Tanenbaum (der Urheber von Minix) sie bevorzugte, ist Darwin ein enger Verwandter von GNU/Linux. Obwohl die Tatsache, dass Apple diesen Schritt tat und in der Folge weiteren Code als Open-Source-Code veröffentlichte, wahrscheinlich dazu beitragen wird, dass „Apple und seine Kunden von dem Erfindungsgeist und der Begeisterung einer riesigen Programmierergemeinde profitieren werden", wie es in der ursprünglichen Presseaussendung vom März hoffnungsfroh hieß, wird ein grundlegenderes Problem des Unternehmens dadurch nicht in Angriff genommen. Dieses Problem war bereits in einem vorausblickenden Essay mit dem Titel „Ein bescheidener Vorschlag", den Don Yacktman 1998


--------------------------------------------------------------------------------------geschrieben hatte, angesprochen worden. Er merkte an: „Das Maß an ,ernsthafter' Entwicklung jetzt oder früher ist beschränkt. Von der vorhandenen Entwicklung entfällt nur ein sehr kleiner Anteil auf NichtWindows-Betriebssysteme. Wenn die Unterstützung für Mac OS durch Dritte ins Trudeln geriete, könnte die Zukunft von Apple ernsthaft gefährdet sein" - unabhängig davon, ob das Unternehmen für sein Betriebssystem Open-Source-Entwicklungstechniken verwendet oder nicht. Weniger neue Anwendungen bedeuten weniger Benutzer. SGI ist sich dessen bewusst, weshalb es seinen Schwerpunkt von Irix auf GNU/Linux verlagerte. Wie Yacktman richtig bemerkte, könnte Apple dasselbe passieren, wenn es GNU/Linux gelingen sollte, sich als Desktopsystem zu etablieren. Die Grundlagen für eine solche Etablierung wurden durch die Entwicklung der KDE- und GNOME-Umgebungen geschaffen. Einer der ersten Distributoren, die Nutzen daraus zogen, war die kanadische Firma Corel, die ihre bekannten Windows-Programme mithilfe eines innovativen Ansatzes portierte, der auf Technologie des Open-SourceProdukts Wine basierte. Der Gründer von Corel, Michael Cowpland, beschreibt GNU/Linux als „Hebel, mit dem die Einzeldistributorsituation endlich aufgestemmt werden konnte", indem die Vorherrschaft von Microsoft auf dem Desktop gebrochen wurde. Diese Ansicht lässt die I35-Millionen-US-Dollar-Investition von Microsoft in Corel im Rahmen einer „strategischen Allianz", die am 2. Oktober 2000 bekannt gegeben wurde, zumindest interessant erscheinen. Aber diese „Einzeldistributorsituation" ist in wenigen Sektoren des Computermarktes üblich, wo die Aussichten für GNU/Linux ähnlich rosig sind. So floriert GNU/Linux zum Beispiel bereits im Bereich der Server Appliance, wo es darum geht, kostengünstige Systeme mit Minimalkonfiguration und geringen Wartungserfordernissen zusammenzustellen. GNU/Linux ist dafür ideal geeignet. Außerdem kann es mit anderer robuster und freier Software wie Apache, Sendmail oder Samba kombiniert werden, um spezielle Boxen für die Durchführung allgemeiner Aufgaben wie Webserving, E-Mail, Filesharing und Ähnliches zu schaffen.Eines der führenden Unternehmen in diesem Bereich und mit Sicherheit eines der etabliertesten ist Cobalt Networks. Die Firma


------------------------------------------------------------------------------------wurde 1996 gegründet und zählte einst Larry McVoy und Dave Miller zu ihren Mitarbeitern. Der GNOME-Hacker Miguel de Icaza wäre fast in das Unternehmen eingetreten, bekam aber das dazu notwendige USVisum nicht. Im Oktober 1999 gab Cobalt einen Vertrag über die Belieferung von Gateway mit Server Appliance Technologie bekannt den ersten zaghaften Schritt des Computerherstellers in die Welt von Open Source. Ein paar Monate nachdem Gateway sein Micro Server System präsentiert hatte, setzte sein Erzrivale Dell mit seiner PowerApp-Linie einen vergleichbaren Schritt. Auch Sun drang mit dem Kauf von Cobalt Networks für Sun-Aktien im Wert von zwei Milliarden US-Dollar in diesen Sektor ein. Die begleitende Presseaussendung war deshalb bemerkenswert, weil sie die Tatsache unter den Tisch fallen ließ, dass die Cobalt-Systeme unter GNU/Linux liefen - wieder ein Beweis für die Ambivalenz von Sun gegenüber seinem Betriebssystemrivalen. Aber GNU/Linux bietet nicht nur für das High End des Gerätemarkts die perfekte Lösung, sondern seine Qualitäten wie Kostengünstigkeit, straffe Codierung und bewährte Zuverlässigkeit machen es auch ideal für kleinere Geräte, die je nach ihrer Funktion die verschiedensten Namen tragen. Ein bekanntes Gerät ist Net Appliance. In diesem Sektor konkurrieren viele Marktteilnehmer, aber keiner ist so wichtig wie der führende Onlinedienst AOL, der Anfang 2001 über 25 Millionen Mitglieder hatte. Am 5. April 2000 kündigte AOL eine „neue Familie spezialisierter Internetgeräte" an. Diese Geräte basieren auf dem Crusoe-Chip von Transmeta und verwenden das Mobile Linux dieses Unternehmens, an dessen Zusammenstellung Linus selbst beteiligt war. Sie setzen auch die Gecko-Layoutmaschine von Netscape für die Browserfähigkeiten ein. In gewissem Sinn repräsentieren die Internetgeräte von AOL die erste Post-PC- und Post-MicrosoftArchitektur: kein Intel, kein Windows und kein Internet Explorer. Flexibilität ist eine der größten Stärken von GNU/Linux; die Tatsache, dass das Betriebssystem unter den verschiedensten Umständen angewendet werden kann, zeigt sich an der breiten Palette innovativer Geräte, in denen es eingesetzt wird. So verwendet TiVo GNU/Linux für seinen digitalen TV-Rekorder. Kerbango Radio und


--------------------------------------------------------------------------------------PenguinRadio, zwei Internetgeräte, die es den Benutzem gestatten, Audiostreams aus der ganzen Welt zu empfangen, basieren beide auf GNU/Linux. Dasselbe tut auch ein neues Heimkommunikationsgerät des schwedischen Herstellers Ericsson. Das Screen Phone basiert auf Red Hat Linux mit einer grafischen Schnittstelle von Trolltech, die auf einem Farb-Touchscreen angezeigt wird und in einem schnurlosen Gerät Telefonie, E-Mail und Webbrowserdienste vereint. Laut Ericsson ist das Screen Phone das erste „einer neuen Reihe von Konsumentenprodukten und Heimkommunikationsdiensten", die gemeinsam mit Red Hat entwickelt werden. Diese Systeme zeichnen sich dadurch aus, dass von den Benutzern nicht erwartet wird, dass sie sie so oft konfigurieren oder upgraden wie ihre PCs. Gleich um welche Geräte es sich handelt -Internetradios oder erweiterte Kommunikationsgeräte -, sie werden einfach eingeschaltet und verwendet. Der Markt der so genannten eingebetteten Geräte umfasst alles, was kein Computer im konventionellen Sinn ist, aber auf Computerchips basiert. Auch wenn dieser Sektor weniger auffallend ist, ist er viel größer als der Computermarkt, und viele meinen, dass GNU/Linux hier entsprechend größere Chancen hat. Ein Unternehmen, das sich dieser Ansicht anschließt, ist Lineo. Im Juli 1999 hervorgegangen aus Caldera, verdankt es seine Existenz der Nachfrage der Kunden. Wie Bryan Sparks, ehemaliger CEO von Caldera und nun Chef von Lineo, sagt: „Wir führten einige individuelle Projekte für Kunden durch, indem wir GNU/Linux für embedded Systems bereitstellten. Im April [1999] sagten wir dann: ,Wisst ihr was, es ist Zeit für etwas anderes - konzentrieren wir uns einfach auf das." Eine der großen Stärken von GNU/Linux in diesem Sektor ist seine Eignung für alle Arten eingebetteter Geräte. Es ist auch „besser, schneller und billiger" als die geschützten Konkurrenzprodukte. Lineo baute bewusst auf diesen Eigenschaften auf, indem es frühzeitig andere Firmen kaufte, die an GNU/Linux für eingebettete Systeme arbeiteten. „Wir mussten schnell wachsen", meint Sparks, „schon was die Mitarbeiterzahl anbelangte. Dabei wurde uns klar, dass wir auch strategische Lücken hatten, die wir schließen mussten. Wenn Sie also ein Kunde sind, der irgendetwas mit


------------------------------------------------------------------------------------eingebettetem Linux oder eingebetteten Geräten macht und Linux evaluiert, können wir das ganze Spektrum von ganz ganz winzigen Geräten bis zum High End abdecken." Das Geschäftsmodell von Lineo unterscheidet sich von den Modellen anderer GNU/Linux-Unternehmen, die großteils meinen, angesichts eines Produkts, das im Wesentlichen frei ist, mit Dienstleistungen Geld verdienen zu können. „Wir sind in erster Linie ein Produktunternehmen", sagt Sparks. „Natürlich bieten wir auch Dienstleistungen, aber nur, soweit sie sich auf den Produktverkauf beziehen." Eines dieser Unternehmen im Markt der eingebetteten Produkte, das sein Geschäft nicht auf Produkte, sondern auf Dienstleistungen stützt, ist Red Hat. Bedingt durch die Übernahme von Cygnus im November 1999 konkurriert es heute nicht nur mit seinem alten Rivalen Caldera, sondern auch mit Lineo. Cygnus war auf dem Markt der eingebetteten Produkte schon zu einer Zeit aktiv, als Linux noch gar nicht existierte. Nachdem es seine Programmiertools für die verschiedenen eingebetteten Chips portiert hatte, bestand der nächste logische Schritt in der Entwicklung eines Betriebssystems für diesen Sektor. Aber anstatt GNU/ Linux zu verwenden, wie zu erwarten gewesen war, präsentierte Cygnus seine eigene Lösung namens eCos, die im September 1998 als Open Source herausgebracht wurde. eCos basierte nicht auf Linux, aber das nächste Cygnus-Projekt im Bereich der eingebetteten Produkte, EL/IX, tat das sehr wohl, wenn auch mit einer Einschränkung. Im September 1999 präsentierte das Unternehmen nicht nur ein weiteres eingebettetes GNU/Linux, von denen es inzwischen schon viele gab, sondern eine Methode für Konkurrenzprodukte, die ihnen die Aufrechterhaltung der Kompatibilität untereinander ermöglichen sollte. Die Presseaussendung nannte EL/IX „einen wichtigen Schritt zur Verhinderung der Fragmentierung des eingebetteten Linux". Das klingt im Prinzip gut, aber einige Leute wie Sparks von Lineo, haben da ihre Zweifel. „Wir glauben, dass das Unsinn ist", sagt er. „Es gibt überhaupt keine Technologie, es gibt nur Marketingtricks." Trotz seiner Verachtung für EL/IX hat Sparks viel Respekt für Cygnus/Red Hat im Bereich der eingebetteten Produkte


--------------------------------------------------------------------------------------übrig. Zumindest, so sagt er, „betrachten wir sie als Konkurrenten in den Dingen, die sie früher konnten." Die Gefahr der Zersplitterung innerhalb des Bereichs der eingebetteten Produkte ist wahrscheinlich geringer als für die Bereiche Server oder Desktops. Ihrer Natur nach sind eingebettete Geräte für bestimmte Aufgaben gedacht und werden normalerweise mit individuell abgestimmter Software betrieben. Deshalb ist die präzise Kompatibilität zwischen den vielen existierenden Plattformen weniger wichtig als zum Beispiel bei Servern. Es gibt noch eine weitere interessante Folge dieser zersplitterten Natur des Sektors der eingebetteten Geräte. Der Linux-Kernel floriert und wächst, weil so viele Hacker den Code ausprobieren, Bugs aufspüren und Vorschläge machen können. Da eingebettete Systeme spezialisiert sind, ist es unwahrscheinlich, dass viele Hacker mit dem für sie geschriebenen Code herumspielen werden; das bedeutet, dass die klassische Open-Source-Entwicklungsmethode im Bereich der eingebetteten Produkte und in anderen Sektoren, in denen sich nur wenige Leute den Code ansehen, wie in spezialisierten Nischenmärkten, wenig zu bieten hat. Ungeachtet der Unterschiede in ihrer Philosophie sind sich Bryan Sparks und Michael Tiemann, Mitbegründer von Cygnus und inzwischen zum CTO von Red Hat aufgestiegen, über etwas einig: „Ich bin davon überzeugt, dass die Internetgeräte in Wirklichkeit die große Sache sind. Dem PC wird es ergehen wie dem universellen Motor." Sparks fügt hinzu: „Wir glauben, dass die nächste Linux-Welle eingebettete Produkte sein werden, und umgekehrt glauben wir, dass die nächste Welle bei eingebetteten Produkten Linux sein wird." Ein paar berühmte Namen schließen sich dieser Ansicht an. Im Mai 2000 erhielt Lineo 37 Millionen US-Dollar von Mitsubishi, Motorola und Samsung; im September investierte Motorola weitere 22,5 Millionen US-Dollar, während Samsung und Lineo in Korea mit der gemeinsamen Entwicklung eingebetteter Systeme begannen. Anfang 2000 erhielt Lynx Real-Time Systems, ein weiterer Hersteller eingebetteter Systeme, Investitionen von Intel, Motorola und TurboLinux. Lynx brachte im Februar 2000 sein eingebettetes LinuxProdukt BlueCat auf den Markt und änderte den Namen im


------------------------------------------------------------------------------------Mai auf LinuxWorks, um zu zeigen, „dass wir uns jetzt darauf konzentrieren, die Vorteile von Linux in den Markt der eingebetteten Produkte zu tragen", wie es in der Presseaussendung hieß. Das starke Bekenntnis von Motorola zu GNU/Linux im Bereich der eingebetteten Produkte wurde nicht nur durch die Beteiligung an den oben erwähnten Investitionen signalisiert, sondern auch durch eine Presseaussendung im März 2000, der zufolge das Unternehmen eine eigene Distribution für die Telekommunikationsindustrie namens High Availability Linux auf den Markt bringen würde. Wie es in der Presseaussendung hieß, ist dieses Produkt für „Networking auf CarrierEbene, Drahtlos- und Intemetapplikationen gedacht, die eine Verfügbarkeit von 99,999 Prozent erfordern." Diese „Fünf-Neuner"-Verfügbarkeit entspricht weniger als fünf Minuten Ausfallszeit pro Jahr. Der vielleicht endgültige Beweis für die außergewöhnliche Zuverlässigkeit des Open-Source-Betriebssystems besteht in der Tatsache, dass Motorola, das 1999 einen Umsatz von über 30 Milliarden US-Dollar erreichte, GNU/Linux wählte, um diese extrem hohe Verfügbarkeit bieten zu können. Gemeinsam mit der Ankündigung von IBM im Januar 2000 ist dies eines der stärksten Unterstützungsbekenntnisse eines Technologieunternehmens mit makellosem Ruf. Der Sektor der eingebetteten Produkte könnte GNU/Linux durchaus eine größere Chance bieten als der Server-and-Client-Markt. Viele sind jedoch davon überzeugt, dass sich die Open-Source-Philosophie noch weiter ausbreiten wird - über die Computerwelt hinaus. Eine logische Anwendung der für Open Source typischen Entwicklungsmethode besteht zum Beispiel im Erstellen von Content anstatt im Codieren. Neben der GNU General Public License zielt die GNU Free Documentation License (FDL) darauf ab, die Weitergabe von Dokumenten so zu fördern, wie es die GNU GPL im Softwarebereich tut. Aber wo die GNU GPL in ihrem Bereich als führende Lizenz etabliert ist, ist die GNU FDL einer stärkeren Konkurrenz ausgesetzt: zum Beispiel der Open Publication License des Open-Content-Projekts oder der IDG Open Content License des Open-Book-Projekts.


--------------------------------------------------------------------------------------Obwohl die Content-Lizenzierung noch in den Kinderschuhen steckt, floriert die Zusammenarbeit im Contentbereich. Das Open Directory erstellt zum Beispiel eine Klassifikation des Internet-Contents im Yahoo!-Stil durch Freiwillige anstatt durch bezahlte Forscher. Der Vorteil dieses Ansatzes besteht wie bei der Open-Source-Softwareentwicklung in der Skalierbarkeit. Ende 2000 waren im Open Directory über 30.000 Beitragende verzeichnet, die zwei Millionen Websites in 300.000 Kategorien für eine frei verfügbare Datenbank auswählten und organisierten. Ursprünglich GnuHoo und NewHoo genannt, wurde das Open Directory im November 1998 von Netscape gekauft und auf dessen Portal verwendet. Seit damals wurde die Open-DirectoryDatenbank von mehreren anderen bekannten Sites, darunter Lycos, Google und HotBot übernommen und verdrängte in manchen Fällen geschützten Content. Auch im offenen Journalismus wird die Open-Source-Methode mit großem Erfolg angewendet. Am besten ist das an der Slashdot.org Website zu erkennen, die im September 1997 von Rob „CmdrTaco" Malda entwickelt wurde und deren Motto „News for nerds. Stuff that matters" lautet. Das „Zeug, das zählt", ist im Wesentlichen freie Software; es werden aber auch eine Reihe verwandter Themen angeboten. Das wichtigste Merkmal der Site besteht darin, dass sie weniger Neuigkeiten für Computerfreaks als Neuigkeiten von Computerfreaks anbietet: Der Großteil des Materials wird von Lesern eingesendet, und die Geschichten, die jeden Tag auf der Site erscheinen, werden aus den Einsendungen ausgewählt. Die Besucher können ihre Kommentare posten und weitere Informationen beisteuern. Die Analogie mit dem ständigen Feilen am Linux-Kernel durch die sukzessive Verwendung von Patches, die von den Hackern rund um die Welt eingesendet werden, ist eindeutig. Der „Slashdot-Effekt" - die Besucherüberschwemmung einer Website, nachdem sie in einer Story erwähnt wurde - ist inzwischen berühmt. Wichtiger aber ist ein anderer Slashdot-Effekt. Der Ausdruck bezieht sich auf eine leistungsstarke Maschine zur verteilten Sammlung und Filterung von Nachrichten, die unabhängig von den normalen Medienuntemehmen ist (Slashdot gehört heute VA Linux). Slashdot ist ein bekanntes Beispiel, wie die Open-


------------------------------------------------------------------------------------Source-Philosophie die traditionellen Informationsstrukturen verändert, insbesondere die wirtschaftlichen und rechtlichen Strukturen, und wie sie sich verbreitet. Aber manche glauben, dass Open-Source-Software möglicherweise einen ebenso großen Einfluss auf die Neuordnung der Landschaft der geistigen Eigentumsrechte haben wird wie auf den offenen Journalismus. Einer dieser Leute ist Professor Eben Moglen, Professor für Rechtsgeschichte an der Columbia University und Rechtsberater der Free Software Foundation. Er behauptet, dass das gegenwärtige überlappende Rechtssystem von Patenten, Urheberrechten und Geschäftsgeheimnissen mit der Zeit unbrauchbar werden wird. Moglen meint, dass es in der Rechtsgeschichte Präzedenzfälle gibt, die darauf schließen lassen, dass eine solche instabile Situation nicht haltbar ist. Kontroversieller ist seine Überzeugung, dass freie Software wie GNU/Linux ein wichtiger Katalysator für den endgültigen Zusammenbruch dieser miteinander im Konflikt stehenden Systeme sein wird: „Worauf wir zusteuern, ist der große Krieg um freie Software", lautet seine Prognose. Stellen wir uns das Internet zur Abwechslung einmal nicht als Ding oder als Raum vor, sondern als eine Ansammlung von Leitungen und Schaltern. Durch diese Leitungen fließen jede Menge Daten, und die Schalter bestimmen, wer welche Daten bekommen wird und wie viel die einzelnen Teilnehmer für ihre Weiterleitung bezahlen müssen. Diese Schalter sind natürlich im Großen und Ganzen das, was wir uns unter digitalen Computern vorstellen. Die grundlegende Theorie über Medienunternehmen zu Beginn des einundzwanzigsten Jahrhunderts lautet, eine lecksichere Leitung vom Produktionsstudio zu Auge und Ohr herzustellen. Der Schalter, der für diese Leitung am gefährlichsten ist, ist ein am Ende positionierter. Wenn der Schalter, der Auge und Ohr am nächsten ist, unter der vollständigen technischen Kontrolle des Teilnehmers steht, kann der Rest des Aquädukts so lecksicher sein, wie er nur will, es wird nichts helfen. Und der Schalter steht natürlich dann unter Ihrer Kontrolle, wenn die Software freie Software ist.


--------------------------------------------------------------------------------------Dass das nicht nur die interessanten, aber rein theoretischen Überlegungen eines Wissenschaftlers sind, der zu viel Zeit mit dem Herumspielen an GNU-Software und dem Lesen der GNU GPL zugebracht hat, zeigt sich anhand von zwei Open Source-Programmen, die das Content Scramble System (CSS), das für das Blockieren unautorisierter Einsichtnahmen in DVD verwendet wird, umgehen. Da die GNU/Linux-Plattform keine unterstützte Plattform war, konnte man mithilfe dieses Systems keine DVDs ansehen. Die Hacker starteten LiViD, das Linux Video und DVD Project, auf die übliche Weise, um Code zu erzeugen, mit dem sie die DVDs auf ihrem Computer ansehen konnten. Obwohl es keine Beweise dafür gibt, betrachtet die Filmindustrie die Software, die aus dem Projekt heraus entstand, als Versuch, das Verschlüsselungssystem zu Pirateriezwecken zu umgehen. Für die Hacker repräsentiert es die Freiheit, ihre DVDs unter GNU/Linux ansehen zu können. Dieser Fall ist besonders interessant, weil DVD-Software sowohl für GNU/Linux als auch für Windows (jeweils css-auth und DeCSS genannt) unter der GNU GPL herausgebracht wurde. Als solche kann es auf der ganzen Welt kopiert werden, und das wird es auch. Das bringt die Filmindustrie in eine schwierige Lage. Wie Moglen meint: „Nun müssen sie zu irgendeinem Gericht gehen und sagen: .Gebt uns eine Verfügung, damit wir die ganze Welt davon abhalten können, darüber zu reden.' Das wird nicht funktionieren, weil die Gerichte ... sehen werden, dass das unmöglich ist. Sie werden erkennen, dass damit nichts erreicht werden kann und dass es eine Zumutung ist, zu etwas aufgefordert zu werden, was sie unmöglich bewerkstelligen können." Obwohl die US-Filmindustrie diese Software zu fürchten scheint, verblassen ihre potenziellen Auswirkungen auf die Landschaft der geistigen Eigentumsrechte neben zwei anderen Open-Source-Projekten. Diese Programme namens Gnutella - eine Kombination aus „GNU" und „Nutella", dem italienischen Haselnuss-Schokololade-Aufstrich - und Freenet ermöglichen es, Dateien zu finden, die irgendwo in einer Gruppe von internetverbundenen Computern verteilt sein können, auf denen die Gnutella- oder Freenet-Software läuft.


------------------------------------------------------------------------------------Das wichtigste Merkmal von beiden besteht darin, dass der Speicherort dieser Dateien in keinem zentralen Verzeichnis aufgelistet ist, wie es bei dem bekannteren Filesharingsystem von Napster der Fall ist. Wenn das Element gefunden ist, wird es an den Urheber der Anforderung geschickt. Die Tatsache, dass kein zentraler Knoten vorhanden ist, bedeutet, dass es extrem schwer ist herauszufinden, wo die Datei im Gnutella-Netzwerk gespeichert ist. Freenet ist speziell dafür ausgelegt, das zu ermöglichen und dabei die Anonymität des Urhebers der Anfrage zu wahren. Die Art und Weise, wie diese neuen Programme alle Versuche zunichte machen, die Urheberrechtsverletzung zu verhindern, ist besonders interessant. Sowohl Gnutella als auch Freenet liegen als eine Art virtuelles Netzwerk über dem derzeitigen Internet; dadurch werden alle Verbindungen zwischen den Dateien und ihren physischen Speicherorten getrennt. Der Content ist nur „im" Netzwerk; das „Wo" ist für den Benutzer ohne Bedeutung. Es scheint logisch zu sein, dass die verteilte Entwicklungsmethode, die als Open Source bekannt und aus dem Internet geboren wurde und größtenteils für seinen Betrieb sorgt, auch zu seiner Neuerfindung in einer noch reineren und stärkeren Form führen wird.

18

Jenseits des Marktes

OB DIE VIELEN FASZINIERENDEN MÖGLICHKEITEN, die sich zurzeit auftun, genutzt werden können, hängt in entscheidendem Maß vom weiteren Erfolg von GNU/Linux und Open Source ab. Viele Skeptiker und Konkurrenten sehen jedenfalls eine Vielzahl von Gründen, warum die Revolution der freien Software ihrer Meinung nach ins Stocken geraten und letzten Endes scheitern wird. Laut diesen Schwarzsehern ist die Zersplitterung das größte Übel, von dem die Open-Source-Welt heimgesucht werden wird. Vor allem die kommerziellen Distributionen von GNU/Linux, so erklären sie, sind nichts anderes als Unix-Varianten - und jeder weiß, was deren Schicksal war. Dazu kommt, dass die Gabelungsmöglichkeit eines der in GNU/Linux inhärent eingebauten Schlüsselmerkmale ist. Die Pessimisten könnten mit einiger Berechtigung sagen, dass die Gabelung in der Welt der freien Software nicht so sehr ein Risiko als ein regelrechtes Recht ist.


------------------------------------------------------------------------------------In diesem Zusammenhang könnten Kritiker auf die XEmacs-Geschichte verweisen, die in Kapitel 10 behandelt wurde. Diese Geschichte zeigt, dass ernsthafte Gabelungen in der Welt der freien Software nicht nur vorkommen, sondern dass es Gabelungen gibt, die bis auf den heutigen Tag nicht geheilt werden konnten. Was diesen Kritikern aber entgeht, ist die Tatsache, dass die XEmacs-Gabelung im Bereich der Applikationen auftrat und dem Wunsch einiger Benutzer nach einem Alternativansatz entsprang. Obwohl es stimmt, dass die Spaltung zwischen Emacs und XEmacs dazu führt, dass beiden Zweigen weniger Aufmerksamkeit von Entwicklerseite zuteil wird, zieht dieser Schaden keine weiteren Kreise: Es gibt keine anderen Programme, die in entscheidender Weise davon abhängen, eine Emacs-Version zu haben. Die Gabelung erweitert die Wahlmöglichkeiten der Benutzer, ohne einen der Zweige zu schwächen. Eine Gabelung von GNU/Linux wäre etwas anderes. Sie würde nicht nur die Entwicklungsaktivitäten spalten, sondern der gesamten GNU/Linux -Plattform einen irreparablen Schaden zufügen, weil Benutzer und Anwendungsentwickler dann wählen müssten, welchen Zweig sie unterstützen würden. Die Inkompatibilitäten zwischen den GNU/Linux-Zweigen würden zu einer allgemeinen Verkleinerung der Benutzerbasis jedes Zweigs fuhren, und die Folge wären schwächere, ärmere Systeme für alle. Deshalb existiert ein enormer Druck zur Vermeidung einer Gabelung auf Betriebssystemebene. Ein Benutzer, der sich für die Unterstützung eines kleineren Zweigs entscheiden würde, liefe Gefahr, auf viele Vorteile künftiger GNU/LinuxApplikationen verzichten zu müssen, und das würde die abtrünnigen Versionen weiterhin schwächen. Es ist immer noch vorstellbar, dass solche Gabelungen erfolgreich sein könnten, wenn sie zum Beispiel ein wichtiges, aber bisher unbefriedigtes Bedürfnis abdeckten. In diesem Fall wäre es aber möglich, dass der Haupt-GNU/Linux-Zweig einen Teil oder alle der von der Abspaltung hinzugefügten Innovation übernehmen und sie wieder in die Hauptentwicklungslinie integrieren würde, um dieses Bedürfnis abzudecken. Die GNU GPL garantiert nicht nur das Recht auf eine Gabelung, sondern sieht auch einen eingebauten Mechanismus für ihre Heilung vor.

18. Jenseits des Marktes

--------------------------------------------------------------------------------------Andere argumentieren, dass das Risiko für freie Software nicht in einer Zersplitterung, sondern im Gegenteil in einer Konzentration besteht vielleicht weil sie erkannt haben, dass das Gabelungsargument entscheidende Schwächen aufweist. So erkennen viele in Red Hat, dem führenden Open-Source-Unternehmen, ein neues Microsoft, das eines Tages bereit sein könnte, die Interessen der Benutzer auf dem Altar des Profits zu opfern. Es ist unbestreitbar, dass der Beginn der kommerziellen Nutzung die Dynamik des Open-Source-Entwicklungsprozesses verlangsamt. Vor allem bringt er seine eigenen Prioritäten mit sich, die im Widerspruch zu denen der Hacker stehen können. Trotzdem gibt es eine Episode in der Geschichte der freien Software, die zeigt, was unter diesen Umständen passiert - und wer das Urteil fällt. Cygnus Solutions, das in Kapitel 14 vorgestellt wurde, hatte sein Geschäft rund um die Entwicklung neuer GCC-Ports und ihre Übergabe an die Allgemeinheit als Open Source aufgebaut. Wie der Mitbegründer von Cygnus, Michael Tiemann, dazu erklärt: „Im Grunde hing unser Geschäft von unserer Fähigkeit ab, neue Mikroprozessordistributoren auf die GNUPro-PIattform zu bringen. „Aber 1997 entstand ein Problem: .Immer mehr unserer Ports des Compilers und der Compilerverbesserungen blieben im Prozess der Patchüberprüfung stecken', sagt er. Das bedeutete, dass die Arbeit von Cygnus nicht schnell genug in die offizielle GCC-Distribution integriert werden konnte. Die Folge war, so Tiemann, „dass der FSF-Prozess begann, zu einer Belastung für unser Geschäft zu werden." Tiemann bringt in diesem Zusammenhang ein interessantes Argument vor: „Die technische Gemeinde bringt manchmal mehr Geduld und Toleranz auf als die Unternehmensseite. Wenn ein Projekt feststeckt", so sagt er, „kann ein unternehmungslustiger junger Hacker hingehen und an einem anderen Projekt zu arbeiten beginnen. Aber wenn man zehn Millionen US-Dollar Umsatz im Jahr macht und dazu noch eine 50-prozentige Wachstumsrate hat, die man aufrechterhalten muss, sind solche Verzögerungen bei den Patches inakzeptabel." Das war also ein entscheidendes Exempel dafür, was passiert, wenn die Geschäftswelt mit dem Entwicklungsprozess kollidiert.


------------------------------------------------------------------------------------Die Lösung von Cygnus war einigermaßen extrem: Das Unternehmen entschied sich für eine Gabelung des GCC-Codes. Mit seinem neuen EGCS (Experimental GNU Compiler System, ausgesprochen „eggs") konnte es alle Änderungen integrieren, die es für seine Produkte brauchte. Aber in Wahrheit handelte es sich um eine „Entführung" des GCC-Standards. „Wir versuchten es so zu machen, dass es eventuell wieder geeint werden konnte, aber wir vertraten unseren Führungsanspruch nachdrücklich", sagt Tiemann. „Sehr befriedigend war, dass im Grunde die gesamte Internetgemeinde hinter uns stand." Dieser letzte Punkt ist entscheidend. Hätte Cygnus sich darauf beschränkt, EGCS für seine eigenen geschäftlichen Erfordernisse zu entwickeln, wäre es einfach zu einem eigenen, von der restlichen GCCBenutzergruppe abgetrennten Zweig verkommen. Das wäre für sich genommen absolut in Ordnung und legal gewesen, hätte aber bedeutet, dass Cygnus alle Vorteile der Open-Source-Entwicklungsmethode verloren hätte, die für einen Großteil seiner Stärke verantwortlich zeichneten. Durch die Schaffung eines Zweigs, der von Benutzerseite breite Unterstützung genoss, setzte es den Hauptzweig - der letzten Endes von Stallman kontrolliert wurde - unter Druck, zu einer Einigung zu gelangen (was der Grund dafür war, warum Cygnus es „so zu machen versuchte, dass eine Einigung möglich war", wie Tiemann es ausdrückte). Tiemann erklärte, was nach der Gabelungsentscheidung passierte. „Während EGCS weiterlebte", sagt er, „versuchte Stallman herauszufinden, welche Folgen die Unterstützung dieser von Cygnus gesponserte Gabelung haben würde. Rückblickend betrachtet denke ich, dass die Integrität der Leute, die derzeit [bei Cygnus] an dem GNUCompiler arbeiten, so unangreifbar war, dass er diese sehr riskante Entscheidung treffen und sagen konnte: ,Na gut, dann setze ich eben alles auf diesen Zweig, der von einem kommerziellen Unternehmen kontrolliert wird.'" Stallman heilte also die Gabelung, indem er die Cygnus-Version als Grundlage für Weiterentwicklungen des offiziellen GCC verwendete, das er auf GNU (Compiler Collection) (vom GNU C Compiler) umbenannte, um den erweiterten Zielen des Projekts Rechnung zu tragen. Das war ein mutiger Schritt und gleichzeitig


--------------------------------------------------------------------------------------ein Sprung ins kalte Wasser. Wie Tiemann zu Recht betont, wurde die EGCS-Gabeiung weniger von Cygnus als von seinen Ingenieuren kontrolliert. Auf der Grundlage ihrer früheren Arbeit - und ihrer „Integrität" im Zusammenhang mit der GCC-Entwicklung - war Stallman zuversichtlich, dass sie GCC zum Wohl der Allgemeinheit weiterentwickeln würden, während sie gleichzeitig die Anliegen von Cygnus berücksichtigten. Das lässt den Schluss zu, dass etwa ein Unternehmen wie Red Hat eine aktivere Rolle bei der Festlegung des zukünftigen Kurses von GNU/Linux übernehmen könnte, ohne es auf irgendeine Weise zu „entführen". Wie Stallman - wohl kaum ein Mann des Kompromisses bereit war, die Entwicklung von GCC in die Hände seiner besten Entwickler zu legen und sich auf ihre „Integrität" zu verlassen, wenn es um seine Unabhängigkeit ging, bereitet es Linus vielleicht keine allzu großen Sorgen, dass Red Hat zur dominierenden Kraft der Linux-Welt wird. Alan Cox und Dave Miller sind in dem Unternehmen beschäftigt, und niemand würde daran denken, ihre Integrität in Zweifel zu ziehen. In gewissem Sinn garantieren sie, dass Red Hat immer ein verantwortungsvoller Hüter der Interessen der Linux-Gemeinde sein wird, wie Cygnus Hüter der Interessen von GCC war. Die Macht der Benutzer, versinnbildlicht durch Spitzenhacker wie Cox und Miller, die zu den Spitzenvertretem der Welt der kommerziellen Distributionen zählen, ist einer der Gründe dafür, dass es Red Hat und ähnlichen Unternehmen nie gelingen wird, der Welt der freien Software ihren Willen aufzuzwingen. Aber es gibt noch einen weiteren Grund, der sich aus der einzigartigen Geschäftsdynamik ergibt, deren Grundlage die Open-Source-Software ist. Um zu verstehen, warum Red Hat nie ein zweites Microsoft werden wird, braucht man sich nur vor Augen zu führen, was ein Unternehmen tun muss, um den Riesen aus Redmond frontal anzugreifen. Da das Windows-Betriebssystem urheberrechtlich geschützt und geschlossen ist, kommt es einem Mammutunterfangen gleich, einen guten Klon zu produzieren. Ein perfekter Klon ist so gut wie unmöglich. Deshalb wird Microsoft immer den Vorteil der aktuellen Kompatibilität und der zukünftigen Innovation haben.


------------------------------------------------------------------------------------In der GNU/Linux-Welt ist die Situation anders. Da Red Hat, wie man ihm zugute halten muss, seine gesamten Produkte unter der GNU GPL herausbringt, kann jeder sie nehmen und verwenden. Das bedeutet, dass die Eintrittsbarrieren für Microsoft-Konkurrenten fast unüberwindlich sind, während sie für Konkurrenten von Red Hat praktisch nicht existieren. Interessant dabei ist, dass diese Dynamik nicht nur den aktuellen Konkurrenten von Red Hat die Möglichkeit bietet, im Technikbereich rasch aufzuholen, sondern auch neuen Marktteilnehmern. Der Aufstieg von MandrakeSoft zeigt, dass diese Möglichkeit nicht nur Theorie ist. 1995 hielt Gael Duval, ein 22-jähriger Student der Computerwissenschaften aus Caen in der französischen Normandie, nach einem Unix für seinen 386er-PC Ausschau - eine Geschichte, wie es sie zu Tausenden gibt. „Ich durchsuchte das Internet und stieß natürlich auf Linux, [das] ich mir auf insgesamt fünfzig Disketten herunterlud", erinnert er sich. Duval war - wenig überraschend -beeindruckt von dem, was er da sah. Auch Duval begann wie namenlose Hacker vor ihm, die stetigen Verbesserungen von Linux zu verfolgen und Red Hat und GNU/ Debian neben der Slackware-Distribution, die er als Erstes heruntergeladen hatte, zu verwenden. Besonders gefielen ihm das Red-HatDistributionsformat und das Installationsverfahren. Dann, als Ende 1997 der KDE Desktop angekündigt wurde, begann Duval, auch dieses Projekt zu verfolgen. „Ich liebe grafische Betriebssysteme", bekennt er. Aber jetzt hatte er ein Problem. Da KDE die Qt-Bibliotheken (die ursprünglich nicht Open Source waren) von Trolltech verwendete, weigerte sich Red Hat, es zu liefern. Aber Duval wollte KDE verwenden und die Red-Hat-Distribution, an die er sich schon gewöhnt hatte, trotzdem behalten. Die Lösung war für einen Hacker klar: Er würde einfach seine eigene Distribution herausbringen, die Red Hat und KDE vereinigte. Nach der Nummer der Red-Hat-Version, auf der sie basierte, nannte Duval seine Distribution Linux-Mandrake 5.1. Im Juli 1998 stellte Duval sie auf einen FTP-Server, von wo sie heruntergeladen werden konnte - wie Linus es mit seinem ursprünglichen Linux-Code getan hatte. Wie Linus von dem Feedback ermutigt worden


--------------------------------------------------------------------------------------war, das er für seinen frühen Kernel bekam, fühlte sich auch Duval durch die Reaktionen auf seine Distribution Marke Eigenbau angespornt. „Es war ganz unglaublich", sagt er. „Ich bekam sofort Hunderte von E-Mails von Leuten, denen das Projekt und das Produkt gefielen. Und ich bekam auch bereits die ersten Patches und Ideen." Noch verblüffter war er darüber, dass er zwei E-Mails aus den Vereinigten Staaten und eines aus Australien bekam. „Am unglaublichsten", so sagt er, „waren drei Firmen, die mir mitteilten, dass sie begonnen hätten, GPL-CDs von Mandrake zu verkaufen." Das öffnete ihm die Augen für eine Möglichkeit, die er bis dahin nicht in Betracht gezogen hatte. Als er Linux-Mandrake entwickelt hatte, verschwendete er keinen Gedanken daran, es zu verkaufen. „Ich hatte eben erst mein Studium abgeschlossen", sagt er. „Ich hatte kein Geld und ich suchte einen Job als Unix-Systemadministrator oder Programmierer. Aber nun, wegen der Nachfrage, begann ich einige Mandrake-CDs zu verkaufen." Duval tat sich mit zwei anderen Franzosen, Jacques Le Morois und Frederic Bastok zusammen. Gemeinsam gründeten sie im Dezember 1998 MandrakeSoft mit Zentrale in Paris. Obwohl sie klein begannen - „wir starteten mit privaten Geldern und finanzierten uns durch den Verkauf von Mandrake-Powerpacks" -, wuchs MandrakeSoft schnell. Am Ende seines ersten Geschäftsjahres hatte es fünfzig Angestellte, bald danach waren es schon hundert. Einer der ersten Coups von MandrakeSoft bestand in der Unterzeichnung eines Vertrags mit dem US-Verlagshaus Macmillan üher die Anfertigung einer Einzelhandelsdistribution, die im Juni 1999 herauskam. „Macmillan ist in vielen Einzelhandelsgeschäften in den Vereinigten Staaten und in einigen europäischen Ländern vertreten", sagt Duval. „Sie suchten nach einer Alternative zu Red Hat und meinten, dass Mandrake die beste Wahl für sie war." Laut einer Presseaussendung vom 27. Oktober 1999 „handelte es sich bei 52 Prozent alle Linux-Softwareeinheiten, die im August 1999 in den Vereinigten Staaten verkauft wurden, um das auf Mandrake basierende Macmillan-Produkt." Das war nicht einmal ein Jahr, nachdem LinuxMandrake zusammengestellt worden war.


------------------------------------------------------------------------------------Macmillan war nicht der Einzige, der sich für dieses junge Unternehmen und seine neue Distribution entschied. Ebenfalls im August 1999 gewann Linux-Mandrake zwei LinuxWorld-Herausgeberpreise als Produkt des Jahres und in der Kategorie Distribution/Server (in der Kategorie Distribution/Client war es Zweiter). Im selben Monat beteiligte sich der Investmentfond AXA, eine der führenden Versicherungs- und Vermögensverwaltungsgesellschaften der Welt, dessen verwaltetes Vermögen sich auf fast 655 Milliarden US-Dollar beläuft, an MandrakeSoft. Und das war noch nicht alles: Das gesamte in einem Jahr aufgebrachte Risikokapital betrug 15 Millionen US-Dollar. Wie seine älteren Rivalen begann MandrakeSoft Spitzenhacker einzustellen und kaufte sogar Projekte, um sie als Open-SourceSoftware herausbringen zu können. So kam es, dass MandrakeSoft heute ein Schaukasten aller Stärken des Open-Source-Modells in der Wirtschaft ist. Die GNU GPL erlaubte es einem mehr oder weniger mittellosen Studenten, eine neue Distribution zu entwickeln, die dem finanziell gut gepolsterten Red Hat Paroli bieten und dieses in vielen Fällen aus dem Feld schlagen konnte. Sie ermöglicht auch, dass andere das Mandrake-Produkt als Ausgangspunkt für weitere neue Distributionen nehmen können. „Das ist auch mehrmals passiert", sagt Duval. Er begrüßt das: „Es ist gut für uns, weil wir dadurch noch bekannter werden und eine noch größere Reichweite erlangen." So wirbt auch Mandrake für die Red-Hat-Distribution. Diese scheinbar unlogische Dynamik wirkt der Dominanz einer einzelnen Distribution entgegen. Sie sorgt auch dafür, dass die Bedürfnisse der Benutzer frühzeitig erfüllt werden. Wenn keine der bestehenden Distributionen - derzeit gibt es mehr als hundert von ihnen - einen Markt gut genug bedient, hat ein Neuling, auch wenn er nur über die beschränktesten Ressourcen verfügt, leichtes Spiel, diese Distribution zu entwickeln und eventuell zum nächsten MandrakeSoft oder sogar Red Hat aufzusteigen. MandrakeSoft entschied sich dafür, als Red-Hat-Klon zu starten, und ist auch heute noch mit Red Hat kompatibel. „Wenn ein Softwareunternehmen eine Applikation ... entwickelt, die auf Red-HatSysteme abzielt, lässt sie sich auf Mandrake installieren",


--------------------------------------------------------------------------------------erklärt Duval. Dieses Feature von Linux-Mandrake deckt allerdings eine Frage auf, die für GNU/Linux von nachhaltiger Relevanz ist: die Inkompatibilität einzelner Distributionen. Diese hat mit der Art und Weise zu tun, wie Software ausgewählt und abgepackt wird, nicht mit Gabelungen des Programms selbst. So können Entscheidungen, welche Kemelversion nun übernommen wird, wie viele Patches integriert werden und an welcher Stelle der Installation eine Bibliothek platziert wird, darüber entscheiden, ob ein Anwendungspaket auf einer bestimmten Distribution laufen wird oder nicht. Viele Softwaredistributoren haben vier oder mehr geringfügig verschiedene Versionen ihrer Produkte auf Lager, um den winzigen Abweichungen der einzelnen Distributionen gerecht zu werden. Nachdem er erkannt hatte, wie ineffizient dieser Ansatz war und wie groß die Gefahr, dass solche Differenzen sich ausweiten könnten, entwickelte Bruce Perens, Autor der ursprünglichen Open-SourceDefinition und zweiter Leiter des Debian-Projekts 1998, die Linux Standard Base (LSB). Hauptziel von LSB ist es, „zu bewerkstelligen, dass eine Applikation von einer Distribution zu einer anderen übergehen kann, ohne rekompiliert werden zu müssen", sagt Perens. Leider, so fügt er hinzu, „dauert das länger, als es mir angenehm ist". Den größten Druck, Standards zu definieren, werden wahrscheinlich jene Unternehmen ausüben, die davon am stärksten betroffen sind. Aufgrund seiner Annahme von GNU/Linux als strategische Plattform, die alle seine Hardwarelösungen einigt, hat IBM durch die Unterschiede der wichtigsten GNU/Linux-Distributionen mehr zu verlieren als die meisten. Es überrascht daher nicht, dass der GNU/Linux-Chef von IBM, Irving Wladawsky-Berger, über LSB sagt: „Sie ist sehr wichtig, und ich glaube, dass sie das werden wird, was die IETF [Internet Engineering Task Force, die technische Standards entwickelt] für das Internet ist. Meiner Meinung nach wird die LSB uns helfen, zu einer Definition der Linux-Standards zu kommen. Meiner Meinung nach ist hier die Unterstützung vieler Firmen wie IBM und Silicon Graphics und auch die Unterstützung anderer nützlich."


------------------------------------------------------------------------------------Diese Unterstützung durch IBM wird die LSB Wirklichkeit werden lassen. Wie es Wladawsky-Berger ausdrückt: „Wir ermutigen alle, eng mit der LSB zu kooperieren." Es ist leicht vorstellbar, welche Art „Ermutigung" IBM einer GNU/Linux-Distribution anzubieten hätte, die - aus welchen Gründen auch immer - den LSB-Standard nicht voll unterstützen würde. So würde die Drohung, aus der IBM-Liste genehmigter Distributionen gestrichen zu werden, wohl jeden, auch die größten Open-Source-Untemehmen, dazu „ermutigen", Linientreue zu zeigen. Selbst unter der Annahme, dass Projekte wie LSB erfolgreich sein werden und dass die Open-Source-Welt nicht übermäßig zersplittert oder konsolidiert werden wird, wird Open Source noch eine Reihe anderer Herausforderungen zu bewältigen haben, bevor es sein volles Potenzial ausschöpfen kann. Eine Bedrohung besteht zum Beispiel darin, dass die kommerziellen Softwarehäuser mithilfe von Patenten die derzeit zumindest in den Vereinigten Staaten für überraschend banale Ideen zuerkannt werden - die Hacker daran hindern könnten, in ihrer freien Software bestimmte Programmiertechniken zu verwenden. Eine weitere Bedrohung, die noch heimtückischer ist, wurde 1998 vom Microsoft-Ingenieur Vinod Valloppillil im ersten Halloween-Dokument angesprochen. In einem Abschnitt mit der Überschrift „Blunting OSS Attacks" „Entschärfung von Open-Source-Software-Angriffen" - schlägt er ein „De-Commoditizing" von Protokollen und Anwendungen vor, durch das die Entwicklung von Internetsoftware nur noch MicrosoftProgrammierern gestattet werden soll. Wie er erklärt, liegt einer der Gründe für das Florieren von Open-Source-Projekten in der Existenz grundlegender Protokolle (Regelwerke), die bestimmen, wie Dinge wie das Web und E-Mail funktionieren. Sie einem „De-Commoditizing" zu unterziehen würde bedeuten, jene Standards zu eliminieren, in deren Implementierung sich Open Source als so effizient erwiesen hat. Wie Valloppillil es ausdrückt: „Durch die Erweiterung dieser Protokolle und die Entwicklung neuer können wir verhindern, dass OSS-Projekte in den Markt eindringen." Der unverblümte Zynismus dieser Aussage ist erstaunlich; hier wird ein Ansatz der Fragmentierung von Standards in den Raum gestellt - und zwar nicht zum Nutzen des Kunden, sondern


--------------------------------------------------------------------------------------einzig zu dem Zweck, der Open-Source-Bewegung Steine in den Weg zu legen. De-Commoditizing ist mehr als reine Theorie. Das Ziel, das Microsoft als erstes ins Visier nahm, um es in die Praxis umzusetzen, war ein offenes Sicherheitsprotokoll namens Kerberos, benannt nach dem dreiköpfigen Wachhund am Eingang zur Unterwelt - die griechische Form des lateinischen Cerberus. Kerberos entwickelte sich aus dem MIT-Projekt Athena, das 1983 begonnen worden war und aus dem heraus auch X Window entstanden war. Es wurde von der IETF als Internetstandard veröffentlicht und steht der Öffentlichkeit zur freien Verwendung zur Verfügung. Microsoft bot Kerberos erstmals mit Windows 2000 an, das am 17. Februar 2000 herauskam. In einem klassischen Beispiel von „Umarmung, Erweiterung und Auslöschung" fügte Microsoft seine eigene Kerberos-Erweiterung hinzu; damit verhinderte es, dass andere Implementierungen uneingeschränkt damit arbeiten konnten. Obwohl es auf offenen Protokollen aufbaute, weigerte sich Microsoft anfangs, Einzelheiten über seine Erweiterung bekannt zu geben. Ende April 2000 stellte Microsoft ein Dokument auf seine Website, in dem diese Erweiterungen beschrieben wurden. Die Sache hatte jedoch einen typischen Haken: Obwohl die Spezifikationen frei heruntergeladen werden konnten, konnten sie nur betrachtet werden, wenn der Benutzer einen Lizenzvertrag akzeptierte. Diese Lizenz untersagte alle Versuche, die Erweiterung in neuem Code zu implementieren, wie zum Beispiel in Samba. Tatsächlich weist Jeremy Allison von Samba darauf hin, dass „Samba eine Totgeburt gewesen wäre, wenn [Microsoft] in den frühen Tagen von SMB diese Möglichkeit gehabt hätte". Die Kerberos-Saga sollte in sich selbst eine deprimierende Geschichte darüber werden, dass Microsoft unverfroren genug war, ein Protokoll einem „De-Commoditizing" zu unterziehen und seine Desktop-Macht dazu zu verwenden, ausgerechnet in der Zeit eine geschützte Erweiterung hinzuzufügen, in der es in dem US-Antitrust-Verfahren wegen seines bisherigen monopolistischen Verhaltens an den Pranger gestellt wurde. Aber die Geschichte


------------------------------------------------------------------------------------nahm eine noch verblüffendere Wendung, als die Hacker die Lizenzvorschriften zu verhöhnen begannen und die vollen Einzelheiten der Microsoft-Erweiterung Anfang Mai auf der Slash-dot.org-Site veröffentlichten. Am 11. Mai 2000 reagierte Microsoft, indem es eine E-Mail an Slashdot schickte, in dem es auf die seiner Meinung nach „nicht autorisierten Reproduktionen urheberrechtlich geschützter Microsoft-Arbeit" hinwies. Microsoft berief sich also auf das Urheberrecht, speziell auf den relativ neuen U.S. Digital Millennium Copyright Act, der den Urheberrechtseigentümern weit gehende Vollmachten für die Verfolgung von Urheberrechtsverletzungen gewährt. Slashdot antwortete, es wolle nicht als Zensor auftreten, indem es Postings seiner Leser zurückhielt. Die Kerberos-Saga macht deutlich, dass die Beziehungen zwischen Geschäftsgeheimnissen, freier Software, Copyright und Freiheit immer verworrener werden, genau wie Eben Moglen, Rechtsberater der Free Software Foundation, es prognostiziert hatte. In einem anderen Bereich, in dem die freie Software möglicherweise vor rechtlichen Problemen steht, kann Moglen aus eigener Erfahrung sprechen. Manche meinen, dass die GNU GPL, die Defacto-Verfassung der gesamten Bewegung der freien Software, vor Gericht eventuell nicht bestehen wird. Sollte das der Fall sein, würde das der Open-SourceWelt einen enormen Schock versetzen, regelt die GNU GPL doch einen Großteil ihrer Aktivitäten. Bisher hat sich die Durchsetzung noch nicht als problematisch erwiesen. „Etwa ein Dutzend Mal im Jahr", sagt Moglen, „tut irgendjemand etwas, was die GPL verletzt. Meistens sind sich die Leute des Problems gar nicht bewusst, weil sie die Bestimmungen nicht durchdacht haben. Dann rufe ich sie an und sage: .Hallo, Sie verletzen die GPL. Sie müssen jetzt Folgendes tun. Würden Sie uns helfen?'" Wie er erzählt, ist die Antwort fast immer Ja. „Es ist richtig", gibt Moglen zu, „dass sich noch kein großes amerikanisches Softwarehaus auf eine öffentliche Kontroverse mit uns über die Durchsetzbarkeit der GPL eingelassen hat." Auch wenn daraus manche schließen, dass „das bedeutet... dass die GPL etwas an sich hat, was nicht durchsetzbar ist, würde ich das schlichtweg


--------------------------------------------------------------------------------------umdrehen", sagt Moglen. „Es gibt deshalb keine solchen Kontroversen, weil niemand glaubt, dass er sie gewinnen kann." Aber, so fügt er hinzu: „Ich glaube, dass wir, um die Ängste, Unsicherheiten und Zweifel in dieser Sache wenigstens zum Teil auszuräumen, irgendwann einmal gezwungen sein werden, in einem Fall, den wir normalerweise auf unsere gewohnte Art beilegen würden, den Weg der gerichtlichen Durchsetzung zu gehen." Damit würde ein für alle Mal demonstriert werden, dass die GNU GPL gilt und weiterhin das Fundament der freien Software bildet. In einer Hinsicht kann die Open-Source-Welt von Glück reden, dass es Unternehmen gibt, die über die erforderlichen Ressourcen verfügen, um einen langwierigen Rechtsstreit mit einem finanziell gut gepolsterten Widersacher durchzustehen. Wie Moglen sagt: „Der Vorteil, den uns die anarchistischen Zustände an der Wall Street 1999 brachten", als Unternehmen wie Red Hat und VA Linux ungeheuer erfolgreiche IPOs erlebten, „ist, dass ... da einiges Geld herumliegt, das für diese Zwecke verwendet werden kann." Aber nur „in Grenzen", fügt er hinzu und merkt an, dass „alle diese Unternehmen nur deshalb so toll dastehen, weil ihre Produktionskosten gleich Null sind. Ihre Modelle gehen von der Idee aus, dass dieses Geschäft ein sehr kostengünstiges ist, weil ihre Produkte gratis von anderen Leuten für sie hergestellt werden." Moglens Beobachtung rührt an das vielleicht größte Fragezeichen, das hinter Open Source steht: Werden die Geschäftsmodelle, die darauf basieren, auf lange Sicht funktionieren? Larry McVoy ist ein Mann, der das bezweifelt: „Ich glaube, das nächste Problem der Open-Source-Bewegung wird sein, dass sie sich überlegen muss, wie man einen Ertragsstrom generiert und aufrechterhält", sagt er. Seine Worte haben besonderes Gewicht, ist er doch Autor des Sourceware-Vorschlags, der viele Merkmale der heutigen Betriebssystemlandschaft voraussah. „Das Problem an Open Source", erklärt er, „ist, dass sich die Dinge, die der Open-Source-Defmition entsprechen, allesamt auf die Rechte der Endbenutzer konzentrieren, zum Nachteil der Rechte der Distributoren." Die Folge, so McVoy, besteht darin, dass die Unternehmen, die auf Open-Source-Software basieren, nie in der Lage sein werden, es Netscape, Sun und Microsoft als Industrie-


------------------------------------------------------------------------------------giganten gleichzutun. McVoy ist auch der Ansicht, dass solche Unternehmen unter einer grundlegend falschen Vorstellung vom OpenSource-Entwicklungsmodell leiden. „Die einfache Arbeit zu machen, ist keine große Sache", sagt er. „Man kann ein Wochenende oder sogar einen Monat lang einen Hackeranfall haben, etwas Wichtiges zustande bringen und dafür viel Lob von der Community einheimsen." Aber er weist darauf hin, dass nach der einfachen Arbeit die Schinderei anfängt. VcVoy will nicht einmal gelten lassen, dass unbezahlte Hacker nützlich sind, wenn es darum geht, Bugs in dem Code zu finden, der von bezahlten Profis geschrieben wurde. „Wenn ein Collegestudent in seinem Zimmer über dem Zeug brütet, in das du fünfzehn Mannjahre Arbeit investiert hast, und sich eine Woche, ein Wochenende, einen Tag oder nur eine Stunde lang damit beschäftigt, kann er auf keinen Fall erfassen, wie das alles zusammen passt. Es gibt Unternehmen, die darauf setzen, dass sie durch das Open-Source-Modell einen Teil ihrer Entwicklungskosten einsparen können", sagt McVoy. „Aber ich glaube, sie setzen auf ein Modell, das scheitern wird." McVoy setzt seine Tirade gegen Open Source fort. Er ist nicht nur davon überzeugt, dass solche Unternehmen dem Untergang geweiht sind, sondern dass sie in ihrem Scheitern auch noch große Teile der bestehenden Softwarebranche mit sich in die Tiefe reißen werden. Je stärker sich GNU/Linux und andere Open-Source-Programme verbreiten, werden sie unweigerlich Lösungen anderer Distributoren hinausdrängen, in erster Linie im Unix-Bereich. Dabei, so McVoy, haben diese Distributoren das bezahlt, was wir heute Open Source nennen. „Das frühere [Software-] Ökosystem hatte ein eingebautes Polster", sagt er. „Es wurde mehr Geld verlangt, als das Zeug, das man dafür bekam, wert war. Das zusätzliche Geld finanzierte die Ingenieure, die in den Labors von Sun und HP und in den anderen Firmen saßen. Open Source ist nicht Freiwilligen zu verdanken", insistiert er. „Es ist Ingenieuren in Firmen wie Sun zu verdanken." „Das ist etwas, worüber Bob Young [von Red Hat] und ich ständig diskutieren", fahrt McVoy fort, „und er zerbricht sich ständig den Kopf deswegen. Denn Red Hat ist ja auf dem Weg, die


--------------------------------------------------------------------------------------Softwaredivision von Sun aus dem Geschäft zu drängen. Nun, das ist cool für Red Hat - aber es gibt ein Problem: Red Hat ist nicht profitabel genug, um die Software, die es bekommt, bezahlen zu können. Dabei bekommen sie einen Teil ihrer Software sogar von Sun. Das ist das, was man in der Branche als Killen des Lieferanten bezeichnet. Keine gute Idee." McVoys Argumentation wirft kritische Fragen über die Überlebensfähigkeit von Unternehmen auf, die sich rund um freie Software entwickelt haben. Wenn er Recht hat, sind die neuen OpenSource-Untemehmen, deren Lichter in den letzten Jahren so hell geleuchtet haben, dazu verurteilt zu scheitern und in Vergessenheit zu geraten und dabei auch noch die Lichter anderer Unternehmen auszulöschen, die von Unix abhängig sind. McVoys Analyse scheint den signifikanten Beitrag zu unterschätzen, den die Studenten zur freien Software leisten, ob nun in ihrer Freizeit (GIMP und Gtk) oder durch Kursprojekte (LyX Dokumentenverarbeitung) oder durch beides wie bei Linux, das als müßige Hackerei im Schlafzimmer begann und sich in Material für eine Dissertation verwandelte. Aber selbst wenn die Beiträge der Studenten relativ gering sind, und wenn die Open-Source-Unternehmen tatsächlich einige traditionelle Softwaredistributoren aus dem Geschäft drangen, bevor sie ihnen in die Vergessenheit folgen, spielt das möglicherweise keine Rolle. Wie im vorhergehenden Kapitel beschrieben, hat die Open-SourceRevolution die Pioniere hinter sich gelassen und ist weitergezogen. Heute haben die großen Mainstreamunternehmen wie IBM, HP, Compaq oder SGI Open Source alle in irgendeiner Weise aufgegriffen. Sie sind weder entscheidend von Unix abhängig wie Sun noch von Open Source, wie es bei Red Hat und anderen Distributionen der Fall ist. Stattdessen verwenden sie beide als Bestandteile einer allgemeineren Strategie, zum Beispiel, indem sie Hardware und Dienstleistungen verkaufen. Vor diesem Hintergrund erscheint dann die Frage, ob die neuen OpenSource-Unternehmen erfolgreich sein werden oder nicht, in gewisser Weise als sekundär, wenn auch nicht für sie selbst und für ihre Aktionäre. Die Entwicklung von GNU/Linux und Open Source innerhalb anderer Unternehmen wird trotz allem fast sicher


------------------------------------------------------------------------------------weitergehen. McVoy erklärt in seiner eigenen Analyse, warum. Das „eingebaute Polster", von dem er spricht, bedeutet, dass traditionelle Computeruntemehmen „es sich leisten können, einen gewissen Prozentsatz ihrer Techniker an Dingen arbeiten zu lassen, die sie [die Unternehmen] nicht verstehen und mit denen sie nicht einverstanden sind", merkt er an. Der Grand dafür ist, dass „die Ingenieure die Sache mit einer solchen Leidenschaft verfolgen, dass sie sagen: ,Also, ich mache das hier oder ich gehe.' Und die Unternehmen sagen: ,Na gut, dann mach es eben.'" Zumindest einige dieser Unternehmen werden erfolgreich sein - welche Auswirkungen Open Source auch haben wird, es ist nicht möglich, dass die gesamte Softwarebranche verschwinden wird - und diese leidenschaftlich engagierten Ingenieure werden dort weiterhin arbeiten. Die Früchte ihrer leidenschaftlichen Arbeit werden die Arbeit neuer Studentengenerationen in den Bildungsinstituten und die Arbeit der Hobbyprogrammierer zu Hause ergänzen, gar nicht zu reden von so besessenen Hackern wie Richard Stallman und der FSF, die nicht codieren, um zu leben, sondern leben, um zu codieren. Das ist letzten Endes der Grund dafür, warum das Überleben der freien Software nicht von Open-Source-Unternehmen abhängig ist: Sie existiert jenseits der Grenzen des Marktes. Die zentrale Frage lautet daher nicht, ob Open-Source-Unternehmen florieren und zu Milliarden US-Dollar schweren Kolossen anwachsen können, sondern ob sie so weiterwachsen und sich entwickeln können, wie sie es in den letzten anderthalb Jahrzehnten getan haben. Und es kommt eine weitere Skalierungsherausforderung auf sie zu: Wie kann die Open-Source-Methode auf immer ambitioniertere Projekte angewendet werden? GNU/Linux, Apache, Sendmail, Perl und die anderen sind der nachhaltige Beweis dafür, dass der Entwicklungsansatz sehr wohl Wachstum und Veränderung erlaubt - wenn die Straße auch manchmal ein wenig holprig ist. Aber die Projekte können nur dann in Angriff genommen und erweitert werden, wenn es genügend Hacker gibt, die Zeit, Energie und Begeisterung investieren: Der Erfolg der freien Software hängt von einem ständigen Zustrom frischer Codiertalente ab. Das Problem ist noch schwer-


--------------------------------------------------------------------------------------wiegender, als es auf den ersten Blick erscheint, weil Open Source diesen ständigen Zustrom neuer Hacker schon zur Weiterführung seiner aktuellen Projekte braucht. Obwohl bekannte Codierer wie Richard Stallman, Larry Wall und Linus Fixsterne am Hackerhimmel zu sein scheinen, ist das die überwältigende Mehrheit der Akteure in der Welt der freien Software keineswegs. So beschlossen zum Beispiel die Urheber von GIMP, Peter Mattis und Spencer Kimball, nachdem sie ein paar Jahre lang mehr oder weniger eigenständig gearbeitet hatten, es sei Zeit, weiterzuziehen, auch wenn die Software noch nicht ganz fertig war und keine Nachfolger nominiert waren. Zwei Männer, denen diese ständige Fluktuation im Codiererbereich mehr als bewusst ist, sind Miguel de Icaza und Mattias Ettrich. Um dem Problem entgegenzuwirken, konzipierten beide ihre ehrgeizigen Grafikschnittstellenprojekte als Ansammlung kleinerer Subprojekte. „Meistens ist es so, dass die Leute eine Zeit lang Beiträge leisten", erklärt de Icaza. „Dann kommen andere Verpflichtungen auf sie zu wie Schule, Heirat und Familie oder ein Jobwechsel, und sie müssen die Arbeit an dem Projekt einstellen." Ettrich drückt sich genauer aus: „Beim Programmieren freier Software ist eine Generation unglaublich kurz: Sie dauert zwischen einem halben und - bei den Engagierteren vielleicht zwei Jahren." Die Welt der freien Software beschäftigt sich daher mit der Frage, ob es genügend neue Hacker geben wird und woher sie kommen werden. In diesem Ausmaß ist nur die Open-Source-Welt mit dem Problem konfrontiert: Hersteller kommerzieller Software können immer zusätzliche finanzielle Anreize bieten, um Programmierer, die ans Kündigen denken, zu halten. Es ist leicht möglich, dass zusätzliche professionelle Programmierer Beiträge zu leisten beginnen, wenn die Open-Source-Welt weiter wächst und in den Mainstream eintritt. Aber auch wenn sie es nicht tun, hat die Welt der freien Software einzigartige Vorteile zu bieten, die es ermöglichen, diese Programmierer in neuen Quellen zu finden: in Gebieten, in denen das Computing noch in den Kinderschuhen steckt.


------------------------------------------------------------------------------------Wenn es keine gut entwickelte lokale Supportinfrastruktur gibt, ist die Zuverlässigkeit eine entscheidende Überlegung. GNU/Linux und freie Software sind dann möglicherweise die einzige Option, vor allem dann, wenn die finanziellen Ressourcen beschränkt sind. So verwendet zum Beispiel das in New York ansässige Sustainable Development Programme (SDNP), Teil des Entwicklungsprogramms der Vereinten Nationen, routinemäßig einen auf GNU/ Linux basierenden Ansatz für die Bereitstellung der ersten Internetanschlüsse für rund fünfundvierzig Nationen. Freie Software wird seit 1994 für diesen Zweck verwendet ein Zeichen für ihre frühe Stabilität und nachhaltige Nützlichkeit. Die Kleinheit der Computermärkte in vielen dieser Länder bedeutet oft, dass es einfach keine lokalen Versionen von urheberrechtlich geschützter westlicher Software gibt. So galt zum Beispiel „der äthiopische Markt einfach nicht als groß genug für Produkte im Microsoft-Stil", erklärt Donald Knuth. „Aber Freiwillige konnten den Open-Source-Code [des freien Satzprogramms TEX] nehmen und ihn selbst adaptieren." Die Folge war, so sagt er, dass die Computerbenutzer in Äthiopien „gute Schriften in Amharisch [der nationalen Hauptsprache, die ein eigenes Alphabet hat] bekamen, die irgendjemand in seiner Garage gemacht hatte." In einigen Teilen der Welt gibt es weitere Faktoren, die möglicherweise für Open Source anstelle von geschützter Software sprechen. In China einem Land, das Cliff Miller von TurboLinux besser kennt als die meisten anderen - „vertritt die Regierung die Einstellung, dass sie nicht auf etwas festgelegt sein möchte, das aus den Vereinigten Staaten kommt", wie er sagt. Die Folge ist, dass sie „ein Unternehmen, das urheberrechtlich geschützte Closed Source Software aus den Vereinigten Staaten verkauft, als ziemliche Bedrohung betrachtet. Linux entspricht ihren politischen und wirtschaftlichen Bedingungen besser als Microsoft Windows." Tatsächlich kursieren Gerüchte, dass die chinesische Regierung die Verwendung von Microsoft Windows 2000 sogar verbieten und GNU/Linux zum „offiziellen" chinesischen Betriebssystem machen könnte. „Wenn man an vielen Meetings teilnimmt, bekommt man ständig zu hören, dass die Chinesen mit Microsoft unzufrieden sind", sagt Miller. „Aber niemand sagt das offiziell. Für Linux


--------------------------------------------------------------------------------------hingegen gibt es große Begeisterung", sagt er. Ob offiziell oder nicht, GNU/Linux ist dabei, in China zum De-facto-Standard zu werden. „Ich bin mir sicher, dass es das werden wird", sagt Miller. Das heißt, dass Millionen chinesischer Benutzer Einfluss auf Open Source ausüben könnten, und dieser Einfluss könnte enorm sein. Aber auf kurze Sicht versprechen die indischen Beiträge noch wirkungsvoller zu sein. Indien hat den Vorteil, dass dort nicht nur Englisch - die Lingua franca der Zusammenarbeit der Hacker im Netz - weit verbreitet ist, sondern dass es dort auch eine große und gebildete Mittelklasse mit ungehindertem Computerzugang gibt. Kurz gesagt, ist Indien vielleicht das perfekte Reservoir für Codierer, die bereit sind, an freier Software mitzuarbeiten. Indien ist schon jetzt eine nicht zu unterschätzende Kraft in der Programmiererwelt. Das fiel international zum ersten Mal auf, als es darum ging, die Softwareprohleme im Zusammenhang mit dem Jahr 2000 zu beheben. Und es ist sicher kein Zufall, dass sich IBM im Rahmen seines Bekenntnisses zu Open Source zur Einrichtung eines GNU/Linux-Zentrums in Indien entschloss. „Eines der schönen Dinge an Linux ist, dass es nicht nur in den Vereinigten Staaten eine Brutstätte hat", sagt Wladawsky-Berger von IBM, „sondern sogar noch heißere in Europa, Indien und China. Wie man sich vorstellen kann, gibt es jede Menge toller indischer Ingenieure." Wahrscheinlich wird es noch mehr solcher Ingenieure geben, wenn sich ein indisches Open-Source-Projekt namens Simputer -zusammensetzt aus SIMPle compUTER - als erfolgreich erweist. Laut einer Presseaussendung vom 26. Mai 2000 ist der Simputer „ein mobiles Computinggerät für den .kleinen Mann' ... das ausschließlich auf freier Software basiert", in erster Linie auf GNU/ Linux, Perl und Tk. Es ist als „gemeinsamer Rechner für eine lokale Benutzergemeinde konzipiert" und ist dazu ausgelegt, „den ländlichen Massen Indiens die Vorteile der Informationstechnologie zugute kommen zu lassen". Der niedrige Preis des Geräts - um die 200 US-Dollar - ist für eine möglichst weite Verbreitung von entscheidender Bedeutung. Ohne Open Source wäre dieser Preis unmöglich zu erreichen.


------------------------------------------------------------------------------------Auch aus anderen Ländern werden wahrscheinlich größere Beiträge zu Open Source kommen - zum Beispiel aus Mexiko. Grund ist das große Fernschulungsprogramm, das dort derzeit durchgeführt wird. Einzelheiten darüber wurden erstmals im Oktober 1998 bekannt, als Arturo Espinosa Aldama einen Beitrag an eine Mailingliste für GNOME schickte, ein Projekt, zu dem er eine persönliche Beziehung hat. Wie Miguel de Icaza erklärt: „Er war in Mexiko mein Zimmergenosse", und im August 2000 trat Espinosa in de Icazas Unternehmen Helix Code ein. Espinosa schrieb 1998: Ich bin Projektleiter von „Scholar Net", einem Programm, dessen Ziel es ist, Computer und das Internet in jede Grund-und Mittelschule in Mexiko zu bringen. Wir gehen davon aus, dass zwischen 20.000 und 35.000 Labors pro Jahr installiert werden können, sodass sich die Gesamtzahl der Zentren in den nächsten fünf Jahren auf 140.000 belaufen wird. Zum damaligen Zeitpunkt führte diese Nachricht in manchen Gebieten zu der stark übertriebenen Behauptung, dass bald 140.000 mexikanische Schulen GNU/Linux verwenden würden. Espinosa betont: „Unsere Linux-Lösung ist nichts weiter als eine Möglichkeit. Linux wird nicht per Erlass installiert. In Wirklichkeit ist es so, dass jeder Bundesstaat selbst entscheidet, welche technologische Lösung für die Implementierung von Scholar Net dort verwendet werden soll." Bis jetzt, so sagt er, haben sechs von zweiunddreißig mexikanischen Staaten ein Interesse an seinem GNU/Linux-Ansatz bekundet. „Realistischerweise glaube ich, dass es in einem Jahr ungefähr fünf Staaten sein werden, die tatsächlich mit GNU/Linux arbeiten", sagt er. „Das bedeutet, dass es das Betriebssystem von etwa 1.500 Schulen sein wird." Obwohl das natürlich viel weniger ist als die von einigen vorschnell verkündeten 140.000 Schulen, handelt es sich doch um eine erhebliche Anzahl. Die Schulen würden ein wichtiges Testlabor für die Verwendung von GNU/Linux an Schulen sein. Außerdem würde ein wenn auch kleiner - Prozentsatz der dortigen Schüler an freier Software zu hacken beginnen. Das könnte einen


--------------------------------------------------------------------------------------wesentlichen Einfluss auf GNU/Linux haben. Wie Icaza sagt, bedeuten dieses und ähnliche Projekte, dass es „immer mehr Leute geben wird, die nicht von urheberrechtlich geschützten Technologien abhängig sind, und die wissen, wie man die Alternativen in Form von freier Software verwendet und wie man sie entwickelt". In gewissem Sinn sind jedoch die Pläne zur Einführung von GNU/Linux-basierten Systemen an Schulen ineffizient, wenn es um die Förderung junger Codierer zwecks Vorantreibung der Entwicklung freier Software geht. Dabei wird vorausgesetzt, dass die Kinder oder Jugendlichen mehr über die zugrunde liegende Software in Erfahrung bringen und zu programmieren und zu hacken beginnen. Neben solchen ehrenwerten Hoffnungen wäre ein formellerer Ansatz des Programmierunterichts notwendig, der die Betroffenen auf natürliche Weise dazu bringen würde, Beiträge zu Open-Source-Projekten zu leisten. Dies ist eines der Ziele eines Projekts namens Computer Programming For Everybody (CP4E), Geistesprodukt einer weiteren Schlüsselfigur der Open-Source-Welt. Guido van Rossum wurde 1956 in den Niederlanden geboren. Ende der achtziger Jahre, als er in Amsterdam lebte, arbeitete er an einem Zweig des Amoeba-Projekts, des Hauptforschungsprojekts des Minix-Urhebers Andrew Tanenbaum, der Professor an der Freien Universität der Stadt Amsterdam ist. „Ich erinnere mich, dass Tanenbaum mich einmal fragte: ,Sind Sie Forscher oder Entwickler?'", sagt van Rossum. „Ich weiß die Antwort auf diese Frage noch immer nicht. Wahrscheinlich bin ich ein bisschen von beidem." Während er am Amoeba-Betriebssystem arbeitete, hatte van Rossum die Idee, eine neue Sprache zu entwickeln. „Wir versuchten, Amoeba zu einem hinreichend verwendbaren System zu machen, das wir auf unseren Workstations laufen lassen und für unsere tagtäglichen Aktivitäten verwenden konnten", sagt er. „Dabei erkannten wir, dass das unter anderem deshalb schwierig war, weil wir keine gute Skriptsprache hatten" - eine Methode zur schnellen und einfachen Erstellung von Programmen. Deshalb schrieb van Rossum eine solche Skriptsprache, die er nach der Komödienserie Monty Python 's Flytng Circus von BBC TV Python nannte. „Das war damals eine meiner Lieblingsfernsehsendungen", sagt er.


------------------------------------------------------------------------------------Wie er später in seinem Vorwort zu Programming Python schreiben sollte: „Im Dezember 1989 hielt ich Ausschau nach einem ,Hobby'Programmierprojekt, mit dem ich mich in der Weihnachtswoche beschäftigen konnte." Zu beachten ist, dass er von einem „Hobby" sprach, ein Ausdruck, den auch Linus für seinen Kernel verwendete, als er bekannt gab, dass er daran arbeitete. Außerdem schrieb van Rossum ihn über Weihnachten 1989, wie Linus den Virtual Memory Code über Weihnachten 1991 schreiben sollte - und zwar aus demselben Grund: als Kampf gegen die Langeweile. Python wurde im Februar 1991 veröffentlicht und hatte bald eine begeisterte Anhängerschaft. Python ist in vieler Hinsicht ein Konkurrenzprodukt von Perl - der führenden Skriptsprache -, aber van Rossum betont, dass der Urheber von Perl, Larry Wall, und er einander nicht als Rivalen betrachten. „Ich finde, dass Larry ein großartiger Kerl ist, und Perl ist eine äußerst nützliche Sprache. Aber ich habe eine andere Philosophie, was das Sprachdesign anbelangt." Aufgrund dieser anderen Philosophie - die zum Teil von Ideen herrührt, die er sich von einer früheren Bildungsprogrammiersprache namens ABC lieh, die er „in freundlicher Erinnerung" hat - sagt van Rossum: „Mit der Zeit dämmerte mir, dass Python eine ausgezeichnete Sprache für den Anfängerunterricht ist." Die Projekte, an denen er damals für seinen Arbeitgeber, die Corporation for National Research Initiatives, CNRI, mit Sitz in Virginia, arbeitete, neigten sich ihrem Ende zu, und er begann Ausschau nach etwas Neuem zu halten. „Ich war mir sicher, dass ich hauptberuflich an Python arbeiten wollte", sagt er. „Dass es sich für den Bildungsbereich eignen könnte, war nur eine dieser Ideen, die mir durch den Kopf gingen." Dieses Projekt demokratisiert die Open-Source-Bewegung. Derzeit beginnen die Hacker entweder mit eigenen größeren Projekten oder sie schließen sich denen anderer an. Bei van Rossums Ansatz können viel mehr Leute ein einfaches Skript für ihre eigenen Bedürfnisse erstellen. Sobald sie auf den Geschmack gekommen sind, können sie problemlos zu etwas Größerem übergehen. Van Rossum ist davon überzeugt, dass dieser Ansatz bedeutende Auswirkungen auf Open Source haben könnte. „Manchmal glaube


--------------------------------------------------------------------------------------ich, dass ich verrückt bin", sagt er, „aber dann denke ich wieder, dass es sicher viele Leute gibt, die über grundlegende Programmierkenntnisse verfügen, die es ihnen erlauben, ihren Computer dazu zu bringen, das zu tun, was sie von ihm wollen. Es wird eine Open-Source-Gemeinde von Leuten geben, die kleinere und größere Dinge, die sie für ihre Computer geschrieben haben, untereinander austauschen. Diese Gemeinde wird sich nur insoweit von der bestehenden Open-Source-Community unterscheiden, als es sich um viele weitere Millionen Leute handelt, die vielleicht weniger kenntnisreiche, aber trotzdem interessierte Computerbenutzer sind." Das ganze CP4E-Projekt ist eng mit Open Source verflochten. Es wird nicht nur eine enorme Zahl potenzieller Codierer hervorbringen, sondern auch eine neue Nachfrage nach Open-Source-Software schaffen. „Wenn der Großteil der Software urheberrechtlich geschützt ist, werden viele der Ideale von CP4E nicht realisiert werden können", sagt van Rossum. „Denn eines dieser Ideale besteht darin, dass die Leute nicht nur keine Software von Grund auf schreiben wollen, weil das ein mühsamer Prozess ist, sondern dass sie bestehende Software nehmen und Veränderungen daran vornehmen wollen." Auch wenn man davon ausgeht, dass sich neue Pools von Codiertalenten entwickeln - in China und Indien, in den Schulen Mexikos und durch breit angelegte Bildungsprojekte wie CP4E -, gibt es einen Schwachpunkt der Open-Source-Bewegung: die Spitze. Wenn die richtige Führung fehlt und kein Prozess vorhanden ist, der die nahtlose Übergabe der Macht an die Nachfolger ermöglicht, wird die Energie verpuffen und die weltweiten Projekte freier Software werden zu einem irrelevanten Programmierzeitvertreib verkommen - selbst dann, wenn es einen stetigen Zustrom begabter Hacker gibt. Viele der wichtigsten Open-Source-Projekte haben hier bereits vorgesorgt. Die Kerngruppe von Apache nimmt neue Mitglieder auf, wenn alte ausscheiden. Larry Wall zog sich aus der alltäglichen Leitung von Perl zurück, damit andere übernehmen konnten. Hinter Projekten wie Sendmail und Tel stehen Unternehmen mit bezahlten Ingenieuren, die die Standards weiterentwickeln und gleichzeitig die Offenheit wahren. Aber bei zwei der führenden


------------------------------------------------------------------------------------Softwareprojekte bleibt die Nachfolgefrage unbeantwortet: Linux und GNU. Da Linux eine hohe Bekanntheit genießt und immer mehr Unternehmen ihre Zukunft von der Fortsetzung seiner Entwicklung abhängig machen, wird besonders die Frage diskutiert, was nach Linus sein wird. Die Meinungen innerhalb der Open-Source-Welt gehen auseinander. Larry McVoy ist zum Beispiel überzeugt, dass „Linux von Linus zusammengehalten wird. Er ist eine einzigartige Persönlichkeit. Ich drücke es immer so aus: großartiger Programmierer, großartiger [Software] Architekt, netter Kerl - man entscheide sich für zwei davon: Alle drei sind in einem einzelnen Menschen nicht vereint" - außer in Linus. Stephen Tweedie ist optimistischer. „Es sind so viele andere Leute involviert", sagt er, „die in der Lage sind, immer mehr Arbeit zu übernehmen. Ich sehe wirklich nicht, dass es da ein langfristiges Problem geben könnte." Ein weiterer langjähriger Hacker, Ted Ts 'o, stimmt zu: „Es gibt eine Reihe von Leuten, die imstande sind, die Arbeit zu bewältigen. Irgendjemand müsste zum Nachfolger ernannt werden, oder wir könnten uns auch für ein anderes Modell entscheiden vielleicht etwas wie Apache oder Perl, Entwicklergemeinschaften. Es steht noch nicht fest, was wir tun werden." Und Ts'o betont: „Es hat viel damit zu tun, ob es genügend Leute in der Entwicklergemeinde gibt, die die notwendige Reife aufbringen." Zum Glück scheint die Linux-Gemeinde sowohl über tief gehende Stärke als auch über die notwendige Reife zu verfügen, um mit jeder Situation fertig zu werden, die da kommen mag. So sind Alan Cox und Dave Miller auf jeden Fall Kandidaten, die das Steuer übernehmen könnten, sollte das notwendig werden. Alan Cox leitet bereits den stabilen Codezweig, sodass Linus sich auf die Entwicklungsversion konzentrieren kann. Obwohl Alan Cox die logische Wahl ist, ist er überzeugt, dass „es mehrere Leute gibt, die das Ruder übernehmen könnten". Er fugt hinzu: „Wie ich höre, hat Linus irgendwo Anweisungen für den Fall des Falles liegen. Den Inhalt habe ich aber nie gesehen, und ich hoffe, dass ich ihn auch nie sehen werde." Auch Dave Miller leitet einen alternativen Kernel Source Tree, der auf der vger-Maschine beheimatet ist. „Das ist ein riesiger


--------------------------------------------------------------------------------------Brocken, der jetzt vollkommen unabhängig von Linus entwickelt wird", wie Tweedie sagt. Trotzdem weiß auch ein so begabter und ehrgeiziger Mann wie Miller, der 1998, als es darum ging, dass „Linus nicht skaliert", um ein Haar den gewagten Schritt einer Gabelung des LinuxCodes gesetzt hätte, dass der Zeitpunkt, an eine Übernahme zu denken, noch nicht gekommen ist. „Ich glaube nicht, dass ich persönlich wirklich reif genug bin, es in diesem Augenblick richtig zu machen", sagt er. „Wenn ich müsste, würde ich es machen. Vielleicht in einem oder zwei Jahren könnte ich mir einen Überblick über ein so großes Projekt verschaffen und intelligente und wohlüberlegte Entscheidungen treffen. Aber ich hoffe, dass ich nie dazu gezwungen sein werde." Und mit wissendem Understatement fügt er hinzu: „Linus macht seine Sache doch ziemlich gut." Diese beiden Standpunkte - dass Linus einzigartig ist, und dass er ersetzbar ist - schließen einander nicht vollkommen aus. Linus' größte Leistung liegt nicht in seiner Software: Eines Tages wird Linux obsolet werden. Wie Alan Cox es ausdrückt: „Irgendwann wird der Punkt kommen, an dem jemand etwas zu entwickeln versucht, das verlangt, dass Linux grundlegend aufgebrochen werden muss. Es wird also etwas kommen, das Linux ersetzt und Linux nur als Ersatzteillager verwendet." Linus' bleibender Beitrag besteht also eher darin, dass er das von den Hackerkulturen in Berkeley, dem GNU-Projekt und Minix ererbte Entwicklungsmodell in leicht modifizierter Form perfektionierte. Linus öffnete den Prozess und weitete ihn unbeschränkt aus: Jeder kann den neuesten Kernel herunterladen, jeder kann Patches einsenden. Linus fügte das entscheidende Element der sofortigen Überprüfung hinzu, das bewirkt, dass zu bestimmten Zeiten fast täglich aktualisierte Kernels herauskommen, und durch das der Open-Source-Prozess auf die nächsthöhere Ebene gehoben wurde. Linus ließ es immer mehr zu, dass seine Leutnants Teile des Kernels übernahmen, und sorgte so dafür, dass seine Skalierbarkeit und seine langfristige Überlebensfähigkeit zunahmen. Linus ist deshalb einzigartig, weil es ihm gelang, zu einem Brennpunkt für all diese Fortschritte zu werden, die gemeinsam jene bahnbrechend neue Methode schufen, die heute für den


------------------------------------------------------------------------------------weiteren Erfolg der Open-Source-Bewegung eine entscheidende Rolle spielt und die erste plausible Alternative zum derzeitigen - und ins Trudeln geratenen - Modell der Softwareentwicklung bietet. Genau wegen dieser Methode, die das Delegieren von programmbezogenen und architektonischen Entscheidungen auf spezialisierte Expertenrunden gestattet, ist Linus auch ersetzbar. Durch sie kann aber auch sein Führungsstil - zugunsten der Benutzerbasis Macht abzugeben - weiter verbreitet werden. Dieses Delegieren von Macht ist möglich, weil Linus Pragmatiker ist und der Entwicklungsprozess von Linux inhärent konsensbestimmt ist. Im Puristenflügel sind die Dinge jedoch nicht so einfach gelagert. Kompromisse werden nicht akzeptiert, wenn es um grundlegende, prinzipielle Fragen geht, wie es die Wahl einer zukünftigen Führungspersönlichkeit für die GNU-Bewegung unweigerlich ist. Angesichts der Tatsache, dass es in den Zielen des GNU-Projekts keine Unklarheiten geben darf, ist Führung durch ein Komitee - ein in sich unklarer Ansatz - nicht möglich. Gebraucht wird jemand, der in der puristischen Hackergemeinde nicht nur seiner technischen Fähigkeiten wegen ungeteilten Respekt genießt, sondern auch, weil er nachweislich den Idealen treu ist, die im Mittelpunkt der GNU GPL und des GNUProjekts stehen. Stallman sagt mit einem Anflug von Verzweiflung: „Ich werde in der Bewegung der freien Software weiterarbeiten, weil ich nicht sehe, wer mich ersetzen soll." Trotzdem könnte sich in der Person Miguel de Icazas bereits ein würdiger Nachfolger präsentieren, der über die seltene Mischung der notwendigen Eigenschaften verfügt. Seine Managementfähigkeiten, die sich in der reibungslosen Durchführung Hunderter Programme im GNOME-Projekt zeigten, sowie seine eigenen überzeugenden Fähigkeiten als Programmierer, die er beim Codieren des Midnight Commander und Gnumeric unter Beweis stellte, stehen ebenso außer Frage wie sein unverbrüchliches, tief verankertes Bekenntnis zu den Idealen der freien Software. Seine eigene Sichtweise dieser Ideale ist interessant: „Wenn die Jahre vergehen und man in diesem Rahmen arbeitet", sagt er, „beginnt man in vielen Bereichen die Beziehungen zu Freunden und Familienmitgliedern neu zu bewerten. Diese Ideen, die der freien Software zugrunde liegen, die Ideen des Weitergebens und


--------------------------------------------------------------------------------------der Anteilnahme und Fürsorge für andere, beginnen dann auch andere Bereiche des Lebens zu durchdringen." De Icaza bringt hier Dinge zum Ausdruck, die in Stallmans Kreuzzug für freie Software und in der Schaffung einer Gemeinde, die sie gemeinsam verwendet, seit jeher verankert waren. Obwohl de Icaza hofft, dass jemand Stallman ablösen wird, der weniger Pflichten hat als ich", wenn sich die Notwendigkeit dazu je ergeben sollte, sagt er doch, „dass ich es tun würde, wenn Richard mich darum bittet". So gibt er der gesamten freien Softwarebewegung die Garantie für Kontinuität und eine Zukunft, ganz gleich, was geschieht. Die Bereitschaft von de Icaza, eine so mühsame Aufgabe zu übernehmen - eine Aufgabe, die bereits Stallman dazu zwang, auf vieles im Leben zu verzichten -, ist auch ein Zeichen dafür, dass freie Software und Open Source weiterhin florieren und sich weiterentwickeln werden. Irgendjemand, ganz gleich ob in Boston, Helsinki, Mexico City, Beijing oder Delhi, jemand, der jung und mit zunehmender Wahrscheinlichkeit eine Frau ist, wird bereit sein, trotz des zu leistenden persönlichen Tributs eine ähnliche Last zu übernehmen, wenn sich die Notwendigkeit dazu ergibt. Alles in allem geht es bei GNU/Linux und den Open-Source-Projekten nicht nur um Softwarecode. Wie in diesem Buch beschrieben, geht es auch um Freiheit, Teilen und Gemeinsamkeit, um Kreation, Schönheit und das, was Hacker als „Spaß" bezeichnen - obwohl „Freude" wahrscheinlich ein besserer Ausdruck wäre. Es geht um den Code, der dem Besten in uns zugrunde liegt, dem, was sich gegen das Schlechteste wehrt, dem, was es geben wird, solange die Menschheit existiert.

(Leerseite)

Epilog von Sebastian Hetze

Linux in Europa und Deutschland Linux wäre nicht das funktionelle und faszinierende Kronjuwel der freien Software ohne die Fan- und die Entwicklergemeinde aus Europa, besonders aus Deutschland. Hunderte Entwickler und Betatester aus Deutschland entwickelten und entwickeln an allen Teilen des Kernels, XFree86, KDE und vielen anderen Open-Source-Projekten. Mit SuSE sitzt in Deutschland zudem ein Distributionshersteller im XXL-Format. Ohne Anspruch auf Vollständigkeit will ich hier aufzeigen, welchen enormen Einfluss europäisch-deutsche Strömungen auf die weltweite Entwicklung von Linux hatten - und haben.


------------------------------------------------------------------------------------lSDN4Linux: ein deutscher Entwicklungsbeitrag Noch 1992 hatte kein Privatmann Zugang zum Internet. Die Kommunikation über Linux und der Download von Linux-Dateien wurden meist über Modems mit 2400 Bits pro Sekunde vollzogen: nach heutigem Maßstab unglaublich langsam. Nur an den Universitäten waren einige Zugänge zu Newsgroups wie comp.os.minix verfugbar. Das gleiche Bild bei Linux: Serielle Treiber für Modems und das UUCP sowie die verschiedenen Programme für Terminalemulation und komprimierte Datenübertragung standen am Anfang der Entwicklung, die mit der Einführung von ISDN, dem digitalen europäischen Telefonnetz, ihren Siegeszug antrat. Dank massiver Telekom-Förderung waren dem privaten und kommerziellen Internet Tür und Tor geöffnet. ISDN ermöglichte die schnelle digitale Datenübertragung zwischen Computern zu einem erträglichen Preis - gerade unter Linux. Die erste ISDN-Lösung für Linux entwickelte 1993 Matthias Urlichs. Er tauschte dafür den gesamten TCP/IP-Stack des Linux-Kernels durch Code von NetBSD aus. Diese eigenwillige Lösung animierte Fritz Elferts, den alternativen ISDN-Treiber zu entwickeln: ISDN4Linux. Dieser Code ist seit dem Kernel 1.3.69 in Linux enthalten. Mit der raschen ISDN-Integration bewies Linux, dass es zukunftsfähig ist. Durch die Entwicklungs- und Entwicklerstruktur war das wichtigste freie Software-Projekt in der Lage, auf „lokale Besonderheiten" wie ISDN flexibel zu reagieren. Andere wichtige deutsche Projekte sind Mgetty+Sendfax von Gert Döring, der Logical Volume Manager LVM von Heinz Mauelshagen, KDE und große Teile des Xfree86-Projekts. Deutsche Firmen, die Linux weiterbrachten In der Steinzeit von Linux konkurrierten eine Hand voll Distributionen um den noch recht übersichtlichen deutschen Markt. Sie bestanden anfangs aus wenigen, später aus ganzen Kartons voller Disketten und hießen DLD von Delix, SuSE-Linux, LST, Unifix oder LSD. Erst die CD-basierten Distributionen und schnelle Internetverbindungen eröffneten einen lohnenden Markt, der schon bald nach dem Motto „Die Revolution frisst ihre Kinder" bereinigt wurde. Nur


--------------------------------------------------------------------------------------SuSE konnte sich etablieren. Trotzdem drängte viel versprechender Nachwuchs, zum Beispiel die französische Distribution MandrakeLinux, auf den Sektor. Kommerzielle Linux-Software ist geprägt von deutschen Namen. An erster Stelle stand die mittlerweile in Sun eingeflossene Hamburger Firma StarDivision, die mit StarOffice einen wesentlichen Beitrag leistete, Linux auf Desktop-PCs hoffähig zu machen. Die Software AG näherte sich mit der leistungsfähigen SQL-Datenbank Adabas D. Erst als die deutsche Firma SAP wegen großer Kundennachfrage ihr R/3 auf Linux portierte, zogen die anderen Datenbankhersteller reumütig nach. Nicht zu vergessen zwei weitere Produkte: Vshop und ArCad. Ein frühes und spektakuläres Zeichen setzte in Deutschland zudem der Autoverleiher Sixt mit seinem Umstieg auf Linux im Jahr 1996. Das Anwenderhandbuch, das Linux-Magazin und das LinuxCluster-Projekt Bereits 1992 haben deutschsprachige Fachzeitschriften, die HeiseMagazine iX und et, ausführlich und positiv über Linux berichtet. Es ist dem journalistischen Spürsinn von Ulrich Schmitz und Axel Kosel, später dem Engagement von Harald Milz, zu verdanken, dass eine breite Fachöffentlichkeit von Anfang an über die Linux-Entwicklung unterrichtet war. Auf Anregung der Fachbuchhandlung Lehmanns Berlin wurde das 1992 entstandene Linux-Anwenderhandbuch 1993 regulär herausgegeben. Die Autoren Martin Müller und Sebastian Hetze gründeten eigens den Verlag LunetIX, nachdem einschlägige Fachverlage die Veröffentlichung abgelehnt hatten. Obwohl - oder gerade weil - die Quellen vom Linux-Anwenderhandbuch unter der GPL im Internet verteilt wurden, wurde der Titel schnell zum Bestseller unter den Computerbüchern. Der Buchhandel wurde auf das Thema Linux aufmerksam und avancierte schnell zum Vertriebskanal für Linux-Distributionen. Im Oktober 1994 wurde in München die erste Ausgabe des LinuxMagazins herausgegeben. Damit gab es wenige Monate nach


------------------------------------------------------------------------------------dem Erscheinen des Linux-Journals in den USA auch ein deutschsprachiges Magazin, das sich auf das Open-Source-Betriebssystem konzentrierte. Ohne Venture Capital und Werbeetat war die neue Zeitschrift anfangs ein Insidertipp, nur die bereits für Linux sensibilisierten Fachbuchhandlungen führten das neue Magazin. Mit wachsender Linux-Gemeinde verbesserte das Linux-Magazin auch den professionellen Zuschnitt, ohne den Draht zur Anwender-Gemeinde zu verlieren. Vom ersten Heft an hat sich die Zeitschrift als Organ der Linux User Groups verstanden. Die Liste der Gruppen und Treffen hat heute einen Umfang von 170 Einträgen. Die von den Usergroups ausgehenden Aktivitäten finden ihr Echo im Linux-Magazin, Einsteiger werden mit dem zweiten Heft der Linux New Media AG, dem LinuxUser mit praktischen Tipps unterstützt. Viele Usergroups veranstalten Installationspartys, bei denen mit Unterstützung erfahrener „Linuxer" Installation und Konfiguration der aktuellen LinuxDistributionen vorgenommen werden. Ein gutes Beispiel für das weit reichende Engagement des LinuxMagazins in der Community ist das Linux Cluster Projekt. Es wurde von Tom Schwaller, dem damaligen Chefredakteur, unter dem Titel „CLOWN; Cluster of Working Nodes" ins Leben gerufen. Ziel war, anlässlich der WDR-Computemacht 1998 medienwirksam die Leistungsfähigkeit von Linux unter Beweis zu stellen. Dazu wurde ein Beowulf-Cluster aus 512 Linux-Rechnern aufgebaut und live im Fernsehen vorgeführt. Mit einer Vorbereitungszeit von nur sechs Wochen sollte der größte Cluster ins Guinness-Buch der Rekorde eingehen. Durch vereinte Anstrengung der Linux User Groups und der Sponsoren wurden am Vortag der Veranstaltung über 550 Rechner in den Räumen des Informatikbereichs der Uni Paderborn zu einem „Supercomputer" vernetzt. Hewlett-Packard stellte ein mit Gigabit Glasfaser vernaschtes Netz aus zwölf Switches bereit, Siemens sorgte für die Energieversorgung und die Freiwillige Feuerwehr für die zur Kühlung empfohlene Entlüftung der Räume. Der Cluster demonstrierte seine Funktion, indem er animierte Filmsequenzen live erzeugte. Verschiedene Benchmarks wurden ausgeführt, unter anderem ein für die Alpha-Architektur optimier-


--------------------------------------------------------------------------------------ter Linpack Benchmark. Wäre der Cluster fest installiert und dauerhaft produktiv geblieben, härte er es allein mit den 48 getesteten Alphas ins Mittelfeld der Top 500 Supercomputer gebracht. Die Linux-Kongresse 1994 fand in Heidelberg der erste Linux-Kongress statt. Veranstalter waren die German UNIX User Group (GUUG); LunetIX, der Julius Springer Verlag und JF Lehmanns. Ursprünglich war er als große Party geplant, auf der sich die Linux-Hacker aus aller Welt zum ersten Mal im „wirklichen Leben" treffen sollten. Der Einladung der Organisatoren folgten neben Linus und Tove aus Finnland auch Remy Card aus Frankreich, Alan Cox und Stephen Tweedie aus UK, Theodore Tso, Drew Eckhardt und Eric Youngdale aus den USA. Aus Deutschland waren als Referenten unter anderem Olaf Kirch, Dirk Hohndel und Gert Döring dabei. Im Zentrum der Diskussion standen Dateisysteme, die Fortschritte von Net3, die Binärkompatibilität zu anderen Unix-Systemen mit iBCS2 und das Wine Projekt. Der zweite Linux-Kongress 1995 in Berlin stand im Zeichen der Portierung von Linux auf Alpha, Motorola 68k und MIPS. Die Umstellung auf das ELF-Binärformat war ein bewegendes Thema für Anwender und Distributoren. Die herausragende Neuigkeit des dritten Kongresses 1996 in Berlin war die Präsentation des Multiprozessor-Kernels durch Alan Cox. Als offizieller ISDN-Treiber wurde ISDN4Linux von Fritz Eifert vorgestellt. Kalle Dalheimer, damals noch Entwickler bei StarDivision in Hamburg und verantwortlich für die Portierung von StarOffice für Linux, berichtete über die Portierungspraxis. Beim vierten Kongress in Würzburg 1997 war neben der Premiere von Eric Raymonds „The Cathedral und the Bazaar" und Matthias Ettrichs Präsentation des KDE-Desktops noch Dave Millers Spare Port für Linux spektakulärer Höhepunkt. Das wachsende Interesse der Industrie an Linux verdeutlichte das „Linux High Availibility Project" von Harald Milz.


------------------------------------------------------------------------------------Der Linux Kongress hat auch heute seinen guten Ruf als Entwicklertreffen in Europa behalten, auch wenn seine internationale Bedeutung durch US-amerikanische Großveranstaltungen geschmälert wurde. LinuxTag und LinuxPark Von der Projektgruppe Linux der UNIX-AG Kaiserslautem organisiert, wurde im Jahr 1996 eine außerordentlich erfolgreiche Veranstaltungsreihe aus der Taufe gehoben: der LinuxTag. Der Name täuscht, handelt es sich doch um eine mehrtägige Veranstaltung. Charakteristisch für den LinuxTag ist die Nähe zu den Open-SourceProjekten. Die Projektgruppe Linux ist eine der ältesten Linux User Groups in Deutschland. Mit einem umfangreichen Vortragsprogramm für Anwender und Anwendungsentwickler und einer wachsenden Zahl von Ausstellern ist der LinuxTag heute die größte Linux-Veranstaltung in Deutschland. Mittlerweile hat er die Kapazitätsgrenze der Universität Kaiserslautem gesprengt. Im Jahr 2000 zog er unter dem Motto „where .com. Meets .org" in der Messe Stuttgart fast 100 Aussteller und 17.000 Besucher an. Einen weiteren Schwerpunkt setzt die Linux New Media AG mit dem Linux-Magazin seit 1999: Auf der Computermesse SYSTEMS wurde ein LinuxPark ins Leben gerufen: Die Community und knapp 100 Linux-Firmen präsentieren dabei eindrucksvoll ihre Projekte und Produkte. Erstmals wurde damit dem Thema Open Source auf einer internationalen Businessmesse mit einem eigenen Bereich und eigenem Forum Rechnung getragen. Die vielen Facetten der Entwicklung von Open-Source-Software fügen sich zum großen Bild einer faszinierenden Bewegung zusammen. Glyn Moody füllt dieses Bild mit Farbe. Das vorliegende Buch ist kein Rückblick, es ist die gelungene Dokumentation eines lebendigen Prozesses. Sebastian Hetze Vorstand der Linux Information Systems AG

Stichwortverzeichnis

386-Minix 67

A ACC Bookstore 143,312 Adabas D Datenbank 139 AI-Lab 32, 28, 195,207 AIX25 Aldama, Arturo Espinosa 444 Allchbi,Jim39i Allison, Jeremy 386 All man, Eric 168,232 Alpha 153, 160 Alpha-Port 163 Aitiazon.com 192 Amiga 150 Amiga-Mikrocomputer 106 Amoeba 74, 445 Amsterdam Compiler Kit 36

Andreessen, Marc 266 Angst 148 AOL 282, 416 Apache 177, 181, 255, 290, 348, 376 Apax Partners 326 Apple 150, 413 -Macintosh 16 ARPAnet 167, 171 Arroganz 22, 53, 56,189 Assembler-Sprache 19 AT8T 13, 25,50,93, 196 -Klage 102 -Quellcode 68 Atari 150 Augustin, Larry 141, 234, 238, 400

B B2B-Exchanges 344


------------------------------------------------------------------------------------Barry, James 311, 348 Bash40 Basic 19 Bastok, Frederic 431 Beliiendorf, Brian 176, 232, 278, 293, 297 Bell Labs 25 Benchmark Partners 305 Ben-Halim, Zeyd M. 298 Bemers-Lee, Tim 16, 256 BIND 255 Boich, Michael 373 BoIzem,Mark 133, 140, 209 Bostic, Keith 208 Brooks, Fred 26 Bumout 248

C C Compiler 39, 36 Caccamo, Wayne 308, 347 Caldera 137,165, 309, 318, 323,413 Carr, Eric 376 Case, Steve 282 CERN 17, 176 Charles, Philippe 296 Clark, Jim 261, 265 Clustering 324 Comdex 145 Compaq Computer Corporation 311, 410 Compatible Time-Sharing System CTSS 29 Computer Associates 298 Connolly, Dan 256 Convex 256 Copyleft 43 Corel, Michael Cowplant 415 Cox.Alan 100, 103, 105, 112, 117,195,251, 336, 429 Cutler, Dave 16,399 CVS-System 242 Cygnus 345, 372 -Solutions 331

D D'Cmze, Patrick 144 DARPA 171, 184 Dawes, David 91 Dawson, Terry 101 De Icaza Amozumta, Miguel 363, Debian 124, 234 DECUS 148 Delivermail 169 Dell 311, 348 Digital 25 -PDP-Minicomputer 29 Ditzel, Dave 227 Domino Go 289 DOS 199 -Basis 16 Dougan, Cort 243 Duopol Wintel 228 Duval, Gael 430 DVD-Software 423

E Eazel 373 Eckhard, Drew 80, 88 ECos 418 Eich, Brendan 280 EIT 177 Ellison, Larry 300 Emacs 29, 37, 39, 199, 240, 426 Eng,Eirik359 Ettrich, Mattias 355 Evans, Bruce 57, 74 Ewel, Jim 388 Ewing, Marc 134, 314

F Fetchmail 209 Fintronic 141 Flagship 133 Foresight-Tnstitute 234 Free Software Foundation (FSF)40


--------------------------------------------------------------------------------------Free Software Foundation 127 Friedman, Nat 372 FvK 112

G Gabelung 139 Garloff, Kurt 243 Gates, Bill 10, 15, 264, 300, 311 General Electric 25 Ghostscript 324 Gilmore, John 333 GIMP-Projekt 353 GN0ME365, 398, 411 GNU Emacs 87 -Pro-Plattform 427 Goethe, Johann Wolfgang 216 Greenblatt, Richard 31 Greylock 305

H Hahn, Eric 264, 288 Hall, John "Maddog" 161, 336 Hamois, Michael 241 Hecker, Frank 268, 348 Helix GN0ME 372 Henkel-Wallace, David 333 Hertzfeld, Andy 373 Hewlett-Packard [HP] 25, 307 High Availability 397 Hobbyist 10 Hohndel, Dirk 92 HotWired 176, 181,293 HP 348 HP-UX 25 HTML 279 -Modus 258 HTTP 179, 258 Hughes, Phil 142

I IBM 25, 288, 290, 309, 348, 35B, 369 -PC 49 IETF 178 IMG 259 Incompatible Time-Sharing System, ITS29 Intel 311, 315, 326, 348 - Pentium 228 -Prozessor 49 Internet- Connection Server 289 - Exporer 263

J Java 17,265,343 Jeeves 173 Jikes 296 Jobs, Steve 256, 414 Jolitz, Bill 95 - Bill und Lynne 93 Joy, Billy 172 Junius, Martin 123

K Kerberos 435 Kimball, Spencer 351 Kirch, Olaf 100, 102 Knuths, Donald 216

L Larry McVoy 195 Le Morois, Jacques 431 Lemmke, An 63 Levy, Steven 28 Linux Journal 124, 131, 142, 149 Linux News 53, 65, 66, 76, 93, 95, 298 Lisp 30, 37 - Machine Incorporated 31


------------------------------------------------------------------------------------LMI 32 Lonnroth, Magnus 300 Love, Ransom318 Lu, H. J. 123 LyX 356

M MacDonald, Peter 123, 131, 325 Manchester Computing Centre (MCC) 122 Mandrake 430 Mares, Martin 244 Maschinencode, binärer 26 Mattis, Peter 351 McArthur Foundation 45 McCool, Rob 174 McNealy, Scott 197 McVoy, Larry 250, 335, 394, 437 Metzenheim, Bill 94 Microsoft Visual Basic 15 - Windows 16 --NT 153, 158 - 3.5 105 -Imperium 11 MicroVAX-System 23 Mikrokemel 41, 50, 72 Militärdienst 22 Miller, Cliff 321 Miller, Dave 231, 242, 251, 336, 429,150 Mills, Steve 293 Mindcraft 383 Minix 48, 50, 52 -Newsgroup 84, 7i MIT 25, 36, 67 Mockapetris, Paul 173 Moglen, Eben 436 Molnär, Ingo 336, 394 Monni, Tove 161 Mosaic 257 Motif354 Mozilla 269, 276, 278, 287, 295

MS-DOS 49, 53, 84 Murdock, lan 123

N Nall, John 75 Nash, Mike 391 NCSA 176, 257 Net--2 Code 108 -Bench 389 -BSD 118 -scape 180, 280, 284, 287, 315 -work File System 85 Netiquette 75 New Hacker's Dictionary 204, 214 NFS 97 NLP277 Noorda 138 Nord, Haavard 359 Novell 137, 348

0 O'Reilly Et Associates 143, 193, 347 O'Reilly, Tim 231 Open Source 10 Oracle 299, 348 Ousterhout, John 341

P Pacific HiTech 309, 321 Palmisano, Sam 406 Paquin, Tom 279 PDP-10 34 Perens, Bruce 127 Perl 182, 187, 191, 224, 232, 255, 446 Petcrson, Christine 234 Photoshop 352 Picasso, Pablo 210 Pinguin 156 P0P 8I Popcüent 208


--------------------------------------------------------------------------------------Posix 59 Prince of Persia 81 Python 445

Q Qt359

R RAID-System 364 Raymond, Eric 233, 236, 248, 278, 336,361 Red Hat 134, 306, 314, 331, 372, 394,429 Reden 148 Richter, Adam 132 Ritchie, Dennis 26 Roell, Thomas 90 Ross, Biro 103 Rossum, Guido van 445 Rubini, Alessandro 101

S Saffords, Dave 123 Salzenberg, Chip 192 Samba 377, 380, 409 Santa Cruz Operation 49 SAP 304, 309 SCSI-Treiber 68 -System 114 SDC 184 Sendmaii 171,255,337 SGI 311, 397 Shan, Yen-Ping 290 Shareware 65 Shell 40, 64, 186 Shields 297 Sicherheit 398 Sifry, Dave 344 Silicon- Graphics, Inc. 261 -Valley 164, 230 Simputer 443

Sinclair--QL 20, 92 -ZX-81 117 Slackware 130 Sladkey(-) 85 -Rieh 81, 104 SLS 130, 135 Solaris 25 SourceXchange 348 Sparks,Bryan 137, 165,318 Spektrum 21 Stallman[-) 126, 160, 181, 202, 236 -Murdock 130 -Richard 27, 64, 70, 88 Star Trek 242 Sun(-) 25, 141, 196, 265,333, 342, 348,377 -Sparc(-) 150, 152 -Station 141 SunOS 60 SuSE 309, 325 SVLUG 238 Symbolics 32 Symmetrie Multi-Processor (SMP)

T Taekwondo 213 Tanenhaum, Andrew 36,48,50,55,71, 79, 108, 445 Task Switching 54 Tel 342 TCP/lP-Codes 119 TCP/IP-Standards 113 TEC0 29 TEX 218 Thau, Robert 179 ThinkPad-Notebooks 403 Thompson, John M. 292 Thompson, Ken 26,76 Tible, Bud 373 Tiemann, Michael 332, 336, 372


------------------------------------------------------------------------------------TkWWW342 Torvalds, Patricia Miranda 161 Transmeta 227 Tridgell, Andrew 377 Trollteeh 359 Ts'o,Ted 114, 195, 225, 231, 246, 336 TurboLinux 348 Tweedie, Stephen 117, 231, 336, 448

-2000 11,388 -3.0 15 -3.1 15,82 - 95 369 -NT23, 375 -NT5 11 Wirzenius 21f., 121 Wiizenius, Lars 18, 47, 128 Wladawsky-Berger, Irving 404 Würzburg 231

U

X

UCB94 Ultrix 25 Uytterhoeven, Geert 241

Xanadu-Projekt 205 XEmacs 426 Xenix 49 Xerox 322 Xfree86-Gruppe91, 129 XML 344 X-Window-System 359 X-Window-Version 268

V VA Linux 327, 331 VA Research 141,234 Valloppilli, Vinod 12 Van Kempen 104 Vaughan-Nichols, Steven 376 VC-20 53 VC-20-Mikrocomputer 18, 163 Vera, James 142 Version--0.01 97, 164 - 0.02 256 -0.12 - 0.95 96 - 0.9B 1OO, 119 - 1.0 119 - 2.0 164 Vger 241 Viral Marketing 274 Virtual Memory 68 Vixie.Paul 174,232 VMS 16

W Wall 225

Wall, Larry 181, 215, 232 WebBench 389 Weiner, Bruce 383 Welsh, Matt 82 Wexelblatt, David 90 Wicca-Religion 213 Windows-

Y Yacc 35 Yahoo! 142, 173, 181, 192, 327, 421 Yale, Linus 18 Yggdrasil 132, 206, 334 Young, Bob 142,311,319,336,372

Z Zawinski 278, 283 Zawinski, Jamie 240, 268 Zborowski, Orest 89

Die Software Rebellen

Die Rebellen

Die Rebellen

Die Rebellen

Die Rebellen

Die Rebellen

Die Rebellen von Trakarat

Die Mission der Rebellen

Die Königin der Rebellen

Die Rebellen von Ordardor

Die Rebellen von Trakarat

Die Rebellen von Tuglan

Die Rebellen von Trakarat

Die Geliebte des Rebellen

Die Knigin der Rebellen

Die Rebellen von Terra

Die Rebellen von Ordardor

Die Rebellen von Ordardor

Die Rebellen von Escalian

Die Rebellen von Traversan

Die Mission der Rebellen

Die Robot-Rebellen

Die Robot-Rebellen

Die Geliebte des Rebellen

Die Rebellen von Hetossa

Die Mission der Rebellen

Die Rebellen von Traversan

Die Rebellen von Hetossa

Die Rebellen von Hetossa

Die Rebellen von Escalian

Die Rebellen von Tuglan

Die Software Rebellen

Die Rebellen

Die Rebellen

Die Rebellen

Die Rebellen

Die Rebellen

Die Rebellen von Trakarat

Die Mission der Rebellen

Die Königin der Rebellen

Die Rebellen von Ordardor

Die Rebellen von Trakarat

Die Rebellen von Tuglan

Die Rebellen von Trakarat

Die Geliebte des Rebellen

Die Knigin der Rebellen

Die Rebellen von Terra

Die Rebellen von Ordardor

Die Rebellen von Ordardor

Die Rebellen von Escalian

Die Rebellen von Traversan

Die Mission der Rebellen

Die Robot-Rebellen

Die Robot-Rebellen

Die Geliebte des Rebellen

Die Rebellen von Hetossa

Die Mission der Rebellen

Die Rebellen von Traversan

Die Rebellen von Hetossa

Die Rebellen von Hetossa

Die Rebellen von Escalian

Die Rebellen von Tuglan

Recommend Documents