bounties

https://www.google.com/accounts/o8/id?id=AItOawn3NCtvZDktI1KupmiqsOjzB7GuYW2L5t8 edited this page Mar 10, 2011 · 3 revisions

Bounty Pools</br></br>

Bounty pools are a solution to some common problems for FOSS software development that stem from lack of funding.</br></br>

Some of the problems are as follows:</br></br>

  • The project managers and developers get paid little to nothing for their dedication and hard work. With little to no money going to a FOSS project's top developers, the possibility of abandonment of the project is much higher since other projects or priorities can come along for the developers. Since the developers were not making anything to begin with, no one steps up to fill their positions after they leave.</br></br>
  • The value of a part of the project is difficult to measure. A FOSS project can often have demands for documentation or particular features by individuals who put a price of 0 on the work needed for such documentation or features. Since everything has a price of 0, it is up to the developers on the project to determine the value of some aspect of the project. Or they just work on what they believe to be the most valuable or interesting to them. Basic economic theory says that prices direct resources to places where they are more urgently needed. Therefore, if prices could be placed on certain aspects of a project, it would be easier to determine the most valuable things (to users in general) to work on.</br></br>
  • Often the solution to the above problem for people who do have money to spend on custom improvements, is to pay a developer a full wage to implement a feature. However, this solution often leads to such enhancements to be closed source since the individual purchasing such an enhancement has no obligation to FOSS the enhancement (provided they are not distributing or selling the software).</br></br>
  • An individual with a relatively small sum of money to spend on an enhancement cannot get the enhancement implemented because the amount of money is too small to attract the developers of the project away from the main project.</br></br>

Solution:</br></br>

Pool the resources of all individuals that desire a feature on a per feature basis. By pooling funds for enhancement, no individual has to pay the full cost of the feature and so the feature can remain FOSS.</br></br>

A simple example:</br></br>

A feature that would cost $500 to have a developer implement is shared among 5 individuals (or stakeholders) at $100 each. The feature is developed and integrated into the main project code and everyone benefits and gets the feature at 1/5 the cost they would have had to pay without the bounty pool.</br></br>

A slight variation on the first example:</br></br>

A feature that would cost $500 to have a developer implement is shared among 4 stakeholders. However, in this case each stakeholder has varying degrees of ability and or willingness to pay. In this case, 2 stakeholders put up $150 each while the other 2 stakeholders put up $100 each. Once again, the feature is developed and integrated into the main project code with no stakeholder having to put up the full $500.</br></br>

Now, a proposal will be made as to how bounty pools would actually be run.</br></br>

The first thing a bounty pool requires is means for stakeholders to be matched with developers. This could be done on a forum, a web application specifically designed for this task, or simply through a mailing list.</br></br>

The second thing a bounty pool requires is an escrow for the bounty. A trusted individual would be in charge of the escrow and would be charged with 2 major tasks:</br></br>

  • Provide a safe visible account for the bounty funds from the stakeholders to be placed.</br></br>
  • Release the funds to the developer upon adequate completion of the feature request.</br></br>

An alternative to an escrow would be for each stakeholder to honor their word on an individual basis and pay out to the developer when the feature was completed. But the problem is that the developer would simply have a promise to pay from many individuals, some of whom may not actually pay out after the work is completed. Therefore, an escrow with visible funds in it and controlled by an individual trusted by both stakeholders and the developer is necessary for the bounty pool to work.</br></br>

As explained above, the bounty pool matchmaking can take place across many different Internet based communication mediums and so such a medium should not be difficult to find for a particular FOSS project. However, the much more involved aspect of the bounty pools is the escrow. Not only does the escrow require a trusted individual on both the stakeholder and developer side, but it also requires an account in which funds can be placed and from which the bounty would be paid out of to the developer upon completion and integration of a feature. It is proposed that such an account or payment system would have two desirable properties:</br></br>

  • Fund transactions are irrevocable (e.g. no chargebacks or disputed transactions are possible within the payment system). Once a transaction is complete, it cannot be undone. This is important because it gives the developer peace of mind that the funds cannot be charged back or disputed after they have received the funds.</br></br>
  • Funds in the account are visible by outsiders who do not necessarily have full access to the account. This is important because it allows the developer to see that the funds are in the account ready to be paid out upon completion of a feature. It also allows everyone to see how much is actually in the bounty pool at any given time.</br></br>

Now the above elements of a bounty pool are brought together to explain the creation and execution of a bounty pool.</br></br>

  • Stakeholders through a web board propose features and express an amount of money they are willing to put into a bounty pool for such features.</br></br>
  • After the proposed funding for the feature has been posted, an escrow is set up with an appointed escrow agent.</br></br>
  • Each stakeholder that expressed an amount of money they would put into the bounty pool transfers the stated amount of funds to the escrow agent's account.</br></br>
  • A developer makes a proposal to create and implement the feature.</br></br>
  • Upon acceptance of the developer's credentials and pre-requisite skills necessary to create the feature, the escrow agent 'blesses' the developer's proposal.</br></br>
  • Upon completion, bug testing and integration of the proposed feature, the escrow agent determines that the work has been completed and releases the funds in the bounty pool to the developer.</br></br>

The above scenario was simplified by the fact that there was only 1 developer. However, this is not necessarily the case. In a more complex example, there are multiple developers that are represented by a developer team leader. In this case, the escrow agent negotiates with the team leader only and pays out only to him upon completion of a proposed feature. The team leader is in turn required to distribute the funds to the developers. The key here is that the escrow agent representing the stakeholders only needs to negotiate with and pay out to 1 other individual, and so the issues regarding the management of the development team are not the concern of the escrow agent.</br></br>

For the Pyjamas project it is proposed that a web board or forum specifically for bounty pools be set up. A custom application built with Pyjamas would be ideal, but a web board will do. Unfortunately, the mailing list would probably not be a good medium, because pertinent information such as stakeholder bids cannot be easily kept in 1 easy to link to spot. In contrast, on a web board, the initial post can be updated with the important information for a bounty pool on an ongoing basis.</br></br>

The second issue is what medium of exchange would be suited for the bounty pools for Pyjamas. After searching for payment systems that fulfill the two traits of irrevocable payments and visible account balances, I found a new payment system called WingCash: www.wingcash.com. WingCash is a payment system that has virtual U.S. dollar based bills. There are no transaction fees to send people WingCash, each transaction is irrevocable and the history of each WingCash bill is publicly available. WingCash bills can be cashed out electronically into a bank account. Unfortunately, WingCash is U.S. based and is only available in a few states for now.</br></br>

An alternative to WingCash is Bitcoin: www.bitcoin.org. Bitcoin is a pure digital currency not tied to any government issued currency. Bitcoin transactions are irrevocable and are publicly available, as are the balances of the addresses that the Bitcoins are sent to. Unfortunately, Bitcoin exchange rates are very volatile as it is a relatively new online currency.