35 Jahre Linux: Die Erfolgsstory von Open Source

Aus einem Hobbyprojekt für 386er-Rechner ist binnen 35 Jahren ein Fundament der digitalen Infrastruktur geworden. Fünf Open-Source-Unternehmen erklären, warum offener Code längst kein Nischenthema mehr ist – und weshalb Souveränität, Sicherheit und KI die Debatte heute prägen.

Am 17. September 1991 erschien Linux 0.01. Die erste Version war klein, unfertig und für einen engen Kreis technisch versierter Menschen gedacht. 35 Jahre später läuft Linux in Rechenzentren, auf Routern, in Fahrzeugen, auf Entwicklungsrechnern und in einem großen Teil der Cloud-Infrastruktur. Das Jubiläum ist deshalb mehr als Nostalgie für Terminal-Fans: Es erzählt, wie aus frei einsehbarem Code ein tragfähiges Geschäftsmodell und ein politisches Thema geworden ist.

Die Frage hinter dem Geburtstag ist erstaunlich aktuell: Wie verdient man Geld mit Software, die sich lesen, verändern und weitergeben lässt? Vertreter von SUSE, Univention, KIX Service Software, Stackable und Nextcloud sehen die Antwort nicht in künstlicher Knappheit. Bezahlt wird für Betrieb, Support, geprüfte Versionen, Integration, Know-how und die Freiheit, bei Bedarf den Anbieter wechseln zu können.

Dieses Bild wurde komplett mit KI generiertProvideropenaiModellgpt-image-2PromptUse case: photorealistic-natural Asset type: featured editorial image for a German technology magazine article about 35 years of Linux and Open Source. Primary request: a real, candid editorial photograph of three European IT professionals collaborating around a compact modern server rack and one small workstation in a bright industrial coworking space. Scene/backdrop: real server hardware, cable management, neutral concrete and metal surfaces. Style/medium: authentic professional magazine photography, not staged, slight imperfections. Composition/framing: wide landscape 16:9, asymmetric composition, no screen is dominant. Lighting/mood: calm natural cool daylight, technically credible. Constraints: absolutely no visible text, numbers, logos, branded devices, UI, code, watermarks, or artificial holograms. Avoid vintage aesthetics, wooden desks, coffee mugs, notebooks, generic laptop-on-desk compositions, and sci-fi effects.

35 Jahre Linux: Vom Hobby zum professionellen Fundament

Linus Torvalds kündigte sein Projekt im August 1991 in einer Usenet-Gruppe noch als Freizeitbeschäftigung an. Im September folgte Linux 0.01. Wer heute auf dieses Datum schaut, sollte einen Punkt nicht verwischen: Linux ist streng genommen der Kernel, also der Kern eines Betriebssystems. Seine enorme Reichweite entstand erst im Zusammenspiel mit Distributionen, Werkzeugen, Unternehmen und einer Community, die Fehler meldet, Code pflegt und Infrastruktur betreibt.

Genau dort liegt die eigentliche Erfolgsgeschichte. Freier Quellcode bedeutet nicht, dass professionelle Arbeit gratis bleibt. Er verschiebt nur die Leistung, für die gezahlt wird. Statt eines bloßen Nutzungsrechts rücken verlässliche Updates, Support-Zusagen, Sicherheitsprüfungen, Schulungen und der Betrieb komplexer Umgebungen in den Mittelpunkt. Das mag weniger spektakulär klingen als eine Lizenzbox – wirtschaftlich ist es sehr real.

Peter Ganten, CEO von Univention und Vorstandsvorsitzender der Open Source Business Alliance, verortet die Professionalisierung spätestens in den frühen 2000er-Jahren. Enterprise-Subskriptionen hätten gezeigt, dass Unternehmen und Behörden für geprüfte Versionen und belastbaren Support auch im hochpreisigen Segment zahlen. Das ist der Knackpunkt: Offenheit und Verlässlichkeit schließen einander nicht aus.

Wer die technische Seite des Themas verfolgen will, findet bei digital-magazin.de auch eine Einordnung dazu, warum ein Stable-Release des Linux-Kernels für den Alltag von Admins mehr ist als Routine. Gerade diese gepflegten, nachvollziehbaren Veröffentlichungsprozesse machen aus Quellcode eine Infrastruktur, auf die sich Organisationen verlassen können.

Wann der Markt begriff, dass Open Source ein Geschäft ist

Der kulturelle Wandel dauerte länger als die technische Entwicklung. Rico Barth, Geschäftsführer von KIX Service Software, erinnert daran, dass Open Source lange mit Garagenprojekten, freiberuflichen Enthusiasten und vor allem niedrigen Lizenzkosten verbunden wurde. Eine sichtbare Zäsur kam 2018: IBM kündigte die Übernahme von Red Hat für rund 34 Milliarden US-Dollar an; im Juli 2019 wurde der Deal abgeschlossen. Die offizielle Mitteilung von IBM zum Abschluss der Red-Hat-Übernahme machte deutlich, wie strategisch die Branche Hybrid Cloud und Open Source inzwischen einordnet.

Die Summe war kein Beweis dafür, dass jede freie Software automatisch ein Goldesel ist. Sie war aber ein unübersehbares Signal: Mit offenem Code lassen sich hochpreisige Enterprise-Angebote bauen. SUSE, Red Hat, Nextcloud und viele spezialisierte Anbieter verdienen nicht daran, den Zugang zum Code zu versperren, sondern daran, die Nutzung in anspruchsvollen Umgebungen berechenbar zu machen.

Frank Karlitschek, Gründer von Nextcloud, verweist darauf, dass sein 2016 gestartetes Unternehmen nach eigener Aussage noch im Gründungsjahr profitabel war. Bei solchen Modellen kaufen Organisationen nicht das Recht, eine Datei auszuführen. Sie kaufen Zeit, Verantwortung und eine Ansprechperson, wenn ein Update nachts schiefgeht. Mal ehrlich: Genau das ist in der Praxis oft wertvoller als ein proprietärer Lizenzschlüssel.

Die Kehrseite ist unbequem. Große Cloud-Anbieter können erfolgreiche Open-Source-Projekte als Dienst anbieten und von ihrer Infrastruktur profitieren, ohne zwingend im gleichen Maß in die ursprüngliche Entwicklung zu investieren. Manche Hersteller reagieren mit Open-Core-Modellen oder angepassten Lizenzen. Die Debatte darüber ist berechtigt, denn sie berührt die Frage, wie sich Pflege und Weiterentwicklung finanzieren lassen, ohne die Offenheit nur noch als Etikett zu behalten.

Ein Blick auf Amazon Linux und seine technische Ausrichtung zeigt, wie nah Open Source und große Plattformen heute beieinanderliegen. Für IT-Teams heißt das: Nicht nur auf den Quellcode schauen, sondern auch auf Supportmodell, Abhängigkeiten und die Möglichkeit eines späteren Wechsels.

Die Exit-Option ist kein Detail

Stackable-Mitgründer und CPO Sönke Liebau beschreibt einen praktischen Vorteil offener Software: Kundschaft bleibt, weil Produkt und Support überzeugen sollen – nicht, weil eine Lizenz den Ausstieg unnötig teuer macht. Diese permanente Exit-Option setzt Anbieter unter Druck. Sie müssen liefern, sonst gibt es Alternativen.

Das ist auch der Grund, weshalb das alte Preisargument zu kurz greift. Lizenzkosten zählen weiter. Aber digitale Souveränität, Datenkontrolle und die Vermeidung von Vendor Lock-in stehen heute deutlich weiter oben auf vielen Prioritätenlisten. Wer den Code prüfen, selbst betreiben oder einen anderen Dienstleister beauftragen kann, hat mehr Handlungsoptionen, wenn Preise steigen, eine Produktlinie endet oder ein Anbieter seine Strategie ändert.

Torsten Hallmann, Open Source Ambassador bei SUSE, nennt Innovationsgeschwindigkeit, Resilienz und Wahlfreiheit als zentrale Gründe für den Einsatz offener Lösungen. Rico Barth verweist auf die Chance, die Bindung an einen einzigen Hersteller aufzubrechen. Beides klingt abstrakt, wird aber konkret, sobald eine Organisation eine gewachsene Plattform ablösen muss. Migrationen sind selten bequem. Doch die Alternative kann sein, die eigene IT-Planung dauerhaft an die Roadmap eines fremden Konzerns zu koppeln.

Ein Umstieg muss nicht nach dem Muster „alles oder nichts“ ablaufen. Einzelne Workloads lassen sich parallel betreiben und Schritt für Schritt umziehen. Diese Strategie passt besser zu der Realität heterogener IT-Landschaften als der Wunsch nach dem großen Schalter, der an einem Wochenende alles erledigt.

Was IT-Teams aus 35 Jahren Linux mitnehmen können

Für Entscheidungstragende ist die Linux-Geschichte kein Aufruf, morgen jede proprietäre Anwendung zu ersetzen. Sie ist ein Anlass für bessere Fragen. Ist eine Schnittstelle dokumentiert? Können Daten exportiert werden? Gibt es mehr als einen Dienstleister mit dem nötigen Know-how? Und lässt sich ein kritischer Workload notfalls selbst weiterbetreiben? Wer diese Fragen erst stellt, wenn der Hersteller Preise erhöht oder ein Produkt einstellt, hat bereits Zeit verloren.

Open Source ist besonders dort stark, wo Organisationen ihre Anforderungen präzise kennen. Ein Linux-Server im Keller ist noch keine souveräne IT. Ohne Patch-Prozess, Backups, Monitoring und Verantwortliche wird aus Freiheit schnell eine schlecht gewartete Baustelle. Umgekehrt kann ein externer Dienstleister durchaus sinnvoll sein, solange Verträge, Datenwege und Ausstiegsszenarien sauber beschrieben sind.

Das gilt ebenso für die Auswahl von Distributionen und Plattformen. Community-Distributionen können für Entwicklung, Tests und spezialisierte Umgebungen hervorragend passen. In Produktionslandschaften entscheiden jedoch oft Zertifizierungen, lange Support-Zeiträume und die Verfügbarkeit von Fachleuten. Der offene Code bleibt eine Konstante; das passende Betriebsmodell ist eine individuelle Entscheidung.

Dieses Bild wurde komplett mit KI generiertProvideropenaiModellgpt-image-2PromptUse case: photorealistic-natural Asset type: inline editorial image for a German technology magazine article about Open Source, digital sovereignty, and Linux. Primary request: close-up candid photograph of a female IT professional's hands connecting a compact mini PC to a small, neatly organized server shelf during a real technical workshop. Scene/backdrop: metal shelf, ordinary network cables, neutral office environment. Style/medium: authentic professional editorial photography, not staged, natural slight imperfections. Composition/framing: landscape 16:9, close detail shot, subject positioned off-center. Lighting/mood: subtle cool office daylight. Constraints: absolutely no text, numbers, logos, branded devices, readable screens, code, watermarks, holograms, or sci-fi. Avoid wooden desks, coffee mugs, notebooks, and generic stock-photo posing.

Auch die Community ist kein abstrakter Wohlfühlbegriff. Maintainer pflegen Pakete, prüfen Patches, dokumentieren Änderungen und reagieren auf Fehlerberichte. Dieser Aufwand braucht Finanzierung und Anerkennung. Gerade nach dem XZ-Vorfall wurde sichtbar, wie sehr kritische Komponenten mitunter von wenigen Personen abhängen. Unternehmen, die von Open Source profitieren, sollten deshalb nicht nur konsumieren, sondern Supportverträge, Upstream-Arbeit, Sponsoring oder eigene Beiträge als Teil ihrer Risikostrategie begreifen.

Für kleinere Unternehmen kann der Einstieg pragmatisch beginnen: eine interne Anwendung mit offenen Standards, ein lokales Tool für sensible Daten oder ein klar abgegrenzter Serverdienst. Wichtig ist nicht die ideologische Reinheit der Architektur. Wichtig ist, dass Wahlfreiheit nicht nur behauptet wird, sondern technisch und vertraglich vorhanden bleibt.

Ein sinnvoller Realitätscheck beginnt bei der eigenen Abhängigkeit. Welche Anwendungen wären nach drei Monaten ohne Hersteller-Support noch betreibbar? Wo liegen Konfigurationsdaten, Zertifikate und Automatisierungsskripte? Gibt es dokumentierte Wege, um Daten in einem nutzbaren Format herauszuholen? Diese Fragen sind keineswegs nur für Linux-Spezialisten relevant. Sie betreffen CRM-Systeme, Kollaborationsplattformen, Datenbanken und zunehmend auch KI-Dienste.

Open Source kann dabei ein Hebel sein, aber kein Freifahrtschein. Ein frei verfügbarer Codebestand hilft wenig, wenn intern niemand ihn versteht und kein Partner Verantwortung übernimmt. Gute Beschaffung schaut deshalb auf die Community, die Release-Politik, die Sicherheitsmeldungen und die finanzielle Stabilität eines Anbieters. Wer eine offene Lösung auswählt, sollte genauso genau hinsehen wie bei einer proprietären – nur mit der zusätzlichen Chance, kritische Annahmen überprüfen zu können.

Spannend ist auch die Rolle offener Standards. Selbst wenn eine Organisation nicht jede Komponente selbst betreibt, senken offene Schnittstellen die Wechselkosten. Sie verhindern nicht jede Abhängigkeit; Datenmodelle, Schulungen und Prozesse bleiben klebrig. Aber sie schaffen Verhandlungsspielraum. Und der macht einen Unterschied, wenn der nächste Vertragszyklus ansteht.

Die Linux-Welt hat sich gerade deshalb gehalten, weil sie nie auf eine einzige Nutzungsform festgelegt war: Entwicklungsrechner, Embedded-System, Unternehmensserver oder Cloud-Workload – derselbe Kernel kann in sehr unterschiedlichen Umgebungen arbeiten. Diese Anpassungsfähigkeit erklärt nicht alles, aber sie ist ein gutes Gegenmittel gegen die Vorstellung, Software müsse zwingend in einer festen Produktbox gedacht werden.

Genau darin liegt die nüchterne Lehre des Jubiläums: Technische Freiheit entfaltet ihren Wert erst dann, wenn Organisationen sie mit Kompetenz, klaren Zuständigkeiten und einem belastbaren Betriebsplan verbinden – auch im ganz normalen Alltag.

Wer das beherzigt, gewinnt keine Wunderwaffe. Aber eine realistische Chance auf Kontrolle, nachvollziehbare Entscheidungen und weniger unangenehme Überraschungen bei der nächsten technischen oder kommerziellen Kursänderung.

Bei digitalen Diensten geht es dabei zunehmend um lokale Kontrolle. Wer etwa Sprachmodelle außerhalb einer Public Cloud einsetzen will, findet in unserem Praxisüberblick zu lokalen KI-Tools wie LM Studio und Ollama erste Orientierung. Auch dort taucht dieselbe Frage auf: Wo liegen Daten, wer kann Systeme prüfen und wie frei ist ein Wechsel wirklich?

Offener Code ist kein Schutzschild – aber eine Chance zur Kontrolle

Die Sicherheitsdebatte begleitet Open Source seit Jahrzehnten. Der Einwand ist schnell formuliert: Wenn Angreifende den Code sehen können, müssten sie Schwachstellen doch leichter finden. Das greift zu kurz. Den gleichen Einblick haben auch Sicherheitsforschende, Nutzende und unabhängige Fachleute. Transparenz ersetzt kein Sicherheitskonzept, schafft aber die Voraussetzung dafür, Behauptungen und Änderungen selbst zu prüfen.

Peter Ganten formuliert es treffend: Offener Quellcode garantiere keine Sicherheit, schaffe aber eine wesentliche Voraussetzung für höhere Sicherheit. Das Viele-Augen-Prinzip ist kein magischer Effekt. Es funktioniert nur, wenn genug Menschen tatsächlich prüfen, wenn Verantwortlichkeiten klar sind und wenn Hinweise ernst genommen werden.

Der Angriff auf die XZ Utils im Jahr 2024 zeigt beide Seiten. Ein Angreifer hatte über längere Zeit Vertrauen in einem Projekt aufgebaut und eine Backdoor in vorbereitete Releases eingeschleust. Entdeckt wurde sie vor einer breiten Auslieferung durch einen aufmerksamen Entwickler, der ungewöhnliches Verhalten untersuchte. Die ursprüngliche Sicherheitsmeldung zu xz Utils dokumentiert, wie schnell Distributionen und Maintainer reagierten.

Daraus folgt nicht, dass offene Software automatisch sicher ist. Es folgt auch nicht das Gegenteil. Der Vorfall zeigt, dass Lieferketten, Maintainer-Strukturen und Review-Prozesse ernst genommen werden müssen – bei freiem wie bei proprietärem Code. Wir bei digital-magazin.de finden: Wer Transparenz als Ausrede für Nachlässigkeit verkauft, hat das Thema ebenso wenig verstanden wie jemand, der Geheimhaltung mit Sicherheit verwechselt.

Die nächste Etappe: digitale Souveränität und offene KI

35 Jahre nach Linux geht es längst nicht mehr nur um Server und Betriebssysteme. Bei KI stellt sich dieselbe Grundfrage in neuer Schärfe: Können Organisationen nachvollziehen, mit welchen Daten ein Modell trainiert wurde, wo es läuft und wer Zugang zu den Eingaben hat? Rico Barth sieht gerade bei Sprachmodellen die Kontrolle über Modelle und Daten als entscheidend. Für sensible Einsatzfelder reichen Versprechen eines Anbieters nicht immer aus.

Offene Modelle und offene Werkzeuge lösen nicht jedes Problem. Trainingsdaten, Sicherheitsvorkehrungen, Kosten und Fachwissen bleiben anspruchsvoll. Sie erweitern aber die Optionen: lokal betreiben, unabhängig prüfen, anpassen oder mit einem vertrauenswürdigen Dienstleister arbeiten. Für Behörden und Unternehmen ist das kein ideologischer Luxus, sondern eine strategische Frage.

Der Begriff „offene KI“ verlangt dabei dieselbe Genauigkeit wie „Open Source“. Veröffentlicht ein Anbieter nur Modellgewichte, aber keine Informationen zu Trainingsdaten oder Lizenzbedingungen, ist das etwas anderes als ein vollständig überprüfbares Projekt. Diese Unterschiede müssen Beschaffung und IT-Sicherheit kennen. Eine griffige Vermarktungsformel ersetzt keine technische Prüfung.

Linux hat die Garage längst verlassen. Geblieben ist sein unangenehmer, produktiver Kern: Niemand muss einem einzelnen Hersteller vollständig ausgeliefert sein. Das verpflichtet Anbieter dazu, gute Produkte und guten Support zu liefern. Und es verpflichtet Nutzende dazu, Wahlfreiheit nicht nur auf Folien zu feiern, sondern sie bei Architektur, Verträgen und Migrationen mitzudenken.