Structure

Having already covered membership and voting, I'd like to finish up the last major piece of the project charter draft and talk about the Board of Directors. The board is a vital component of the project: they oversee management, make top-level decisions about the project's direction, and in general serve to make sure the interests of the project members are being represented. I've already touched a bit on the board's role in selecting a developer previously, but today I'd like to establish more clearly how the board will be structured and its more general responsibilities.

Continuing on with the project charter, today I want to outline the sections related to voting mechanics. As discussed in several previous articles, the voting is going to be split up into three main areas: general votes, design voting, and leadership voting. There's still a lot that's open to change for these, particularly the exact voting methods used in each section; But we can always amend them later once something basic is in place, and we get a better sense of the overall voting dynamics.

Recently I've been planning some new features for the website; but before putting too much new infrastructure in place I want to have some clear guidelines in place for the project's overall structure, and make sure the website corresponds to them. To that end, I'd like to get at least a draft version of the project charter down in writing. In the next couple articles I'll be drafting a section at a time and posting them, in case anyone has last minute input or comments. To start, I want to sum up what's been discussed so far about membership: how to become one, what the conditions and privileges are, and what different levels there will be.

A complaint that's become increasingly common with new games is that they don't feel "finished". Look around the forums of almost any newly released game and you'll find a post to the effect of "I paid for a complete game, not a beta!" Reviews of "has a lot of potential, but feels like a work in progress" are not uncommon, even for high-profile, big-budget games. While I think part of the blame for this trend lies with publishers who push games out the door too soon and developers who don't spend enough time on testing, it's also an inevitable result of increasing complexity, both in terms of games and of hardware. It's simply impossible for a game to run perfectly on the nearly limitless combinations of hardware and software that make up the PC landscape. Game companies have to make some sort of compromise in order to release a game in a timely manner at a price people are willing to pay. An open source game, on the other hand, is always considered a work in progress. Short release cycles and small iterations foster the feeling that the end product is a continuous process of improvement rather than a monolithic single product. There are bugs, of course, but user tend to be more tolerant of them: they know that bugs are (at least in theory) in their power to fix, without being hostage to the original developer for changes to the code.

Metropolis falls somewhere in between these two cases. The game itself, being open source, will be improving continuously; In a sense it will never be "finished". But the development model we're pursuing, which asks users to fund the game by "buying" shares, also demands that there be a definite release, where a final product is delivered to the "buyers". The question I want to address today is, how do we determine what constitutes an acceptable point for an official release?