It's cool to see such an impactful project choose sovereignty. I hope more projects follow their example.
If you're a backbone-of-the-internet project like FFmpeg is, living on GitHub seems horrible. You will be subjected to thousands of low quality pull requests and issues from people searching for typos to fix, adding a line of white space for a contrived reason, or similar nonsense changes. Just so they can put "FFmpeg contributor" on their CV (or whatever).
Rejecting useless or white space-only PRs is quick and easy. It’s not as big of a problem as you’re suggesting.
I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements.
It’s all in the approach: start with a “thank you for the project”, and a “hope you don’t mind but I’ve corrected a few typos” and nobody will shout you down. Only go with a blank PR description and it’ll come across as arrogant and spammy.
As a maintainer of a few open source projects, yes it happens a lot.
I want to believe some people just want to send small patches to projects when they notice something (I tend to do the same for projects I use) but my impression is a lot of them do it so that it shows up as "contributions" on the GitHub profile which they can then add to their resume (or get some other kind of street cred).
At least typos are actual fixes, far more often you get complete spam (people copy-pasting the contents of PRs and issues from 5 years ago, sending bizzare pull requests with hundred of commits as a merge commit, leaving cryptic comments on 5 year old commits). The spam reporting process on GitHub is kind of annoying to go through, but I trudge through it every time we get one of these PRs. There was one year of Hacktoberfest where some streamer told people that if they just spammed projects with 5 PRs they would get a free shirt and every open source project was DoSed by hundreds of garbage PRs made by accounts created the same day.
Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)
> Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)
I have to disagree, changes to development processes are the worst kind of drive by contributions. I don't want CI jobs contributed from someone who isn't going to maintain them.
I mean, I would prefer that it be done as part of a discussion with upstream but if you're talking about a GitHub Action it's not really that much effort to maintain in my experience.
But even if adding CI jobs is not the preference of upstream, I would prefer that the contributor runs codespell locally and fixes all of the issues rather than just sending one-line patches. And I can imagine much worse forms of drive-by contributions than CI jobs that you can easily disable in the future.
I fix documentation typos or broken links because they really annoy me. There are some egregious examples of people doing it for GitHub-as-a-social-network reasons, but I think some are like me and just want to fix the writing.
I always start with a small patch to test the waters of a project. That way i dont waste my time with a larger patch if the project is a PITA to contribute to.
I similarly contribute only minor language and writing corrections to Wikipedia, and usually anonymously (unless my phone has randomly pulled a blocked IP and I need to sign in). I don’t consider myself enough of an expert in any Wiki-worthy topic to do anything more, but I’ll make damn sure small mistakes get addressed.
I feel even less qualified to contribute corrections on GitHub mostly for the same reasons mentioned above. Staying anonymous prevents anyone from thinking I’m attempting to capitalize on low hanging fruit.
There’s also a couple of video tutorials that show how to make a pr, using node or nom on GitHub, and people just follow the tutorial verbatim, not thinking about what they’re actually doing.
> Rejecting useless or white space-only PRs is quick and easy.
No, it really is draining.
> I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements.
It's frustrating when people make "contributions" that take more effort to review than they put in and then get mad when they don't get thanked for it. This attitude is exactly why dealing with drive by pull requests is not "quick and easy" - suddenly you need to do social and public relations stuff when all you want to do is code.
This issue has only worsened with LLMs "assisting" contributors in submitting PRs that end up wasting maintainers' time.
Tools like OpenAI Codex, which can connect directly to repositories, are likely to amplify this problem even further.
That said, this is also the real measure of the actual value of LLMs and coding agents: the day we see top open-source projects having dozens of bugs effectively fixed per day by LLMs, we’ll know they’ve matured into a solid, reliable resource.
In my previous work we were strict about typos, whitespace and general consistency in reviews. And even fixed them later if they slipped through. I found it a bit ridicolous a times.
In my current company nobody cares. It can be seen in the whole code quality. Full of smaller and bigger bugs as well as horrible hacks. It can be seen whether coders look twice or more at their own stuff before putting it to review or not, just trying to avoid ridicolous comments. It's a whole attitude. I write good code in a messy source base is unlikely to work in practice.
That said, I have submitted cleanup commits to open source projects only in the same MR with a real code change I wanted to make and only in vincinity of that change.
FFmpeg seems to have dealt with that problem when they still were on github. This is the paragraph at the end of the readme:
> Contributing
> Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email. Github pull requests should be avoided because they are not part of our review process and will be ignored.
An agentic LLM bot is likely to have no problems at creating a patch and mailing it but it's a major pain for most human developers. Furthermore they can ban source email addresses and vet potential contributors before letting them in the mailing list.
(I work on a project that uses an email workflow. "Should we switch to something else?" is a perennial topic.)
I think the main pain points are:
* unfamiliarity -- if you're not already set up then it's extra admin work. And the "obvious" approach (paste the patch into your usual email client and hit send) generally mangles the patch.
* developers are no longer largely using local plain text based email clients -- if you are already doing email that way then sending patches like that is a natural extension. If your email client is gmail, or worse still some Microsoft mail server, now you have to figure out how to send email in a way that's not html and doesn't get mangled by your mail server.
* how to set it up is not a single well documented path. Github has an incentive to do a decent tutorial/docs, and how to create an account and send a patch is the same for everyone. Using git send-email, there's a lot more variability: how to install it depends on your OS, and how to configure it to talk to your mail server depends on your mail server. In these days of two factor authentication and app specific passwords, it's no longer as easy as "put the server name and your account name and password into the config file".
This has got better in that now you can point people at e.g. https://git-send-email.io/ which has info on e.g. setting up gmail app specific passwords and what kind of authentication to use.
If you're a regular developer on a project, this is a one-time pain and thereafter sending patches is straightforward (assuming you're not totally allergic to the command line). But for one-off or first time contributions it can be a barrier.
If you are ignoring all of them. Filtering PRs to see which are worth having might take time in a large popular project. Even if it isn't much time, it is more than zero. You also have to deal with all the other comms associated: people submitting genuinely useful patches which accidentally get rejected querying (maybe politely, maybe not) and people who submitted less useful ones bitching about their rejection, both to the project and in public forums.
Another way to frame this is that even though the FFmpeg repository clearly indicates it's a mirror repository and has had a single open pull request titled "WARNING: PULL REQUESTS ON THIS REPOSITORY ARE IGNORED" [0] sitting in the pull requests page for 10 years, they've still had to close hundreds of pull requests.
That’s fair, but it would be trivial to use GitHub’s actions/API (and probably just an existing open source tool in either case) to automatically close them without anyone wasting their time.
I think you’re definitely right that being a massive project on GitHub that accepts PRs there would be a nightmare though.
If you're a backbone-of-the-internet project like FFmpeg is, living on GitHub seems horrible. You will be subjected to thousands of low quality pull requests and issues from people searching for typos to fix, adding a line of white space for a contrived reason, or similar nonsense changes. Just so they can put "FFmpeg contributor" on their CV (or whatever).