Widely used open source components frequently have very small maintainer teams. The reason is that the demanding part of maintenance is not writing code, and it does not scale with contributors.
Review consumes more time than writing
Incoming contributions must be read, understood, checked against the project's design intentions and tested. That work falls on maintainers regardless of how much help arrives.
A contribution that is well-intentioned but unsuitable takes longer to handle than one that is straightforwardly good, because declining it requires explanation and often discussion.
More contributors therefore increase maintainer workload before they reduce it, which is the opposite of how volunteer help is usually imagined to work.
Compatibility obligations grow with adoption
Once many systems depend on a library, changing its behaviour breaks them. The project takes on an obligation it never agreed to and cannot easily withdraw.
Maintaining compatibility means keeping older interfaces working while adding new ones, which increases the surface that must be tested on every release.
Popular projects thus become slower to change precisely because they are popular, and maintainers spend more time preserving than building.
Support requests arrive without limit
Issue trackers receive genuine defect reports alongside usage questions, configuration problems and reports that concern entirely different software. Sorting them is continuous work that requires context nobody else has.
Commercial users often submit issues with the expectations of a vendor relationship, including urgency and follow-up, without any corresponding commercial arrangement existing. The asymmetry is a common reason maintainers step back.
Automated dependency tooling adds a further stream, since every downstream project now files upgrade requests and compatibility reports mechanically. Volume rises without any human having decided the report was worth making.
Security handling has a fixed shape
A vulnerability report requires confirmation, a fix, coordination with distributors and a disclosure timeline, all under time pressure and often under confidentiality.
This work cannot be delegated to the wider community by definition, so it lands on whoever holds the keys regardless of their availability that week.
It also arrives unpredictably, which makes it hard to reconcile with the paid employment that usually funds the maintainer's time.
Funding rarely reaches the right layer
Sponsorship tends to flow toward visible, user-facing projects rather than toward the small libraries deep in dependency trees that carry the most systemic risk.
Those low-level components often have the fewest maintainers and the broadest reach, which is the combination that produces widely reported incidents.
The structural point is that adoption creates obligation without creating resources, and nothing in the model connects the two automatically.