Newsletter

    Newsletter abonnieren

    Neue Infrastruktur-Guides, Vergleichsberichte und Migrationshinweise direkt ins Postfach.

    Infrastruktur-Notizen, Guides und neue Tools. Jederzeit abbestellbar.

    Zurück zum Blog
    Open Source
    Kubernetes
    CNCF
    Maintainer
    Community

    Maintainer, Märtyrer und Mythen: Ein Blick in die Arbeitsökonomie von Kubernetes

    28. Mai 2025
    9 Min. Lesezeit

    Im Kern der modernen Infrastruktur sitzt ein seltsamer Widerspruch: Ein Großteil der wichtigsten Software, die das Internet am Laufen hält, steht nicht hinter Milliarden-Budgets, sondern hinter Slack-Threads, ehrenamtlicher Zeit und Code, der nach Feierabend geschrieben wird.

    Nehmen Sie Kubernetes. Oder „k8s", wie es die Devs, die es bändigen, liebevoll nennen. Es ist das Rückgrat cloud-nativer Deployments – der Orchestrator für Container, das Betriebssystem für moderne Apps, der Grund, warum Ihre liebste Streaming-Seite nicht bei jedem neuen Serienstart abstürzt. Und doch schlürfen die Menschen, die es bauen und pflegen, nicht alle Lattes auf dem Google-Campus.

    Ja, Kubernetes wurde bei Google geboren. Die Logos großer Player wie Amazon, Microsoft und IBM prangen auf seinen Konferenzbühnen. Doch wer unter die Haube schaut, findet eine andere Geschichte – eine, in der die Arbeit verteilt, ungleich und in vielen Fällen unbezahlt ist.

    Nicht alle Contributor werden bezahlt

    Ein Lead für Contributor Experience bei Kubernetes schaltete sich in die Diskussion ein, um Klarheit zu schaffen: Es ist eine Mischung. Manche Contributor arbeiten Vollzeit. Andere werden teilweise gesponsert. Und nicht wenige? Die machen es einfach, weil es ihnen wichtig ist – Studierende, Hobbyisten, Rentner, Freelancer. Menschen, die ihre Abende damit verbringen, Issues zu triagieren oder Dokumentation zu schreiben, ganz ohne finanzielle Gegenleistung.

    Und das sind keine Nebenaufgaben mit wenig Wirkung. Es geht um handfeste Verantwortung: Release-Leads, Community-Management, Roadmap-Planung. Ein Student leitete einen kompletten Release-Zyklus. Ein anderer Contributor, mittlerweile wieder im Studium, co-leitet noch immer eine wichtige Working Group – unbezahlt. Es gibt sogar einen Contractor, der Führungsaufgaben übernommen hat, ohne dafür einen Vertrag vorweisen zu können.

    Das ist eine Menge Verantwortung für null Dollar. Aber mehr noch: Es ist Risiko.

    Der Mythos vom wohlwollenden Konzern-Mäzen

    Es kursiert eine gemütliche Erzählung, wonach Open Source großzügig von Big Tech finanziert wird. Ganz falsch ist das nicht – nur unvollständig.

    Klar, manche Firmen finanzieren Projekte oder lassen ihre Engineers auf Firmenzeit beitragen. Aber dieses Geld fließt selten tief. Ein Contributor brachte es unverblümt auf den Punkt: „Die 'gewaltigen Geldsummen' gehen an die CNCF. Die Projekt-Devs sehen davon nichts." Ein anderer ergänzte: „Ich arbeite an ein paar CNCF-Projekten. Wir bekommen null von Big Tech."

    Kurz gesagt: Es gibt institutionelle Finanzierung – aber kaum persönliche. Die Marke Kubernetes wird vielleicht unterstützt, aber die Menschen, die sie vorantreiben? Oft nicht.

    Manche Devs nehmen sich Urlaubstage, nur um ihren Backlog aufzuarbeiten. Andere bezahlen Konferenzreisen aus eigener Tasche, außer sie halten einen Talk, den ihre Firma als PR-tauglich einstuft. Das ist Liebe zur Community. Das ist Durchhaltevermögen. Aber es ist auch … irgendwie kaputt?

    Das Pyramidensystem der Abhängigkeiten

    Zoomt man heraus, wird es noch beunruhigender.

    Der Open-Source-Stack ist auf Schicht um Schicht anderer Open-Source-Software aufgebaut – das meiste davon unsichtbar. Denken Sie an libxml2, libattr, zlib, curl. Diese fundamentalen Pakete bekommen fast keine Finanzierung. Ihre Maintainer halten keine Keynotes und posten keine Launch-Rückblicke auf LinkedIn. Trotzdem wird ihr Code millionenfach pro Sekunde von der Internet-Infrastruktur aufgerufen.

    Und anders als Kubernetes sind diese Projekte nicht „hip". Sie haben keine übergeordnete Foundation und keine schicken Logos. Aber wenn sie kaputtgehen – geht alles kaputt.

    Ein Kommentator brachte es mit brutaler Klarheit auf den Punkt: „Mindestens 50 % der Abhängigkeiten eines Enterprise-Produkts sind Bibliotheken, die von unbezahlten Freiwilligen gepflegt werden."

    Wenn Burnout zur Bedrohung für die Stabilität wird

    Was passiert, wenn diese Freiwilligen ausbrennen?

    Fragen Sie den ehemaligen PyPI-Maintainer, der sich selbst als „total im Arsch" beschrieb, bevor die Python Software Foundation endlich einsprang, um Unterstützung zu finanzieren. Bis dahin wurde die globale Paket-Registry – auf die sich Millionen Python-Entwickler verlassen – allein durch persönlichen Willen zusammengehalten.

    Das ist keine Einzelgeschichte. Die Open-Source-Welt ist übersät mit Geschichten von Maintainern, die hinwerfen, Projekten, die vor sich hin dümpeln, und Konzernen, die mit den Schultern zucken. „Nur Software, die die jeweilige Firma auch wirklich schreiben will", merkte ein Entwickler an. „Sobald das Interesse verloren geht, bleibt es einfach liegen."

    Die Arbeit ist nicht nur unbezahlt. Sie ist unsichtbar, fragil und wird viel zu oft als selbstverständlich hingenommen.

    Warum machen die Leute das trotzdem?

    Es ist leicht, das als trostlose Landschaft zu zeichnen. Aber es ist nicht nur Untergangsstimmung.

    Manche Contributor zieht es wegen der Community dorthin. Andere wegen des Lerneffekts, des Lebenslauf-Boosts, oder einfach wegen des Nervenkitzels, etwas zu bauen, das wirklich zählt. Und es gibt seltene, herzerwärmende Geschichten – wie den Entwickler, der sein Vermögen aus einem Vergleich in einem Code-Rechtsstreit nutzte, um Open-Source-Contributor auf seiner Farm in Oregon unterzubringen und zu finanzieren.

    Aber diese Geschichten sind Ausreißer, keine Struktur. Leidenschaft sollte nicht der Patch für systematische Unterfinanzierung sein.

    Wer trägt also die Verantwortung?

    Das ist die Millionenfrage – im wahrsten Sinne des Wortes sogar die Milliardenfrage. Wenn Kubernetes für die Unternehmen, die es nutzen, Milliarden wert ist, sollten sie dann nicht in die Menschen dahinter investieren, nicht nur in die Logos?

    Im Moment verlassen wir uns auf eine seltsame moralische Ökonomie: eine Mischung aus professionellem Stolz, Ehrenamt und dem merkwürdigen Gefühl von „wenn ich es nicht mache, wer dann?" Das funktioniert – bis es nicht mehr funktioniert.

    Und wenn es zusammenbricht, bleiben die Folgen nicht auf einen GitHub-Issue-Thread beschränkt. Sie treffen echte Unternehmen, echte Nutzer und die Infrastruktur, auf die wir uns alle verlassen.

    Zeit, den Deal neu zu verhandeln

    Die Open-Source-Welt braucht keine Wohltätigkeit. Sie braucht Nachhaltigkeit. Das könnte so aussehen:

    Direkte Finanzierungsmodelle für Maintainer (nicht nur für Foundations).

    Unternehmen, die einen echten Anteil der Engineering-Zeit für Upstream-Arbeit bereitstellen.

    Transparente, faire Vergütung für Führungsrollen.

    Die Erkenntnis, dass „kostenlose" Software in der Pflege nicht kostenlos ist.

    Ein Kommentator brachte es so auf den Punkt: „Niemand zwingt Open-Source-Contributor dazu, umsonst zu arbeiten." Das stimmt rein technisch.

    Aber sie werden gezwungen, unter Bedingungen zu arbeiten, in denen ihre Leistung unterbewertet, ihre Zeit unbezahlt und ihr Burnout einkalkuliert ist. Das ist kein Open Source mehr – das ist Ausbeutung im Gewand der Innovation.

    Wenn Kubernetes – oder irgendeine andere kritische Software – im nächsten Jahrzehnt gedeihen soll, muss es aufhören, von den letzten Dämpfen des Märtyrertums zu leben. Der Mythos vom einsamen Coder, der im Alleingang alles rettet, muss sterben. An seine Stelle brauchen wir ein Arbeitsmodell, das Maintainer als das behandelt, was sie sind: das Rückgrat – nicht ein nachträglicher Gedanke.

    Denn die Zukunft der Infrastruktur hängt nicht nur davon ab, wer den Code schreibt, sondern davon, ob sie es sich leisten können, damit weiterzumachen.