that and, i would argue that npm in particular is filled with lots of small projects and only very few large ones simply by the nature of the ecosystem. it is the wrong place to look. something better would probably be to eg count the contributors on github, or, on npm, analyze project dependencies and distinguish projects that are directly downloaded vs those that are loaded as a dependency. arguably, dependencies can be replaced by the developers of the project using it, so a developer of a dependency disappearing is less dramatic than if you use that project directly.

technically speaking, if you have a large project with many contributors, every contributor is often still only responsible for one small part of the project. linux kernel drivers and subsystems most have their dedicated developers. and very few of them each.

leftpad was a minuscule project that could have been created by anyone. Yet its deletion caused chaos. There are certainly load bearing projects of moderate complexity that are still single person efforts.

right, but the problem here was the deletion of the module, not the disappearance of the maintainer. in the later case the module would have remained, and if it would stop to work because of some incompatibility in a future js, people would replace it

You could also imagine leftpad was using some security compromised library (eg log4j). If the project is of moderate complexity and there is nobody behind the wheel to maintain it, what happens to the ecosystem?

basically, my rule of thumb is that i have to be prepared to take over and maintain any dependency that i use. it's all part of my code. if i am not prepared to do that then i better avoid pulling in the dependency in the first place.

the leftpad example, as it happened, was not a maintainer issue. had the maintainer just stopped working on it, replacing leftpad would have been a no brainer for anyone taking their project seriously. deleting leftpad was deliberate sabotage by the maintainer, even if he may not have predicted the consequences.

i dare say that the leftpad incident would not have affected me because i never deploy live depending on remote resources. everything needed to deploy is cached, and the only time leftpad disappearance would have affected me is when setting up a new project, at which point the failure to build would be an oops, there is a bug, we need to fix it kind of situation.

i don't rely on others such that if they don't do their work my house would come crashing down. if that happens, then that's on me. i rely on things that have been proven to be stable. a maintainer disappearing does not affect the current stability of any of my systems. it only affects future upgrades, and i can deal with those.

even security issues don't necessarily depend on the maintainer such that only the maintainer could fix them. that's the whole point of FOSS, that anyone can fix issues if necessary. in the worst case someone out there would work on a patch to fix the log4j issue, or, remove it as a dependency. if the issue is critical enough for me, then that someone might even be myself.

Maintainers and contributors have overlapping but subtly different responsibilities AFAIK.

Maintainers are the ones responsible in the end for the state of the repo while contributors suggest changes.

I have couple open source NPM packages I develop together with other developers. In some of this packages I have less than 50% contributions in code. But I listed as contributor on NPM, just because I found this packages and did not update contributors list a long time.

So definitions does not matter when stats that author refers, does not include a developers who own over 50% code in repo, but includes me as contributor.

That's widely known problem of programmers to believe that world is perfect and all data are always actual. Actually it won't.