These "slides" are a bit of a misnomer. I talked without visual aids, for about five minutes in all. Still, I'd like to give those who were there a more permanent record of my remarks, should they want one. While I'm at it, I'm going to take the opportunity to revise and extend my remarks a bit.

For the details of those claims, see James Grimmelmann, Virtual Worlds as Comparative Law, 49 N.Y. L. Sch. L. Rev. 149 (2005).In my defense, I wrote that article in 2003.

In my day job, I'm a law clerk. I'm required to uphold the dignity and impartiality of the courts. Even when I'm being non-contentious, I don't speak for my judge or for the courts.

Code-level governance destabilizes the relationship because it becomes more difficult to trust the technical administrators. Their motivations for making a given change are always open to question, as are the motivations of the people asking them to make that change. I explain this idea at more length in Virtual Power Politics, an essay forthcoming in a book of essays from the first State of Play conference.

Churn increases bugs because software is complex and it's hard to get a complex system completely right immediately. The more you change, the less of your time you can spend actually fixing old bugs and the more opportunities you have to introduce new ones.

The final point is perhaps the most subtle. Clay Shirky's A Group is its Own Worst Enemy gets at the idea. Groups define themselves, in part, through their crises. Big contentious decisions are part of how a community figures out what it is as a community. If you take away the difficult back-and-forth of a decision, you may also take away the opportunity for the members of the group to learn from the decision. In thse debates, they can learn who they are, what the other members of the community care about and why, and what the community as a collective stands for. Don't underrate the value of these foundational conversations.

Linden Labs repeatedly emphasizes that Second Life is a platform, not a game. They say that they want participant-driven creativity to be what makes it worth being part of Second Life. They also emphasize the importance of community. They have made many changes in response to player requests -- most notably the changes to the tax system. But they don't want to be in the business of resolving every dispute that comes up in Second Life.

Their experience emphasizes the critical point about technical coordinators: You can't live virtually without them. Someone has to control the plug. The best you can hope for is for that someone to do a good job of facilitating what the entire group of players wants the world to be on a technical level. If they do their job well, the software running the world will smooth social interactions and enable people to come together virtually in productive ways. It'll be easy for people to deal with problems, to consult each other in coming to decisions, and to understand who they are as a collective. So technical coordination matters for community creation . . . but it's just not the first place to look to deal with the social issues of the world.

(A deep-thought issue for the long-term, one that many Second Lifers are already deep-thinking, is how the role of technical coordination itself will change as virtual world technology moves to a more distributed architecture. Will it be possible to avoid having one authority over the rules of the world? If so, how will the individual technical decisions of the different players be combined into a coherent shared world? I don't know the answers to these questions, but I'm looking forward to seeing what you come up with.)

If technical coordination has bad side effects, then try to do as much as you can with pure social interaction. If that doesn't work, you can always fall back to changing the code. But the longer you resist falling back, the better things will go. You'll understand issues much better before you go changing the rules of the world. You'll be forced to engage with each other and to engage in great acts of collective creation. You'll keep the coders doing what they do best. And you'll find out that a great many problems can be solved without any software engineering at all.

These are the consequences that I think follow naturally if you start from the hypothesis that code-level governance is the second-best option out of two.