Julian Lombardi makes some terrific points about asset risk for virtual worlds on his blog. I think the issue is a pretty fertile area for exploration as we all continue to invent new ways of working together, but Blogspot simply doesn’t allow that much content in discussion, so I’ll have to fork it here.
I see the asset risk issue-space as breaking out into at least two dimensions:
* Bit storage vs bit usage
* Point assets vs context
Where Are the Bits? Obviously, the first requirement to protect your assets is to be able to access the bits that represent them. I think Julian is right that in principle, storing your bits on someone else’s system exposes you to a big risk that the bits will go away, and that one solution is to keep things on your own servers. I also agree with the opposite argument that is sometimes made: that the important thing in practice is to preserve the bits, and Software-As-A-Service hosts may employ better backup and availability practices than you and I do on our own. (In principle.) I gather that Metaplace and Lively were pretty good about the way in which they shut down, but it’s still awfully scary to not be in control. Of course, many advanced organizations doing virtual world development don’t have much control over their own institution’s IT hosting services. When Julian moved from U.Wisconsin to Duke, we all had a lot of trouble on both ends keeping Croquet going and the assets transferred! Yet having a reliable external service is no panacea, as the best of intentions and practices gives no guarantee that the hosts will understand a given project’s special needs (such as a deep appreciation of a university’s teaching and funding calendar), much less simultaneously accommodate all their user’s conflicting needs.
What Are the Bits? Once you’ve established some way to keep access to the bits, you want to know that you can still interpret them. For example, the program used to display and interact with the assets has to still be viable and backwards compatible with the bits. For “dumb” assets like 1D documents, 2D pictures or movies, or 3D models without behavior, this often means creating the asset elsewhere and then importing it into the virtual world. When the implementation lets you do this, you have complete control (and responsibility) for maintaining the original pre-imported asset. For some use cases, this may partially moot the your-host-or-mine? issue.
Context is King. I don’t believe that the value of virtual worlds is in individual content, but in context. The minimum implication for asset risk is that whole information-spaces need to be preserved in a re-useable way. Outside of virtual worlds, consider for example, that Google recently shut down an entire Orkut discussion board when they feared it was in danger of starting a riot in India. Even if you had used some technical or legal means of lowering the risk of lossage of any of your own contributions, the value in-situ is gone. For virtual sites, context also includes behavior (e.g., treating assets as objects rather than dead data).
The Innovative User’s Dilemma? Virtual worlds and realtime collaboration are in a rapidly changing pre-standards infancy. We’re all still learning what’s important, so we don’t yet know what to standardize. Furthermore, as Clay Christensen points out, a developing technology does not have sufficient performance headroom to be frittered away on fixed inefficient protocols, and so ever-changing (and often, alas, proprietary) interfaces will win out until such time as overall performance exceeds user expectations. I think the best strategy in such a situation is to run as fast as you possibly can: cover your bases where possible and ruthlessly eliminate anything that will slow down your time-to-deliver — or to re-deliver after some technical or other failure shuts down your intended path. For if you dawdle, surely, something inside or outside your organization will change.
State of the issue? My company is agnostic on the implications for bit-storage: Teleplace lets you host your own or use our servers. I’d like to think that our leadership in choices for hosting and server-on-a-stick, as well as on content import, has had good effects on industry expectations for covering your bases on fixed assets. But honestly, I still think that when the world is ready, a secure distributed file system is ultimately going to be a better bit-storage solution. Public real-time replicated data seems to me to offer the best combination of survival characteristics for both bits and context, independently of whether it is for 3d worlds, documents, or discussion boards. Alas, I think the technology and the driving factors for usage are simply not there yet.
I don’t know what the ultimate answer is for reducing the risk of loosing asset context and behavior. This is the realm of such ambitious projects as Xanadu. The state of the art at Teleplace is our persistent storage format, which lets you save any asset, grouping of assets, and whole spaces as compressed XML data. Objects are identified by class in such a way that an implementation can instantiate the appropriate class of object with arranged behaviors, or just dumbly represent the data if it doesn’t know about that class in the current implementation. Teleplace has provided a public spec for this, which allows for information- and context-preserving asset transfer between systems, but I don’t think anyone has adopted it. After all, everyone is just trying to run as fast as they can, and few implementers really have the time or inclination to work on such deep issues. (We did because we needed the flexibility to innovate on versions and behavior in such a way that older work isn’t lost.) And indeed, the Teleplace .c3z format doesn’t pin down a deep solution for persisting user-defined behavior. Our state of practice is for users to implement behavior as separate Python programs, for which we persist the program text in the same way as other documents, and the program instance data similarly to other context-dependent references. The Brie model that Julian and Josh and I built years ago was more “turtles all the way down”, but I haven’t yet had any reason to implement something like this for Teleplace.
