Warum wir Open-Source-Projekte unterstützen

Freitag Mittag, das neue Feature ist fast fertig. Fehlt nur noch der CSV-Export…gibt es dafür nicht fertige Bibliotheken? Dann könnte ich das Thema heute noch abschließen…

Ah ja, der “Super Easy CSV Exporter”. Auch noch Open-Source und frei verwendbar, perfekt - keine Lizenzgebühren, also keine zusätzlichen Kosten für uns oder den Kunden. Auf geht’s!

Solche oder ähnliche Szenen kommen während der Entwicklung eines Softwareprojekts immer wieder vor. Natürlich macht es erstmal Sinn, das Rad nicht jedes Mal neu zu erfinden, sondern bestehende Funktionalität zu nutzen. Umso besser, wenn sie frei verfügbar ist. Gerade für weniger wichtige Rand-Features ist es oft schwierig, die Kosten für kommerzielle Lizenzen zu argumentieren, vor allem, weil je nach Hersteller teilweise Abos mit laufenden monatlichen Kosten und/oder Lizenzen für das ganze Team notwendig sind (unabhängig davon, wie viele Leute tatsächlich damit arbeiten).

Wie wir Bibliotheken auswählen

Ganz so einfach wie oben beschrieben machen wir uns die Entscheidung für eine bestehende Komponente in der Praxis übrigens nicht. Folgende Fragen spielen bei der Bewertung und Auswahl eine Rolle:

Wird die Bibliothek regelmäßig gewartet und aktualisiert?
Wie viele Entwickler:innen arbeiten aktiv daran?
Wie viele andere Leute verwenden sie bereits?
Wie sieht es mit dem Support aus? Wie wird mit offenen Tickets umgegangen?
Wie groß ist die Abhängigkeit der Anwendung von der Bibliothek?

Trotzdem bleibt ein gewisses Risiko: Oft wird der Code nur von einzelnen Privatpersonen in ihrer Freizeit gewartet und “as is” zur Verfügung gestellt. Meist gibt es keine Garantie, dass die Wartung auch in Zukunft gewährleistet ist.

Wenn der Erfolg zum Problem wird

Das führt zu einem im ersten Moment paradox erscheinenden Phänomen: Je erfolgreicher eine Bibliothek wird, je mehr Leute sie nutzen, desto höher wird auch der Aufwand für die Wartung und Weiterentwicklung. Wenn es sich zeitlich irgendwann nicht mehr ausgeht, all die Feature Requests und Bug Reports zu bearbeiten, während die Komponente selbst ja auch aktuell gehalten werden will, bleibt den Entwickler:innen dann oft nur die Wahl zwischen mehreren suboptimalen Optionen, um nicht im Burnout zu landen:

Einstellung von Wartung und Weiterentwicklung
Manche Projekte werden irgendwann einfach nicht mehr weiterentwickelt. So geschehen ist das in jüngerer Vergangenheit zum Beispiel bei der Bibliothek Swashbuckle für die Generierung von OpenAPI Metadaten, obwohl (oder weil?) diese sogar in den offiziellen Projekt-Templates für ASP.NET Core von Microsoft genutzt wurde und bei über 40 Millionen Downloads steht.
Das stellt die Nutzer:innen natürlich vor ein großes Problem: Man kann zwar die letzte veröffentlichte Version weiter nutzen, aber früher oder später wird es zu Inkompatibilitäten mit anderen Komponenten kommen, und spätestens dann braucht man eine Alternative. Man könnte jetzt natürlich argumentieren, dass es ja eben ein großer Vorteil von Open-Source-Software ist, dass der Code verfügbar ist und man ihn somit selbst weiterentwickeln kann. Das stellt jedoch oft nur eine theoretische Möglichkeit dar. Ganz abgesehen vom Aufwand sind viele Projekte zu komplex, als dass eine Einarbeitung einfach möglich wäre. Das beste, was in diesem Fall passieren kann, ist dass sich in der Community genügend Leute finden, die bereit sind, das Projekt am Leben zu erhalten (siehe Übergabe).
Im schlimmsten Fall machen die Autor:innen die Pakete aus Protest sogar unbrauchbar ¹ ².
Übergabe
Wie bereits erwähnt, kann es eine Möglichkeit sein, die Weiterentwicklung der Bibliothek auf mehrere Schultern zu verteilen. Das geht aber natürlich nur dann, wenn es auch genügend andere Entwickler:innen gibt, die sich dazu imstande sehen und ihrerseits dazu bereit sind - ansonsten verschiebt sich das Problem nur auf jemand anderen. Außerdem ist auch diese Variante nicht frei von Risiken. So wurde im April 2024 eine Sicherheitslücke in den XZ Utils entdeckt, die dort absichtlich von mutmaßlich staatlichen Akteuren eingefügt wurde ³ ⁴. Der urspüngliche Autor Lasse Collin, der schon länger über Überlastung geklagt hatte, wurde über Monate und Jahre dazu gedrängt, weiteren Personen Zugriff auf sein Projekt zu geben - was dieser schließlich auch tat.
Umstellung auf ein kommerzielles Lizenzmodell
Viele Projekte versuchen auch, bei entsprechendem Erfolg auf ein kommerzielles Lizenz-Modell umzusteigen, z.B. IdentityServer, ImageSharp, QuestPDF oder EPPlus, um nur einige zu nennen. Ob das von vornherein so geplant war oder schlicht eine Notwendigkeit, um das Projekt am Leben zu erhalten, lässt sich als Außenstehende:r schwer feststellen.
Für die Nutzer:innen der Bibliotheken ist es aber natürlich trotzdem bitter, gerade wenn die Auswahl (auch) aus Kostengründen getroffen wurde. Es bleibt dann nur die Wahl, die (oft monatlichen) Kosten zu akzeptieren oder (sofern vorhanden) auf eine andere Komponente umzusteigen - die möglicherweise aber vor ähnlichen Problemen steht. Und auch der Umstieg verursacht natürlich Aufwand und Kosten.
Auch bei dieser Variante schrecken leider manche Entwickler:innen nicht vor fragwürdigen Praktiken zurück: Der Autor der bekannten Bibliothek Moq hat beispielsweise beim Versuch die Nutzung zu monetarisieren großen Ärger der Community auf sich gezogen, weil er auf undurchsichtige Weise und entgegen jeglicher Datenschutzbedenken und -bestimmungen Code eingefügt hat, der für die Überprüfung der Lizenz die E-Mail-Adressen der Nutzer:innen in die Cloud hochgeladen hat ⁵.)

Nachhaltigkeit

So richtig nachhaltig ist das jedenfalls alles nicht (und wie mein Kollege Tobias in Ausgabe 6 unseres Kundenmagazins aware beschreibt, ist Nachhaltigkeit ein wichtiges Thema für uns ⁶). Aus Sicht der Entwickler:innen ist es aber auch verständlich, dass man nicht seine Feierabende und Wochenenden opfern will, damit diverse Fortune 500-Unternehmen gratis davon profitieren können.

Der Vorwurf ist nicht ganz von der Hand zu weisen: Laut einer Studie der Harvard Business School⁷ (The Value of Open Source Software) müssten Firmen 3,5 mal so viel Geld für Softwareentwicklung ausgeben, wenn es keine frei verfügbare Open-Source-Software gäbe. Die Studie liefert außerdem noch eine brisante Schätzung, wieviel Geld es global gesehen kosten würde, wenn die Nutzer:innen der meist verbreiteten Open-Source-Projekte die entsprechende Funktionalität stattdessen selbst implementieren müssten: unglaubliche 8,8 Billionen Dollar ($ 8.8 trillion).

Sponsoring

Langsam erfolgt daher ein Umdenken in der Branche. Immer mehr Entwickler:innen fordern, dass gerade große Firmen bei der Nutzung von Open-Source-Software die dahinterstehenden Personen fördern und unterstützen, anstatt sich nur die (kostenlosen) Früchte ihrer Arbeit zu Nutze zu machen.

Auch wenn wir knapp noch nicht zu Fortune 500 gehören 😉: Auch wir versuchen, unseren Beitrag zu leisten. Aus diesem Grund unterstützen wir als Firma unsere meistgenutzten Open-Source-Bibliotheken bzw. deren Autor:innen mit einem monatlichen Beitrag. Dank des GitHub Sponsors Programmes ist das sehr unkompliziert möglich. Eine Alternative wäre beispielsweise das Open Source Collective, viele Entwickler:innen sind auch auf Crowd-Funding-Plattformen vertreten.
Können die Autor:innen davon leben? Nur von unserem Beitrag nicht. Aber je mehr Leute und Firmen die Notwendigkeit erkennen und ebenfalls dazu beitragen, das Open-Source-Ökosystem nachhaltig zu gestalten, desto realistischer wird dieses Ziel.