The announcement this afternoon that URL shortener tr.im would stop service immediately and eventually get rid of all its data sparked widespread discussion in the blogosphere today, as evidenced by all the stories about it clustered on Techmeme. URL shorteners provide a surprising amount of convenience to the average Internet user including links that don’t break in e-mails, are friendly to microblogging services like Twitter, can be read easily over the phone, or sent via SMS. And if a microblog service lets users create accounts, it even aggregates all the links that are shortened forming both an activity archive and social bookmarking service, though it increases long-term reliance on the service as well.
To see how embedded into the Web ecosystem that URL shorteners have already become, just read about the impact that tr.im’s demise had to Robert Scoble, including the (eventual) loss of the majority of his historical tweets. For his part, Dan Frommers says that you just shouldn’t rely on URL shorteners to preserve your data. But increasingly, that’s just not an option. As microblogging gets more and more important and widely used, and even starts moving into businesses with tools like Yammer and SocialText Signals, URL shorteners will be required to get the most out of these platforms. This is true beyond microblogging as well: On the modern social Web, long URLs are just messy, inconvenient, and clutter up the conversation. So increasingly, you’ll have to find a way to pick a service that you can do business with and which will stick around.
For example, Frommer recommends using a URL shortener service that lets you take your data with you if you decide to leave (or if the service goes out of business.) This is a smart recommendation, but one that is extremely hard to follow because incredibly, almost no service today provides this option, despite many years of talking about the need for data portability to head off these issues.
For example, one of the most popular, feature rich, and in my opinion best URL shorteners, Bit.ly, offers no data export option (at least that I can find after 15 minutes of looking). The data can go into the app, but it can’t get back out unless you arduously scrape it. This is extremely poor Web application policy in mid-2009 where data portability has become a major issue. This happens every time sites like tr.im that haven’t figured out how to monetize or stay in business despite some popularity. I’ve been talking about an online software “Bill of Rights” for years now and it boils down to this: We as users of these services which are so integrated into our lives must stand up and demand that our online applications get rid of their “roach motel” data policies.
But the bigger issue surrounding cloud applications that 1) we don’t pay for, 2) don’t run on our infrastructure, and 3) which we have little control over as users, is that we need to sort out where our true priorities lie. In general, this means voting with our pocketbooks, and paying in proportion for how valuable the service is to us. This also means not using applications that lock us out of our own data by not letting us export it when we want to.
For my part, the tr.im story is a too-often repeated parable that we can’t ignore. In fact, because of this we are moving from Bit.ly — which unlike services that I use like Flickr that allows me to pay, I can’t support Bit.ly as a business to ensure they stick around — to our own hosted URL shorteners. This ensures I can have guaranteed access to the links we send out to our contacts and clients for as long as I want to pay for it. In this way and others, short links will form a good part of the glue of the Web going forward. We should not forget that the demise of a URL shortener actual does terrible damage to the fabric of the Web itself (which is eponymously a deep web of billions of links), especially if a URL shortener has poorly designed redirects. Shortened links, particularly since they are used so close to the attention center of the Web, when they break ultimately interfere with many important services that do link analysis (such as search engines) from providing good results.
While in the long term most Web damage will sort itself out, the issue is that foundational service collapse can be far more impactful of us as users individually when it does happen (URL shorteners are “foundational services” since they insert themselves into foundation of the Web itself, it’s deep link structure.). To begin resolving all this, I humbly suggest that startups and their users alike ponder these points carefully:
A Cloud Services “Mutual Contract”:
- Cloud applications will let users extract all of their data in open standard formats on demand. This includes their explicit data as well as their data shadows (log files, user behavior tracks, search terms, etc.)
- Users of cloud application will be given the option for paying for higher quality service as well as offsite backups. Cloud applications can still monetize through advertising and give away free versions but this guarantees a financial footing as well as a higher level of control by customers, who have a greater stake when a services actual revenue comes from them. Giving users an option to pay (and businesses certainly will if the service is important) is one of the best ways to ensure a service, particualrly popular ones that widely affect a large number of people doesn’t have an unexpected demise. Backups should be accessible without an intermediary.
- Users should use the “for pay” version of the service whenever they use it signficantly as part of their lives or businesses. Monetize the usage, not the content as Fred Wilson says. Unfortunately, free is the most popular business model on the Web and users just aren’t used to paying, even if an application has become important. But keeping very reasonable usage fees that can be billed yearly seems to be a successful model.
- Cloud applications should offer use 3rd party storage for users’ data. Trusted services such as S3 make good “backing stores” for a user’s cloud application data. That way, if a service goes out of business or permanently offline, the data is already in a safe place. Technically, this poses few serious challenges for most applications and is actually a strong selling point for a new, untrusted service.
This list is very close to my original Online Software Bill of Rights in the link above except the pay-for-use option. I added this because so many startups habitually avoid early monetization, hoping that lack of fees will help build a big “pop” and where they are then either acquired or attain enough page views to monetize for a few years. I’m certainly not advocating a pay gate, but Web startups too often never become real businesses either. Instead, I’m encouraging that cloud applications offer at least a freemium model as soon as they build a good, initial audience. And keep all their users’ data safe and portable.
For a full view of how to build modern Web apps read: 50 Strategies For Creating A Successful Web 2.0 Product
Lastly, services keep forgetting that data is the key to the Web 2.0 era and frequently fail spectacularly to exploit it in their businesses. Network effects by default is what happens when services make use of user’s data to create powerful new features and capabilities for other users with fair use of user contributions. While just letting users store private data in your cloud application can result in a viable business, it won’t set the world on fire.
Are URL shortners complicating the Web by inserting themselves as key intermediaries? Will this make the cloud too fragile in the long term? Your comments below.