Im Rahmen der täglichen Entwicklungsarbeit setzen Europace Entwicklungsteams immer wieder auf Freie und Open Source Software. Aufgrund der gelebten Selbstorganisation liegt auch die Verantwortung über die Entscheidung für oder gegen die Einführung einer externen Abhängigkeit in den Entwicklungsteams.
Ist die Entscheidung über den Einsatz eines Open Source Projektes die ausschließlich von technischen Kriterien abhängt? Schaut man auf die übliche Lebensdauer eines Softwareprojektes wird schnell klar, dass das was heute als Hype ins Projekt wandert oft lange über die Dauer des Hypes seinen Dienst tun muss: Selbst im Linux kernel Umfeld gibt es insbesondere im professionellen Umfeld Stimmen, die nach sechs Jahren long-term-support rufen.
Rahmen und Kontext
Die bei Europace entwickelte Software setzt sich aus unterschiedlichsten Komponenten zusammen: Selbst entwickelt, proprietär aber auch Open Source. Die folgenden Kriterien sollen ein Leitfaden sein, Open Source Komponenten über den technischen Aspekt hinaus besser bewerten zu können. Open Source hier heißt, Open-Source-Lizenz:
Lizensierung: Projekte müssen mit einer OSI zertifizierten Open Source Lizenz kommen. Beispiele: AL2.0, MIT, GPL.
Es muss klar sein, dass mit dem Projekt keine aus rechtlicher Sicht unzulässigen Abhängigkeiten mitkommen.
Nicht nur die Technik entscheidet
Neben der technischen Eignung sind auch Kriterien zu betrachten, die sich auf Projektführung, Finanzierung und Governance beziehen. Oft müssen hier Abwägungen getroffen werden. Alle folgenden Kriterien sind als Empfehlung zu verstehen, die je nach konkret anstehender Entscheidung hinsichtlich Risiko/ Vorteil zu gewichten sind.
Code
Letzter Commit … Wurde in den letzten Wochen und Monaten an einem Projekt nichts mehr getan, kann dies ein erstes Indiz dafür sein, dass ein Projekt nicht mehr aktiv gepflegt wird. Werden auch keine Anfragen von Nutzern mehr beantwortet, sollte man sich darüber im Klaren sein, dass ein Einsatz dieses Projektes heißen kann, sich selbst um das Beheben von Fehlern kümmern zu müssen (also das Projekt mit entsprechendem Zeitaufwand selbst führen und instand halten zu müssen).
Einfachheit … Ein Projekt das viele transitive Abhängigkeiten mitbringt oder selbst umfangreicher oder komplexer als notwendig ist, erhöht damit das Risiko für Lücken, Fehler oder Sicherheitslücken.
Buildsystem … Ein Projekt, das Standard-Build-Tools verwendet, läßt sich auch lokal auschecken und anpassen. Je schwerer es ist, ein Projekt zu bauen, umso höher ist auch die Hürde für andere potenzielle Mitstreiter, eigene Verbesserungen vorzunehmen.
Dokumentation … Projekte sollten die Hoheit über ihre eigene Dokumentation haben. Dabei spielen Faktoren wie Aktualität, Verfügbarkeit für vergangene Releases, Offline-Verfügbarkeit, Vollständigkeit eine Rolle. Dokumentation umfasst hier Design, Code, Nutzerdokumentation, aber auch Dokumentation der üblichen Kommunikations- und Entscheidungsprozesse im Projekt.
Hält sich das Projekt bei APIs an existierende Standards?
Design … Werden Diskussionen über Designentscheidungen öffentlich nachvollziehbar geführt? Kann ich als Nutzer nachvollziehen wann und warum Features hinzugefügt oder gelöscht werden? Inwieweit kann ich diese Entscheidungen beeinflussen? Offene Entscheidungsprozesse führen zwar unter Umständen einerseits zu einer verlangsamten Entwicklung, andererseits aber dazu, dass das Projekt von mehr als einem einzelnen Player getragen wird.
Releases
Regelmäßige Releases … Softwareprojekte sind üblicherweise nie fertig, mindestens Bugfixes und Securitypatches sollten in regelmäßig veröffentlichten Releases einfließen.
Security … Wie geht das Projekt mit dem Thema Security um? Werden CVE Nummern für bekannte Lücken vergeben? Wie zügig werden Lücken gepatcht? Werden Lücken öffentlich oder in einem geschützten Raum diskutiert, solange noch keine Lösung zur Behebung der Lücke implementiert wurde? Über welche Kanäle werden Nutzer von solchen Lücken in Kenntnis gesetzt?
Verfügbarkeit in geeignetem Package-Repo … Wird zur Verteilung ein bekanntes Packagingformat eingesetzt, ist es einfacher das Projekt intern zu integrieren - und neue Versionen nach einem Update auszurollen.
Findet eine Releaseplanung statt und wenn ja, wie transparent wird der Planungsprozess durchgeführt? Wer ist daran beteiligt?
Projektführung
Entwicklung von Issues/Pull Requests/Patches über die Zeit … Ein Projekt ohne jegliche offenen Issues ist ein Indiz für ein Projekt, dass keine Nutzer, und damit eine ungewisse Zukunft hat. Auch wenn Issues nicht mehr oder nur schleppend bearbeitet werden liegt der Verdacht nahe, dass das Projekt nicht mehr die Pflege erhält, die es eigentlich bräuchte - auch wenn es in diesem Fall wahrscheinlicher ist, dass man als Nutzer Gleichgesinnte findet, die bereit sind, dabei zu helfen, das Projekt am Leben zu erhalten.
Finden sich unter den Issues trivial zu behegende Bugs als Einladung an neue Entwickler?
Bus Faktor … Ist das Projekt von einer Entität abhängig oder wird es überleben, wenn der aktuelle Sponsor das Projekt verläßt? Mit Entität ist hier nicht nur gemeint, dass ein Projekt mehr als einen Maintainer haben sollte - auch für Projekte, die ausschließlich von Entwicklern eines Unternehmens vorangetrieben werden, besteht das Risiko, dass dieses Unternehmen seine Unterstützung für das Projekt zurückzieht. Ein Blick auf das Geschäftsmodell kann hier bei der Entscheidung helfen. (Einfache Tests: Anzahl der Entwickler; Anzahl der unterschiedlichen Unternehmen für die diese Entwickler arbeiten; Rechtsform des Inhabers des Projekt-Trademarks, finanzielle Absicherung des Projektes.)
Unabhängigkeit … Wie werden Projektbeiträge behandelt? Gibt es eine bevorzugte Abarbeitung von Issues/Pull Requests/Patches einzelner Beteiligter oder sind alle Beiträge willkommen? Welche Vorraussetzungen müssen erfüllt sein, um das Projekt aktiv mitgestalten zu können (einfacher Test: Wer hat auf das Projektrepository Schreibrechte?)
Community … Von wem und von wievielen wird das Projekt hinsichtlich der Faktoren Quellcodeentwicklung, Marketing, People Management, User-Support, Trainings, Dokumentation unterstützt? Werden Dritte bei der Entwicklung von Integrationen, Tooling, Plugins aktiv unterstützt? Wie groß ist das daraus entstandene Ökosystem? Wie stabil ist es?
Offenheit des Projekts … Wie transparent werden Entscheidungen gefällt? Welche Möglichkeiten gibt es, sich selbst aktiv am Projekt zu beteiligen? Wie geht das Projekt mit Fragen von Newbies um (Stichwort Mentoring)?
Professional services … Von wem und von wievielen Drittanbietern kann Unterstützung für Einführung, Betrieb, Anpassung und Weiterentwicklung eingekauft werden?
Nutzer
Verbreitung … Wird ein Projekt nur von einigen wenigen Nutzern eingesetzt wird es schwerer sein, andere Nutzer zu finden, die es in ähnlichen Szenarien einsetzen wie man selbst. Entsprechend wird es schwerer, Hilfe zu finden. Entsprechend wird es unwahrscheinlicher, dass umgebungsabhängige Fehler schnell gefunden und behoben werden. Indizien können hier sein: Beliebtheit auf Github, verfügbare Meetups, Einträge auf “Powered By” Seiten, Erfolgsgeschichten von Nutzern, verfügbare Bücher, Popularität auf Stackoverflow.
Weiterführende Links
Apache Project Maturity Model: https://community.apache.org/apache-way/apache-project-maturity-model.html
Producing Open Source Software: Evaluating OSS Projects
OSS Watch: Openess evaluation
Credits
Dankeschön an Tobias Gesellchen, Markus Ackermann, Peter Sauer, Stephan Harbauer und Ralf Alberti für die Unterstützung bei der Ausarbeitung des Artikels.