Some of us have a closet full of connected devices that at one time represented the cutting edge of smart home tech — devices like the Revolv hub, the Lighthouse camera, the Jibo robot, the Petnet feeder, and the original Sonos speakers. And while most of us were able to shrug off the end of Juicero and the related loss of $400 as the inevitable cost of living the early adopter lifestyle, the perception of expensive, short-lived gadgets haunts consumer IoT.
Every time these stories hit the tech press or the mainstream media, a much larger group of people congratulate themselves for not buying into the latest hype around connected devices and smart homes. They recognize that this tech is new, unproven, and likely not as convenient or necessary as its creators claim. Which is why — even more than the lack of standards that we in the smart home world constantly bemoan — the lack of faith in the life of a connected product hurts the IoT. After all, if you can’t convince someone to buy a connected product in the first place, they’ll never reach the point where they’ll want it to interoperate with other devices.

So what’s the industry to do? The common demand after a product fails and the companies that make them tell their customers they’re turning off the servers (if they do, in fact, tell customers that) is to open-source the device code so the tech-savvy early adopters can keep the device operational. But while this sounds great, it’s akin to cryonically freezing your head in the hopes of coming back to life after death.
Getting the code running on a connected device without having access to the backend cloud code and the application code may allow the device to run, but the overall experience will suffer. The device may work, but it won’t have a good interface (or you’ll have to build and maintain it) and it won’t have a cloud component for remote access and other functionality (unless you build and maintain it). Just like your newly thawed head will need a body, the open-source device code needs someone to build and maintain a cloud backend and a mobile application.
There are third-party companies such as Digital Dream Labs, which raised funds to take over the support and development of the Anki Vector robot, that are attempting to take device code and build infrastructure around it. But doing so requires expertise, time, and money. Are customers willing to pay someone a second time just to keep their devices running?
So when asking a company to open up its source code for a connected device, ask yourself if your frozen brain is successfully revived, if that would be enough for you.
Such partial resurrection was the plan all the way back in 2015 when we starting seriously discussing what happens when connected products fail. Some companies put code in escrow so people could have it later and maintain it. In the meantime, I encouraged venture firms, entrepreneurs, and development shops to think about failure and how their product might gracefully degrade to give the consumer time to come to terms with the loss.
Now I realize that keeping code in escrow and thinking about failure are only part of the solution. Granted, because people crazy enough to build a connected pet feeder are often stupidly optimistic, it’s still good advice. Please do think about what happens if your business fails so you can build a decent experience for the end consumer. Also, set milestones that indicate failure so you can warn your customers in time and perhaps allocate some of the diminished cash on hand to ensuring a graceful shutdown.
By far the greatest challenge for connected device companies is the ongoing cost of operating those devices. An investor in Mellow, the maker of a connected sous vide machine that recently told customers they needed to pay a subscription fee or see certain features vanish, explained the issue. He told me that the company has roughly $4,000 in monthly costs associated with the device and those costs go up the more people use it. And that doesn’t include the ongoing costs associated with having a developer update the Android and iOS apps.
Some of those monthly bills might be lowered by choosing a different cloud architecture or security platform, but every connected device company has to account for ongoing maintenance costs. And the more features a company adds and the more customers it has, the higher those costs tend to go. At an event I hosted in August, Matt Van Horn, CEO of June Life, said that his company’s cloud bill continues to rise, and he doesn’t have the resources or cloud infrastructure that Amazon or Google do.
So one option might be to only buy gadgets made by those companies, since I doubt AWS is going to shut Alexa down if that business unit stops paying its cloud bills. But that’s a really limiting option for consumers — and for innovation in the sector overall. Nate Williams, a former employee at August and now an investor at Union Labs Ventures, says he thinks some kind of model built around an independent organization that companies pay into, and that will operate and support a device and the supporting server code going forward, might help.
He initially likened it to a homeowners’ association for smart home devices, but given the negative connotations around HOAs then clarified that he was seeking a sense of shared responsibility as opposed to something punitive. But I think having a little enforcement might actually be good. We could see companies pay into an organization that ensures a product has a year or 6 months of cloud and developer costs in escrow to at least ensure a failed company can keep a product running for a little while longer after giving customers notice that it will die.
That organization should also have some sort of provision for getting the remaining stock of a defunct product off the shelves. Indeed, I’d love to see retailers like Best Buy or Amazon get involved. Kickstarter or Indiegogo might also be good members of such an organization to add a little more credibility to the products launched on their platform.
This sort of upfront cash that would be held in escrow to cover six months of cloud and developer costs would be a burden for smaller startups or folks trying to build something in their garage. It would be great to see scholarships or other models arise that could pay those costs for a company that can’t otherwise afford it. It could be kind of like a pension plan for IoT devices.
This may not be the right solution, but failed consumer IoT devices or abrupt changes in the business model for connected devices are a very real problem that holds back adoption. I’d love to see us set aside optimism so we could focus on what to do if the companies behind these products fail.
I’ve always though Juicero was actually a piece of conceptual performance art designed to mock Silicon Valley techno-utopianism, much as Piero Manzoni’s Merda d’Artista mocked modern art critics and the whole economy built around them.
As for IoT devices, the obvious answer is they must not have cloud components that invade privacy and are a flimsy excuse or rationalization for the company-centric need to extract subscription revenue. Even the cheapest 32-bit MCU is more than perfectly capable of running network services on its own. In fact what we really need a “Cloud-free” label for IoT just like the FDA Certified Organic label. I certainly won’t buy any IoT device that requires a cloud component to run, and enforce this on my firewall.
> In fact what we really need is a “Cloud-free” label for IoT […] I certainly won’t buy any
> IoT device that requires a cloud component to run, and enforce this on my firewall.
Hear! Hear!
Another option could be to have a device as a service model, that makes a customer pay over a period of time, thus ensuring recurring revenues for the maker or assured service for the user, even when the original maker maybe under.
“IoT: Who’s gonna maintain it” https://link.medium.com/im6Bm0EIA9
Everything can operate in the cloud, but should it? Yes, it saves a company on server infrastructure. But does a device constantly need to “phone home”? Some people by now realize that having a home server to anchor their IoT devices makes much more sense. And as far as I’m concerned, edge computing is extremely more practical and faster. And since at least one person in the home acts as the net admin anyway, it shouldn’t be all that difficult to run a script that looks for updates once a week.
Heh. “Edge computing.”
It’s called a home automation controller and they have existed for more than 20 years.
I have homeseer now. Hubitat is another prebuilt option or the open source CQC, HomeAssistant and OpenHab.
Just use Hubitat.
Can’t we have these devices and sensors use Zero-configuration networking on the local link network to enforce in-home control abilities and prevent external attacks on these weak security devices.
A bridge would be necessary to allow MQTT external access and death of the external servers should not impact the device and local control.
We don’t need mater to continue monetization at our expense and risk.
I’m not entirely convinced that the Matter protocol is going to be the final solution for those wanting a cloud based setup. It’s one of those “sounds too good to be true” deals.