TopCoder's interesting twist on community-based development
Most open-source companies are adept at finding bugs after a product release because their customers and system integrators - their community - discover these when trying to go into production. But getting qualified volunteers before a release to
An old friend from the open-source world, Ira Heffan, called me today about his company, TopCoder. Ira is a smart guy so I figured anything with which he was involved must be good.
And it is. At its most basic, TopCoder stages programming competitions, both for itself (that is, its direct consulting clients) and for third parties like Google. Companies hire TopCoder to stage competitions to build functionality for them (as well as to scout for new talent). TopCoder also provides consulting services and uses competitions to create the requested applications, and heavily reuses its portfolio of applications and components to drive down development costs.
As an example, TopCoder has its premier competition in Las Vegas next week at the 2008 TopCoder Open (May 12 through 15), hosting 120 finalists from 30 countries. $260,000 in prize money is on the line.
Ira told me that one developer made over $500,000 last year in TopCoder prize money. Not too shabby. This, coupled with recruiting interest from top companies means that developers may be winning themselves a new job, as well as a competition.
However, it's actually a lower-profile component of TopCoder's business that I find the most fascinating: Bug Races.
Bug races are a way for TopCoder to do maintenance on the software it develops, but the company is considering opening the program up to third parties interested in "renting" a community to spot and fix bugs. It's a great way to provide comparatively small dollars ($25 to $200 per bug fix) to find quick fixes for TopCoder's internal stable of Jira-reported bugs.
Now imagine what this could mean for commercial open-source projects. Despite the myth of open-source development (zillions of eyeballs making all bugs shallow), the reality is that most projects don't have the luxury of zillions, or even hundreds, of qualified people actively looking at their code to find bugs. Here's where rent-a-bug-killer comes in handy, as Ira noted to me:
...[T]he Bug Races might be an interesting way for open source companies to do bug fixes. The companies could post issues on the site with a bounty on them, and then review the member's submissions to see if they take care of the issue. The companies would need to provide the members with information on where to get the source, and environment requirements, etc., but that's something that open source companies would already have in place anyway. TopCoder already has in place the developer community and the payment and IP transfer processes, so it could be a very easy thing for us to do.
I think this is absolutely brilliant. Most open-source companies are adept at finding bugs after a product release because their customers and system integrators - their community - discover these when trying to go into production. But getting qualified volunteers before a release to find bugs, and getting bandwidth post-release to fix the bugs, would be invaluable.
Rent-a-community. It might not fit the myth of open source, but it seems like a direct hit on the reality of open source. If you'd like an introduction to the company, ping me.