zlacker

[return to "The Rust project has a burnout problem"]
1. markph+H4[view] [source] 2024-01-17 13:10:46
>>Philpa+(OP)
This is a good description of what life is like working on almost any significant open source project. The only thing not included was the comments from overly entitled users that saps whatever morale and energy you have left. Probably best he did not include that though as that is what all discussion would be about.

I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them.

Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.

◧◩
2. Waterl+A7[view] [source] 2024-01-17 13:27:01
>>markph+H4
> I am not sure what to do about the burnout problem.

Pacing and self-regulation. It’s a marathon not a sprint. Set an hours-per-week budget. Beyond that things just don’t get done. That’s okay.

If the community needs faster pace, they can consider supplying hours or dollars to fund more developers to work full-time.

◧◩◪
3. markph+78[view] [source] 2024-01-17 13:29:31
>>Waterl+A7
I should have clarified, I meant I am not sure what an OSS Project can do about it. I think this ultimately has to be managed by the OSS contributor.
◧◩◪◨
4. Waterl+x8[view] [source] 2024-01-17 13:31:26
>>markph+78
Ah yes. I wonder if an OSS project should set forth a time budget in some way? Hard to “enforce” though. And goes counter to wanting contributors to feel free to contribute on their terms.
◧◩◪◨⬒
5. bombca+ce[view] [source] 2024-01-17 14:00:00
>>Waterl+x8
The best I’ve seen is have additional contributors (often who just like the project but aren’t coders themselves) who run interference for the dev team. They can triage feature requests, filter out the spam and repeat issues, etc.

Also, and this can be the hard part, is sometimes you have to have someone who (even politely!) can be a bit of a dick when necessary. People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear.

Also having a defined procedure for “hiatus” helps quite a bit - make it easy for a dev to say “I’m off” and it can be indeterminate - this allows them to easily come back later. Encourage devs to use it liberally.

[go to top]