IoT Abandonware: When your cloud service leaves you stranded

A cloud service provider or an IoT vendor going belly up can cause your internet accessible devices to stop functioning. What can the industry do to mitigate further Aethers and Rdios from happening again?
Written by Jason Perlow, Senior Contributing Writer

In November, owners of the Aether Cone intelligent streaming audio device got a lump of coal for the holidays, when Aether, the manufacturer of the "smart speaker" announced it was going out of business.

To add insult to injury, Rdio, the streaming audio service that Aether Cone used exclusively also went belly up, with its assets sold to competing streaming service Pandora.

The Rdio service itself will be shutting down entirely over the coming weeks.

I liked the Aether Cone, as it had interesting design features. Unfortunately it also had fundamental shortcomings -- it only worked with one content provider, and it was more expensive than more functional competitors such as SONOS and Amazon's Echo. Its smartphone app was also somewhat limited in functionality.

The Cone has now been issued a final firmware update that effectively lobotomizes any of its "smart" capabilities -- all it can do now is act as a Bluetooth or AirPlay speaker, and as a consolation prize, it can now be used with Spotify Connect, which has to be controlled by the Spotify iOS/Android application.

If anything is to be learned from this, it is that there is great risk to purchasing IoT devices from startup companies, as well as subscribing to and depending on startup cloud services.

Having a single device like a smart speaker like the Aether become lobotomized -- or in a worst case scenario, find itself completely nonfunctional or unable to be reconfigured/re-initialized -- is unfortunate, especially if we are talking about a piece of equipment that costs several hundred dollars.

Combining the two, in the case of Aether and Rdio is clearly a recipe for disaster.

But this has potentially much more serious implications for devices that are integrated components as part of a household's automation system or used in a business setting.

This is going to have a chilling effect on the IoT industry because it is going to make it more difficult for smaller players to enter the game.

Sure, that smaller player might have more interesting features, but do you really want to take a risk on deploying and investing in a multi-sensor, multi-device setup in your home or business if the devices have a risk of becoming non-functional if the vendor goes under?

In a previous article last spring I talked about how IoT is a veritable "Tower of Babel" of competing protocols and vendors. In it I called for increasing vendor interop as well as the establishment of standardized protocols, so that device ecosystem silos between vendors become less of an issue.

Embracing interoperability would not necessarily have made the Aether/Rdio belly-up situation easier to swallow for their end-users, but it would have made it easier for Aether's product engineers to provide open firmware that in the event of the company's collapse, the Open Source community could supply alternative firmware to make the device communicate with an alternate set of cloud services, so the device could be salvaged.

We need to stop thinking about IoT devices as completely disposable. Those of us who have put smart devices in our homes and businesses expect them to function for years, if not a decade at a time.

These aren't the same kind of IT assets which depreciate over a period of 3-5 years and have to be pulled out for planned upgrades due to capacity or business continuity concerns -- once we put these things in, we want them to continue to work, indefinitely.

Frankly, barring device failure, there's no reason why they need to be pulled out and replaced at all. I expect my NEST thermostat and the cloud service it connects to continue to work until the device itself dies.

These devices are for the most part solid state, and they don't die so easily.

The same goes for my WeMo Wi-Fi smart switches, My Philips Hue bulbs, my Wi-Fi-connected Big Ass Fan, my Scout internet-connected home security system, and my iAqualink/ZODIAC swimming pool control system. And yes, my Amazon Echo and my SONOS multi-room speaker setup.

All of these companies need to seriously consider providing open source firmware -- the reason being that even if they stay solvent, there will come a point in time in which it might be impractical to continue to provide firmware updates to these devices.

If they use Open Source Software in the design of these devices, particularly if they are Linux-based and use GPL-licensed components, it behooves them to release the source code of what runs on these devices anyway. But frequently it is difficult to get vendors to release source code unless formal requests are made.

Developers and end-users should not have to do this, it should be standard practice for any IoT device vendor.

Certainly, we have learned from community projects such as CyanogenMod and DD-WRT that is possible to extend the life of a device long after the manufacturer is able to provide continuing support for the product.

The end user might still decide to throw out the device and get a new one anyway, but having the option to re-image with new firmware should be available.

This is no different than what we have seen in the automobile industry where parts are still manufactured for older cars by 3rd-parties, in some cases long after the original automaker has gone belly-up.

If we can do this for smartphones and Wi-Fi routers, why not devices like the Aether? Or the NEST? Or Echo and SONOS, for that matter?

Should all IoT device manufacturers be compelled to provide Open Firmware? Talk Back and Let Me Know.

Editorial standards