What public money does to open-source projects

Most of the software running inside a typical company was written by volunteers the company never paid. Open-source code sits under web apps, build pipelines, and the machine learning stacks getting so much attention right now. Roughly 96 percent of codebases carry some of it.

open source funding impact

That dependence turned visible in December 2021, when the log4j flaw exposed applications from Twitter to Minecraft. The xz utils backdoor of 2024 drove the point home again. Both traced back to tiny volunteer teams looking after code that billions of systems lean on, often in their spare time around day jobs.

Everyone uses the code for free, from solo developers to the largest tech firms, and almost no one is on the hook to give anything back. Maintainers burn out. Projects holding up huge chunks of the internet run on a handful of people and a lot of goodwill.

Governments started treating this as their problem too. Germany’s Sovereign Tech Fund began in 2022 under the Federal Ministry for Economic Affairs and Climate Action, hosted by SPRIND. It signs maintenance contracts with open-source projects, starting at 50,000 euros and running anywhere from several months to a couple of years.

In November 2024 the fund grew into the Sovereign Tech Agency. Its lineup now covers well over a hundred projects, with sister programs pointed at developers and at security work.

So what does the money buy? A new study takes a run at exactly that. Laia Domenech Burin, a data scientist at the agency, crunched the numbers on whether paying for maintenance changes what a project puts out. Her approach was to build a stand-in for each funded project out of similar projects that got nothing, then check whether the funded ones pulled ahead.

Getting a fair comparison was the hard part. She started with a long list of open source projects that plenty of other software leans on, picked the ones that resembled the funded projects on things like dependent repositories, stars, and forks, and landed on 62 unfunded projects to measure twelve funded ones against. The activity data ran back to 2015.

Four funded projects sit at the center: the Python Package Index, curl, Fortran tooling, and RubyGems. These are load-bearing pieces of everyday development. Curl alone reports more than twenty billion installations across phones, cars, televisions, and medical devices. Its funded stretch worked through more than a hundred known bugs and added support for newer versions of the HTTP protocol.

The short version of the result is that the money moves the code. Funded projects logged a real rise in commits, in new change requests, and in merged ones. New issues went up too. The picture is a burst of development in the quarters right after a contract gets signed.

And the burst is big. Commits roughly doubled and then some, up about 144 percent over where they would have landed with no funding. New issues climbed the most, up by well over double. Change requests moved by amounts in the same range. The margins around these figures are wide, so they point to a direction more than a hard number.

Three things stayed flat. The number of contributors barely budged. Release frequency held steady, and so did the count of closed issues. The money got more out of the people already on hand. It pulled in few new ones, and it left the backlog about where it was.

That mix is the part worth chewing on. Paying a project speeds up what its current maintainers do. The shortage of hands stays a shortage. Domenech Burin calls the metrics “a compass: they indicate the direction, but not the destination.”

The study covers four projects and twelve repositories, a thin base for sweeping claims. The jump in new issues cuts two ways: an engaged crowd filing bug reports, or a growing pile of work no one has time to touch.

There is a lesson in here for anyone writing checks for open source, in a company or a government. Growing the contributor base and clearing the backlog sit with the agency’s other efforts, a fellowship for developers and a resilience program aimed at vulnerabilities. Grading a maintenance contract on contributor counts would measure the wrong thing.

Match the yardstick to the goal. A fund that pays for maintenance buys speed from current maintainers. Growing the community and working through old items are separate jobs, with their own budgets and their own scorecards. The money keeps critical infrastructure moving. Keeping the people behind it going is a different line in the ledger.

Must read:

Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!

Don't miss