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

Leer en español

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:

  1. Clone the repository.
  2. Create a branch.
  3. Make your changes.
  4. Generate a patch with git format-patch.
  5. Send it to my email, preferably using git send-email, and using a template for the subject and body of the message.
  6. 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. That casual "drive-by" is valuable and necessary.

But I don't maintain the Linux kernel, I maintain small projects, alone, with little time.

When you are a team of one, your scarcest resource is the attention you give to whoever wants to contribute.

Every empty issue, every patch that doesn't compile, every "it doesn't work" with no context, costs me a while that I take away from writing code, from my family or from rest. I am the triage. Protecting my time is protecting the quality of my projects. Still, I'm not hiding in a cave, there is a door to knock on. There is a document with a few simple steps that anyone can follow to contribute. But it takes your attention and your time.

Conclusion

I no longer have to chase and push Issues that their author walked away from the moment they opened them. I no longer have to read a Pull Request where someone changed a couple of lines while having a coffee and never tested them. I get 2 or 3 patches a week, all of them with context, explained and tested. And if I need more information, I have the author's email to ask.

Now everything is more personal and human.

Sources

This work is under a Attribution-NonCommercial-NoDerivatives 4.0 International license.

Help me keep writing

Every coffee gives me a push toward the next article.

Ko-fi donationsSure, it's on me!

Comments

There are no comments yet.

You may also like