Richard Kadrey said it best:
What does the death of Delicious teach us? The cloud isn’t your friend. The cloud will lure you into its van, but there’s no candy in there.
Substitute ‘Google Reader’ for ‘Delicious’, and the lesson is the same.
Today, Google announced that they’re pulling the plug on Reader, their RSS aggregation service. This has prompted predictable cries of outrage in the Twitterverse, as people who love and use Reader daily suddenly face the chilling prospect of life without it after July 1st.
I am not a Google Reader user … or rather, I am, but I don’t use Reader on the web to read news. Instead, I use applications - NetNewsWire on the Mac, and Reeder on my iPod. Both of these applications offer the option to use Google Reader to synchronize your news feeds. When I read something on my iPod and then switch to the Mac, the thing I’ve just read is marked as read, so I don’t have to read it all over again. If I flag something to read it later on the Mac, it’s flagged on the iPod. If I subscribe to a new newsfeed on the iPod (or on the Mac, or even on Google Reader itself) it’s there on all the other devices I might use. It’s seamless, transparent, essential.
Come July 1st, Reeder and NetNewsWire aren’t going to be able to leverage Google Reader to provide this very useful functionality. They’ll either have to drop the feature, or switch to another provider that offers the same functionality, or implement it themselves. Google has just pulled the rug out from underneath them, and they - and many similar apps or services - are going to have to scramble to find another solution.
If you go to Reeder’s settings panel, the very first item is “Google Reader Account”. Same thing with NetNewsWire: under Sync settings there’s a checkbox that says ‘Sync with Google Reader’. There are no other options, no alternative services.
The fundamental error that the creators of both these excellent apps have made is that they programmed against an application, not against an API. What they need isn’t Google Reader: it’s something that offers the same API endpoints and the same functionality as Google Reader. That something could be anything. So long as it looks and behaves like Google Reader, it doesn’t have to be Google Reader. My guess would be that an averagely-capable programmer could implement a simple webapp to implement the API and duplicate the synchronization and storage functionality of Google Reader in a weekend.
What the app makers then need to do is to change their apps so that instead of saying “Synchronize with Google Reader” they say “Synchronize with …” and let you specify the service of your choice. Provided that service supports a synchronization API, the app shouldn’t care who or what it is.
I’ve actually wanted this for a while, simply because I don’t see that what I read is any of Google’s business. I would have been happy to deploy a synchronization webapp on my own server and keep it all to myself. Not everyone has their own server, of course, but I’m sure there’d be businesses who’d be happy to step up and provide synchronization as a service - if the apps supported it.
This error - programming against a specific application, not a general API - repeats throughout the app ecosystem. Reeder lets me choose one of three bookmarking services - Pinboard, Delicious and Zootool - to save links to. It lets me save articles to two offline reading services - Instapaper and Pocket. It lets me send updates to two different micro-messaging services - Twitter and App.net. Each one gets a separate entry in the Reeder settings panel.
What if, instead of Twitter or App.net, I wanted to use Identi.ca or Tent.is? Or my own server running tentd? Sorry, no can do. Those options aren’t offered. Even though each of these is fundamentally the same kind of thing as Twitter, and may even support precisely the same API (or, if they don’t, could easily be made to). It’s the same thing with the other options: for all the options that an app developer can squeeze into a settings panel, there are always a few more services that aren’t offered. Yet in many cases, the app could talk to them without changing a single line of code.
I’m not singling out Reeder - a truly excellent application - here. All app developers are doing something similar. They pick the current market leader for some particular functionality, they implement support for it, and they put it in their app. If there are a few equally prominent competitors, they might support two or three. But that’s all.
In the same way, a bunch of other apps that I use offer support for Dropbox. Why not? Dropbox is a wonderful service. But Dropbox is now just one of many similar services. Why support Dropbox and not Box.net, or Pogoplug, or Microsoft SkyDrive, or iCloud? Or a private cloud storage service implemented using an open-source solution running on someone’s server somewhere?
“Oh, but we can’t possibly support all those different applications,” the app makers say. Right. You can’t support a half dozen different applications. But you could support just one API for any functionality you need to implement. One API for cloud storage. One API for bookmarking. One API for RSS synchronization. One API for micro-messaging. One API for sending articles to an offline reader. One, open, documented, well-defined API for each type of service.
The beauty of this is that if a given provider - say Microsoft - doesn’t offer the required API, they will actually be under pressure to implement it. “I’d like to use SkyDrive,” says Joe User, “but it’s not compatible with the apps I like on my smartphone.” When Microsoft realizes that everyone’s using still Dropbox instead of SkyDrive, they’re going to wise up and roll out the necessary API support pretty fast.
Actually, they probably won’t. This is Microsoft we’re talking about, after all. But I can dream.
The death of Google Reader is a teachable moment. App developers should take note of what just happened to Reeder and NetNewsWire and all the other dozens of newsreaders that used Google Reader for synchronization. They tied a critical feature of their software to one specific implementation. When Google took their ball and went home, they got screwed. Don’t let that happen to you.
Using open, well-defined, standard APIs is the Way of the Web. Locking your product to someone else’s proprietary implementation is a recipe for heartache. Program to the API, not the application. And if the API doesn’t exist, get together with a bunch of like-minded folks and design one. In the long run, it’s better for everyone.