Crowdfunded bounty tracker

Revision as of 14:29, 13 December 2015 by Woozle (talk | contribs) (→‎Notes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


The crowdfunded bounty tracker is a web-based tool to enable funding of solutions with the following set of attributes:

  • A relatively small number of people (possibly as few as one) can devise the solution.
  • A relatively large number of people stand to benefit from the solution.
  • The amount of benefit to any given individual, or even a small group of individuals, is not enough to justify resources (payment) which would be sufficient to justify the resources (mostly time) necessary to create the solution.


While the process has the potential to solve other types of problems (e.g. social problems, infrastructure) from whose solution there is no clear "profit" to be made, the most obvious application is in the development of open-source software:

  • designing/writing new applications
  • designing/writing new features
  • fixing bugs

I'll continue to use software-development terminology when discussing this tool, but this should not be taken as limiting its utility to software development.


  1. Users enter software bugs they'd like to see fixed and features they would like written (aka "issues").
  2. For each issue, any user may pledge a bounty, to be paid when the issue is resolved.
    • See "Handling funds" below for some options.
  3. When one or more developers believes they have resolved the issue, they post it for user approval-vote.
  4. If enough of a majority agree that the issue has been resolved, then the pledgers pay up.
    • What constitutes "enough" should be made clear before pledging begins, and non-adjustable on a per-issue basis.)
  5. Developers split the proceeds.

In this way, developing open source could become much more profitable.

If you want to prevent money from ruling the process, then some degree of hiding could be done -- let users vote on the most important issues and let the pledges (or some percentage of all pledge money) be apportioned accordingly, rather than directly assigned by the pledger.

Handling funds

Having funds actually go through the organization operating the Bounty Tracker introduces some complications. Either it would want to be some sort of non-profit with permission to act as an escrow account for cash redistribution (which I gather banks can be touchy about), or it would want to avoid handling cash intended for others.

There seem to be two potential fund-handling models: pay-up-front and pay-on-solution.


In this model, money is actually transferred from each bounty-funder to an escrow account (under the site's aegis) at the time the funder posts their bounty.

  • Advantages:
    • site could easily earn income by claiming a small percentage of each successful bounty
    • possibly the site could earn interest from held funds as well (though this might introduce further legal issues)
  • Disadvantages:
    • more responsibility for keeping track of funds; risk of financial damages
    • would have to meet legal requirements in order to avoid having funds viewed as taxable income
    • money would have to be refunded to bounty-funder after a set time-period
    • people might be more reluctant to pledge, due to concerns that their money going to be sitting around unused for some unknown length of time


In this model, each bounty funder pays the appropriate bounty-hunter directly once the solution has been delivered. The site could recommend a specific amount for each funder and/or hunter to voluntarily contribute towards site maintenance on delivery of the solution.

  • Advantages:
    • no need for the site to have any specific legal structure or even have a bank account
    • people will only be paying when a problem is actually solved, and thus will have more cash to spare per problem and more satisfaction per dollar invested
  • Disadvantages:
    • some pledged bounties inevitably would not be paid -- but hopefully over time it would be possible to predict, with some dependability, the likely actual developer revenue from a given set of pledges, again making it possible for developers to determine feasibility of tackling a problem even if the actual take would be less than with pay-up-front.



  • Bountysource seems to have implemented this idea, although it's limited to software and has some other restrictions




The voting module from InstaGov could be adapted for this; an additional module would be needed to handle the pledging process.