Open source maintainers are really feeling the squeeze
- Reference: 1739698211
- News link: https://www.theregister.co.uk/2025/02/16/open_source_maintainers_state_of_open/
- Source link:
The theme cropped up repeatedly during 2025's State Of Open Conference, with speakers from tech giants and volunteer maintainers laying out the challenges. Much of the open source ecosystem relies on volunteers putting in too many hours for too little support and the cracks are growing.
four hours a month... does not come close to meeting the demands of users and the "How hard can it be?" brigade. Maintainers are undoubtedly under pressure, and many have either quit or are considering doing so...
This week, the lead of the Asahi Linux project – a Linux distribution for Apple silicon – Hector Martin, [1]abruptly quit , citing factors including developer burnout and demanding users.
Jamie Tanna, who gave himself the title of "Tired Maintainer" [2]put it simply : "Being an open source maintainer is really rewarding... except when it isn't."
Tanna has been active in the open source world for several years, although it was the experience of being an [3]oapi-codgen maintainer that he spoke about. For the uninitiated, oapi-codgen is a tool to convert OpenAPI specifications to Go code.
[4]
"It's used by a load of companies... and a load of angry users."
[5]
[6]
The story is a familiar one. Tanna has helped out with some issues on the project and had volunteered for maintainer duty. There was a flurry of releases, but before long, the time between each release began to lengthen. Being a maintainer, he explained, with big or small projects (but especially big ones) meant dealing with "fun" users who are very happy to express their feelings as well an ever-increasing list of requests.
The experience of feeling under pressure, isolated and faced with a growing pile of work while receiving the occasional unpleasant message from an entitled user demanding their issue be dealt with now or that a contribution merged be immediately is far too common.
[7]
Tanna is relatively fortunate – his employer gives him four hours a month to work on the project. However, that does not come close to meeting the demands of users and the "How hard can it be?" brigade. Maintainers are undoubtedly under pressure, and many have either quit or are considering doing so.
Many projects, even those deemed 'critical infrastructure' are supported by very few people (often with one person doing most of the work)...
Sophia Vargas, an analyst and researcher for open source programs and operations at Google, told The Register that "Absolutely" maintainers were under pressure. Vargas added that the pressure was "both systematically and at the individual community level.
"Many participants in open source feel that open source projects are chronically undersupported, especially given the growing appetite for using open source software.
"This feeling is also reflected in the numbers: many projects, even those deemed 'critical infrastructure' are supported by very few people (often with one person doing most of the work), many maintainers have considered quitting, and many projects may not be maintained at all."
Vargas used figures including a [8]2024 Tidelift survey that put a figure of 60 percent on maintainers that had either quit or were considering quitting, and [9]another [PDF] from the Linux Foundation showing that most of the more widely used Free Open Source Software was developed by only a handful contributors.
[10]
Kubernetes maintainers Kat Cosgrove and Jeremy Rickard weighed in on the discussion too. Rickard, a Microsoft employee, also works on the CNCF code of conduct. The pair run a survey collecting the experience of maintainers and project contributors.
Cosgrove noted the number of respondents was too small to be statistically significant, however, the problem wasn't just maintainers being on the receiving end of pressure and abuse. The issues extended to users on the sidelines. "They like the project less, and seventy percent considered whether or not they should contribute to that project."
Dealing with the problem is difficult. Do maintainers simply need to be paid in recognition of their efforts? Vargas is unsure that everything has a financial solution and noted research (https://dl.acm.org/doi/10.1145/3674805.3686667) presented at this year's FOSDEM. Vargas told The Register , "Money is not going to solve all problems."
"Each maintainer and project has their own context and challenges - while many maintainers would benefit from financial support, others really could use more contributors to complement their work and remove responsibilities from them - especially for non-code tasks like mentorship, community management, issue triage, promotion and fundraising, etc."
[11]Why do younger coders struggle to break through the FOSS graybeard barrier?
[12]After clash over Rust in Linux, now Asahi lead quits distro, slams Linus' kernel leadership
[13]LibreOffice still kicking at 40, now with browser tricks and real-time collab
[14]Murena boss says customers about to wake up from its cloud storage nightmare
Rickard also worried about a potential squeeze on budgets as economic uncertainties bite and talked of raising awareness on platforms such as GitHub around sponsorship, given a contraction in the funding of projects by companies.
"You've got to have something as a catalyst for that change to happen. We, as a group of humans, don't seem to do proactively very well."
Cosgrove said, "I'm afraid it'll take a significant project falling over to convince them [the users] that paying for open source maintainers is worthwhile and, in fact, may actually be a requirement.
"I don't want to see that happen because the fallout will be ugly and gross, but I'm concerned that that's what it'll take." ®
Get our [15]Tech Resources
[1] https://www.theregister.com/2025/02/13/ashai_linux_head_quits/
[2] https://youtu.be/PK8CMcePn2A
[3] https://github.com/oapi-codegen/oapi-codegen
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z7HFUArroCZoV3csRxdN3QAAAIw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z7HFUArroCZoV3csRxdN3QAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z7HFUArroCZoV3csRxdN3QAAAIw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z7HFUArroCZoV3csRxdN3QAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://explore.tidelift.com/2024-tidelift-survey/2024-tidelift-state-of-the-open-source-maintainer-report
[9] https://www.linuxfoundation.org/hubfs/Research%20Reports/lfr_harvard_censusII_mar2022_042824b.pdf
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z7HFUArroCZoV3csRxdN3QAAAIw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2025/02/14/youngsters_in_foss/
[12] https://www.theregister.com/2025/02/13/ashai_linux_head_quits/
[13] https://www.theregister.com/2025/02/13/libreoffice_wasm_zetaoffice/
[14] https://www.theregister.com/2025/02/12/murena_ceo_de_googling_android/
[15] https://whitepapers.theregister.com/
Obligation to maintain?
The idea of freely sharing code is as old as computing. The first computer user group (SHARE, which originally was exclusively for the IBM 704) began in 1955 and defined a card-based format for sharing software amongst the participating organisations as well as essential standards (such as linkage conventions) to make them readily reusable. Software from computer manufacturers was usually free as the computers were a hard sell without it and unless you'd bought a machine there was no way of making use of it. Copyright in computer programs wasn't really a consideration until there was a level of compatibility between computers - software was typically distributed either as assembly code or compiled object code - and the bundling of hardware and software came to be seen as anti-competitive. However, once people had to pay for software, they expected it to be maintained in a working condition in the same way as the computer itself.
The twist that the Open Source movement put on this was to make the source code freely available on request, but having thereby eliminated any commercial element from the creation of software nevertheless offered ongoing support and maintenance as a possible source of income.
We now seem to be in a situation where even that source of income has been eliminated, not by any particular law or campaign, but simply by developers capitulating to peer pressure. And having done that, they're of course finding themselves expected to serve up not only support, but also functional enhancements they don't themselves need, free of charge.
It's not only unsustainable, it's also counter-productive. It leads to developers and maintainers simply walking away and leaving projects abandoned. It also leads to the constant churn of new frameworks and re-implementations because developers prefer to move on to new things. And of course it leads to a worldwide distributed security threat because, outside a few prominent projects, no-one knows who's actually writing the code or cares what's actually in it (despite, ironically, the source being open).
If a solicitor prepares your will, you don't expect to get free updates for life. If a plumber fixes your tap, you don't expect them to come back at no cost whenever it drips in future. I'm all for developers freely sharing their code, but that altruism should not come at the cost of a future obligation: it's the recipient's job to decide whether it's useful, how to adapt it to their environment and to maintain it. That might involve paying someone (possibly the original author), but no-one should expect a free ride.
Especially galling are large corporates ...
(some of who I have worked in) who depend on Open Source components and then complain about bugs or missing features. I have suggested that they pay for the bug fix or enhancement to be met with derision "who do I think they are - to pay for something that could benefit their competitors ?", or similar sentiments.
Sometimes I fave fixed a bug while being paid for them and with their approval. "Now let me send in a patch" to be told "not on our time" - so I do it when I get home.
They just do not understand that we can all move forward faster if we cooperate, payment of trivial sums (compared to what they waste elsewhere) is an anathema to some of them.
Re: Especially galling are large corporates ...
But but but SHAREHOLDER VALUE!!!! /s
No support contract? Then STFU!
This has been an issue for years. FOSS isn't there so you don't have to pay anyone. Many of the people doing the HARD work are hobbyists or doing it out of a love of technology. Log4j showed how embedded this stuff is and how even multi billion $ corporations take advantage & just chuck modules in without testing etc.
If you're not paying support for #opensource then you've got zero right to complain, EVEN if a zero day isn't patched for a year!
The trick with open-source was to keep things simple and fun.
Many newbies / beginners don't realize this and so chose complex tools, complex workflows, promise far too much and then ultimately can't deliver.
That's fine, hopefully once they recover they will learn from their mistakes and start smaller (i.e using C, simple build systems, pulling in less dependencies, less technical debt, etc)
Open Source was traditionally about "scratch an itch"
There is a simple way to get features and bug fixes to an OpenSource project. Pay IBM a pile of money and ask them to do it.
Otherwise, it's only really going to happen if a maintainer happens to have the same requirement/problem as you. Why would it? It's your problem, not their's.