Suche
LiesMich.jar Teil 1

Make or Buy: Bewusster Umgang mit 3rd Party Libraries

Harm Gnoyke

©Shutterstock/igor.stevanovic

Eine 3rd Party Library ist in Java schnell eingebunden. Entwickler freuen sich über die gesparte Zeit und die geschenkte Funktionalität. Auch der Projektleiter ist froh, kann er nun den Entwickler wieder an richtigen Features arbeiten lassen. Doch heißt „geschenkt“ auch wirklich kostenlos? Natürlich ist die Antwort darauf „Nein“, denn ein Projektteam sollte Folgekosten und Risiken bei solch einer Entscheidung immer berücksichtigen. Im ersten Teil dieses zweiteiligen Beitrags steht die Entscheidung für eine Library im Vordergrund.

Als 3rd Party Library bezeichnet man eine Library, die von einer projektfremden Partei bereitgestellt wird. In Java-Projekten ist der Einsatz von 3rd Party Libraries weit verbreitet, und es stehen eine Menge solcher wiederverwendbarer Komponenten zur Auswahl. Die Einsatzzwecke reichen dabei von einfachen Utility-Funktionen  (z.B. Apache Commons [1] oder Google Guava [2]) bis zu komplexen Frameworks für die Persistenzschicht (z.B. Hibernate [3]).

Im Folgenden werden typische Situationen betrachtet, die Projekten beim Einsatz von 3rd Party Libraries begegnen. Es werden Ansätze gezeigt, mit denen diese Situationen gemeistert werden, und wie vermieden wird, dass ein Projekt in einer Sackgasse landet.

Zum Anfang muss noch richtiggestellt werden, dass in der Einleitung „geschenkt“ gesagt wurde. Dies trifft natürlich nicht  beim Einsatz einer kommerziellen Lösung zu. Hier sind sofort Lizenzkosten fällig. Doch auch bei solch einer Entscheidung darf das Team sich nicht komplett aus der Verantwortung ziehen und alles dem Anbieter überlassen.

Nun aber zu den typischen Situationen im Projektverlauf.

„Make or Buy“

Vor dem Einsatz einer neuen Library sollte man sich zunächst fragen, ob diese wirklich benötigt wird. Zur Bewertung ist es hilfreich, die aktuell eingesetzten Libraries zu kennen und deren Zweck auch nennen zu können. Dafür hilft als Überblick eine einfache Tabelle mit den Libraries und einer kurzen Beschreibung ihres Einsatzzwecks (Tabelle 1). Ob die aktuell eingesetzte Version Teil der Tabelle sein sollte, ist zumindest diskutabel, da diese Information veralten kann. Ein guter Kompromiss ist ein Link in die Versionsverwaltung zu der Ressource, in der die Version einer oder aller Libraries aufgeführt ist.

Library Einsatzzweck Besonderheit
ABC Erzeugung von PDF Dokumenten Singleton-Zugriff wegen hohem Speicherbedarf
DEF Logging keine

Tabelle 1: Library Überblick für ein Projekt

Eventuell muss man sich nun gar nicht mehr auf die Suche nach Alternativen machen, sondern kann sich damit begnügen, was bereits eingebunden ist. Das befreit von vielen der folgenden Fragestellungen bzw. wurden diese ohnehin bereits für die eingebundenen Bibliotheken beantwortet.

Tabelle 2 zeigt Kriterien und beispielhafte Fragestellungen an das Team bei der Auswahl einer Library. Diese helfen bei der Bewertung, ob sich der Einsatz der Bibliothek lohnt, oder auch um verschiedene Alternativen gegeneinander abzuwägen.

Kriterium Beispielfrage(n)
Zweck Wofür möchte man die Library einsetzen? (Siehe auch Tabelle 1)
Aktualität Wird die Library aktiv gepflegt? Welchen Reifegrad hat die Bibliothek (Indikator Versionsnummer >= 1.x)?
Änderbarkeit Wie gut kann man die Funktionalität an seine Bedürfnisse anpassen bzw. sie auch später erweitern?
Verständlichkeit Kann man den Code der Library gut lesen und verstehen? Wie ist das Laufzeitverhalten? Kann man den Code gut debuggen?
Aufwand Wie hoch ist der tatsächliche Integrationsaufwand? (Anmerkung: Für die Beantwortung helfen auch die anderen Kriterien weiter). Wie hoch wäre der Schulungs-/Trainingsaufwand für betroffene Entwickler?
Verbreitung Wie häufig wird die Library in anderen Projekten genutzt? Wie gut ist das Know-how bei eigenen Entwicklern? Könnte man sich Know-how von außen einkaufen?
Lizenzmodelle Gibt es Kosten je Server/CPU/User? Welche Vertragslaufzeiten gibt es? Gibt es Beratungs-/Schulungsleistungen bei Vertragsabschluss inklusive? Falls es eine kostenlose und eine kommerzielle Edition gibt: Welchen konkreten Vorteil bringt mir die kommerzielle Edition für meinen Kontext?
Interoperabilität Wie würde sich die neue Library in die vorhandene Software einfügen? Muss man sich auf Inkompatibilitäten mit vorhandenen Libraries einstellen und dafür Aufwände einplanen?
Kapselungsmöglichkeit Lässt sich die Bibliothek kapseln oder muss man sie direkt nutzen? Ist der Aufwand für eine Kapselung vertretbar? Wie passt die Fehlerbehandlung zur eigenen Strategie?
Tests Kann man Tests für die gewünschten Funktionalitäten schreiben? Wie schwierig ist es, diese Tests zu schreiben? Wie gut ist die Bibliothek selbst getestet?
Branching Wie sieht die Branching-Strategie bei der Library aus? Werden Bugfixes auch auf älteren Branches umgesetzt?
Wichtigkeit für Projekt Bis wann muss eine Entscheidung herbeigeführt sein? Was wären die Konsequenzen beim Aufschieben oder Nicht-Treffen der Entscheidung?

Tabelle 2: Kriterien zur Auswahl einer Library

Wenn eine Eigenentwicklung eine Alternative ist, wird diese auch in die Tabelle aufgenommen und sichert damit die Entscheidung zusätzlich ab.

Nach der Entscheidung

Wenn das Team sich dazu entschließt, eine neue Fremdbibliothek aufzunehmen, ist die Arbeit nicht nach der Aufnahme in die Projektabhängigkeiten erledigt. Das Team weist den Projektleiter erneut auf Folgekosten hin: Das Zusammenspiel der eigenen Software mit der Library bleibt ein ständiger Begleiter im Projektverlauf.

Speziell die Eigenschaften Änderbarkeit und Erweiterbarkeit der eigenen Software sind stets zu hinterfragen, was schon bei der initialen Überlegung „Make or Buy“ – also selber programmieren oder 3rd Party Library nutzen – eine Rolle spielte. Wenn wir etwas selbst bauen, können wir uns immer selbst um Änderungen oder etwaige Probleme kümmern und müssen uns nicht an einen Dritten wenden. Hingegen muss man für die gewünschte Funktionalität bei einer Library eventuell Einschränkungen hinnehmen, kann allerdings auf bereits erprobte Lösungen zurückgreifen.

Um was man sich alles kümmern muss

Als Entwicklungsteam sieht man sich hauptsächlich in der Verantwortung für die Teile einer Software, die selbst geschrieben wurden. Wenn aber eine Fremdbibliothek eingebunden ist, kann man die Verantwortung nicht einfach auf den Hersteller übertragen (Abbildung 1). Im Falle eines kommerziellen Anbieters werden SLAs ausgehandelt oder vorgegeben. Für Open-Source-Projekte gibt es so etwas nicht. Wenn es um schnelle Hilfe bei kritischen Fehlern geht, helfen jedoch auch SLAs nicht weiter, da diese nur eine Reaktionszeit beschreiben, aber nicht die Zeit bis zur Lieferung eines Bugfixes versprechen. Als ersten Impuls wünschen sich Kunden zwar genau dies. Doch frage man sich einmal selbst: Würde das eigene Projekt sich auf solche SLAs gegenüber dem Kunden einlassen? Sehr wahrscheinlich nicht, da man in Gefahr gerät, in Regress genommen zu werden. Das Handeln der kommerziellen Anbieter ist also verständlich.

 

Abb. 1: Verantwortungsgrenze: Die Art der Verantwortung ändert sich

Abb. 1: Verantwortungsgrenze: Die Art der Verantwortung ändert sich

 

Wie gut und schnell die Communities von Open-Source-Projekten weiterhelfen, lässt sich nur schwer vorhersagen. Von außen betrachtet gibt es die folgenden Fragen zur Überprüfung (siehe auch Tabelle 2):

  • Wie viele Teammitglieder gibt es?
  • Wie viele Commits gibt es auf dem Repository, d.h. wie aktiv ist die Community?
  • Ist das Projekt in einem reiferen Zustand und wird schon von anderen eingesetzt – oder wäre man ein Versuchskaninchen?

Eine tiefere Untersuchung dieses Aspekts würde neben einer intensiveren Auseinandersetzung mit dem Source Code auch das Bauen von Prototypen und die Beobachtung des Laufzeitverhaltens beinhalten.

  • Kümmert sich die Community nur um das aktuellste Release oder auch um frühere Releases?

Speziell diese letzte Frage ist wichtig, wenn man ein akutes Problem hat, aber nicht die Möglichkeit, auf die neueste Version zu gehen.

Das Thema Open-Source-Lizenzen spielt natürlich auch eine wichtige Rolle, kann hier aber nicht in aller Tiefe behandelt werden. Einen Überblick über die gängigsten Modelle vermittelt der Kasten „Open-Source-Lizenzmodelle“.

Open-Source-Lizenzmodelle (siehe auch [4] und [5])Ein kurzer Ausflug in die Rechtsabteilung soll zeigen, dass ein Projektteam sich über die verschiedenen Lizenzmodelle bewusst sein muss. Hier sind wesentliche Kategorien und prominenteste Lizenzen als Vertreter der jeweiligen Kategorie aufgeführt.CopyrightFür veröffentlichten Code, der ohne Lizenzhinweis veröffentlicht wird, gilt das allgemeine Copyright. Dies ist zwar von Land zu Land unterschiedlich, man kann sich aber an die übergeordnete Regel halten, dass weitere Verwendung nur nach Genehmigung des Autors geschehen darf.Public Domain

Bei erloschenem Copyright oder aber expliziter Veröffentlichung als Public Domain kann der Nutzer der Software tun, was er möchte. Auf den Punkt bringt dies die WTFPL („Do what the fuck you want“ Public License).

      Copyleft

Ein Wortspiel zu Copyright, welches auch im entsprechend gespiegelten Symbol verdeutlicht wird. Copyleft ist aber nicht etwa das Gegenteil, sondern die Ergänzung, dass Verwender ihre abgeleiteten Werke unter die gleiche Lizenz stellen müssen. Prominentester Vertreter ist die GNU General Public License (GPL), die auf das GNU-Projekt und die Free Software Foundation zurückgeht, die Mitbegründer der Open-Source-Bewegung.

Es gibt noch eine weniger restriktive Form der GPL, die GNU Lesser General Public License (LGPL), welche nicht erfordert, dass eigene Software ebenfalls veröffentlicht werden muss, bis auf die Teile, die unter LGPL veröffentlicht worden sind. So wird sichergestellt, dass Änderungen und Erweiterungen weiter frei verfügbar sind.

Copyfree

Noch einen Schritt weiter als die LGPL gehen die Copyfree-Lizenzen wie die Apache License. Hier gibt es keine Einschränkungen für die Lizensierung der eigenen Software bei Verwendung einer solchen Library.

 

Fazit: Wer seine Software also in irgendeiner Form veröffentlicht oder weiterverkauft, sollte speziell bei Copyleft-Lizenzen aufpassen. Eine grundlegende Kenntnis dieser Lizenzen ist auch für den interessant, der nur Teile seiner Software frei zugänglich macht und damit der Open-Source-Welt ein Stück zurückgeben möchte. Wenn man unsicher ist, welche Lizenz die richtige ist, hilft zum Beispiel der „Licence differentiator“ weiter [6].

Wem das alles zu kompliziert war, dem sei die Beerware-Lizenz empfohlen, die dem Autor ein Bier verspricht, sollte man sich mal persönlich treffen.

Haben Sie es schon mit unserer neuesten Version probiert?

Stößt man als Benutzer auf einen Bug in einer Library, ist der Standard-Reflex der Library-Anbieter oft, zum Update auf eine aktuellere Version zu raten. An dieser Stelle sind aber oft die Hände gebunden. Hat man es zum Beispiel mit Implementierungen von JPA zu tun, kann ein Entwickler die Seiteneffekte von einem Upgrade auf die neueste Version nur schwer abschätzen. Aufgrund der sehr wahrscheinlich weiten Verbreitung in der eigenen Software müsste man viele Tests durchführen, um hier Sicherheit zu erlangen. Die eigenen Unit-Tests können weiterhelfen, um bewerten zu können, ob das Problem richtig behoben wird.

Mit Einbinden einer komplett neuen Version werden häufig weitere Änderungen als nur die benötigten Bugfixes eingeführt. Hier helfen wiederum viele Tests weiter. Man kann sich aber auch absichern, indem man die gewünschte Funktionalität einer Library exakt bestimmt und auch entsprechend testet. Im besten Fall kann ein Projekt seine Tests sogar an den Anbieter zurückfließen lassen, so dass die Testfälle im Sinne von  „Consumer Driven Contract Testing“ [7] schon vor Auslieferung der Library laufen. Im ersten Schritt ist es ausreichend, dass solche Tests überhaupt ausgeführt werden.

Die Kosten für dieses Vorgehen steigen, je breiter die Schnittstelle ist. Daher ist dies für Frameworks nicht umfassend machbar. Man kann sich aber auf wichtige genutzte Funktionalitäten beschränken und nur bestimmte Fälle gründlicher testen. Für kleinere eingesetzte Libraries oder Schnittstellen ist dieser Testansatz also lohnenswert.

Lesen Sie Teil 2 dieser Reihe: Darin begeben wir uns zusammen mit dem Anbieter auf Fehlersuche und zeigen, worauf man bei Aktualisierungen einer Library achten sollte.

Aufmacherbild: Stack of Used Old Books in the School Library, Toned Cross Processed Image von Shutterstock / Urheberrecht: igor.stevanovic

Geschrieben von
Harm Gnoyke

Harm Gnoyke (embarc GmbH; hg@embarc.de) hat gute und schlechte Erfahrungen mit 3rd Party Libraries in internationalen Java Projekten von ganz klein bis ganz groß gesammelt. Für embarc unterstützt er Kunden bei Analyse und Design komplexer Softwarearchitekturen.

Kommentare
  1. Blogserie auf JAXenter: "LiesMich.jar - Bewusster Umgang mit 3rd Party Libraries" - embarc2015-09-22 15:24:35

    […] – Bewusster Umgang mit 3rd Party Libraries Blogserie von Harm Gnoyke Teil 1 online bei JAXenter erschienen am 22. […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.