Unter dem Titel „Open Source erzeugt unzuverlässige Software und Umgebungen“ veröffentlichte ein Kommentator in der FAZ unter dem Namen „Wolfgang May“ sinngemäß:
- Open source funktioniere nicht zuverlässig
- Der zuständige SysAdmin könne nicht weiter helfen und verweise stattdessen auf die Beteiligungsmöglichkeit
- Führe zu Wildwuchs
- Sei von Nerds und für Nerds
- Sei bei der Online-Lehre der Uni in Verwendung und genüge dabei nicht seinen Ansprüchen
Was ist dran, an diesen Aussagen?
Punkt 1: Funktioniert (nicht)? zuverlässig
Die Software-Qualität von open source Produkten schwankt genau wie die proprietärer Software. Klar ist aber auch, dass man schlechte Qualität wegen des offenliegenden Quellcodes leichter erkennen kann.
Punkt 2: SysAdmin kann nicht weiterhelfen
Wie läuft das üblicherweise? Nutzende wünschen sich einen Dienst, z.B. eine Cloud oder einen Dienst für Vorlesungsaufzeichnungen, oder einen für Videokonferenzen. Der Zuständige IT-Versorger legt den Entscheidern eine Beschlussvorlage vor:
- Option: Open source + wenig zusätzliches Personal + kleiner Support-Vertrag
- Option: Open source + ausreichend zusätzliches Personal
- Option: Gut gewartetes Softwareprodukt + großer Support-Vertrag
- Option: Betrieb außerhalb der Zuständigkeit des IT-Dienstleisters: Software-as-a-Service (im eigenen Rechenzentrum, also on-premise oder im Rechenzentrum des Anbieters, häufig „Cloud“ genannt)
Bei Option 1 könnte sich eine Person gezielt in die Software einarbeiten und über den Support-Vertrag stellt man sicher, dass Änderungswünsche auch Eingang in ein Hauptentwicklungsrepository finden, oder er bietet Unterstützung bei den besonders kniffligen Fällen, die viel Produkt-Wissen erfordern.
Option 2 ermöglicht es, dem lokalen Personal, Teil der Entwickler-Community zu werden, an Jour Fixes und regelmäßigen Arbeitstreffen des Projekts teilzunehmen. Auch so können Änderungswünsche z.B. eines Informatikprofessors nachhaltig in das Projekt einfließen und gemeinschaftlich gewartet werden.
Mit Option 3 belastet man zwar das Personal ebenfalls zusätzlich; wenn alle Stricke reißen, kann man die Probleme aber auf den Support-Dienstleister abschieben, der wegen des Vertragsvolumens auch genügend Kapazitäten eingeplant haben wird.
Bei Option 4 mietet man sich quasi den Software-Betrieb und der lokale IT-Dienstleister gibt nur Probleme und Änderungswünsche an den Betreiber weiter.
Jede der Optionen ist meist zu teuer. Es ist ja nur Geld für Projekte da. Da leistet sich Uni Institut X, Stabsstelle Y, oder Zentrale Einrichtung Z eine Parallelinstallation der gleichen open source Software mit viel besserer finanzieller Ausstattung als der zentrale Dienstleister sie zur Verfügung hat und Hochglanzoberfläche. Wenn die gekaufte Software dann nicht auf Anhieb läuft, kann man ja beim zentralen Dienstleister anfragen. Oder man versucht sie nach Auslauf der 2 Jahre Premium-Support, die man mitgekauft hat, an den zentralen Dienstleister abzuschieben. Oder Informatikstudierende haben etwas gutes gebaut, schließen jetzt aber leider ab und gehen weg. Auch dann ist es einen Versuch wert, den Dienst an den zentralen Dienstleister abzugeben? Geld für die Einstellung der Studierenden nach deren Abschluss oder den Abschluss eines Support-Vertrages mit ihnen hat man ja leider nicht.
Entscheider wählen dann Option 0: Open source ohne zusätzliches Personal und ohne Support-Vertrag. Das Ergebnis: Der SysAdmin hat bei gleicher Arbeitszeit einen weiteren Dienst vor sich und weder Zeit für die Einarbeitung in den Code, noch die Changelogs bei Updates gründlich zu lesen.
Irgendwann funktioniert etwas nicht mehr, wie der Endnutzer es erwartet und der SysAdmin hat keine Zeit für Support.
Punkt 3: Wildwuchs
Es ist richtig, dass offene Systeme auch dazu einladen, mitzuwirken und dann wieder zu verschwinden, wenn es sich nicht lohnt. Das trifft aber nicht nur auf OSS zu und die Folgen sind häufig weitaus weniger problematisch als bei SaaS-Lösungen auf Closed Software-Bases, die man dann nicht mal eben so weiter betreiben kann.
Wichtig ist deshalb, dass man Projekte, welche die selbst genutzten Dienste entwickeln, ausreichend unterstützt, so dass sie weiter aktuell und fehlerfrei gehalten werden können. Das funktioniert zum einen über Vereinsmitgliedschaften und zum anderen durch Support-Verträge mit denjenigen, die sich maßgeblich an der Entwicklung beteiligen, auch wenn beides durch das deutsche Vergaberecht nicht ganz einfach umzusetzen ist.
Aber wer zahlt schon für Basisunterstützung? Gefordert werden immer Features. Sicherheit und Robustheit bringen ja keinen sofortigen Mehrwert.
Punkt 4: Nerd2Nerd
Bei Option 2 sollte der zuständige SysAdmin oder ein Entwickler im Haus ziemlich genau wissen, wie die Software funktioniert und sie so einrichten, dass sie intuitiv durch Nutzende bedienbar ist. Womit wir wieder bei Punkt 2 angelangt wären; wahrscheinlich wurde Option 0 durch die Entscheider gewählt.
Punkt 5: Online-Lehre
Einfach mal beim IT-Dienstleister anfragen, wie viele Ressourcen (Geldmittel, Personenarbeitsstunden) in die Online-Lehre, die ja häufig etwa das 10-fache an Nutzendenzahlen verglichen z.B. mit der übrigen Universitätsverwaltung hat, gehen. Kommt bestimmt raus, dass allein Stabs- und Pressestellen mehr verschlingen.
Plant Ihre Uni auch die Einführung von HISinOne oder nutzt es schon? Dann erfragen Sie mal die Kosten für die HIS-Mitgliedschaft und die, die für ihr aktuelles Lern-Management-System.
Unzufrieden mit dem Videokonferenzsystem? Big Blue Button oder Jitsi und Option 0 gewählt?
Ihr Chat versendet keine Push-Nachrichten? RocketChat und Option 0 gewählt?
Ich habe folgende Erfahrung gemacht: Ein Dienst funktioniert nicht den Nutzererwartungen entsprechend → man kauft eine SaaS-Lösung oder Closed-Source-Produkt mit Wartungsvertrag und gibt viel mehr Geld aus, als man zuvor in ein gleichwertiges open source Produkt hinein gesteckt hätte.
Auf die Idee, Support-Verträge abzuschließen oder sich langfristig für eine nachhaltige Entwicklung einzusetzen kommt man dagegen eher nicht.
Fazit
Nicht open source erzeugt diese unzuverlässige Software und Umgebungen, sondern mangelndes Wissen über open source und mangelnde Ausfinanzierung im Vergleich zu den gestellten Anforderungen.