Category: RSS


Monday will be the very last day that you will be able to access your RSS feeds using Google Reader, so if you haven’t already migrated to one of the other services, I strongly recommend that you…

Export your Google Reader data before Monday!

Here’s a quick how-to:

  1. Go to Google Takeout at
  2. Assuming you only want Reader data right now, click on Choose services at the top of the page
  3. Click on the Reader button
  4. Click the Create Archive button

Unless you have an enormous number of feeds, your archive should be created relatively quickly. If it’s taking a long time, you can check the box to send you an email when the archive is ready for download. (There’s no need to keep your browser opened in this case.)

Once it’s all packaged up, click the Download button next to your new archive. (If you did the email option, there will be a link in the email to take you to the download page.)

What the heck do I do with it?

The download will be a zip archive containing a bunch of JSON files and one XML file. The JSON files have your notes, likes, starred, shared and follower data.

The XML file – subscriptions.xml – is the important one. It has a list of all of your feeds, and what folders they are in. (It’s actually in OPML format, which is based on XML.) Most feed reading services and apps will know how to import this file, and recreate your subscriptions. Some will be able to understand your folder structure, but not all.

Preserving my read/unread state?

Sadly, importing just subscriptions.xml doesn’t keep your read/unread state, and most services also don’t know how import the JSON files at all.

There are only two web-based services that I’ve tried so far that actually do keep your read/unread states: Feedly, and Newsblur. Of the two, I prefer Newsblur’s UI over Feedly’s since it’s more like what I’m used to, but lots of people seem to like Feedly’s slicker, less cluttered UI better.

Both Feedly and Newsblur were able to import from Google directly, as can many others, but these are the only two I know of that keep your read/unread state. To do this, you connect the app to your Google Account, and they go out to Google to get your data.

Both services can also import your subscriptions.xml, connecting to your Google account is the better option if you’re doing your import before Reader is shut off. This will capture read/unread state (and in Newsblur’s case your shared stories) instead of just your subscriptions.

Edit: I just tried the new AOL Reader, and while it has a decent mobile web UI (gah), and did import my feeds from Google, it did not preserve my read/unread state.

Other web-based services

There are a slew of other services out there too, spanning a wide range of feature-completeness, API support, iPhone or other mobile apps, and social/sharing functionality.

The ones I’ve looked at most closely are:

  • David Smith’s Feedwrangler which lacks folder support but has a very interesting Smart Streams feature, and has its own iOS apps and API
  • The Old Reader, which started as a web-only Reader replacement that imitated an older version of Google’s UI, and does include folder support

Both services can import your feed list either directly from Google or using your subscriptions.xml from Google Takeout, but neither will preserve your read/unread articles or shared/starred stories.


Last month, I started working at Black Pixel, which just released NetNewsWire 4 in open beta.

NetNewsWire is a desktop RSS reader for Mac, which was originally created by my friend and former colleague, Brent Simmons. Previous versions of the app supported Google Reader syncing, but Reader sync was removed from this version since Reader itself is shutting down.

To be clear: I’m not working on NetNewsWire at Black Pixel, so I don’t have intimate knowledge of the roadmap, but syncing will come.

There is some public information on the beta release announcement here.


Russell Beattie has compiled a quite comprehensive list of services and companies that either already exist, or are moving in to fill the gap that will be left behind when Google shuts off Reader.

And there seem to be around 50 of them.

My guess — and it’s a total guess — is that there’s room for one or two successful startups, and around five successful pivots by existing companies. It’s going to be one wild ride once the shutdown actually happens.

Of the 50 or so, probably fewer than 10 will end up being reasonable direct replacements for both Reader’s web interface and never-supported sync API. Half of those will screw up something like scaling or reliability pretty early, or fail to catch enough buzz to be sustainable financially.

So that leaves maybe 3 to 5 serious products that will back-fill the gap that Reader leaves behind in the near-to-mid term.

Just a guess.

(I’m very intrigued to see what the open source community provides in this space as well.)


Marco Arment has a great post on the meta-issue surrounding Google Reader’s shutdown, on the issues around “free” in the tech industry:

“If you try to play by the traditional rules and regulations, you run the risk of getting steamrolled by someone who’s perfectly willing to ignore them. Usually, that’s the biggest potential failure of the tech world’s crazy economy, which sucks for you but doesn’t matter much to everyone else. But sometimes, just like unregulated capitalism, it fails in ways that suck for everyone.”

Go read it.


love-rss-icon-sm.jpg: Seen on Brent Simmons’ new RSS-Sync mailing list:

On Sun, Mar 17, 2013 at 10:13 PM, Will wrote:
“It seems like W3 Community groups are designed to structure the development of this sort of web standard… it seems like integrating with their process would help add credibility to the protocol this group settles on…”

I think this is the wrong approach.

We already have a de-facto standard in Google Reader’s API. Tens, if not hundreds of mobile and desktop apps are built to speak this API, and don’t currently have an alternative.

Involving a standards body, with all the negotiating, politics, and gnashing of teeth that comes along with that, could take years and might still not result in a useful protocol.

Given that there’s a matter of months before Reader is turned off and hundreds of apps break, slowing down now is not an option.

A couple of examples

De facto standards count, especially when they’re widely adopted.

Here are a couple of examples where there was a large push to get the standard supported by a standards body, which haven’t panned out so well:

The Atom format was an IETF standard that arrived after RSS was already established. It took at least 18 months to be published as an IETF proposal.

Atom has never been as widely adopted as RSS, and the RDF-based RSS 1.0 has even less footprint than Atom does today.

I worked for months on SOAP 1.1 interoperability while at UserLand in the early 2000’s. SOAP was a W3C standard.

Getting everyone to agree on what it should be was enormously time-consuming, and arguably yielded a spec that as of v1.1 when my involvement ended, still had many ambiguities, and favored some programming languages over others.

Today JSON prevails, and SOAP is limited mostly to apps that need to interop with legacy services, and large enterprise service-oriented architectures.

(JSON was an informal standard for years before it was published as an IETF standard.)

Why this matters

Users shouldn’t have to care
Users don’t know, and couldn’t care less what protocol or wire format is used for this stuff.

They want their feeds to stay in sync across all of their devices. And they want their favorite apps to keep working after Google turns off the lights.

Users couldn’t care less whether the way this works has a stamp of approval from a standards body, and they’ll never glimpse the blood, sweat and tears that developers will invest in the systems they rely on.

They just want their stuff to work.

Developers shouldn’t have to care either
A new standard means that the tens or hundreds of apps that are already in the ecosystem, would have to have one of their most important components rewritten. And that’s assuming that whatever the new standard were, it would even be compatible with those apps without a major rewrite in other areas.

Apps by developers who can’t (or won’t) make the investment to move to the new standard would die, and that would be nothing but bad for users, bad for competition and diversity, and bad for RSS.

And when those apps die, who will the majority of users blame?

(Hint: It’s not Google.)


Chuck Shotton: Google Reader’s Real Value (via Dave Winer)

“Google Reader was at best an average RSS reader. But it excelled at keeping all of my other 3rd party RSS reader apps in sync… When Google Reader shuts down, what is going to do that for me? The answer right now is ‘nothing.'”

Yep – this is a big hole. One that will hopefully be filled soon.

I wrote a bit last month about what Syncpocalypse would mean for bloggers, after the last brief outage.


From The Old Reader blog:

“Paid accounts will have some additional features, but the basic free accounts will still be 100% usable. We are not in this game to make money, but we want to give something special back to the people who are going to be supporting us…

“We reworked the plans according to the news today. Creating an API for mobile clients is the number one priority in our roadmap. We would love to collaborate with any developers who were making Google Reader clients. Please, spread the word about this if you can.”

This is the right move, in my opinion, however I do have two bits of unsolicited advice:

  1. Please clone the Google Reader API, even if you are going to create your own. By doing this you’d immediately make it possible for app developers to migrate their users from Reader to your service.
  2. Re-position your API as a more general service, not just targeted at Mobile. While there are many more mobile apps that depend on the Google Reader API, there are still desktop apps that use it too.

For now their web UI is under quite some strain. It took many seconds to load when I tried it just now (but it did load). They’re adding capacity as I write this, and I bet they’ll get it under control.

(Bonus link – Rob Fishman on BuzzFeed: Google’s Lost Social Network. “How Google accidentally built a truly beloved social network, only to steamroll it with Google+.” Amen, brotha.)

Blogging RSS Web

Dave Winer: Google Reader’s demise, part 2

“I don’t doubt that people will be well-served by a newly revitalized market for RSS products, now that the dominant product, the 800-pound gorilla, is withdrawing.”

Om Malik: Google Reader lived on borrowed time: creator Chris Wetherell reflects

“[It] was Google Crawler that gave the system ability to make lightning-fast connections and bring up recommendations. It is one of the main reasons it cannot be open sourced. The systems are too intertwined with Google’s search and other infrastructure to be sold as well.”

Marc Canter: Do they expect us to just stop using RSS?

“Here’s another thing – they’re saying we’re supposed to utilize Takeout to export our subscriptions. Well when I went to do that – the archive being built included all my YouTube videos – which are like 50G.” (I agree – Takeout pretty much sucks.)

Laura Hazard Owen: Google Reader, please don’t go – I need you to do my job

“… Flipboard is a lean-back kind of service. I use it when I want to curl up and read. In the mornings when I’m looking for stories, I don’t want to tap through a pretty magazine-like interface on my iPad. I just want to scan headlines and text fast, and I want to do it on my laptop.”

Quora: Why is Google killing Google Reader? (via Dare Obasanjo on Twitter)

Brian Shih, Former Google Reader Product Manager wrote, “I suspect that it survived for some time after being put into maintenance because they believed it could still be a useful source of content into G+.”

Todd Bishop on GeekWire: Bye, Google Reader: Don’t let the door hit you in the RSS (pretty terrible pun, IMHO)

“This is the third time Google has axed one of my favorite services or apps. But whatever. I’m already over it.”

Mat Honan on Wired: RIP: Google Reader Meets Its Inevitable End

“Google Reader was notable not only for its features, but for the active community it fostered for which Reader wasn’t just another tool.”

Feedly is building a Reader API clone: Transitioning from Google Reader to feedly

“We have been working on a project called Normandy which is a feedly clone of the Google Reader API – running on Google App Engine. When Google Reader shuts down, feedly will seamlessly transition to the Normandy back end.”

Blogging RSS Web

Google Reader has been a quite popular, if geek-centered service, with a social bent…

With the announcement that the service will shut down on July 1st, and all the millions of dollars, hours spent, and investment in competing with Twitter and Facebook, I find myself wondering:

If Google had invested more in Reader as a social networking platform, would they have done better than they did with Orkut, Dodgeball, Jaiku, Wave, Buzz and Google+?

(Time: A Brief History of Google’s Social Networking Flops)

Blogging RSS Web

Marco Arment: Google Reader shutting down July 1

“Now, we’ll be forced to fill the hole that Reader will leave behind, and there’s no immediately obvious alternative. We’re finally likely to see substantial innovation and competition in RSS desktop apps and sync platforms for the first time in almost a decade.”


See also: NetNewsWire Cloud

“By implementing a suitable syncing API for RSS, and implementing a reasonably useful web interface, Black Pixel could establish NetNewsWire Cloud as the de facto replacement for Google Reader.”