Es gibt keine „Softwarelieferkette“

In den heutigen Lieferketten wechselt Geld den Besitzer. Ein Serverhersteller zahlt für die Leiterplattenherstellung, der seine Lieferanten für Rohmaterialien und Ausrüstung bezahlt, und so weiter, bis sich alles von selbst erledigt, wenn ein Bergbauunternehmen einen Server kaufen muss.

Wenn Sie in einem Softwareprojekt eine zusätzliche Abhängigkeit übernehmen, wechselt das Geld oft nicht den Besitzer. npm install und cargo add belasten Ihre Kreditkarte nicht. Es gibt keine formelle Vereinbarung zwischen einem Betreuer und seinen nachgeschalteten Benutzern.

Der Sicherung von "Software-Lieferketten" wird viel Aufmerksamkeit geschenkt. Der übliche Ansatz besteht darin, zu verhindern, dass Sicherheitsprobleme in Ihren zugrunde liegenden Komponenten Kunden Ihres Produkts beeinträchtigen. Und wenn dies der Fall ist, möchten Sie in der Lage sein, schnell zu reagieren, um das Problem zu beheben. Leute, die sich um diese Klasse von Problemen kümmern, sind oft Softwareanbieter. Die Klasse von Komponenten, um die sich diese Unternehmen am meisten Sorgen machen, ist, wo unbezahlte Hobby-Instandhalter ohne Wartungsplan etwas für sich selbst geschrieben haben.

Hier fällt die Lieferketten-Metapher - und das ist nur eine Metapher - auseinander. Wenn ein Mikrochip-Anbieter eine Vereinbarung eingeht und diese nicht einhält, haben die Kunden des Anbieters Rückgriff. Wenn ein Open-Source-Betreuer ein Projekt aus irgendeinem Grund nicht betreut, ist das nicht die Schuld des Betreuers, und die Unternehmen, die sich auf seine Arbeit verlassen haben, sind diejenigen, die ihre Probleme in Zukunft beheben werden. Die Verwendung des Begriffs „Lieferkette“ entmenschlicht hier die Arbeit, die mit der Entwicklung und Wartung von Software als Hobby verbunden ist.

Alles, was über das Sponsoring und die Bezahlung von Führungskräften gesagt werden kann, wurde bereits gesagt. Wichtige Arbeiten werden noch immer nicht gefördert. Einige von uns, einschließlich mir, kümmern sich nicht besonders darum, dass wir mit unseren Wochenend-Hacks kein Geld verdienen. Das Problem ist, wenn das bloße Freigeben von Software zu einer Belastung wird.

Sie können Pull-Anforderungen in einem GitHub-Repository immer noch nicht deaktivieren. Ein Paketrepository kann Ihre Software als „kritisch“ einstufen und Anforderungen an die Veröffentlichung von Updates hinzufügen, die Sie möglicherweise nicht erfüllen möchten oder können. Google wollte sogar verhindern, dass anonyme Personen kritische Software verwalten, und wollte die Identität anderer kontrollieren.1

Oder vielleicht teilt ein Betreuer jemandem mit, dass er ein Projekt nicht mehr betreuen wird, und GitHub benachrichtigt Tausende von abhängigen Repositories und nennt es eine „kritische Schweregrad“-Benachrichtigung.2 Das war offensichtlich ein Fehler, und GitHub hat sich zurückgezogen und erneut hat heute Morgen den Schweregrad als niedrig eingestuft, aber das ist bei weitem nicht das einzige Mal, dass Systeme, die zur Sicherung der "Software-Lieferkette" entwickelt wurden, die Nuancen der Wartung von Open-Source-Software nicht verstanden haben.

Ich möchte nur Software veröffentlichen, die ich cool finde, damit andere Bastler sie verwenden und daraus lernen können, ansonsten möchte ich in Ruhe gelassen werden. Ich sollte entscheiden dürfen, ob etwas, das ich geschrieben habe, "fertig" ist. Der Fokus auf die Sicherung der „Software Supply Chain“ hat es noch wahrscheinlicher gemacht, dass die Freigabe von Software für andere nur mehr Arbeit für mich bedeutet, von der ich nicht profitiere. Ich lehne die Idee ab, dass ein so dürftiges Konzept überhaupt gesichert werden kann.