Use open source liberally to make progress.

Avoid open source dependencies in the long run if you can.

How to Reduce Dependencies Later

Start a project by ingesting open source libraries to make progress fast and see if your product works. That’s fine. If it’s not too much, you can leave them in.

But when the product matures, and if you offer a library yourself, you may benefit from reducing dependencies to ease product maintenance. Pick what you really need:

• Copy/cherry-pick as few files as possible from other projects. Do you need the whole swift-algorithms package and its future updates, or just the one OrderedSet.swift file?
• Inline the code you need, or write it yourself. That’s not always possible (good luck inlining React.js, or the whole TCA package).

Case Study: Rust sudo Replacement Project

The programmers behind sudo-rs, the Rust rewrite of the sudo/su commands, started their development process with a couple of libraries (“crates” in Rust) to make progress fast.

Ruben Nijveld: “Sudo-rs dependencies: when less is better” (2024-03-07)

During development we accrued approximately 135 transitive (direct and indirect) dependencies. Once this was identified, we managed to reduce our total dependencies down to three.

To make the code understandable, more self-contained, and harden it against trust issues with all these other Rust crates, they inlined as much as possible wherever it made sense, e.g. replacing a dependency on clap to parse arguments with a simpler argument parser that does just the couple of things they actually needed.

In the end, only 3 dependencies were left: glob, libc, log.

For a core component with security implications like sudo-rs, it makes perfect sense, because people will want to read the code and check that nothing nasty is going on. 135 dependencies made that impossible. With 3, you can do that – especially if one is libc that you’ll be interested in and familiar with in that position anyway.