3 ms·

It comes down to “the project doesn’t have enough staffing to keep operating” in the end, and those decisions get made way higher up. Any engineer at Google has

It comes down to “the project doesn’t have enough staffing to keep operating” in the end, and those decisions get made way higher up. Any engineer at Google has no visibility into that. Engineers at Google only understand how understaffed projects get shut down—it’s because there isn’t enough staff on the project to keep updating to work with Google’s changing infrastructure. This isn’t the root cause, though, it’s just a contributing factor. Maybe if Google infrastructure changed less, some of these projects would stick around longer with reduced staff.

bitcharmer 2y ago
How much staffing does a feature like that even require? It's not like it even requires any maintenance at this point. They could just leave it alone.
- roland35 2y ago
  I think the issue is that the underlying dependencies are changing, so even if the feature set never changes it still requires some amount of engineering work to keep it up and running.
- myth_drannon 2y ago
  Depends on the tech stack. If it's JS/TS then it's a nightmare to maintain, with all the Critical and High security issues. Packages that are not updated anymore you need to replace with something else. You can't just leave it alone, it's easier to shut it down and save yourself another accident and subsequent postmortem.
- klodolph 2y ago
  It does require maintenance, unfortunately.
- criddell 2y ago
  The service has access to years and years of very fine-grained location data for millions of people. There's no way they could just let it drift. It would be a liability nightmare.
londons_explore 2y ago
To be more concrete... It isn't acceptable for a service to be running from a years-old build, since it wouldn't pick up any security fixes. Googles infrastructure evolves reasonably quickly - so most reasonably large services will need quite a few code changes every year just to keep up with the fact that internal database type X is going away and everyone needs to migrate to database Y which might have subtly different semantics requiring bits of your service be rewritten. There is also a gradual flow of legal/privacy mandates (eg. as of Y date, IP addresses must not flow through technology Z because we now have to consider them personal information) At some point, one of these migrations requires a lot of work, and there aren't enough humans really keen on doing the work, so it gets shut down. Management could assign workers to do the work, but generally maintaining stuff isn't good for the career path, so few volunteer for big but non-impactful projects like this. As soon as the 'founders' of a project have moved on, it is vulnerable to this kind of shutdown.
- klodolph 2y ago
  We can assume that with minimal staff, the project is still building and deploying new versions with new dependencies. If it weren’t getting new builds and security fixes, it would raise internal alarms designed to catch unpatched software. It’s the “database X is going away” that really, really kills an understaffed project.
- brigandish 2y ago
  > Googles infrastructure evolves reasonably quickly - so most reasonably large services will need quite a few code changes every year just to keep up with the fact that internal database type X is going away and everyone needs to migrate to database Y which might have subtly different semantics requiring bits of your service be rewritten. I find this an unsatisfying explanation (to be clear, I'm not criticising you but the effect you're describing), if we develop to interfaces as a principle, then underlying implementations shouldn't matter.
  - Tyr42 2y ago
    We have interfaces. They have one implementation. Then next year we have different interfaces with a different implementation.
davidmurdoch 2y ago
I figured engineers wouldn't know. But someone at the company makes these decisions. Do they ever poll random users to get feedback in how much a feature is loved? I'm curious what data and processes are used to determine if a project should be staffed more vs just killed. From the outside it doesn't make sense.
wwtrv 2y ago
> enough staffing to keep operating” Which is interesting considering how bloated Google seems to be.
BurningFrog 2y ago
Changing infrastructure so much that you constantly have to rewrite your actual applications is a tail-wagging-the-dog scenario.
donkers 2y ago
It’s not a staffing thing. They’re fundamentally getting away from storing your location data to avoid having to deal with law enforcement requests and other problematic things.
- deleted 2y ago
  [deleted]
brainwad 2y ago
I don't think that's it, since this project has been in the works for years and has burnt way more resources than just keeping on-server location history in maintenance mode ever would have. It seems to be motivated by actual privacy concerns with Google keeping an exhaustive history of users' precise and semantic locations on Google servers, in particular the increasing use of geofence warrants (https://www.forbes.com/sites/cyrusfarivar/2023/12/14/google-just-killed-geofence-warrants-police-location-data/ https://www.forbes.com/sites/cyrusfarivar/2023/12/14/google-...).
surajrmal 2y ago
While often true, in this case it seems like supporting the web view as it would break the new security model. I'm sure they could develop something similar to how you can use WhatsApp from the web, but that's also probably a lot of work for a feature that's probably not heavily used.

bitcharmer 2y ago

How much staffing does a feature like that even require? It's not like it even requires any maintenance at this point. They could just leave it alone.

roland35 2y ago
I think the issue is that the underlying dependencies are changing, so even if the feature set never changes it still requires some amount of engineering work to keep it up and running.
myth_drannon 2y ago
Depends on the tech stack. If it's JS/TS then it's a nightmare to maintain, with all the Critical and High security issues. Packages that are not updated anymore you need to replace with something else. You can't just leave it alone, it's easier to shut it down and save yourself another accident and subsequent postmortem.
klodolph 2y ago
It does require maintenance, unfortunately.
criddell 2y ago
The service has access to years and years of very fine-grained location data for millions of people. There's no way they could just let it drift. It would be a liability nightmare.

londons_explore 2y ago

To be more concrete... It isn't acceptable for a service to be running from a years-old build, since it wouldn't pick up any security fixes. Googles infrastructure evolves reasonably quickly - so most reasonably large services will need quite a few code changes every year just to keep up with the fact that internal database type X is going away and everyone needs to migrate to database Y which might have subtly different semantics requiring bits of your service be rewritten. There is also a gradual flow of legal/privacy mandates (eg. as of Y date, IP addresses must not flow through technology Z because we now have to consider them personal information) At some point, one of these migrations requires a lot of work, and there aren't enough humans really keen on doing the work, so it gets shut down. Management could assign workers to do the work, but generally maintaining stuff isn't good for the career path, so few volunteer for big but non-impactful projects like this. As soon as the 'founders' of a project have moved on, it is vulnerable to this kind of shutdown.

klodolph 2y ago
We can assume that with minimal staff, the project is still building and deploying new versions with new dependencies. If it weren’t getting new builds and security fixes, it would raise internal alarms designed to catch unpatched software. It’s the “database X is going away” that really, really kills an understaffed project.
brigandish 2y ago
> Googles infrastructure evolves reasonably quickly - so most reasonably large services will need quite a few code changes every year just to keep up with the fact that internal database type X is going away and everyone needs to migrate to database Y which might have subtly different semantics requiring bits of your service be rewritten. I find this an unsatisfying explanation (to be clear, I'm not criticising you but the effect you're describing), if we develop to interfaces as a principle, then underlying implementations shouldn't matter.
- Tyr42 2y ago
  We have interfaces. They have one implementation. Then next year we have different interfaces with a different implementation.

davidmurdoch 2y ago

I figured engineers wouldn't know. But someone at the company makes these decisions. Do they ever poll random users to get feedback in how much a feature is loved? I'm curious what data and processes are used to determine if a project should be staffed more vs just killed. From the outside it doesn't make sense.

wwtrv 2y ago

> enough staffing to keep operating” Which is interesting considering how bloated Google seems to be.

BurningFrog 2y ago

Changing infrastructure so much that you constantly have to rewrite your actual applications is a tail-wagging-the-dog scenario.

donkers 2y ago

It’s not a staffing thing. They’re fundamentally getting away from storing your location data to avoid having to deal with law enforcement requests and other problematic things.

deleted 2y ago
[deleted]

brainwad 2y ago

I don't think that's it, since this project has been in the works for years and has burnt way more resources than just keeping on-server location history in maintenance mode ever would have. It seems to be motivated by actual privacy concerns with Google keeping an exhaustive history of users' precise and semantic locations on Google servers, in particular the increasing use of geofence warrants (https://www.forbes.com/sites/cyrusfarivar/2023/12/14/google-just-killed-geofence-warrants-police-location-data/ https://www.forbes.com/sites/cyrusfarivar/2023/12/14/google-...).

surajrmal 2y ago

While often true, in this case it seems like supporting the web view as it would break the new security model. I'm sure they could develop something similar to how you can use WhatsApp from the web, but that's also probably a lot of work for a feature that's probably not heavily used.