Given that open source is a side project for so many people, it seems this is also a natural side effect of how much the software engineering community has been rattled by big changes in the market (at least on the US). As much as I appreciate contributions to much of the tech I love to use, I would certainly want folks to prioritize what's critical to their livelihood and well-being. There's a lot of cognitive load already on people lately.
I'd have thought with so many people on severance and no work, some people will contribute even more to open sources while grinding up for next job too.
I contribute a lot to open source, and it pays off less than you think, and is often only appreciated by people who also contribute, which is a minority.
I contribute to open source the most when I'm between jobs. I generally enjoy doing it a lot, and I'd like to more, but... Family, job, wanting to be away from a screen... It's not really doable when I'm employed.
I wonder how much of the burnout is due to the big companies laying off people. A lot of open source developers have been affected. Seeing these companies use the open source products they worked on and then laying them off while they make big profits has got to be pretty disheartening.
> It can be a grind working on a project where everyone is mostly independent but coordinated. Most OSS projects have no project management or support staff to help. In fact, most projects frown on companies providing that service to a project because it looks like control.
> "It is often hard for those working so hard to say no. Many find it hard to self-monitor for burnout and few know how to step away without full decoupling."
This should give a hint towards a solution: add some support stuff to shield off the developers (of course these people are not authorized to issue directives to the developers - we are not at a commercial company).
Offering commercial support doesn't really help unless developers also take a hard stance at that point and immediately close all filed issues that aren't bugs.
I do see that happen alot in OSS, too many people use issues as help forums and too many people enable it.
> Offering commercial support doesn't really help unless developers also take a hard stance at that point and immediately close all filed issues that aren't bugs.
I am not sure whether such a hard stance is necessary. Why not rather strongly deprioritize filed issues that are not bugs (i.e. it will be left open, but only worked on if ressources are available, which might be months to years)?
Clogs the priority queue with trivial comparisons that are still necessary to make. If its really valuable it will come up again until a person that really does need it pays for it in labour money and so on. The issue can be archived and made a live option again anyway.
Quality of life improvements fall by the wayside in this model, but that is a separate degree of motivation.
Hello Hacker news, feel free to fight me on this, just understand that you're wrong and I'm right; the number one way to stop burnout on a project is: stop breaking backwards compatibility.
For reasons I cannot quantify or qualify, projects that go through rapid transformation and repeatedly break compatibility with themselves burn like comet, bright and intense, before everyone jumps ship to the next hot thing.
Projects where people stick around know that real world users depend on them and they cannot change simple things like I dunno... renaming the boot drive from /boot to /bootfs (yep, looking at you Raspbian, and yes, that was fucking stupid). Everyone reading this thread will be outlived by a COBOL program running on ZOs, but their ridiculous node contraption will be forgotten by next year (and it won't build next month anyway).
Causation/correlation/selection bias... I think the simplest thing wins, which probably already is done
