Linux wird 30: Erfolgsfaktoren damals und heute

Inhaltsverzeichnis

Herzlichen Glückwunsch zum 30sten, Linux! Am Freitag vor dreißig Jahren hast du das Licht der Welt erblickt, nachdem Linus Torvalds dein Erscheinen zuvor schon am 25. August in Aussicht gestellt hatte. Einige Ecken und Kanten aus deiner Frühzeit hast du dir bis heute bewahrt. Mach dir nichts daraus, wenn sie dir jemand vorhält: Kritiker erkennen oft nicht, dass einige von ihnen der Grund für deinen Siegeszug sind. Zum Jahrestag bietet es sich daher an, einige deiner charakteristischen Eigenschaften näher zu betrachten.

Zur richtigen Zeit das passende Produkt

Der Hauptfaktor für den Erfolg des Linux genannten Betriebssystemkerns sind eindeutig die vielen Helferinnen und Helfer. Indem sie Linux für ihre jeweiligen Einsatzzwecke immer wieder ein klein wenig verbessert haben und kontinuierlich weiterverbessern, konnte es nach und nach Konkurrenten ausstechen und letztlich so gut werden, dass selbst Microsoft den Kernel von Torvalds für einige Dinge nutzt.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes Video (Kaltura Inc.) geladen.

Videos immer laden Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Kaltura Inc.) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Die ersten Mitstreiter lockte der damals erst 22-jährige Linus Torvalds schnell an, nachdem er Linux 0.0.1 am 17. September 1991 veröffentlicht hatte. Der rege Zulauf lag vor allem am fruchtbaren Boden, auf den Linux fiel: Abgesehen vom bewusst beschränkten Lehrsystem Minix gab es nichts Vergleichbares für Intels 386er-Prozessoren, die sich damals breit machten.

Torvalds hätte Linux nicht einmal begonnen, wenn es den FreeBSD- und NetBSD-Vorläufer 386BSD schon gegeben hätte. Der erschien jedoch erst im Frühjahr 1992 – ungefähr ein Jahr also, nachdem Torvalds mit Linux angefangen hatte.

Die Software-Welt von heute hätte daher leicht ganz anders aussehen können. Die Frage ist allerdings, ob ein von BSD abgeleiteter Kernel tatsächlich den durchschlagenden Erfolg von Linux gehabt hätte. Denn während BSD-Ableger meist eine liberale Lizenz nutzen, wählte Torvalds eine, die beim Weitervertrieb zur Herausgabe aller Modifikationen verlangt.

Open Source, wenn auch nicht von Anfang an

Torvalds beging allerdings einen Fehltritt, als er Lizenzbedingungen für die erste Version formulierte. Sie waren zwar knapp, enthielten aber dennoch etwas, das ihnen den Stempel "Open Source Software" verwehrt hätte.

Konkret handelte es sich dabei um eine Klausel, die untersagte, Gebühren für den Weitervertrieb des Codes zu nehmen, wie es einige Dienstleiter damals taten. So eine Einschränkung widerspricht allerdings den Grundbedingungen der Definition von "Open Source", wobei die erst Jahre später im Fahrwasser des Linux-Erfolgs entstand.

Software, die so eine Hürde reißt, findet heute schwer helfende Menschen; insbesondere das kommerzielle Umfeld hält sich dann zurück. Damals schreckte der Fehltritt weniger. Dennoch rieten schon bald die ersten Mitstreiter zum Wechsel auf eine ausgeklügeltere Lizenz – nämlich auf Version 2 der GNU Public License (GPL).

Die Szene um freie unixoide Betriebssysteme kannte die GPLv2 bereits von den vielen Werkzeugen des GNU-Projekts, die nötig waren, um mit dem Linux-Kernel ein Betriebssystem zu bauen – und die heute noch wichtig sind, auch wenn ihre Bedeutung schwindet. Torvalds stimmte mit der Idee überein. Bei Linux 0.12 kündigte er den Lizenzwechsel auf die GPLv2 an, den er Ende 1992 bei Version 0.99 vollzog.

Lizenz zwingt zur Offenheit

Eine Sache hatten allerdings schon Torvalds erste Lizenzbedingungen mit der noch heute verwendeten GPLv2 gemein: Sie verpflichteten jedermann dazu, beim Vertrieb des Betriebssystemkerns auch den zum Bau genutzten Quellcode bereitzustellen. In den Anfangstagen war das hilfreich, aber auch nicht schrecklich entscheidend. Denn wer an Linux schraubte, um es für seine Anforderungen besser zu machen, übermittelte diese Änderungen ohnehin oft aus Idealismus von sich aus an Torvalds, damit er sie in neue Versionen seines Betriebssystemkerns integrierte.

Wichtiger wurde der Aspekt in den Folgejahren: Im weiteren Verlauf der Neunziger begannen nach und nach immer mehr Firmen, Geld mit Produkten zu verdienen, in denen Linux steckte. So mancher dieser Konzerne sah keinen Sinn darin, die Änderungen, mit denen er Linux für seine Einsatzzwecke aufgebohrt hatte, im Anschluss auch bei Torvalds zur Integration einzureichen. Kein Wunder, denn Torvalds und seine Mitstreiter verlangen bei der dabei durchgeführten Qualitätskontrolle häufig Verbesserungen, die Arbeit beim Einreichenden verursacht. Zudem sehen Firmen beim "Upstreamen" Wettbewerbsvorteile gefährdet, denn schließlich erhalten Konkurrenten die hauseigenen Modifikationen mit neuen Linux-Versionen dadurch frei Haus.

Andere Entwickler helfen aus

Noch heute findet sich so eine Denke bei manchen Firmen – insbesondere bei jenen, die mit Linux erst warm werden oder in Märkten mit kleinen Verdienstspannen agieren. Die Pflicht zur Bereitstellung des Quellcodes beim Weitervertrieb hilft dem Betriebssystemkern aber nach wie vor: Jeder mit genug Motivation kann den Code aufarbeiten und in Linux einbringen.

Genau das machen Hobbyentwickler oder Programmierer anderer Firmen immer mal wieder. Das verursacht oft erhebliche Arbeit und ist daher nicht ganz alltäglich, passiert aber häufig genug, um Linux einen Vorteil zu verschaffen. So ist es vor allem unabhängigen Entwicklern zu verdanken, dass Torvalds' Kernel dieser Tage viele Raspberry Pi von Haus aus unterstützt, denn die Foundation hinter den Kleinstcomputers hat sich lange gar nicht oder nur wenig darum geschert, ihre Modifikationen in Linux zu integrieren.

Tricksereien scheitern

Dieser Vorteil zeigt sich insbesondere im Vergleich zu liberal lizenzierter Software, wie sie dieser Tage gerade bei Großprojekten wie Kubernetes oder OpenStack en vouge ist. Auch BSD-Derivate sind so lizenziert. Firmen können daher dort ihre Anpassungen unter Verschluss halten und ein Aufgreifen durch andere verhindern, wie es die GPLv2 ermöglicht. Sie schafft so einen Rahmen, durch den beispielsweise die auf Googles Android basierenden Smartphone-Betriebsysteme LineageOS und dessen Vorläufer CyanogenMod entstehen konnten.

Natürlich haben einigen Firmen versucht, die Anforderungen der Lizenz zu umgehen. Gerade nach der Jahrtausendwende wurden einige von ihnen vor den Kadi gezerrt. Die meisten mussten am Ende klein beigeben. Dadurch sind große Ökosysteme entstanden, in denen mittlerweile einiges an Geld fließt. Ein Paradebeispiel dafür: Das Linux-basierte Router-Betriebssystem OpenWRT.

Lizenz führt Helfer an Linux heran

Die vielen Helferinnen und Helfer und der auf ihrer Mitarbeit fußende Erfolg sind aber nur zum Teil der Lizenz zu verdanken. Denn viele Firmen, denen diese anfangs ein Dorn im Auge war, beginnen irgendwann, sich immer mehr in die Kernel-Entwicklung einzubringen. Oft erfolgt dieser Wandel, weil die Firmen sich so die Codepflege erheblich erleichtern. Denn externe Kernel-Modifikationen ständig an neue Linux-Versionen anpassen zu müssen ist aufwendig und dröge. Außerdem bringt eine saubere Integration in Torvalds' Kernel und die Zusammenarbeit mit anderen früher oder später oft komplexere, zuvor unerreichbar scheinende Ziele in Reichweite. Viele Firmen fangen daher sogar an, an anderen Stellen des Kernels mitzuschrauben, selbst wenn sie davon nur indirekt profitieren.

Das Entwicklungsmodell von Linux zwingt Konkurrenten dabei zur Kooperation – etwa bei der Basisinfrastruktur des Kernels oder seiner Treiber, die über die Hälfte des Quellcodes ausmachen. Oft sind das Bereiche, die jeder braucht, die aber niemandem direkt Geld einbringen. Die Kooperation kann Kosten sparen. Zugleich führt sie zu robusten, flexiblen und mächtigen Techniken, die am Ende allen das Leben erleichtern und Linux so gut machen.

Viele machen sogar mit, obwohl sie es gar nicht müssten

Diese und weitere Gründe überzeugen Konzerne mit der Zeit. Das gilt nicht nur für Distributoren wie Red Hat und Suse oder Hardware-Hersteller wie ARM, AMD, IBM und Intel, die alle schon lange mitmachen: Selbst Amazon, Facebook und Google bringen sich dieser Tage stark ein. Die drei schrauben viel an Interna und Techniken für Server herum, denn bei ihren riesigen Rechenzentren sparen kleine Optimierungen schnell die Anschaffung von tausend weiteren Servern. Und hier bringt sie nicht die Lizenz, sondern das bessere Entwicklungsmodell zum Mitmachen: Beim rein internen Einsatz müssten sie ihre Modifikationen schließlich gar nicht veröffentlichen.

Darum stammen dieser Tage weit über achtzig Prozent der in Linux vorgenommenen Änderungen von Entwicklern, die für ihre Arbeit an Linux bezahlt werden. Von denen stammen auch fast alle großen und tiefgreifenden Umbauten. Mittlerweile finden sich nahezu alle Größen der IT-Branche unter den regelmäßig Beitragenden – darunter auch Microsoft. Und dass, obwohl sich diese Konzerne anfangs fast ausnahmslos nicht um die Integration in den Betriebssystemkern geschert oder sie sogar mehr oder weniger vehement zu verhindern versucht haben.

Vorteile und Marktdruck motivieren zur Mitwirkung

Selbst viele konservative, verschlossene Firmen wie Oracle oder Nvidia mussten wenigstens in einigen Bereichen einsehen: Bei Linux mitmachen lohnt sich, weil es Unkosten reduziert oder den Umsatz steigert. Nvidia schafft es dieser Tage sogar immer in die Top 20 der beitragenden Firmen, bei der als Maßstab die Zahl der Commits bei den im letzten Jahr veröffentlichten Linux-Versionen dient. Das hat der Konzern vor allem durch die Mitarbeit am Code für Tegra-Prozessoren und Mellanox-Produkte geschafft.

In einem anderen Marktsegment wirkt Nvidia allerdings partout nicht an der Entwicklung mit: Bei Grafikkarten und Rechenbeschleunigern für PCs und Server setzt der Konzern auf proprietäre Linux-Treiber. Die Firma kann sich das dort leisten, weil sie in diesem Bereich extrem gut aufgestellt ist beziehungsweise dominiert. Die Treiber funktionieren recht ordentlich, haben aber allerlei Tücken bei Installation und Pflege, die bei manchen Nutzern für Frust und Ärger sorgen. Einige Linux-Anwender meiden Nvidias Grafikprozessoren daher wie der Teufel das Weihwasser.

Schnittstellen für extern gewartete Treiber fehlen

Die Probleme mit solchen Treibern werden durch eine gerne kritisierte Eigenart von Linux verursacht: Ihm fehlen von jeher Schnittstellen für extern gewartete Treiber. Die proprietären von Nvidia docken daher über ein Modul-Interface an, das für etwas ganz anderes eingeführt wurde: Zum Modularisieren des Betriebssystemkerns selbst, um die auf einem Rechner nicht verwendeten Teile nicht laden zu müssen.

Aus Sicht zentraler Linux-Macher sind diese Andockpunkte für Module ein internes Interface. Sie ändern es daher bei der Weiterentwicklung des Kernels immer mal wieder, um neue Features zu ermöglichen oder Fehler zu korrigieren. Dabei passen sie auch die im Kernel enthaltenen Treiber an die neue Ordnung an, um nicht auf Abwärtskompatibilität achten zu müssen – das würde den Fortschritt hindern, da es viele Umstände macht und einengt. Die Macher externer Treiber müssen ihren Code daher immer wieder nachjustieren, damit er mit neuen Linux-Versionen arbeitet.

Der Spielraum proprietärer Treiber schrumpft

Hinzu kommt, dass alte Andockpunkte bei den Umbauten manchmal wegfallen. Viele neue dürfen proprietäre Treiber zudem nicht nutzen. Dies untersagen die Entwickler über die 2003 aufgekommene Schnitstellendeklaration "EXPORT_SYMBOL_GPL", weil sie nicht wollen, dass unfreie Linux-Treiber auf den von ihnen geschriebenen Kernel-Code zurückgreifen. Das passiert zwar nur schleichend, engt proprietäre Treiber wie den von Nvidia aber mehr und mehr ein.

Diese Entwicklung könnte Nvidia früher oder später dazu zwingen, zumindest teilweise auf quelloffene, im Kernel gewartete Treiber umzusatteln. AMD hat den Wechsel dorthin schon 2007 begonnen und hat den Ansatz seit einigen Jahren gut im Griff. Die Strategie, proprietären Treibern Steine in den Weg zu legen, zahlt sich für die Linux-Macher mittlerweile auch an anderer Stelle aus: In der Embedded-Welt mit ARM-Prozessoren gibt es einen schleichenden Trend hin zu quelloffenen Kernel-Treibern, nachdem proprietäre Grafiktreiber dort bislang fast überall an der Tagesordnung waren.

Ursache für das Scheitern auf dem Desktop?

In Internetforen werden die Hürden für proprietäre Treiber und das Fehlen stabiler Treiberschnittstellen gerne als riesiges Manko von Linux angesehen und oft als Hauptgrund dargestellt, warum "Linux auf dem Desktop" ein Nischendasein fristet. Die Kritiker übersehen dabei oft: Eben diese Eigenschaften zusammen mit der Lizenz sind die Hauptgründe, warum Linux überhaupt so gut ist. Denn sie haben einige Individuen und viele Firmen dazu motiviert, ihre Treiber und andere Modifikationen in Linux einzubringen.

Für einen vermeintlichen Vorteil bisherige Prinzipien aufzugeben, denen letztlich auch die vielen Helfer zu verdanken sind, hätte fatale Folgen für die künftige Entwicklung und Bedeutung von Linux. Ohnehin scheint es weit hergeholt, dass stabile Treiber-Schnittstellen so entscheidend für den Erfolg von Linux auf Desktop-PCs wären. Denn es geht auch ohne, wie der Erfolg von Android und ChromeOS zeigt. Oder auch der Erfolg der ersten Netbooks, auf denen Linux dominierte, bis Microsoft es mit einigen Manövern ins Abseits drängen konnte.

Alles Gute zum Dreißigsten!

Zum 30sten sei daher gesagt: Bleib Dir treu Linux, und gib Deine positiven Eigenarten nicht auf. Mit einigen von ihnen hast Du schließlich die IT-Welt revolutioniert – und dabei über den Erfolg bei Android und Server mehr Leute erreicht, als Du es über Desktops je hättest tun können. Und ich bin sicher: Über Chromebooks und ähnliche Konzepte wirst Du Dir in den nächsten 30 Jahren auch noch einen größeren Anteil auf den Schreibtischen sichern.

(ovw)