Mastodawn

Jesus Michał "Le Sigh" 🏔 (he)

New on #blog: "Money isn’t going to solve the #burnout problem"

"""
The xz-utils backdoor situation brought the problem of FLOSS maintained burnout into the daylight. This in turn lead to numerous discussion on how to solve the problem, and the recurring theme was funding maintenance work.

While I’m definitely not opposed to giving people money for their FLOSS work, if you think that throwing some bucks will actually solve the problem, and especially if you think that you can just throw them once and then forget, I have bad news for you: it won’t. Surely, money is a big part of the problem, but it’s not the only reason people are getting burned out. It’s a systemic problem, and it’s in need of systemic solution, and that’s involves a lot of hard work to undo everything that’s happened in the last, say, 20 years.

But let’s start at the beginning and ask the important question: why do people make free software?
"""

https://blogs.gentoo.org/mgorny/2026/03/07/money-isnt-going-to-solve-the-burnout-problem/

#FreeSoftware #OpenSource #AI #NoAI #LLM #NoLLM #Gentoo

Money isn’t going to solve the burnout problem

The xz-utils backdoor situation brought the problem of FLOSS maintained burnout into the daylight. This in turn lead to numerous discussion on how to solve the problem, and the recurring theme was …

Michał Górny

mirabilos Mar 7

@mgorny yes. This. All of this. Literally all of the blogpost is something I feel. (And I raised the "money needs to come in, guaranteed safely, or I couldn’t give up my job" point often enough.) All of what you write about the burning down FOSS (whether by oxydisation/rusting or by literally burning down the planet/"AI"), too. You speak for me here.

Laurent Bercot Mar 7

@mirabilos @mgorny Same. I don't feel the doom and gloom too acutely because my community is awesome, I work at a low enough level to be isolated from the most glaring problems, and I got lucky (after decades of toil!) with funding, but it's definitely there and I subscribe 100% to what @mgorny says as well.

Cassandrich Mar 7

@mgorny So much all of this. I could use more money and appreciation, but really the worst part is all the charlatans and sellouts trying to burn down everything we've created, harvest and enclose it, apply the things they built on our backs to do evil, etm etm etm. Or even just trying to replace things that work with shiny new things that don't. Pressures to constantly update, adopt new languages and tooling, adopt the latest snakeoil "security" someone is selling, generally move fast and break things. Pushing back against rotten values in our industry & communities feels like a full time job in itself before even dealing with any code. And then you have a global fascist meltdown on top of that, tied in with lots of the same bad actors.

mirabilos Mar 7

@mgorny @dalias

Pressures to constantly update

I hadn’t realised, but, yes, this also contributes to burnout. Also, pressure to follow what others constantly update that has a chance to break your things. (CMake 4.0 did it and 4.2 did it again, I just want to build Mu͒seScore…) (And other happenings inside e.g. Debian that mean more work for me and/or loss.)

mirabilos Mar 7

@mgorny @dalias and then the whole b/s with calling something that hasn’t had more than one release in the last twelvemonth "legacy", "obsolete" or "unmaintained".

we used to call it well-hung software ("gut abgehangen", unsure if this translates well), robust and something you’d want to build things with.

@mirabilos @mgorny @dalias Stable software that doesn't need constant churning or that is, indeed, finished/complete is underrated.

Source-based distribution helps, as it also means one doesn't need some silly CI tooling just to add the newer runtime bugfixes or whatnot.

@lispi314 @dalias @mgorny @mirabilos There's absolutely no technical reason for software to be constantly changing, instead it's all just a byproduct of economic conditions. If your code is "finished", then there's no more need for you in the company, which means you get fired and fuck you for wanting to afford surviving. Or, on the flip side, if a company sells software, they need constant changes to justify charging for it over and over again with new editions (as was the case in the past) or SaaS subscriptions (as is mostly the case now), as well as to have "innovation" to show to investors so they keep pouring money in. Does software sometimes need to change for technical reasons? Sure, but not constantly like we're seeing, especially from corporate software.

Cassandrich Mar 7

@reiddragon @mgorny @mirabilos @lispi314 This isn't entirely true. There can be real new requirements from changes in the real world and how we understand it, like meeting accessibility needs we didn't understand well before, working with human languages the original authors weren't familiar with, working with new technologies that replaced old extremely resource-inefficient ones, etc. But most updates are just bullshit.

@dalias @mgorny @mirabilos @lispi314 ok but those come irregularly and months if not years apart. The constant updates on a (semi-)fixed schedule that we're so used to seeing have no technical reason to exist.

Cassandrich Mar 7

@reiddragon @mgorny @mirabilos @lispi314 Yep exactly.

@dalias @mgorny @mirabilos @lispi314 and that's exactly the point I made initially, so Idk where the disagreement is

@reiddragon @dalias @mgorny @mirabilos I have Python (lol) programs I finished and which stopped working.

Some of them because of stdlib changes. Some of which happened on minor version changes.

Cassandrich Mar 7

@lispi314 @reiddragon @mgorny @mirabilos Yeah but that's Python imposing gratuitous breakage most likely. Not something fundamental.

@dalias @lispi314 @mgorny @mirabilos actually, some of the changes are quite fundamental, but even if they weren't, they shouldn't have happened on minor releases. The whole point of minor releases is that interfaces don't break

@reiddragon @dalias @mgorny @mirabilos Yeah that's why I mentioned it. It's not supposed to have ever happened.

@lispi314 @dalias @mgorny @mirabilos oh, I've had a bunch of those as well; partially why I stopped using Python for anything serious unless I have no other choice

mirabilos Mar 7

@reiddragon @dalias @mgorny @lispi314 yeah, and PHP started doing it as well. I really need to learn Perl properly.

Taran Rampersad Mar 7

@mgorny 1/ this is an outstanding writeup.

I miss the days of just me and a gnucc hacking some code out to solve a problem.

The changes started right around when OSI did (correlation, not causation). Ballmer was still shouting about developers so companies would be stuck with legacy code that tied them to Microsoft.

First it was all the different licenses.
Then it was all the new languages that everyone wanted to do something with and left orphaned legacy code.

And yeah, at the same time...

Taran Rampersad Mar 7

@mgorny 2/ ... work did get worse because of all the shitty ms legacy codebases and ms dbas I wanted at times to strangle.

.net was supposed to bridge, and it just became more crap with mono.

So while you're trying to handle new frameworks and some legacy code, companies sold out adap to get out from under it. Suddenly, you need to know new frameworks.

Sisyphean churn.

Yup. That's the tension. Straddling all that crap.

///

Matt Campbell Mar 7

@mgorny I have a question about the section on Rust. You wrote, "Rust went against so many principles I believed in." Which principles?

I don't want to start an argument. I use and like Rust, and I wouldn't want to give it up, but I also want to be sensitive to things that are causing burnout among distro maintainers. I'd just like more detail about what principles you believe Rust went against. Thanks.

Jesus Michał "Le Sigh" 🏔 (he)Mar 8

@matt, dynamic linking (saving memory and build time), packaging every dependency separately (you can't do that when packages have hundreds of dependencies that are being updated all the time, and it makes no sense anyway if you can't reliably link dynamically), support for older/more exotic hardware (admittedly, that's technically doable, but you need lots of time and expertise, and it doesn't help that Rust *and* LLVM are in constant churn; gccrs *may* help here).

Marcin Cieślak Mar 8

@mgorny Tried #Ada already? @matt

degenerating degenerate Mar 8

@mgorny Well my observations over the years are that nobody is going to give FOSS maintainers any money, unless you're in a clique. So it's moot if it would help or not.

The section on coding assistants is a self-inflicted wound though. If you spent half a day with https://antigravity.google (it's usable for free but very ratelimited) and your own code on your own machine, with your own choice of tasks, you would not write it off as "slop".

Google Antigravity

Google Antigravity - Build the new way

Google Antigravity