To Depend Or Not To Depend

The whole idea of using open source libraries and whether it is even a good idea to include dependencies in our projects at all has been on my mind lately for a variety of reasons. I have been listening a lot to the maintainable podcast and there is a lot of discussion on there about dependencies and open source libraries. I’ve also been having some discussions with both Steve Watts and Chris Cilino. It seems there are really 2 camps when it comes to this idea.

2 schools of thought

Dependencies are bad

There is a school of thought that says “Dependencies are bad”. They view dependencies as a liability. They can conflict with each other. They can have bugs. They are not always maintained. When they are maintained, sometimes the upgrades break our code (see the 2 line Javascript library that broke the internet). When people download our code they often have to find all the dependencies. Managing all the versions can be a pain. People often include them without fully understanding them. They never seem to do exactly what we want anyway, so why not just write it ourselves or at least fork it and use it as starting point so we are in control.

Don’t Reinvent the Wheel

There is another school of thought, epitomized by GCentral, that says “Don’t reinvent the wheel”. We are all solving similar problems, so let’s figure them out once and be done with it. They view dependencies as an asset. By using a commonly available package they can save a lot of effort. If the packages are well tested, it can also eliminate a lot of risk.

What do you think?

Are dependencies an asset or a liability? If the answer is they can be both, what factors determine that? How do you decide whether to include a particular package or not? How do you mitigate some of the downsides that come with having dependencies?

Updated to Add

I just had an interesting conversation about this recently on Linkedin after pasting a link to this article. Click on the image below to go to the thread on Linkedin.