12

Here's one problem I don't have a strategy yet: I find an important bug in an open source project, contact a mailing list requesting the maintainers to fix it and after a triage, I get no response.

What could I do to maximize the chances of getting the bug fixed? So far I usually resort to nagging, but this seems to rarely work out well.

  • 3
    Are other people using that program? Distributions? For small projects you should expect that maintainers are busy, so several months is IMHO acceptable delay. – Giacomo Catenazzi Feb 26 '16 at 20:10
  • 1
    And as a follow-up to the previous comment: how many bug reports are there in total? – Michael Schumacher Mar 1 '16 at 7:22
  • 1
    ... and here we are, in a thread not addressed by the OP :) – Michael Schumacher Mar 2 '16 at 7:21
  • @MichaelSchumacher: sorry. There's just a few bug reports, the programs are among the most popular ones, included in the distributions. – d33tah Mar 2 '16 at 10:32
  • Any examples? Knowing them might improve the answers beyond the generic "things you could do" towards "things you should have done". – Michael Schumacher Mar 2 '16 at 16:13
12

Ultimately, if the developers are working on the project as a labor of love, they're going to work on what they want to work on. You can't expect them to prioritize your issue just because you asked them to. Instead, you can try to add incentives to make it more likely that your issue is one that they do want to work on.

I can think of a few options, depending on the particular circumstances:

  • Patch it yourself: In the event that you have the technical know-how to fix the bug yourself, you can submit a patch. Be sure to follow the project's style guide, and ensure that your patch includes tests if the project maintainers typically expect them. Of course also make sure it doesn't cause any new problems in any other parts of the project (so, don't cause any existing tests to fail, for starters). Submit your patch for integration into the project.

  • Supply more information: Even if you can't completely fix the problem yourself, try investigating the issue further. See if you can find any relevant parts of the code that cause the problem, or see if you can produce any other test cases that reveal more information or are more succinct than whatever you've already given. If you do a good job here, you can simultaneously draw renewed attention to the issue while potentially making it easier for the developer(s) to solve.

  • Get other people involved: If you know that lots of other people have this issue, draw their attention to your issue in the project's issue tracker and have them star/comment, depending on the features of the tracker. If it becomes obvious that the issue affects a lot of people, it will probably get higher prioritization. Obviously, if you do this all the time, or in an obnoxious way, you might just be delegating your unsuccessful "nagging" approach out to other people, so use this option thoughtfully.

  • Money talks: If it's really important to you to see this issue fixed immediately, pay the developers to fix it. If lots of people have this issue, see if you can collect money from multiple sources via a crowdfunding platform like Indiegogo. If the developers aren't interested in your money (e.g., they simply don't have the time, and money won't change that), you can pay someone else to fix the issue, since you have the source code already. See Nikolas Raoul's answer for step-by-step look at the process involved in contracting a patch.

  • 2
    What about "* add a patch to the bug report"? – Michael Schumacher Feb 25 '16 at 21:31
  • 2
    @MichaelSchumacher That seems like a reasonable option as well, if you have the ability to fix the issue yourself. I've just edited. – apsillers Feb 26 '16 at 1:16
  • 2
    Thanks. Keeping up the participatory aspect of software projects is important, I'm seeing too many people who react as if "do you want to contribute a patch?" was an insult. – Michael Schumacher Feb 26 '16 at 15:24
  • 1
    If creating the patch would be a lot of work, it might be worth asking the project maintainers in advance if they would be interested in accepting a patch to fix a bug. You might not want it go to to waste, and you also might not want to maintain a fork of the project in the long term. – bdsl Mar 16 '16 at 14:58
9

Apsillers' answer is perfect, I will just add a case study about the last paragraph ("Money talks").

My open source project (1.5 million users) has had users pay third-party companies for features. I wrote the guidelines below, they are general enough to be applicable to most projects:

Guidelines about sponsoring development

In case you are willing to pay money for a feature or fix to be implemented, here is how you can do it:

  • Find the issue in the issue tracker, or create a new issue if it does not exist yet.

  • Add as many details as you can, describe how it could work, draw a prototype on paper, etc.

  • Post a comment asking "If I provide a good quality patch for this feature, will it be merged?" and wait for our answer.

  • Choose someone to do the job. Use any crowdsourcing platform you trust (for example bountysource), or a developer friend, or a software company. Make sure they know Android and Git.

  • Reach an agreement with the developer:

    • Agree with the developer on the conditions, defining exactly what they must implement.

    • Insist that produced source code must be released as Open Source (not doing so would be a breach of the GNU-GPLv3 license). A common error would be to ask only for the binary (which will quickly get out-of-date and incompatible)

If possible, make it a condition that produced source code must be merged by us before total payment. Or make it half/half. If the issue is classified as "critical" in our issue tracker, then the developer can be assured that we will merge it fast, if the code is good enough.

Propose to become a tester if they need. Giving your feedback early could help. Be sure to test on different devices and in different scenarios.

Summary of the workflow:

Paying for open source development

  • 2
    Nice aproach towards the 'I wrote this, now why won't your merge it?' problem. – Michael Schumacher Mar 1 '16 at 7:20
3

You must also consider that what you consider an important bug might be very low priority for the developers (for whatever reason). Yes, there have been cases where blatant security problems were dismissed as "irrelevant". In the end, you'll have to make your own call.

  • See if you can fix the bug, band together with other users willing to chip in, get more confirming reports, refine the report (see to make it reliably repeatable, smaller/simpler case exposing the bug, ...)
  • Look for workarounds
  • If you see the project might not be serious enough about bug fixing or general development standards, you'll have to look for replacements
  • If worst comes to worst, fork the project (or start an alternative). But unless the itch is severe, and affects lots of people, and you can motivate the crowd of users to chip in...

Added later: If it is commonly packaged in distributions (in particular, it is in yours, as mentioned in a comment), perhaps the best bet is to report it locally. Your distribution's packagers are often active upstream too, or at least have more direct access to upstream developers. A bug report by the maintainer of the package in a major distribution will certainly carry more weight than one by an unknown user on foot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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