Hacker News Reader

Comment by kyrra | Hacker News Reader

Googler, opinions are my own.

I wasn't at Google during the reader shutdown, but after being here at 8 years, I now understand why things shut down so often.

Google has a lot of shared infra and they are always doing forced migrations and various unfunded mandates. Depending on the stack, maintaining a project at Google takes 0.5-3 people (like if a UI toolkit is turned down, you have to migrate). Plus there are infra costs.

On top of that, being on maintenance for a project like Reader, it's probably not very good for your career trajectory. The adverse effects of always going for launching/landing destroyed so much at Google.

Many engineers would love to just help maintain software like that, it just doesn't tend to work out given the incentive structures. (Plus that headcount and infra has to be attributed to some team. A person maintaining Reader means some other thing that can't be built, so there isn't an incentive for VPs either)

View on HN

I was at Google during the reader shutdown. It was absolutely a top down decision and not a lack of support due to incentives. The execs tried to frame it as an infra problem/cost of migration, but neither myself nor any of my coworkers believed that at the time.

It was very telling during TGIF that week when Larry and Sergey skipped literal pages worth of top questions about it and refused to give direct answers as to why it was shut down.

The Reader shutdown coupled with Google+ reaching its tendrils into every product (“hey, real identities are great for YouTube users!”) at the time convinced me “don’t be evil” may have been a goal, but “don’t miss out on profit” was a requirement.

Can we blame Vic still? (He obviously convinced Larry and Sergey)

IIRC there were volunteers, at least 3 or 4 engs who were content to work on maintaining it either as their 100% project or as their 120% project, but it just wasn't an option.

That's the problem though isn't it. Google doesn't want to maintain stuff otherwise they would incentivize it. Classic "The purpose of the system is what it does"

This raises questions (that you probably can't answer, but still) about why Google doesn't have a "maintenance subsidiary" playbook, where instead of killing a project off, they spin it off, with a bucket of cash to last that project 3 years, after which they'll have to have figured out their own monetization plan (or open source transition) while still having access to everything Google because it'd just be another Alphabet-owned company.

Not every engineer wants to live the fast-paced "create and move on" life, there are so many skilled engineers who would happily take the lower salary, but also lower-pressure, maintenance jobs.

If a project makes a million bucks under Google, that doesn't even remotely push the needle and it gets shut down. If a 5 man subsidiary makes a million bucks, that's a million bucks. Foster that?

It’s not necessarily straightforward or cheap to migrate a living product to open-source land. Backend services at Google are built using proprietary frameworks and infrastructure for which no equivalent exists out in the real world. They could help people out a bit by open-sourcing the web front-end, but that’s substantial work and you’re still a long way from having a working clone of the product.

EDIT: I see I misread your comment and you’re talking about keeping it on Google infra but separating it for accounting purposes. It’s an interesting idea but I don’t see why it would fundamentally change the viability of the product. Also, there’s an ongoing maintenance cost to having more products on shared infra. If you’re the team that runs the global distributed relational db (for example), or maintains the C++ discrete optimization library, it’s much simpler to support two products that make a billion each rather than 2,000 subtly different use-cases each making a million each. Not to mention costs incurred by non-engineering departments (marketing, accounting, legal).

Not just separated for accounting purposes: literally make it a new company under the Alphabet umbrella (spinning up an LLC is basically a Tuesday afternoon for Alphabet) and then seeing if, as its own entity with an Alphabet "series A" grant, it can keep the product alive or not. And then if that company fails: bonus, Google didn't kill it, the market did.

I wonder how many people maintain Gmail...

Gmail is a huge data source for their ad business. They use it to fingerprint people all over the web (sign in with google). I imagine they see it as essential to their ad stack.

Forget about ads, Gmail is essential to paying Workspace customers.

They don't need it to fingerprint people by forcing them to sign in -- Google has enough other priorities like Search, YouTube, Chrome, for that.

Making Gmail available for free to consumers, along with Docs and Drive, isn't something to drive ad sales. It's to get everybody used to the products and liking them, so that businesses choose them instead of MS. Google has successfully turned themselves into the main alternative to MS Office with this strategy.

When it comes to Gmail, Docs and Drive, Google's making their money "honestly" -- not through ads but through paid corporate subscriptions, and a smattering of consumer ones (like extra storage).

Reply on news.ycombinator.com