On the death of Google Reader

You can probably tell the sort of on-line company I keep from the deluge of noise on the social networks regarding Google’s decision to shut down Reader. However we shouldn’t be that surprised. In fact some companies that source content from Reader have anticipated the need to collect content themselves.

I of course will have to make a decision at some point. However I’ll not do it today like a lot of Reader users have. The rush to try out alternatives has over-whelmed some open source based projects who were quietly growing organically. I don’t envy those that have to suddenly gear up their back-end systems because an Internet behemoth gave us 2593 hours notice to sort out a replacement.

I’m mulling over the difference between self-hosting and having someone else do it. I’m not overly worried about going for convenience if I know I can get my data back if I need to. In fact the knowledge that you can theoretically self-host might be enough. To be fair to Google their Data Liberation team made exporting all my Reader data easy.

Before I make a choice I need to decide what my priorities are. Currently I subscribe to 250+ RSS feeds. Obviously I don’t read every single post but I make extensive use of tags to quickly process through stuff I do need to see when I need to see it. Aside from news, blog posts, funny cat pictures I also subscribe to other data feeds like bug trackers, code repositories, and other data sources. I of course want access to all of this data at any point on one of a number of devices. This makes a web hosted solution pretty much a must. There is no point having the data on my desktop when I’m somewhere else. From my point of view I want it to be open source compatible because if the company hosting now decides it no longer wants to I’ll only have to move the data and not break my work-flow.

It would also be very useful if it had a public API so others can interact with the data. I don’t need the solution to be all provided by one company. It’s perfectly fine to have multiple 3rd parties sorting out the Android integration. I might even look to doing something to integrate it with my favourite editor (the name of which even my non-geek readers probably know by now). So far my experiment with moving all of IRC and IM into Emacs seems to be working well and should be a subject of another post.

Are you a Reader user? What are your criteria for it’s eventual replacement? Is RSS just a dying protocol or is the need to aggregate and sift through data becoming more important?

There may well be a much better way of solving this problem around the corner. I certainly am open to persuasion. But don’t take away my current preferred solution until I’m convinced I’m ready to switch đŸ˜‰


  1. I’ve been using Gnus with nnrss to read feeds for a few years now (Emacswiki has a trick for dealing with Atom). Recently I’ve started to try gwene as suggested above. It does keep track of which messages I’ve already read.

    The messages do not seem to be stored locally, and I don’t know how long they’re available through gwene, but IIRC you can archive copies onto your own machine if desired. Gnus is designed to handle high message volume though, so it might be just the thing for your 250 or so feeds.

  2. I’m leaning towards self-hosting a server side RSS feed aggregator. I like being able to read my feeds in browser, on iOS, and on Android. Not excited to delegate this, since that’s already worked out poorly once. Although I suppose paying for it raises the probability of the service sticking around.

    Unfortunately, there are a dizzying array of web aggregators, and it’s hard to get a sense of the relative feature sets, much less which ones are going to give the keys of your server to J. Random Hacker.

Comments are closed.