Once upon a time, I worked as a programmer in the R&D department of a large computer company. There was an expensive air-conditioned computer room with people whose job it was to look after the (then) cutting edge hardware. One day, we arrived for work to find that the equivalent of the main file server was down, and a number of engineers from the hardware company ware scurrying around the fancy computer room looking flustered. Of course, being a business environment, we were soon found some work to fill the time (filing papers or something) until after lunch when we were told the system was back.

Well, “back” is the word – back a whole week, in fact. The IT department took regular backups (monthly rotating copies – lost data may not be noticed for a while – off-site – in case of fire, etc. – daily incremental – changes since the last complete backup – and so forth) but it seems the contractors hadn’t been so careful. They had managed to wipe the main disc (or maybe it had crashed already) along with a week’s worth of backups. This was three days before the customer delivery deadline. Being a commercial organisation of course, they didn’t want to delay delivery, so it was down to the programmers to redo a week’s worth of programming and finish the project in the remaining three days (well, five in fact, as there was a weekend attached). It was, actually, a valuable lesson in the importance of backing up one’s work.

Zipping forward in time, to University of Leicester’s SWIFT project in 2010.

We have created two virtual laboratories in the virtual world of Second Life (SL) – not a small task. Now as before, we are trusting a third party to make suitable backups of that work (Linden Labs in fact, who run the Second life system). Now for all I know, they may have a backup regime to rival NASA. It’s just that, well, past experience has taught me to always make my own backups as well.

So I was very happy this week to find just how easy  SL backups can be. I used the independent (of SL) viewer “Imprudence” and simply selected “Export” from the pie menu. You can’t backup textures and scripts, or other people’s objects, but since we created everything we now have a directory from which we could restore the main parts of our virtual genetics lab should we ever need to.

But it gets better! I was investigating Imprudence because I was recommended a web page giving easy  instructions for installing Opensim (Opensim provides a free open-source virtual environment, largely compatible with SL).  In less than a couple of hours I recreated our virtual lab in our own Opensim environment – our own, private SWIFT.

There’s more . . . as my colleague Simon Kear pointed out, it should be possible to create a distributable single-user virtual world for anyone to use – a complete OER (Open Educational Resource), the virtual world and its project such as SWIFT, for download to a memory stick to run anywhere, no Second Life or even internet connection required.

Currently, we like to distribute “regular” OERs in several formats, such as DOC, PDF and e-book formats, so as to ensure they can be used by as many people as possible. That’s why it’s exciting to find we could distribute virtual world artefacts in a new way that anyone with a fairly new computer could take and use. Our OTTER project was very successful in setting up a streamlined mechanism for distributing OERs. As more is built in virtual worlds, maybe it’s time for “virtual-OTTER” – a project to incorporate virtual worlds into the OER fold.

OERs – the ultimate off-site backup!

Paul Rudman, BDRA