I use third-party libraries aggressively on short projects and cautiously on long-lived ones.
That is the whole argument.
If I need to ship a client web app in 4-8 weeks, dependencies buy me time immediately. If I am building a platform expected to run for years, every dependency becomes a long-term liability I have to own. Security events like log4j are the reminder: borrowed code still becomes your operational problem.
The part teams underrate is not just CVEs. It is people turnover.
Will a junior engineer be able to debug that library at 2:00 AM? Will it still be maintained three years from now? In my experience, team composition changes faster than dependency trees, which means maintainability beats elegance over time.
Dependency decisions are now architecture decisions. The math got harder, not easier. This discussion is explored well in Surviving Software Dependencies.
My rule is simple: default to well-known, battle-tested libraries with strong maintenance signals. If a package is niche, weakly maintained, or hard to replace, I would rather copy a small piece of code than import a long-term burden. “A little copying is better than a little dependency.” https://go-proverbs.github.io/
Use external libraries when they clearly accelerate delivery, but treat every one as potentially temporary. Plan for removal before adoption. Software entropy is not just your code. It is your code plus every third-party line you transitively ship.