- In jüngsten Berichten wurde Kritik an der Nutzung von von einem russischen Entwickler erstellter Open-Source-Software geäußert
- Tatsächlich wird die große Mehrheit fast aller Open-Source-Projekte von nur einer einzelnen Person als Maintainer betrieben
- Nicht nur bei NPM, sondern in vielen verschiedenen Ökosystemen gibt es sehr viele Fälle, in denen ein einzelner Maintainer populäre Pakete verwaltet
- Das Problem dieser Struktur sind die übermäßige Belastung einer einzelnen Person und das Supply-Chain-Risiko
- Der Kern des Problems ist nicht die Nationalität, sondern der real bestehende Mangel an Ressourcen und Unterstützung
Einleitung: Open Source und die jüngste Kontroverse
- The Register veröffentlichte einen Artikel, der die Abhängigkeit des US-Verteidigungsministeriums von einem von einem russischen Entwickler erstellten Open-Source-Utility problematisierte
- Der betreffende Open-Source-Entwickler wird dabei zu Unrecht an den Pranger gestellt
- Der Artikel missversteht die Realität von Open Source, und hier werden die Grenzen eines solchen Ansatzes aufgezeigt
Die Realität von Open Source: die Struktur der „einen Person“
- Daten zufolge werden fast alle Open-Source-Projekte von einer Person gepflegt
- Das Projekt ecosyste.ms erfasst Daten zu rund 11,8 Millionen Open-Source-Projekten
- Davon haben etwa 7 Millionen einen einzelnen Maintainer
- Bei den übrigen rund 4 Millionen Projekten ist die Zahl der Maintainer unbekannt, aber bei vielen dürfte es ebenfalls nur eine Person sein
- Nur eine verschwindend kleine Zahl von Projekten hat Hunderte von Maintainer:innen
Auch populäre Projekte sind keine Ausnahme
- Viele Menschen denken, „wichtige Open-Source- oder populäre Projekte werden sicher von mehreren Personen betreut“, aber in Wirklichkeit sieht es auch in zentralen Ökosystemen wie NPM nicht anders aus
- Im NPM-Ökosystem gibt es mehr als 4 Millionen Projekte mit nur einem Maintainer
- Selbst unter NPM-Paketen mit mehr als 1 Million Downloads pro Monat wird etwa die Hälfte von nur einem Maintainer betrieben
- Hebt man die Download-Zahl auf 1 Milliarde an, gibt es zwar gewisse Unterschiede, aber noch immer existieren Pakete mit nur einem Maintainer
- Die tatsächliche Zahl der Personen, die diese 4 Millionen Single-Maintainer-Projekte bei NPM betreiben, liegt bei rund 900.000 (das heißt, eine Person trägt oft die Verantwortung für mehrere Projekte)
Der Kern des Problems: nicht Staaten, sondern Ressourcenmangel
- Die wirtschaftliche Größenordnung von Open Source ist ein Fundament im Wert von mehreren Billionen Dollar (laut Harvard-Studie 8,8 Billionen Dollar)
- Den meisten Projekten mit nur einem Maintainer fehlen Ressourcen, und es bestehen Supply-Chain-Risiken
- Das größte Risiko ist nicht ein Staat, sondern „die eine Person als Maintainer“, die überlastet ist und nicht angemessen entlohnt wird
- Wenn Medien oder andere Akteure einzelne Maintainer ins Visier nehmen, ist das keine Lösung
Fazit und Ansatzpunkte zum Handeln
- Die Ursache des aktuellen Problems liegt in der Struktur des einzelnen Maintainers; der Fokus auf Staaten ist sinnlos
- Einzelne Maintainer zu dämonisieren oder aufzuspüren, ist keine Lösung
- Das Problem ist komplex, und es gibt derzeit keine sofortige Lösung
- Statt einzelne Maintainer herauszugreifen und zu kritisieren, sollte über strukturelle Probleme und Unterstützungsansätze nachgedacht werden
1 Kommentare
Hacker-News-Kommentar
Ich habe das Gefühl, dass es in der Software-Community viele Missverständnisse zu diesem Thema gibt; in Wirklichkeit ist Supply-Chain-Risiko eher ein Governance-Problem als ein Software- oder Engineering-Problem.
Auch ohne böse Absicht kann in einem Projekt ein Supply-Chain-Risiko entstehen, und je nachdem, wer es bewertet, unterscheiden sich Sicherheitsblickwinkel und Kriterien.
Das DoD (US-Verteidigungsministerium) betrachtet Risiken aus einer völlig anderen Perspektive als normale Entwickler, und viele Ein-Personen-Projekte gelten allein deshalb als Risiko, weil nur eine Person dafür zuständig ist.
Wenn der „Bus-Faktor“ 1 ist, ist das an sich schon ein Supply-Chain-Risiko.
Die meisten Menschen denken bei der Auswahl eines Pakets nicht an Kriegssituationen, aber das Militär kann genau das im Blick haben.
Wenn ein Krieg ausbricht, kann sich die Lage auch bei Open-Source-Projekten, die normalerweise autonom gepflegt werden, schlagartig ändern.
Tatsächlich verlangen viele Länder im Kriegsfall per Gesetz die Mitwirkung privater Unternehmen oder persönlicher Projekte; es gibt also Stellen (wie das DoD), die selbst so etwas in ihre Sicherheitsrisikobewertung einbeziehen.
Im Kriegsfall würde man sicher nicht nach dem Motto arbeiten: „Hätten wir doch wenigstens noch irgendeiner anderen Person vertraut, der wir überhaupt nicht vertrauen.“
Es gab Daten, wonach es bei NPM 4 Millionen Ein-Personen-Projekte gibt und etwa 900.000 Menschen, die diese Projekte pflegen; ich habe mich gefragt, ob das wirklich der entscheidende Punkt war.
Den größten Teil des wirtschaftlichen Werts von Open Source (Harvard schätzt ihn auf 8,8 Billionen Dollar) erzeugen also „Ein-Personen-Projekte“, und keiner von ihnen erhält dafür angemessene Ressourcen.
Das wirklich Gefährliche in der Supply-Chain-Risiko-Debatte sind schlecht bezahlte, überarbeitete Einzel-Maintainer.
Aus welchem Land diese Person kommt, halte ich dabei ehrlich gesagt für weit weniger wichtig.
Ich frage mich, ob es Statistiken dazu gibt, was passiert, wenn ein Einzel-Maintainer plötzlich einen Unfall hat oder ein Projekt aufgibt.
Bei so vielen Daten wäre das ein lohnendes Forschungsfeld.
Ich würde gern wissen, ob neue Entwickler ein Projekt übernehmen, ob es durch ein ähnliches anderes Projekt ersetzt wird oder ob es vollständig verschwindet.
In der Praxis kommt es häufiger vor, dass „der Maintainer das Interesse verliert oder keine Zeit mehr hat“, als dass er tatsächlich vom Bus überfahren wird.
Häufige Szenarien sind dann:
Die Stärke von Open Source ist, dass selbst dann, wenn der Urheber verschwindet, seltsam wird oder die Lizenz ändert, irgendjemand das Projekt forken und bewahren kann.
Bei proprietärer Software dagegen ist es einfach vorbei, wenn der Hersteller — ob Firma oder Einzelperson — verschwindet oder die Inhalte ändert.
Dann bleibt höchstens, nach einem Ersatzprodukt zu suchen.
Das ist übrigens auch der Grund, warum ich Netflix nicht leite.
Letztlich hängt es von der Zahl der Nutzer, der Komplexität der Codebasis und der Verfügbarkeit von Alternativen ab.
Das ist eine deutlich eigenartigere Geschichte, als einfach nur „vom Bus überfahren“ zu werden, und am Ende ist das Projekt verschwunden.
Selbst bei Projekten mit mehr als zwei Maintainern wird die große Mehrheit der tatsächlichen Commits am Ende meist von einer einzigen Person gemacht.
Relevanter Link: https://github.com/11ty/eleventy/graphs/contributors
Schade, dass nicht einmal die Aktivität geprüft wurde; dann hätte man sofort gesehen, dass bei der Hälfte aller Projekte die Zahl der Maintainer bei null liegt.
Das heißt, man kann sie einfach so lassen, ohne Aufräumen, Tuning oder Nachjustierung.
Eher sind Updates das Problem, nicht unbedingt das Projekt selbst.
Beunruhigender finde ich die Tatsache, dass das DoD Node verwendet.
Ich habe das ungute Gefühl, dass eine Plattform wie npm eine viel zu große Angriffsfläche bietet.
Das DoD ist eine der größten Organisationen der Welt und hat auch Aufgaben wie Newsletter-Versand oder Webseiten für die Buchung von Führungen in Pfadfinderlagern.
Dafür kann man meiner Meinung nach ruhig Node einsetzen.
Solche Systeme laufen getrennt von kritischen Systemen wie Raketenstarts, und wenn eine einfache Veranstaltungsanmeldeseite kompromittiert wird, ist das kein großes Problem.
Ich denke, viele Ein-Personen-Projekte auf GitHub sind in Wirklichkeit nur persönliche Experimente oder Spielereien wie „hello world“.
Ich weiß nicht, wie es bei npm aussieht, aber auf PyPI gibt es davon ebenfalls mehr als genug.
Ich habe selbst einmal auf „browse projects“ geklickt und bekam so etwas: https://pypi.org/project/helloworld-eduardo/
Niemand wäre, egal wie betrunken, auf die Idee gekommen, so etwas in einem Produkt einzusetzen.
Das DoD ist sehr geschickt darin, etwas kostenlos zu bekommen, alle davon zu überzeugen, dass „davon am Ende alle profitieren“, und es dann doch an bezahlte Auftragnehmer auszulagern.
Es hieß, es gebe „Pakete mit einem einzelnen Maintainer und mehr als einer Milliarde Downloads“; ich frage mich, was genau das aussagen soll.
Ich habe viel Gutes über die Arbeit eines Mannes namens Linus gehört und sie wohl auch oft genutzt.
Er stammt aus einem Land mit Grenze zu Russland, und da fragt man sich schon, ob man auf so etwas ebenfalls achten sollte.
Ich entwickle seit Jahrzehnten Open Source und habe dabei fast immer allein gearbeitet oder gelegentlich ein Freiwilligenteam aufgebaut.
Wer schon einmal mit einem Freiwilligenteam gearbeitet hat, weiß: Das ist wirklich nicht einfach.
Natürlich ist es nicht völlig unmöglich, aber es funktioniert bei Weitem nicht so oft gut, wie man vielleicht denkt.
Wenn es gut lief, dann meist entweder mit einem „BDFL (wohlwollenden Diktator)“ oder weil alle auf ein gemeinsames Ziel hinarbeiteten.
Bei mir war es fast immer Letzteres.
Sein Vater hat außerdem einige Jahre in Moskau verbracht.