zlacker

>>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.

>>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.

>>sph+G8
I strongly believe GitHub has the same dynamics as most "big tech social media". Where anything that drives "engagement" gets prioritized. From algorithms that make alt-right/neo-nazi's more visible because the controversy drives "eyeballs" to features that are removed or never implemented because they would lower engagement.

I'm confident that GitHub has a good prediction on what will happen if they roll out features that lower the burden of maintaining a FLOSS repo. And am rather certain that several of these features also lower the engagement. And therefore will not be implemented. In other words: the needs and goals of GitHub/MSFT and those of Open Source maintainers don't align perfectly. Yet the power balance is way off, so open Source maintainers will experience pain to a level that they almost walk away in great numbers.

>>berkes+ld
It would be a baffling decision for GitHub to make any product decisions based on engagement. They don’t even serve ads, what benefit do they have to an engaged user?

>>ninken+Am
Engagement isn't just driving ads. It's driving engagement: The "toothbrush"-factor we called that in app-development: do you have an app that people pick up like their toothbrush: without much thought, several times a day?

Engagement means people have you in their workflow, on their radar. I would love it if Github is something that I don't have to think of, that is invisible and out of my mind. I'd love it if it's something I never have to visit, open, see or interact with; as as little as possible. I'd love it if it were preconfigured to take work from me rather than impose yet another inbox, timeline, bookmarks, "likes" and so on.

And if you consider "advertisements" very liberal, that's exactly what Github is: a place for companies to attract eyeballs and engagement on their software.

>>berkes+rq
I think I know what engagement is, but I’m wondering why you think Microsoft benefits from me being engaged with GitHub?