Reuse Less Software

An essay by icefox (Simon Heath) on the alopex wiki, June 2026. The thesis: cheap software distribution plus automated dependency fetching flipped the 1970s software crisis into its opposite. We used to struggle to reuse enough; now we reuse too much, and the fix for exploding supply-chain risk is to vendor every dependency so automatic propagation stops. (The author calls the title clickbait up front.)

How we got here

The 1960s-70s "software crisis" was exponential demand for software against a sub-linear ability to build and reuse it. That drove research into modularity and structured programming — every language module system since 1990 traces back to Modula-2. Then the 1990s-2000s made distribution cheap: open source plus volunteer bandwidth produced package repositories and managers (CPAN, CTAN, Linux distros) that fetch and build software from nothing but a name and a version number. Building SDL by hand in 2003 sucked; the author is explicit that nobody should pine for those days.

Modern Rust, Go, and Docker software barely touches system libraries — build systems fetch dependencies directly. That solved the old crisis and created the new one: dependency hell, bloat, long builds, and maintainers vanishing into the ether. Using software still has costs even when distributing it is free.

The supply-chain problem

Supply-chain attacks aren't new. The essay cites the classic attempted malicious Linux kernel patch — uid = 0 instead of uid == 0 — as an early example. What changed is automation: CI runs on every change, and a compromised dependency "spreads like wildfire, as fast as CI runners can execute it." The auto-fetch that made reuse cheap is also the propagation channel for the attack.

The proposal

Stop auto-pulling dependencies at build time. Vendor everything — copy upstream source into your git repo and commit it; when upstream updates, copy it again; automate the copy in the build tool; make the lockfile correspond to a committed full source tree. "Vendor the shit out of your project... Own every line of source code with the iron fist of an absolute control freak."

This turns every package into a fire-break against supply-chain attacks. It's also a fire-break against bug-fix propagation, which the author accepts: if a fix matters you'll look for it, and if you aren't looking, it usually doesn't matter. The dependency-vendoring page covers the mechanics and tradeoffs in more depth.

Objections and side effects

The essay rebuts the obvious objections. Git bloat — disk is cheap. Build times — you were rebuilding that code anyway. Harder reuse — mostly affects client/server pairs sharing a protocol lib, which already have version-mismatch problems to handle. A useful side effect: vendoring raises the visibility and cost of dependencies, so a "200-line lib" that's actually 50,000 lines becomes obvious, nudging toward flatter, wider trees. The author hopes to cut typical dependency counts "from 200-300" to "at most 2-3." The real downside is no automatic transitive deduplication. The logical endpoint is Nix/Guix, which the author endorses.

See also

• dependency-vendoring — the mechanics, visibility effect, and Nix/Guix endpoint
• supply-chain-security — the attack class, and dependency cooldowns as the softer version
• abi-stability — a related reason self-contained artifacts win: not trusting the surrounding system
• open-source-security-astral — cooldowns and Trusted Publishing as alternative mitigations
• tanstack-npm-supply-chain-postmortem — a concrete auto-propagation attack of the kind vendoring blocks
• anubis-wasm-vendor-binary — vendoring a binary in practice, and the reproducibility it demands