Advogato: Buy my bug

Buy my bug

Posted 7 Feb 2003 at 18:42 UTC by garym

Wanna buy a piece of my bug?

One of our ongoing projects is a client-side processor for subscribers to very broken services; a huge chunk of the program exists only to fix the feed providers brokenness. Each service vendor probably has thousands of customers, and each and every one of these customers independently funded their own kludge fix --- the cummulative cost of all these must be staggering, easily enough money to fix the broken server side many times over.

I've seen services where opensource projects are auctioned to the highest bidder -- you bid a price, some programmer accepts your contract -- but are there any services who auction bugs and features to an aggregate bid?

Random muse time -- This is how I see it working:

Using the normal bug-zilla/sourceforge trackers, developers and users alike post feature requests and bug reports, and just as always people are free to walk in, take a ticket from the job jar, fix it and gain the adoration and respect of their collegues world-wide.
In addition to people fixing what they need fixed or fixing things just for the fun of it, subscribers to this system could 'bid' on a bug -- or a better term might be to 'pledge': They log a promisary note which promises to pay some amount (perhaps held in escrow?) to whomever submits the 'winning' solution.
There must be checks and balances. For example, maybe a time-limit on the solution or a procedure to back out without causing too much trouble to anyone who may be mid-solution and depending on that income; perhaps it's like a stock-ticker where each bug has a 'current' payoff that may fluctuate moment to moment, giving the game an nice element of risk and adventure! You might have a solution, but hold off submitting it in hopes the price will go up before someone beats you to the mark.
When someone has a solution, they submit their patch to the CVS moderators who must then decide whether the patch is up to snuff; this is no different than current opensource development models, only this time, if it goes into the project, the author of the patch is paid through cashing in on the "promisary notes" or "shares" members have pledged against this feature.
Won't this skew the project priorities to those features with the biggest budget? Not necessarily. If I want a feature, I might just go ahead and do it the old way, paying myself (in beer, food whatever) to do it, or, if I'm in business, I might take my programmer's bid on doing this fix, pledge that and set them to work on it, and if we accummulate more pledges, then, if my programmer is successful, we stand to make money on the deal (and if they are not, the penalty I pay having paid them for nothing plus pay someone competent might urge me to re-evaluate my choice in employees ;)
Projects where many people are permitted write access to the CVS may pose a problem; there's opportunity for abuse by posting bogus 'fixes' just to claim the prize ... and this leads to the next point:
There needs to be some sort of independent arbiter, someone who declares that the fix fullfills the bug/feature requirements specification. This may involve some grace period when the bug may be rolled back and I suppose we should allow individual pledge-holders to back out if they really feel the fix is not what they'd wanted (as we saw in the Linux Journaling File System Wars) They would, of course, be free to use the fix anyway; these are our risks, the costs of doing business -- besides, using our existing methods, if I pay for the fix, others use my work anyway so we haven't really lost anything if people back out after the fact.
Or maybe it's irrelevent, the abuse easily absorbed by the gains: Within our own cloistered ranks (like it was before the covered wagons arrived on the internet) people would probably be well behaved enough to make it work, and eBay is able to enforce a "you promised, you pay" policy, so it should be reasonably assured that no one will promise huge amounts they never intended to pay out. As with eBay, perhaps a reputation system might help.
A commission can be creamed off the transaction somewhere to fund the administration (and cover abuse costs). The arbiter has responsibility and expense, and since stockbrokers take a cut, agents take a cut, even do-nothing-for-you bogus-RFP server websites take a cut , I suppose, yes, there's a commission system required in here too.
This may require the system be administered by an independent third party, perhaps a PayPal or someone just like them, and then hooked into a bid-API in BugZilla (or whatever) so we get the benefit of the safe funding model, spread across many open source projects with a branded trust factor from the money-changers. Hmmm ... maybe this is a funding proposition for SourceForge ... or MandrakeSoft!

Take even one small fix to these service provider feeds, for example, the annoying artifact of duplicate lines. Sure it's no big deal, takes perhaps 3-4 hours for an experienced programmer to write a two-line look-ahead buffer to check last against current and then pass only the non-duplicate lines down the pipe (unix <code>uniq</code>). It's not difficult and can be done, coded and debugged in under half a day <u>but</u> when that innocent half-day of labour cost is compounded over thousands of programmers each working alone at their own shop, it may be a trivial expense of only a few hundred dollars, but it's an aggregated development budget of hundreds of thousands of dollars!

Waved beneath the nose of any vendor, this sort of attention-getter would get most any bug fixed at the source in very short order ... and turn a very healthy profit in the process!

let's apply this open source development. The Collab.net and others have tried to find individual sponsors for large-scale inventions, but what about simply adding credit-card hooks to Drupal or fixing pagination in OpenOffice ... this aggregate consortium funding adds up pretty quickly and might rapidly accellerate some of the nearly-there applications to a prime-time status. For example, a new-feature request for even some critical hack to the Linux kernel, if it carries a current market pledge in the thousands or hundreds of thousands of dollars -- which may only be $200 from 1000 companies --- well that's pretty good impetus for some enterprising engineers to go out, hire top people and work diligently to solve the problem.

Many eyes make all bugs shallow, and many wallets make all bugs cheap!

It seems such an obvious idea and it has some precident: it's really not very far from PBS deciding what shows to keep based on viewer membership donations! MandrakeSoft did try something vaguely similar in trying to drum up donations for it's pet projects such as the 8086 emulator, but this was fuzzy and general donation funding to specific individuals, not an open market bid on a specific feature; I don't know ow successful they've been, but I haven't heard of any great breakthroughs from their fund-target projects either.

Would a per-feature model do better? Has anyone seen anything like this out in the wild? (in software engineering or any other domains) Any comments, thoughts, ideas on the implementation?

Quick reference, posted 7 Feb 2003 at 23:30 UTC by mbrubeck » (Journeyer)

I just want to throw in a link to a recent Advogato article on Conditional donations to fund software development, which discussed mechanisms to funnel aggregated donations to developers.
Also look for some background on SourceXchange and CoSource, two late-1990s "code for bounty" sites, now defunct. I believe that CoSource allowed multiple users to contribute donations for a single project specification, and focused on per-feature or per-bug bounties.

CoSource, etc., posted 8 Feb 2003 at 00:14 UTC by emk » (Master)

CoSource did this for a while, with marginal success.
In theory, it's a good idea for anything which takes a couple of days to a few weeks of programming. Two hour projects are just too small to justify the transaction costs; bigger projects involve a lot more digging for specifications, and a lot more risks.
In practice, you have a lot of "people" issues to solve, or your transaction costs (risks, time overhead, etc.) will be way too high. E-Bay solved these issues for online auctions--using rating systems to enforce good behavior--but I'm not sure if there are similarly clever ways to specify a software design and decide whether it has been implemented well.
I'm currently working as an in-house tools guy who occasionally arranges to hire open source project leaders to add features to their projects (the best way to spend money on software, PERIOD). I could easily imagine joining some sort of second-level co-operative to help maintain the open-source toolkits we use. This could be a way to contribute to an open-source project without employing a full-time developer. Member organizations could invest a few thousand dollars/year, vote on bugs to fix and features to implement, and employ a few full-time programmers to do the work.
It sounds like your company is basically the for-profit version of this. :-)
I think sourceXchange and CoSource both failed because they mistook a bunch of clever Perl scripts (and a few policy documents) for a living, breathing organization. SourceXchange's specification and bidding process was designed to keep sponsors and programmers from talking to each other (d'oh!), and CoSource was just a database with draconian legal agreements (deliver the project one day late, receive zero pay). Ironically enough, you can't really use software to automate software contracting; there are too many human variables involved.
If you depend on open source software for mission-critical operations, hunt down some other users in the same situation and see if you can't work out some sort of plan, formal or informal. Open source software is all about use value, not sale value, so I think the users of open-source software are in the best position to dream up new funding ideas.

Encouraging collaboration and smart users are the key., posted 11 Feb 2003 at 21:17 UTC by davb » (Apprentice)

A great example of user cooperating to improve an open source project is < href="http://www.collaboraid.biz/blog/one-entry?entry%5fid=6122">http://www.collaboraid.biz/blog/one-entry?entry%5fid=6122</a>. (I work on OpenACS, but I am not involved in this project.)More groups need to work togther to fund this kind of development. The users need to understand that spreading the cost between multiple parties saves them money and results in a better solution for everyone involved. This means the people who are making decisions in these organizations need to understand open source, and usually also believe in the benefits of open source solutions.

Fixed link, posted 11 Feb 2003 at 21:27 UTC by mbrubeck » (Journeyer)

[Here's a fixed version of the link from davb's comment above.]

collaboraid, posted 12 Feb 2003 at 07:29 UTC by garym » (Master)

collaboraid isn't precisely what I was thinking of, but it's an excellent model just the same. Where I see any direct sponsorship for free software its usually one vendor paying for code that others can "take it or leave it" whereas this one is starting off with the balance that comes from multiple applications. Very encouraging!