Marco.org • About ▾

I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Baby steps toward replacing Google Reader

With Google Reader’s impending shutdown, lots of new feed-sync services and self-hostable projects will be popping up.

Nearly every mobile and desktop RSS client syncs with Google Reader today, often as the only option. Getting widespread client support for any other service will be difficult since it’s probably going to be a while before there’s a clear “winner” to switch to.

The last thing we need is a format war — with Reader’s shutdown in July, we don’t have time for one.

An obvious idea that many have proposed (or already implemented) is to make a new service mirror the (never-officially-documented) Google Reader API. Even if it also offers its own standalone API for more functionality, any candidates to replace Google Reader should mirror the fundamentals of its API.

Clients then only need to change two simple things:

Then use that as the hostname for all API requests: https://{hostname}/reader/api/0/...

Like it or not, the Google Reader API is the feed-sync “standard” today. Until this business shakes out, which could take years (and might never happen), this is the best way forward.

We need to start simple. We don’t have much time. And if we don’t do it this way, the likely alternative is that a few major clients will make their own custom sync solutions that won’t work with any other company’s clients, which won’t bring them nearly as much value as it will remove from their users.

Let’s get Reeder and NetNewsWire to support the Hostname field ASAP so we can build alternative services to back them. Once they support it, other clients will need to follow from the competitive pressure of checklist feature comparisons. The result will be the easiest, fastest solution for everyone and a healthier ecosystem for feed-sync platforms.

What do you think, Silvio Rizzi and Black Pixel?

Ads via The Deck