Comments on: How much for a bug?

By: petur

petur — Tue, 15 Sep 2009 09:40:59 +0000

At work we mostly work fixed price. The customer comes with a problem, we do a first analysis and estimate the work. This is documented so that the customer understands why it will take x days. If we take longer, it is our loss, if we do it faster, we win.
Some safety margins are added, obviously

By: JoachimS

JoachimS — Tue, 15 Sep 2009 07:23:49 +0000

Aloha!

My Euro worth of ideas is to divide bugs and their monetary value in groups, for example like this:

(1) Typos and nitpicks that makes the code better (accordning to your published rules): A Euro for a dozen or a handful.

(2) Lethal syntax bugs that breaks runtime and open up for simpler types of security vulnerabilities. A handful of Euros for each bug.

(3) Protocol and semantic bugs that open up for race conditions, execution paths that lead to use of undefined variables and other high level thought mistakes. A pile of Euros and an award – “cURL-breaker of the year” or similarly.

The idea is to provide an incetive to get people to dig in on the bugs that are hard to reach and find the things you as the developer can’t find simply because the code is a reflection of how you think.

Also by publicly recoginizing, and awarding the bug finder you build a positive relation with the bug hunters (or debuggers as they are) the likelyhood of having bugs be used for exploits rather than responsible disclosure (as in full disclosure by you and the bug finder) should be lessened.

By: Raphael

Raphael — Tue, 15 Sep 2009 05:31:47 +0000

How about charging for the price quote? I think this is usual in many areas.

By: daniel

daniel — Mon, 14 Sep 2009 22:30:53 +0000

As a developer considering to do something like this in a business perspective, I’m more interested in finding out the upper margin of my price range. I mean, like how much I can get for a particular fix as opposed to what has someone else charged in the past for something that might be similar.

Also, in my experience I get approached by companies who have non-publicized problems. There’s no bug track entry anywhere to refer to that has gotten any public “score” or comments about its seriousness etc. One company shows one problem and asks for a quote on how much for fixing it.

I think we might just end up where I am today: I give the existing problem a glance, I research it to get a grip of its complexity and then I guesstimate a fixed price that gives me a small margin to err. And on average I stay within the estimated time frame.

The downside is of course that each bug takes a considerable time to research just to be able to quote a price so already there I’ve lost in case the customer doesn’t bite.

I figure there’s a reason why this isn’t a service a lot of people provide already…

By: jrep

jrep — Mon, 14 Sep 2009 22:28:07 +0000

“A thing is worth what people will pay for it,” the economists tell us. We just need to establish some sort of auction situation. I have the idea I’ve heard of something like that, where companies offer to pay for FOSS-project fixes, and developers bid for the job, but I can’t google it up at th emoment. Am I just confusing it with similar services in other areas, like Amazon Mechanical Turk, and a site or two for graphic work?

By: Raphael

Raphael — Mon, 14 Sep 2009 21:55:49 +0000

I’m not sure however, how to determine those base prices. Maybe look at bounties that have been paid for other bugs or features.

By: Raphael

Raphael — Mon, 14 Sep 2009 21:51:49 +0000

I’d guess the ‘value’ of a bug is not determined by how much time is needed to fix it but by the question “How many users are affected how much.” This information could be extracted from the project’s bug tracker, maybe combined with distro bug reports for the package.
I would define a base price for each bug severity (wishlist less, grave bugs more). Then I would multiply it by the number of users affected by it. If I don’t have a good estimate I would just take the number of comments on a bug (maybe weighing recent comments higher). Popcon statistics could also be used.
This is the amount I would offer. Developers could do a quick assessment of the bug and determine if it is worth the money to fix it.
Thus, grave bugs that are easy to fix will be fixed very quickly while grave bugs that are hard to fix will stay aroung until enough people are annoyed by this bug and have commented on it.
So, as a developer you might do it the other way around – look at the bug that you are asked to fix, calculate the “worth” of this bug as shown above and maybe adjust your offer a little bit upwards or downwards depending on the difficulty of the bug. If you feel that the bug requires far more work than it is worth (in money), tell your client and determine an hourly rate – if they really need this bug fixed.