日付の計算、グラフの表示、外部との通信。どのアプリでも必要になる定番の処理を、毎回ゼロから書く人はいません。誰かがまとめて公開している部品を借りてきて、自分のプログラムに組み込みます。この再利用できる部品のまとまりが、ライブラリです。
道具箱にたとえると分かりやすいかもしれません。必要なときに、必要な道具だけを取り出して使う。主導権は使う側にあります。似た言葉のフレームワークは、作業のルールまで決まった工房のようなもので、こちらは枠組みに沿って作っていきます。道具箱は自分で選んで使うもの、工房は決まりに合わせて入るもの、と覚えておくと区別しやすいでしょう。
チームで品質の高い実装を共通して使える、同じ処理を何度も書く手間が減る、というのが借りる側の利点です。
部品を足すたびに面倒を見る相手が増える
便利な部品ほど、気軽に足したくなります。ただ、ライブラリを1つ入れるということは、その部品の面倒も一緒に見るということです。部品に弱点（脆弱性）が見つかれば更新しなければならず、更新すれば動きが変わっていないか確かめる必要があります。増やしすぎると、この対応の負担がどんどん重くなります。
入れる前には、まず本当に必要かを考え、そのうえで次のことを確かめておきましょう。
- 今もメンテナンスが続いているか。何年も更新が止まっている部品は、弱点が見つかっても直らないかもしれない
- ライセンスが、自社の使い方（たとえば商用利用）に合っているか。MIT や Apache-2.0 など、条件は部品ごとに違う
- 使い方を覚える手間に対して、得られる効果が見合っているか
- その部品が、さらに別の部品をたくさん連れてこないか（依存関係）