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).

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.