Crowdfunded bounty tracker

From ICMS
Revision as of 20:24, 18 April 2013 by Woozle (talk | contribs) (fund handling)
Jump to navigation Jump to search

About

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.

Applications

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.

Process

  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.

The latter could be accomplished by having the bounty-funders pay the bounty-hunters directly on completion, and asking all parties to voluntarily contribute a percentage to the site to cover operating expenses. This would probably result in some percentage of bounties not being 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. (Of course, it might not be less; on a pay-first system, 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; on a pay-later system, people will only be paying when a problem is actually solved, and thus will have more spare cash per problem.)

InstaGov

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