I’m worried about developers’ health. And, I’m worried about the long-term viability of open source software.
Part of the reason why I like Gemini is that it is easier to use and, I hope, easier to maintain.
Hector Martin, project lead of Asahi Linux, resigned from that effort early Friday, Japan Standard Time, citing developer burnout, demanding users, and Linus Torvalds’s handling of the integration of Rust code into the open source kernel.
“Burnout” in the open source community is a long-standing issue and it can be attributed to fairly obvious sources of stress, such as verbal abuse, lack of recognition for volunteer work, or work overload. It can also be complicated, particularly to the extent that online interactions become personal and intertwine with daily life.
“Our recent State of the Software Supply Chain report found that the update frequency of open source software projects have stagnated or decreased since 2020, indicating burnout or resource shortages among these not-for-profit publishers,” [Brian Fox, co-founder and CTO of Sonatype] said. “By 2024, more than 300,000 projects had slowed or halted their update release cadence.”
Sadly an all-too-common issue; lots of demands and expectations without the consideration of the people working to make them happen. Hopefully Hector gets some respite.
I honestly can’t imagine having the motivation and dedication to work on a free software project for years, let alone decades like some developers have done (e.g. Bram Moolenaar). I have some idea of what it’s like, having read Daniel Steinberg’s book, Uncurled, and it seems like quite the thankless job.
I guess there are things you can do to make it easier, like barely interacting with the community at all and only releasing a tarball once yearly, like the Cinelerra project has done for the past 25 years or so.
It was really quite exciting to get my first patch from someone a few years ago, but I wonder how I’d feel after managing a high-profile project for several years…
Hector Martin was burned out by both the kernel community and the Asahi Linux community, but I’ve read that it’s usually non-programmers that stress free software developers out. Maybe highly technical code forges like Sourcehut, which raise the barrier to entry, is one way to go; essentially limiting interaction to technical discussions from technical people who are likely to have a high understanding of what you do and hopefully some empathy for you.
That empathy seemed to be lacking somewhat in the kernel community; though, I did notice a few people commiserating with Hector on the list.
It can be a stressful hobby, and even a stressful day job. I don’t think the solution is necessarily giving people enough money to do this for a living (though that would be a good start).
What makes free software work so well (in some cases better than proprietary software) is the community, but the community (along with finances) is also the leading cause of burnout for free software developers.
I don’t really have a conclusion to this. It’s sad to see, and part of why I am reluctant to put so much of myself into a free software project in the future.
burnout is certainly an issue that can lead to carelessness or catastrophe (xz debacle) but OSS development is a highly dynamic environment - people come and go constantly
i don’t have any definitive view on the subject, but a quick search yielded…
The open source software landscape in 2024 is defined by several key trends:
Continued growth in adoption of open source software across industries, with increasing numbers of enterprises relying on open source tools and platforms. This is driven by factors like flexibility, cost savings, security, and access to a global community of developers.
In December 2024, GitHub announced reaching the milestone of over 100 million registered developer accounts on the platform.
The Apache Software Foundation (ASF), known for projects like Hadoop and Spark, celebrated hosting over 8,000 open source projects in 2024. This milestone reflects the continued growth in open source collaboration.
Parting Thoughts
At the end of 2024, open source software is thriving.
you know, one thing that may well contrib to burnout and project abandonment is issue tracking - the vast majority of feedback that developers seem to get is related bugs, complaints and feature requests and this can overwhelm a developers enthusiasm for a project, especially if the project is a one-man-show
i try to thank FOSS devs and i’ve often found that they are exceedingly grateful when you open an issue only to praise their effort
a little love goes a long way and i’ve experienced this myself on different projects
In a proprietary software company, isn’t there usually a separation between developers and customer service?
Corporations will do that to have “cheaper people” doing “customer facing” work, I guess. Or if I try to be a bit less cynical for a hot second… folks whose specific expertise is customer service. Open-source developers and contributors might sometimes like engaging on issue queues because it helps them connect with their users and adjust their strategic choices. But, yeah, abuse and entitlement from some non-expert users must be so exhausting and demoralising.
I used to help run a completely free (to users) open access computer and arts lab using recycled hardware and FLOSS (access-space.org - still exists, but in a different form), and I’d respond to entitled grumpiness from occasional users with, “I’m so sorry I can’t do more to help, but you are of course entitled to a full refund of all the money you haven’t spent here ”
I wonder if high demand open-source projects could build teams of volunteers with some technical experience who can provide front-line user support, and liaise kindly and supportively with the developers away from the shitfights of support channels?
One interesting project I’ve experienced is the Pods plug-in for Wordpress. Their core developer is present in their support Slack, but there’s another WordPress dev and friend of his who leads user support and handles most requests (encouraging other experienced users to join in). Means the core dev can keep a lower profile, though will join in to clarify or when something is too interesting to stay out of
I’m happy to share what I’ve learned to those who ask for it, but issue trackers are a cesspool of entitled grumpiness. Github is particularly bad. You don’t see this kind of entitlement on Stack Overflow in my experience. Probably because people asking questions are more afraid of upsetting the people answering them…
And, people getting annoyed enough by bugs or missing features to go to an issue tracker are likely to be in a real bad mood. GIMP is a good example of this. I don’t know how some of the developers can stand sifting their way through comment sections to answer people politely.
If you can convince people to volunteer for it, it’s the way to go. I think they have a setup like that on the GrapheneOS forums.