What It Actually Means
The difference from a framework is control. Your code calls a library. A framework calls your code. That makes libraries far easier to replace, because they sit inside your structure rather than defining it.
A vendor-provided library for talking to their service is often called an SDK. Same idea, published by the company whose system it connects to.
Why They Are Used So Heavily
Because most problems in software are already solved, and solving them again is expensive and worse.
Date and time handling is the standard example. It looks trivial and it is genuinely difficult once time zones, daylight saving and locale differences are involved. Writing it yourself means recreating bugs that were fixed years ago in something well tested.
The same applies to currency, PDFs, image processing, encryption and file formats. Using a mature library is not laziness; writing your own is usually the mistake.
The Cost Of Each One
Every library added is a permanent commitment to somebody else’s decisions.
It has to be maintained. Updated, checked for vulnerabilities, and eventually replaced if abandoned. That is the dependency burden and it never goes away.
It may be abandoned. Maintainers move on. An abandoned library stops receiving security fixes, and anything found in it stays open.
It brings its own dependencies. A library that seems small can pull in a dozen others. This is how a modest application ends up with hundreds of components.
It can change direction. Major versions break things, licences occasionally change, and projects sometimes get acquired.
None of that is a reason to avoid libraries. It is a reason to add them deliberately rather than reflexively, and to prefer mature well-used ones over clever new ones.
The Judgement That Matters
The useful test before adding one: is this problem genuinely solved better elsewhere, or are we importing a hundred lines we could write in ten?
Both mistakes are common. Writing your own encryption is dangerous. Adding a library to check whether a number is even is the opposite failure, and ecosystems where that happens routinely have produced some memorable outages when a trivial package was withdrawn.
For a business, the practical signal is the total count relative to the size of the system. A large number on a modest application suggests things were added casually, and each is maintenance somebody has to carry.
What To Ask
- How many libraries do we depend on? Not a target, and a very large number on a small system is worth discussing.
- Are any unmaintained? An honest team can name them.
- Are they scanned for known vulnerabilities? This should be automated.
- What are the licences? Mostly permissive, and some carry obligations that matter for commercial software. Worth checking once.
- Could we replace this one if it were abandoned? For anything critical, the answer should not be no.
The Sensible Position
Use well-established libraries for genuinely solved problems, keep the total deliberate rather than accidental, and make sure somebody is watching for vulnerabilities and abandonment.
That is ordinary maintenance rather than a project, and it is exactly the work that gets deferred until it becomes one.
More terms are in the glossary.
