The Developer II: The Tennis Approach

Well, we're halfway though the old Cities Unlimited posts, and I've been making steady progress on illustrating the old articles; but lest we lose sight of the main point, today I'm taking a little time out for some further thoughts on how to select a developer.

If you'll recall, we previously talked about some different approaches for developer choice; essentially we need to find a balance between a purely fiat selection by the project board, and a purely democratic one by vote among the project members. I've been giving some more thought to this, and I'd like to propose a process that I think is mostly fair: I call it the Tennis approach, and here's how it works.

The heart of the process is that there are several phases of back-and-forth between the community and the board (like a tennis ball being hit between two players.) Let me break it down into the principal steps:

1. Developer Bids

As I discussed in the article on the Mandate, developers would be able to submit bids based on a predecided format. They would include things like their estimated costs (for completion and Phase One,) their technical qualifications (other games completed, team available or experience building a new team,) and their general design ideas, including how they would address the items in the Mandate. These would be submitted to the project Board of Directors.

2. Investigation

At this point, the board would be responsible for checking up on these submissions. The board members (or at least a committee of members) would take various steps to verify the claims made by the candidate developers; apart from fact-checking any information submitted in the bid, they would also contact the bidders for a preliminary interview, and if possible meet with the developer in person.

After this investigation is completed, the candidate bids would be publicly posted on the project website, along with the board's report; Either the board could post a consolidated report, or each member could record their own individual comments (or both.)

3. Public Voting

Now the ball would be in the community's court (so to speak.) Project members would have one vote per share to apply towards the developer choice. Between the time bids are submitted and the point where the project is ready to make a final choice, members would be able to read the developer bids and the board comments and submit their votes. Bids would then be ranked by which have garnered the most votes. One minor question here is whether the rankings should be publicly visible; there might be some concern about a feedback loop, where certain bids get more votes simply because they appear to be the most popular. But, one way or another, a ranking would be established.

4. Board Voting

From the community's choices, the board would now take the top ten entries and discuss them in a full meeting; Prior to, and during this, the members could request more information from the candidates and add it to the debate. After a given amount of time for discussion, the board members would cast three votes for their favorites, and the top three would be placed on a "short list" of finalists.

5. Final Selection

Lastly the three finalists would be given another audit by the full board, including a live presentation of their vision for the game and a face-to-face meeting with as many of the board members as is feasible. They would also have to submit a detailed business plan, including projected budgets, terms of employment, timelines, etc. After the finalists have had a chance to make their case, the board would make a final vote and select the developer for the game.

6. Community Approval

But we're not quite done yet... After the board makes its decision, the final choice would be presented to the community along with a report from the board members explaining their reasoning. At this point the community would have a chance to veto the board's decision: an up-or-down vote on the candidate, which would have to show at least a two-thirds majority (with abstentions being regarded as a tacit approval.) This would ensure that the community could vote down any candidate it strongly disagreed with. If that happened, the board would select another of the remaining two finalists and the confirmation vote would be repeated. If the vote succeeded, however, the final choice would become Metropolis's official developer.

I think this process would give us a fair selection based on what the community wants, while still safeguarding the decision-making process against fraud or appeals to popular sentiment without the substance to back them up. Let me know if you foresee any problems with this approach, or ways it could be improved!