Understanding Google's Bug Bounty Program

2013-04-23

Some people have taken Google's idea of offering security bug bounties (wherein Google will pay cash rewards for reporting security issues to Google), and taken them to their logical conclusion: why stop at security bugs? Why not incentivize reporting of ALL software bugs with bounties? Aren't other companies cheap for not offering bug bounties?

Questions along these lines misunderstand how software development works. Engineers don't sit on their hands and surf Reddit after shipping a product. They're already working on bugs. All sufficiently complex software ships with known bugs; more reporting isn't likely to change whether they get fixed or not.

So the premise that "reporting more bugs will improve software quality" is speculative, at best. Software quality is determined by what the market will bear. The market usually rewards buggy-but-good-enough software that solves a problem now, rather than perfect solutions that are late to the party. This is partly because of the time value of software, and partly because chasing defects offers diminishing returns.

But more to the point: everyday users are not equipped to report bugs. They don't have the training, tools, or motivation to do it properly.

At Microsoft (and other software companies), crash dumps already include as much information as can be legally collected, based on the user's consent. So bug information for crashes and many other issues (uncaught exceptions, for example) are already being collected in an automated, accurate way. So really, any well-supported software already has built-in reporting for most high-impact bugs.

In addition, you run into other problems with bug bounties:

The only exception to this rule is security bugs, which operate a little bit differently than run-of-the-mill defects:

So paying bounties for security bugs can be effective, but it's not likely bounties for functionality bugs in the general case would be particularly productive.