The first time I stayed in a hotel was when I was 12 and I and my brother met my father for holiday in Hawaii. We’d stayed in motels before–this was the era of the auto vacations–but never a multi-story hotel, where you accessed your room using an elevator.
When we got to our room, my Dad took us out into the hallway and pointed out the Exit sign. He told us that if a fire happened, we should not use the elevator. Instead, we should look for the Exit signs and follow them out of the building.
Since that one trip, I briefly pause at my door and locate the nearest exit before entering my room in hotels.
That trip was also the first time I flew on a plane. It was wonderful–scary and exciting. When the stewardess talked about what to do in case of an crash landing, I paid attention. To this day, I still pay attention–not because I don’t know what to do (butt, meet lips), but because it’s rude to ignore this poor soul who has to go through the motions. Shades of fatalism aside, I do check to see what is the closest exit when I find my seat. Old habits are hard to break.
My check for the exit bleeds over into my use of web services. No matter how clever a service, I never use it if it doesn’t have an exit strategy.
Recently, I took a closer look at the possibility of using Feedburner for serving up my feed. Now that I’ve moved my photos offsite to Amazon’s S3 service, the feeds are now the most massive bandwidth use. With my new austerity program of minimizing resource use, the use of Feedburner is attractive: let it serve up the feeds, with its much more efficient use of bandwidth.
My first thought, though, was: what’s the exit strategy? After all, it’s easy for me to redirect my feeds (all but the RSS 1.0) to Feedburner: I can adjust my .htaccess file to redirect traffic for all requests that don’t come from the Feedburner web bot. But what happens if I decide to bail on Feedburner?
This question was asked of the Feedburner staff last year, and the organization responded with an exit plan. It’s a month long process where you can redirect from Feedburner back to whatever feed URI you want. At the end of that time, all aggregators should have an updated feed URI–all without people having to manually edit feed subscriptions.
As such, I’m trying the service out, see how it goes. I know that if I decide I don’t like it, I can bail. If the worst case scenario happens, with Feedburner going belly up, then people know where to find my weblog and will have to manually edit their feeds. That’s also an exit, albeit more like jumping out a window than walking down stairs.
When I used Flickr, the API was what sold me on the service more than anything. When I decided to not use Flickr, the first thing I did was use an existing application to export a dump of all the original images, to ensure I had a copy of each. If I wanted to, I could also export the metadata and comments. I then ran an application to make an image capture of all the photos I had linked in my web pages, saving the photos locally still using the image names that Flickr generated.
I created a program that then converted all Flickr, as well as other photo URIs, to using one local URI: http://burningbird.net/photos/. This is redirected using the .htaccess to Amazon S3. If I decide to stop using Amazon the exit strategy is very simple: run an API call and pull down the images into one location; stop redirecting to that service and either host the images locally, or redirect to another storage service.
I use Bloglines, but I can easily export my subscriptions as OPML. Though it lacks much as a markup vocabulary, OPML is becoming ubiquitous as a way of managing feed subscriptions. I can then use this file to import subscriptions into Newsgator, or even a desktop hosted tool, like NetNewsWire.
I won’t use a hosted web service like Typepad or weblogs.com. It’s too easy for them to decide that you’re ‘violating’ terms of service, and next thing you know, all your weblog entries are gone. I saw this with wordpress.com in the recent events that caused so much discussion: in fact, I would strongly recommend against using wordpress.com because of this–the service is too easily influenced by public opinion.
I don’t use either my Yahoo or Gmail mail accounts. Regardless of whether I can get a copy of my email locally, if I decide to not use either account I have no way of ‘redirecting’ email addresses from either of these to the email address I want to use. (Or if there is a way, I’m not aware of it.) Getting a copy of my data is not an exit strategy–it’s an export strategy. An exit strategy is one where you can blow off the service and not suffer long-term consequences. A ‘bad’ email address is definitely a long-term consequence*.
Instead, I have a domain, burningbird.net, which I use for everything. I will always maintain this domain. My email address listed in the sidebar, will always be good.
There was a lot of discussion about Yahoo Pipes recently. Pipes is an interesting innovation, and excellent use of the Canvas object–my hat’s off to the creators for their UI design. However, the service has one major drawback: it’s a hosted solution. If you want to ‘export’ your Pipe, you can’t. There’s no way to generate, say a PHP application, from the Pipe, which creates the web service requests for you that can be run locally. No matter how good and interesting the service–there’s currently no exit strategy.
Anytime you find yourself saying, or even thinking, how ‘dependent’ you are on a service, you should immediately look for the exit strategy. If there isn’t one, decrease your dependency. The web is an ephemeral beast; the path of least resistance is 404, not 200. All pages will end someday. The same can be said for services.
Where are you vulnerable? What’s your exit strategy?
*An option for email is to use a local email address, and forward all email to Yahoo or GMail.