The opinions expressed in this article are my own and do not reflect the views of the AllSeen Alliance nor Royal Philips.

Recently a lot of talk about the consolidation of open source IoT standards has hit the media, sparked by the announcement of the Open Connectivity Foundation (OCF).

As cofounder of the AllSeen Alliance, championing the need for IoT protocol consolidation has been a passion of mine for many years.   It’s clear that enabling the “magical” use cases we all see in those sexy IoT demos and videos requires a common language that everyone can get behind. I wrote about this in 2013 in this All Things D article, Connecting Things To the Internet Does Not an Internet of Things Make.”   I emphasized the need for consolidation and alignment around a common IoT protocol at dozens of industry keynotes such as the MIT Digital Summit (2014), the Linux Foundation Collaboration Summit (2014) and at SxSW (2015). The Economist also interviewed me on this topic for their article “The Language of the Internet of Things.”

Over all these years, the goal has been clear: the sooner we can all align on a common language, the sooner we can realize this game changing IoT vision. My views on this have not changed.

The tech press has been fast and eager to conclude that this new OCF announcement consolidates the IoT landscape with a so-called merger of OIC and AllSeen. But consolidation means more than press releases. If we want to change the future, we need to be willing to roll up our sleeves and get our hands dirty in the details. That’s where I live. If your desire to understand truth starts and ends at the PR headlines, you can stop reading here.

To evaluate this announcement, it is important to rewind and understand why AllSeen Alliance was created in the first place. The AllSeen Alliance was founded on three fundamental tenants: 

1. The project must be truly open with governance based on open source meritocracy, not controlled by a few strong companies. This point was absolutely central to the formation of Alliance. Those of us who grew up in mobile were painfully familiar with what happens when one or two big companies “own the platform.”   In the case of mobile, Google Android and Apple iOS are good examples. Once these strong platforms took hold and became the de-facto mobile OS standards, power and control quickly shifted away from the other stakeholders in the space (semiconductor companies, phone manufacturers, operators, etc.) Why? Because the HLOS platform evolution basically dictates the future capabilities of phones.   And as a hardware manufacturer or chipset supplier, if you want to build differentiation for these features, you are limited to “the big boys” decisions on whether they are willing to expose the APIs to you for the features you want to enhance.   Indeed, even though Android has always been an “open source project,” everyone in the industry knows that from a governance perspective, its far from being open. It’s simply up to Google to decide what will and will not be in the next version of the OS. With Apple and Google both clearly looking to IoT as the next big frontier for their OS’, we wanted to create a market alternative for IoT companies who want to have more control of the platform.   The idea has always been to make it as easy as possible for any company to use the open source but also join the Alliance and help shape the future of the platform. Anyone in the community, no matter how big or small the company, can contribute new extensions and services to AllJoyn. As such, the community truly dictates the future of the platform.

2. The future of IoT requires more open source, less specs. Our observation was that when it came to interoperability protocols, standards were not enough. There are so many examples of very complex, 500 page standards that many companies around the world help shape. The problem with these specifications is that 50 different companies often interpret them in 50 different ways. And then, each of these companies implements the spec in a different way, based on their interpretation. UPnP is a prime example. It’s a very successful standard that is frankly ubiquitous in our homes today in almost all consumer electronics. However very rarely does anyone use it. Why? Because very rarely does one manufacturer’s UPnP device actually interoperate with another’s. Manufactures have all interpreted the same spec in different ways and have different implementations many of which are actually not so interoperable. So yes, they all “meet the spec” but no, they don’t meet the original goal and vision for UPnP.   We wanted to avoid this in IoT protocols where we imagined things will become much more complex with so many new players and verticals. Instead, we wanted to take the open source approach, more akin to Linux, Webkit, et al. This means we don’t just write a spec for others to interpret and implement. We actually provide THE IMPLEMENTATION of the protocols as source code that anyone can use, extend and contribute back to. Focusing on real implementation of code (the AllJoyn project) is core to AllSeen’s differentiation in the IoT landscape. Anyone who wants to use AllJoyn simply picks up the code. If we all build based on one implementation, interoperability should be cleaner.

3. Ensure the open source code is unencumbered from licenses that may limit its use. Many large and small IoT players around the world stated clearly that they will not use source code in their products which can lock them into something that may be problematic in the future. If, for example, one company could contribute code into the open source that later becomes a Trojan horse for asserting future claims on commercial products, that would limit the uptake of the protocol by the community. Consequently, AllSeen Alliance ensured AllJoyn was not only free and open, but it also came with a pledge by any contributor that no contributor will assert against any certified product for the certified implementation.   These details were difficult to work through but very important for the community.

For me at least, any successful consolidation of solutions should try to still address these core tenants. Otherwise, while it may appear that there are less competing standards out there, will miss the forest for the trees. Having less fragmentation is not the only problem to solve. Indeed, the industry can readily get behind the vertical players who already have an impressive footprint in the market with their proprietary protocols. This would immediately solve the problem of fragmentation. But the point is that there is a desire for a protocol standard that is not entirely controlled by one or few big players.

Very few details have been released about the OCF beyond the well-crafted press release and blogs written by savvy marketers who know how to spin inferences from minimal data. If I was a tech reporter, what I would like to understand is how OCF plans to address the three fundamental goals above.   Specifically:

1. Re: Truly open governance & open IoT community; my understanding is that OCF takes quite a different approach. The only way to certify a product for OCF requires joining OCF and you can only join OCF with permission of the Diamond Members. For me, this feels more like a closed and controlled country club than an open source community. AllSeen Alliance does not require companies to join and pay dues to certify their project or to use/contribute to the AllJoyn open source project.   Furthermore, a true merger would suggest that all of the AllSeen Alliance board companies and those companies who have actively contributed code to AllJoyn should have a say in driving OCF & likely diamond membership.

2. Re: Open Source vs. Specs, my understanding is that OCF is a standards organization not a code organization. IOTivity may be their sponsored reference code, but what is the plan to really drive implementations of the code as the go to market path? Or will there be a heavy reliance on third parties to interpret and implement OCF specs with only a subset of the spec fully implemented and released via IOTivity?

3. Re: open source policies and license concerns, I don’t really know where OCF stands.   OCF has not clarified their IP position on their specs. Will the license permissions in OCF attach to both the IoTivity open source code as well as the underlying spec? Would that mean that any company’s independent implementation of the spec could be encumbered by license terms of OCF? Simply because a given implementation has a permissive license like Apache 2.0 does not mean that the underlying spec does not carry licenses. We need to be asking if the spec can be encumbered with patent claims and possible fees. As Microsoft said in their blog, indeed there are millions (10s of millions) of AllSeen certified devices out there across many different vendors (vs. how many commercial IOTivity devices?). Open source code & understanding IP and licensing implications is critical for the successful evolution of an open IOT protocol.

The bottom line is this: the time is right for consolidation. We need to start working together. And I believe that there is a lot at stake here if we do not find a way to work together. But consolidation only makes sense if we don’t end up with yet another platform controlled by a few big players. And collaboration across the organizations must not endanger AllJoyn products with unknown and undefined licensing requirements on the core code. I would personally really love to see us work through these issues. It may take time, but the door must be open to find a solution. Otherwise OCF will be just another Oligopoly Club For now.