They use our stuff. Why not our values too?

At this point in history, arguments for using Linux, FOSS (free and open-source software) and the Internet make themselves. Yet the virtues behind those things—freedom, openness, compatibility, interoperability, substitutability—still tend to be ignored by commercial builders of new stuff.

For example, US health care, like pretty much every business category, is full of Linux and FOSS, and is to some degree connected on the Net. Yet, it remains a vast feudal system of suppliers that nearly all work to lock doctors, hospitals and labs into dependency on closed, proprietary, incompatible, non-interoperable and non-substitutable systems. I've witnessed these up close as a patient. In one case, diagnostic scans by one machine and software system couldn't be read by computers with software designed to read the output of a different company's scans. In another case, records kept by one specialty failed to inform another specialty in the same hospital. The first one gave me a case of pancreatitis, and the second one gave my mother a fatal stroke.

We are seeing the same thing start to happen already with the Internet of Things (IoT), about which Bruce Sterling has written a brilliant essay titled The Epic Struggle of The Internet of Things. "The first thing to understand about the 'Internet of Things'", he says, "is that it's not about Things on the Internet. It's a code term that powerful stakeholders have settled on for their own purposes. They like the slogan 'Internet of Things' because it sounds peaceable and progressive. It disguises the epic struggle over power, money and influence that is about to ensue. There is genuine Internet technology involved in the 'Internet of Things'. However, the legacy Internet of yesterday is a shrinking part of what is at stake now."

It's actually worse than that:

An Internet of Things is not a consumer society. It's a materialized network society. It's like a Google or Facebook writ large on the landscape.

Google and Facebook don't have "users" or "customers". Instead, they have participants under machine surveillance, whose activities are algorithmically combined within Big Data silos. They don't need the reader to be the hero. He's not some rational, autonomous, economic actor who decides to encourage the Internet of Things with his purchasing dollars. They're much better off when those decisions are not his to make.

The reader may be allowed to choose the casing of his smartphone and the brand of his vacuum cleaner, but the digital relation between the two of them is not his decision. He still has a role of sorts, but it's much like the role he has within Google and Facebook. He gets fantastic services free of charge, and he responds mostly with dropdown menus and check boxes, while generating data whose uses and values are invisible to him.

The reader didn't build the phone or the vacuum cleaner. He can't repair or modify them. He doesn't understand their technical workings, and when the two of them interact (by various adroit forms of wireless communication), he's not in charge of that, or of where the data goes....

The reader is not a "customer" of Facebook because he never paid for Facebook. Facebook's genuine customers are the marketers—those who pay Facebook for the hard labour of surveilling the billion people on Facebook. Facebook is one of the "Big Five" of Facebook, Amazon, Google, Microsoft and Apple....

The Big Five are the genuine heroes of the Internet of Things. The epic drama of the Internet of Things is really their story. It's not a popular uprising—except in the sense that the Big Five are really, really, really "popular"—because billions of people are willingly involved in their systems. The Internet of Things is basically a recognition by other power-players that the methods of the Big Five have won, and that they should be emulated.

The Big Five are smart, profitable, capable and colossal. They are as entirely free of political constraint as the railroads or Standard Oil were in their own heyday....

Phil Windley calls this The Compuserve of Things, and says:

On the Net today we face a choice between freedom and captivity, independence and dependence. How we build the Internet of Things has far-reaching consequences for the humans who will use—or be used by—it. Will we push forward, connecting things using forests of silos that are reminiscent the online services of the 1980s, or will we learn the lessons of the Internet and build a true Internet of Things?

Well, it depends on who "we" are. If we're geeks like most Linux Journal readers, we're already doing our part, laboring away on free and open-source stuff, and using as much free and open stuff as we can. But we're not the ones running the companies building closed and silo'd systems, including proprietary networks of things. And those folks aren't getting the lessons we've been teaching for decades. Why is that?

One dividing line is between standards and platforms built on them. This is also the line between infrastructure and commerce in the "layers of time" graphic from The Long Now Foundation—see Figure 1.

Figure 1. Layers of Time (from The Long Now Foundation)

FOSS building materials are all at the Infrastructure layer. So are the standards that create the Net and the Web: TCP/IP, HTTP and the rest. These and countless thousands (millions?) of standards and code bases support boundless freedom and generativity for everything that's built on them and with them, up at the Commerce and Fashion-Art levels.

But all the Big Five, while founded on those standards, and packed with FOSS code, need to compete at the commerce level. This tends to subordinate freedom, interop, generativity and the rest—except within their own feudal empires. There they can do a pretty good job.

For example, most of the big platforms come with SDKs (software development kits), APIs (application programming interfaces) and other means for encouraging, producing and supporting lots of code—and dependencies. This is why there are more than a billion apps each on iOS and Android.

But platforms can also change fast and put dependent developers and users at their mercy, as many discovered when Twitter pulled the rug out from under them in 2012 by changing its API. This was a huge interop fail for many code bases, some of which died.

Infrastructural standards and code bases (such as Linux and Apache) come up from lowest level—Nature—and bubble up through their cultures and governance norms. None of those norms arise from government policies, in spite of what the Governance layer suggests in that graphic. As David Clark famously put it to (and for) the IETF in 1992, "We reject: kings, presidents and voting. We believe in: rough consensus and running code" (Lessig, Code 2.0, p. 4: http://www.codev2.cc/download+remix/Lessig-Codev2.pdf).

Geeks working down in the lower geology layers tend to be as oblivious to what happens at the Commerce and Fashion layers as the core of the Earth is to civilization. Some of us have heard Linus say "I do kernel space". "I don't do user space". That's because Linux developers make a sharp distinction between those two spaces, by name. The deep nature of Linux is in its kernel, whose job (as working infrastructure) is to support everything above it without prejudice. In other words, it tries to be as neutral as possible.

But up at the Commerce and Fashion-Art levels, where most people acquire goods and live with them, few are concerned that a billion+ iOS apps run only on Apple hardware, or that a billion+ Android apps run on hardware from makers required to privilege Google's apps first. Or that the walls of those feudal empires block views toward negative externalities, one of which is restricted (or absent) inter-empire interoperability. As a result we have a marketplace where the benefits of freedom and openness—taught by the Net, the Web, open standards, open code and open hardware—aren't seen, because their first causes are out of sight: buried down at the infrastructure layer and below.

But some geeks aren't forgetting. Cory Doctorow, for example, warns of a coming "civil war" between general-purpose and special-purpose computing. The white-box PC, for example, is general-purpose. Meanwhile, we still have no equivalent with smartphones and tablets. Instead we have closed and locked things that foreclose on many freedoms.

The Net and the Web were both built on software and hardware that leveraged standard, open and general-purpose equipment, protocols and code bases. Smartphones and tablets take advantage of those things, but limit what people can do with them. Apps are available only in stores, which are closed and private. Apps themselves also tend to be silo'd. They may operate on your phone, but don't easily interoperate with each other. Try gathering data from all your fitness and health apps into a place of your own. Even if you can, such as with DigiFit, it's in yet another company's silo.

Research on the questions raised by these issues is remarkably thin. Toward relieving that, Urs Gasser and John Palfrey, colleagues of mine at the Berkman Center, published Interop: The Promise and Perils of Highly Interconnected Systems, in 2012. In it they argue for "a nuanced and stable theory of interoperability" that can resolve issues at the four layers at which they see interoperability playing: technological, data, human and institutional.

I've been watching problems at all four layers for the past eight years through ProjectVRM, which seeks to provide individuals with tools for both independence and engagement in the commercial world. All the projects and companies on our developers list do their best to reconcile the need for interop and substitutability with commercial imperatives: attracting investment and partners, competing and so on.

Some efforts are formal and involve a number of players that compete in a cooperative framework. The Respect Network, for example, includes dozens of partner organizations committed to the Respect Trust Framework, which assures both interoperability and substitutability between service providers.

But it's an uphill battle, and has been for a long time.

As I see it (and I've been looking at this for Linux Journal since the mid-1990s), the biggest conflict for Interop is freedom vs. captivity. Developers that value freedom tend to maximize interop, while developers that value captivity tend to minimize interop. And most of what we get are compromises.

I believe the main problem is simply ignorance of consequences, which is an old problem with business. But I also believe in research. Urs recently wrote to one of the Berkman lists, asking for "the most challenging, fascinating, puzzling...interop stories, questions, problems, opportunities...that you've been thinking about recently"—toward fresh research on interop.

Let's give him some of those. Comment below (when this goes up on the Web) or write me (doc at linuxjournal dot com).