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 (getgro.com) 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.