Gordon Mohr suggested in a comment that as a name Dominant Assurance Contract is no good and perhaps “refund bonus” would be better. That may be right, though “refund bonus” seems to only describe part of the arrangement.
I conducted a brief search for alternatives, unsatisfactory apart from discovering that the term reverse bounty was recently (April) used to describe an offer by a programmer to develop a feature when a certain amount of money is raised (a bounty is offered by someone requesting a feature). At least one reverse bounty successfully raised the amount requested. I cannot tell what happens to contributed funds in the case where the amount requested is not raised. Notably for the successful reverse bounty the developer said they would ‘top up’ the money and ensure the feature got built. A subsequent reverse bounty seems to have raised nothing so far, perhaps in part because it does not appear to come with any guarantee (also the proposed feature is probably has a narrow audience and the reverse bounty is being called a “request for funding”–true, but very dull).
An assurance contract returns contributions (or cancels pledges) in case the amount requested is not raised. A dominant assurance contract returns contributions plus a failure payoff or refund bouns, making it worthwhile for interested parties to contribute even if they believe the contribution threshold will not be met. Both concepts could easily be applied to reverse bounties.
The second reverse bounty was basically cancelled…I talked it through at the post on Drupal.org, and basically consider it to be “cancelled”. I would also have done a top up if interest had been shown.
The key factor seems to be making sure that there is a true desire for the feature, and to appropriately scope the product so that it meets a broad range of needs.
As for various payment/non-produce clauses etc…..well, I would say keep it simple, otherwise you’ll spend more time fielding questions about the donation process than actually getting something built.
I have little doubt that adequate demand is the key factor.
KISS is certainly a good approach, but I don’t think “you’ll get your money refunded if we don’t raise enough” is very complicated. If anything its a simplification, as it removes an undefined outcome.
The refund bonus idea (different than a non-produce/performance clause) is more complicated, but it seems useful in at least two respects: 1) it establishes that the developer is serious and 2) it may attract interest to a feature that isn’t obviously in high demand, but the developer believes would be in high demand if people gave the feature some consideration.
Someone with already excellent standing in a community may not need to offer such assurances to raise small amounts of money, but I suspect that anyone who doesn’t have a long track record and/or anyone attempting to raise significant amounts of money for a project would increase the chances of their request for funds’ success by making some promises.
Contribution towards public goods is modeled with game theory in Alex Tabarrok’s paper, which makes clear how assurances change the expected utility of contributing toward a public good for people who desire the good (“feature” in the case of extending software).