Consider this: a 2020 study found that 87% of published research papers in computational biology depend on fewer than ten open-source tools. Tools maintained by small teams, often volunteers, frequently working nights and weekends.
When those tools break, thousands of research pipelines fail. When those maintainers burn out, entire fields slow down.
Yet the funding system treats this infrastructure as invisible.
Here is the problem in concrete terms:
- The dependency gap: A bioinformatics researcher uses samtools, BWA, and GATK daily. Each tool represents person-decades of work. Each receives a fraction of the funding allocated to any single wet-lab project that depends on them.
- The maintenance trap: Grant agencies fund new tools, not maintenance. So researchers build v1.0, publish, get tenure points, then move on. Users are left with unmaintained software that breaks with every OS update.
- The invisibility tax: When a critical library like NumPy or scikit-learn works flawlessly, nobody notices. When it fails, everyone notices. Funding follows visibility, so foundational work remains chronically underfunded.
- The bus factor problem: Many critical scientific tools have a bus factor of one or two. If those maintainers leave, entire research workflows become fragile.
The open-source software movement solved this problem in tech. Companies pay for support contracts, sponsor maintainers, fund core infrastructure through organizations like the Python Software Foundation or Apache.
Science has not caught up.
A Grants for Free Software approach would treat open-source scientific tools as public goods worthy of sustained funding—not one-time development grants, but ongoing maintenance support tied to actual usage metrics and community impact.
The question: Should grant applications be required to disclose their software dependencies? And if a project depends on unfunded open-source tools, should a percentage of the grant automatically flow to those maintainers?
Comments
0 approved