Mehr als man auf den ersten Blick sieht: Ein Blick hinter die Kulissen von Red Hat Enterprise Linux 10

In dieser Serie erfahren Sie mehr über die Personen und die Planung, die hinter der Entwicklung und Veröffentlichung von Red Hat Enterprise Linux 10 stehen. Von den ersten Konzeptphase bis zum Launch auf dem Red Hat Summit 2025 erfahren wir aus erster Hand, wie RHEL 10 entstanden ist.

Auf dem Red Hat Summit 2025 haben wir die neueste Version der bekannten Linux-Plattform für Unternehmen angekündigt: Red Hat Enterprise Linux (RHEL) 10. Dieses Release umfasste weit mehr als nur kleinere Verbesserungen oder Funktionserweiterungen. RHEL 10 bietet KI-gestütztes Linux-Management, Post-Quanten-Kryptografiefunktionen und integriert Container als nativen Bestandteil des Betriebssystems.

Kurz gesagt, RHEL 10 stellt eine bedeutende grundlegende Veränderung in der Funktionsweise von Linux-Plattformen für Unternehmen dar. Das bedeutet, dass dies nicht von heute auf morgen geschehen ist.

Mehr als 1.000 Red Hat Mitarbeitende aus Engineering, Marketing, Produktmanagement, QE und weiteren Bereichen haben zusammengearbeitet, um diesen Launch zu ermöglichen. Für diese Personen und Teams war es jedoch kein einzelnes Ereignis, sondern die Summe Hunderter von Momenten und Meilensteinen.

Lassen Sie uns also einige dieser Momente aus der Perspektive derjenigen betrachten, die RHEL 10 tatsächlich entwickeln.

2022 (direkt nach dem Release von RHEL 9)

Major Releases von RHEL, wie beispielsweise 8, 9 und 10, erscheinen etwa alle drei Jahre. Dies bedeutet, dass der Launch auf dem Red Hat Summit 2025 bereits direkt nach dem Red Hat Summit 2022 begann, als RHEL 9 veröffentlicht wurde.

Gunnar Hellekson, Vice President and General Manager, Red Hat Enterprise Linux

„Die Arbeit an RHEL ist ein kontinuierlicher Prozess. Major Releases bieten etwa alle drei Jahre die Möglichkeit, disruptive, evolutionäre Änderungen vorzunehmen, die in einem Minor Release einfach nicht umsetzbar oder akzeptabel wären.“

Mike McGrath, Vice President, Core Platforms Engineering

„Wir haben Architekten, Product Owner, Software Engineers und Software QE-Engineers, die alle zusammenarbeiten, um dieses umfangreiche Projekt zu realisieren. Und dabei ist es auf Programmebene entscheidend, sicherzustellen, dass alle Beteiligten gleichberechtigt zusammenarbeiten. Sie müssen verstehen, was wir tun, wohin wir wollen und wann wir unsere Ziele erreichen, damit wir alle gleichzeitig ankommen können.

Bei einem umfangreichen Release wie RHEL ist ein Großteil der Beteiligten ein Team von Engineers. Man richtet also ein Programm ein und Shelley Dunne ist für uns als Program Managerin zuständig. Dies war das erstes Release mit RHEL für Shelley, und wir waren sehr froh, sie in unserem Team zu haben.“

Shelley Dunne, Senior Principal Program Manager

„Wir arbeiten gemeinsam an diesem Projekt. Wir müssen fortlaufend prüfen, ob eine bestimmte Fähigkeit, Feature oder Änderung die richtige Lösung für das Produkt darstellt. Wenn dies der Fall ist, sollten wir herausfinden, wer welche Aufgaben übernehmen muss, und diese umsetzen.“

McGrath

„Anschließend legen wir fest, wer die einzelnen Bereiche leitet. Brian Stinson war unser Hauptarchitekt für RHEL 10, und wir haben ihn frühzeitig einbezogen, da die Fedora Community eine wichtige Rolle bei den RHEL-Releases spielt. Fedora wird alle sechs Monate veröffentlicht und ist RHEL deutlich voraus. Wenn wir jedoch wissen, wohin sich RHEL entwickeln wird, müssen wir diese Entwicklung zuerst in Fedora umsetzen.“

Brian Stinson, Principal Software Engineer

„Wir wollten gut in die Fedora Community integrieren sein, um sicherzustellen, dass die Zukunft von RHEL in den Fedora-Releases abgebildet wird. Es ist kostengünstiger – sowohl finanziell als auch hinsichtlich des Wartungsaufwands und der Arbeitsbelastung –, etwas in Fedora zu entwickeln und es dann zu übernehmen, anstatt später zu versuchen, es abzuspalten. Daher ist es uns ein wichtiges Anliegen, Features und Funktionen in Fedora sehr frühzeitig zu beeinflussen, zum Wohle von Fedora und für die Kunden von Red Hat.

Wir möchten aber auch sicherstellen, dass wir Fedora zum richtigen Zeitpunkt beeinflussen und anpassen, denn die Funktionen, die wir in RHEL wünschen, müssen in Fedora verfügbar sein, wenn wir für die Produktentwicklung bereit sind.“

McGrath

„In dieser frühen Phase, in den ersten 18 Monaten nach der Veröffentlichung, ergeben sich manchmal hervorragende Ansätze, die neue Ideen in uns wecken, und manchmal sind wir es, die diese Ideen vorantreiben. Aber all dies geschieht im Community-Bereich, wo wir fortlaufend Feedback erhalten, und das unterstützt uns maßgeblich dabei, uns auf neue Technologie-Stacks zu konzentrieren.“

Dunne

„Lassen Sie uns Ideen sammeln. Lassen Sie uns prüfen, welche Möglichkeiten es gibt. Lassen Sie uns besprechen, was wir von Kunden hören. Lassen Sie uns besprechen, was wir von unseren Partnern hören.

Aufgrund der Natur unserer Technologie und unseres Geschäfts sind schnelle Umsetzungszeiten erforderlich. Wenn Sie also über etwas für RHEL 11 im Jahr 2025 sprechen, das noch drei Jahre entfernt ist, kann sich die Welt bis dahin noch ändern.“

Scott McCarty, Senior Principal Product Manager – Technical, Red Hat Enterprise Linux

„Wir haben also 36 Monate vor dem Red Hat Summit mit der Arbeit begonnen. Wir wussten, dass wir das Produkt auf diesem Summit vorstellen würden. Es schien sehr weit entfernt zu sein. War es aber nicht.“

Hellekson

„Alle Beteiligten sind begeistert von den Möglichkeiten, da der Plan nicht durch die harten Realitäten von Zeit und Ressourcen eingeschränkt ist. Vieles ist möglich!“

Dies ist jedoch nur der Anfang der zahlreichen Momente, die in die Entwicklung von RHEL 10 eingeflossen sind. In unserem nächsten Beitrag werden wir sehen, wie die neuen Entwicklungsmethoden von RHEL, die als Teil von CentOS Stream vollständig offen erfolgen, die Zukunft der Plattform mitgestaltet haben.