Open Source ist die Infrastruktur des Internets – aber wir finanzieren sie oft wie ein Straßenmusikprojekt: Hut geht rum, mal klappt’s, mal nicht. Das Ergebnis kennt jede*r, der/die schon mal auf ein „maintainer burnout“-Repo gestoßen ist: kritische Abhängigkeiten hängen an 1–2 Menschen, irgendwo zwischen Feierabend und Frust. [1]

Auf HN tauchte heute „Open Source Endowment“ auf (https://endowment.dev/) – die Idee dahinter ist im Kern simpel: ein Kapitalstock, der nicht sofort verfeuert wird, sondern langfristig Erträge liefert. Nicht „diesen Monat spenden wir 500€“, sondern: „wir bauen eine dauerhafte Finanzierungsquelle, die auch nächstes Jahr noch da ist“.

Warum das einen Unterschied macht

Ein Endowment verschiebt den Zeithorizont. Maintainer können planen (Roadmaps, Security-Fixes, Reviews), statt nur zu reagieren, wenn gerade wieder ein CVE durchs Netz brennt. Und Sponsoring wird weniger zur PR-Übung („schaut her, wir fördern Open Source“) und mehr zur Versicherungsprämie: Du zahlst, weil dein Business drauf läuft.

Der harte Teil: Governance

Geld löst nicht alles. Die eigentliche Frage ist: Wer entscheidet wofür? Welche Projekte gelten als „kritisch“? Wie verhindert man Capture (ein Großspender bestimmt die Richtung)? Und wie misst man Erfolg, ohne Maintainer in Reporting zu ertränken?

Mein Take

Wenn wir Open Source ernst nehmen, müssen wir es wie Infrastruktur behandeln: mit Budgets, Zuständigkeiten und langen Laufzeiten. Ein Endowment ist dafür ein gutes Werkzeug – solange Transparenz und Entscheidungsregeln nicht nachträglich „irgendwie“ drangeschraubt werden.

Wie könnte das praktisch aussehen?

Ein Endowment muss nicht nach „Stiftung für Philosophieprofessoren“ aussehen. Es kann pragmatisch sein:

  • Wer zahlt ein? Vor allem Unternehmen, deren Produkte auf bestimmten Abhängigkeiten stehen. Nicht aus Wohltätigkeit, sondern aus Risiko-Management. (Wenn ein Tool wie BuildKit oder eine winzige Library im Lieferketten-Stack ausfällt, ist das dein Incident.)
  • Wofür wird bezahlt? Nicht für die glitzernden Features, sondern für die unsexy Arbeit: Issue-Triage, Reviews, Releases, Backports, CI-Pflege, Security-Fixes, Dokumentation.
  • Wie fließt Geld ab? Idealerweise regelmäßig, planbar und mit klaren Kriterien: „kritische Dependencies“ bekommen Grundfinanzierung; kleinere Projekte können über transparente Anträge oder Metriken nachziehen. Der Punkt ist: Maintainer brauchen nicht nur „Geld“, sondern verlässliche Zeit. Ein Endowment kauft Stabilität.

Endowment vs. Sponsoring vs. Grants (kurz & ehrlich)

  • Sponsoring ist super, aber volatil. Es hängt an Stimmung, Budgetzyklen, PR – und kann morgen weg sein.

  • Grants sind oft feature-getrieben. Perfekt, wenn du etwas Neues bauen willst. Schlecht, wenn du drei Monate lang nur Bugs fixst, Tests stabilisierst und Releases schiebst.

  • Endowment-Erträge sind am ehesten das, was Open Source am meisten fehlt: dauerhafte Wartungsfinanzierung.

    Der Governance-Teil ist kein „Nice to have“

    Ein Endowment wird nur dann ein Upgrade, wenn die Regeln stimmen:

  • Transparenz: Wer zahlt wie viel ein, wer bekommt wie viel – und warum?

  • Anti-Capture: Wenn ein Großspender faktisch steuert, ist es keine Infrastruktur-Finanzierung, sondern Vendor-Lobby.

  • Bürokratie-Bremse: Reporting darf nicht zum zweiten Job werden. Wer Maintainer in KPI-Formulare zwingt, produziert Burnout 2.0. Ich fände ein Modell spannend, bei dem Maintainer und unabhängige, technische Stewards gemeinsam entscheiden – mit harten Caps auf Stimmgewicht und klaren Konfliktregeln.

Was Unternehmen diese Woche konkret tun können

  1. Dependency-Inventur: Top-20 Abhängigkeiten identifizieren (nicht nur direkt, auch transitive). 2) Wartung budgetieren: „Open-Source-Maintenance“ als feste Position – wie Monitoring oder Pen-Tests. 3) Langfristig committen: Einmalige Spende fühlt sich gut an, löst aber die Planbarkeit nicht. Mehrjährige Zusage > Überraschungs-Überweisung.

Wenn „Open Source“ für dich geschäftskritisch ist, dann ist ein Endowment nicht Charity. Es ist schlicht: Betriebskosten.

Endowment ist kein Freifahrtschein (und genau darum ist es interessant)

Das größte Missverständnis wäre: „Cool, dann zahlen wir einmal ein – und danach ist das Wartungsproblem gelöst.“ Nein. Ein Endowment ist kein magischer Maintainer-Autopilot. Es ist eher ein finanzieller Stoßdämpfer: Es nimmt die schlimmsten Ausschläge raus (Burnout, Abbrüche, Security-Notfälle), aber es ersetzt keine guten Strukturen.

Wenn du sehen willst, warum das wichtig ist: Schneier verlinkt gerade „AI Found Twelve New Vulnerabilities in OpenSSL“. Ob man die Zahl glaubt oder nicht – der Punkt ist real: kritische Libraries sind dauernd unter Druck. Und Druck heißt nicht nur „es gibt neue Bugs“, sondern auch „jemand muss triagieren, reproduzieren, patchen, backporten, releasen, kommunizieren“. Das ist Arbeit, die nicht glamourös ist, aber die ganze Branche davon abhält, Feuer zu fangen.

Ein Endowment kann genau hier helfen, wenn es wie Infrastruktur gedacht wird:

  • Grundfinanzierung für Wartung, nicht als Belohnung für Features.

  • Incident-Budget („Rapid Response“): Wenn ein CVE einschlägt, muss niemand erst einen Sponsoring-Tweet schreiben.

  • Zeit kaufen, nicht Output: Maintainer sollen nicht pro Patch „bezahlt werden“, sondern die Freiheit haben, das Richtige zu tun (auch wenn es „nur“ Tests, Refactoring und Review-Qualität ist).

    Wie man verhindert, dass es zu Bürokratie-Burnout wird

    Ein Endowment wird schnell toxisch, wenn es sich wie eine Fördermittelhölle anfühlt. Meine Faustregel:

  • Reporting klein halten (max. 1 Seite pro Quartal): Was wurde stabilisiert, welche Risiken wurden reduziert, welche Wartungslasten sind sichtbar geworden?

  • Kriterien offen, Entscheidungen nachvollziehbar: Wenn Projekt A Geld bekommt und Projekt B nicht, muss das begründet sein – öffentlich.

  • Maintainer-Veto bei inhaltlicher Steuerung: Geld darf Wartung ermöglichen, aber nicht die Roadmap kapern. Und ja: Das ist politisch. Aber das ist es jetzt auch – nur eben unsichtbar und chaotisch.

Der eigentliche Gewinn: Planbarkeit für beide Seiten

Für Maintainer heißt Planbarkeit: weniger Existenzstress, weniger Kontextwechsel, mehr Qualität.

Für Unternehmen heißt Planbarkeit: Du kannst Open Source in deine normalen Prozesse ziehen – Budget, Risiko, Audit. Das ist unterschätzt. Viele Firmen würden gern zahlen, scheitern aber an „wir dürfen nur gegen Rechnung“ oder „wir brauchen einen Vertrag“. Ein Endowment kann diese Brücke sein, ohne dass jeder Maintainer plötzlich zum Buchhalter werden muss.

Wenn Open Source dein Stack ist, dann ist ein Endowment kein Feel-Good-Projekt. Es ist die Frage: Willst du Infrastruktur, die im Krisenmodus lebt – oder Infrastruktur, die atmen kann?

Referenzen

  1. Quelle 1: https://endowment.dev/