Auf Mastodon ansehen
Für ein optimales Hörerlebnis empfehlen wir, eine Podcatcher-App zu verwenden. Zum Beispiel:
- AntennaPod (Android)
- gPodder (Desktop)
- GNOME-Podcast (GNOME-Desktop)
- Kast (KDE-Desktop)
- PodPhoenix (Ubuntu-Touch)
Der RSS-Feed für den Podcast lautet: https://gnulinux.ch/podcast/gnulinux_newscast_rss.xml. Ihr findet uns in den Podcast-Verzeichnissen unter dem Suchbegriff: "GNU/Linux".
Wenn euch der Podcast gefällt, freuen wir uns über eine Unterstützung. Vielen Dank!
Shownotes
CIW - Folge 196 - 07.10.2026 - Migrationsangst
- Wir begrüssen alle Zauderer zur Folge 196 von "Captain it's Wednesday", dem Podcast über Freie Software und Freie Gesellschaft von GNU/Linux.ch, aufgenommen am 26. September von Michel Ketterle und Ralf Hersel. In dieser Folge reden wir über mögliche Gründe, die Unternehmen den Umstieg auf Freie Software erschweren.
Hausmitteilungen
- keine
Thema: Warum zögern Unternehmen bei der Umstellung auf Freie Software?
Die Zurückhaltung gegenüber Open-Source-Anwendungen hat meist weniger mit der Software selbst zu tun als mit organisatorischen, wirtschaftlichen und psychologischen Faktoren. Die Gründe lassen sich in mehrere Kategorien einteilen:
Strategische und organisatorische Gründe
Bei proprietärer Software gibt es einen klaren Hersteller, der für Support, Fehlerbehebung und Weiterentwicklung verantwortlich ist. Bedenken: Wer haftet bei Problemen? Wer garantiert die Weiterentwicklung? Wer ist Ansprechpartner bei Sicherheitsvorfällen?
Viele Organisationen bevorzugen einen festen Lieferanten mit: Service Level Agreements (SLAs), definierten Eskalationswegen, langfristigen Verträgen. Open Source wird oft als „Community-getrieben“ wahrgenommen, auch wenn es kommerzielle Anbieter gibt.
Viele Firmen hätten gerne Dienstleister, die in der Gegend tätig sind und ggf. schnell vorbeikommen können. In diesem Zusammenhang weisen wir auf das neue Partnerprogramm des ZenDiS hin.
Behörden und grosse Unternehmen sind typischerweise risikoarm organisiert. Das Motto lautet häufig: Niemand wird entlassen, weil er Microsoft, SAP oder Oracle gekauft hat. Für Open Source muss die Entscheidung oft stärker begründet werden.
Wenn auch nur ein Windows-System vorhanden ist, muss man sich auch um die Administration des Gerätes kümmern und geschäftliche Lizenzen dafür kaufen. Viele Firmen haben ein/zwei Anwendungen/Server und/oder Clients, die nicht gewechselt werden können.
Wirtschaftliche Gründe
Die Lizenzkosten entfallen zwar, andere Kosten bleiben jedoch bestehen: Einführung, Schulung, Betrieb, Integration, Migration, Support. Dadurch entsteht häufig die Wahrnehmung: Kostenlos in der Anschaffung bedeutet nicht kostenlos im Betrieb.
Viele Organisationen haben bestehende Investitionen in: Microsoft 365, SAP, Oracle, Fachapplikationen. Ein Wechsel verursacht: Datenmigration, Prozessanpassungen, Schulungen, Parallelbetrieb. Diese Kosten übersteigen oft die eingesparten Lizenzkosten.
Langfristige Verträge mit Herstellern machen einen Wechsel wirtschaftlich unattraktiv (Lock-in Effekt).
Die langfristeigen Verträge sind nicht wirklich relevant. Sie erfordern es lediglich, dass man den Wechsel auf das bestimmte Datum hin plant. Solche Wechsel dauern ohnehin sehr lange.
Technische Gründe
Sorge vor Problemen bei der Kompatibilität von Dateiformaten, Schnittstellen, Fachanwendungen, Hardware-Treibern.
Hardware und Treiber sollten kein Problem mehr darstellen. Schnittstellen auch nicht mehr zwingend. Was fehlt, sind die schon fertig programmierten Hilfsmittel, die ein Tool ergänzen. Anpassungen müssen immer erst entwickelt werden. Mir sind Fälle bekannt, in denen man sogar Treiber deaktiviert hat, weil ein Spezialfeature nur Neid hervorgebracht hätte.
Open-Source-Lösungen müssen oft integriert werden in: Active Directory, Identity Management, ERP-Systeme, Dokumentenmanagement, Fachanwendungen.
Fertige bekannte Integrationen und Presets fehlen komplett. Hier muss alles selbst erarbeitet werden. Bei Microsoft sind zumindest ihre Tools und Oberflächen schon bekannt.
Nicht alle Open-Source-Produkte bieten dieselbe Funktionstiefe wie etablierte kommerzielle Lösungen. Besonders kritisch sind: Spezialsoftware, Branchenanwendungen, CAD-Systeme, Engineering-Lösungen.
Eine praxistaugliche Lösung ist ein hybrider Ansatz: Open-Source-Produkte werden dort eingesetzt, wo sie funktional ausreichen, während für Spezialsoftware, Branchenanwendungen, CAD- und Engineering-Lösungen gezielt etablierte kommerzielle Systeme genutzt und über standardisierte Schnittstellen integriert werden.
Sicherheits- und Compliance-Gründe
Obwohl Open Source oft sehr sicher ist, existiert die Vorstellung: Jeder kann den Quellcode sehen, also auch Angreifer. Technisch ist dies nicht zwangsläufig ein Nachteil, beeinflusst aber Entscheidungen.
Ich denke nicht, dass das noch Gültigkeit hat. Ich denke, dass Linux im Compliance-Bereich sogar die Nase vorn hat.
Organisationen müssen Vorgaben erfüllen bezüglich: Datenschutz, Informationssicherheit, Auditierbarkeit, Zertifizierungen. Fragen sind beispielsweise: Wer garantiert die Einhaltung? Gibt es ISO- oder Branchenzertifizierungen? Wie werden Sicherheitsupdates bereitgestellt?
Open-Source-Lizenzen können komplex sein (GPL, LGPL, AGPL, Apache, MIT). Rechtsabteilungen fürchten: Lizenzverletzungen, Offenlegungspflichten, Haftungsfragen.
Eine der ersten Fragen, die man sich stellen wird, ist: Wie sichere ich Laptops der Mitarbeiter im Aussendienst ab?. Festplattenverschlüsselung, Fingerprint-Access. Remote-Wipe. Und hier hapert es bei Linux
Personelle Gründe
Viele IT-Abteilungen sind stärker auf proprietäre Produkte spezialisiert. Es gibt oft mehr Experten für Windows, Microsoft 365, Azure als für Linux, Kubernetes, PostgreSQL, Nextcloud usw.
Selbst wenn die IT Erfahrungen mit Linux hat, sind es meist nur die von Anwendern.
Ein Technologiewechsel erfordert Weiterbildung der IT, Schulung der Benutzer, neue Betriebsprozesse. Das verursacht kurzfristige Produktivitätseinbussen.
Eher langfristig, da so eine Administration komplett neue Tools und Arbeitsweisen erfordert. Selbst Linux-interessierte Windows-ITler haben unter Linux kaum Terminalerfahrungen. Die Schulung - integriert in den allgemeinen Arbeitsalltag - und fehlende Erfahrungswerte können die Produktivität noch lange reduzieren.
Politische und kulturelle Gründe
Menschen bevorzugen bekannte Werkzeuge. Typische Aussagen sind „Mit Microsoft funktioniert es doch”, oder „Das haben wir schon immer so gemacht.“
Das wird meist heisser gekocht, als es am Ende gegessen wird. Das Problem ist eher, dass geänderte Abläufe schlecht designt sind und kritische Mitarbeiter bei den ersten Schritten nicht begleitet werden. Kritische Mitarbeiter dürfen auch dafür gelobt werden und sie gebeten werden zu helfen die kritischen punkte zu verbessern. Gleichzeitig muss man sie auch darauf hinweisen, dass es kein zurück mehr gibt.
Bekannte Hersteller vermitteln Sicherheit: Microsoft, SAP, Oracle, Salesforce. Open-Source-Projekte besitzen oft weniger Markenbekanntheit, auch wenn sie technologisch führend sind.
Ein Wechsel verändert Verantwortlichkeiten, Budgets, Zuständigkeiten, Lieferantenbeziehungen. Dadurch entstehen interne Widerstände.
Ein kritisches Element ist auch, wie man den Wechsel organisiert. Welche Abteilung wechselt man zuerst? Wie teste ich die neuen Workflows?
Beschaffungs- und Vergabegründe
Beschaffungsstellen kaufen oft lieber Produkte, Wartungsverträge, und klar definierte Leistungen als Community-Projekte. Bei einer Beschaffung müssen Kriterien dokumentiert werden, wie z. B. Herstellerstabilität, Supportfähigkeit, Referenzen und Marktpräsenz. Bei Open Source ist dieser Nachweis manchmal schwieriger.
Ein Thema, das man lange diskutieren könnte:
Eine IT‑Abteilung hätte lieber einen Vertrag mit einem Unternehmen als zu spenden, weil Verträge dauerhafter und stabiler sind.
Eigentlich müsste nicht viel in einen Vertrag. Aber auch kleine Softwarehersteller wollen t.w. keine Verträge eingehen, weil dann plötzlich der Staat mit seiner Bürokratie daher kommt.
Psychologische Gründe
Entscheidungsträger kennen häufig die Risiken eines bestehenden Systems besser als die Risiken einer Alternative. Das führt zum sogenannten Status-quo-Bias: Bekannte Probleme werden gegenüber unbekannten Chancen bevorzugt.
Gilt nur, wenn der Entscheidungsträger nicht aus der IT kommt. IT-ler wissen, dass keine Änderung des Systems – und sei es nur ein Upgrade von Win 10 zu Win 11 – problemlos ist.
Bei einer Fehlentscheidung mit einer bekannten kommerziellen Lösung lässt sich die Verantwortung leichter rechtfertigen als bei einer weniger verbreiteten Open-Source-Lösung.
Fazit
Interessanterweise zeigen viele erfolgreiche Open-Source-Einführungen, dass die technischen Gründe oft weniger entscheidend sind als die organisatorischen und kulturellen. Die grössten Hürden liegen meist nicht in der Software, sondern in den Prozessen und Strukturen der Organisation.
Ich denke, die Grösse der IT‑Abteilung könnte hier auch noch entscheidend sein.
Was wäre nötig, damit Firmen leichter migrieren können?
Einfach die Stärke von Linux ausspielen. Es müsste ein kostenloses Set an VMs geben, vorkonfiguriert zu einer virtuellen Firma. Client-Rechner, verschiedene vorkonfigurierte User und Admins (für ein modernes Rechtemanagement), Firewall, User- und Berechtigungsadministration, Mailserver, Fileserver, On-Premise-Firmen-Cloud, eine BackupVM, ein einfaches kostenloses ERP, ein DMS.Alles state of the Art in VLANs unterteilt und ready-to-use vorbereitet. Per Image auf einen PC installierbar. Folge einem Wizard und am Ende läuft ein Basic-Firmennetz. Das z. B. auch Startups nutzen könnten. Admins könnten da das Aufsetzen neuer PCs üben, neue User anlegen und andere Daily-Business-Administration testen. Mags der Admin, ist das Wichtigste geschafft.
Outro
Euer Feedback zählt! Kommentiert zur Podcast-Folge oder schreibt uns einfach über Matrix, Mastodon oder per E‑Mail. Nehmt aktiv an der Community teil. Ihr könnt Artikel schreiben, Themen diskutieren oder selbst beim Podcast mitmachen. Bei GNU/Linux.ch wird eure Stimme nicht nur gelesen, sondern auch gehört.
Quellen
- keine
Es gibt noch andere Gründe:
Ja, man kann (und wir haben das so gemacht) ein QEMU-Image von Windows 11 (oder wenn es nicht ins Netz muss auch früher) unter Linux laufen lassen (Wine ist Mist dagegen). Aber es erfordert eben Arbeit und man kommt nicht vom Windows weg.
Es kann auch eine Schule sein, deren Infolehrer vollkommen überfordert ist, die 70 Windows-Rechner zu administrieren und gleichzeitig - also neben seiner Lehrtätigkeit - den gesamten Schulbestand auf Linux umzustellen.
Fakt ist: es fallen bei jedem Wechsel Transaktionskosten an. Wenn keiner da ist, der die (a) kurzfristig schultert und (b) begreift, dass langfristig Kosten gespart werden können, bleibt man beim alten.
Und noch einmal: wir arbeiten nahezu alle bei uns mit Linux. aber in einem 30-Mann-Institut haben wir auch keine 10-Mann große IT-Abteilung und alle KMUs werden das gleiche Problem haben.
Danke für den guten Podcast, in dem ihr viele Themen angesprochen habt. Da das Spektrum so breit war, konntet ihr die einzelnen Punkte natürlich nur kurz anreißen. Eventuell möchtet ihr bestimmte Aspekte ja noch einmal vertiefen – daher werfe ich mal meine „zwei Cent“ in den Ring:
Aus meiner Perspektive ist Open Source eher eine Frage des Geschäftsmodells einer Firma und weniger eine Frage des ursprünglichen Open-Source-Gedankens. Für viele Geschäftsmodelle ist der eigentliche Quellcode zweitrangig, weil das Geld anderweitig verdient wird – zum Beispiel über die Plattform selbst, durch Fördermittel oder durch einen treuen Kundenkreis, den keine andere Firma so schnell kopieren kann. In diesen Fällen dient Open Source meist nur als Marketinginstrument, da das Projekt ohnehin komplett von der Firma gesteuert und verwaltet wird. Kurz gesagt: Open Source ist nicht gleich Open Source.
Bei eurer Besprechung zum Thema Compliance hat mir leider die Organisationsebene gefehlt. Was ich als Unternehmen mit einer kommerziellen Lizenz nämlich auch einkaufe, ist die strukturierte Organisation der Softwareerstellung. Das ist für Firmen ein entscheidender Faktor bei Security und Compliance. Besonders in kritischen Sektoren (Finanzwirtschaft, Medizin, Energieversorgung) ist es essenziell, dass die Entwickler nachweisbar geschult sind – etwa in den Bereichen Social Engineering, Datenschutz oder sichere Softwareentwicklung. Das ist bei einem Open-Source-Projekt standardmäßig nicht garantiert (die Mitwirkenden können qualifiziert sein, müssen es aber nicht). Als Firma kann ich von kommerziellen Anbietern Zertifikate und Nachweise einfordern – bei Open Source geht das nicht. Zudem kann ich dort gezielt nach Sicherheitsüberprüfungen (wie Führungszeugnissen) bei der Personaleinstellung fragen. Auch dieser Kontrollmechanismus entfällt bei Open Source; hier müsste ich im Zweifel selbst recherchieren, wer am Projekt mitarbeitet und was diese Personen tun. Auch beim Offboarding kann ich mir die Prozesse eines kommerziellen Anbieters vertraglich zusichern lassen, während bei Open Source oft unklar bleibt, wer noch Zugriff auf den Code hat.
Wir steigen in unserem Unternehmen nicht um, weil Linux keinen professionellen Support bietet. So ein kostenloses Bastelprojekt kann morgen beendet sein.
Auf jeden Fall ein Faktor, der beachtet werden solle. Aber genau dafür gibt es ja zahlreiche Dienstleister welche Support bieten. Alternativ auch Distros, wo große Unternehmen hinterstehen, welche Support bieten (RedHat z.B.).
Es wäre gut gewesen, wenn der Gesprächspartner Michel Ketterle sich am Anfang noch mal vorgestellt hätte, was sonst bei anderen Interview- oder Gesprächspartnern ja auch passiert. Vielleicht kennst du den persönlich zu sehr, dass du da nicht dran gedacht hast, aber es wäre gut zu wissen, was für eine Firma er arbeitet, wie viele Mitarbeiter, was er für eine Stellung in der Firma hat. Dann kann man die Aussagen auch etwas besser einschätzen.
Ansonsten finde ich das Thema gut und wichtig. Allerdings habt ihr in den Show Notes jetzt nur die negativen Sachen im Verlauf des Podcast-Gesprächs dargestellt. Hat sich das ja teilweise auch entkräftet oder kamen auch die positiven Sachen zum Vorschein. Da wäre es vielleicht gut gewesen, beides in den Show Notes zu erwähnen.
Okay ansonsten vielen Dank für den Podcast.
Das ist ein berechtigtes Anliegen. Ich kenne Michel seit 20 Jahren. Er hat Artikel bei GNU/Linux.ch geschrieben und Podcast-Folgen mit mir aufgenommen und ich kenne ihn persönlich aus der FSFE und anderen FLOSS‑Organisationen. Im Podcast hat er als ganz normaler Community-Teilnehmer gesprochen, so wie das jede andere Person auch machen kann. All diese Informationen habe ich im Podcast mitgeteilt. Auch über die Firma, für die er arbeitet, hat er berichtet. Wie viel mehr möchtest Du noch wissen?
Hallo Ralf,
Michell redet oft von seiner Firma. Deswegen wäre es schön zu wissen, in welcher Firma er arbeitet. Er sagt, dass er auch im CAD-Bereich tätig ist. Das Thema FreeCAD war da auch Thema. Insofern fände ich es schon gut, wenn man auch weiß, in was für einer Firma oder Branche er arbeitet und was die machen (weil doch viele seiner Antworten nicht aus der Community Erfahrung kommen, sondern vieles auch Erfahrung von seiner Firmentätigkeit ist).
Vielleicht kann die Vorstellung deines Gesprächspartners direkt in den Show Notes nachgetragen werden. Da würde man das ja am ehesten sehen, so als Idee.
Hallo, es könnte ein guter Schritt sein, in Unternehmen von Software der Tech-Giganten zu freier Software zu wechseln. Leider spielt die Barrierefreiheit von freier Software auch keine Rolle. D.h, dass ein Wechsel meines Arbeitgebers von Microsoft Office zu freier Software dazu führen könnte, dass ich in Zukunft zu hause bleiben kann. "Auch" schreibe ich deshalb, weil die in Unternehmen eingesetzte proprietäre Software nicht auf Barrierefreiheit geprüft wird bzw. nicht geprüft werden muss. Fazit: Diese Migration würde mich nicht vom Regen in die Traufe, sondern ziemlich sicher ins Nichts führen.
Gruß Jörg
Vielen Dank für diese Podcast Episode, meine kurze Anmerkung dazu:
Ich bin in der IT im Gesundheitswesen unterwegs: Software ohne einen Hersteller Support einzusetzen macht hier keiner, die IT hat keine Ressourcen um den Support selbst bereitstellen zu können. Fachanwendungen, wie es ja immer so schön heisst, sind meistens Windows basiert, und diese sind Alternativlos, wenn man z.B. eine Medizingerät zur Diagnostik von Hersteller XY ein Produkt kauft und der Hersteller die Software vordiktiert. Und die Anzahl der Fachanwendungen ist sehr groß. Auch ist Software bereits seit Jahrzehnten im Einsatz mit riesigem Datenbestand und wird nicht mal eben so gewechselt. Vieles setzt auch auf MS Office auf, weil's historisch so gewachsen ist. Also mehrere Faktoren warum man in der MS Welt gefangen ist! Und da man größere, über mehrere Standorte verteilte, standardisierte Umgebungen mit tausenden von Clients, Servern und Anwendungen hat, bewegt man sich auch mal eben nicht so einfach um Gegebenheiten zu ändern.
Das ist ein guter Kommentar. Ich werde dazu einen Artikel schreiben, weil deine Anmerkung den Nagel auf den Kopf trifft und sich viele dieselbe Frage stellen.