Für Anwendungsentwickler ist die Integration von Open-Source-Code in Ihr Projekt wie die Bestellung eines „Meal-Kit“, anstatt von Grund auf zu kochen. Es erspart Ihnen etwas Zeit und Mühe. Aber es reduziert auch Ihr Maß an Kontrolle über das Endprodukt, und es könnte zu Problemen führen, die Sie nicht vorhersehen.
Das heißt nicht, dass Sie keine Open Source (oder übrigens auch „Meal Kits) verwenden sollten. Es gibt viele gute Gründe Open Source in ihren Projekten zu nutzen. Aber es ist wichtig, sich der potenziellen Nachteile und Risiken bewusst zu sein und einen Plan zu haben, um diese anzugehen.
Die meisten Organisationen mit internen Entwicklungsteams unterhalten ihre eigenen Codebasen. Ihre Entwickler schreiben den größten Teil des Codes für diese Codebasen selbst. Sie können jedoch aus mehreren Gründen Open-Source-Code von Drittanbietern zu ihren Codebasen hinzufügen:
Die offensichtlichste ist, dass es oft schneller und einfacher ist, eine Funktion zu integrieren oder eine Integration mit Code von Drittanbietern zu erstellen, als es es selbst zu schreiben. Warum sollten Sie eine Woche damit verbringen, einen neuen Dienst von Grund auf neu zu erstellen, wenn Sie den benötigten Code aus einem offenen Repository auf GitHub abgreifen können? Warum sollte man das Rad neu erfinden, wenn es jemand bereits für Sie erfunden hat und möchte, dass Sie es kostenlos nutzen?
Die Integration von Open Source kann auch dann nützlich sein, wenn ein internes Entwicklungsteam nicht über das erforderliche Know-how verfügt, um eine bestimmte Funktion oder einen bestimmten Dienst selbst zu implementieren. Vielleicht müssen Sie eine neue Funktion zu einer älteren Anwendung hinzufügen, die in einer Sprache geschrieben wurde, die niemand gut kennt. Dann werden Sie sich, wenn möglich entscheiden, die benötigte Funktionalität aus einem Open-Source-Projekt zu ziehen, anstatt sich selbst die Sprache beizubringen.
Entwickler können sich auch aus taktischen Gründen für die Arbeit mit Open-Source-Code entscheiden. Das Ausleihen von Code aus Open-Source-Projekten von Drittanbietern kann dazu beitragen, Brücken zu diesen Projekten zu bauen. Der Beitrag von Code Back baut noch stärkere Brücken auf. Wenn sich ein Unternehmen als Teilnehmer am Ökosystem rund um ein bestimmtes Open-Source-Projekt etablieren möchte, kann die Arbeit mit seinem Code eine Möglichkeit sein, dies zu tun.
Die Gründe für die Nutzung von Open-Source-Code sind klar nachvollziehbar, aber gibt es potenzielle Nachteile, die Sie beachten sollten.
Eine ist, um den Ingenieur Steve Belovarich zu zitieren, „wenn Sie Open-Source übernehmen, wissen Sie oft nicht, was Sie bekommen.“
Mit anderen Worten, wenn Sie Open-Source-Code verwenden, können Sie ungefähr verstehen, was er tut und wie er in Ihre Codebasis passt. Aber wenn die Entwickler nicht Tage damit verbringen wollen, jede Zeile des Codes zu durchforsten – was unwahrscheinlich ist, weil dies den Zweck des Ausleihens von Code, nämlich Zeit und Aufwand zu sparten widersprechen würde, wird das Team nicht vollständig verstehen, wie der Open-Source-Code funktioniert. Das ist ein Risiko, weil es bedeutet, dass das Unternehmen von etwas abhängig wird, das seine Entwickler nicht vollständig verstehen.
Die Wiederverwendung von Open-Source-Code kann auch zu Lizenzierungsproblemen führen. Es gibt Dutzende von verschiedenen Open-Source-Lizenzen, die alle ihre eigenen Regeln haben, wie Open Source in andere Codebases integriert werden kann. Einige Lizenzen lassen Entwickler alles tun, was sie wollen. Andere erfordern die Zuordnung der ursprünglichen Autoren des Codes. Einige haben Beschränkungen dafür, falls der Code öffentlich verwendet wird, aber nicht, wenn Unternehmen ihn nur intern verwenden.
Aufgrund dieser Komplexität kann es sehr leicht passieren, dass man gegen Lizenzbedingungen verstößt. Und es kann sehr leicht dazu kommen, dass man davon ausgeht, dass eine Lizenz nicht zwingend erforderlich ist, was nicht immer der Fall ist.
Unternehmen sind einem realen Risiko ausgesetzt, wenn sie Open-Source-Code ausleihen, ohne die Lizenzbedingungen zu verstehen und ohne zu verfolgen, wo der Code in ihren eigenen Codebasen vorhanden ist.
Die Verwendung von Open Source kann auch Sicherheitsprobleme auslösen. Open Source ist von Natur aus nicht weniger sicher oder unsicherer als proprietärer Code. Wenn Entwickler jedoch Open Source verwenden, ohne vollständig zu verstehen, wie der Code funktioniert, und ohne zu wissen, welche Schwachstellen darin lauern können, riskieren sie, Sicherheitsprobleme in ihre Codebasen einzuführen.
Für die Entscheidung, ob Open Source-Code verwendet werden soll oder nicht, muss man beurteilen, ob der Nutzen die Risiken überwiegt – sowie die Fähigkeit Ihres Unternehmens, diese Risiken zu kontrollieren.
Wenn die Verwendung von Open Source eine erheblich an Zeit, Aufwand und Geld spart, indem die Menge an Originalcodierung, die das Entwicklungsteam durchführen muss, erheblich reduziert wird, lohnt es sich wahrscheinlich.
Wenn Sie der Quelle des Codes vertrauen und sicher sind, dass er sicher ist, ist es sinnvoll, sich darauf zu stützen. Im Allgemeinen ist es besser, Open-Source-Code aus einem Großen Projekt zu verwenden, als Code aus einem zufälligen GitHub-Repository abzurufen.
Am wichtigsten ist die Transparenz und die Kontrolle, die Entwickler über den Quellcode haben, den sie verwenden. Unabhängig davon, ob Sie den Autoren des Open Source-Code vertrauen oder wie gut der Code geschrieben ist, können Sie nie ganz sicher sein, dass dadurch kein Sicherheits-, Lizenzierungs- oder sonstiges Problem entsteht, wenn Sie keine eigenen Überprüfungen durchführen.
Hier kommen Software Composition Analysis (SCA)-Lösungen ins Spiel. Mit SCA-Tools können Unternehmen den Open-Source-Code finden, der in ihren Datenbanken vorhanden ist (was wichtig ist, da Entwickler nicht immer gut dokumentieren, wo sie Open Source hinzugefügt haben), damit sie den Code für Lizenzierung, Sicherheit und andere Risiken bewerten können.
