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 von the native web GmbH, der andere Geschäftsführer von 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 Bibliothek 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 entstehen. Das bedeutet nicht, dass die Bibliothek schlecht entwickelt ist. Meist passt der momentane Anwendungszweck oder 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 modifizierten 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 Bibliotheken anschauen muss, sind die Lizenzen, unter denen die entsprechenden Bibliotheken stehen. Der Dschungel an Lizenzen ist unübersichtlich, und wie so oft liegt der Fehler im Detail und in der juristischen Auslegung. Einen groben Überblick liefern u. a. tldrlegal.com oder choosealicense.com. Letztere Adresse 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, genügt 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 Ergebnis 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 in der Zielumgebung geeignet ist.
Am besten ist es, wenn man sich mit den einzusetzenden Bibliotheken im Vorfeld strukturiert auseinandersetzt. Auch helfen oft kleine Testprojekte, um eine Bibliothek in der gewünschten Umgebung und für den gewünschten Anwendungszweck näher zu betrachten. "Drum prüfe, wer sich (ewig) bindet."

Zurück