It depends.
Some advantages of small and focused libraries:
- Small components may be reusable. That's the big one.
- Code size is small, so perhaps the deliverable is too (although you could probably do dead code removal as part of compilation, especially in static languages).
- Code size is small, so it'll be easier to understand it.
- Less code means less trust is needed, e.g. for security.
- It encourages creating a common infrastructure that others can build on, e.g. pythons numpy or linux streams or js events.
Disadvantages:
- Some things are hard to split, e.g. unicode support.
- It's administration overhead - more repos, more versions, more interdependencies...
- It's annoying to pick the parts you need. Most people will just end up using packages of many small utils.
- Integration may be worse, e.g. a web server framework that comes with an ORM and router and template engine is more restrictive, but perhaps more symbiotic than a pluggable one.
- Having hundreds of small libraries could be confusing for users (although with a decent package manager it needn't be).
- Small libraries that are reused may conflict if they have different versions (although with a great package manager they might not).
It's all kind of a spectrum. Is "json encoding for all the most common types" doing one thing well? Is "all of regex" doing one thing well? Is "collection of useful stream operations"?
I considered making lexing, parsing, code generation etc separate packages for my compiler, but in the end I didn't, because they're mostly useless in isolation.
Often users can get the best of both words with packages that give a unified interface using independent components (kind of a Facade pattern).
I think in many cases, the ideal system for open source projects is like:
- A package with shared infrastructure (usually mostly interfaces or data types). Or several if separable. Should be very stable. E.g. streams.
- Many small inplementation packages that depend on the infrastructure. E.g. cat, grep, sed, wc... Mostly for other developers.
- A few (nested) collection packages that fairly directly expose many independent components, possibly with a little integration logic. 90+% of end users will use this.