[waych]

Doesn't surprise me. Google has trouble planning for anything longer than 1-2 OKR cycles, which nowadays means 6-12 months (previously 3-6 months). Sustainability planning and long term support just aren't in their wheelhouse as a result. In fact, anything long term planning there is a bit of a farce, including headcount planning done yearly.

[ineedasername]

The crazy thing is that they don't even need to actually support a 6 year old product: you're not getting much in the way of updates from a random netgear router that old. But Netgear isn't going to brick your device so you can't make changes and reconfigure it. All google has to do it not block it in the Home app.

[waych]

The problem is that, as a product, it's just not built to be sustainable with zero effort.

The phone apps end up having to keep up with the underlying android+ios stacks' ever changing details, but even worse are the cloud services that help make the app -> router connection seamless, with the need to keep up with the ever-ongoing churn required to run binaries on Google's servers (aka "in Production").

To give an idea of how much churn is required to run binaries "in Production", there is a 6 month build horizon enforced across the company to ensure that all teams keep up with the underlying churn (changes to security, rpc, filesystems, monitoring, libc, etc). Running binaries older than that is verboten. The reasoning is that teams building the underlying components would never get a chance to upgrade / turndown down-versions/ down-compatibility.

Supporting these products means requiring staffing the role of keeping these services running from both dev+ops perspectives.

It sounds crazy but the system is designed to build "at scale" rather than to be built "sustainably". Dealing with this ever ongoing churn is the typical life of a Google engineer building "in prod". The model works well with a healthy CI/CD (albeit still a waste of time to deal with mandated churn), but falls apart quickly when staffing is removed.

[trhway]

>the cloud services that help make the app -> router connection seamless

an idea - "Cloud free" label for hardware similar to "GMO free" for food

[ineedasername]

Yes, 3 categories:

--Cloud free

--Cloud required

--Cloud supplemented

The last one would need to be accompanied by a list of features that depend on the cloud.

Expiration dates should also be required. "Guaranteed support for X years from original release date; Y Years from date of final official sale."

I'm not inherently against products that use or require cloud infrastructure to function, but I think consumers should have the information needed to make an informed decision.