Rethinking the Linear Funding Model

When first conceived, community funding for Metropolis was a fairly straightforward idea: collect money, hire a team, and make the game, with each step completed before the next begins.  As the project has taken shape, some problems with this concept have emerged, prompting me to rethink the paradigm a bit.  I want to explain what those problems are, examine some alternatives and their relative advantages/disadvantages, and consider how to they could be implemented in the current structure.
 
To start out, I'd like to reiterate the reasoning behind the original model (the "linear" model as I'll be referring to it). First of all, there is the risk factor. One of the big concerns for potential investors in this project is completion risk: fewer people want to put money into a project that has a possibility of running out of further funding and ending half-completed.  That's the point of using an assurance contract in the first place.  The linear model allays this concern by assuring that no funding will be collected until the total budget is in place, thus allowing investors to indicate support without commitment.  Another advantage is its simplicity: an assurance contract is a little counterintuitive at the best of times, and the linear model makes for a concise explanation of the principle (as above.)  I want to continue to bear this in mind as we talk about modifying the model, because both of these are important and powerful benefits which shouldn't be discarded lightly.
 
The weaknesses of the linear model are less apparent but potentially devastating.  The most significant is that it dramatically lengthens the timeline for the actual game to be produced.  Funding might take two or three years,  followed by a period of organizing the dev team, and  finally several more years for all the development. While obviously this is a negative in itself, on the surface it doesn't seem like a such a dire downside: after all, since no one is risking substantial capital on the project's success, our time goal can essentially be "as long as it takes."  In reality, though, too long a funding phase could have profoundly negative effects, all of which fall under the general heading of "loss of momentum" (or, "momentum risk".) For example
 

• Members who pledged early on may lose interest, lose confidence, or get hit by busses by the time pledges are called in.
• Potential new members might look at the project and think "After all that time, nothing substantial has been accomplished; why should I participate?"
• The long lead time for investors is a moving target; that is, every investment from the first to the last will have to be made in the face of at least several years wait to see an actual game.
• Competition could emerge from the commercial sector.  While a new game is always welcome, it could also mean decreased interest in an open source solution, even if it only partially fulfils community wishes.

In other words, momentum is critical for the project's success; steady growth of interest and support will make the project more attractive to new investors, which in turn attracts more support, and so on.  But if that cycle slows down, interest will stagnate and the funding level will begin to plateau.  And last of all, it goes without saying that we just don't want to wait that long.
 
Besides these obvious time scale issues, however, some other problems begin to manifest themselves when we consider the time sequence.  The largest one is the problem of making a proper budget estimate for the overall project; when I first wrote about this idea, I made a wildly approximate, back-of-the-envelope estimate of how much a game like this would cost; but when it comes to setting our actual funding goals, we need a much, much clearer number, otherwise we run the risks of either badly underfunding the project, or wasting time overshooting our goal.  Getting an accurate estimate, however, is contingent on receiving actual developer proposals and choosing the one that represents the best value.  But with this choice made, we want to be in a position to engage our developer as soon as possible; very few would be willing to wait an indefinite amount of time for their front-to-back budget to be collected.  For instance: We begin accepting developer proposals at a low but still substantial pledge level (say, one million); developers submit bids, and the bid we select specifies 9.7 million for the complete game.  If we then accept a bid in these circumstances, the developer would have to wait on the sidelines until the remaining 8.7 million is assembled.  Needless to say, this isn't a very attractive prospect and would likely discourage a lot of potential bids.
 
Last of all, we face the problem of an unknown market saturation point; in other words, there are a finite number of people who might potentially contribute to Metropolis.  But with no way of knowing what that number is, we run the risk of getting to a point where we have all the funding we are likely to get, but are still short of our goal.  In that case, we could end up stuck with little to no growth indefinitely, as we continue to wait for additional investment that won't be forthcoming. (Note, of course, that I personally think the city sim community is more than large enough to fund this project.)
 
So, clearly the linear model has some flaws; but what are our alternatives?  The most basic one is to collect donations directly, but that is no solution at all.  Trying to sell the idea of "give us fifty dollars now and maybe you'll get a game in six years" is hopeless; I wouldn't put money down on those terms myself.
 
The next-most-obvious alternative is to move to an iterative funding model: Break the development into broad "phases" to be funded one at a time.  This method has some good points: the cost target for starting development is lower, which means the project will move along faster.  Also, the continual release of prototypes and new code has the potential to spur further interest and increase the project's momentum: as each phase is completed, the next becomes a more attractive prospect for new investors, as x amount of work is already completed and the game is x amount of time closer to being finished.
 
So, iterative funding neatly answers all the concerns of momentum risk, but throws us back on our original problem of completion risk.  Although there are more discrete levels of progress, investors are still faced with the same question: what happens if this project runs out of money halfway? Will my investment be wasted?
 
The solution lies not in combining these two models, but in simply using both.  Rather than trying to select the best model centrally, we pass the choice on to the individual member. We can implement this by, instead of having a single value for pledges, giving members the option to make either "Phase 1 Pledges" or "Completion Pledges"; those who want to see production begin sooner and are willing to risk spending their pledge on an incomplete final product would be able to pledge to "Phase 1," a bare minimum budget for a core game framework.  People less willing to take that chance, or who aren't bothered by a longer timeframe, would continue to pledge towards the total, final budget. This means we can optimize contributions by the individual's level of risk tolerance.
 
To complement this system, we would instruct developers to structure their bids around this same principle; to include both a total cost estimate and a "Phase 1" or "Core" estimate as part of their proposal.  We could specify that this first phase would have the goal of producing the barebones game engine and the general architecture; The remainder (which might also be split up into phases) could cover the individual simulation elements, the game assets, and refinements to the interface.  On those terms, even an incomplete project would still yield a useful core codebase from which the community could proceed on a volunteer basis.
 
In a future article, I'd also like to address the market saturation problem I mentioned above. But for the moment, I look forward to hearing your opinions on this change; I believe using this dual approach will help mitigate both our completion risk and our momentum risk very neatly.