I’m thinking of doing a crowd funding campaign for Conjecture.

One of the things that makes this a nice proposition is that there’s an almost unbounded amount of work I can do on it, but there’s also quite a nice finite core that it would still be very useful to make really good and would take much less time.

However how would I decide which of the unbounded work to do? The classic model seems to be stretch goals. I hate stretch goals, particularly ones where the stretch goal required to make it useful for you is 2 or 3 items down the list (I’m looking at you, people who put android support as a stretch goal).

The obvious answer is to let people pay for work. I was originally thinking in terms of reward tiers there, but I’m not a huge fan of that. If I declare that, say, ruby support costs £3000 and 300 ruby developers are willing to chip in £10, I should do ruby support. That seems like exactly the point of crowd funding.

So I started sketching out how I’d like this to work and came up with a system I’m pretty pleased with. I’m not sure if it’s a good idea, but it’s a nice design, so I thought I’d share.

It’s based heavily off the single transferable vote method of proportional representation but with some tweaks to fit the problem.

Usage: When creating a campaign, you set an “initial cost” figure (this should be the same as your campaign goal). You also specify a list of additional features, in your personal priority order, with costs attached to them.

Every pound (dollar, euro, whatever) people contribute to your crowd funding campaign then gives them voting power to choose which of these features is implemented. They vote by simply listing their feature preferences in order of most preferred to least. They can list as many or as few of the features as they like.

First, everyone pays for the initial cost you set. Everyone pays the same fraction of their contributuon, chosen to exactly match the cost

Voting now proceeds in rounds. In each round there are a number of active features – inactive features have either been chosen to be implemented or disqualified. Additionally each voter has a set of remaining funds, which starts at the amount they contributed and is reduced as they pay for features.

Each contributor votes for their current most preferred active item. If they’ve run out of active items they care about they vote for your most preferred active item (this part ensures people that you don’t get “free money” – as much money as can be spent on features will be spent on features, it’s just that if people don’t express a preference you get to choose).

Now, some features may have been funded: Any feature for whom the total remaining funds of the people voting for it exceeds its cost is funded. The feature is chosen to be implemented and marked inactive. Anyone who voted for it now has their remaining funds reduced by the same fraction, so that just enough is spent to cover the cost. E.g. if Ruby cost £3000 and there had been £6000 available funds, each person voting for it would spend half their remaining funds.

If no features were funded, one of the features drops out. Take the feature that is furthest from being funded (i.e. cost – funds allocated is highest), breaking ties by picking the one that is lowest in your preference order. This is disqualified and marked inactive.

This process is repeated until the total funds remaining is smaller than the cost of any active feature.

If it’s also less than the cost of any feature that was not chosen, stop. Otherwise, start again from the beginning with the current remaining funds and only the set of features that were not chosen previously.

Repeat this until you make it through an entire vote without choosing anything. At that point just fill in the remaining features in order of your preferences.

Design notes

1. It is a little complicated, as there are a bunch of edge cases I noticed when writing this up, but I think it’s simpler to use than to describe, and most of those edge cases contribute to making it better for both you and the contributors.
2. I’m not sure how essential the use of the preference list is. Certainly the “uncast votes go to your preference list” is quite useful, because it lets you shape the results in your direction while still complying with peoples’ wishes – e.g. if Ruby and Lua both cost £3000 and currently have £2500 voting for each, but I prefer to do Lua and now have £1000 in my spare change pool, I get to choose Lua.
3. The multiple repeats thing is annoying, but it feels unfair to just go straight to the preference list.