Du könntest ja mal eine Umfrage erstellen um herauszufinden, wie viele externe Bibliotheken von anderen Herstellern in den Projekten verwendet werden. Das sieht je nach Branche sicher anders aus, bei mir liegt das zwischen 0 und 1. Es gibt auch nur wenige Hersteller die so etwas mitliefern, und wenn dann passt es meistens nicht für das aktuelle Projekt oder in die eigene Struktur.
Auch hier haben wir wieder ein klassisches "Henne-Ei-Problem".
Wenn kein vernünftiger Package-Manager eingesetzt wird, dann hat das folgende schädliche Effekte:
- Externe Hersteller veröffentlichen keine oder nur weniger Pakete, weil der Aufwand für Wartung und Updates zu groß ist.
- Initiativen von einzelnen Entwicklern werden abgewürgt, weil der Aufwand für die Verteilung des Codes zu groß ist.
- Bugfixes werden nur verzögert oder spärlich ausgeliefert, weil der Aufwand für Updates zu groß ist.
- Codesharing innerhalb von Unternehmen wird nur in Form von "Copy and forget" betrieben, weil das Publishen von internen Paketen zu aufwendig ist.
Package-Manager sind daher keine revolutionäre Technologie für sich alleine, sondern nur eine "Enabler-Technologie" für gesteigerte Innovation und Effizienz.
Das Problem "Paket passt nicht in die eigene Struktur" ist genau diese Art von Engineering-Problem, welches nur durch offene Standards für eine ganze Industrie gelöst werden kann.
Zugegeben war die IT auch jahrzehntelang von diesen Problemen geplagt, und auch in der IT hat es viele Bremsen gegeben.
Trotzdem haben sich dann einzelne Unternehmen wie GitHub und npm durchgesetzt und die Welt nachhaltig verändert, und zwar zum besseren verändert (es sei denn, das Ziel ist es, möglichst viele Jobs zu behalten die nur bereits gelöste Software-Probleme wieder und wieder neu lösen).
Allein das Feststellen eines schwerwiegenden Fehlers sollte aber keinen Update auslösen - oder geht es nur darum. unverzüglich Betriebsamkeit zu dokumentieren?
