Google Reader's 2013 shutdown made export formats matter

A cleanup announcement with a firm date

On 13 March 2013 Google published a post grouping several product closures under the banner of a spring clean. Google Reader, the RSS aggregator it had run since 2005, was on the list. The stated reason was plain: usage had declined, and the company wanted to focus its engineering effort on fewer products. A second, Reader-specific post, Powering down Google Reader, fixed the actual closing date as 1 July 2013, giving subscribers a little under four months of notice.

A workflow built on one file, not one company

Reader worked by polling the feeds a person subscribed to and presenting new items in one interface, sorted and searchable, with starring and sharing built in. Because RSS is an open format rather than a proprietary one, a Reader user's actual asset was not locked inside Google's servers: it was a list of feed URLs, portable in principle to any other aggregator. The shutdown post pointed users to Google Takeout to download that subscription list, along with starred items and notes, before the July deadline. For anyone who had also built browser extensions, scripts or a paid third-party reader around Reader's sync API, the more disruptive change was the loss of that API, which took working tools down with it even though the underlying feeds kept publishing.

What four months of notice did and did not solve

A four-month window is enough time to export a subscription list and pick a replacement, which is why the migration is often remembered as painless. It was not enough time to rebuild every integration that depended on Reader's specific service, and it did nothing for anyone who missed the March announcement and only discovered the closure in July. The declining-usage justification is a vendor's account of its own decision; Google did not publish usage figures alongside it, so the claim should be read as a stated reason rather than an audited one. The lasting lesson is not about RSS specifically: any single free service, however well used by a minority, can be judged not worth maintaining by the company that owns it, and the export window is set on the vendor's schedule, not the user's.

• Does the tool publish data in an open, documented format, or only through its own interface?
• If the service closed tomorrow, is there a same-day way to get a usable export, not just a promise of one?
• Does anything you depend on plug into the service's API rather than into the open data underneath it?

Reader's closure is now a decade-old event, but the shape of it recurs throughout this batch: a company decides a free product no longer earns its keep, states a reason, and sets a deadline. What varies each time is how much of the user's real asset, the data rather than the interface, survives the transition.