EOF

Before the Internet there were just nets, and they didn't get along. Each was a country or a city-state of its own, with hard boundaries that could not be crossed—or could be crossed only if the owners of the networks created closed and silo'd ways of doing it. Every company's LAN (Local Area Network), for example, had its own way of working, with its own internal e-mail system and methods for transferring files. The same went for “on-line services”, such as AOL and Compuserve. Those too were closed and separate worlds of their own. You couldn't send e-mails from one to the other. Many vendors of network “solutions” considered lack of interoperability a feature and not a bug.

The Internet didn't blow existing networks away so much as it simply subordinated them to higher principles that were good for everybody and everything: 1) making every node an end point and 2) getting all the member networks to agree about how to pass data from any end to any other end. Those agreements are protocols, which are simply manners, like nods or handshakes.

That all networks agreed on the same protocols for moving data between end points, with no guards or tolls at border crossings, was as unlikely as instant world peace. Yet, that's exactly what it was—and still is. True, there are countries that censor or restrict the Net and companies that charge us for access to it, but the Net itself is as open and ownerless as gravity and light.

The main effect of the Net in our midst is elimination of distance. This is new to human experience, but it's already as ordinary, embedded and essential to civilization and its future as were language, fire and the wheel when each of those came along—and just as easy to take for granted. So easy, in fact, that we've forgotten why the Net was such a big success in the first place.

This amnesia is made clear by pretty much everything happening in the ill-named “Internet of Things” (aka IoT) today. Rather than a true Internet of Things—namely, the Internet we already have—we have what Phil Windley calls “The Compuserve of Things” (www.windley.com/archives/2014/04/the_compuserve_of_things.shtml). In other words, silos of things. In his summary of that essay, Phil writes:

Right now the way to bet is on the forest of silos. Every gizmo- and system-maker either has its own silo for things or one inside a farm run by Google, Apple, Facebook or some other large operator. For a clear and depressing look at how this is already ending up badly, read Bruce Sterling's The Epic Struggle of the Internet of Things or Cory Doctorow's summary of it (boingboing.net/2014/09/13/bruce-sterlings-the-epic-s.html).

For a clear and encouraging look at where this should be going, read Phil Windley (www.windley.com). He not only writes eloquently about the IoT (www.windley.com/tags/iot.shtml), but he has been working on GPL'd open-source code for things and how they relate (https://github.com/kre/Kinetic-Rules-Engine). To me, Phil is the Linus of IoT—or will be if people jump in and help out with the code. Whether Phil fills that role or not, nobody has more useful or insightful things to say about IoT. That's why I decided to interview him here.

DS: To me, your most important insight is that things don't need onboard intelligence to be on the Net. Every thing can have what you call a pico—a persistent compute object (www.windley.com/archives/2015/05/picos_persistent_compute_objects.shtml). Earlier you called these “clouds” of their own. What led you to make this leap, which to my knowledge, nobody else has done?

PW: We've made a mistake associating the Internet of Things too closely with “things”. To be functional, the IoT will have to operate on a model of the world that doesn't just connect things, but people, places, organizations and even concepts. Everything will have to be on-line. I've been heavily influenced on this by David Gelernter's book Mirror Worlds (https://en.wikipedia.org/wiki/Mirror_Worlds). Even though it was written in 1993, pre-Web, it still reads well.

For example, I like to think about what it would take to put every pothole on the Internet of Things. Why? Imagine driving onto your street and seeing a new pothole. Your heads-up display could alert you to its presence, maybe even automatically help your car avoid it. You'd see infographics that tell you when it appeared, who reported it to the city, that city inspectors looked at it last Thursday, and when they were planning to fix it. A city engineer might see a history of potholes on your street, how they related to other infrastructure like water and sewer lines, and so on. The road crew that comes to fix it would see something else entirely.

DS: Interesting. So, if I understand it right, somebody—anybody—could create the first pico for a pothole.

PW: Right. It could be a driver, a resident, a person on a truck from the city, somebody on a crew doing electrical work....

DS: But once the pico is created, and has an OS and storage cloud of its own, it can retain information and interact with different parties. Is that right?

PW: Right.

DS: How will it work so the city engineer, the driver and the road crew see something different in a pothole's pico?

PW: Picos have relationships with other picos or services. The pico can present a different API based on the nature of the relationship. So in the case of the pothole, its pico would naturally have a relationship with the street it's part of. The homeowner and city engineer would also have a relationship with the street. The street would introduce the pothole to them, and they'd create a direct relationship. This can all happen automatically and on the fly. The attributes of those relationships would control what the driver's or engineer's pico saw when they queried the pothole.

DS: Meanwhile all the conversation and development on IoT is on things with built-in intelligence or data storage. What made you start thinking and working outside that box?

PW: Well, the world is full of things, and only some of them have intelligence. Worse, most of the intelligence being built into things is silo'd to Apple or Google/Nest or some other company—what I call the Compuserve of Things. All this thinking and development is as primitive and isolated and broken and doomed as Compuserve was. Don't get me wrong, it's all useful up to a point, just like Compuserve was. But we didn't iterate from Compuserve to the Internet, and we won't iterate from the current work on IoT to what we really need to build.

To be fully useful and meaningful, IoT should embrace all things, whether or not they have intelligence or memory onboard. Among the infinitude of things in the world are potholes.

Of course, potholes aren't computers, so you can't program them. And we're unlikely, at least for a while, to instrument them. But we could put them on the Internet of Things, as a functional entity with a pico, or something like it. The pico represents the pothole in models, manages relationships to other picos, remembers attributes, history and past interactions, and runs programs for the pothole. The pothole has an API, responds to queries, listens for events and participates as a full-fledged member of the IoT.

When you start to think of the IoT this way, you realize that there could be trillions of things, and many of them won't need a microprocessor to be part of it.

DS: You also have a kind of operating system for picos called CloudOS, and a language for programming them called KRL. How did those come about?

PW: KRL started off as a domain-specific language for Web page augmentation, and it got away from me. As KRL become more capable, with support for an entity-oriented event bus, event expressions and persistent variables, picos more or less sprung into existence. It was very much a process of discovery.

CloudOS came about one day when Ed Orcutt and I realized that KRL was finally powerful enough to build the functionality we needed for a new project instead of having to put it in the underlying pico hosting platform (KRE). This was a great feeling because it told us we were getting close to having a mature system that could be used for real IoT products.

I have a group of students working on rewriting CloudOS to incorporate the lessons we've learned over the last four years, most notably from using it, and picos, to build the Fuse-connected car system (joinfuse.com).

DS: Companies also can give anything they make or sell its own pico, along with its serial number, SKU (stock-keeping unit) or VIN (vehicle identification number). I can imagine lots of ways this can play out, but I'd rather hear where your thinking goes with it.

PW: As cheap as microprocessors are, it's still going to be a while before there's one in everything we buy. In many cases, the business model just can't support it yet. But picos are cheap and easy to create. So it's feasible to give one to every thing right now.

This lets manufacturers, retailers and almost anyone add unique functionality to products that haven't had it before. One obvious, easy-to-imagine scenario is for the product, backed with a pico, to serve as the customer service portal for the owner. The product pico has a relationship with the owner and one with the manufacturer. When there's a problem, the product itself can intermediate the customer support.

But customer support is just a start. Why doesn't my furnace order its own filters, send a text to my teenage son to install them, and then augment his allowance when he's done? Why doesn't my car schedule its own oil changes?

We've always imagined a future world where the device itself is finally smart enough to take care of itself. But we don't need to wait for a smart furnace in our home. With a cloud-based doppelganger in the form of a pico, the furnace could do it today.

The best part is that the architecture puts all of this firmly in the control of the owner, not some cloud owned by the manufacturer. Picos use a hosting model not unlike how Web pages work, so it's easy to move them from the manufacturer's hosting site to your own with no loss of functionality.

DS: How do you see this playing out in the marketplace?

PW: Socially, so to speak. In a blog post on social things, I describe how social things get along with other social things (www.windley.com/archives/2015/07/social_things_trustworthy_spaces_and_the_internet_of_things.shtml). And, just as important, how they can protect themselves from things that don't play well in the sandbox.

Imagine a world where things are connected, but unsociable. Every interaction would have to be explicitly scripted or it wouldn't happen. Oh wait, you don't have to imagine it. That's the current model for the IoT, and it won't scale.

On the other hand, if the things we buy are social, not just able to connect to their maker, but also have relationships with other things, people, places and concepts, they can play a variety of roles. As a small example of this, suppose I buy an electric car. The car needs to negotiate charging times with the air conditioner, the home entertainment system and so on. The charging time might change every day. How does the car find these other devices? How does it know which of them to trust? How do they know if they can trust the car? What happens if I want to charge my car at my friend's house?

The number of interaction scenarios for connected devices grows exponentially. We can't script that. It has to come into being on its own. A collection of manufacturer-provided APIs doesn't cut it. Social things act as independent agents to accomplish goals on behalf of their owner.

DS: So, while they might be social things, they're still your things. They work for you—not for somebody else.

PW: Right. They know their place in the world, so to speak. That's an important component of sociality.

DS: The IoT, whatever it turns out to be, comes at an interesting time for Linux, because Linux's main problem today is its success. In its first decade, Linux was a cause. In its second decade, it won. Now it's everywhere. I'd like to see the same thing happen with the IoT, based on somebody's code—yours, or anybody's. What can we do to energize development around the early code we already have, and what additional code bases are we going to need?

PW: One big problem is that there are a thousand and one IoT projects. Everyone—and I'm as guilty as anyone else—just wants to work on their own, so none of us get critical mass. Commercial efforts get traction, but aren't likely to produce the true IoT we all want to live with. You've pointed out that the Internet doesn't have a business model. Neither will the IoT.

DS: And we're a long way from it.

PW: Yes. But, we can see the way forward if IoT has a cause. As you say, Linux was a cause—and still is. Here's mine: we won't get a true Internet of Things until we connect things together in ways that are decentralized, heterarchical and interoperable. These are key properties of the Internet, and they're sadly lacking in almost every so-called IoT product on the market.

Furthermore, we need an IoT architecture that is biased toward personal control of things without any intervening administrative authority (like the manufacturer, the police, or the Federal Highway Administration, to name a few). What if, in some future world, a root certificate authority revokes the identity documents I use for banking, shopping, travel and a host of other things? Or if my car stops running because Ford shuts off my account? Personal control of the connected things in our lives is fundamental for our freedom.

As a result, I believe the architectural and business model choices we make around IoT will have far-reaching consequences for the humans who will use—or be used by—it. I write about social things and build connected car systems like Fuse because I'm hoping to convince people, a few at a time, that there's an alternative to the Compuserve of Things—one that actually supports freedom.

We can push forward at building forests of silos that are reminiscent the disconnected on-line services of the 1980s, or we can learn the lessons of the Internet and build a true Internet of Things. That's our choice. And I think it's a cause worth working on.

DS: Thanks!