the rust project has a burnout problem (
from to on 18 Jan 2024 10:15

#rust on 18 Jan 2024 15:44 next collapse

Thanks for the post!

I’m obviously not the target audience, but I really like the idea of treating maintaining a FOSS project as a job. Fix how much time you’ll spend on it, set expectations, etc, and remember that you can quit and rejoin at any time (just notify the rest of the team that you need a break).

I appreciate all the hard work Rust maintainers put in, and I wish I was in a position to help out (I’d just get in the way). Please take the time off you need, the Rust project is in a good spot right now and new things can wait. on 18 Jan 2024 16:38 next collapse

I wish I were more aware of what level of burnout there is in other large open source projects. Is Rust unique? Better? Worse? How do other projects manage this (if in fact they do)?

Projects like GCC and the Linux kernel do almost all their development in the open, via mailing lists, so maybe it would be possible to analyze that data to determine, say, the rate at which contributors drop out of the project. But I’m not aware of anyone having actually done an analysis like this. on 18 Jan 2024 23:30 collapse

Aren’t those two projects mostly maintained by people on the job? I don’t know what’s the proportion for the rust team, but I think it’s getting much less sponsoring. Hopefully this will get better quickly on 19 Jan 2024 03:17 collapse

I don’t know, but historically, for GCC at least, I wouldn’t expect so, because it’s so ideologically anti-corporate. on 19 Jan 2024 07:38 collapse

That’s a hell of an assumption. I know a number of Arm GCC and LLVM hackers who are all employed by various companies including Arm themselves. It’s in chip designers/manufacturers interest to have good GCC support for their architecture. on 20 Jan 2024 03:07 collapse

Of course hardware vendors have a vested interested in GCC support, and of course there are a lot of people paid to work on GCC! But the claim above was that GCC and Linux are “mostly” maintained by people paid to work on them. I don’t actually know how to measure that (I thought I might be able to find a quick answer by googling, but no such luck), but even if it’s true now, I seriously doubt it’s been true for the majority of GCC’s very long history.

I also specifically didn’t mention LLVM because it’s very closely associated with both Apple and Google.

The other claim was that fewer Rust maintainers are paid to work on Rust. But there are in fact quite a few people paid to work on Rust full time, and there have been throughout its history; most obviously at Mozilla, but even though Mozilla has since let go of its Rust language team, Amazon has a significant team of Rust maintainers (several of them from Mozilla), and I believe Facebook, Microsoft, Intel, and possibly Google do as well.

So as far as I can tell, (early) GCC, Linux, and Rust all have a mix of paid and unpaid maintainers. on 20 Jan 2024 12:33 collapse

I added gitdm stats awhile back although the mappings could certainly do with some clean-up. For the last year of activity the stats are:

Top changeset contributors by employer
Red Hat                   1807 (17.6%)       814 (7.9%)
AdaCore                    795 (7.8%)
ARM                        778 (7.6%)
SUSE                       649 (6.3%)
Intel                      475 (4.6%)
Code Sourcery              366 (3.6%)
Automatic Admin            360 (3.5%)  347 (3.4%)
IBM                        201 (2.0%)

Top lines changed by employer      1392979 (25.9%)
SiFive                    1236220 (23.0%)
Code Sourcery             676611 (12.6%)
Red Hat                   416369 (7.8%)
ARM                       309116 (5.8%)       300270 (5.6%)  174876 (3.3%)
Automatic Admin           160200 (3.0%)
Intel                     86657 (1.6%)
AdaCore                   60414 (1.1%) on 20 Jan 2024 21:01 next collapse

I didn’t know about gitdm; that’s a handy tool! Looks like those are just based on the domain of the email addresses used for commits, so it doesn’t necessarily indicate whether the company employees people specifically to work on GCC. But I think you’re right, that does indicate quite a lot of corporate support for the project. on 20 Jan 2024 23:44 collapse

The gitdm scripts come from LWN who do a regular “who writes the kernel” report but can work on any git repo.

You can be fairly certain that patches coming from a corporate domain are paid for their time. You can add extra metadata to track people who use personal or org addresses if they confirm it’s a paid gig. The project I work on most is about 75% paid contributors with hobbyists and academics making up the rest. The good unpaid contributors can often get hired if they want to be. on 21 Jan 2024 02:58 collapse

Sorry, what project is this? GCC? on 21 Jan 2024 07:17 collapse

Sorry yes this was GCC, I can do the same for the rust repo if you want. on 22 Jan 2024 02:41 collapse

That would be helpful! Thank you. on 22 Jan 2024 10:46 collapse

It looks like a lot of mappings need adding as most people come up as unknown:

EDIT updated with newer mappings.

Top changeset contributors by employer
(Unknown)                 11190 (62.7%)
(None)                    4280 (24.0%)
Huawei                     862 (4.8%)
Ferrous Systems            630 (3.5%)
Academics (various)        563 (3.2%)
Red Hat                    124 (0.7%)
Google                     102 (0.6%)
Microsoft                   59 (0.3%)
IBM                         28 (0.2%)
Funky                       11 (0.1%)

Top lines changed by employer
(Unknown)                 1018418 (56.9%)
(None)                    484385 (27.0%)
Academics (various)       118247 (6.6%)
Ferrous Systems           100533 (5.6%)
Huawei                    45443 (2.5%)
Red Hat                   16009 (0.9%)
Microsoft                 3359 (0.2%)
Google                    2844 (0.2%)
Funky                      447 (0.0%)
IBM                        388 (0.0%)

the top contributors over the last year were:

Developers with the most changesets                                                                                                                                          
Michael Goulet            1027 (5.7%)                                                                                                                                        
Nicholas Nethercote        789 (4.4%)                                                                                                                                        
Ralf Jung                  763 (4.3%)                                                                                                                                        
Camille Gillot             727 (4.1%)                                                                                                                                        
Lukas Wirth                640 (3.6%)                                                                                                                                        
Guillaume Gomez            583 (3.3%)                                                                                                                                        
bjorn3                     550 (3.1%)                                                                                                                                        
Oliver Scherer             470 (2.6%)                                                                                                                                        
Michael Howell             293 (1.6%)                                                                                                                                        
Waffle Lapkin              266 (1.5%)                                                                                                                                        
Esteban Küber              251 (1.4%)                                                                                                                                        
Zalathar                   249 (1.4%)                                                                                                                                        
lcnr                       247 (1.4%)                                                                                                                                        
y21                        221 (1.2%)                                   on 21 Jan 2024 17:09 collapse

I used to work at a company that held to the concept of “don’t be a hero.” Basically, if you were having to step up, work overtime, and always go out of your normal routine to “fix” stuff, then you’re actually enabling bad processes.

I think the same concept applies here. If you can’t let any code be submitted without personally reviewing it, then there is something wrong with either the review system, the onboarding system for new devs, or the continuous integration system that should be catching mistakes. Same goes for triaging: if no one is triaging because it’s too exhausting and leads to burnout, then some other system may need to be devised for handling outstanding issues.

Obviously this is much harder to deal with in an organization where most contributors are volunteers. But if we want the project to survive and not be taken over by corporations who can afford to pay people to deal with this stuff full time, I think it should be addressed in a different way.