Before dependency managers,
publishing an eight-line code library
would have been unthinkable: too
much overhead for too little benefit.
NPM, however, has driven the overhead approximately to zero, with the
result that nearly trivial functionality
can be packaged and reused. In late
April 2019, the escape-string-regexp
package was explicitly depended
upon by almost a thousand other
NPM packages, not to mention all the
packages developers write for their
own use and don’t share.
Dependency managers now exist
for essentially every programming language: Maven Central (Java), NuGet
(.NET), Packagist (PHP), PyPI (Python),
and RubyGems (Ruby) each host more
than 100,000 packages. The arrival of
this kind of fine-grained, widespread
software reuse is one of the most consequential shifts in software development over the past two decades. And if
we are not more careful, it will lead to
What Could Go Wrong?
A package, for this discussion, is code
downloaded from the Internet. Adding
a package as a dependency outsources
the work of developing that code—
designing, writing, testing, debugging,
and maintaining—to someone else on
the Internet, often unknown to the programmer. Using that code exposes the
program to all the failures and flaws
in the dependency. The program’s execution now literally depends on code
downloaded from this stranger on the
Internet. Presented this way, it sounds
incredibly unsafe. Why would anyone
Because it’s easy, it seems to work,
everyone else is doing it, and, most
importantly, it seems like a natural
continuation of age-old established
practice. But there are important dif-
ferences that are being ignored.
Decades ago, most developers trusted others to write the software they
depended on, such as operating systems and compilers. That software was
purchased from known sources, often
with some kind of support agreement.
There was still a potential for bugs or
outright mischief, 20 but at least the developers knew who they were dealing
with and usually had commercial or
legal recourses available.
The phenomenon of open source
software, distributed at no cost over the
Internet, has displaced many of those
earlier software purchases. When reuse
was difficult, there were fewer projects
publishing reusable code packages.
Even though their licenses typically disclaimed, among other things, any “
implied warranties of merchantability and
fitness for a particular purpose,” the
projects built up well-known reputations that often factored heavily into
people’s decisions about which to
use. The commercial and legal support for trusting software sources
was replaced by reputational support.