Live data from Hacker News

Google Kills Cloud Print

support.google.com

511–520 of 567 posts

Re: Google Kills Cloud Print

#511

The product has been around 10 years, and they're giving over a year notice before killing it. Sure, Google kills off another product... But the comments here are a bit silly.

Counter-argument: Just let it sit there and keep working? Outside of security patches, if there even are any, there's always the option of "just stop touching it." After all, the whole pitch of elastic compute is you only pay for what you use. It's not like resources are being freed up for other things here. The software industry is always on this treadmill of churn, leading to stable products continuing to have a co…

At Google nobody gets a promo for maintaining stale product.

Re: Google Kills Cloud Print

#512
post #332

Earlier quoted context omitted.

> Silo it off and just leave it be. Not really possible. It's an internet service that talks to large number of different printers from different manufacturers. Besides the code management issues others have mentioned, services like this require a great deal of product and partner coordination and testing effort to ensure that even small security patches don't break the heterogeneous ecosystem of devices. More import…

More importantly, CUPS and driverless printing standards have solved the problem (os-specific print drivers) that cloud print was designed to work around. Guess who owns CUPS?

No one? It is an open standard originally created by Apple.

Re: Google Kills Cloud Print

#513
post #459

Earlier quoted context omitted.

> Those printers are not getting updates, either. Nobody is changing the printer side of this Of course things change. Security protocols get upgraded. New attack vectors are discovered in protocols and need to be fixed. New devices with new capabilities are created and need API integration. That all requires human effort to make happen. All of that has to be worth the cost of maintaining the project. > CUPS still ne…

> Of course things change. Except they don't. The clients are frozen in time forever. There's no change happening here. It doesn't matter if they should be changed, they aren't being changed. Printer firmware does not get updates. > New attack vectors are discovered in protocols and need to be fixed. IF that ever happens, which is super duper unlikely, then kill it since the clients are unfixable. But this is not an…

> Printer firmware does not get updates.

Sounds like you've never owned a printer before...

> IF that ever happens, which is super duper unlikely, then kill it since the clients are unfixable.

So have a possible security hole with no active developers until a third party finds a vulnerability, then shut it down?

> But this is not an ongoing cost.

You would still require SRE support for keeping this thing up running. You would also open yourself up to a lot of risk, losing user trust and potential lawsuits if it ever was hacked.

Everything you wrote sounds like an elaborate troll but I'm assuming that you've just never worked on a large system before.

Re: Google Kills Cloud Print

#514
post #512

Earlier quoted context omitted.

More importantly, CUPS and driverless printing standards have solved the problem (os-specific print drivers) that cloud print was designed to work around. Guess who owns CUPS?

No one? It is an open standard originally created by Apple.

Apple owns the copyright to the CUPS software that runs on Linux and Macs.

But the point being that unlike Google, Apple has supported CUPS and actively developed the software for well over a decade even though it doesn’t profit directly from it.

Re: Google Kills Cloud Print

#515

Earlier quoted context omitted.

Google pays their engineers a lot and they’d need to recruit a lot more of them if they were going to keep running everything they ever killed. That, or stop launching so many new products.

I know it's beside the point, but you stepped on one of my peeves. Google doesn't have to pay their engineers "a lot". They don't have to keep sucking more and more wealthy people into a concentrated corner of California. They could open a modest office in Nebraska and pay some 5-figure salaries. They could hire some run-of-the-mill college grads to work on a "dead" project. They could cut their teeth on low-profile…

> Spend $1M in St. Louis and move 100 employees out of SF.

~100/100 SF Google engineers would change teams if they received a mandate that their team was relocating to St. Louis (or basically anywhere). Anyone who couldn't arrange to change teams would quit.

Re: Google Kills Cloud Print

#516

Earlier quoted context omitted.

> Just let it sit there and keep working? Sounds simple but sometimes it is not so easy. E.g. it might be written in Python 2 for all we know. Should they leave it on Python 2 with zero security updates, or invest lots of time porting to python 3? Obviously there will likely be a million other internal examples of the python 2 to 3 migration that we don't know about.

> Should they leave it on Python 2 with zero security updates, or invest lots of time porting to python 3? Leave it, of course. The only meaningful security risk at this point is something like heartbleed. We're talking security issue in 10 year battle hardened protocol. This is a fantastically rare case. Not something you need headcount on a constant basis to deal with.

"250M printers compromised by Google Cloud Print" is an ugly look. It won't matter at that time that Google rescued a beloved product from being Deep-Sixed.

Re: Google Kills Cloud Print

#517

Earlier quoted context omitted.

..said nobody but an English major.

Neither productive, insightful, nor accurate, just FYI.

Nobody says 'champing at the bit'. I don't think I've heard it in my entire life. To point it out is pedantic at best.

Re: Google Kills Cloud Print

#518
post #97

Earlier quoted context omitted.

My guess is these things are generally unprofitable because their internal costs are so used to operating as a near monopoly they simply can’t do anything on the cheap. Which ends up killing off seemingly viable products. It’s much like how bell labs invented so much great technology, but could never make the transition to new producers themselves.

They might not be wrong. Engineers who could be maintaining mildly profitable products could be invented new products that have some percentage chance of being much more profitable. If someone did the math and said the expected value of "engineer working on new projects" was bigger than the expected value of of the the profits of an existing project divided by the number of engineers needed to maintain it, then it'd…

> If someone did the math and said the expected value of "engineer working on new projects" was bigger than the expected value of of the the profits of an existing project divided by the number of engineers needed to maintain it, then it'd be logical to abandon a bunch of seemingly profitable products.

In case anyone is wondering, the math has been done. I have been told that Google even has an internal page devoted to informing engineers how much something has to be worth before it is worth their time, and it's a big number.

Re: Google Kills Cloud Print

#519
post #398

Earlier quoted context omitted.

Which proves the futility of these OKR metrics. Once the metric becomes the objective, it loses any usefulness, indeed it becomes the opposite

How is that true? The OKR explicitly doesn't include cloud print because it is deemed not important to Google, and so cloud print is not worked on. Seems to be WAI?

Seems then like the incentive systems have a blind spot: they don't account for pissing off users relying on a service.

Why shouldn't people get promos for doing heroic acts on obscure services that actually delight users in real life? That surely has a benefit for Google. And the lack of it has a cost. Think of it like a PR budget. They'd get fewer grumpy articles about unmaintained services being dropped.

Post reply on HN