In Alienating Developers and End-Users, Are IoT Vendors Headed for a Trainwreck?

My favorite kind of article to write is the kind that connects stories that upon first glance appear to have nothing in common. But then, after further contemplation, you realize there is a connection because, in those stories, you can see the invisible forces of the tech industry's gravity at play as they drive commoditization, force bitter pills to be swallowed, and allow us to bear witness to  history as it repeats itself (sometimes, in not-so-positive ways). Maybe we're just gluttons for punishment.

It's only Wednesday. But this week, I am already struck by three stories; two of which speak to the direction that developer ecosystems eventually head once developers and their end users get fed up with certain inconveniences. These tales come from the underbelly of the industry to which, in the grand scheme of things, very little attention is paid. But it's where the stuff that really matters often happens.

The first of these stories has to do with Mozilla's adoption of the same WebExtension API architecture in Firefox as the one that developers can use to build add-ons for Google Chrome (which, incidentally, is also supported by Opera). In other words, Firefox will essentially be add-on/extension-compatible with Chrome (and Opera).

According to Mozilla's developer blog, "WebExtensions is the new API for building add-ons in Firefox. It seeks to unify the extension APIs and architecture with those of other browsers in the name of interoperability and modern architecture." Technically, this isn't news. To the consternation of some devotees of Firefox's previous add-on architecture (XUL and XPCOM), Mozilla announced its intentions back in August 2015. 

Browsers having different add-on architectures is reminiscent of a lot of incompatibilities in tech history -- incompatibilities that were both difficult and costly for developers, often producing inconsistent user experiences for end users. BIOS and bus incompatibilities. Microprocessor incompatibilities. Desktop and network operating system compatibilities. Java Virtual Machine incompatibilities. Browser incompatibilities. The list goes on.

Who among us, for example, doesn't remember all the conditional branching that was necessary for most Web sites to look the same in Internet Explorer and Netscape Navigator? It was enough to drive Web site operators crazy and, in many cases, end-users even crazier. It's taken me 25 years. But I've come to realize that neither greed nor religious zealotry (of the technical sort) are matches for gravity. Sooner or later, in the name of reduced developer cost and better user experiences, compatibility eventually triumphs. For example, native mobile apps have already yielded ground to Web apps that run unchanged across all platforms and it's only a matter of time before industry gravity finishes them off altogether. 

Unfortunately, before there can be winners like WebExtensions, history proves that we can't check our egos at the door in the name of developer and end-user efficacy. This is presumably to gain some market advantage or a penny royalty on some otherwise unencumbered specification. Such competition is often cited as a driver of sorely needed innovation. Developers and downstream end-users be damned. When I look back on the technology wars that I've reported on over the last 25 years, the crazy thing is that the majority of these so-called innvoations ended up not mattering in the long run. When I think about all the money and end-user headaches that must have been wasted on the bloodshed between VHS and Betamax, on the myriad DVD format wars, or GSM and CDMA  -- all at the expense of developers and consumers -- it's pretty shocking. What a waste.

Yet, history seems destined to repeat itself. Is it greed? Stubbornness? Or just new generations of founders and tech execs who missed-out on their history lessons?

I was reminded of this by the second of the three stories -- this one about Miracle-Gro's (Scotts) Connected Yard announcement at SxSW. Described as a platform, the announcement says "Gro software is enhanced by connecting into Internet of Things hardware.  Gro's hardware partners in the 'Works with Gro' program are a hand-picked combination of sensor and water controller manufacturing partners. Their hardware feeds information into Gro software." It's statements like these where I full-stop because as I read them, they don't sound like the Internet of Things that I'm envisioning.  

A bunch of sensors feeding some central software? Hand-picked partners? It sounds more like a walled-garden (no pun intended) of things that Scotts is trying to control rather than an Internet of Things (IoT) that are openly accessible via APIs over that infinitely more programmable platform; the Internet. In fairness, there could be a developer story behind the announcement. But, neither the announcement nor the company's Web site for the initiative ( contain anything inviting to developers. Likewise, the "Gro partner" that brought the annoucement to my attention --- smart watering controller maker Blossom -- appears to run a Web site that is equally void of any developer information. Repeated attempts to contact the company via email (in reply to its emails to me) were met with radio silence.  

(Editor's note: One day after this article was published, ProgrammableWeb was able to get comment from Blossom CEO and founder Manrique Brenes who said "Today, Blossom’s controllers are only accessible via the Blossom App, and access via Scotts Gro App will be available later this summer. We are looking at a localized API – which will be focused on cloud based services connectivity – but not in the in the near future.")

The truth is that the majority of IoT announcements that come my way seem to formulaically omit the notion of a democratized Internet of Things whereby everything has APIs that are reachable by developers, their apps, and ultimately end users, over a standard network protocol like HTTP (the Web). In the big picture, consumer companies appear to be in a race to repeat the same colossal mistakes that the technology industry made over a period of three decades; that is, as a part of an attempted land-grab, to build a bunch of non-interoperable islands of technology. It's the antithesis of the Internet and in particular, of the Web as a programmable platform (what ProgrammableWeb is all about!).

Our so-called smart homes are going to end up being the dumbest homes on the block because of the havoc these walled-gardens are going to wreak on end-users and the developers who are desperate to serve them. Oh, wait. You wanted a unified view of that light bulb and your garage door opener so that the bulb activates when the garage door opens? You should have thought ahead before buying those two so-called smart things, each of which belong to different "Internets." 

Think I'm kidding? Try using your Kindle to view that Amazon Prime content on your big screen over a Google Chromecast dongle. Or that Google Play content on your big screen over that Amazon FireStick. A big thank you to whoever put two HDMI ports on the back of my big screen TV just so I can buy more hardware from both Amazon and Google than I should really need. If you've bumped into that problem, then you may have some idea of how much worse it's going to get with the IoT.

At some point, there will be thousands of proprietary IoT "platforms," none of which can talk to the others. Some will involve stand alone products like a door lock. Others will be exclusive "approved-partner" ecosystems. There will be lots of networks of things but no true Internet of Things.

This brings me to the third story; an announcement from the Eclipse Foundation that to me, represents one of several shreds of hope for the IoT. By itself, it's not a solution to the walled-garden problem. But, it's similar to Mozilla's concession to industry gravity and proof that when they can, developers will find commoditizing ways to neutralize the inherent if not purposeful incompatibility between connected things. This one had to do with a technology called Edje. The general idea of Edje is to produce a hardware abstraction layer (HAL) that works across dissimilar hardware platforms in such a way that a call to the same Java API will produce the same outcome on each of those platforms.

For example, to access an LED or serial port, developers wouldn't need to know anything about a thing's underlying hardware specifics. The HAL would essentially map the underlying hardware drivers into standard Java APIs for accessing LED, serial ports, and the like. Letting my imagination run wild for a minute, I'm picturing a cloud-based proxy that polls a thing's Java API to read one of its GPIOs, transforming the results into data that's developer-accessible via an HTTP-based API (RESTful, or not).

Such a cloud-based proxy is one of the prevailing architectural models for addressing "things" that are too underpowered to be stand-alone Web servers (some sort of Web serving functionality is necessary to serve an HTTP-based API onto a network). If successful, Edje could introduce a welcome degree of hardware agnosticism to the Internet of Things. But it's really just one tiny step for Internet of Thing-kind.

It's like watching the various generations of Star Trek. Different decades. Different producers. Different actors. But fundamentally, it's the same predictable script. Only in this case, it's not very entertaining. 

Be sure to read the next Internet of Things article: Daily API RoundUp: Agora, Tucia, Planet OS, Plus mnubo, Shapeways, TaskCluster SDKs


Comments (4)

John-Michael Scott

I don't want to over simplify your entire argument but standards are often in a race to catch up because - perhaps unsurprisingly - it takes an extraordinary act of will for the entire world to agree on a protocol. As a result - entrepreneurs and business leaders create your walled gardens to move the ball forward. Personally - I don't have a horse in this race - being not a standard setter - but I've been in the same industry as you for equally long. For all your frustration - it's simply a fact that standards can't keep up with he pace of change - and as a result proprietary solutions exist first. Just some things to think about. John-Michael Scott -




Thanks for the comment @John-Michael.  In the case of IoT, I don't see missing standards as a barrier to developer accessibility or even some degree of interoperability (thinking about the light bulb-garage-door-opener example, let's call that workflow for now). I read "Connected Yard" and I see "Scotts Miracle Gro Walled-Yard" because it sounds like Scotts is building a closed system that at the very least will keep developers and/or competitors from participating in ways that could either benefit end-users or marginalize Scotts' role.  Scotts and its partners like Blossom may see only one possible way of mashing-up a worfkflow that involves a smart water-controller. But there would no doubt be developers or competitors who would like the flexibility to include that so-called connected yard and its components into workflows that Scotts may not have envisioned.  Maybe for example, I'd like the doggie door to automatically lock when the sprinklers are running in the back yard.  I may be speaking out of school here, but today's relatively standard API technologies can be applied to keep most of these ecosystems open. 

Again though, thank you very much for commenting.

Rick Bullotta

David, we solved many of these problems when I founded ThingWorx in 2009. We provided a unifying layer for hardware, data, event, and service abstraction, all accessible via a consistent API over HTTP or websockets.  The reality is that there will be many silos and "walled gardens" to contend with, at all levels of the iot stack, and we chose to face that reality and solve it for customers rather than naively assume any type of industry driven unification. It won't happen. We then went well beyond the original platform scope to include app and business logic composition, user experience and mobile app development tools, analytics, and more.  Embracing the complexity is what enabled ThingWorx to become the leading iot platform.  


Thanks for commenting @Rick. One thing I left out of the discussion is that the practice of exclusion isn't necessarily based on a proprietary protocol (although it can be). If I were to purposefully build an exlusive ecosystem, I might choose to use/invent a proprietary protocol just to raise the barriers to unauthorized access (HTTP APIs are terribly easy to reverse engineer). But exclusion can also be a function of authentication and access rights at the API management level. It could very well be an HTTP API, but I could only choose to allow access to certain developers. I'm guessing ThingWorx must offer that same capability as it is pretty much table stakes when it comes to APIs. It is true that the likelihood of some sort of proprietary or non-HTTP API seems to go up with the IoT as I have observed "things" with all sorts of weird-fangled communications mechanisms. I don't know that there necessarily needs to be agreement on standards above and beyond architectural styles and commonly accepted protocols when it comes to the IoT (though I am pretty peeved about having to equip my screens with both FireStick and ChromeCast dongles).  It's just that when it comes to things, I believe companies like Blossom are making a big mistake by not starting with broader developer access in such a way that the so-called connected yard can be driven by unhibited innovation vs. one or two vendor agendas.

Thanks again for commenting @Rick and be sure to keep us posted on your API-related news.