The impending death of Google Reader has got me thinking about what an ideal replacement for would look like. The first and most important feature (of an idealized replacement) is something I alluded to in an earlier post. Namely that the feed reader backend (which keeps track of all subscriptions and which items have been read) needs to have an API that is an open and standardized.
It almost seems like every single developer is working in a replacement for the Google Reader API. Feedly, Superfeedr, and even digg (and probably plenty others that I have already forgotten) all have something in the works. My personal favorite feed Reeder has also indicated that the app will transition to some other back-end API (though what exactly that means remains a mystery). It would be a shame if all of these developers didn’t come together and create some sort of standard (kind of like the equivalent of IMAP for feed reader as I mentioned in my previous post). This would prevent us from going down the same path that got us into all this trouble in the first place.
A long time ago the RSS ecosystem was a vibrant place. Developers were experimenting and trying out cool new thing. Sure some of them were terrible but this experimentation lead to an understanding of what worked and what didn’t. It eventually lead to the creation of Google Reader, which offered a fast, simple and efficient UI. But more importantly it was one of the first cloud based readers, which meant your feeds and all the articles you had read were synced across devices.
This might seem like an obvious feature, but back then the ‘cloud’ was just getting started. Back then most feed readers were native applications that did not sync with anything. If you spent a few hours reading articles on your laptop, you would have to wade through all those articles again when you sat down on your desktop and fired up your feed reader to do more reading.
In fact Google Reader was so good that it quickly dominated the landscape. Most other feed readers faded away, or pivoted to something else. Once the dust had settled only Google Reader remained. Innovation in the RSS space ground to a halt.
With the launch of the iPhone and Android phones, there was a renewed interest in RSS and a new crop readers emerged (like Reeder). There apps were great, but generally they depended on Google Reader for they backend feed management and syncing. The ones that didn’t simply weren’t very useful. They locked you into their walled garden and made it difficult to keep one centralized list of feeds and read articles. Without syncing with Google Reader these RSS apps were about as useful as the feed readers we all abandoned in favour of Google Reader. Reading a bunch of articles on one device, meant that those articles would still show up as unread on all other devices.
But this reliance of Google Reader made the entire feed reader ecosystem brittle. If Google Reader ever shut down then the entire ecosystem would come crashing down as well. That is exactly what is happening now.
It would be very short-sighted if now that Google Reader is shutting down we went down the same path and all coalesced around one proprietary feed syncing service (Feedly seems like the leading contender right now) It would leave us in exactly the same position.
A far more robust approach would be for the various developers working on replacing the Google Reader syncing backend each worked together to create a standardized API to access any feed reader service.
This would allow feed reader app developers to connect to any sync backend. Much like email clients can connect to any email server.
That was the first feature I want to see in whatever replaces Google Reader. I want to replace the reliance on one single backend syncing service and instead rely on a standardized syncing API that anyone could implement that doesn’t have a single point of failure. One that lets me, the user, chose who I want to trust with my feeds and articles.
I would even be more than happy to pay for such a service.
In Part 2 I’ll delve into the misguided river of news vs inbox debate.
Thanks for the Superfeedr mention :)
I mostly agree with you that we need to have a common API… however, I also think that the google reader API is/was not good.
I will post later this week about why I think the best API for RSS is actually RSS.
Fair enough. I’ll admit that I don’t know the ins and outs of the Google Reader API, and I don’t really care what the API ends up looking like. As long as it works and is standardized.
RSS as the RSS API is interesting, though.