Open Source im Unternehmen/ Migration zu Open-Source-Software
Für eine Migration von proprietärer zu quelloffener Software sind viele Aufgaben abzuarbeiten, die bei jeder anderen Migration auch anfallen – selbst bei einem Update von Windows NT zu Windows 2000.[1]
Einer Migration geht in der Regel eine Adaptionsentscheidung voraus. Diese umfasst die Prüfung des Bedarfs eines Softwarewechsels, die Suche nach adäquater Software und letztlich die Entscheidung über die Migration selbst. Die Entscheidung sollte mit Pilotprojekten gestützt werden. Diese erzeugen wichtige betriebsbezogene Erfahrungswerte über die Einsetzbarkeit der Software und mögliche Hemmnisse bei der Migration. Ist die Entscheidung getroffen, folgt die Migration. Hierzu gehören die Schritte Feinplanung, Roll-Out und Betrieb.[2]
Diese Vorgehensweise ist von allgemeinem Charakter. Dennoch gibt es bei der Migration zu quelloffener Software weitere Punkte, die für den Migrationserfolg einen entscheidenden Einfluss haben können. Diese hängen überwiegend mit den im Abschnitt Abwägen von Chancen und Risiken ausführlich diskutierten Kriterien zusammen.
Alle aufgeführten Kriterien wurden auf allgemein gültige Aussagen pro quelloffene oder pro proprietäre Software überprüft. Von den 18 Kriterien sprechen 11 jedoch nicht für eine einzelne Softwarekategorie. Sie sind abhängig von der jeweiligen Ausprägung einzelner Programme bzw. bei beiden Kategorien gleichwertig. Die verbleibenden 7 werden nachfolgend nochmals unter dem Aspekt der Migration beleuchtet.
Die entfallenden Lizenzkosten werden vor allen von Anhängern quelloffener Software immer wieder als entscheidender Vorteil genannt. Dies birgt jedoch die Gefahr, Folgekosten zu vernachlässigen und OSS im Unternehmen ohne weitere Prüfung einzusetzen. Verfügen Unternehmen nur über wenig formalisierte Entscheidungsprozesse, ist diese Gefahr am größten.[3]
Weiterhin sind lizenzrechtliche Fragen zu prüfen, wenn das Unternehmen die Flexibilität und die Modularität von quelloffener Software nutzen möchte. Eigenentwicklungen und Modifikationen eines unter GPL stehenden Quellcodes fallen automatisch auch wieder unter diese Lizenz. Außerdem müssen Supportverträge so gestaltet sein, dass sie durch solche Änderungen nicht gefährdet werden.[4]
Die zur Zeit größte Unsicherheit im Einsatz von OSS stellen mögliche Verletzungen von Softwarepatenten dar. Eine Prüfung des Quellcodes auf Patentverletzung kann hier für mehr Sicherheit sorgen. Jedoch kann die Konsequenz einer solchen Prüfung sein, dass das Risiko einer Nutzung zu groß ist. Das vielleicht besser geeignete quelloffene Programm käme dann nicht zur Anwendung.
Ein Fork kann als ein natürliches Risiko der Entwicklungsform von quelloffener Software bezeichnet werden. Dieses Risiko muss dem Unternehmen vor der Migration bewusst sein. Die Problematik liegt aber nicht im Fork selbst, sondern in der ungewissen Zukunft der weiteren Entwicklung des Programms. Die Auswirkungen sind unterschiedlich: sie können überhaupt nicht spürbar sein oder das Unternehmen vor die Wahl zwischen zwei und mehr Programmen stellen. Dies ist dann kritisch, wenn beispielsweise der Anwender die Funktionen aller Programme benötigt.
Dass aber auch bei proprietärer Software mit einem Fork zu rechnen ist, haben die Überlegungen aus dem Abschnitt Kriterien aus der Entwicklungsform gezeigt.
Offene Standards sind ein Plus für quelloffene Software. Der Einsatz von nicht-offenen Standards erschwert einem Unternehmen eine ablösende Migration. Für die aktuelle Migration kann dieses Kriterium im Hinblick auf weitere zukünftige Migrationen und die Herstellerunabhängigkeit (Lock-in) von Bedeutung sein.
Fehlende Hardwareunterstützung ist eines der großen Hemmnisse bei der Verbreitung von offenen Betriebssystemen. Hier muss eine Überprüfung der unternehmenseigenen Software vor der Migrationsentscheidung durchgeführt werden. Falls nicht, drohen im günstigsten Fall Kosten für die Hardwareumstellung. Schlimmstenfalls kann das gesamte Migrationsprojekt scheitern, wenn zu spät festgestellt wird, dass es keine unterstützte Hardware für die unternehmerischen Anforderungen gibt.
Der Faktor Mensch ist hier das abschließend betrachtete Kriterium. Es ist eines der wichtigsten, das den Verlauf und damit auch den Erfolg einer Migration bestimmt. Viele Menschen haben die Tendenz, Veränderungen zunächst eher ablehnend gegenüber zu stehen. Dies gilt auch für jede Veränderung bei der Software, unabhängig davon, ob sie quelloffen oder proprietär ist.
Mitarbeiter können jedoch aus zwei Gründen einer Migration zu OSS kritischer gegenüber stehen als einer Migration zu proprietärer Software: Erstens stellen viele proprietäre Programme im betrieblichen Bereich mittlerweile einen Quasi-Standard dar, beispielsweise die verschiedenen Versionen von Microsoft Office. Kenntnisse über dieses Programm können im Lebenslauf einen höheren Stellenwert haben als Kenntnisse über OpenOffice. Mitarbeiter sehen sich hier möglicherweise in ihren Karrieremöglichkeiten benachteiligt.[5]
Zum zweiten sind Anwenderprogramme und Betriebssysteme den Mitarbeitern oft aus dem privaten Gebrauch bekannt. Der Wechsel auf quelloffene Software kann Mitarbeiter deshalb mit Wissens- und Machtverlust konfrontieren.[6]
Die Mitarbeiter sind möglichst früh in das Migrationsprojekt einzubeziehen. Zum Abbau von möglichen Ängsten und Bedenken muss das Unternehmen ausreichend Zeit und Ressourcen zur Verfügung stellen.
Eine Migrationsentscheidung ist idealerweise frei von ideologischen Elementen zu treffen. Wenn die Migration auf quelloffene Software im Unternehmen Erfolg haben soll, ist eine objektive Auseinandersetzung mit den genannten Kriterien notwendig. Diese Auseinandersetzung muss sich deshalb ausschließlich an den betriebswirtschaftlichen Notwendigkeiten des Unternehmens orientieren.
Quellen
[Bearbeiten]Die zitierten Quellen sind im Literaturverzeichnis zu finden.
- ↑ Vgl. European Communities: Guidelines, 2003, S. 17.
- ↑ Vgl. auch Berlecon Research GmbH: Strategien, 2004, S. 42.
- ↑ Vgl. Berlecon Research GmbH: Strategien, 2004, S. 41.
- ↑ Vgl. auch Berlecon Research GmbH: Strategien, 2004, S. 43.
- ↑ Vgl. auch Berlecon Research GmbH: Strategien, 2004, S. 48.
- ↑ Vgl. auch European Communities: Guidelines, 2003, S. 22.