Beschleunigung der digitalen Produktentwicklung durch den Einsatz von Open Source Bausteinen

Konkurrenzfähig bleiben in einer Zeit, die von immer kürzeren Produktionszyklen bei gleichzeitig höherer Kundenorientierung geprägt ist, funktioniert nur auf der Basis von qualitativ hochwertiger, an die konkreten Anforderungen angepasster Software. Dies gilt sowohl, wenn die Software selber Teil des Produkts ist, als auch, wenn sie für den Entwurf oder die Produktion eingesetzt wird oder – als Datenanalyse oder bei Anwendungen der KI in verschiedenen Varianten – für die Analyse und Verbesserung existierender Produkte. Die PWC Studie „Digital Product Design 2025“ (Geissbauer 2019) listet unter anderem Digital Prototyping, Digital Twins und Product Lifecycle Management als Unterstützer der modernen Produktentwicklung auf. Gleichzeitig bedingt eine steigende Digitalisierung auch, die Cybersicherheit ernst zu nehmen, um die digitalen Bausteine des Entwicklungsprozesses vor Zugriff und Beschädigung durch Dritte zu schützen.

In Sparten mit direktem Software-Bezug gilt schon lange, dass Software qualitativ hochwertig, zeitnah und auf den konkreten Kundennutzen fokussiert entwickelt werden muss. Mit der wachsenden Abhängigkeit von Software wird diese Erkenntnis zukünftig in allen Industriezweigen immer relevanter.

Wie kann die Software-Entwicklung mit diesen stetig wachsenden Anforderungen Schritt halten? Hier können Ansätze der Industrialisierung der Software-Entwicklung (Adersberger 2015) weiterhelfen. Dabei zählt es, neben der Produktivität auch die Qualität der Software-Entwicklung zu verbessern. Nur so lässt sich Software nachhaltig bedarfsgerecht und wirtschaftlich produzieren.

Eine Option zur Steigerung der Produktivität ist die Verringerung der Fertigungstiefe. Das bedeutet, nur so viel neue Software zu schreiben, wie für den jeweiligen Anwendungsfall benötigt wird und für bereits gelöste Aufgaben Bausteine von existierender Software wiederzuverwenden. Hier kommt insbesondere Open Source Software ins Spiel, die Lösungen für viele der üblichen Problemstellungen anbietet. Dabei kann man (mindestens) drei Ebenen betrachten (Siehe auch Abb. 1):

Zu allen Punkten gibt es mittlerweile eine Vielzahl an Lösungen, sowohl Closed als auch Open Source. Letztere werden im Folgenden näher betrachtet.

Bei der Entwicklung eines Software-Produkts gibt es viele Gelegenheiten, von Wiederverwertung Gebrauch zu machen. Neben dem simplen Einsparen von Aufwand für eine Eigenimplementierung profitiert das Produkt bei guter Auswahl der Bausteine auch von dem Wissen, das in deren Implementierung geflossen ist. So müssen sich die eigenen Software-Entwickler*innen nicht tief in alle nötigen technischen Domänen einarbeiten, wodurch mehr Kapazität für das Verstehen der fachlichen Domäne bleibt, in der die eigentliche Wertschöpfung passieren soll. Eine Stichprobe in unseren Projekten ergab, dass die Fertigungstiefe (individuell entwickelter Code zum gesamten Code des fertigen Produkts) darin zwischen 1 und 7 % liegt. Umso wichtiger wird also die richtige Auswahl der Bausteine, damit die Qualität des Produkts nicht darunter leidet.

In der Software-Entwicklung werden viele Werkzeuge verwendet, die den Entwicklungsprozess unterstützen, ohne in das fertige Produkt einzufließen. Dazu gehören Integrierte Entwicklungsumgebungen (IDE), Versionskontrollsysteme, Build-Tools, Testausführung und -Auswertung und viele weitere Hilfsmittel für die vielfältigen Schritte, die von den Anforderungen über Programmcode schließlich zum fertigen Software-Produkt führen.

Für alle zugehörigen Aufgaben gibt es Closed und Open Source Lösungen mit unterschiedlichen Stärken und Schwächen. Im Java-Umfeld setzt sich die kommerzielle IDE IntelliJ⁹ langsam gegen die Open Source Varianten Eclipse¹⁰ und Netbeans¹¹ durch (Schlosser 2018). In der Source Code Verwaltung findet das quelloffene Git¹² breite Verwendung und fließt auch in kommerzielle Produkte mit erweiterter Funktionalität ein (siehe z. B. Bitbucket von Atlassian), die Git in bezahlte Services einbetten. Aber auch Closed Source Produkte wie Microsofts Azure DevOps Server¹³ (vormals Team Foundation Server) oder Helix Core¹⁴ von Perforce sind im Einsatz.

Im Vergleich zu Frameworks oder Libraries ist die Lizenzfrage bei Tools meist weniger relevant, da die Software nicht in das fertige Produkt eingeht. Dies erlaubt zum Beispiel die Verwendung von Projekten mit GPL-Lizenz, die nicht direkt in den Quellcode einer Closed Source Anwendung einfließen dürfen.

Virtualisierung von Infrastruktur ermöglicht den Einsatz von Software-Bausteinen in diesem Bereich und die damit einhergehende stärkere Verteilung macht den Einsatz von unterstützender Software geradezu notwendig. Dadurch wird die Schnittstelle von Software-Entwicklung und „reinem“ Betrieb weiter in Richtung der Hardware verschoben. Unterstützt und gegenseitig verstärkt wird dieser Effekt beispielsweise vom DevOps-Gedanken, nach dem Entwicklungsteams unter anderem auch die Entscheidung über die eingesetzte Infrastruktur treffen. Im Folgenden betrachten wir eine Auswahl der zugehörigen Bausteine.

Erfolgreiche Open Source Bausteine werden von vielen Software-Projekten verwendet und sind damit vielfach getestet und bewertet. Das Gleiche gilt selbstverständlich auch für Closed Source Bausteine, hier ist allerdings eine Beurteilung nur „von außen“ möglich. Weder die Architektur noch der Code-Stil oder die automatisierten Tests lassen sich bewerten. Dagegen kann auch der Erfolg eines Open Source Projekts relativ gut anhand der Aktivität innerhalb des Repositorys oder auf der Webseite abgeschätzt werden. Gibt es viele Änderungen von Team-Mitgliedern oder Pull-Requests von anderen Entwickler*innen? Wie viele Bugtracking-Tickets sind offen? Wann war das letzte Release?

Vorsicht walten lassen muss man, wenn die Antworten auf diese Fragen darauf hindeuten, dass es sich um ein weniger erfolgreiches oder aufgegebenes Projekt handelt. Hier kehren sich die Vorteile nämlich zum Teil ins Gegenteil: Fehler-Tickets werden nicht beantwortet, Anpassungen an neue Rahmenbedingungen finden nicht mehr statt. Entwickler*innen, die solche Bausteine einsetzen, sind gezwungen, die notwendigen Änderungen selbst durchzuführen. Durch das Open Source Modell ist dies immerhin möglich, kostet aber Ressourcen, die in der Regel im konkreten Projekt nicht eingeplant sind. Als Alternative bleibt sonst nur, neue Bausteine auszuwählen und zu integrieren.

Im Gutfall allerdings werden Fehler behoben bzw. können mit vertretbarem Aufwand von den Anwender*innen selbst behoben werden. Durch den Rückfluss der Fixes an das Projekt profitieren auch alle anderen Anwender*innen, was insbesondere bei Security Fixes relevant ist.

Bei Closed Source Produkten muss hierfür ein Ticket eröffnet werden, das ggf. nicht oder erst nach längerer Wartezeit umgesetzt wird. Die Erfüllung von Feature-Requests ist abhängig von den Interessen des Betreibers.

Allgemein liegt der Vorteil beim Support des Bausteins aber bei den kommerziellen Produkten. Mit dem Kauf der Lizenz und ggf. einem separaten Supportvertrag haben die Anwender*innen Anspruch auf Unterstützung. Die meisten Hersteller bemühen sich, dieses Argument durch kurze Antwortzeiten zu bekräftigen. Auf Seiten der Open Source Projekte ist man oft abhängig von der Community des Projekts. Hier gibt es keine Garantie, dass Fragen beantwortet und Probleme gelöst werden. Aktive Communitys fangen dieses Problem in der Regel auf, bei unbekannteren Projekten ist man auf sich allein gestellt. Dann hängt es stark von der Architektur- und Code-Qualität ab, ob sich Bugfixes oder neue Features gut im Alleingang einarbeiten lassen. Zu einigen der größeren Projekten kann Support von beteiligten Unternehmen oder unabhängigen Dienstleistern bezogen werden, womit sich sowohl das Kosten- als auch das Unterstützungsargument den Closed Source Varianten angleichen.

Ein weiterer Aspekt beim Einsatz von Open Source Software betrifft die rechtliche Seite der Verwendung von fremdem Code. Jedes Open Source Projekt kann über die Bedingungen für die Verwendung seines Codes entscheiden, darum müssen die jeweils geltenden Lizenzen sorgfältig geprüft werden. Insbesondere beim Einsatz in Closed Source Produkten dürfen Bausteine unter bestimmten Lizenztypen wie z. B. der GPL nicht verwendet werden (Goldstein 2019). Um der großen Vielfalt der Lizenzen von verwendeten Bausteinen und deren Abhängigkeiten (inklusive aller transitiven Abhängigkeiten) Herr zu werden, braucht es einer bestimmten Grundkenntnis und Sensibilität gegenüber diesen Themen. Zum Glück gibt es auch hier Tools, die z. B. dabei unterstützen, die verwendeten Lizenzen übersichtlich zu reporten.

Den größten Vorteil spielen Open Source Projekte dann aus, wenn sie ein florierendes Ökosystem begründen, in dem sich Anwender gegenseitig unterstützen, an der Weiterentwicklung beteiligen oder komplementäre Bausteine schaffen, die den Mehrwert des Projekts erhöhen. Gute Beispiele dafür sind das schon genannte Kubernetes, das Java Framework Spring und natürlich Linux.

Vor der Entscheidung, ob ein bestimmter Open Source Baustein eingesetzt wird, sollten – wie bei jeder Investitionsentscheidung – Vor- und Nachteile abgewogen werden. Neben den angesprochenen rechtlichen Aspekten gibt es noch weitere Punkte, die in eine Bewertung einfließen sollten. Für unsere Software-Projekte haben wir eine entsprechende Open Source-Checkliste (Tab. 1) erarbeitet, mit der die wichtigsten Fragen überprüft werden.

Bei jedem Aufläuten einer „Alarmglocke“ sollte genau untersucht und bewertet werden, wie sehr dieser Fall eine Verwendung im eigenen Produkt beeinträchtigt. Sollten sich daraus große Bedenken ergeben, so sucht man lieber nach Alternativen. Bei kleinen oder mittleren Bedenken sollte der Baustein zumindest so eingebunden werden, dass er später leicht ausgebaut oder ersetzt werden kann.

Die angegebenen Kriterien und Werte sind aus unserem „Bauchgefühl“ für den Einsatz in unseren Projekten entstanden und erheben keinen Anspruch auf Allgemeingültigkeit – je nach Rahmenbedingungen können sich Relevanz und Grenzwerte verschieben.

Aus der modernen Software-Entwicklung ist Open Source nicht mehr wegzudenken. Open Source Bausteine werden erfolgreich auf allen Ebenen von Entwicklung und Betrieb eingesetzt und tragen erheblich zur Produktivität bei. Gibt es einen allgemeinen Trend, Closed Source Bausteine durch Open Source zu ersetzen? Aus der Sicht eines einzigen Software-Dienstleisters ist dies nicht umfassend bewertbar. Wir nehmen allerdings durchaus wahr, dass unsere Kunden offener gegenüber Open Source werden. Auch Kunden, die bisher strikt auf Closed Source Software gesetzt haben, sind nun aufgeschlossen gegenüber der Verwendung entsprechender Open Source Pendants. Das liegt sicher auch daran, dass sich der Markt für Open Source Bausteine in den letzten Jahren weiter professionalisiert hat. So ist für die relevanten Projekte meist „echter“ Support verfügbar, entweder direkt vom Hersteller oder von unabhängigen Dienstleistern. Auch die vielleicht befürchteten rechtlichen Probleme sind managebar, wenn man die Bausteine sorgfältig auswählt. Dem entgegen stehen weiterhin Punkte wie fehlende Gewährleistung und die eben doch noch latent vorhandene Rechtsunsicherheit beim Einsatz von Open Source Software. Hier sind Anwender von Closed Source auf der sicheren Seite, wenn sie entsprechende Verträge abschließen.

Oft werden geringere Einarbeitungszeit und -Kosten als Vorteil von kommerziellen Produkten angeführt, weil die Hersteller meist Schulungen anbieten. Erfahrungsgemäß ist dies aber stark abhängig von der Qualität der Schulungsleistung. Spätestens wenn bei der Implementierung des eigenen Produkts mehr als „Hallo Welt“-Anforderungen an den Baustein gestellt werden, muss man doch wieder die (hoffentlich gute) Dokumentation wälzen. Dies gilt im gleichen Maße für Open und Closed Source Produkte.

Eine wichtige Informationsquelle ist in beiden Fällen der Austausch mit anderen Anwendern des Bausteins. Erfahrungen, Ideen und Problemlösungen Anderer helfen sowohl bei der Auswahl als auch beim Einsatz in der eigenen Software. Open Source Projekte haben es leichter, eine aktive Community zu entwickeln, da die Motivation zum freien Teilen von Informationen höher ist, wenn dies in beiden Richtungen passiert. Kommerzielle Produkte müssen mehr Aufwand investieren, um dies zu fördern.

Für uns bietet die aktive Mitwirkung an Bausteinen, die wir oft und/oder an zentralen Stellen unserer Projekte einsetzen, die Möglichkeit, unsere Anforderungen direkt einzubringen und Problemstellungen unserer Kunden optimal zu unterstützen. Bugs, die wir in unseren Projekten aufgedeckt haben, konnten wir schnell und ohne bürokratischen Umweg über den Hersteller beheben und so schnell zu einer guten Lösung kommen. Ebenso hilft uns der offene Austausch mit den Entwickler*innen und anderen Anwender*innen der Bausteine dabei, Nutzungsoptionen gut zu bewerten und auszuwählen. Für relevante Projekte wirken wir zudem gerne als „Botschafter“ und sprechen bei Konferenzen und Meetups über deren Einsatz. Dies hilft nicht nur den Projekten, sondern erhöht auch unsere Sichtbarkeit als Experten.

Als Software-Dienstleister sind wir darauf angewiesen, uns mit Qualität, Innovationskraft und Methoden der Software-Industrialisierung gegen vermeintlich günstigere Konkurrenz aus In- und Ausland durchzusetzen. Dies erfordert den Einsatz von bewährten Lösungen für Standardprobleme, damit sich das konkrete Projekt auf die spezifischen Anforderungen konzentrieren kann. Nur so lassen sich Innovation, Qualität und Entwicklungsgeschwindigkeit auf dem gewünschten Niveau halten. Open Source Bausteine sind dabei kommerziellen Varianten in der Funktion ebenbürtig und bieten bei umsichtigem Einsatz viele Vorteile. Insbesondere die Möglichkeit der Mitgestaltung eines Bausteins sowie die oft sehr aktiven Communities helfen bei der zielgerichteten Verwendung in unseren Projekten.

Wie bei allen Entscheidungen gilt es auch hier, die Stärken und Schwächen der vorhandenen Optionen abzuwägen und auf die Eignung für den jeweiligen Use Case zu untersuchen. Letztendlich sollte man sich dazu weder auf Marketing-Versprechen noch auf Community-Hypes verlassen, sondern auf den eigenen Sachverstand.