In March 2013, Google shut down Google Reader, one of the most beloved RSS applications ever built. The backlash was immediate and loud. A petition to reverse the decision gathered hundreds of thousands of signatures. Journalists wrote eulogies. Power users felt personally betrayed.

Google’s stated reason was declining usage. The real reason was more interesting.

The Setup

Google Reader launched in 2005, three years before Chrome, four years before Android matured into a real platform. RSS, the open protocol that Reader was built on, was exactly the kind of technology Google should have feared: a decentralized system for distributing content that no single company controlled. Anybody could read any publication’s feed without the publisher, the reader, or the aggregator having any particular loyalty to Google.

Reader became wildly popular among journalists, developers, and the kind of early adopters who shape how technology gets talked about. By the late 2000s, it was the default way a certain class of internet user consumed information online.

But here is the thing about RSS: it was too open. It created no lock-in, generated minimal data about user behavior, and offered no obvious surface for advertising. Every person reading their feeds through Google Reader was a person Google knew relatively little about, moving through an information ecosystem Google did not own.

What Happened

The launch of Google+ in 2011 reframed everything. Google wanted social. It wanted the engagement loop, the social graph, the behavioral data that Facebook had built its business on. Google+ needed content to survive, and content needed readers, and readers were already using Google Reader.

Internally, the question was never really whether Reader was declining. The question was whether an open, interoperable reading tool served Google’s evolving interests. It didn’t. Reader was, from a strategic standpoint, a sponsored bridge to a content consumption model Google had already decided to move away from.

When Reader was shut down, the RSS ecosystem fractured. Some users moved to paid alternatives like Feedly or Inoreader. Many more drifted toward Twitter, Facebook, and eventually algorithmic feeds that no individual user controlled. The open web’s most practical navigation tool was gone, and the replacement was platforms where Google, Facebook, and Twitter set the terms.

Google didn’t kill Reader because it failed. It killed Reader because Reader had succeeded at the wrong thing.

Abstract diagram showing user migration from an open platform through a controlled funnel, with some users lost in transition
The strategy isn't to keep users on the open product. It's to make sure the walled alternative is ready when you remove it.

Why This Pattern Keeps Repeating

Google Reader is not an isolated story. It is the clearest example of a pattern that runs through modern tech history: companies build products that are genuinely useful, allow those products to become load-bearing infrastructure for user behavior, and then retire them in ways that push users toward more controlled environments.

Microsoft did something structurally similar with Internet Explorer. IE wasn’t just a browser; it was a platform that made Windows stickier and made competing operating systems less viable. When the browser wars became less strategically important, and when IE’s technical debt became a liability, Microsoft let it calcify deliberately before finally replacing it with Edge. The transition was painful for enterprise customers precisely because Microsoft had spent years encouraging dependence on IE-specific behaviors.

Amazon has done this with AWS services repeatedly: launch a tool that fills a genuine gap, let startups build on it, then sunset it in favor of a more integrated, more expensive, more Amazon-controlled successor. The developers who built on the original service don’t leave AWS. They migrate deeper into it.

The pattern has a consistent logic. Tech companies build products they know will die because the death is the point, but the death isn’t waste. It’s a controlled burn that redirects traffic.

The Economics of Deliberate Obsolescence

Building a product you intend to retire is not irrational. It is, in many cases, the most rational thing a large technology company can do.

The calculus works like this. Open or interoperable products attract users who are skeptical of lock-in. These users are often influential, technically sophisticated, and vocal. Getting them into your ecosystem, even via an open tool you don’t fully monetize, gives you distribution and credibility. Once they’ve built habits around your infrastructure, the cost of leaving rises regardless of how open the original product was.

The retirement of the open product then forces a choice. Users either migrate to your controlled alternative, migrate to a competitor’s controlled alternative, or leave entirely. The first outcome is what you’re engineering for. The third is acceptable. The second is the only genuine loss, and it’s the risk companies take.

Google bet that Reader users, once displaced, would migrate toward Google’s social and algorithmic products rather than toward Facebook or Twitter. That bet was wrong. Google+ failed, and the users Google had cultivated through Reader scattered. But the lesson most companies took from Google’s failure was not “don’t retire open products.” It was “make sure your controlled alternative is actually ready before you retire the open one.”

What We Can Learn

For individual users and businesses, the Reader story is a reminder that free, popular, well-designed products built by large companies are not public utilities. They are investments with expected returns. When the return profile changes, the product changes, or disappears.

The products most at risk of deliberate retirement are the ones that are genuinely useful but strategically inconvenient: tools that build user habits without building platform dependence, or that operate on open standards the company doesn’t control. If you’re evaluating whether to build your workflow around a corporate-owned free tool, the question isn’t whether it’s good. The question is whether it serves the company’s long-term interests as well as it serves yours.

For people building products, the Reader case illuminates something about competitive strategy that gets underappreciated. Openness can be a growth mechanism, but it is not a moat. If your product succeeds by being open and interoperable, a larger company can build a compatible version, attract your users, and then close the door. The solution isn’t to avoid openness. It’s to understand that openness is a phase, not a permanent state, and to build the kind of community or network effects that survive a platform’s strategic pivot.

Google Reader had both, actually. It had a devoted community and genuine network effects among the people who shaped how technology was discussed. Google shut it down anyway, because those things mattered less than alignment with Google’s core business model.

The most honest reading of the Reader story is not that Google made a mistake. It’s that Google made a calculation, the calculation turned out to be wrong, and then Google moved on. That’s the part the eulogies missed. The company wasn’t sentimental about a product that no longer fit the strategy. Neither should you be.