Lizenzgebührfrei nicht gleich kostenfrei Versteckte Kosten von Open Source in unternehmenskritischen Anwendungen

Ein Gastbeitrag von Bert Farabaugh* 5 min Lesedauer

Anbieter zum Thema

Open-Source-Software ist heute in vielen Anwendungen weit verbreitet - teils in Form von Komponenten, teils auch als eine komplette Lösung. Der Hauptgrund für die Beliebtheit von Open-Source-Software ist die Kostenwahrnehmung: die Vorstellung, dass kostenlose Verfügbarkeit auch wirklich bedeutet, keine Kosten zu haben. Aber ist das wirklich so?

Bei der Neuentwicklung eines Embedded-Systems scheint es oft eine naheliegende, kostengünstige Entscheidung zu sein, zu einer augenscheinlich kostenlosen Open-Source-Lösung zu greifen. Aber was sind die wahren Kosten einer solchen Entscheidung?(Bild:  Pixabay)
Bei der Neuentwicklung eines Embedded-Systems scheint es oft eine naheliegende, kostengünstige Entscheidung zu sein, zu einer augenscheinlich kostenlosen Open-Source-Lösung zu greifen. Aber was sind die wahren Kosten einer solchen Entscheidung?
(Bild: Pixabay)

Laut einer Untersuchung von Synopsys enthalten 96% aller 1067 für die Studie geprüften Codebasen Open-Source-Code,. Darunter befanden sich fortschrittliche Anwendungen wie hochentwickelte Robotik, intelligente Stromnetze, Verteidigungsinfrastrukturen, unbemannte Fahrzeuge oder komplexe Logistik-Systeme. Der Hauptgrund für den Einsatz von Open-Source-Komponenten war in nahezu all diesen Fällen derselbe: Open Source ist erst einmal kostenlos verfügbar!

Es stimmt zwar, dass Open-Source-Software in der Regel frei von Lizenzgebühren und somit zunächst kostenlos erhältlich ist. Für die Wahl selbst fallen also meist - zunächst - keine Kosten an. Allerdings ist es möglich, und in vielen Fällen sogar naheliegend, dass im Laufe der Projektentwicklung die potenziellen Einschränkungen (sofern vorhanden) von Open-Source-Software zu Situationen führen, die die Produktivität beeinträchtigen und kostspielige Nachbesserungen erforderlich machen. Oder es sind bereits in der Art der Lizensierung versteckte Kosten enthalten, die erst im Laufe der Entwicklung augenfällig werden.

Im folgenden Beitrag führen wir einige der häufigsten Gründe auf, die die Kosten für den Einsatz von Open-Source-Software in die Höhe treiben können.

Vorab anfallende Rechtskosten

Während der Code selbst in der Regel kostenlos heruntergeladen werden kann, fallen für die Lizenzierung und Nutzung oft Rechtskosten an. Darüber hinaus verlangen einige Open-Source-Lizenzen (z. B. Copyleft), dass alle vorgenommenen Änderungen an die ursprüngliche Open-Source-Gemeinschaft zurückgegeben werden müssen.

Dies kann für einige Projektteams ein Hindernis darstellen, da die von ihnen für ihre Anwendung erstellte Software urheberrechtlich geschützt ist und nicht außerhalb des eigenen Unternehmens weitergegeben werden darf. Zu berücksichtigen ist auch, dass Unternehmen, die Open-Source-Software verwalten, manchmal einseitige Änderungen an den Lizenzvereinbarungen für Open-Source-Software vornehmen, wodurch die Projektkosten und die Codeintegrität auf eine unsichere und/oder sich ändernde Grundlage gestellt werden können.

Funktionserweiterungen

Was passiert, wenn die Anwendung eine Funktionalität benötigt, die in der Open-Source-Software nicht verfügbar ist? Um den Zeitplan des Projekts einzuhalten, könnte das interne Team die Funktion direkt hinzufügen, aber dann müsste sie in der Regel wieder an die Open-Source-Gemeinschaft unter der Open-Source-Lizenzvereinbarung zurückgegeben werden.

Passiert dies nicht, arbeitet das Projekt an einem „verwaisten“ Softwarezweig, der zukünftige Versionen der Open-Source-Gemeinschaft ausschließt. Sobald sich das interne Team für die Verwendung eines verwaisten Softwarezweiges entscheidet, muss ein Fachexperte beurteilen, wie Verbesserungen oder Fehlerbehebungen aus der Open-Source-Community integriert werden können. Die daraus resultierende Integration wird noch schwieriger, was zu erweiterten Testszenarien führt.

Konformität mit Vorschriften

Die Angriffe und Bedrohungen im Bereich der Cybersicherheit nehmen ständig zu, und jede Software mit einem gewissen Maß an Netzwerkkonnektivität ist durch nicht autorisierte Akteure gefährdet. Weil bei Open Source die Autoren der Software unbekannt sein können, ist eine Überprüfung der Open Source-Projekte und ihrer Mitwirkenden unmöglich. Dies kann Open-Source-Software zu einem leichten Ziel für Hacker machen – sie können unbemerkt Angriffspunkte einbauen und so weitreichende Schwachstellen in Hunderten von eingesetzten Systemen schaffen, die die gleiche Software mit den gleichen Zugriffspunkten verwenden.

Ist dies der Fall, kann so etwas zu kostspieliger Neuprogrammierung oder sogar zu Systemausfällen führen. Das stellt sich besonders dann als verheerend heraus, wenn diese Systeme in regulierten, kontrollierten oder als geheim eingestuften Umgebungen eingesetzt werden. Wie erfährt ein Nutzer von Open-Source-Software normalerweise von Sicherheitslücken - und wie schnell werden diese behoben?

Support und Talentbindung

Open Source Software bietet keinen Support – das kann zu bestimmten Zeitpunkten der Projektentwicklung verheerende Folgen haben. Es kann kostspielig sein, entweder interne Ressourcen bereitzustellen, um das Team zu unterstützen, oder den Support an eine Drittfirma auszulagern (Support-as-a-Service).

Zudem birgt die interne Bereitstellung von Support Risiken in Bezug auf Personalfluktuation, Arbeitsbelastung und Zeitaufwand des vorgesehenen Entwicklers. Man muss sicherstellen, dass die für diese Aufgabe ausgewählten Support-Ingenieure während der gesamten Projektlaufzeit zur Verfügung stehen. Andernfalls kann es zu hohen Einarbeitungskosten für die Projektteams und zu kostspieligen Verzögerungen kommen, bis die neuen Experten fit in ihren Aufgaben sind.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Software-Lebenszyklus-Management

Das Entwicklungsteam, das Open-Source-Software einsetzt, muss im Vorfeld klare Vereinbarungen darüber treffen, was passiert, wenn etwas nicht wie erwartet funktioniert. Sicher, Open-Source-Software bietet einem Team in der Regel den Vorteil, dass sich Fehler im Code genau lokalisieren lassen. Aber was passiert mit dieser Fehlerbehebung? Und wie wirkt sie sich auf andere Funktionen der Software aus?

Solche Verzögerungen bei der Fehlerbehebung bergen die Gefahr, dass Entwicklungszeitpläne durcheinander geraten. Daher ist es bei Open-Source-Software sinnvoll, eine Unterbrechung der Nutzung einzuplanen. Wenn beispielsweise ein erfolgreiches Forschungsprojekt in eine kommerziell nutzbare Phase übergeht, werden in der nächsten Arbeitsphase viele der oben beschriebenen direkten oder versteckten Kosten von Open-Source-Software anfallen, die erst einmal adressiert werden müssen  

Der Vorteil kommerzieller Software

Hat man all diese anfallenden potenziellen Fallstricke, direkten (zusätzlichen) Entwicklungskosten und Zeitaufwände auf dem Plan, lässt sich eine bessere Kosten-Nutzen-Aufwandseinschätzung für den Einsatz von Open-Source-Komponenten aufstellen. Nicht selten stellt sich dabei heraus, dass der Einsatz von Open Source letztendlich teurer kommen könnte als eine komplette Eigenentwicklung. Insbesondere bei der Entwicklung neuer Produkte oder Dienstleistungen kann das Fehlen bestimmter Funktionen erhebliche Folgen haben und zu Verzögerungen bei der Markteinführung führen. Hier kommt der große Unterschied zwischen kommerzieller und Open-Source-Software zum Tragen.

Der Einsatz kommerzieller Softwarekomponenten und kommerzieller Software in neuen Produkten bietet im Vergleich während der gesamten Projektlaufzeit in der Regel die folgenden Vorteile:

  • Neue Funktionen und Upgrades werden direkt vom Anbieter verwaltet, der einen genau auf die Projektanforderungen abgestimmten Fahr- und Zeitplan bereitstellen kann. Der Anbieter verwaltet die zukünftige und rückwirkende Kompatibilität, um Upgrades zu erleichtern;
  • der Anbieter kontrolliert den Code in allen Phasen, um ihn vor Hintertüren zu schützen;
  • Anbieter halten sich an strenge Qualitätsprozesse, einschließlich Cybersicherheitsbewertungen, die überprüft werden können, um die Konformität sicherzustellen;
  • der Support ist entweder im Kaufpreis enthalten oder stellt nur einen kleinen Teil der Vorabkosten dar, mit einem vorhersehbaren und eingeplanten Budgetposten;
  • die Anbieter sind für die Nachverfolgung, das Testen und die Validierung des aktualisierten Codes sowie für alle anderen Änderungen verantwortlich;
  • die Anbieter stellen eine Dokumentation mit Anwendungsbeispielen zur Verfügung; und
  • Projektteams können zur kurzfristigen Lösung kritischer Probleme auf die große Anzahl von Experten des Anbieters zurückgreifen, wodurch das Projektrisiko verringert wird. Dies kann einer der kosten- und zeitsparendsten Aspekte sein, die mit dem Einsatz von kommerziell verfügbarer Software verbunden sind.

Die Entscheidung für Open-Source-Software muss sorgfältig gegen die potenziellen Kosten und Risiken abgewogen werden. Es ist möglich, dass bei unternehmenskritischen Anwendungen der Einsatz von Open-Source-Software anstelle kommerziell verfügbarer Optionen wesentlich teurer ist als robuste, kommerziell verfügbare Lösungen, insbesondere wenn Sicherheitsgarantien und die Einhaltung gesetzlicher Bestimmungen für die Markteinführung erforderlich sind. Wenn alles auf dem Spiel steht, kann die Verwendung eines kommerziellen Softwarepakets die Einhaltung von Standards, Stabilität, Qualitätskontrolle und vor allem vorhersehbare Kosten bieten.

(sg)

* Bert Farabaugh ist der Leiter der Abteilung für Field Application Engineering bei RTI.

(ID:50159728)