Wer Open Source nutzt, muss auch beitragen

Ursprünglich 2020 bei publicplan erschienen handelt es sich hier um einen inhaltlich gleichen Artikel, in meiner persönlichen Sichtweise geschrieben.

Open Source wird in der Verwaltung gerne als kostenfreie Software-Bezugsquelle missverstanden. Man lädt sich herunter, was öffentlich verfügbar ist, baut darauf eine Lösung, betreibt sie und ist fertig. Das funktioniert. Es funktioniert aber nur kurz, und es funktioniert nicht für die Probleme, für die man Open Source eigentlich gewählt hat.

Wer Open Source nutzt und nicht beiträgt, ist Konsument einer Community, die jemand anderes trägt. Beim ersten Maintainer-Wechsel, beim ersten Sicherheitsproblem, bei der ersten Anpassung an deutsches Datenschutzrecht ist man auf den Goodwill von Menschen angewiesen, die mit der eigenen Verwaltung nichts zu tun haben. Das ist eine Form von Vendor-Lock-in. Nur ohne Vendor.

Was Open Source eigentlich liefert

Open Source bezeichnet Software, deren Quellcode öffentlich ist und von Dritten kopiert, geändert und genutzt werden kann. So weit, so technisch. Der eigentliche Wert liegt aber nicht im Quellcode-Zugriff, sondern in dem, was um den Code herum existiert. Eine Community, die ihn pflegt. Eine Dokumentation, die ihn erklärt. Ein Issue-Tracker, in dem Probleme verhandelt werden. Reviewer:innen, die neue Funktionen prüfen. Releases, die regelmäßig erscheinen.

Das gilt für Drupal in der CMS-Welt, für Linux im Server-Umfeld, für Kubernetes in der Container-Orchestrierung. Reife Open-Source-Projekte sind keine zufällig öffentlich gewordenen Code-Sammlungen, sondern stabile Liefer-Organisationen mit klar verteilten Rollen. Wer sie nutzt, profitiert von einer Infrastruktur, die er nicht selbst bauen muss. Genau diese Infrastruktur muss er aber tragen helfen, wenn er sie dauerhaft nutzen will.

Beitragen heißt nicht nur Code

In der Vorstellung mancher Verwaltungs-IT-Leitungen ist „beitragen" gleichbedeutend mit „eigene Entwickler:innen schreiben Code für ein Open-Source-Projekt". Das ist eine Form. Es gibt aber viele andere, und die meisten davon erfordern keine Programmierkenntnisse.

Dokumentation, an der die Community immer leidet. Übersetzungen, weil viele internationale Projekte Mehrsprachigkeit nur teilweise abbilden. Testing, also das systematische Probieren neuer Versionen vor einem produktiven Roll-Out. Bug-Reports, die so präzise sind, dass die Maintainer schnell handeln können. Finanzierung über Mitgliedschaften in Trägervereinen oder direkte Spenden. Und sehr wirksam: das öffentliche Bekenntnis, eine bestimmte Open-Source-Komponente produktiv einzusetzen, weil das andere Verwaltungen ermutigt, sie ebenfalls zu nutzen, und damit die Community wachsen lässt.

Wer als Behörde eine dieser Beiträge leistet, ist Teil der Community. Wer keinen davon leistet, ist Trittbrettfahrer.

Was die Lizenz dazu sagt

Lizenz-Modelle wie die GNU General Public License oder die Mozilla Public License regeln, wie weit Beitrags-Pflichten gehen. Die GNU GPL geht weit: Wer GPL-lizenzierte Software modifiziert und weiter verteilt, muss seine Modifikation ebenfalls unter der GPL veröffentlichen. Andere Lizenzen sind großzügiger. Aber selbst die strengsten Open-Source-Lizenzen verpflichten niemanden, der Software intern für die eigene Verwaltung anpasst und einsetzt, dazu, diese Anpassungen zu veröffentlichen.

Das ist die rechtliche Wahrheit. Die strategische Wahrheit ist eine andere. Eine Verwaltung, die Anpassungen für sich behält, hat kurz Vorteile, weil sie nicht zur Veröffentlichung verpflichtet ist. Mittelfristig hat sie Nachteile, weil ihre Eigenentwicklungen mit jeder neuen Upstream-Version in Konflikt geraten. Wer Anpassungen nicht zurückspielt, pflegt einen privaten Fork. Privates Fork-Pflegen ist teuer.

Warum es sich für die Verwaltung lohnt

Es gibt fünf Argumente, die für Verwaltungen besonders zählen. Sicherheit, weil eine Open-Source-Komponente, die viele Augen sehen, schneller geprüft wird als eine, an der eine Behörde alleine bastelt. Geschwindigkeit, weil man als Community-Mitglied früh sieht, was kommt, statt von einem proprietären Hersteller mit Roadmap-Geheimnissen abhängig zu sein. Standardisierung, weil beitragender Code gegen Community-Standards geprüft wird, nicht gegen den eigenen Hausstil, und damit übertragbar bleibt. Wissensaufbau, weil jede:r Mitarbeiter:in, der bei einem Open-Source-Projekt mitarbeitet, etwas lernt, das im eigenen Haus nutzbar bleibt, auch wenn die Person das Haus später verlässt. Und Reputation, weil eine Verwaltung, die in der Open-Source-Community sichtbar beiträgt, es bei Ausschreibungen leichter hat, qualifizierte Anbieter zu finden.

Was Verwaltungen konkret tun können

Drei Schritte sind realistisch und kein Hexenwerk. Eine Bestandsaufnahme: Welche Open-Source-Komponenten setze ich produktiv ein, von welcher Community werden sie gepflegt, was hat sich an dieser Community in den letzten Jahren verändert? Eine Beitrags-Strategie: An welchen Stellen kann meine Verwaltung etwas zurückgeben, ohne sich zu überfordern? Und ein Beschaffungs-Hebel: In Verträgen mit Open-Source-Dienstleistern festschreiben, dass Anpassungen, die im Auftrag gebaut werden, an die Upstream-Community zurückgehen.

Open Source funktioniert, weil viele Beitragende ein Stück Verantwortung übernehmen. Wer als Verwaltung Open-Source-Software nutzt und nicht beiträgt, schwächt die Substanz, von der sie selbst lebt. Das ist nicht moralisch verwerflich, das ist strategisch unklug. Wer beiträgt, bekommt mehr zurück, als er gibt. Das ist kein Slogan, das ist die Lieferlogik.

Hat Sie das Thema interessiert?

Dann schreiben Sie mir gerne eine kurze Nachricht.