A Second Life for Old Code

Official Linden Blog » Blog Archive Embracing the Inevitable «

If you haven’t heard, Linden Labs, makers of Second Life, has “open sourced” its client code today (some of which I contributed to, way back when). This could potentially be a bigger move for openness than when they decided to revert content rights back to their in-world authors. On the other hand, it could potentially be a more disruptive move than when they opened free registration and swelled their numbers to two million virtual virtual inhabitants (the number of real virtual inhabitants, i.e., those who visit once or more and contribute to the economy, being much lower).

The first thing this does is it permits anyone with a C++ compiler (which is anyone who knows how to use a C++ compiler) to make cool new clients that do cool new things. The Linden protocols had already been reverse engineered, at least as of this version. There were hints that the next version would be entirely different anyway. But making cool new things is what innovation is all about, and the source makes that much, much easier. Companies like Electric Sheep are now much freer to customize, make new and better user interfaces, add special features and so on. It could be incredibly exciting.

But the danger is fracture. What happens when custom client A supports one cool new feature and B supports another? Ideally, one could pick and choose the best of both. But tell that to proponents of the various flavors of Linux in active development, or the user interfaces that vie for attention and acceptance. Camps emerge and later compromise becomes more difficult. And what happens when client A supports a cool new feature that’s totally invisible to anyone using client B? The world itself becomes more and more solipsistic. And that seemed to be the one thing Linden Labs was always trying to avoid.

What would actually do more good than the literal source is for Linden to create a system whereby improvements in all of the emergent clients can be aggregated and distributed to users in a straightforward manner — a kind of roll-your-own client kit, with an official channel for improvements to migrate back to the community.

Plugins do that for browsers like Mozilla. You can download the source for Mozilla and make changes, and ideally release them back to the wild. But if you want to drive adoption of your changes, the best route is to make a plugin for the common trunk that everyone runs. For Linux, Linus Torvalds does a lot of the work of picking and choosing which new developments make it into the core, blessed version. I’m not sure that Linden has signed up for that, or if they’re just dumping a big tarball and saying, “here you go.”

But I’m eager to see where it leads.

Leave a Reply

Your email address will not be published. Required fields are marked *