Re: Bounty for Bugs in Open Source Projects?

   From: Nik Cubrilovic <[email protected]>

   I am interested to know if there is currently an initiative for commercial
   organisations to offer a bounty (cash incentive) for bugs or features to
   be implemented in Open Source projects. The company I work for would be
   interested in paying developers on Open Source projects to implement
   features, and to fix certain bugs that we require in some software, but
   the only way to do this at the moment seems to be to contact the project
   leader, or to post to the corresponding project mailing list with the
   details.


In my experience, those alternatives are, in fact, a cheap and often
effective way to get things done.  I take considerable pride in the
fact that *my* projects have generated revenue for others who were 
hired to work on my projects.

I suggest *not* directly posting a bounty ("Hey everybody, $N for
feature X") but instead presenting your problem to the community and
seeing who (a) gets what you're describing; (b) is already established
well enough to present a credible offer to fix it.  After that,
negotiate privately.  Post -- certainly -- but don't post a public
offer (you'd just attract hooligans).   At this stage in history,
you aren't asking bidders to compete on price, mostly -- you're asking
them to compete on "ability to actually get the job done".

(That said, the price range for spot-market hacks seems to me to be 
between $500 and $10,000 per hack --- with the average somewhere in
the low-4-digit prices.)

There are two big problems with this approach, both of which are
surmountable (but I won't declare (only suggest) how since I'm not
sure my answers are best):


  (a) You want your fix in the mainline?  Show some consideration
      to the upstream pipeline.  If you hire someone to write a 
      fix and expect to appear in mainline --- don't *presume* 
      that the maintainer is happy to process every little improvement
      that comes along.  Each improvement costs the maintainer 
      effort -- sometimes considerable effort.   The worst (and not
      uncommon, in my experience) situation is when the person you've
      hired needs in-advance help from the maintainer to do the work
      well.   It's totally ordinary that such help is needed -- it 
      does *not* reflect poorly on the guy you hired -- but it is
      also a *material imposition* on the maintainer to ask the maintainer
      to give that help on *your* schedule.   

      Suggestion: definately buy labor on the spot market but, don't
      get a reputation as a jerk: be sure to tip upstream as well.

      Flip side of that suggestion to free software maintainers: if
      you find yourself asked to participate in one of these
      commercial circuits and the goal of the circuit makes sense ---
      WORK WITH THESE FOLKS AND DON'T BE A JERK ABOUT IT.  Insisting
      on or urging some compensation is The Right Thing
      for a maintainer to do in this circumstance --- but aside from that,
      a lot of good tasks get accomplished by this route.





   > So is there some central way to do this? If there is not, I would be
   > interested in setting up a site to facilitate this and kick it off by
   > having the company I work for pay developers for bug fixes and features.


  (b) The *biggest* problem most of these little spot market contracts
      seem to cause is the delivery problem.   The actual hacking is 
      cheap, relative to the cost of *presenting* the hacking in a 
      form that it is cost effective for your customer to consume.

      The arch project is working very hard on that problem.  Although
      it isn't ready for formal release yet, I have infrastructure that
      lets me very cheaply set up an entire web site for each customer.
      The web site includes a blog-style diary of the progress of the work,
      a bug database just for this work, and any ancillary documentation
      that arises during the work.   This seems to smooth delivery quite
      a bit and it fits in well with the emerging world in which all
      free software exists, principally, within a distributed revision
      control universe.

   > What would the implications be for such a scheme?

Among other things, they would be "huge" --- bigger than big.  Bigger
than John Lennon, relatively speaking.

The place where you betray your naivete' is where you say "I would be
interested in setting up a _site_"....

Forgive me but, it would be idiotic to centralize the already extremely
efficient spot market by trying to force it through a central "site".

You have the right idea about the general characteristics of the
economic circuit that *will* (im(current)o) win --  you have a
distorted-by-greed idea of how to implement it (and you are behind
the times since the market you seek to create already exists and is
thriving).

(I also speak from the experience of having proposed to various potential
funders more or less exactly what you suggest.   I once thought as you did.
But then I saw a bunch of hackers who volunteered for *my* projects
win without any such heavyweight infrastructure for trade.....)

-t