Das Engagement von Red Hat für Open Source: eine Antwort auf die Veränderungen bei git.centos.org

Ich habe an diesem Wochenende viel Zeit damit verbracht, über die Reaktion unserer Branche auf meinen letzten Blog-Beitrag nachzudenken. Wir wurden böse genannt, ich wurde als Handlanger von IBM bezeichnet, der instruiert wurde, Red Hat zu Closed Source zu machen – und viele noch schlimmere Sachen. Es ist Zeit, einige Dinge klarzustellen. 

Mein Name ist Mike McGrath. Ich bin Vice President of Core Platforms Engineering bei Red Hat. Ich bin seit 16 Jahren hier, und bevor ich anfing, hier zu arbeiten, arbeitete ich ehrenamtlich im Fedora-Projekt. Open Source und alles, was damit zusammenhängt, ist für mich sehr wichtig. In der letzten Woche habe ich gesehen, wie viele Leute viele unfreundliche und unwahre Dinge über hart arbeitende Beschäftigte bei Red Hat sagen, die wie ich diese Arbeit zutiefst schätzen.

Trotz allem, was derzeit über Red Hat gesagt wird, machen wir unsere harte Arbeit auch Nicht-Kunden zugänglich. Red Hat verwendet schon immer ein Open Source-Entwicklungsmodell, und daran wird sich auch in Zukunft nichts ändern. Wenn wir einen Fehler finden oder ein Feature schreiben, tragen wir unseren Code im Upstream bei. Davon profitiert die gesamte Community, nicht nur Red Hat und unsere Kunden.  

Wir nehmen nicht einfach Upstream-Pakete und machen einen Rebuild. Bei Red Hat verbringen Tausende von Menschen ihre Zeit damit, Code zu schreiben, um neue Funktionen zu aktivieren, Fehler zu beheben, verschiedene Pakete zu integrieren und diese Arbeit dann für lange Zeit zu unterstützen – etwas, das unsere Kunden und Partner brauchen. 

Hier geht es um die Stunden und Nächte, die wir damit verbringen, einen Patch in Code zurückzuportieren, der jetzt 5 bis 10 Jahre oder älter ist. Wir bieten jederzeit Support für 3 bis 4 große Release-Streams und versorgen sie mit Patches und Backports. Wenn wir Fixes für Probleme in RHEL entwickeln, wenden wir sie nicht nur auf RHEL an. Sie werden zuerst im Upstream auf Projekte wie Fedora, CentOS Stream oder das Kernel-Projekt selbst angewendet und dann zurückportiert. Die Wartung und der Support eines Betriebssystems über einen Zeitraum von 10 Jahren ist eine Herkulesaufgabe – die Arbeit, die wir leisten, hat einen enormen Wert.

Wir senden unseren Code immer in den Upstream und halten uns an die Open Source-Lizenzen, die unsere Produkte verwenden, einschließlich der GPL. Wenn ich sage, dass wir die verschiedenen Open Source-Lizenzen einhalten, die für unseren Code gelten, dann meine ich das auch so. Ich war schockiert und enttäuscht darüber, wie viele Leute in Bezug auf Open Source-Software und insbesondere die GPL so viel falsch verstanden haben – insbesondere Branchenbeobachter und sogar Veteranen, die es meiner Meinung nach besser wissen sollten. Die Details – einschließlich Open Source-Lizenzen und -Rechten – sind wichtig, und diese Dinge hat Red Hat nicht nur mitgestaltet, sondern auch gepflegt und weiterentwickelt. 

Ich habe das Gefühl, dass ein Großteil der Wut über unsere jüngste Entscheidung in Bezug auf die Downstream-Quellen von denen stammt, die entweder nicht für die Zeit, den Aufwand und die Ressourcen in RHEL bezahlen möchten, oder die es zu ihrem eigenen Gewinn neu verpacken möchten. Diese Forderung nach RHEL Code ist unaufrichtig. 

Wir müssen die Leute bezahlen, die diese Arbeit erledigen – diese engagierten Mitarbeiterinnen und Mitarbeiter, die sich durch die langen Stunden und Nächte quälen und an die Werte von Open Source glauben. Das einfache Neuverpacken des von diesen Personen erstellten Codes und dessen Weiterverkauf ohne Mehrwert macht die Produktion dieser Open Source-Software nicht nachhaltig. Dazu gehören wichtige Backportierungsarbeiten und zukünftige Features und Technologien, die sich in der Upstream-Entwicklung befinden. Wenn diese Arbeit nicht mehr nachhaltig ist, wird sie aufhören, und das ist für niemanden gut.

Ich möchte speziell die Rebuilder erwähnen, die sich von Distributionen unterscheiden, die beispielsweise eine neue Architektur oder ein Kompilierungs-Flag hinzufügen können (wir unterstützen Sie umfassend dabei, Linux-Funktionen zu erweitern, anstatt sie zu imitieren). 

Vor nicht allzu langer Zeit schätzte Red Hat die Arbeit von Rebuildern wie CentOS. Wir haben unsere SRPMs in einem übersichtlichen Paket auf git.centos.org verteilt, wodurch sie leicht neu erstellt werden konnten. Wir haben es sogar für sie de-branded. Vor kurzem haben wir festgestellt, dass ein nachgelagerter Rebuilder keinen Wert hat. 

Die allgemein akzeptierte Position, dass diese kostenlosen Rebuilds zur Bildung von Experten und Expertinnen beitragen und später zu Umsätzen führen, hat sich als unrealistisch erwiesen. Ich wünschte, wir würden in dieser Welt leben, aber es ist nicht so, wie sie sich tatsächlich entwickelt. Stattdessen haben wir eine Gruppe von Benutzern gefunden, von denen viele zu großen oder sehr großen IT-Organisationen gehören und die die Stabilität, den Lifecycle und das Hardware-Partnernetzwerk von RHEL nutzen möchten, ohne die Betreuer, Ingenieure, Autoren und viele andere Rollen, die es erstellen, unterstützen zu müssen. Diese Benutzer haben sich auch entschieden, keine der vielen anderen Linux-Distributionen zu verwenden.

In einem gesunden Open Source-IT-Ökosystem gehen Wettbewerb und Innovation Hand in Hand. Red Hat, SUSE, Canonical, AWS und Microsoft erstellen Linux-Distributionen mit den dazugehörigen Branding- und Ökosystem-Entwicklungsaktivitäten. Diese Varianten verwenden Linux-Quellcode und tragen diesen bei, aber keine behauptet, „vollständig kompatibel“ mit den anderen zu sein.

Letztendlich sehen wir keinen Wert in einem RHEL Rebuild, und wir sind nicht verpflichtet, die Dinge für Rebuilder zu vereinfachen. Ob wir das tun oder nicht, liegt einzig und allein an uns. Das bringt mich zu CentOS Stream, über das es eine immense Verwirrung gibt. Ich erkenne an, dass dies eine Änderung in einer langjährigen Tradition ist, in der wir enorme Leistungen erbracht haben. Änderungen wie diese können zu Verwirrung führen. Diese Verwirrung manifestierte sich in Anschuldigungen, wir würden Closed Source werden und angebliche Verstöße gegen die GPL begehen. Es gibt CentOS Stream, den gelieferten Binärcode, und CentOS Stream, das Quell-Repository. In der CentOS Stream gitlab source erstellen wir RHEL Releases, die offen sichtbar sind. RHEL als „Closed Source“ zu bezeichnen, ist grundsätzlich falsch und ungenau. CentOS Stream bewegt sich schneller als RHEL, daher befindet es sich möglicherweise nicht auf HEAD, aber der Code ist vorhanden. Wenn Sie ihn nicht finden können, handelt es sich um einen Fehler. Teilen Sie uns dies bitte mit.

Wir bieten auch kostenlose Red Hat Developer Subskriptionen und Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure an. Die Developer Subskription bietet Entwicklern ein kostenloses RHEL und ermöglicht die kostenlose Nutzung für bis zu 16 Systeme. Einzelpersonen können diese Subskription für ihre eigene Arbeit verwenden. Kunden von RHEL können sie außerdem für die Arbeit ihrer Beschäftigten verwenden. RHEL for Open Source Infrastructure ermöglicht Open Source-Projekten (unabhängig davon, ob sie in irgendeiner Weise mit Red Hat verbunden sind oder nicht) den kostenlosen Zugriff auf RHEL für ihre Infrastruktur- und Entwicklungsanforderungen.

Abschließend möchte ich auf Open Source-Unternehmen eingehen, unabhängig davon, ob Ihr Code gegenwärtig offen ist oder Sie erwägen, auf ein Open Source-Modell umzusteigen. Red Hat hat es in jeglicher Hinsicht „geschafft“, und ich hoffe, dass viele Open Source-Unternehmen so erfolgreich sein können wie wir. Sie können selbst entscheiden, ob Downstream-Rebuilds für Sie wertvoll sind. Es liegt in Ihrer Hand, es einfach zu machen oder nicht. 

Einfach einen Rebuild von Code zu erstellen, ohne einen Mehrwert zu schaffen oder ihn in irgendeiner Weise zu ändern, stellt eine echte Bedrohung für Open Source-Unternehmen auf der ganzen Welt dar. Dies ist eine echte Bedrohung für Open Source, die das Potenzial hat, Open Source wieder in eine reine Hobby- und Hacker-Aktivität zu verwandeln.

Wir wollen das nicht, und ich weiß, dass unsere Community-Mitglieder, Kunden und Partner das auch nicht wollen. Innovation findet im Upstream statt. Bei Open Source geht es darum, auf den Schultern anderer zu bauen. Lassen Sie uns weiterhin Innovationen vorantreiben, einander unterstützen und weiter vorankommen.