|
a |
For many years, I've been looking into various ways to fund the development of free software. I'm especially interested in ways to get users to directly pay for development instead of support services, proprietary add-ons, etc. The closest thing I've found so far is microPledge. They have a system where either users or developers can write a project spec, users pledge money to the project, and then developers can bid on the project. When there are enough pledges to match a developers bid, the users have to give their pledges to microPledge which either gives the money to the developer upon successful completion or back to the donors upon failure. That is good as far as it goes, but in my opinion there are a few critical features missing.
An Incentive to Pledge
Most importantly, donors should be able to demand (and developers offer) a financial incentive for donating. So, a donor might pledge to pay $100 if the project is completed, but only if the developer agrees to pay him $10 when his pledge is paid, regardless of whether the project is completed. This is critical because it compensates the donor for a risk he is taking. Specifically, the donor is taking a risk that the project would have been completed even if he hadn't donated. That would mean that he was wasting his money and would have been better off free-riding. If the donor thinks there is a 10% chance that his pledge of $100 is unnecessary, then the decision to pledge has an expected cost of 0.10*$100 = $10. If the developer pays him $10 for the pledge, then the decision to pledge has an expected cost of $0. And, of course, in exchange for the value of the pledge itself ($100), the donor gets the value of the completed project which is presumably worth at least $100 to the donor.
Meanwhile, each developer would specify a non-performance deposit he is willing to risk. For example, a developer might bid $900 with a $100 non-performance deposit. In other words, he wants $900 if he completes the project and is willing to lose $100 if he doesn't. If $100 is sufficient to encourage $1000 worth of pledges, then microPledge takes the $900 in net proceeds ($1000 in pledges - $100 in incentives) from the donors and $100 non-performance deposit from the developer and holds the total of $1000 in trust. If the project is completed, microPledge gives the developer the $1000 ($900 for project completion + $100 non-performance deposit refund). If the project is not completed, the $1000 is returned to the donors, and the developer loses his $100 non-performance deposit.
In short, microPledges job would be to constantly check whether there is a bid offering a large enough non-performance deposit to buy enough pledges to pay the price quoted in the bid. As soon as that happens, microPledge would hold the funds from both parties in trust until the project was completed or the project deadline passed.
One potential problem with the above incentive scheme is that a malicious "donor" might make a large pledge and then try to sabotage project completion so that he can get his pledge back and keep the incentive. This can be discouraged by changing the terms of service to prohibit and penalize such behavior. It could also be discouraged by requiring that donors pledge all refunded money to other projects instead of cashing it out. Some amount of policing would probably be necessary to discourage bogus projects from being set up simply to launder refunded money into non-refunded money.
Donor-Specified Deadlines
Right now, microPledge only allows developers to specify deadlines. However, for many potential donors they need the project completed by some date in order for it to have any value. So, a donor should be able to associate a project completion deadline with his pledge. When determining whether there are enough pledges to pay the developer's quoted price, microPledge would only consider pledges with deadlines on or after the deadline quoted by the developer.
So, a pledge would have the following form:
I charge $c to pay $x for completion by mm/dd/yy.
Guidance on Pledges
Many donors won't know how to set $c and $x. As described above, a donor should set $c to a percentage of the $x that corresponds to the probability that the project will be completed if he pledged $0. What is that probability? There is no way to know for certain, but one way to model it is to assume that project completion is a Poisson process. If the project was first proposed at t0 and the project has not been completed at the current time t, then the expected time to completion is 2*(t-t0) and the probability of completion by the donor's deadline T is 1-e0.5*(T-t)/(t-t0). Note that this probability decreases over time. For simplicity, microPledge could default to using that formula to determine the probability (and in turn $c given $x) and automatically update the pledge periodically.
To determine the amount to pledge, the donor first needs to estimate the value of the project. The donor could use the replacement value (e.g. the price of a similar product), the expense caused by the project not being completed (e.g. the cost associated with a bug), or the profit he could generate if the project was completed. To assist, microPledge could provide a calculator for determining the present value of a future stream of expenses or profits.
Given the donor's estimated value for project completion, the question remains "how much should he pledge?" If he is just trying to maximize the value of the pledge to himself (i.e. he is being purely selfish), they should pledge the full value that completion of the project would have to him. Why? Here's the math. The donor is trying to maximize the expected return r on his pledge of $x. Let P(x) be the probability that the project will be completed if he pledges x. The donor has an estimate of the value of the project, V, and an estimate of the probability, P(x), that the project will be completed if he pledges x. As discussed above, the donor requires a payment of $c=P(x)*x to cover the expected loss of pledging x when it wasn't necessary. If the project is not completed he only receives that payment of P(x)*x. If the project is completed, he additionally receives V and pays x. So, the expected return E(r) is:
E(r) = P(x)*x + P(x)*(V-x)
That simplifies to:
E(r) = P(x)*V
Since x must be less than or equal to V to avoid an incentive to sabotage, and P(x) is an increasing function of x, E(r) is clearly maximized when x=V. So, he should pledge his full value, V, if he is paid P(V)*V when his pledge his accepted.
Conclusion
To summarize:
- incentives for pledging solve the free-rider problem,
- donors-specified deadlines will encourage more donors to pledge more money
- pledge guidance will encourage each donor to pledge his full value for the project
Please email questions or comments to dean at brettle dot com.
|
|
a |
|