小さく作って組み合わせていくというやり方は、作る方からすると理にかなっている。自分の必要とする機能を実現するコードだけを書けば済むようになるからだ。使う方からしてもパッケージ・マネージャーがそれなりに動作すればさほど問題になることはない。ただバグを見つけた時に伝言ゲームになりやすいという問題がある。
小さく作っていく関係上、多くの場合はそういったライブラリー達をうまくラップしたものがエンド・ユーザーには使われる。具体的には以下のような構成になっていることだろう。
4を使っている人がバグを見つけた場合、当然4に報告する。4の開発者がどうも3に原因があるらしいと判断した場合、3へ報告される。以下、3の開発者が2へ、2の開発者が1へ、と必要ならばバグは伝言ゲームのように伝わっていくことだろう。途中でバグの内容がうまく伝わらなくなり、戻ってきたりすることもある(それで良いことももちろんあるが)。または途中の開発者が忙しかったり、もう開発を投げていたりすると、1などの上流へバグが伝わらないこともある。
つまり、バグ報告に正確さが欠けやすいという問題と、上流のモジュールにバグ報告が到達しづらいという問題がある。これらの問題を避けるためには、なるべく上流にバグ報告をする必要があるが、それをしてしまうとせっかく小さい単位で作っている意味が少なくなってしまう。小さく作ることの目的のひとつに、自分で書いたコード以外におけるバグの調査を他に投げられることがあるはずだからだ。
上流に直接報告することが難しいとなると、いかにこのバグ報告という伝言ゲームを途切らせないかが重要になる。すなわち、小さなライブラリーで構成される世界では、ライブラリーを選択する際、その歴史的な評価よりも開発の活発さの方が重要な要素になりうるということだ。上流へ速やかにバグが伝わり、下流へきちんとその修正が流れてくれば、開発者がアドホックな対策に追われる必要はなくなる。この流れが途切れないようにするためには開発の活発さが重要になるというわけだ。
単純にコミットのペースだけではなく、週に閉じられたイシューの数やプル・リクエストが立ってからの反応の早さなどでも開発の活発さを計ることができるだろう。むしろ後者の方が重要かもしれない。パッケージ・リポジトリーでの人気だけではなく、こういった点もライブラリーを選択する参考にすると良さそうだ。