I've been thinking about this a long time[1][2]. At the moment, I think "build or reuse?" is the wrong question to ask.

* Reusing someone else's implementation gives you the benefit of an initial kickstart. It also can give you future benefits: a library may contain improvements that you may need in the future, at which point you get them for free. Infinite productivity!

* Building your own implementation has an initial cost, but it reduces your maintenance burden to only the features you actually use. It also insulates you from counterparties whose interests may not align exactly with your own, or who accidentally introduce security risks.

If only we could magically unbundle the benefits of other people's code from their limitations, have features magically appear when we need them, and be magically robust to security holes in features we don't use. Here's the closest I've been able to get so far:

Use libraries by copying them.

Let's see why this is good. For starters, it makes you robust to the leftpad failure mode. The library is literally copied into your repository. Who cares how small it is anymore?! It could literally vanish off the face of the rest of the earth, and your code would continue to work.

A less obvious benefit is that copying a library puts you on a trajectory of taking responsibility for your dependencies. You don't need to understand all of it on day 1, but as you use it and run into issues you should be gradually understanding its internals better, gradually resolving features that you use, and features that you don't. That then gives you the option to rip out stuff you're sure you'll never need. Or to rip out stuff you may need in future, but is easy to put back (this is analogous to deleting code without fear because version control).

I consider an example of exemplary library use to be how I copied the termbox library into Mu (https://github.com/akkartik/mu/commit/5f1285238b), periodically merged commits from upstream (https://github.com/akkartik/mu/commit/9ba313ab7f), gradually cleaned it up to fit better with my project (https://github.com/akkartik/mu/commit/9a31c34f0f), and gradually stripped out code from it that Mu does not require (https://github.com/akkartik/mu/commit/c04baba4f2; https://github.com/akkartik/mu/commit/8e7827dfcf; https://github.com/akkartik/mu/commit/547ec78bf2). In the process I made some wrong turns, deleting features that I later decided I wanted (https://github.com/akkartik/mu/commit/10a3b8cca2) and created bugs for myself (https://github.com/akkartik/mu/commit/3315a7d3bb; https://github.com/akkartik/mu/commit/0c0d1ea5cd). But when it did things I didn't want, I was now empowered to change them (https://github.com/akkartik/mu/commit/ee1a18f050). One of my patches was useful upstream, so I submitted it: https://github.com/nsf/termbox/commit/0730826a07. I would be in no position to submit that patch if I hadn't taken the trouble to understand termbox's internals. And that shows a final benefit of copying and privately forking libraries: it makes you a better citizen of the open source world, because open source depends on eyeballs, and using a library blindly helps nobody except your (extremely short-term) self.

Now you may say, this sounds like a lot of work. I can't do it for all the libraries I use. Start small. Pick one dependency that is pretty central to your project, bring it in. See how you like it. As you gain experience come tell me what you discover. (My email is in my profile.) I didn't have all this thought out when I copied termbox into Mu. Benefits gradually became apparent.

[1] http://akkartik.name/post/libraries

[2] http://akkartik.name/post/libraries2

(Past versions of this comment: http://arclanguage.org/item?id=20213; https://lobste.rs/s/w4auk6/more_shell_less_egg_all_this#c_nv...)