Red Hat: Koordinator im Chaos der Communities

ZDNet: Fedora wurde also von der Community nicht akzeptiert.

Riek: Ja, aber seit September vergangenen Jahres kann man sagen, dass es läuft. Am Anfang war’s schwierig, das stimmt. Die Community musste sich erst erwärmen, das ist ja klar. Auf der anderen Seite musste unserem Marketing die Angst genommen werden, dass die Kunden künftig nur mehr Fedora statt Red Hat Enterprise Linux einsetzen und uns somit Zahlungen entgehen. Dabei ist der Fedora-Nutzer von heute der Enterprise-User von morgen. Doch am Anfang gab es bei Red Hat keinen, der sich da wirklich darum gekümmert hätte. Dann kam die berühmte Rede von Michael Tieman, in der er diesen Fehler eingesteht und ein Umlenken fordert.

ZDNet: Dann war also nichts mit Einbettung in die Open Source-Community? Ich dachte, Red Hat wäre direkt daraus hervor gegangen?

Riek: Auf Seiten der Entwickler gab es ja auch keinerlei Problem, Red Hat ist vielmehr und eben gerade Entwickler-fokussiert. Man sprach nur mit den Leuten in bestimmten Projekten. Das Problem stellten aber die Anwender von Linux dar, also die Enthusiasten oder Leute, die in Projekten arbeiten, die nicht so im Scheinwerferlicht stehen. Für diese Leute hatten wir niemanden abgestellt, der sich gekümmert hätte. Aber seit September haben wir das geändert. Damals gab’s die Fedora User and Developer Conference (FUDCon), die auf dem Linuxtag vom 22. bis 25. Juni in Karlsruhe ihre zweite Auflage erleben wird.

ZDNet: Und wie unterscheidet sich Red Hats Art der Zusammenarbeit mit der Community etwa von der von Suse?

Riek: Unsere Strategie, nur innerhalb der Community zu entwickeln, finden Sie bei Suse nicht. Die setzen stark auf Add-ons.

ZDNet: Wie das lange Zeit umstrittene Yast.

» Daran sehen Sie den Vorteil unserer Vorgehensweise. Die haben ein Alleinstellungsmerkmal, wir bieten dagegen architektonische Stabilität. «

Riek: Yast war ja noch harmlos! Mittlerweile ist Yast sogar GPL. Fairerweise muss man sagen, dass auch wir über eigene Admin-Frontends verfügen, ähnlich wie Suse. Schwierig sind aber die Patches innerhalb des Kernels, die Suse eingeführt hat. Da kommt ein großer Hard- und Software-Anbieter und verlangt den Einbau, was Suse auch umgehend macht. Zum Teil Sachen, die von der Community explizit abgelehnt wurden. Beispiel: Multi Threading, um effizienter innerhalb eines Prozesses zu parallelisieren. Unter Windows bringt das einen enormen Performance-Vorteil, unter Linux immerhin einen nennenswerten. Unter Linux wurde das aber nur emuliert – dann hat der Anbieter eine eigene Threading-Lösung entwickelt – allerdings nicht besonders schön. Die Community hat das abgelehnt. In Suse Linux fanden sie das aber vorübergehend. Wir dagegen haben das Problem in die Community getragen und dort gelöst. Sogar der Hersteller, der die von der Community abgelehnte Lösung entwickelte hatte, hat sich daran beteiligt. Heute ist unsere Lösung Standard für den Kernel 2.6. Die Suse-Lösung ist aber nun aber nicht mehr Source Code-kompatibel zu diesem Standard. Die sind in eine Sackgasse gelaufen. Daran sehen Sie den Vorteil unserer Vorgehensweise. Die haben ein Alleinstellungsmerkmal, wir bieten dagegen architektonische Stabilität.