Warning: blog post with no clear conclusion!
I offer support deals to companies that want to get help with Open Source programs I’ve contributed to. The deals I’ve made so far have primarily involved libcurl, c-ares or libssh2, but that’s basically because those are projects in which I participate a lot in (and maintain) so people find me easily in relation to those projects.
I wouldn’t mind accepting service and support deals for other projects or software products either, as long as they are products I know and am fairly familiar with already and I am not scared of digging in and fixing things under the hood when that is required.
In fact, I could very well consider to offer to fix bugs in any Open Source software. Like a general: if you have a bug in an open source project that you really want fixed and you can’t do it yourself I might be your man. Of course this would be limited to some certain kinds of projects and programs, but it could still include a wide range of software. A lot more than the ones I happen to be involved in at any particular point in time.
But while “a bug” is a fairly easily defined term to a user who can’t make something work in a given program it can be anything from dead simple to downright impossible for a developer to fix. The fact that users many times cannot determine if a “bug” is hard or easy, if it’s a bug or a feature not working on purpose, makes such a business deal very hard to provide.
How to pay to get a bug fixed?
Fixed price per bug? Presumably only tricky bugs would be considered for this so it would require a fairly high fixed price. But then it’ll also never be used for simple bugs either since the fixed price would scare away such use cases. I don’t think a fixed-price scheme works very well for this.
Then we only have a variable price approach left. A common way for a consultant like me is to charge for my time spent on a project: I set an hourly rate, I fix the issue in N hours. I charge hourly rate * N. For smallish projects, this is less attractive to customers. If we have no previous relationship, there’s a trust issue where the customer might not just blindly accept that I worked 10 hours on a task they think sounds easy so they feel overcharged. Also, there’s the risk that I estimate the job to be 2 hours but end up spending 12. My conclusion is that per-hour pricing doesn’t work for this either.
A variable price approach based on something else than number of hours it took for me to fix the problem is therefore needed.
A bug fix is of course worth whatever someone is willing to pay for it. But we don’t know what they are prepared to pay. On the other end, a bug fix can get done by someone for the price he/she is willing to accept to get the job done. So where is the cross section of those two unknown graphs?
I don’t have the answer here. I’m very interested in feedback and suggestions though. If you would pay for a bug fix, how would you like to get the price set?
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.
I’m not sure however, how to determine those base prices. Maybe look at bounties that have been paid for other bugs or features.
“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?
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…
How about charging for the price quote? I think this is usual in many areas.
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.
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 😉