9 ms·

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 i

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 constant maintenance burden. But that's not an intrinsic property of the area. It's a thing we do because... we can? We want to? But it's not required. Silo it off and just leave it be.

arkanciscan 7y ago
See: Google Play Music
- FactolSarin 7y ago
  Which I still prefer to YouTube music, it's theoretical replacement
q3k 7y ago
> 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." That's not exactly possible with a monorepo that has no branches and everything has to be maintained 'in step'. Any time a library breaks API, all dependents must pass tests, and/or be fixed so that they do. Any time a runtime API breaks (think things like interfaces to runtime authentication, compute scheduling, database services, network bandwidth scheduling), updated services must be made to conform and then be rolled out. As with real life, this might mean getting a 1 or 2 year old deployment system (configuration for production, roll out code, ...) undusted, understood, probably fixed in turn, etc. As such, some SRE/SWE team _must_ be responsible for projects that are in the "don't touch"/maintenance phase. This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google.
- formercoder 7y ago
  This. Someone has to be in OWNERS and it’s difficult to find people willing to do this because fixing breakage due to API changes isn’t going to be on anyone’s OKRs. And if it’s not on your OKRs, it’s not contributing to your promo.
  - eecc 7y ago
    Which proves the futility of these OKR metrics. Once the metric becomes the objective, it loses any usefulness, indeed it becomes the opposite
    - mattnewton 7y ago
      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?
      - asveikau 7y ago
        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.
- remus 7y ago
  > This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google. I don't think this is google specific. Keeping a dead product on life support is going to get boring for most people after a while.
  - asdff 7y ago
    There is an infinite supply of cheap intern labor at every college in the U.S. chomping at the bit to mop the floor at google hq.
julianozen 7y ago
So this works in theory until there is a really bad bug in some part of the code base and there is no one who knows how to fix it. Or it breaks some kind of migration plan. Or it is embedded somewhere on some architecture that slows down an important projects development. or makes an application incompatible with a future OS If they’re not going to keep a team dedicated to keeping it alive, then you get into a situation where an emergency fix needs to be deployed or it needs to be abruptly cancelled It’s possible this already happened once or twice which is why they had to sunset it
- kllrnohj 7y ago
  > So this works in theory until there is a really bad bug in some part of the code base and there is no one who knows how to fix it. 10 years of production usage tends to have hammered out all the "really bad bugs." Sure it's possible that something goes wrong, but it's also extremely unlikely that it does unless something in it changes. Which, if you freeze it & silo it off, doesn't really happen. A huge amount of software not made in silicon valley operates exactly like this. It just sits there, running for decades, doing its thing.
  - crehn 7y ago
    Still, the risk and maintenance/ownership burden is there.
    - kllrnohj 7y ago
      Yes, of course, but the point is it's a very, very small cost. It's basically zero for a company with Google's resources. Meanwhile killing it is actually costly. Not to engineering, but to PR and reputation.
  - julianozen 7y ago
    I don't know. I'd bet anything that has been production for 10 years with no feature added means anybody who knows anything about it left ages ago. Its a cloud service that was started pre-Google Cloud. There is no way that it can sit in perpetuity and not be worried about old versions of Java, old OS, HTTPS bugs, large deprecation plans
deleted 7y ago
[deleted]
mattlondon 7y ago
> 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.
- kllrnohj 7y ago
  > 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.
  - arbie 7y ago
    "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.
    - Already__Taken 7y ago
      Right. Is nobody remembering the Google Plus API fiasco?
danans 7y ago
> 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 importantly, CUPS and driverless printing standards have solved the problem (os-specific print drivers) that cloud print was designed to work around. Disclosure: Google employee but not on cloud print, though I use it on my personal printer.
- irq-1 7y ago
  What are you going to use after this? A internet available print server? VPN?
  - danans 7y ago
    The problem I had that cloudprint solved was printing from a Linux machine to a local non-Linux-compatible printer. With CUPS and driverless printers, this is no longer a problem. I don't generally need to print remotely to my printer.
    - JAlexoid 7y ago
      Well... I do and I choose my printers based on availability for remote printing. You forget that there are a lot of cases where elderly people can't print shit and need actual paperwork.
      - danans 7y ago
        > You forget that there are a lot of cases where elderly people can't print shit and need actual paperwork I'm guessing you are referring to a scenario where you have configured an elderly person's printer to allow you to print directly to it, sort of like a one way fax machine? I can see how that could be useful for some people, but it's a very rare use case, and hard to argue for maintaining the cloud print service based on that. There appear to be alternatives for this specific use case, like HP ePrint, or you could set up a VPN to use in these situations. You could also just use printer that hooks up directly to eFax: https://www.faxcompare.com/blog/signing-up-for-efax-with-your-hp-all-in-one/ https://www.faxcompare.com/blog/signing-up-for-efax-with-you...
all_blue_chucks 7y ago
Having customer data is a liability. If someone hacks this service and gets the ability to read every customer's printout, it would be a disaster for Google's reputation. If it doesn't make enough money directly or indirectly to compensate for the liability it presents, it is actually a VERY expensive service to continue operating.
JAlexoid 7y ago
It's not free to run and it is not generating revenues. Have printer manufacturers pay for it's maintenance, then it's a reasonable argument for jut keeping it up.
- kllrnohj 7y ago
  > It's not free to run and it is not generating revenues. If there's only a few users then it's cheap to run. If there's a lot of users then this is a mountain of bad PR right at the time they are trying to get users to adopt new products (like, say, Stadia). Since all it does is shuffle PDFs & images between endpoints I'm gonna guess this is on the order of basically free to run. But either way canceling it isn't free, either. I'm arguing the cost of canceling this is far larger than the cost of keeping it running.
- saagarjha 7y ago
  Google is a large company. Surely the goodwill of keeping it around must mean something? Can’t they take a small loss on one of their “nice-to-have” products?
- lowercased 7y ago
  perhaps even charge people for it? like... it's part of a google business accounts? unless it's going to bring in multiples of billions of $ per year - and accelerate that growth - they're probably not interested in doing that though.
- chenning 7y ago
  I saw it as a counterpoint to AirPrint. I'd like to know what changed that made Google think they don't really need this anymore. Maybe they think WiFi Direct is going to be the future?
  - danans 7y ago
    Local wifi-based printing and printer discovery (same as Airprint) is already available on Google devices. No Cloudprint required.
rc-1140 7y ago
A lot of the responses to the parent are things along the lines of "well it needs to be owned by a team" and all the usual valid cost-related reasons why [x] can't be maintained, and of course that doing so is boring. Isn't this the kind of project that should be reserved for people in explicit learning states such as (for example) novice hires, new hires, and aspiring mangers who haven't done any management before? It doesn't really have burning deadlines, it's not a frontline project but it's still something that can be referenced as work with impact, there's still the technical challenge of keeping it functional as the years go by, and eventually it will actually be old enough to be taken out back and deprecated. If any company could do something like this with their various projects as well as culture, I'm pretty sure Google could. Of course there are probably a bunch of problems with this idea, but it seems to be more preferable in contrast to just axing a product that a not-insignificant number of people found useful and going "NEED. NEW. SHINY. TOY. MUST MAKE MONEY NOW!"
- plumeria 7y ago
  I think if they release it as OSS some people would eventually fork it and maintain it.
  - ce4 7y ago
    Except it doesnt work, don't forget that endpoints ( *.google.com or other google subdomains) are hardcoded in the printer firmware out there.
- kristianc 7y ago
  Over time, if the cost of creating a new thing for a company is maintaining it forever, a lot less new things will get made.
  - glangdale 7y ago
    I'm frustrated at the fact that this comment, and many others elsewhere on this, are creating the false dichotomy that Google either needs to ruthlessly kill products that many users are still using (Reader, Cloud Print, ...) or alternately support Every Single Product Forever. They can still kill their outright failures, of which there are many.
lokar 7y ago
Others have pointed out how this is hard with the Google code base (internal API changes, etc). But it's more than that. Consider how something like GDPR impacts this. It requires at least some work from Legal, Product, Eng, etc. And these things happen fairly often. Even without a monorepo it takes work to stand still.
vl 7y ago
At Google nobody gets a promo for maintaining stale product.
thaumasiotes 7y ago
> Outside of security patches, if there even are any On the fundamentals, a service the whole point of which is to let untrusted computers from the internet connect to your home network and talk to your devices is pretty likely to need continuous security updates.

arkanciscan 7y ago

See: Google Play Music

FactolSarin 7y ago
Which I still prefer to YouTube music, it's theoretical replacement

q3k 7y ago

> 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." That's not exactly possible with a monorepo that has no branches and everything has to be maintained 'in step'. Any time a library breaks API, all dependents must pass tests, and/or be fixed so that they do. Any time a runtime API breaks (think things like interfaces to runtime authentication, compute scheduling, database services, network bandwidth scheduling), updated services must be made to conform and then be rolled out. As with real life, this might mean getting a 1 or 2 year old deployment system (configuration for production, roll out code, ...) undusted, understood, probably fixed in turn, etc. As such, some SRE/SWE team _must_ be responsible for projects that are in the "don't touch"/maintenance phase. This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google.

formercoder 7y ago
This. Someone has to be in OWNERS and it’s difficult to find people willing to do this because fixing breakage due to API changes isn’t going to be on anyone’s OKRs. And if it’s not on your OKRs, it’s not contributing to your promo.
- eecc 7y ago
  Which proves the futility of these OKR metrics. Once the metric becomes the objective, it loses any usefulness, indeed it becomes the opposite
  - mattnewton 7y ago
    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?
    - asveikau 7y ago
      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.
remus 7y ago
> This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google. I don't think this is google specific. Keeping a dead product on life support is going to get boring for most people after a while.
- asdff 7y ago
  There is an infinite supply of cheap intern labor at every college in the U.S. chomping at the bit to mop the floor at google hq.

julianozen 7y ago

So this works in theory until there is a really bad bug in some part of the code base and there is no one who knows how to fix it. Or it breaks some kind of migration plan. Or it is embedded somewhere on some architecture that slows down an important projects development. or makes an application incompatible with a future OS If they’re not going to keep a team dedicated to keeping it alive, then you get into a situation where an emergency fix needs to be deployed or it needs to be abruptly cancelled It’s possible this already happened once or twice which is why they had to sunset it

kllrnohj 7y ago
> So this works in theory until there is a really bad bug in some part of the code base and there is no one who knows how to fix it. 10 years of production usage tends to have hammered out all the "really bad bugs." Sure it's possible that something goes wrong, but it's also extremely unlikely that it does unless something in it changes. Which, if you freeze it & silo it off, doesn't really happen. A huge amount of software not made in silicon valley operates exactly like this. It just sits there, running for decades, doing its thing.
- crehn 7y ago
  Still, the risk and maintenance/ownership burden is there.
  - kllrnohj 7y ago
    Yes, of course, but the point is it's a very, very small cost. It's basically zero for a company with Google's resources. Meanwhile killing it is actually costly. Not to engineering, but to PR and reputation.
- julianozen 7y ago
  I don't know. I'd bet anything that has been production for 10 years with no feature added means anybody who knows anything about it left ages ago. Its a cloud service that was started pre-Google Cloud. There is no way that it can sit in perpetuity and not be worried about old versions of Java, old OS, HTTPS bugs, large deprecation plans

deleted 7y ago

[deleted]

mattlondon 7y ago

> 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.

kllrnohj 7y ago
> 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.
- arbie 7y ago
  "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.
  - Already__Taken 7y ago
    Right. Is nobody remembering the Google Plus API fiasco?

danans 7y ago

> 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 importantly, CUPS and driverless printing standards have solved the problem (os-specific print drivers) that cloud print was designed to work around. Disclosure: Google employee but not on cloud print, though I use it on my personal printer.

irq-1 7y ago
What are you going to use after this? A internet available print server? VPN?
- danans 7y ago
  The problem I had that cloudprint solved was printing from a Linux machine to a local non-Linux-compatible printer. With CUPS and driverless printers, this is no longer a problem. I don't generally need to print remotely to my printer.
  - JAlexoid 7y ago
    Well... I do and I choose my printers based on availability for remote printing. You forget that there are a lot of cases where elderly people can't print shit and need actual paperwork.
    - danans 7y ago
      > You forget that there are a lot of cases where elderly people can't print shit and need actual paperwork I'm guessing you are referring to a scenario where you have configured an elderly person's printer to allow you to print directly to it, sort of like a one way fax machine? I can see how that could be useful for some people, but it's a very rare use case, and hard to argue for maintaining the cloud print service based on that. There appear to be alternatives for this specific use case, like HP ePrint, or you could set up a VPN to use in these situations. You could also just use printer that hooks up directly to eFax: https://www.faxcompare.com/blog/signing-up-for-efax-with-your-hp-all-in-one/ https://www.faxcompare.com/blog/signing-up-for-efax-with-you...

all_blue_chucks 7y ago

Having customer data is a liability. If someone hacks this service and gets the ability to read every customer's printout, it would be a disaster for Google's reputation. If it doesn't make enough money directly or indirectly to compensate for the liability it presents, it is actually a VERY expensive service to continue operating.

JAlexoid 7y ago

It's not free to run and it is not generating revenues. Have printer manufacturers pay for it's maintenance, then it's a reasonable argument for jut keeping it up.

kllrnohj 7y ago
> It's not free to run and it is not generating revenues. If there's only a few users then it's cheap to run. If there's a lot of users then this is a mountain of bad PR right at the time they are trying to get users to adopt new products (like, say, Stadia). Since all it does is shuffle PDFs & images between endpoints I'm gonna guess this is on the order of basically free to run. But either way canceling it isn't free, either. I'm arguing the cost of canceling this is far larger than the cost of keeping it running.
saagarjha 7y ago
Google is a large company. Surely the goodwill of keeping it around must mean something? Can’t they take a small loss on one of their “nice-to-have” products?
lowercased 7y ago
perhaps even charge people for it? like... it's part of a google business accounts? unless it's going to bring in multiples of billions of $ per year - and accelerate that growth - they're probably not interested in doing that though.
chenning 7y ago
I saw it as a counterpoint to AirPrint. I'd like to know what changed that made Google think they don't really need this anymore. Maybe they think WiFi Direct is going to be the future?
- danans 7y ago
  Local wifi-based printing and printer discovery (same as Airprint) is already available on Google devices. No Cloudprint required.

rc-1140 7y ago

A lot of the responses to the parent are things along the lines of "well it needs to be owned by a team" and all the usual valid cost-related reasons why [x] can't be maintained, and of course that doing so is boring. Isn't this the kind of project that should be reserved for people in explicit learning states such as (for example) novice hires, new hires, and aspiring mangers who haven't done any management before? It doesn't really have burning deadlines, it's not a frontline project but it's still something that can be referenced as work with impact, there's still the technical challenge of keeping it functional as the years go by, and eventually it will actually be old enough to be taken out back and deprecated. If any company could do something like this with their various projects as well as culture, I'm pretty sure Google could. Of course there are probably a bunch of problems with this idea, but it seems to be more preferable in contrast to just axing a product that a not-insignificant number of people found useful and going "NEED. NEW. SHINY. TOY. MUST MAKE MONEY NOW!"

plumeria 7y ago
I think if they release it as OSS some people would eventually fork it and maintain it.
- ce4 7y ago
  Except it doesnt work, don't forget that endpoints ( *.google.com or other google subdomains) are hardcoded in the printer firmware out there.
kristianc 7y ago
Over time, if the cost of creating a new thing for a company is maintaining it forever, a lot less new things will get made.
- glangdale 7y ago
  I'm frustrated at the fact that this comment, and many others elsewhere on this, are creating the false dichotomy that Google either needs to ruthlessly kill products that many users are still using (Reader, Cloud Print, ...) or alternately support Every Single Product Forever. They can still kill their outright failures, of which there are many.

lokar 7y ago

Others have pointed out how this is hard with the Google code base (internal API changes, etc). But it's more than that. Consider how something like GDPR impacts this. It requires at least some work from Legal, Product, Eng, etc. And these things happen fairly often. Even without a monorepo it takes work to stand still.

vl 7y ago

At Google nobody gets a promo for maintaining stale product.

thaumasiotes 7y ago

> Outside of security patches, if there even are any On the fundamentals, a service the whole point of which is to let untrusted computers from the internet connect to your home network and talk to your devices is pretty likely to need continuous security updates.