Aus dem Blog

Golo & Götz (05)

von Götz Martinek

"Golo & Götz ist eine gemeinsame Serie von Golo Roden und Götz Martinek. Der eine ist CTO der the native web GmbH, der andere Geschäftsführer der sodge IT GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Golo findet sich in seinem Blog auf heise.de/developer.

Die Fragestellung zu diesem Beitrag lautete: "Welche Bibliotheken nutzt ihr und warum?"

Nutzung von externen Bibliotheken

Wir nutzen in unseren Projekten häufig open source Bibliotheken. Zum Beispiel Boost, STL, ICU, catch, gstreamer, glib, libnice oder gnutls. Diese Bibliotheken bieten uns Funktionalitäten, die wir, ohne den Projektumfang zu sprengen, sonst nicht nutzen könnten.
Um unsere Aufgaben zu erledigen, sind wir auf solche Bibliotheken angewiesen und auch dafür dankbar.
Das Angebot an open source Bibliotheken ist allerdings überwältigend. Oft stellt man erst nach intensiverer Nutzung fest, dass eine Bibliotheke nur teilweise für das geplante Projekt sinnvoll genutzt werden kann. Unter Umständen stellt sich sogar während der Laufzeit des Projektes heraus, dass aufgrund einer speziellen Bibliothek Probleme für das gesamte Projekt enstehen. Das bedeutet nicht, dass die Bibliothek schlecht entwickelt ist. Meist passt der momentane Anwendungszweck bzw. die Umgebung (Compiler, OS, andere Libs, ...) nicht zur ursprünglichen Idee oder ursprünglichen Entwicklungsumgebung.
Wenn solche Probleme dann auftreten, befindet sich das Projekt meist in einem fortgeschrittenen Stadium und der Kunde hat ja schon gesehen, dass es tut. Oft wird dann ein Workaround genutzt, der das Problem momentan versteckt. Doch selbst, wenn das Problem wirklich gelöst wird, ist das keine langfristige sinnvolle Lösung. Die Lösung bleibt nämlich oft nur InHouse und wird nicht weitergegeben. Die so modifizierten InHouse Bibliotheken wachsen über die Generationen von Entwicklern immer mehr.
Was bei einer späteren Aktualisierung der genutzten Bibliothek zu den merkwürdigsten Fehlern führt. Diese Bibliotheken sind irgendwann ein riesiger Aufwandsklotz, der jegliche weitere Entwicklung verlangsamt.

Am sinnvollsten ist es, wenn auch noch nicht weit verbreitet, wenn Änderungen an Open Source Projekten als Patch upstream geliefert werden. Dies bedeutet einiges an Aufwand, denn erstens
reicht hier kein Workaround eines lokalen Problems, sondern es muss wirklich gelöst werden. Zweitens muss das gelöste Problem zum Kern/Ziel der Bibliothek passen und von den Maintainern angenommen werden und drittens ist auch der Aufwand, dem Projekt beizusteuern, nicht zu unterschätzen.
Allerdings rentiert sich dies oft langfristig, da so solche InHouse modifizierte Versionen nicht mehr gewartet werden müssen und so die neuen Entwicklungen nicht zusätzlich behindern oder im Falle
einer Aktualisierung der Bibliothek stören. Um die Auswirkungen besser darzustellen, könnte man überspitzt sagen: "Man hat die Wahl, eine eigene Bibliothek komplett zu maintainen (InHouse) oder an einer öffentlichen Bibliothek mitzuarbeiten."

Das nächste Thema, welches man sich beim Einsatz von externen Blibliotheken anschauen muss, sind die Lizenzen, unter denen die entsprechenden Blibliotheken stehen. Der Dschungel an Lizenzen ist unübersichtlich und wie so oft liegt der Fehler im Detail und der juristischen Auslegung. Einen groben Überblick liefern u.a. https://tldrlegal.com/ oder https://choosealicense.com/. Letztere bietet auch eine Hilfe bei der Suche nach einer passenden Lizenz für das eigene Open Source Projekt. Im Detail hilft meist nur ein juristischer Ansprechpartner. Ein Lichtblick, aus Sicht der Entwickler, beim Kontakt mit Juristen und Lizenzen: sollte das Entwicklungsbudget für ein sinnvolles Update auf eine neue Bibliothek oder ähnliches mal nicht ausreichen, reicht meist ein Hinweis auf mögliche Lizenzprobleme oder Lizenzverbesserungen.

Um das Auftreten solcher Probleme zu verringern, ist es sinnvoll, die Nutzung und Eignung einer Bibliothek in den Entwicklungsprozess mit aufzunehmen und nicht bei Bedarf einfach das erste Ergebniss einer Websuche zu nutzen.
Manchmal kann ein kurzer Check der Aktivität des gewünschten Open Source Projektes im Vorfeld schon einen Hinweis geben, ob das Projekt für den Einsatz der der Zielumgebung geeignet ist.
Am Besten ist es, wenn man sich mit den einzusetzenden Bibliotheken im Vorfeld struktuiert auseinander setzt. Auch helfen oft kleine Testprojekte, um eine Bibliothek in der gewünschten Umgebung und für den gewünschten Anwendungszweck näher zu betrachten. Daher "Prüfe wer sich (ewig) bindet."

Zurück