Open Source Software

Unter dem Titel „Open Source erzeugt unzuverlässige Software und Umgebungen“ veröffentlichte ein Kommentator in der FAZ unter dem Namen „Wolfgang May“ sinngemäß:

1. Open source funktioniere nicht zuverlässig
2. Der zuständige SysAdmin könne nicht weiter helfen und verweise stattdessen auf die Beteiligungsmöglichkeit
3. Führe zu Wildwuchs
4. Sei von Nerds und für Nerds
5. 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:

1. Option: Open source + wenig zusätzliches Personal + kleiner Support-Vertrag
2. Option: Open source + ausreichend zusätzliches Personal
3. Option: Gut gewartetes Softwareprodukt + großer Support-Vertrag
4. 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.

Bezahlpflichtige Software ist in verschiedenen Preismodellen erhältlich. Manchmal bezahlt man pro Person, manchmal pro Rechenmaschine, auf der die Software installiert oder ausgeführt wird.

Damit nicht mehr Lizenzen genutzt werden, als eingekauft wurden, und dem System-Admin dennoch eine Installation und Verteilung von Einzelschlüsseln erspart bleibt, verlangt manche Software die Installation und den Betrieb eines Lizenzservers. Das hat im Regelfall den Vorteil, dass die Software auf vielen Rechnern vorinstalliert und auf beliebigen Rechnern genutzt werden kann.

Startet ein lizenziertes Programm am Arbeitsplatzrechner, meldet es sich beim Lizenzserver und dieser meldet zurück, ob noch Lizenzen frei sind. Wird das Programm geschlossen, wird auch das an den Server gemeldet und der kann nun wieder eine Lizenz mehr herausgeben.

Problem 1: Arbeitsplatzrechner stürzt ab

Stürzt ein Arbeitsplatzrechner ab oder wird er vom Netzwerk vor Beendigung des lizenzpflichtigen Programms getrennt, kann keine Meldung an den Lizenzserver erfolgen, dass wieder eine Lizenz frei ist. Im Extremfall wird der Lizenzserver dem Arbeitsplatzrechner bei dessen Neustart eine neue Lizenz zuteilen, oder, wenn keine Lizenz mehr übrig ist, dem Rechner sagen: Du darfst das Programm nicht mehr starten, weil das Lizenzkontingent ausgeschöpft ist.

Das wäre ja ganz einfach zu beheben denkt man; die aktiven Programme müssten dem Server nur regelmäßig sagen, dass sie die Lizenz noch benötigen und der Lizenzserver könnte Lizenzen inaktiver Rechner freigeben. Leider hat sich gezeigt, dass Herstellern das zu kompliziert ist, und die einzige Lösung bei Lizenzknappheit in Folge neustartender Arbeitsplatzrechner der Neustart des Lizenzservers ist. Manchmal mit der Folge, dass laufende Programme mit zugewiesener Lizenz dann auch nicht mehr wollen.

Problem 2: Der Lizenzserver stürzt ab oder läuft nicht

Dann kann das lizenzpflichtige Programm auf dem Arbeitsplatzrechner auch nicht starten. Ungünstig, wenn das Softwareprodukt auf einer gerade laufenden Tagung eingesetzt werden soll.

Kommen euch die Update-Beschreibungen einiger Apps aus dem Google Play Store und dem Apple App Store auch so nichtssagend vor? Manche Hersteller schreiben dauerhaft hin, dass sie ihre App immer besser machen.

Problem 1: Daten

In den meisten Fällen hat der Kunde keine Chance zu erfahren, ob er von einer Sicherheitslücke durch die Nutzung der App betroffen war, weil weder die Beschreibung das eindeutig sagen, noch ein Zugriff auf den Quellcode besteht. Die Hersteller sollten dem Kunden nach DSGVO zwar Bescheid sagten, aber gemessen an der Anzahl von Datenlacks, wie häufig wurden Sie schon benachrichtigt?

Problem 2: Änderungen

Auch wenn ein Update nur verschiedene Bugfixes und performance improvements verspricht, werden doch gelegentlich grundlegende Funktionen geändert. Stellen Sie sich eine Closed Source Umfragesoftware vor, nennen wir sie AdamSys, die einen Auswertungsalgorithmus ändert oder die Darstellung. Sie hätten keine Möglichkeit ohne den Hersteller zu erfahren, was genau geändert wurde.

Fragt man bei Auskunftspflichtigen, beispielsweise einer Verwaltungseinheit, die fast ausschließlich mit personenbezogenen Daten hantiert nach, was bestimmte Softwareprodukte ohne Quellcodeoffenlegung mit eingebauter Telemetrie nun genau an den Hersteller übermitteln, und ob darunter auch personenbezogene Datein sein könnten, wenn sie bei einem Crash zufällig diese gerade verarbeiteten, erhält man meist Achselzucken oder Beschwichtigungen als Antwort.

Unübertroffen an Aufwand ist der Lizenzaudit. Gebunden an die Nutzung bestimmter Software ist das Recht der Hersteller einen anlasslosen Lizenzaudit durchzuführen.

Wie läuft so etwas ab? Der Hersteller selbst oder eine von ihm beauftrage Firma verlangt, einen bestimmten Prozentsatz der Rechner auf den Einsatz ihrer Software untersuchen zu dürfen. Zusätzlich dürfen Sie Kennzahlen und weitere Antworten zuarbeiten.

Wenn der Hersteller die Untersuchungsmethode ungünstig vorgibt, besteht auch die Gefahr, dass er im Rahmen dieses Audits personenbezogene Daten zu Gesicht bekommt, die er niemals hätte sehen sollen. Man stelle sich folgendes Szenario vor: Die Firma Büromaschinen möchte wissen, ob ihr Name irgendwo in Dateien auf den gewählten Servern vorkommt und Sie haben dort eine Datenbanksicherung liegen, die eine Tabelle Benutzer enthält:

Benutzer(name, pass_hash, hobbies)

Hat ein Benutzer ein Hobby, das mit Büromaschinen zu tun hat, so stehen die Chancen gut, dass mindestens der Datensatz dieses Benutzers während des Audits angezeigt wird. Sowohl die Hobbies, als auch das Passwort sind für den Auditor aber eigentlich Tabu.

Da nicht jeder Rechner von der gleichen Person betreut wird und solche Datenleaks durch Wissen über die auf den Rechnern liegenden Daten verhindert werden muss, muss nahezu die gesamte Einrichtung am Audit mitwirken. Insgesamt kann das gern über 20 Personenarbeitsstunden kosten.

Damit ist es aber noch nicht getan. Im Vorfeld müssen die Bedingungen vereinbart und gesampelt werden. Und wenn man so etwas nicht regelmäßig von der gleichen Firma hat, prüft man natürlich auch nochmal die Lizenzverträge und -nutzung.

Kennt ihr das? Die Kolleg*innen, die gerne einer Blackboxsoftware ihre personenbezogenen Daten oder genialsten Ideen anvertrauen, haben eine Software bestellt, aber der Schlüssel wird an andere zugestellt, z.B. die Softwarebeschaffung oder den Support, die aber gerade im Urlaub sind? Auf der Suche nach ihrem Schlüssel fragen sie sich durch die ganze Einrichtung, nur um resigniert feststellen zu müssen, dass sie aktuell nicht an ihren Lizenzschlüssel kommen.

Huch, schon wieder abgelaufen. Schnell nachkaufen! Über 500 Euro? Dann geht’s nach VOL/A wohl mindestens in die freihändige Vergabe und etwa 14 Tage Geduld für einen fairen Bieterwettbewerb und den juristischen Overhead.

Lizenzbeschaffung kostet Zeit, nicht nur auf gemeinsamen Sitzungen; wenn man merkt, dass es zu spät zum Ausdrucken oder Rendern des fertigen Videos ist, sondern auch die Zeit von Vergabejursten. Und dann muss die (häufig) billigste Firma auch noch liefern. Selbst nach erfolgreicher Beschaffung hat man meist nur die Lizenz, keinen Support und niemanden den man fragen kann.