Sick of "many dependencies" framing

Posted Feb 11, 2026 10:43 UTC (Wed) by farnz (subscriber, #17727)
In reply to: Sick of "many dependencies" framing by mjg59
Parent article: FOSS in times of war, scarcity, and AI

The challenge is that maintainer count and dependency count are not correlated; large dependencies often have many maintainers, while it's possible for one person to maintain many small dependencies to a high standard.

Using dependency count as a proxy for something you really care about (like "how many maintainers am I trusting") increases the risk that you will consider yourself "safe" (because you're trusting a small number of dependencies) while actually being at risk (because one of those dependencies has a large number of trusted maintainers, and in the worst case, has a large number of transitively trusted maintainers hidden behind a small number of known maintainers - where you can't actually see directly that someone maintaining the printer support in GTK4 is not on the list of people you've identified as the "GTK Development Team").

Dependency count works within a single build ecosystem as a proxy, because everyone using (say) Bazel, or Cargo, or CMake, faces the same challenges integrating one more dependency - so a CMake project with 15 dependencies probably trusts more people than a CMake project with 10 dependencies. But once you start comparing across build ecosystems, you run into the issue that some ecosystems have a single maintainer comfortably maintaining 15 dependencies in usable form (split up so that you only pull in code you care about), while other ecosystems push maintainers to group together, so that each dependency represents multiple trusted maintainers.

to post comments

Sick of "many dependencies" framing

Posted Feb 11, 2026 11:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (2 responses)

Dependency counts work because they reduce the relationship graph to something a human can understand and act on.

Software is a human creation where human relationships matter, infinite delegation chains do not work for humans and are ripe for abuse, that’s why no one is surprised when a non-software project goes overboard and the inquest shows deep levels of subcontracting, that’s why the automotive industry co-locates its suppliers as close to its own factories as possible (sometimes the next side of the road with a bridge over the road to reduce the effective distance further).

Delegation abuse breads lack of accountability. Software may be special but the humans writing software are not.

Sick of "many dependencies" framing

Posted Feb 11, 2026 12:17 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

Dependency counts reduce the relationship graph by hiding significant portions of it behind invisible delegation chains, with the very problems you cite with deep levels of subcontracting.

In the extreme case, you replace 200 visible maintainers (maintaining 500 visible dependencies - one person maintaining several related dependencies, but splitting them up for your benefit in choosing which bits of their code you use), with 5 visible maintainers maintaining 5 visible dependencies, and a total trust set on the order of 20,000 people, of whom only 200 are actively working on the parts of your dependencies that you use (but where any of them could introduce malicious code and break your trust in that dependency).

And that's why I consider dependency count a bad metric - by saying "I want a small dependency count, with a small number of top-level maintainers", you don't reduce the amount of code you depend upon, but you do incentivise those top-level maintainers to abuse delegation so that they can offer you a single large dependency that does everything you want, rather than offering 10 smaller dependencies, of which 2 are helpful, and requiring you to pick up the other 90 functions they could put in their dependency via delegation abuse from other places.

Sick of "many dependencies" framing

Posted Feb 11, 2026 13:18 UTC (Wed) by Wol (subscriber, #4433) [Link]

And this is also an argument against dynamic linking. If I dynamic-link a library, ALL that code is available to an attacker, and needs to be vetted.

Okay, it's not true of all static linking, but the linker I used many moons ago, you would link the library, and it would search the library for modules that the (partially) linked program needed, and pull in JUST those modules. It had the downside that you might need to link the same library two or three times, if the modules you pulled in linked to further modules in the same library, but it had the upside that if you only wanted a couple of modules from the library, you only GOT a couple of modules.

And by seeing which modules were linked, you knew which modules to vet and which ones to ignore.

That's the other problem with "thousands of LOC" dependencies - do you even depend on them? Would you be better off without them? Does your project even call them?

Cheers,
Wol