The dependency nobody funds

Every large software company runs on components it did not write, did not pay for and cannot easily replace. That arrangement has worked for two decades because a small number of people maintained those components without being compensated for it.

The concentration is the part that keeps surprising people who look at it. Analysis of the funding problem describes a majority of downloads in major package ecosystems resting on fewer than twenty maintainers, many of whom do the work outside a paying job.

That is not a moral observation, it is a risk register entry. A dependency maintained by one person who has lost interest is an unpatched vulnerability waiting for a disclosure, and no procurement process captures it because nobody signed a contract.

The industry has tried to fix this several times and the attempts share a shape. Donations arrive after an incident, in a burst, and stop. A maintainer cannot plan a year of work around a spike of goodwill following someone else's breach.

The models being tried now are attempts to make the money boring. Corporate sponsorship at a fixed rate per developer, consortium funding for named projects, and an endowment structure intended to pay out returns rather than principal.

Google's own community consultation on the question found the same theme repeatedly: maintainers want predictable, ongoing support rather than one-off grants, because the work is ongoing and a grant is not.

Money is also not the only ask, which companies consistently underweight. Maintainers describe the heavier burden as the volume of low-quality issues, security disclosures they are not equipped to triage, and compliance questionnaires from firms that have never contributed anything.

Artificial intelligence has sharpened both problems at once. Generated pull requests arrive in volume and require review by the same unpaid person, and the models producing them were trained on the very code whose maintenance nobody is funding.

The counterargument from companies is that they contribute engineering rather than cash, and for large projects that is genuinely true. It is least true precisely where the risk is highest, which is small libraries with one maintainer and enormous download counts.

What would change the picture is treating a critical dependency as a supplier, with a contract, a contact and a renewal date. That is unglamorous, it is how every other input is procured, and it remains rare.