Counting the Cost of Dependencies

The balancing act that is always there

I’m shy about adding dependencies to projects I’m working on. I’m extremely hesitant. When I make a package myself, though, I weigh the addition of every package with extreme care.

Dependencies are me outsourcing my code to someone else. Something for nothing. Free sounds awesome at first. Borrowing someone else’s work is only part of being involved in Open Source.

When I use Open Source Software, I take on both the benefits and harms of that software. If there’s anything wrong with that code, I have complicated my life:

• For starters, I may not know there’s something wrong. That in of itself should give you pause, because verifying that someone’s work is correct is often harder than doing it yourself.

• If I happen to determine the problem is related to a particular dependency, it may have been fixed on a newer version.

• If it has been fixed on a newer version, then maybe I can do a simple upgrade. But sometimes there are breaking changes in between, and now I have to check for hidden side effects.

• If it hasn’t been fixed, it may at least have an issue already raised with some work arounds.

• If that doesn’t exist, then maybe I can fork it and put together a PR with the fix.

• But maybe the project maintainer won’t take my PR, or maybe he or she just doesn’t respond, or maybe the project is abandoned. Then I guess I become dependent on my own fork.

Having lots of dependencies is not automatically bad, but having lots of dependencies and using very little of them probably is bad. You’re setting yourself up for heart burn. And what’s worse, if you’re putting this into OSS, you’re setting up your users for potential long hours of work if you don’t vet what you’ve added very thoroughly.