Open Source in Behörden einführen: dein operativer Fahrplan

Der schwierige Teil einer Open-Source-Einführung ist selten die Technik der Arbeitsplätze. Ein Ubuntu- oder Linux-Mint-Client mit LibreOffice ist in wenigen Wochen paketiert. Aufwendig sind die Ränder: Fachverfahren, die nur mit Internet Explorer, ActiveX oder einer Windows-only-Clientkomponente laufen, Signaturkarten und Kartenleser, Fachanwendungen mit proprietären Druckertreibern, Makro-lastige Excel-Vorlagen aus zwanzig Jahren Verwaltungspraxis sowie Verzeichnisdienst, Gruppenrichtlinien und Dateifreigaben, die auf Active Directory aufsetzen.

Dazu kommt die Betriebsseite. Wer Windows-Clients bisher über ein zentrales Managementsystem verteilt hat, braucht für Linux ein funktionierendes Äquivalent für Imaging, Paketquellen, Patchstände und Konfiguration, typischerweise über eigene Spiegel-Repositories, Konfigurationsmanagement mit Ansible und ein Monitoring, das den neuen Stack auch abbildet. Ohne diese Grundlagen wird der Pilot zwar bunt präsentiert, lässt sich aber nicht auf mehrere hundert Arbeitsplätze skalieren.

Der dritte und meist unterschätzte Punkt ist Personal. In vielen Häusern gibt es zwei bis drei Kolleginnen und Kollegen mit Linux-Erfahrung, aber keine Breite im Team und keine Vertretungsregelung. Typische Fehler sind deshalb: zu früh in die Fläche gehen, den Schulungsaufwand für Anwender und Administration nicht als eigene Position im Projektplan führen, den First-Level-Support nicht mitschulen und externe Dienstleister ohne internen Wissensaufbau beauftragen. Danach hängt der Betrieb an einzelnen Personen, und genau das war das Argument gegen die alte Abhängigkeit.