Kommerzielle Distributionen, aber auch Debian "veralten" viel zu schnell. Die Leidtragenden sind in erster Linie die Kunden, doch die Distributoren schaden sich auch selbst damit.
Ein Hundejahr entspricht sieben Menschenjahren, sagt man, doch beim Support von Linux-Distributionen wird das kaum reichen. Deren Lebenszyklus endet nämlich noch früher, bei Red Hat beispielsweise schon nach ganzen zwölf Monaten. Doch was für kommerzielle Distributoren auf den ersten Blick aus wirtschaftlichen Gründen kurzfristig nahe liegend erscheinen mag, ist letztlich ein Schuss ins eigene Knie.
Dass Software in der Open-Source-Welt besonders lange lebt, darf gerade Linux-Distributoren nicht verwundern. Doch das wirkt verkaufshemmend und so arbeiten sie gleichzeitig mit Leibeskräften an der Einführung Microsoft-ähnlicher Verhältnisse im Linux-Markt, die den Benutzer zu Versionsupdates im Ein-, allerspätestens aber im Zweijahrestakt zwingen sollen.
De facto würde damit eines der größten Sparpotenziale von Linux untergraben. Das besteht nämlich nicht in der Einsparung von Lizenzgebühren, sondern darin, dass der Anwender selbst bestimmt, ob und wann er Upgrades vornimmt. Gerade die Einsparung unnötiger Versionsupgrades wirkt sich mittel- und langfristig vor allem auf das aus, was hierzulande wirklich teuer ist: die Personalkosten, die für die IT-Administration aufgewendet werden.
Debian kaum besser als die Kommerziellen
Kein Wunder, dass ein Securityfocus-Artikel zu diesem Thema [www.securityfocus.com/columnists/142] regelrecht Furore machte. Dessen Zielscheibe waren jedoch nicht nur Red Hat und Mandrake, sondern auch das Debian-Team bekam gehörig sein Fett weg, zumindest was die Kurzfristigkeit von Ankündigungen zum Ende des Supports betrifft. Mit nur zwei Wochen Vorwarnung hatte das Projekt Mitte September 2000 angekündigt, Debian 2.1 ab 30.9.2000 Support-mäßig komplett fallen zu lassen, obwohl die Folgeversion gerade erst einen Monat zuvor freigegeben worden war.
Wer hier einwendet, zumindest bei kommerziellen Distributionen sei das doch gar nicht so schlimm, denn dafür gebe es schließlich bei Red Hat und SuSE die Advanced-Server- beziehungsweise Enterprise-Server-Versionen mit fünf Jahren Support, der verkennt das Problem. Denn das Vermeiden unnötiger Versionswechsel gerät aus wirtschaftlichen Gründen auch bei Desktops zum Muss: Schon wegen ihrer schieren Anzahl macht es gerade bei Desktops Sinn, über einen möglichst langen Zeitraum hinweg die gleiche Linux-Version beizubehalten, aber dennoch notwendige Patches und Sicherheitsfixes einzuspielen.
Stellt der Distributor jedoch nach einiger Zeit keine passenden Pakete mehr zur Verfügung, hat der Anwender hier ein deutlich größeres Problem als auf der Serverseite, denn auf Desktops sind typischerweise wesentlich mehr Softwarepakete installiert.
Support ist nicht nur Kostenfaktor
Da die Abhängigkeiten der Pakete untereinander aber nicht-linear zunehmen, wird das Problem der Paketabhängigkeiten schnell unbeherrschbar, sobald man versucht, einzelne RPMs ohne Unterstützung des Distributors zu erneuern. Gerade hier ist es unabdingbar, dass er auch nach deutlich mehr als zwei Jahren passende, neue RPMs schnürt. Wenn er dabei für seine Bemühungen Bares verlangt, ist das durchaus fair. Dass Distributoren diesen Bedarf nicht erkennen, sondern den Support für Desktopversionen lediglich als Kostenfaktor betrachten und deshalb möglichst schnell einstellen wollen, zeugt eher von geschäftlichem Unverstand.
Einen ersten Schritt in die richtige Richtung machte SuSE mit der Ankündigung vom 9. Juni 2003, bei der für die neue, gut 100 Euro teure Linux-Desktop-Version eine “fünfjährige Systempflege” versprochen wird. Was auf den ersten Blick das Malheur zu beheben scheint, sorgt bei genauerem Hinsehen jedoch für Ernüchterung: Wartungsverträge für all jene Versionen, die heute im Feld sind, bieten die Nürnberger damit keineswegs an – und der Anwender steht weiterhin im Regen. Und ob SuSE die für die Linux-Desktop-Ausgabe notwendige Qualitätssteigerung hinbekommt, weiß vorerst auch noch niemand.
Heiße Nadel nützt keinem
Allem Anschein zum Trotz ist Software-Administration auf Servern oft wesentlich einfacher, da die Anzahl der installierten RPMs meist relativ überschaubar ist. Der Support des Herstellers verliert sogar an Gewicht, sofern der Anwender bereit ist, sich notwendige Fixes und Updates einzelner Pakte selbst zu besorgen, und notfalls auch als Nicht-RPM zu installieren.
Also doch auf kommerzielle Supportangebote verzichten? Wohl eher nicht, denn beide Seiten brauchen diesen Service schon aus rein ökonomischen Gründen. Allerdings ist dazu auf Distributorenseite zunächst eine Reihe von Hausaufgaben zu erledigen. Alle kommerziellen Anbieter täten gut daran, den Teufelskreis kurzer Distributionszyklen möglichst schnell zu durchbrechen. Ihr Interesse kann es auf Dauer nicht sein, in immer kürzeren Zeitabständen mit heißer Nadel Gestricktes auf den Markt zu werfen und sich anschließend zu verrenken, um den Fluch der bösen Tat und den eigenen Pfusch bei der Distributions-Zusammenstellung nicht selbst ausbaden zu müssen.
Weniger ist mehr
Geschäftliche Klugheit liegt darin wohl kaum, denn Geld verdienen sie mit hektischem Boxenschieben nun wirklich nicht. Nicht nur für Kunden, sondern auch für Distributoren würde es sich rechnen, nur halb so oft neue Versionen herauszubringen, dafür aber den doppelten Preis zu verlangen. Mit dem Erlös könnte nicht nur eine deutlich bessere Qualitätssicherung bei der Distributions-Zusammenstellung finanziert werden, sondern auch die Zurverfügungstellung von Sicherheitsupdates über einen deutlich längeren Zeitraum als bisher. Außerdem müsste der Distributor weniger Versionen gleichzeitig supporten und könnte das Know-how seiner Mitarbeiter deutlich besser bündeln.
Die Anbieter können es sich durchaus gesondert honorieren lassen, Patches für weit zurückliegende Versionen verfügbar zu machen. Der Arbeitsaufwand und damit auch der Preis dafür sollten sich sich in Grenzen halten lassen. Der Kunde entscheidet dann, ob er den Extra-Obolus entrichten will oder stattdessen auf eine neuere Version umsteigt.
Darf’s auch etwas BSD sein?
Um jenen Abhängigkeiten zu entgehen, die von Distributoren mittels proprietärer Tools und stark eingeschränkter Supportzeiträume gezielt gefördert werden, sollte man sich als Anwender wirklich fragen, ob es nicht von vornherein Debian sein darf – oder besser gleich FreeBSD, zumindest dann, wenn es wirklich um die Wurst geht.
Gerade in FreeBSD steckt Erfahrung, die jedes Linux, auch Debian, an etlichen Stellen noch vor sich hat. Beide erfordern zwar einmalig mehr Arbeit beim Einstieg, doch der wiederkehrende Aufwand für Updates und Versionswechsel ist deutlich geringer und das Prinzip der BSD Ports Collection ist fast unschlagbar, auch wenn Debian-Fans das naturgemäß meist anders sehen.
Persönlich sähe ich es nur ungern, wenn Microsoft dank kommerzieller Distributoren eines Tages mit der Behauptung Recht behielte, Linux sei eben doch recht teuer – vor allem wegen der Personalkosten für häufige Upgrades zu neueren Versionen. (uwo)
|
Der |
|---|
|
Eitel Dignatz ist Unternehmensberater und der Inhaber von Dignatz Consulting in München: [http://www.dignatz.de/spot333] |







