I have previously described that when you make use of third party Web 2.0 services you need to acknowledge the possible risks: yes, if you use Google Docs there are risks if Google goes out of business or the Google service is down. I have been willing to take such risks, especially with well-established and well-used services such as Google portfolio of services and other services such as del.icio.us and Slideshare.
But what about less well-known services? What happens if such services do break? After all, as my colleague Paul Walk has recently pointed out and “there is a growing, commonly-held belief that we are about to enter a global recession” and as “venture capital can become harder to find in a period of economic down-turn” Paul asks “is this a good moment for HEIs to begin a brave experiment with outsourcing services to remote companies?” .
An example of a Web 2.0 service which has become broken happened to me recently. In January 2007 I came across the Squirl service. I wanted to explore a number of Web 2.0 services, so I used Squirl to keep a record of the books I was reading. The service has links to Amazon, so I simply need to type in the title of the book, select the appropriate version and it will store a description of the book, including an image of the cover.
That was fine until and by February 2008 Squirl was keeping a record of 42 books.
But when I finished reading the next book, I found that the link to Amazon had stopped working. I thought no more of it (it wasn’t a mission critical service, after all) but went back to several times afterwards, after reading more books.
Eventually I went to the Squirl groups and discovered a series of messages complaining about the service, as illustrated. And unfortunately there has been no response to any of the messages from anyone working for Squirl. It was also unfortunate, I felt, that Squirl didn’t provide a blog about their service, which I could add to my RSS reader and use various RSS filtering tools to help spot any worrying announcements or concerns raised by the users.
I can still create entries manually (although this does not pull in the images from Amazon). But as the service was still working apart from retrieval of the metadata from Amazon I wasn’t too concerned, especially as I had checked that there was a data export function when I signed up for the service. But when I tried to export my data as a CSV file I got the following error message:
Sorry, we screwed up.
An email has been sent to somebody at squirl, and we’ll try and fix the problem as soon as possible. You might be able to find what you were looking for with the search engine above.
If the problem persists, please contact firstname.lastname@example.org.
And rest assured, somebody is going to get a permanent letter in their file for this. I mean, heads will roll.
I first saw this error message back in February, I think, and I’m still getting the same message in August Even worse, when I send an email message to the address given above I find that the email address no longer exists.
Fortunately as the service provides an RSS feed of my data I have been able to retrieve my data. But this experience has helped to identify a number of approaches which one should take to help minimise such risks in the future. I think ideally the steps would be:
- Find out details about who is providing the service. Is it well-funded? Is it likely to, for example, be sustainable through the current troubled economic times?
- Does the service allow the data to be exported? Can the data be exported in a rich format, allowing the service to be recreated without too much difficulties?
- Check the data export functionality and import into a new service.
- Possibly replicate the data in a complementary service (note this is something I do with this blog).
In addition to these points related to the service and the data I would also look to see if the service provides announcements and discussions using blogs rather than, as in this case, forum software as I add feeds from the third party services I use to my blog reader which allows me to periodically check for any untoward discussions in a single place.
It might be felt that having to implement such processes for any Web 2.0 service could be very time-consuming. But, of course, across a community we are likely to find uses of such services being made by others. So perhaps what we need is to make use of social networks to share our experiences, and have mechanisms in place to alert others to any possible problems (and I’m alerting other Squirl users of problems with the service 6 months after I first spotted them).
Of course, in order to ensure that we have our risk assessment processes in place we will also need an audit of the services we use. That’s a topic I’ll discuss in a future post.