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. sph+G8[view] [source] 2024-01-17 13:32:09
>>markph+H4
> This is a good description of what life is like working on almost any significant open source project.

Open contributions project.

An open source project does not necessarily have to accept random contributions, issues or hatemail from the general public. [1] They just need to make the source available with a permissive licence, period.

I believe that Linux with its idiosyncrasies in its communication model (mailing list vs the ease of Github, strong dictator running the show) works as a great filter from entitled users, and that's an underrated feature in open source. See also sqlite.

---

1: Yet hell will freeze over before Github lets maintainers turn off the PR tab which would lessen this problem a bit.

◧◩◪
3. workin+uU1[view] [source] 2024-01-17 22:06:20
>>sph+G8
This is a frankly ridiculous assertion given LKML's notoriously toxic history. Part of the problem is that overly-entitled maintainers can be as equally dangerous to actual progress in the project by stonewalling useful code on invented reasons that have never been applied to previous PRs and that the maintainer does not apply to their own commits.
[go to top]