Yes they can. Car companies support ten model years and more just fine, and keeping servers alive is a lot easier than constantly replacing mechanical parts.

This sort of logic is enshrined in consumer law as well - the courts idea of a reasonable lifetime for a product is tied to the amount you pay.

If you buy a $50,000 car new, sure, a reasonable person could expect it to last 5-10 years.

You buy a $200 webcam? I somehow doubt you'll be able to argue that it must work 3 years later - if it does, great. If it doesn't, well, what's a reasonable lifetime?

And a lot of armchair commentators seems to underplay the amount of sheer engineering effort or cost involved in these sorts of things - it's not a case of spinning up some AWS instances, and hacking together some PHP on your weekend and deploying.

To get a reliable service, with some decent SLA, which handles changing load and tolerates failures probably takes significant infrastructure (cloud or bare-metal), as well as a team of software engineers and site reliability engineers. Not to mention support teams.

I just had to pick this one. Five years for a car? I expect clothes and computers to last 5 years, for $50k car I'd expect 20-30 years with proper maintenance and repairs. Not that I'd likely use it myself that long, but the expectation would still be within that timeframe.

Or if you buy a shirt and wear it for 5 years - you'd go back to Kmart after 5 years and say, your shirt wore out, give me a refund?

The sense of entitlement in that statement is...pretty high. I'm just going to leave it at that.

If I expect shoes to last 10 years, I'm also prepared for some basic maintenance such as regular polishing and the odd sole replacement. The same obviously applies to car repairs.

If they sold it to me with the claim that the drivetrain had a lifetime warranty, and the fault was there?

Yes.

I see this all the time with people that know zilch about technology, but it really disappoints me when I even see my fellow technologists underestimate the amount of engineering effort it takes to get something simple like a server up and running reliably.

Computers don't exist in a vacuum - the environment is constantly changing.

Let me put a real-life example.

Say there's a new SSL vulnerability or zero-day discovered - you go and check to make sure all your servers and packages are patched. Or maybe there's no patch yet, and you need to run a mitigation.

You better go check all your logs, to make sure nobody got in already though. Hmm, maybe you should contact your NOC as well, just in case.

Load just increased - you better spin up some new servers. Whilst AWS might like you to believe this is all one-button and it works with no human intervention - it probably isn't.

Oh, drat, one of the uptream endpoints you rely on just broke their API. You better whip up a patch. Then you need to test it, and make sure your CI server passes all the tests for it. Oh, and then hire some testers.

The point is - things are more complex in the real world, particularly running at any kind of scale.

Not exactly; in the UK it's tied to "reasonable expectations" for that kind of product. Certainly non-smart heating controllers would have an expected life time of 10-20 years, so why do the more expensive smart ones get away with a lifetime of less than 3?

Heck, even 5 years?

All of this for some cheap widget? (I assume from your description it's cheap).

If you can find a single case (or similar case) where this happened, I will stand corrected.

If this was a $2000 laptop, I can absolutely see that - e.g. Apple Macbooks in Australia have a statutory warranty longer than the manufacturer's 1 year warranty. But I think you'd be hard pressed trying to claim after 3-4 years that it should still apply there. And this is for a $2000 laptop.

Here's an example of how it often works in practice, although on a shorter timescale: http://forums.pepipoo.com/index.php?showtopic=52242

Laptop power socket fails within 6 months. Is repaired, fails again. Demands refund, is refused. Takes company to small claims court; they fail to mount an effective defence and are in any case in the wrong, so he wins £400+costs.

Almost a million ford F-150 trucks were sold in 2006 and most haven't been 'rewritten' in the intervening years. Also, each repair event comes with new money. Neither of these conditions is true for server software.

Server and package vulnerabilities get discovered all the time.

And load is never constantly - it's not like you have 1000 users, and they do the same thing every day, 365 days a year.

And there are an army of script kiddies out there trying to break into your servers. Or maybe somebody more skilful, trying to break in and steal some PII (personally identifiable information).

Point is - the environment and your users are constantly changing. If you don't take that into account, it can blow up pretty bad.

Load isn't constant, but if you're not selling the device any more it's doubtful you'll have significant load increases after the first year.

Shutting down a tiny fraction of your servers isn't going to protect you against hacking.

Worst case scenario: Remove all PII from the server, and have a single employee spend a few hours a week checking on the server and updating anything necessary. It might go down occasionally, but it's infinitely better than no server at all, and it costs basically nothing compared to the original development effort.

There's much more to running a product than 'running a server'.

Eventually, the software is going to stop working on my SOE. Which means more and more boxes are going to be running non-standard deployments in my environment (or it costs me to update). Every maintenance window, infrastructure upgrade, disaster recovery exercise (and event), has to take those servers into account.

Perhaps I pay licenses for those servers to run - OS, support, databases, backup, whatever. Maybe I have a contract with an SI to run all this as a managed service and this costs. There's opportunity cost in terms of resources for keeping all these legacy products on as well - both infrastructure and resource related.

And that's just the technology related part of it. There's business and accounting impacts as well.

If you're fussy about nonstandard servers on your infrastructure, go get a handful of basic servers from hetzner or amazon. Completely silo them. No access from them to your 'real' servers, and don't include them in maintenance windows or disaster recovery. The person who is paid to spend a few hours per week keeping the server mostly-up will use part of their time on basic updates and backups, and nobody needs to worry if something occasionally breaks.

> Perhaps I pay licenses for those servers to run - OS, support, databases, backup, whatever. Maybe I have a contract with an SI to run all this as a managed service and this costs.

If you have license/contracting costs, you should have pre-allocated money for that when you released the product. If it sold to expectations, a later decision to discontinue the line shouldn't be a problem.

> There's opportunity cost in terms of resources for keeping all these legacy products on as well - both infrastructure and resource related.

There should be no infrastructure impact, and the equipment/employee cost should have been part of the initial product scope, not treated as an externality that can be trimmed at will.

> And that's just the technology related part of it. There's business and accounting impacts as well.

Like what, having to process a quarterly bill for the servers?

Let me put it this way: While the costs are real, they were expected, and can be made pretty low. They should be able to run or outsource a basic legacy server without any hurting. I bet if there was a contract saying they had to refund $2 to every customer for every month the servers were down, they could get plenty of offers to take over hosting for half that price.

I know it sells headlines, but I've seen zero evidence at all to back up these claims.

From what I can tell, they're simply pulling the plug on the service.

They already stopped all sales of the units nearly two years ago - in fact, that's one of the first things they did when they bought out the failing Revolv company.

So they've basically paid to keep it running for two years - and this is just speculation, but maybe they decided, this is enough, it's just bleeding money, we have zero revenue to show for it all (since we haven't sold any units in two years), we need to pull the pin on it eventually.

The real reason for pulling the plug on Revolv is to try and drum up Nest sales, but it was executed poorly since they haven't made any particular effort to steer the screwed Revolv users to Nest, or offered any concession.

Tony Fadell will no doubt shit his pants when he reads this post, but despite how accurate it is, I don't even work there.

But that said, I think it's more than that. There's no such thing as autopilot on the Internet, particularly for a company that deals with customer PII (and I count the ability to control stuff in your home in that category. :-). You can imagine the rathole -- we've all been down it a few times: You need to upgrade the kernel/libc on your EC2 instance because of the security vulnerability du jour. But libraries X and Y won't run after the upgrade, so you need to upgrade them. But the developer of those libraries changed the interface, so now you need to... yadda, yadda. One or two of those changes you can probably just hack in, but depending on how disgusting the codebase is (and let's be honest here - it was an acqui-hired startup that was probably in panic mode towards the end!), at some point, it starts looking like a choice between a total rewrite or tossing it to the wind. Suddenly that takes you up to an FTE, who in the valley is going to cost you >= $20k/month. Then you divide by the # of still-active devices (I have no idea what this # looks like) and suddenly it looks like a big resource drain for no benefits.

(Imagine, for example, that the engineers became aware of a firmware-level vulnerability that exposed all customer devices to remote exploits and control -- and somewhere between the acquisition and then the build system for rebuilding and testing the firmware had gotten screwy. Or the last set of test devices in the lab finally broke. Or that, plus it turns out the remote firmware update mechanisms had never worked in the first place, and fixing all the bugs would require not just fixing them, but actually creating and deploying an entirely new update path. Or, or....)

Of course, one can wish that were the case something like that, it had been communicated. My fingers are crossed that maybe Nest - and other companies - can use this as a learning experience and come up with policies, with teeth about acquisitions, governing the sunsetting of cloud based services that are essential for the operation of customer hardware. I'm not optimistic yet, but I'm glad to see the EFF raising the issue.

You get a couple years use out of it - do you really expect the company at the end of it to be like, gee, let me buy the gadget back off you?

I mean, come on....

It'd be super swell if the company decided to just throw money out at people like that, but come on, the sense of entitlement of some people here is nuts.

Look, I bought the Titanfall game. It's multiplayer-only. I knew that when I bought it. Just like the people who bought Revolv 3 or 4 years ago.

If Respawn (makers of Titanfall) decides to shut down the servers tomorrow, sure, I'll be upset, but I'm not exactly going to go on some massive nerd-rage, because I believe they should just keep it running forever.

Do you really think I'm going to turn around and demand a refund, a year later?

I work in tech - so I know how much it costs to keep infrastructure running, and the teams of people that work behind the scenes to keep it all running smoothly.

Surely we're not so disconnected that we know that we engineers get paid a pretty good amount, right?

> do you really expect the company at the end of it to be like, gee, let me buy the gadget back off you?

Yes. If it is cheaper to migrate (or compensate) a handful of existing customers for free than to keep running a legacy service, the company should be making this call.

I mean, come on...

I knew that when I bought it. Just like the people who bought Revolv 3 or 4 years ago.

You don't really know what every person knew that bought Revolv, do you?

I work in tech

Especially since it is your business to know more about this than the average consumer?