Beta-Software im Produktivbetrieb
Diesen Beitrag schrieb ich 14 Jahre und 10 Monate zuvor; die nachfolgenden Ausführungen müssen heute nicht unbedingt noch genau so funktionieren. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
„Software is like sex: it’s better when it’s free.“
OpenSource ist die deutliche Kampfansage den üblichen kommerziellen Software-Angeboten gegenüber, und der Grundgedanke dahinter ist schön: Software die nichts kostet, die aufgrund offener Quellen an eigene Bedürfnisse angepasst werden kann, Weiterentwicklung anhand des Feedbacks der User, Abkehr vom Mainstream, Individualität. In den Köpfen so mancher hat sich leider die Denkweise durchgesetzt, dass Betriebssysteme und -programme keinen Kostenfaktor darstellen, darstellen dürfen.
Die Repositories sind voll, und prinzipiell findet sich für jede Anwendung das gewünschte Tool; was sich auf der Website so gut liest sind in Wirklichkeit aber vielleicht drei Schüler, die irgendwann ein halbgares Projekt anfingen und es in drei Wochen aufgeben werden. Support? Jedes Projekt, das etwas auf sich hält, bietet einen unübersichtlichen Wust an Mailinglisten (wehe, du schreibst dein Anliegen an die falsche!), einen Wiki (meist mangelhaft gepflegt, und im schlimmsten Fall verweist jeder zweite Link auf ein „Coming soon… (hopefully)“) oder gar ein Webforum, in dem erst einmal eine Registrierung fällig ist. Hat man es denn geschafft, den richtigen Weg für eine Anfrage oder einen Bugreport zu finden, sind die Möglichkeiten für den weiteren Verlauf zahlreich:
- In vielen Fällen erhält man überhaupt keine Antwort; das Problem habe ich oft, wenn ich per Google nach einer Fehlermeldung fahnde – die Frage wurde schon zigmal gestellt, doch nie beantwortet.
- Oft erhält man unbrauchbare Antworten; plötzlich findet man sich in einer Diskussion über irrelevante Teilaspekte wieder und merkt, dass viele der anderen offenbar noch ratloser sind als man selbst (bloß geben die’s halt nicht zu). Abschuss sind Tickets, die innerhalb weniger Minuten geschlossen werden mit dem fast schon dreisten Kommentar „Wir wissen, dass das nicht geht, wir kümmern uns aber nicht drum; du kannst uns ja einen Patch schicken und wir gucken dann, ob wir ihn einbauen…“.
- Hin und wieder erhält man tatsächlich hilfreiche Antworten; diese können aber durchaus mit einigen Tagen Verzögerung eintrudeln.
Soweit so gut; Beta-Software stellt dementsprechend eine nicht unwesentliche Steigerungsstufe des eben genannten dar. Der für mich wesentlichste Unterschied ist, dass die Dokumentation hier noch beschissener bzw. schlichtweg nicht vorhanden ist. Patches fliegen innerhalb kürzester Zeit auf den Download-Server, und die Updates beziehen sich in aller Regel auf critical bugfixes. Offenbar ist der Kostenfaktor aber das einzige, was zählt; und OpenSource-Software ist per Definition klasse, da kann man ruhig Beta einsetzen. Produktiv.
Mir stehen da regelmäßig die Haare zu Berge; bei meinen Heimanwendungen kann ich es verschmerzen wenn mal etwas nicht geht, wenn eine Anfrage tagelang nicht auf Resonanz stößt, wenn der Fehler erst im nächsten Release behoben wird – oder gar nie. Aber produktiv? Die Einrichtung der Software kostet, wenn nicht sauber dokumentiert, ein x-faches an Zeit (die ja bekanntermaßen auch Geld ist), und das ständige Troubleshooting im laufenden Betrieb zusätzlich – nur hat man dann, wenn’s dumm läuft, auch noch einen gereizten Kunden an der Backe, den man beruhigen muss. An das ständige Einspielen der ständig erscheinenden Patches traut man sich garnicht richtig dran – und wenn sie dreimal critical sind, so hat man über die Mailingliste doch schon erfahren, dass andere Anwender nichts wie Ärger hatten nach dem Update.
Auf Produktivsystemen hat Beta-Software nichts zu suchen, so einfach ist das. Je nach Anwendungsgebiet sollte man überhaupt hinterfragen, ob der Einsatz einer Software ohne jeden wirklichen Support sinnvoll ist. Oder ob die paar Kröten für einen wirklich fähigen Hotliner sich nicht doch lohnen würden.