Voting and Membership Privileges

As we move forward with the project, the next major task on the agenda is putting infrastructure in place for the subsequent stages (the pledging and voting interfaces being the major items.)  Prior to implementing that infrastructure though, we need to give some consideration to membership, how it's defined, and what privileges it confers. Like the previous article about developer selection, this issue requires us to descend into some rather murky philosophical waters to get grounded; I've been doing a lot of thinking on the subject lately, but unfortunately the only conclusion I've been able to reach with any finality is that absent any objectively "best" approach (thank you, Dr. Arrow,) we will have to approximate a fair solution as best we can.

The Basics

The basic principle of Metropolis is that ownership, and thus control, of the game should rest with the community; our starting point is therefore to define who makes up that community and what form their ownership takes.  Let's start with that definition: "the fan community" is a term that gets thrown around a lot, but it can variously describe several overlapping groups:

• People who play and enjoy city-building and city sim games.
• People who participate in the social culture centered around city sims.
• People who buy, create, or improve city sims.

In practice there is massive overlap among these groups, but only one is really significant for our purposes.  Without the last group, the other groups cannot exist; thus we can identify this group as the stakeholders of the community.  For Metropolis we apply the same principle: control over the end product should lie with the stakeholders whose labor or capital make it possible.  In practical terms, this means that voting membership in the project should be limited to those who contribute.  And, since this project is based on a financial solution rather than a volunteer one, we can refine that to specify that membership be contingent on donating or pledging.

Thus far we are on pretty firm ground; but with this established the hard questions start to crop up.  The first is:

One Man or One Share?

Our first issue is constituency: whether voting should be by person, or by share.  Either we can give all members the same voting rights, or we can allow greater influence to those who make greater contributions by allocating voting rights per share. Arguments can be made for either method: In the first case, the benefit is that average enjoyment is theoretically maximized for each player, as the finished game would most closely reflect a balance of every member's desired features.  On the other hand, however, it seems unfair that a member who contributes ten times as much has the same input as one who contributes the bare minimum.

There's merit to either side, but I am inclined to lean towards the latter solution.  Why?  Well, consider the way democracy works in society at large.  For most democratic governments, the principle of "one person, one vote" is considered sacred; but we need to take into account that citizenship is mandatory (a person can't opt out of laws if they don't like them), unique (a person cannot replicate themselves) and based on mere existence rather than contribution (everyone, on an individual level, is affected equally by the same laws).  Only the last of these conditions applies to membership in a software project: no one is forced to be a member; and since (as we established above) membership is based on contribution rather than simply being present, an individual can effectively "replicate" themselves by buying multiple shares (or, to look at it another way, there is no effective difference between one person buying two shares and two people with the same ideas buying one each.)  Since the game will not be possible at all without funding, it only make sense that it be made largely to the spec of those paying for it.

With that said though, I don't think we can disregard the counter-argument: even if a person buys ten shares of the game (ten "copies" to put it in conventional terms) they are, at the end, having one individual experience, no more or less than someone who only buys one (just as everyone is bound by the same laws in society no matter how they vote).  To take this to a reductio ad absurdum, if we can imagine some rich eccentric donating more than half the funding and then using his influence to dictate a Sim City Societies -like game, I don't think we could accurately claim it as a "community" effort anymore.  And one last point on top of this: sometimes the best things about games are the things we didn't even know we wanted beforehand; we have to level the playing field somewhat for other members' ideas and contributions to take shape, and give Metropolis the capacity to not only meet our expectations, but surprise us.

So, on the whole, I feel a compromise solution is best.  What I would propose is to allocate votes per share, but to have a ceiling per individual member, perhaps around the ten share mark.  This would incentivize members to make larger contributions, but would prevent any single individual from gaining an unfair amount of decision-making power.

Running with that assumption for the moment, let's turn to the next issue:

Timing

The assurance contract model, for all its elegance, does present us with some troublesome quandaries, as I mentioned here.  In this case, we are facing an issue of timing: when does a person qualify for membership? Since membership is based on monetary contribution, the obvious answer would be: "when they pay."  But that presents a problem when using a pledge system: no one pays until development is ready to start; but decisions need to be made and acted upon long before that point. Furthermore, it opens the system up to being gamed: what's to prevent every single member from pledging the maximum amount for vote allocation, only to retract or underpay the pledge at collection time?  Obviously, votes from individual members will be tracked, and the tallies adjusted according to changes in voting status.  But in some cases, this may be too late, as the decision will have already been carried out (choosing a developer, for instance).

What we need is some kind of validation that pledges will be met.  Fortunately, there is an easy way to accomplish this: make some member privileges contingent on verifying payment details, even though no charges would be made.  This would not entirely solve the issue, but it would greatly reduce the scope for frivolous or insincere voting and pledging.  Naturally, though, we want to approach this carefully, as its in our interest to make pledging as simple and painless as possible.  Here is what I suggest:

We implement two tiers of membership, along the lines of "confirmed" and "unconfirmed".  Anyone could become an unconfirmed member simply by pledging; this would allow access to the member areas of the website and participation in the features voting.  However, there would also be limitations: unconfirmed members would be limited to a single share's worth of votes, regardless of pledge amount.  Furthermore, they would not be able to vote on issues surrounding the project's internal direction, such as board elections.

An approach like this would benefit everyone; individuals could commit to the project gradually, and at a level they are comfortable with; new members could test the waters while still participating in the development process, while those more committed would have increased privileges; and for the project leaders, it would remove a lot of the uncertainty about how reliable members' pledges are and give a clearer picture of the project's status.

Which leaves us one last issue to address:

Longevity

One of the first articles I ever wrote about the then-unnamed Metropolis Project touched on the subject of what happens post-release.  And just as it was then, it seems terribly premature to talk about the end of what's barely gotten started.  But by clarifying some of these issues now, we can avoid a lot of misunderstandings and ill-feeling later.  So, our question is: what is the term of membership in the project?  How long does a person's investment qualify them for membership?  By leaving this point unspecified, we default to what people will assume unless told otherwise: forever.  But this isn't a particularly viable option, as we'll see below.

Let's stop for a second and talk about some possibilities after the game's release. One option is to take the game as-is and revert to an entirely volunteer-based project. In that case we will need to determine new criteria for project membership, since new members would have nothing to pledge to.  Alternatively (and I think this is the best possibility) we can begin gathering new pledges for expansions to the initial game; if community funding proves successful, there's no reason to stop using it and go home, we can continue to expand and improve the game according to the membership's willingness to fund new iniatives.  As an open source project, Metropolis needn't be tied to the one-off paradigm that defines boxed game titles; we can continue to build and renew the game iteration by iteration.

Whichever future lies ahead of us, we will need to make a decision about where membership stops.  If a one-time contribution to the project buys membership in perpetuity, the value of membership will eventually become so diluted as to erase any incentive for new members to join and contribute.  If we view investment in Metropolis as the cooperative equivalent of a game purchase, does it make any sense for a person who bought a game ten years ago to still be considered a customer, forever?  No, a person who buys a game makes an exchange of their capital for the product, and an expectation of support for a reasonable period of time.  In the same vein, contributions to Metropolis are for the purpose of receiving a game to play, and it's not particularly sensible to expect a say in all future project decisions once that game is in hand.

My preferred solution is this: In addition to the current pledging and donating, we create an option for subscriptions.  Subscriptions would be paid monthly, with the amount being equivalent to one share value annually.  Subscription would automatically entitle a person to full membership, which would be permanent after reaching the one-year threshold but revoked if the subscription was cancelled prior to that. With that in place, we specify that voting membership in the project is granted up to the official release; at that point, only active subscribers would continue to be full project members. If we decided to continue full-time development, pledging could be opened at that point for the subsequent "expansion" with the same rules as before, for the duration of that project in turn.

While some of these issues are a little tricky, I think the solutions I've outlined are generally fair; But if you have a differing opinion, or see a problem I haven't anticipated, please share!

Coming up in a future article, I want to dive a little deeper into the headache-inducing issue of specific voting mechanics, and address more closely how we determine an "official" release.  In the meantime, leave your two cents below!