281–289 of 289 posts
Earlier quoted context omitted.
Does the Jamboard cease to be usable without the cloud-based stuff?
Most cloud based items are like this by default, and by design. We throw the environment under the bus, to make our next quarterly profit.
Earlier quoted context omitted.
I worked for a sorta "satellite" IBM company. There was always a path or solution of some sort in the IBM world. Expensive as hell yeah but there was a path. And if you wanted to do something slightly weird or that IBM just didn't want to do... there were these satellite companies that IBM was happy to work with us to cover other solutions. IBM never cut us off, was happy to certify stuff to work with them and so on.…
Right. I think it all comes down to the fact that with Google, maybe 2/3rds of any product is software running on servers they control. You can never see that software, let alone modify it. Even the decision to keep running that software on Google’s hardware is totally out of your hands - Google could turn it off literally any day, for any reason. This is the downside of relying on someone else’s cloud software: ulti…
Google has SLAs and service contracts that they are contractually bound to. They technically can turn off their services any day, but they won't, for the same reason that they won't liquidate all their assets into cash and drop it out of a helicopter - because it'd be extremely financially stupid.
This comment makes no sense because it's discussing something that is extremely unlikely to happen - far, far less likely than a service failure caused by self-hosting.
I can predict the whining already, but 8 years is really not a short lifespan for a product. That's an honest effort at getting a market, which failed. That's life.
Stop defending the billion dollar corporations when they make expensive hardware into expensive paperweights. Google could easily open source the software needed to run this without their cloud services.
Earlier quoted context omitted.
Googles backends are all proprietary solutions. So you’d need to open source a huge swath of google code. Much of which has assumptions of running in Google’s DCs.
Eh. They could just opensource the code but not its dependencies. The opensource world is remarkably good at taking something like that and getting it working again. They won’t though, unfortunately.
So open sourcing just jamboard specific code and nothing else even if possible wouldn’t build or be really useful.
Earlier quoted context omitted.
Right. I think it all comes down to the fact that with Google, maybe 2/3rds of any product is software running on servers they control. You can never see that software, let alone modify it. Even the decision to keep running that software on Google’s hardware is totally out of your hands - Google could turn it off literally any day, for any reason. This is the downside of relying on someone else’s cloud software: ulti…
> Google could turn it off literally any day, for any reason. Google has SLAs and service contracts that they are contractually bound to. They technically can turn off their services any day, but they won't, for the same reason that they won't liquidate all their assets into cash and drop it out of a helicopter - because it'd be extremely financially stupid. This comment makes no sense because it's discussing somethi…
I'll grant, Google has SLAs on some of their products (like Firebase). But trust arrives on foot and leaves on horseback. Wave, Inbox, Reader, etc. I still remember - with horror - that time google suddenly announced they were massively increasing GCP (Google Apps?) pricing without warning anyone beforehand.
Is there a prediction market for the life expectancy of google products? Some things will probably be around more or less indefinitely: Docs, Gmail, etc. But the base rate for "this google product, service or API will still be available in 1 year" is probably somewhere between 1% and 10%. I'd consider any "all in" strategy on a lot of google's tech to be a serious business risk for that reason. Especially if losing that bet means you need to rearchitect your entire application.
Earlier quoted context omitted.
Eh. They could just opensource the code but not its dependencies. The opensource world is remarkably good at taking something like that and getting it working again. They won’t though, unfortunately.
I don’t think you get how difficult that is. It wouldn’t build, it would include a ton of internal libraries. For example stubby is not open source. Internal spanner is different than external spanner, including API/SDKs. The code pulls in a ton of internal libraries. Etc. So open sourcing just jamboard specific code and nothing else even if possible wouldn’t build or be really useful.
> So open sourcing just jamboard specific code and nothing else even if possible wouldn’t build or be really useful.
Oh, it definitely wouldn't build. But you'd be surprised how resourceful opensource developers can be when they have a clear scope & clear spec to work towards. This sort of work is akin to making the world's simplest emulator for a video game console - except you only need to get "one game" to run, and you have its source code and you can change the code as much as you like. Its fun, satisfying work.
Obviously you're rolling the dice on whether or not anyone from the community would step up and do that work on your behalf. But the alternative is killing your product entirely. The opensourced wave died because we didn't grow an opensource community who understood & wanted to maintain the codebase. Looking back, we might have done a better job of that if we didn't do all the work ourselves to make it usable first.
Mind you, I have no idea how the community at large would react to google releasing broken source code. They might complain even more than the service just going dark. But I can still dream.
Earlier quoted context omitted.
Most cloud based items are like this by default, and by design. We throw the environment under the bus, to make our next quarterly profit.
Who's "we" here? I'm sure not throwing the environment under the bus.
How does Google not recognize the doom loop they’re entering with these decisions? 1. Google has already made it tremendously difficult for any product of theirs to succeed. They could have a product that’s extremely successful by any reasonably measure, but not at Google scale, in which case they kill it. So the standard of success a product needs to reach at Google is already ridiculously high. 2. Because Google ma…