/ open source

Open Source - oder doch Fauxpen?

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.