As we noted in Part 1 of our post about the newly formed Open Connectivity Foundation (OCF), Qualcomm has joined Intel, Microsoft, and numerous other technology vendors in support of the IoTivity framework for interoperability among IoT devices. Given that Qualcomm was the creator of the competing AllJoyn framework and founder of the AllSeen Alliance, this inevitably begs the question of the long term viability of AllJoyn. The current position of AllJoyn can perhaps be summarized best by the classic scene from the film Monty Python and the Holy Grail, “I’m not dead.”

In our meeting at Mobile World Congress with OCF Executive Director Michael Richmond, he noted that IoTivity’s plug-in architecture will soon support AllJoyn. Referring to Qualcomm membership in the OCF, Richmond said the task of implementing AllJoyn support is “a lot easier when you have the people who wrote it.” (Not surprisingly, not everyone who wrote AllJoyn is onboard with shifting to IoTivity. For an interesting perspective on the matter, see the post entitled, “OCF: True IoT alignment or an Oligopoly Club For now?” by Liat Ben-Zur, cofounder and former Chairman of the Board of Directors of the AllSeen Alliance.)

Nevertheless, with Qualcomm joining the OCF, it appears that the writing is on the wall for AllJoyn. Sure, AllSeen Alliance members can continue to develop and produce AllJoyn products, but what would be the point of constraining themselves to a smaller ecosystem? There indeed may be product scenarios where the AllJoyn framework is technically suitable when IoTivity is not, but those are likely to be few and far between. And some vendors might seek freedom from standards that are under the control of the industry’s big players, but such appeal is limited.

So why would OCF support AllJoyn at all? In our view, doing so has two main benefits. The first is to ensure that any AllJoyn products in the development pipeline, and the few already on the market, won’t be dead-on-arrival. (To date only three products, all lighting devices from the company LIFX, are listed on the AllSeen Alliance website as being certified.) The second benefit is an industry inside move to soothe the anxieties of AllSeen members who worry that they’re being abandoned. This factor is likely of greatest concern to Qualcomm, who was the ringleader in enticing them to join the AllSeen Alliance in the first place, but it also helps the other major OCF members appear to be playing nicely in the sandbox rather than kicking sand in the others’ faces. If more AllJoyn products had already been in the market, this also would have helped soothe homeowners’ anxieties, but at this stage, most homeowners are not even aware of the existence of AllJoyn or IoTivity, much less have they committed to either one.

The AllSeen Alliance and the AllJoyn framework are not dead, at least not yet. Because the rights to AllJoyn are now under the auspices of the Linux Foundation, no company (not even Qualcomm) is in a position to bop it over the head for a quick end à la Monty Python. Instead, the AllSeen Alliance is more likely to wither away slowly as members decline to renew their expiring membership payments over the next year or two.

What About Apple and Google?
Besides AllJoyn and IoTivity, there are other significant IoT middleware frameworks for the smart home, most notably Apple’s HomeKit, as well as Google Weave and Nest Weave.

Apple wants to be master of its own sandbox, and created its own authentication technology for HomeKit including a mandate for Apple-approved coprocessor chips in HomeKit devices. The authentication process likely makes a HomeKit plug-in for IoTivity infeasible.

Somewhat confusingly, Alphabet Inc.’s Google and Nest Labs both have IoT protocols named Weave. Nest Lab’s Weave is proprietary, initially designed for Nest’s own devices to communicate directly with one another, but expanded through the Works With Nest program primarily to enable products from other manufacturers to interact with Nest products. Not a likely candidate for the OCF to pursue for a plug-in to IoTivity, at least not in the near term. (The Thread protocol developed by Nest operates at the network layer, more akin to ZigBee and Z-Wave than to the IoT application layer protocols at hand.)

Google Weave, on the other hand, is an API framework to enable communications and interoperability between smart home devices, Android phones and tablets, and cloud services. Originally developed for use with smart home devices running Google’s small footprint Brillo operating system, Weave will also be built into Android, but it is platform and OS agnostic. We believe that IoTivity’s plug-in architecture could conceivably support the Google Weave protocol, thus expanding the interoperability of IoTivity even further.

In our meeting with Michael Richmond, we asked if the OCF intended to develop a Google Weave plug-in. He replied that no one had previously asked that, but he thought it was “a great idea.” We’ll see if it comes to fruition.

View the 2017 IoT & Embedded Technology Research Outline to learn more.