The impetus for this post is this twit:

At the point of seriously considering paid access to issue tracker. Code still open source, everything still licensed the same. But you want *time* from the core team to work on your bug/feature request? Maybe that should be based on paid tiers.

Maybe.

I don’t know

— John O'Nolan @ (@JohnONolan) May 8, 2018

I cannot express enough how much I object to this statement. I absolutely understand the reasoning, by the way. Drive by bug reports can be frustrating. Users of open source projects can have unreasonable expectations. Any open source project maintainer can tell you about posts with “Your code SUCKS” or people calling your phone at odd hours with hard to understand accents (and I’m not really one who can complain here) and demanding that you fix stuff. This sucks, absolutely. And in a popular project, you might run into a lot of “user error” bug reports, or even outright “fix my code” issues.

Nevertheless, I think that this approach focus on one side of the issue, how much burden it puts on the maintainers of the project. What it misses is that there is really valuable information contained in the bug report. It might be something that the software is not capable of doing, a wrong usage (no, you cannot use this class concurrently) or a real bug. Regardless, a bug report is valuable in and of itself. Someone put the time to actually use your software, identified a problem (for their use case) and reported it.

That doesn’t mean that you are in any way (if you are OSS project) obliged to fix this issue. In fact, I believe that even if you just threw the code on GitHub because you didn’t have anything else to do with it, bugs are still valuable.

Bug reports involve efforts, and if you have a live OSS project, you want to respect that and answer those bugs. At a minimum, they tell you about what users are doing with your software. That might not motivate you to fix those issues, but it is good to know anyway.

Sometimes you will get a good bug, either about an “obvious” missing functionality that you can add or “wow, we have that” that is critical to fix. Bugs that never impact you are also interesting. It might be a race condition that you were lucky to never hit, or a silent miscalculation that was never noticed, data corruption that will hit you in the future or even a security issue. Regardless, it is interesting.

All of the above doesn’t mean that you have to do something about any of these. In fact, even if you don’t ever intend to go back to this project, bugs are very useful. And not for you, for other people. If someone comes to your project and see posted bugs, they can figure out what not to do. They can learn about possible workarounds provided and confirm that this is a bug / limitation and they aren’t going crazy.

As for how to actually handle such bugs in an OSS project, if you aren’t interested in fixing a bug, it is perfectly fine to not to. A free OSS project can absolutely have policies on what are acceptable bugs, and closing the “fix my code” is a good policy in general.

For real issues in the code that you aren’t interested in fixing, it is okay to say: “Send me a pull request for this”.

For nasty replies, I found that: “I’ll be happy to refund your money” usually puts things in perspective.