Burnout epidemic proves there's too much Rust on the gears of open source
Spotting and tackling a widespread problem is a challenge
Open source burnout has reared its head once again, this time in relation to the Rust project. However, the issue is not new, nor are the solutions.
A lengthy blog post last week by a senior Rust engineer, Jynn Nelson, documented the problem, saying: "The number of people who have left the Rust project due to burnout is shockingly high.
"The number of people in the project who are close to burnout is also shockingly high."
The Rust project began as a side project at Mozilla and is currently supported by the Rust Foundation. It's an innovative language and, according to 2023's Stack Overflow developer survey, the most admired by developers.
However, it also has an all-too-familiar problem and an all-too-familiar pattern as far as contributors are concerned.
An engineer is keen to work on the project, opens up the issue tracker, and finds something they care about and want to fix. It's tricky, but all the easy issues have been taken. Finding a mentor is problematic since, as Nelson puts it, "all the experienced people are overworked and burned out," so the engineer ends up doing a lot of the work independently.
"Guess what you've already learned at this point," wrote Nelson. "Work in this project doesn't happen unless you personally drive it forward."
The engineer becomes a more active contributor. So active that the existing maintainer turns over a lot of responsibilities. They wind up reviewing PRs and feeling responsible for catching mistakes. They can't keep up with the PRs. They start getting tired ... and so on.
Burnout can manifest itself in many ways, and dodging it comes down to self-care.
While the Rust Foundation did not wish to comment on the subject, the problem of burnout is as common – if not more so – in the open source world as it is in the commercial one.
- Ransomware attacks hospitalizing security pros, as one admits suicidal feelings
- Infosec pros can secure IT, but have harder time securing job satisfaction
- Quarter of tech pros say they're considering quitting jobs in next six months
- Bosses face losing 'key' workers after forcing a return to office
Patrick McFadin, VP for developer relations at DataStax and an Apache Cassandra committer, told The Register: "The problem can be the 'If I don't do it, nobody will' mindset. 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.
"The result is the classic 'tragedy of the commons' problem in many OSS projects where lots of people benefit, but not enough pay things back."
His advice is similar to Nelson's, who suggested documentation for dealing with burnout was at least as important as handling technical issues of moderation conflicts. "Spend way more time on coordination and project planning than you think you need. Then do more. Don't let individuals feel like it's all on them."
Dave Stokes, a technology evangelist at Percona, also noted the risk of burnout in open source communities. He said: "In the case of the solo or small team project, there is often a lack of team depth to spread the work or tackle emergencies. Many projects are part-time, after-hours endeavors that impact family or personal time.
"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."
Stokes also noted the difficulty in spotting the signs. "It would be nice if tools like GitHub could check on the developers as they commit code. However, communities have to self-police, which is next to impossible in this remote world."
Stokes concluded by praising the quality and consistency of code produced by the various open source communities.
"Big projects like PostgreSQL deliver extremely complex new versions that consistently perform better than their predecessors each year."
But at what cost? ®