[sph]

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

[seagreen]

> Open contributions project.

That's a useful distinction and a good term.

So in total projects can be classified as:

    - Source available or not
    - Open source or not (a subset of source available)
    - Open contributions or not (also a subset of source available)
    - BDFL or community driven

That's a lot of variation and may explain why so many conversations about open source sound like people are talking past each other-- they're talking about different kinds of projects!

PS: Regarding:

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

I wish there was a standardized way of declaring this, I always feel so awkward writing the "no PRs" disclaimer on my toy projects.

[marcosdumay]

> That's a lot of variation and may explain why so many conversations about open source sound like people are talking past each other

Most of the discussion is people suffering through GitHub-style social networks. I don't see a lot of people talking through each other, as much as I see people assuming this is the way, and others pointing out it's just one option.

At some point we have to acknowledge that GitHub is a toxic social network. The toxicity is way more hidden than Facebook and others like it, but it's there too. Every universalist social network is toxic.

[delfinom]

GitHub is absolutely toxic which is why we develop on GitLab instead. The reduction in the slowly creeping "social features" and non-existence of drive-by activism is great.

[sph]

Gitlab's approach to the problem is making every UI redesign even worse than the one before, so people have to click through 3 menus just to file an issue.

The latest redesign is egregious to say the least.

[berkes]

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.

[ninkendo]

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?

[berkes]

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.

[ninkendo]

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

[andrewaylett]

Because the known system effect means that the more arbitrary developers engage with them, the more likely it is that at least some of them will drive corporate adoption and, by extension, sales.

Tailscale put it well: https://tailscale.com/blog/free-plan

> increased word-of-mouth from free plans sells the more valuable corporate plans

[ninkendo]

Why is it a given that GitHub slowing me down by making me engaged with the site more, will make me spread more word of mouth/etc? Everyone in this thread is just assuming a link here, but I don’t see it at all.

GH annoys the shit of me by making me click more shit to get my job done, it “increases engagement”, and then… what exactly? My annoyance is supposed to lead to me… thinking about GitHub more? And thus I’ll pressure my org to use it?

This makes no sense. I hate engagement-based metrics as much as the next person but I’m not sure MS is as brain dead as to intentionally make the UX worse, to make engagement higher, and assuming that will somehow increase sales. There’s no link here.

[alwaysbeconsing]

It means they keep position as dominant Git forge, mindshare: people are most familiar with them, then think of them first for Enterprise contracts, are interested in other paid product/feature (Copilot e.g.).

Side benefit to overwhelming mindshare many people expect/require the other forge to have the Github feature: being different counts as negative. This reinforces.

[barkingcat]

by hijacking the git moniker. most college students think of github before they think of git itself.

that brand power is worth billions.

[sph]

If anyone is getting promoted based on Github engagement metrics, you better believe that's what PMs are gonna optimise for.

[twp]

For an example of GitHub enraging its users and ignoring all feedback see the feedback on the new feed:

https://github.com/orgs/community/discussions/13130

https://github.com/orgs/community/discussions/65343

The feedback is overwhelmingly negative, and has severely disrupted many people's workflow, but GitHub doesn't even acknowledge the problem.

[delfinom]

It's enshittification. The same way LinkedIn is being turned into ...generic social media, GitHub is slowly being eaten away into serving some executive's delusions.

[throwaway17_17]

I would assume, in the context of Microsoft encouraging engagement (specifically the PR feature of GitHub), the more engagement they have the more code is put into their system, thereby allowing them more data to train Copilot and other ML models.

[cozzyd]

conspiracy theory:

GH is Microsoft's ploy to kill open source once and for all by facilitating burnout.

(obviously false, but entertaining to think about)

[voakbasda]

What makes it “obvious”? They tried to kill Linux and Open Source. I will never forgive them, and I sure as hell would never trust them not to try again.

[cozzyd]

Such conspiracies are hard to hide, so it seems quite unlikely to me (and GH was sort of like this before the MS acquisition, no?)

[workingjubilee]

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.

[jackcviers3]

Github marketplace has a close pull request action[1].

You also need to close issues after a set amount of inactivity[2].

If there is a bug without a CVE, or a feature someone wants fixed that users don't want to submit a fix for themselves AFTER it has been discussed with the maintainer in an issue with a replication or strawman proposal and the owner has created a draft pr and asked you to work on it, it probably needs to come with a Patreon donation[3]. This can help alleviate maintainer burnout by allowing the maintainer to hire someone to make the contribution.

A software shop wouldn't operate without some kind of iterative plan. Large open source projects with single maintainers shouldn't either. Scheduling 1 or 2 hours a week for issue triage, hosted in an online meeting, and limiting WIP in terms of open PRs to be discussed during this triage meeting should allow for both community interaction and strong governance for the project and prevent burnout for the maintainer.

All of this can be placed into the Readme or Contributor guide and a CLA that contributors have to sign.

Otherwise, people can fork and maintain the project themselves.

If you want to prevent flame wars, or demotivating comments, something like a comment sentiment analysis app[4] might even be a good idea to add to your project. There are plenty of models available that you can delegate to for this in the wild, and it's worth automating moderation to prevent burnout.

Finally, really toxic users can and should be banned[5]. It's not worth it to deal with anonymous negative contributors all the time.

1. https://github.com/marketplace/actions/close-pull-request

2. https://github.com/marketplace/actions/issue-triage

3. https://github.blog/changelog/2023-10-03-sponsor-projects-th...

4. https://github.com/marketplace/comment-sentiment-analyzer

5. https://docs.github.com/en/communities/maintaining-your-safe...

[delfinom]

The point is Close Pull Request shouldnt be an action. It's should only be a bool in some database column for project settings that turns off the entire functionality.