“Patches accepted” is harmful: How to improve your volunteer introductions

“Patches accepted.” It’s one of the most offensive things you can say to people who genuinely want to help with your project.

Why you should reconsider using the phrase

Not everyone is a programmer. Even those of us who do know how to program might not meet your expectations, and we would likely waste hours (or sometimes even days) writing and formatting a patch exactly how you might like it. And even then, we might be rejected again and again.

Instead: You, an expert programmer, could spend a little bit of time to thoughtfully discuss an idea and possibly consider implementing it. All of us who are better at things other than programming could possibly help you out in other ways too.

The pain of perfect patches

Developers often assume everyone should write perfect code in their project’s language, to their coding style (tabs? spaces? how many spaces? K&R? KNF? how many comments? what types of comments?). Thinking that everyone will send you free code exactly how you like it is not only arrogant; it dismisses other contributions.

Software is much more than the code that goes into it

Contribution is more than just patches; design, documentation, marketing, translation, localization, security audits, testing, discussion, and advocacy all are crucial for software to be good software.

“Patches welcome” ends any kind of meaningful discussion for potential other contributors.

Simple solutions: words & phrases

The words we all use matter. There are often special meanings in phrases we choose.

“Contributions are appreciated” is much better phrase to say than “patches accepted”. It’s not only what you say, though — it’s also what you mean, and we all need to shift our mindsets too.

The differences can be summed up simply:

  1. Be inclusive — people can help out in many different ways.
  2. Be thankful — everyone’s time is valuable, and they could choose to spend theirs doing something else entirely. Instead, they decided to talk with you and spend a bit of their time on your project, to try to help.
  3. Community participation is not only about code.

Sometimes you simply can’t work on an idea or fix a bug in your project due to various constraints, such as lack of time, being sick, or even a lack of skill. That’s okay; everyone has moments like these. If you’re up-front with people, they will likely understand and may think of you and your project more highly with the explanation. (Every once in a while, someone else may even see that there’s help needed and jump in because of your pleasant conversation too.)

Conclusion

If initial conversations are handled correctly, it could be the start of a beautiful symbiotic relationship to make your software better.

4 thoughts on ““Patches accepted” is harmful: How to improve your volunteer introductions

  1. I really hope people like Bastien Nocera or Andre Klapper (among others) will read your blog entry and take it into consideration…

  2. For years I have called “Patches Welcome” the OpenSource Cop Out. It came to my attention early on in my involvement with open source that many would rather take the stance of “Do my job for me” rather than doing it correctly themselves.

    Thank you very much for saying what you did in a way that I never have been able.

    – Bob

  3. I don’t mean to contradict you really, but I suppose my experience maintaining Glade as a volunteer can lend some interesting insight.

    Perhaps many maintainers have a different point of view, many other maintainers out there are paid to maintain one or more projects by a company like RedHat, Intel or others.

    However, in my experience, I’ve always needed to be extremely strict about new features I might consider including in Glade, and also the quality of newly contributed code weighs in very much. If I don’t insist on perfect patches, then I’m alone maintaining bugs (occasional patch submitters to _not_ hang around to fix bugs 6 months later after the stable release). Basically to sum it up, more code and more features costs an overhead in future maintenance, and this additional cost can make or break a project completely when it’s 100% volunteer driven.

    Quite frankly, from where I stand as a volunteer, it’s utter nonsense when someone shows up on the list with an idea that they think I should spend my own time implementing. I usually make that clear (if I have the time to properly let people know) in a polite way, to the best of my abilities… but it seems that in some cases people just dont understand how a volunteer driven project can work in the long term.

    So, while I don’t mean to contradict you completely, I hope that you can understand the position we maintainers face. “patches welcome” is something you sometimes need to say to somebody… in order to let them know that if nobody is offering up their valuable free time to actually do it, then it’s just not ever going to be done.

    In the past I’ve made many similar statements, it’s not because I want to discourage new contributors, but because I want people to understand that the project only survives because “you contribute patches”.

  4. The project as a whole needs to have some way of dealing effectively with those who aren’t contributors or who have limited skill, but often core developers don’t have the bandwidth to do that. They are 100% occupied with what they are doing, which is why they ask that contributors meet standards. If you don’t like that, then perhaps the answer is to have a set of volunteers who can sit between the core developers and the users, and funnel and distil all that traffic into some good ideas and some improvements. But developers are human, they can’t do it all.

Leave a Reply