The reception to the news of Delicious’s new owners has been … varied. Marshall Kirkpatrick has written a post in favour of the transfer, but Violet Blue is not so sure. If you do a little bit of digging, you’ll see that the new Delicious has the potential to be far more restrictive on what you can, and what you can’t bookmark, especially where potentially offensive content is linked to. Offensive is a horribly vague and subjective term; one which means many different things to many different people.

At the heart of the issue is the difference in wording between the old Delicious terms …

The linked websites’ content, business practices and privacy policies are not under the control of Delicious, and Delicious is not responsible for the content of any linked website or any link contained in a linked website. (…) In accessing Delicious or following links to third-party websites you may be exposed to content that you consider offensive or inappropriate. You agree that your only recourse is to stop using Delicious.

… and the new ones …

You agree not to do any of the following: post, upload, publish, submit or transmit any Content that: (…) violates, or encourages any conduct that would violate, any applicable law or regulation or would give rise to civil liability; (iii) is fraudulent, false, misleading or deceptive; (iv) is defamatory, obscene, pornographic, vulgar or offensive (…)

If a complaint is made and if the new terms are upheld, you run the risk of having all your bookmarks removed, without recourse and without warning. Admittedly that’s a lot of ifs.

A cursory trawl through my Delicious bookmarks doesn’t seem to have anything obscene or pornographic, but there’s a lot of linked content which is fictitious and could possibly be deemed misleading or deceptive. As the saying goes, you can please some people, some of the time, not all people, all of the time. When you have terms of service which are vague and ambiguous, you can rest assured that someone will exercise their right to be offended. For now, I’ve authorised my old Delicious account to be transferred to the new service, but I’ve also taken a backup, just to be on the safe side.

What’s also unclear is whether the Delicious API and RSS feeds will remain; one of my web sites relies on these to dynamically update the site’s content.

While Delicious lives on, whether I’ll continue to be a user of the service or migrate to my own, self hosted solution, as I’ve already done with my URL shortener, remains to be seen.

So whilst I’m going to Nokia, I’ll continue to use my core set of Yahoo! products, tools and APIs … YQL, Placemaker, GeoPlanet, WOEIDs, YUI, Flickr and Delicious. Not because I used to work for Yahoo! but because they’re superb products.

That’s still true but the recent news of the closure, or shutting down, or selling off of Delicious has been one of those significant events that makes you sit up and take notice. In this case, it’s made me take notice of just how much I rely on the vague and nebulous technology we call the Cloud.

So before going any further, it’s probably worth stating my own, totally subjective, view of what the Cloud is. It turns out that it’s actually a fairly simplistic definition. The Cloud is any form of remotely access storage where we put content, with the addition that there’s frequently a service and/or an API built on top of that storage. More importantly, it’s all of this content we produce and store in the Cloud that the fate of Delicious has shone a spotlight on. A quick, off the top of my head, list of Cloud based content looks something like this …

• Emails at vicchi.org, hosted on my ISPs IMAP server … Cloud based
• Blog posts at www.vicchi.org, which hosts this post that you’re reading right now … Cloud based
• Photos, hosted on Flickr … Cloud based
• Shared files, hosted on Dropbox … Cloud based
• Tweets and status updates, hosted on Twitter and Facebook … Cloud based
• Slide decks, hosted on Slideshare … Cloud based
• Professional profile, hosted on LinkedIn … Cloud based
• Short URLs, hosted on vtny.org … Cloud based
• Bookmarks, hosted on Delicious … Cloud based

The future of Delicious has made me think long and hard and ask three questions. How much of this content is easily exported or stored elsewhere? How irreplaceable is this content? How at risk is the service hosting the content?

• My email? Not at high risk. I mirror all of my IMAP folders on my laptop which is regularly backed up.
• My blog? Not at high risk. I own the domain and I tend to maintain a mirror copy of my blog on my laptop and even if my ISP shuts down all my posts are easily exported and capable of being migrated elsewhere.
• My photos? Not at high risk, at least not yet. Although Flickr stores a lot of my photos, the master set is in iPhoto on a backed up removable drive.
• My shared files? Not at high risk. Dropbox automagically maintains a local mirror on each machine I use, which is backed up.
• My tweets and status updates? Medium risk here. Whilst there’s no sign of Twitter or Facebook shutting down, archiving and preserving my content here is challenging.
• My slide decks? Not at high risk. The master source of the decks is my laptop, which is regularly backed up.
• My LinkedIn profile? Medium risk. While LinkedIn allows me to export my contacts as far as I can tell there’s no way to export my profile and recommendations.
• My short URLs? Low risk. I own the vtny.org domain and the short URLs it generates are controlled entirely by me.
• My bookmarks? High risk. Even if Delicious is farmed out to another owner, confidence in the service has been severely dented but at least I can easily export all of my data.

A quick look at the list above gives me ample cause for concern. There’s a lot of content I rely upon that is hosted on Cloud services over which I have little or no control and which often offer no means of exporting that data easily, if at all. But it gets worse …

There’s a massive amount of reliance and interdependence on each of these services. My blog relies on other Cloud services, for example almost every one of my blog posts is illustrated either with an embedded slide deck from Slideshare, with an embedded photo from Flickr or both. This post is a classic example of that. My other web site, at www.garygale.com, is dynamic and is almost entirely reliant on my Delicious bookmarks for providing links to my content hosted in other Cloud services.

The delicious irony here (pun fully intended) is that while the internet and the web are massively decentralised, they’ve been used to create a whole set of centralised and silo’d Cloud services, a large number of which my web presences rely upon. In the case of Delicious, I’ll stick with the service for now, until its future becomes less murky but as with my short URLs, hosting my own set of bookmarks will probably be on the agenda for early in 2011, along with the resulting disruption and work this will cause in integrating this new service into my web sites. But at least I’ll be owning and controlling my own Cloud services.

They increase link sharing; the vast majority of social networking sites use 140 characters as the maximum size for an update, using the full version of a URL you’re sharing reduces the amount of space for you to put your own thoughts into the update. Just compare the full URL http://www.vicchi.org/2010/03/03/reclaim-and-own-your-short-urls at 65 characters against http://bit.ly/aG1RBx at 21 characters.

They can track and yield click and referrer information; the information that bit.ly provides is so useful, showing live clicks, geographic and referrer information amongst others.

But almost a year ago, Delicious founder and ex-Yahoo! Joshua Schachter made some pretty compelling arguments against short URLs:

The worst problem is that shortening services add another layer of indirection to an already creaky system. A regular hyperlink implicates a browser, its DNS resolver, the publisher’s DNS server, and the publisher’s website. With a shortening service, you’re adding something that acts like a third DNS resolver.

…

But the biggest burden falls on the clicker, the person who follows the links. The extra layer of indirection slows down browsing with additional DNS lookups and server hits. A new and potentially unreliable middleman now sits between the link and its destination. And the long-term archivability of the hyperlink now depends on the health of a third party.

Or to put it another way, you no longer own your links or the data clicks that those links yield. If the service dies, your links break, pure and simple, and that does happen, as the demise of the original tr.im and cli.gs services show.

But there is a way to take all the benefit that short URLs offer and keep ownership of your links and all the data that clicks on those links will give you and that’s to run your own URL shortening service, which is precisely what I’ve done with vtny.org which is running the YOURLS code behind the scenes. This gives me all the benefits and metrics that other URL shorteners provide but with the added and crucial benefit that I now own the links and the data they generate, in this case via the vtny.org/4 short URL.