I closed pull requests and issues on my projects, and I'm happier | Andros Fenollosa

Skip to content

A while ago I started moving my projects off GitHub, GitLab and Codeberg to my own Gitea instance. Doing it takes courage, because you cut yourself loose from social networks for programmers with huge visibility, interaction and reach. Forget about stars, followers, forks, trending lists and the rest. All you have left is the code, and maybe the people you let in. And yet, I am happier than before. Thanks to friction, the quality of contributions has gone up and the projects are relatively easier to manage.

Reading contribute is no longer optional

You can no longer click a button to open a Pull Request/Merge Request or Issue. All my projects share the same contribution guide. A series of steps that boil down to:

Clone the repository.

Create a branch.

Make your changes.

Generate a patch with git format-patch.

Send it to my email, preferably using git send-email, and using a template for the subject and body of the message.

Wait for me to read it and reply.

Now my email is the only channel of communication.

I also include a few good practices that are basic but worth a reminder:

One patch = one logical change

Test before sending

Write clear commit messages

Be patient with maintainers

Accept feedback gracefully

The friction is huge! I ask you to read a guide, to be reasonably comfortable with Git, and on top of that to have it set up to send email. That last step looks like a grumpy old man's whim, but it has a technical reason. git send-email talks directly to the SMTP server and places the patch as the body of the email in plain text, with the correct encoding. A webmail client (Gmail and friends) tends to rewrite line breaks, turn tabs into spaces or change the encoding. The patch reaches me byte for byte, exactly as the author generated it.

But what do all those extra steps buy you? They make you want to ignore the project altogether.

Friction is not a bug, it's a feature

For decades there was a natural barrier in free software. To send a patch you had to understand the code, clone it, make the change, read documentation, test it and know how to explain it. Whoever goes through all that shows real interest in the project: their issue genuinely matters and their patch is worth reviewing line by line.

It also rewards the contributor enormously. After exchanging several emails, adjusting your patch, aligning the code with the project's conventions, refining the patch with the maintainer's feedback, and... in the end it gets accepted: you don't feel like you fixed a bug in someone else's project, you feel like you are part of it. That your effort has been valued and that your time was worth it. You might even keep contributing, no longer out of need, but for pleasure. A bond has formed between the project and you.

I remember fondly some patches that dragged on for months and were accepted in the end. In fact, one of them is about to be approved in a few days after almost eight months! And the best part is that I made a friend along the way. And that is what makes free software great: the people behind it.

None of that happens by clicking a button and changing a couple of lines without leaving the web interface. In fact, you end up feeling a selfish sense that they owe you something!

A relief for maintainers

Maintainers of huge projects are suffering the tsunami of AI-generated Pull Requests and Issues:

curl went as far as shutting down its bug bounty program. By mid-2025, only 5% of the reports were real vulnerabilities and around 20% looked AI-generated. Daniel Stenberg described it as a "DDoS" against maintainers.

GitHub already talks about an "eternal September" of open source and has started putting limits on the number of Pull Requests to cut down the noise. They are building features to archive and hide low-quality contributions.

According to CodeRabbit, AI-generated Pull Requests carry 1.7 times more problems than human-written ones. And they arrive in far greater volume.

AI sped up writing code, but it did not create more senior reviewers. The cognitive work of reading, understanding and deciding still falls on a person. I'm not saying you shouldn't use AI to write code, hunt for bugs or understand a codebase, let's not kid ourselves, it's an excellent tool, but I do ask that behind it there is an experienced human responsible for managing the contribution. If you can't explain the patch, don't send it. If you can't explain the bug, don't report it. If you can't explain the change, don't propose it. Otherwise, the maintainer will notice in the very first email.

You're scaring off the beginner

Yes, it's true. GitHub's Pull Request was invented in 2008 precisely to lower the barrier for strangers, and it worked: it multiplied participation. And there is a long line of academic literature on how that technical barrier makes many people abandon their first contribution....