This could also be titled “why I host this site myself.”
Part of that could be attributed to the fact that - well - I’m used to doing so, having hosted sites under my own server space since the mid-90’s or so. When I began this particular site in 2000, my weblog (though I didn’t use that term at the time) was powered by a simple content management system I created using little more than bailing wire and duct tape Perl and MySQL.
At the time, about the easiest way to go about such things was to simply do it yourself.
At some point, though, I decided that I was tired with tweaking my own scripts and moved on to an increasingly popular 3rd party weblogging tool - Movable Type. Instead of depending upon on of the various services that had started to spring up to facilitate weblogging (ie. Blogger, Livejournal), I opted to keep everything hosted under my own web hosting account.
My reasoning was thus: If one of these companies were to go bust overnight or institute some sort of asinine policy, I may very well lose access to my creative efforts.
In the last several years, though, a number of so-called “Web 2.0” services have sprung up. Whereas before I could pretty easily do whatever the remotely hosted services did but better, the interconnectedness of these tools - things like Twitter, for instance - has made them far more attractive than the remotely hosted services of the past.
Unfortunately, though, the same problem remains: Control of content.
Companies can still go under. They can still institute ridiculous policy shifts, leaving people stranded. Things are improved significantly these days as many of these tools offer APIs and things like Atom and RSS feeds, but quite often there a lack of tools exist to migrate or back up your data. Obviously the companies themselves (as a rule) aren’t going to expend much effort in helping - they benefit from lock-in, after all - and the community at large seems rather oblivious to how precarious their situation is.
Besides, export tools aren’t nearly as sexy a project to work on as, say, a Google/Flickr mash-up.
With this most recent site revamp I’ve opted to integrate a handful of these services/tools/APIs (so far: Twitter, Flickr and Spore’s own creature feeds) into my site, but the question remains: how much control over our data do we really have? Once EA milks Spore dry and kills the online integration (they’ve done that sort of thing before), will peoples’ creations go along with it? What about Twitter, who has already seen fit to do away with various feeds without prior notice?
Obviously, telling a company “don’t go out of business” is of limited utility, but it seems to me that this is something we in the interconnected “web 2.0″ world of mash-ups and remotely hosted applications should think long and hard about.
…
What got me thinking about this was Scot Hacker’s recent post (yes, that Scot Hacker, from the BeOS days of yore) about the lack of open APIs for Geocaching.com.
This is something I personally ran into recently during my recent redesign project as I investigated integrating geocaching information into the site. I’d have loved to have a section containing my most recent found caches - without having to manually write them up, as in the previous version - but was surprised to find that geocaching.com still - in 2008 - does not have any sort of feed or API to pull this information from.
That alone - while sub-optimal - isn’t even so bad, but they’ve actively put roadblocks up when others have offered to do the job for them via content scraping. They feel - inappropriately, in my opinion - that they are the sole owners and users of factual data submitted by damn near everybody involved in a popular outdoor activity, even to those peoples’ detriment (surely there’s a huge audience for a native geocaching client for the iPhone).
Nobody thought of these sorts of things when geocaching first took off in 2000, and the site took off through sheer inertia - but perhaps geocaching.com users should reevaluate it now, before what is merely backward user-hostile adherance to policy results in that data being lost forever.
/2008-07-21%20at%2018-23-14.jpg)
/2008-07-21%20at%2018-09-50.jpg)
