Unix frequently espouses "do one thing", but how much "one thing" is is always open to interpretation.
And it's never been quite as small as e.g. left-pad. It's more something like `printf` or `cat`, which do "print a formatted string" and "concatenate files" as their "one thing", respectively.
Let me reiterate: The problem isn't "single responsibility", the problem is "single responsibility for half a thing".
The pieces are just too tiny, which leads to an explosion of packages, which leads to packages being badly maintained.
`cat` without any options support is possibly simpler than left-pad.
I think the big difference is that very few people set their systems to trust and receive updates of `cat` directly from the developers of `cat` (and same for all the other standard tiny utilities). Instead, they rely on a Linux distribution to vet the developers' code and to regularly pull in updates. Maybe there's room for a similar model of distributions vetting code in the npm ecosystem.
Also, cat is kind of an important primitive for building a functional system that uses files as one of its core abstractions. It makes total sense that it would (a) exist and (b) be well maintained by an authoritative and reliable source.
The core utilities are provided as a suite. The cat utility is one of a hundred others, all packaged together. Even without distributions, you'd only need to vet one organization for those basic utilities.
Add to that the fact that while the Unix way works well for connecting certain types of programs through pipelines and/or shell scripts, those programs themselves are written usually in C or Perl, Python &c, which are languages that have big standard libraries. It might be reasonable to assume that while programs that conform to Unix philosophy may constitute useful building blocks for end user or sysadmin tasks, more complex programs, even those "building blocks" themselves are better off with languages that provide them with a rather large, well-though-out toolset that's built as an integrated whole, i.e. a standart library.
I don't follow your comparison. What parts of the Linux ecosystem have a single person maintaining a large multitude of packages?
Looking at the kernel itself you see a hierarchy where people are only responsible for small segments of the kernel.
Looking at a standard distro like Debian, which makes this easily available at https://www.debian.org/devel/people you'll see that most individuals are only responsible for a handfull of packages, with the bulk having a team responsible for them.
I think with "single responsibility" he means the packages. So instead of complex packages that are hard to maintain they have lots of smaller packages that are easier to maintain. So a single person can maintain several packages.
Not saying that I think maintaining hundreds sounds like a good idea, just trying to point out the misunderstanding :) .
