[leajkinUnk]

Collateral damage is an interesting way to put it. I've heard the internal story from people who worked at Google at the time, and it sounds like the rough sequence of events goes like this:

1. Google Reader is launched, built on internal Google technologies (the distributed database and filesystem technologies available at the time, like GFS).

2. Headcount is not allocated to Google Reader to do ongoing engineering work. Headcount is instead allocated to projects like Google+.

3. The technologies underneath Google Reader (like GFS) are shut down. Without the engineering headcount to migrate, Google Reader is shut down.

Google+ was reportedly shut down for the same reasons (but different technologies). The internal tech stack at Google is always changing, and projects without sufficient headcount for ongoing engineering will eventually get shut down. The timing of the Google Reader and Google+ shutdown reflect the timing of changes in Googles tech stack more than it reflects any strategic direction by Google.

[Edit: Just to be clear, this doesn't explain the reason why these projects get shut down. It just explains the timing.]

[ramraj07]

As someone seeing org level decisions being interpreted very differently by different people, I am not sure how much weight we can give to this insiders representation- this sounds like what an Eng manager (who himself might not know the real reason) would tell their disgruntled engineers.

Also the real question is why google didn’t assign an Eng team for this product used by millions, not why products without engineers die..

[leajkinUnk]

Just to be clear... I wasn't explaining the reason these projects get shut down, just the timeline of events and some of the contributing technical factors, since these factors are a little different at Google than at other companies.

The decision to deallocate headcount and stop ongoing engineering effort on a project will eventually cause that project to get shut down, no matter what company you work at. However, at many of the software companies I've worked at, projects that run on "industry-standard" or at least mundane tech stacks can run for a very long time with a relatively low amount of effort. At Google, the timeline is shorter.

For example, if you have a web app that runs on Rails or PHP, or something that runs on the JVM, maybe with a Postgres, MySQL, or MS SQL backend, you might be able to shove it onto different machines or VMs for years, only making occasional / minor changes to the code base. If, in 2008, you had a JVM app which used PostgreSQL and ran in Apache Tomcat, there's a good chance you could still run it today with minor changes.

At Google, the internal tech stack--filesystems, databases, monitoring, etc... has changes that are large enough and frequent enough that the situation is different, and projects are shut down on stricter timelines.

[signal11]

This is a really good story about how not to be a customer-centric organisation and not take user feedback.

What I take away is that just because they’re not paying customers doesn’t mean they won’t remember and judge you. And clearly people hold grudges for a long time (witness the number people who still maintain “Micro$oft is evil” from their 90s experiences).