A situation that has arisen several times in open source projects goes like this:

  1. I notice a bug in our deployment, and figure out a quick hack patch. (For example, simply commenting out code that we don't actually need.)
  2. I spend a little bit of extra effort to figure out the real bug, come up with a patch, and submit it via a Git pull request, or similar.
  3. My pull request is rejected. Perhaps the patch was imperfect (eg, included lines it shouldn't have), perhaps it violated coding style, perhaps it had other ramifications. Or maybe I did something wrong in Git - the pull request should have been rebased or something. A maintainer provides feedback about how to improve the patch, and requests that I resubmit it.

At this point I'm confused about how far I should proceed. As far as I'm concerned, I don't have a problem: I fixed it back in step 1. I've reported the issue, I've even taken steps to fix it for others. But I don't feel that it's "my" pull request, so I don't feel that responsibility for improving the patch should come to me.

One particular situation that irks me is after discussion about the failings of my patch, we reach agreement on a mailing list about what the correct patch would be (ie, how it should behave, sometimes including every line of code spelt out). Then, it is still presumed to be my responsibility to actually generate and submit the patch.

Is there a standard etiquette in these situations? How are they resolved? Is my reaction unusual? How far are you expected to go to get your bug fix accepted?

(Note when I say "open source project", some of these are very small, but may not be hobbies - simply small software projects which are of use to several organisations, who commit developer resources to working on them. In case the obvious answer is "fix the patch and resubmit", understand that I have responsibilities to my employer to work on stuff that is of benefit to them. Spending time fixing a bug that doesn't affect us would be wrong...)

6 Answers 6


As far as I'm concerned, if you find a bug or have an enhancement request, are not a contributor to the project, and have submitted a defect report through the appropriate channels, you are done. In terms of giving back to the community, anyone who is using an open source project and finds a defect should report it.

Attempting to find a solution, design it, and implement it is a bonus to the project. If you have done this, it might be a good idea to submit it, either via a pull request or perhaps sending file deltas to the development team along with the defect report or enhancement request to give them something to work with. However, they are under no obligation to accept your contribution to the project.

Expecting a user to contribute patches seems wrong, to me. It's fairly easy to participate in a discussion about a problem, but it's a much larger time investment to come up with a solution. No project should expect non-contributors to become a contributor just to fix a single issue.

  • Agreed 100%, there's no onus on the end-user to submit a fix directly into the source repository, unless you want to become a regular contributor to the project. That's what the mailing lists and bug trackers are for. Spring, Maven, etc do this exact model where people will find the solution on their own, and post it to the entry in Jira. It's upto whomever is working on the bug to accept and handle the contribution. Commented Apr 17, 2012 at 14:41
  • +1 for finding defect and submitting report. You may not be submitting a patch fix but I certainly feel that just by finding the defect, researching it and submitting the relevant information in a defect report then you are certainly contributing to the project.
    – maple_shaft
    Commented Apr 17, 2012 at 17:02
  • Let's assume I am a contributor to the project as a whole. What does that change? Commented Apr 17, 2012 at 23:25
  • @SteveBennett Without knowing the structure of the project, I can't answer that. Some projects are more strictly structured with assigned tasks, while others are more free flowing.
    – Thomas Owens
    Commented Apr 17, 2012 at 23:55

Proceed as far as you're willing to put up with it. It'd be nice to fix up your patch and share it with the world in the main trunk, but if the maintainer doesn't want it, shrug. You can post somewhere your problem, and the patch to deal with it, so that others in the same boat can search for a solution.

And you're not without problem. Your patch won't be in the next upgrade. So you'll have to repatch, and hope it works or massage it into place, whenever you grab a new version. So getting it into the main project will be saving you, and your company, time in the long run.

It's a pain to you, but you're contributing to the community. I certainly appreciate all the work contributors put in. It's not like quality software just magically genesis's from the masses. Someone has to do the work. (So who's awesome? You're awesome). If you don't feel up for it, announce to the community that while you appreciate the discussion of how it should be, you're simply too busy to do it. I mean, what are they going to do? Cut your wages?


There is one tenet that makes open source culture easier to understand: the person who does the work decides what to work on. This is one of its appeals compared to developers' day jobs. Your #1 priority might be #50 on their backlog. If you don't fix your pull request, eventually it will probably trickle up to the top and they will take care of it. However, if you make it easy enough for them, they will take care of it now.

The other reason they ask you to fix your pull request is more magnanimous. They want you to get credit for your contribution, small as it may be. If you do the fixing, your name is the one in the author field of the commit. Most people are proud enough of their contribution to want to see it through, so the maintainers' default modus operandi is to let them.

As far as your responsibility to your employer, if your business is relying on this code you're not doing them a disservice. Employers know the benefit of a workman taking time to sharpen his tools.


AFAIK, the open source way is that the responsability of fixing bugs is left to the one who care enough about the bug to handle the burden to ensure it is fixed. Depending on the circumstances, I've done everything from simply ignoring an issue to battle up (providing patches and arguing so that they are accepted) to ensure it was fixed.

Everything is right, just don't let people managing the project expect the wrong thing from you (i.e. give them hope that you'll fix the issue properly by discussion options and then do nothing), they probably are aware of more issues than they can handle themselves and will try to make a recurrent contributor of you if they can.


The original bug may only affect you, so it's very much in your interest to get the submission in by doing whatever is required to bring your patch into compliance. Otherwise the next version you pull (because you need other fixes) will be missing your fix.

You don't want to maintain a list of patches you need to apply every time you pull a new copy of the project - it's just too much trouble. Take a bit of extra time and get it fixed permanently so you won't have to deal with it again.


To an open source developer, there are two types of problems:

  • (a) problems without a patch
  • (b) problems caused by a patch

I think most open source package maintainers/developers LOVE the idea of helping to get a non-core-contributor up to speed with their patches.

Their primary goal, however, is minimizing the number of type-b problems. That's why the bar is set pretty high.

Some people surmount it. They become contributors, or maybe even core contributors. Others give up. There's a certain Darwinian nature to Open Source - survival of the fittest.

I encourage you to press on and spit-shine your contribution to the point where the team accepts it. Once you've done a few contributions, they'll trust you further, but you should still make sure your contributions are impeccable.

The end result is totally worth it. Stuff like being able to say "Do I code? Yes... You're running something I wrote, every day."

  • Ok, but what's a reasonable level of hoop-jumping to require? Presumably there is a difference between a maintainer asking for a bit of effort in order to gain trust, and simply being difficult and unreasonable. And again, my question is: what am I trying to achieve? Is getting my bugfix into the codebase more in their interests than in mine? Commented Apr 18, 2012 at 1:18
  • It's already been mentioned that the next release won't include your local patch - so it's in your best interest to get a fix into the software. Company-wise - it's in the company's best interest too - someday you may leave and no-one will remember to always re-patch application XYZ with your local fix. Try this: rework the patch, but don't submit it. Send it to the maintainer via email or otherwise - and ASK for their feedback - as in, "I think I got everything you mentioned - can you help me make sure this is right?"
    – pbr
    Commented Apr 18, 2012 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.