NIH is cheaper than the wrong dependency

Paid Dependencies, Vendor Lock‑In, and Longevity

• Several comments argue paid dependencies are often risky: incentives for lock‑in, single support source, and danger when the vendor folds or is acquired.
• Counterpoint: paying can be good if it guarantees people whose job is to maintain and support the code; open source can also abandon users.
• Many recommend only paying for components that implement open standards with alternative implementations, to preserve an escape route.

Dependency Minimalism, Vendoring, and NIH

• Strong support for “dependency minimalism”: fewer moving parts, less that can break, easier long‑term maintenance.
• Common heuristic: “Can I vendor it?” If yes, it may be better to copy small libraries into your tree and own them. Vendoring is framed as accepting maintenance responsibility, not just snapshotting.
• Forking or vendoring dependencies (and even their transitive deps) is suggested to avoid disappearing repos and to understand build chains.
• Others argue a strict “zero dependencies” stance is overreaction: most small, well‑scoped libraries are harmless and save time.

Evaluating Dependencies: Risk, Scope, and Lock‑In

• Suggested process: only use OSS, review license, ubiquity, community health, security history, and ease of replacement.
• Only adopt dependencies you’d be willing and able to maintain or fork. Some advocate preemptive forking; others say that’s too heavy and prefer vendoring or caching.
• Ubiquity and scale are seen by some as a safety signal; others report severe bugs and slow responses even in big‑company libraries.

Where NIH Makes Sense (and Where It Doesn’t)

• NIH is seen as appropriate when:
  • You need only a narrow subset of functionality, can implement it in ≤ a day, and want tight control.
  • The domain is core to your business (e.g., a custom ledger, highly tuned storage, niche graph DB, embedded time‑series engine).
• Generally discouraged for: databases, cryptography, OSes, or large game engines—unless you truly have unique constraints and deep expertise.

AI and NIH

• Some teams use LLMs to generate internal tools or codegen utilities instead of adding runtime dependencies.
• Concerns: AI‑generated clones of libraries may inherit old CVEs, introduce subtle bugs, and lack automated vulnerability tracking.

Organizational and Human Factors

• Dependencies can reduce time‑to‑market, which often dominates business decisions.
• Long‑lived or safety‑critical systems (energy, finance, compliance) tend to avoid sprawling dependency trees due to security, audit, and maintenance costs.
• Multiple commenters stress that hidden long‑term costs of upgrades, security fixes, and lock‑in are routinely underestimated.