Orange Cone

I was recently reading Fred Wilson's thoughts on user generated devices:

Yes, the web has brought this power of the user to the forefront of our society, enough to make us the person of the year. That's cool.

But what is cooler is that this is part of a larger revolution in information technology that started back in the early 90s with Linux. It's the open source movement and it's about opening up technology so that anyone and everyone can contribute to the collective good.

And I believe its time for this revolution in information technology to move into the hardware space. It's time for user generated devices.

I think this is right on: as the barriers to entry lower and standards develop, there is a natural democratization of a medium. In the 1970s it was video production, in the 1990s it was the Web, in the 2010s it'll be hardware (well, I hope, anyway ;-). This blog post reminded me of a conversation I had with Rafi Haladjian (of Violet) as part of the research for my next book. We were talking about Violet's Nabaztag and its relationship to other devices, and we agreed that passing everything through the interface of a general-purpose computer is likely to be short-lived. In the long-term, devices will communicate to each other and to do that, they need an open appliance communication protocol that's easy to use, even if it's not perfect. Period.

Let's revisit (a highly simplified for the purposes of this discussion) Web history: they beauty of the HTTP/HTML protocol pair was not that the were ideal, but they were:

• Good enough
• Did something immediately interesting to both creators and consumers
• Open

That's it: those were the seeds. The protocols weren't perfect from the start, but they evolved to be "perfect" in the sense that they're good enough for an incredibly broad range of uses that Berners-Lee didn't think of, and shouldn't have had to. (it should be noted that other standards had these qualities and were not so successful, so these are not sufficient for success, but they may be necessary)

In contrast, phone companies do not believe in opening their services, try to predict everything that can possibly be done, and lock it down. Their closed-system creation may have prevented the use of wireless phone standards as platforms for anything but voice and SMS.

In the appliance communication world, no one protocol has dominated except the hated X10, which suffers from a combination of low bitrate and crappy performance. Protocols like AMX, Crestron aren't really open because they're owned by competing corporations and, as such, suffer from the problems of all such systems: even if they're not intentionally crippled by their authors, there's little incentive to include anything other than what's going to satisfy the company's short-term goals. From a programmer-as-user perspective, none of them provide a particularly good user experience.

Until there's a good-enough (not perfect: never forget the debacle of X.500!) appliance communication protocol, there's going to be no easy way for Fred's user generated devices to talk.

I'm not a protocol designer. I'm sure that people have been thinking about this for a long time, but I bet all the thought has been behind closed doors and not in a public appliance design forum and framework. That said, my vision is of a household full of devices that

• speak to each other over TCP/IP
  
• are explicitly transport-layer agnostic, so any TCP/IP transport works, whether it's Powerline Ethernet, Wifi Ethernet, Bluetooth, GSM, Lonworks or tachyon telepathy
  
• use a Zeroconf address assignment and service discovery
  

In the most basic implementation, for example, a Powerline time broadcast system allows every device to be time synchronized, so you don't have to reset all the clocks after a power outage. More sophisticated systems can advertise themselves as displays, inputs or outputs. To use the tired coffee maker example: your coffee maker thus no longer has to include its own scheduling device; your alarm clock can schedule all necessary tasks, find your coffee maker as an output device with a standard set of services, and just tell it when to start percolating at the same time that it tells your Wifi rabbit to start caching its the news and traffic MP3s. Your pressure-sensitive carpet can just broadcast "turn on 1/10 power" to all lights in its vicinity, which turn on as you walk to the bathroom in the middle of the night, they light your way. If you have no such lights, they don't light.

The key, I think, is to stop thinking of all of these things as either giant HVAC control system protocols, automation protocols or media control protocols. The world of everyday appliances is much broader and the functions are much more varied. A house is not a factory, an office building or a TV studio. There's a huge potential here, a huge set of possibilities that's not about "automating" but about "activating" and "augmenting" everyday objects. The communications standards used that need to acknowledge that.

Thoughts on other protocols

• DMX is open, but it's also 20 years old, tuned to work with theater lighting, based on an even-older hardwired serial protocol, and unidirectional.
• HP's JetSend was an early attempt, and had many interesting features (a basic version could run with only 60K of memory, or something), but it's now been eclipsed not just by networking technology, but by the vastly greater capabilities of devices (i.e. we don't really need most things to run in 60K of memory anymore). We need something better, smarter, open (JetSend is covered by a patent, which is no way to create interest in your protocol--serves HP right that no one adopted it, and they themselves abandoned it).
• BACnet is another building automation protocol, but it seems to be mired in the needs of giant building automation, and was initially defined nearly 20 years ago, which makes it about the equivalent of X10 in terms of its programmer- and consumer-friendliness. Appliances geared to individuals need something newer and more extensible.
• What do people think of KNX? It's one of these standards that requires membership to use commercially, which I think is a terrible idea and market stifling in the name of arbitrary bureaucratic control, but it has many of the features that I mention above. If all that membership carries with it is "certification" by some arbitrary standards body, while the protocol is open and documented, then maybe it should just be used and the certification ignored?