Open Source:

Was Unternehmen heute davon haben

Als Linux 0.01 im September 1991 erschien, war die Idee offener Software keineswegs neu. Doch das Projekt eines finnischen Studenten wurde zum Sinnbild einer Entwicklung, die aus der Programmiererszene einen Milliardenmarkt entstehen ließ. 35 Jahre später gehört Open Source zur professionellen IT. Wie verdienen Unternehmen mit offenem Code Geld? Und was bedeutet Open Source heute für Sicherheit, Unabhängigkeit und digitale Souveränität? Fünf Vertreter deutscher Open-Source-Unternehmen ziehen Bilanz.

Der wirtschaftliche Erfolg begann lange vor den milliardenschweren Übernahmen, mit denen offene Software später Schlagzeilen machte. Den entscheidenden Schritt sieht Peter Ganten, CEO von Univention und Vorstandsvorsitzender der Open Source Business Alliance, rund um die Jahrtausendwende. „Erfolgreiche Geschäftsmodelle im Umfeld von Open Source-Software gibt es spätestens seit Anfang der 2000er Jahre“, sagt er. Ein wichtiger Schritt waren Enterprise-Subskriptionen: Kunden zahlten nun für dauerhaft betreute Software, nicht für das exklusive Recht am Code. „Damit wurde erstmals nachgewiesen, dass Open Source-Software auch im hochpreisigen Enterprise-Segment einen Wert schafft, für den Unternehmen und Behörden bereit sind zu bezahlen.“

An der Wahrnehmung offener Software änderte sich zunächst wenig. Das Bild war noch von Einzelentwicklern und günstigen Alternativen zu kommerziellen Programmen geprägt. Rico Barth, Geschäftsführer von KIX Service Software, beschreibt die damaligen Vorstellungen so: „Open Source wurde lange mit Garagen-Entwicklern, freiberuflichen Software-Enthusiasten und dem Versprechen deutlicher Kostenersparnisse verbunden.“ Erst die Größenordnung späterer Geschäfte machte einem breiteren Publikum deutlich, welche Wirtschaftskraft dahintersteckte. Im Jahr 2018 gab IBM die geplante Übernahme von Red Hat für rund 34 Milliarden Dollar bekannt; SUSE wurde mit gut 2,5 Milliarden Dollar bewertet. Barth erinnert sich: „Spätestens da hat jeder verstanden, dass auf Open Source funktionierende Geschäftsmodelle aufgebaut werden können.“

Bezahlt wird, was rund um die Software passiert

Das klassische Lizenzgeschäft lebt davon, den Zugang zu einer proprietären Software zu verkaufen. Bei Open Source ist der Quellcode dagegen offen und kann im Rahmen der jeweiligen Lizenz genutzt und weitergegeben werden. Ein zahlender Kunde erwirbt deshalb vor allem etwas anderes: eine für seinen Betrieb geeignete Version, Pflege und Sicherheitsupdates, Support, Zertifizierungen, Integration in die vorhandene IT oder den Betrieb als Dienstleistung. Auch zusätzliche Funktionen können zum Angebot gehören. Entscheidend ist nicht allein, dass die Software verfügbar ist, sondern dass sie im Arbeitsalltag zuverlässig funktioniert.

Für Unternehmen ist deshalb die Frage nach der kostenlosen Lizenz zu kurz gegriffen. Maßgeblich sind die Gesamtkosten über die geplante Nutzungsdauer: Einrichtung, Schulung, Anpassungen, Infrastruktur, Updates, Betrieb und ein möglicher späterer Wechsel. Eine quelloffene Lösung kann hier günstiger sein, muss es aber nicht. Wer eine Anwendung vollständig selbst betreibt, spart möglicherweise Lizenzgebühren, trägt dafür aber mehr Verantwortung im eigenen IT-Team. Wer einen Dienstleister beauftragt, kauft diese Leistung hinzu. Ein sinnvoller Vergleich betrachtet nicht nur den Anschaffungspreis, sondern auch die Kosten im laufenden Betrieb und im Störungsfall.

Gerade bei kritischen Anwendungen zählt außerdem, was vertraglich zugesichert ist. Wie schnell reagiert ein Anbieter auf Sicherheitslücken? Gibt es verbindliche Reaktionszeiten und Unterstützung bei Versionswechseln? Wer hilft, wenn Schnittstellen nach einem Update nicht mehr funktionieren? Erst solche Zusagen machen aus öffentlich verfügbarem Code ein Angebot, das sich auch für größere Organisationen kalkulieren lässt.

Dass sich daraus vergleichsweise schnell ein rentables Unternehmen machen lässt, demonstrierte Nextcloud. Der Anbieter startete 2016 und schrieb nach Angaben seines Gründers Frank Karlitschek bereits im Gründungsjahr schwarze Zahlen. Als IBM später den milliardenschweren Kauf von Red Hat ankündigte, sah Karlitschek darin eine Bestätigung für das wirtschaftliche Potenzial der Branche: „Das macht kein Unternehmen, wenn man damit keinen ROI erwartet. In dieser Zeit wurde immer mehr deutlich: Open Source kann es auch wirtschaftlich mit den Großen aufnehmen.“

Doch derselbe freie Zugang, der das Modell attraktiv macht, verhindert eine exklusive Vermarktung. Wer Software entwickelt, muss damit rechnen, dass andere sie ebenfalls kommerziell nutzen. Gerade große Cloud-Unternehmen können ein erfolgreiches Projekt als fertig betreuten Service anbieten. Mit ihren Rechenzentren und ihrem Vertriebsnetz sind sie dabei bisweilen im Vorteil – selbst gegenüber dem Team, von dem die Entwicklung ursprünglich stammt. Um sich dagegen abzusichern, ändern manche Hersteller Lizenzbedingungen oder wählen einen Open-Core-Ansatz: Der Kern bleibt offen, bestimmte Erweiterungen dagegen nicht.

Dabei ist nicht jede Software mit einsehbarem Quellcode automatisch Open Source. Nach der Definition der Open Source Initiative gehören dazu unter anderem Rechte zur Weitergabe und Veränderung sowie die Möglichkeit, abgeleitete Programme zu verbreiten. Eine bloße Erlaubnis, den Code anzusehen, reicht nicht aus. Für Beschaffer ist diese Unterscheidung wichtig: Von den konkreten Lizenzrechten hängt ab, ob sie eine Anwendung durch Dritte pflegen oder für eigene Zwecke weiterentwickeln lassen dürfen. Lizenzmodelle müssen deshalb ebenso sorgfältig geprüft werden wie technische Funktionen.

Damit entsteht ein Dilemma. Entwicklung kostet Geld; neue Beschränkungen können jedoch die Unabhängigkeit der Nutzer vermindern, die Open Source gerade ermöglichen soll. Zugleich ist Konkurrenz stets nur einen Codezugriff entfernt. Wer nicht über Exklusivrechte verkaufen kann, muss bei Qualität, Funktionsumfang und Dienstleistungen überzeugen und weiterentwickeln, was seine Kunden tatsächlich brauchen.

Beim Wedeler Unternehmen Stackable ist diese Freiheit Teil des Angebots. „Unsere Kunden sind bei uns, weil sie glücklich mit uns sind, sie sich auf unseren Support verlassen können und weil sie nicht durch eine Lizenz eingesperrt sind. Die permanente Exit-Option ist ein großer Pluspunkt“, sagt er. Die Freiheit zum Wechsel wird damit selbst zu einem Verkaufsargument. Für den Anbieter bedeutet sie, sich die Kundentreue immer wieder verdienen zu müssen. Neben der wirtschaftlichen Frage ist für die Verbreitung offener Software allerdings noch etwas entscheidend: Vertrauen in ihre Sicherheit.

Was einsehbarer Quellcode für die Sicherheit bedeutet

Wer den Programmcode einer Anwendung lesen kann, kann darin auch nach Fehlern suchen. Genau das nährt den Vorwurf, Open Source mache es Angreifern besonders einfach. Die Kehrseite dieser Zugänglichkeit wird dabei oft übersehen: Auch IT-Abteilungen, unabhängige Experten und Sicherheitsforscher können nachvollziehen, wie die Software arbeitet, statt auf die Angaben des Herstellers angewiesen zu sein.

Das häufig angeführte Viele-Augen-Prinzip funktioniert jedoch nicht von selbst. Ein Repository kann öffentlich sein und trotzdem nur von wenigen Menschen regelmäßig geprüft werden. Zwischen dem Entdecken einer Lücke und ihrer Beseitigung liegen oft mehrere Schritte: Die betroffene Komponente muss identifiziert, eine Korrektur entwickelt, getestet und anschließend bei den Anwendern installiert werden. Wird ein Update nicht eingespielt, nützt seine Veröffentlichung wenig. Unternehmen benötigen deshalb auch bei Open Source klare Zuständigkeiten für die Überwachung und Behebung von Schwachstellen.

Peter Ganten warnt deshalb vor einem einfachen Schluss von Transparenz auf Schutz: „Offener Quellcode garantiert keine Sicherheit, schafft aber eine wesentliche Voraussetzung für höhere Sicherheit“, sagt er. Die Veröffentlichung eines Programms beseitigt keine Schwachstellen. Sie eröffnet jedoch die Möglichkeit, dass viele Fachleute sie entdecken und prüfen – nicht nur diejenigen, die der Hersteller selbst damit beauftragt.

Besonders schwierig ist die Kontrolle der zahlreichen Bausteine, aus denen moderne Anwendungen bestehen. Ein Programm kann Bibliotheken einbinden, die ihrerseits weitere Komponenten verwenden. Sicherheitsbehörden wie die US-amerikanische CISA und das National Institute of Standards and Technology empfehlen deshalb, Softwarebestandteile systematisch zu erfassen. Eine Software Bill of Materials, kurz SBOM, bildet diese Abhängigkeiten ähnlich einer Stückliste ab. Sie schützt nicht vor Angriffen, erleichtert aber die Antwort auf eine entscheidende Frage: In welchen eigenen Systemen steckt eine Komponente, für die gerade eine kritische Schwachstelle gemeldet wurde?

Der Fall der XZ Library aus dem Jahr 2024 illustriert diese Stärke, aber auch die Risiken. Angreifer hatten versucht, eine verbreitete Softwarekomponente zu manipulieren. Liebau verweist auf die Entdeckung der Manipulation als Beleg dafür, was unabhängige Prüfung leisten kann: „Jahrelange Vorbereitung durch die Angreifer, aufgedeckt von der Community an einem Wochenende. Ich behaupte, dass die Entdeckung Jahre gedauert hätte, hätten die Angreifer den Schadcode in eine proprietäre Software bekommen – wenn sie überhaupt je gefunden worden wäre.“

Bei XZ war der Angriff besonders tückisch, weil er nicht als gewöhnlicher Programmierfehler entstand. Manipulierter Code sollte über eine verbreitete Kompressionsbibliothek in Systeme gelangen. Aufgefallen war der Fall Ende März 2024 unter anderem durch ungewöhnliche Verzögerungen bei SSH-Anmeldungen – der Entwickler Andres Freund machte seine Beobachtungen öffentlich. Dass die Manipulation entdeckt wurde, spricht für die Kontrollmöglichkeiten eines offenen Entwicklungsprozesses. Dass sie überhaupt so weit kommen konnte, zeigt dessen Grenze: Auch die Vertrauenswürdigkeit von Beitragenden, Veröffentlichungen und Abhängigkeiten muss geprüft werden.

Wenn die Unabhängigkeit wichtiger wird als der Preis

Lange war das stärkste Verkaufsargument von Open Source die Aussicht auf niedrigere Lizenzkosten. Inzwischen geht es den Anwendern zunehmend darum, wie frei sie über ihre Systeme entscheiden können. Torsten Hallmann, Open Source Ambassador bei SUSE, nennt als Gründe: „Innovationsgeschwindigkeit, Resilienz und echte Wahlfreiheit. Früher ging es primär um Lizenzkosten. Heute steht die Unabhängigkeit im Fokus. Denn gerade diese Wahlfreiheit wird immer wichtiger. Wer offene Software einsetzt, kann sie anpassen, selbst betreiben oder einen Dienstleister damit betrauen. Fällt ein Hersteller aus, ändert er seine Strategie oder erhöht die Preise, bleibt die technische Grundlage grundsätzlich verfügbar.“

Im Kern geht es um das Risiko, auf einen einzigen Lieferanten angewiesen zu sein. Bei offenen Lösungen bleibt grundsätzlich die Möglichkeit, einen anderen Dienstleister zu beauftragen oder die Software selbst weiterzubetreiben. Rico Barth nennt dies die Chance, „die Bindung an einen einzigen Hersteller und damit Monopolisten aufzubrechen“. Das Argument sei keineswegs neu, werde aber anders bewertet als früher: „Heute wird dieser Aspekt durch die Debatten über digitale Souveränität und Resilienz immer stärker wahrgenommen. Aber natürlich bleibt es auch eine wirtschaftliche Frage. Wer sich langfristig an einen Anbieter bindet, macht sich von dessen Preisen, seiner Produktstrategie und seinem Support abhängig. Was kurzfristig bequem erscheint, ist langfristig ein Risiko.“

Allerdings beseitigt der Einsatz von Open Source nicht automatisch jede Abhängigkeit. Auch offene Software kann an proprietäre Datenformate, spezielle Erweiterungen oder die Infrastruktur eines Cloud-Anbieters gekoppelt sein. Selbst standardisierte Schnittstellen machen einen Wechsel nicht zum Kinderspiel. Daten müssen übertragen, Anwendungen angepasst und Abläufe getestet werden. Der entscheidende Unterschied: Der Quellcode bleibt grundsätzlich verfügbar, und damit stehen Unternehmen mehr Möglichkeiten offen, sich von einem Anbieter zu lösen.

Trotzdem bleiben viele Unternehmen ihren bisherigen Produkten treu. Ein Umstieg erscheint kompliziert, die Folgen der fortgesetzten Abhängigkeit dagegen oft weniger unmittelbar. Nextcloud-Gründer Frank Karlitschek hält diese Abwägung für verfehlt: „Die meisten überschätzen den Migrationsaufwand und unterschätzen dabei den Verlust an Souveränität.“ Ein Wechsel erfordert zudem nicht zwangsläufig eine vollständige Umstellung an einem Stichtag. Statt „Ganz oder gar nicht“ lassen sich einzelne Workloads nacheinander verlagern und vorübergehend parallel betreiben.

Bei einer geplanten Migration empfiehlt sich deshalb ein nüchternes Vorgehen. Am Anfang steht die Bestandsaufnahme: Welche Anwendungen sind mit welchen Datenbanken, Benutzerverwaltungen und Fachverfahren verbunden? Anschließend lässt sich ein überschaubarer Bereich auswählen, in dem Funktionen, Schnittstellen und Arbeitsabläufe unter realen Bedingungen getestet werden. Erst wenn auch Datentransfer, Benutzerrechte und Rückfallmöglichkeiten geklärt sind, folgt die breitere Umstellung. Gerade die zeitweilige Doppelstruktur verursacht zwar Aufwand. Sie kann aber verhindern, dass aus einem technischen Wechsel ein Risiko für den laufenden Betrieb wird.

Wie wichtig diese schrittweise Vorgehensweise ist, zeigt der Zustand gewachsener Unternehmens-IT. Hallmann sagt: „Kaum eine Organisation baut heute auf der grünen Wiese. Die Realität sind gewachsene, heterogene IT-Landschaften.“ Offene Software muss sich deshalb gerade in bestehenden Umgebungen bewähren und mit bereits genutzten Anwendungen zusammenarbeiten. Sein Maßstab dafür: „Echte Innovation erweitert Optionen, statt sie einzuschränken.“

Der nächste Prüfstein: Offene KI

Der Nutzen der technischen Wahlfreiheit reicht inzwischen weit über Einkauf und Lizenzverträge hinaus. Wer eine Anwendung überprüfen, verändern, selbst betreiben und bei Bedarf von Dritten warten lassen kann, hat mehr Einfluss darauf, wie die eigene Infrastruktur funktioniert und was mit den Daten geschieht. Gerade dort, wo Unternehmen und Behörden sensible Informationen verarbeiten, ist das eine strategische Frage. Digitale Souveränität bedeutet in diesem Zusammenhang nicht, alles selbst entwickeln zu müssen, sondern über echte Alternativen zu verfügen.

Mit künstlicher Intelligenz bekommt diese Frage eine neue Dringlichkeit. Peter Ganten fordert, „Open Source – und auch offene KI – in allen Bereichen zum Standard werden zu lassen“. Die Entscheidung für ein Sprachmodell betrifft schließlich nicht nur dessen Fähigkeiten, sondern ebenso die Kontrolle über Daten und die Bedingungen des Betriebs. Rico Barth spricht sich dafür aus, solche Modelle in „geprüften, vertrauenswürdigen, gegebenenfalls lokalen Umgebungen“ einzusetzen. Unternehmen und Behörden müssten außerdem nachvollziehen können, auf welcher Datenbasis die Modelle trainiert wurden, wie Informationen verarbeitet werden und ob eine unabhängige Prüfung möglich ist. Damit könnte offene Software auch für die nächste Generation digitaler Infrastruktur an Bedeutung gewinnen.

Bei KI wird bereits die Frage komplizierter, was überhaupt offen ist. Manche Anbieter veröffentlichen lediglich die Gewichte eines Sprachmodells, also seine trainierten Parameter. Das erlaubt unter Umständen den eigenen Betrieb, sagt aber noch wenig über Trainingsdaten, die Entstehung des Modells oder dessen Veränderbarkeit aus. Die Open Source Initiative hat deshalb 2024 eine eigene Definition für offene KI veröffentlicht. Sie verlangt nicht nur Freiheiten zur Nutzung und Weitergabe, sondern auch Zugang zu den Informationen und Bestandteilen, die für das Verständnis und die Bearbeitung des Systems notwendig sind. Open Weights und Open Source sind demnach nicht grundsätzlich dasselbe. Für Unternehmen ist das mehr als eine Definitionsfrage. Denn ob sie eine Technologie prüfen, anpassen, selbst betreiben oder den Anbieter wechseln können, entscheidet darüber, wie unabhängig sie tatsächlich sind.

35 Jahre nach der Veröffentlichung von Linux 0.01 ist Open Source längst Bestandteil professioneller IT und Grundlage eines Milliardenmarkts. Geld verdient wird mit Entwicklung, Wartung, Sicherheit und Betrieb offener Software. Für die Anwender reicht ihr Wert jedoch weit über mögliche Kostenvorteile hinaus: Sie gewinnen mehr Einfluss auf ihre IT und den Umgang mit ihren Daten. Die Debatte um offene KI zeigt zugleich, dass diese Unabhängigkeit keineswegs selbstverständlich ist. Entscheidend ist nicht, ob ein Anbieter seine Technologie als offen bezeichnet, sondern welche Freiheiten er seinen Kunden tatsächlich einräumt.

Quellen und weiterführende Nachweise

Open Source Initiative: The Open Source Definition (Definition offener Software und Lizenzanforderungen). https://opensource.org/osd

IBM, Unternehmensmitteilung vom 28.10.2018: Ankündigung der Übernahme von Red Hat. https://de.newsroom.ibm.com/2018-10-28-IBM-ubernimmt-Red-Hat-und-erschliesst-den-vollen-Wert-der-Cloud-fur-Unternehmen

EQT, Mitteilung vom 02.07.2018: Bewertung von SUSE mit 2,535 Mrd. US-Dollar. https://eqtgroup.com/news/eqt-ubernimmt-fuhrenden-open-source-softwareanbieter-suse

Nextcloud: Unternehmenschronik (Gründung und Profitabilität 2016). https://nextcloud.com/blog/6-months-in-nextcloud-profitable-and-growing-strong/

NIST: Software Security in Supply Chains – Software Bill of Materials. https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20

CISA: SBOM Resources Library (Einordnung und Anwendung von Stücklisten für Software). https://www.cisa.gov/topics/cyber-threats-and-advisories/sbom/sbomresourceslibrary

Elastic Security Labs, 05.04.2024: 500ms to Midnight – Analyse der XZ-Manipulation. https://www.elastic.co/security-labs/threat-command/500ms-to-midnight

Open Source Initiative: Open Source AI Definition, Version 1.0 (2024). https://opensource.org/ai/open-source-ai-definition