A few weeks ago, Twitter announced changes to their APIs. You've probably heard some of the complaints about them. The most severe changes affect Twitter clients not made by Twitter. This has had real affects. Tweetbot, for example, canceled their alpha program because of the new rules (although they claim the full product will still be available).

Nova Spivack posted ten questions for Twitter that does a good job of outlining some of the problems and questions that Twitter's new requirements pose. The requirements create significant limits in what others can do within the Twitter ecosystem. Wired has a good run down of the expected fallout.

While people will gnash their teeth over the new API requirements, Twitter is acting in a completely rational manner relative to the requirements they have to create revenue from their platform. We have become accustomed to using the API. What's more, businesses have been built on assumptions about Twitter behaving in certain ways. But as these changes show, there's no reason to expect that big companies will behave in the interest of their API users. As soon as your interest doesn't align with theirs, you're in danger of being cut off.

While the current angst is around Twitter and their actions, there's no reason to expect that Facebook, LinkedIn, Google, or any other company won't change their API policies when it suits their interest. Businesses that rely on them better do so with their eyes wide open.

Notice I didn't include Apple or Microsoft in the list of companies in the preceding paragraph. Apple and Microsoft are different beasts than those I did mention. Apple and Microsoft derive revenue from their OS's by charging for them and the popularity is, in part, due to the work of others who build upon the OS. Facebook, Twitter, Google, and others derive value from advertising and thus move their platforms to maximize that revenue. The users of their APIs don't necessarily enhance that directly and so they are less beholden to them.

Classifying Business Relationships

The relationship between clauses in sentences can be classified as paratactic or hypotactic. Consider the difference between "The sun was shining brightly. We went for a walk." and "The sun was shining brightly, so we went for a walk." In the first, the two clauses are independent thoughts. In the second, "we went for a walk" is subordinate to the first.

We can classify business relationships the same way: paratactic or hypotactic. In a paratactic business relationship, the two entities sit side-by-side as equals. One may use the other, but there are choices. There is a measure of independence Kynetx has a paratactic relationship with Office Depot. We could easily shop somewhere else. On the other hand, a number of companies—like those whose business is producing Twitter clients—have hypotactic relationships where one company is subordinate—at the mercy—of the other. Businesses on the subordinate end of a hypotactic relationship, generally classify that as a "risk."

Companies that write software have always been dependent on the APIs of operating systems, this new dependence on APIs is different:

1. Operating system APIs can't be updated or turned off as quickly or abruptly as an online API.
2. Updating operating system APIs requires the user's cooperation to install the new version. Users can usually continue to use software as long as they maintain their current API regardless of what else happens.
3. OS vendors have always been heavily dependent on some of the larger software vendors to make their platform valuable and so they avoid making wholesale changes without significant warning and consultation. (See Invisible Engines for much more on this.)

While plenty of developers have been angry over API changes in operating systems in the past, building on cloud-based APIs has made the problem much worse.

Is it bad to be in a hypotactic business relationship? Certainly Twitter's moves raise that issue. When another company's changes in API policy could to put you out of business, you're in real danger. I'm sure investors will take note of this as they contemplate future deals. Put another way, when you live in a silo, asphyxiation is a real danger.

Good API, Bad API

All of this is not to say that APIs are bad. On the contrary, I think they're wonderfully useful. The point is that businesses ought to be aware of the risk that the loss of an API poses to their business. To the degree that your business depends on an API, you are in danger of a very unpleasant surprise unless you're careful to align your interest with the API provider's.

One way to look at interest alignment is that it moves a hypotactic relationship to one that is more paratactic. Plenty of companies live in a comfortable, profitable symbiotic relationship with a larger company because their interests are aligned. For example, as far as I can tell, Gnip has a very different relationship with Twitter than many others who are using the Twitter API. Gnip is a Twitter customer who pays them money. Consequently, Twitter pays attention to them—even recommends them.

The hardest APIs to align with are those whose providers derive the majority of their revenue through advertising. Advertising forces a company like Twitter to restrict the use of it's content in the ways we've seen in order to protect the revenue stream. Apple and Microsoft, on the other hand, rely largely on platform sales for revenue and thus they see third party developers not as potential parasites siphoning off revenue, but as allies in creating a valuable platform that people are willing to pay for. It's not for nothing that Apple and Microsoft both tout the apps that run on their platform, even providing free or discounted advertising for some app developers.

Protocol to the Rescue

The problem of misaligned interests between an ad-supported platform and its developers isn't new to the online world. Early on, before the web, there was a company called AOL. AOL is still around, of course, but is shadow of it's former self. People who grew up with the web may not realize just how powerful AOL was. Being "on AOL" defined "being online" for millions of people. Businesses had to use AOL to reach and connect with potential online customers. (This situation might sound familiar; just substitute "Twitter" for "AOL" in the previous two sentences and see if it doesn't ring true.) The web ended AOL's online domination by defining protocols for interaction that were open, non-proprietary, and standardized: URLs, HTML, & HTTP.

With the advent of these protocols, businesses no longer relied on AOL to provide a conduit to their customer. They could create their own spot online and interact with customers directly—without AOL's intermediation. They become independent. People and businesses rushed onto the web because the freedom felt good. Put another way, the web's decentralized structure worked better than AOL for most applications. In the nomenclature we used above, businesses were hypotactic to AOL. Protocols allowed them to move out from under AOL and become it's equal. AOL went from a position where they were dictating terms to one where they were had to compete for attention.

Note carefully that the world wasn't changed by moral outrage like what we see directed against Twitter for having the temerity to change the terms of an agreement that was always one-sided. Rather change came by way of protocols that allowed people new freedoms they hadn't had before. As people and companies became used to the idea that they could just put up a web server without anyone's permission, the world shifted.

I think the world's ready for another shift. As I noted above, Twitter (along with Facebook) is the AOL of our time. Twitter operates centralized relationship network on top of the web. We can imagine that protocol will topple Twitter, just the latest centralized system that has exploited its position at the top of a hypotactic business model to become a dominant intermediary and charge tolls for access to it's customers.

I put together a matrix to help envision this. We can see that as single-channel communication systems (email) moved from centralized to decentralized architectures, so can multi-channel communication systems like Twitter and Facebook.

Note that app.net is another centralized relationship system. Unlike Twitter and Facebook, app.net aims to charge for using its platform. In this way it is more like Apple and Microsoft and thus aims to be a platform where it's interests are more easily aligned with those of it's users (be they developers or members). While I think it's a worthwhile venture, it won't compete with protocol-based relationship networks because it can't be flexible enough to meet all the needs that people and businesses envision for relationship networks.

Whither Relationship Protocols

So, where will this protocol-based relationship network come from? I believe that it will be event-based (naturally my preferred technology there is KRL and event-based APIs). I believe it will also require semantic data interchange and location independent API references (my preferred technology there is XDI). My preference for events and semantic data is based on a belief that the openness, loose coupling and metaprotocol capabilities that these technologies provide is critical in an effort where flexibility and adaptability are paramount.

But whether or not my technology choices pan out, I believe that protocol-based relationship networks are coming. Eventually enough of us will be cut off through—or put off by—the rules that the centralized players will inevitably impose. The Internet and the web have taught us that we gain unprecedented freedom when we use decentralized, open systems. We will undoubtedly put that knowledge to use.