On 2026-07-31 13:51:21 -0700 (-0700), Russ Allbery wrote: [...]
One solution that anyone in open source software communities has heard about for decades now is to turn open source software maintenance into a job with a paycheck. Then it doesn't necessarily have to be fun; there are other compensations instead, just as there are with all the other things we do for a paycheck that we wouldn't do voluntarily. Some larger projects, and even some small projects that invested effort into money raising, have made this transition and the people working on those projects are at least partly doing so for a paycheck.
[...]
Conversely, for a lot of the projects I'm involved with, a majority of contributors are paid by their employers for their involvement. The challenge becomes: they often only have time to work on features or fixes important to their employer's product/device and not on the commons (keeping documentation updated, tests working, defect reports tracked, evolving ecosystem packaging standards met, new backward-incompatibilities in dependencies dealt with, and so on). If convincing companies to pay people to work upstream is hard, convincing them to pay people to work on the most important boring bits is nigh impossible.
What's become clear to me over the years is that corporate contribution in collaborative open source communities isn't all that different from volunteer hobbyist involvement, everybody's still scratching their own itches it's just that the employed contributors are scratching the itch of some company rather than a personal one.
Even with money, the tragedy of the commons remains tragic, or perhaps becomes even more so. Each company involved has little incentive to help with the commons if they think there's a chance that avoiding doing so will cause another company (perhaps even a competitor) to do it instead and assume the related expense.
I think open source software is coming face to face with a motivation crisis that has been building for a long time. The large projects with funding ecosystems and heavy corporate involvement will be fine; they have already largely switched from volunteer motivations to paid employment motivations, and can complete that switch.
[...]And yet even they are mostly falling into the "can't someone else do it?" trap. At least in my communities, maintenance of the commons ends up being shouldered by a vanishing few whose employers are gracious enough to pay them to work on whatever those individuals think is actually important to get done, rather than only on directly marketable product features or support for a specific vendor's hardware.
Vulnerability management is part of that under-resourced commons, but a part which requires deep understanding of the software and how it's used, as well as the nuances of navigating the whole of the developer community. It isn't a task that a company can just throw warm bodies at and certainly not something that outside consultants are going to have much success with, even if they have a general understanding of software security and coordinated disclosure norms.
Now we seem to be able to get some companies to care about security in the free/libre open source software on which their businesses rely (whether through a newfound sense of self-preservation or because their lawyers tell them complying with recent regulations is important). The problem I'm facing is that we need a good way to explain to them that helping with the whole of the understaffed commons in these projects frees up existing maintainers to focus on making the software more secure.
-- Jeremy Stanley
signature.asc
Description: PGP signature
