Untangling The Politics of APIs
Kin Lane coined the phrase “The Politics of APIs,” referring to all of the issues and decisions made around designing, developing, distributing and consuming APIs. These are things like Terms of Service/licensing, service level agreements and branding. Naturally, there are a lot of intersections with your API products (technological and business) and these politics, and they often are strongly related.
The key conflict in APIs stems less from APIs themselves than from the nature of structured information and the presumed “openness” of the web. One of the advocates for the open web might argue like so:
The web is an open standard.
REST APIs are based on the web and operate over open standards.
Therefore, all APIs ought to be open.
An alternate version of this argument replaces open standard with public. This same confusion reappears in free software, where open is conflated with free. We see it again, although in a different form, when we confront advertising or paywalls on the internet, confronting the ethics of using ad blockers and other technological means of getting to a person’s personal understanding of free, public, or open.
Chuck Freedman at Intel Mashery has a good post about these assumptions that people make in regards to APIs, and it often comes down to an accepted definition of terms.
Traditional politics, of course, run on local, national and global levels, working together and against each other. You have competing factions, competing constituencies; disagreements about tradeoffs, focus on domestic and foreign policy. The world of APIs also have these.
When we speak of an open API, in the open web sense, we’re speaking on a global level. Surely we can agree that everyone ought to have access to knowledge and the internet in general, and that most of the web technologies out there were built to facilitate this in an inexpensive (if not free) and open way that does not present many barriers to entry. Because these are published standards, my browser, your browser, can all work to more or less get the same content online. Perhaps we’re talking about truly legally public data: census reports, government statistics.
It’s important, though, not to conflate the freedom of information with the cost of delivering it. Like the UN, some sort of system must exist to broker and manage the delivery and transfer of an open API.
This perspective posits no copyrights on API definition (in some cases, a commons), interoperability, and API-ifying the web through scraping (although some of these are exclusive to each other). You may even be able to draw some parallels to libertarianism.
At the national level, we have a hybrid API: it’s open to register for access to, but may closed by way of a terms of service, or other tiers of service. In many cases the provider and the press around it may still call this an open API.
Things start to get contentious here for the globalists. You let me sign up for free, but I don’t get everything? You dictate what I can and can’t do with it? Some developers (and companies) stop here. Others understand that politics are a series of negotiations and competing interests between company and technology, company to developer, even technology to technology.
You’ll see a mix of global standards (they’re often still built with REST principles), but they’re increasingly self-concerned. Rightfully.
Moving local we get much more specialized. We have APIs designed to support specific constituencies— they’re more likely to be Partner or Private APIs. Very rarely would they be confused with open APIs.
These are highly regulated, set up with very specific business objectives, and are less likely to be following global standards. Since business is driving, developer experience isn’t an essential feature: the essential features are the products and behaviors within, and most businesses aren’t concerned with ease of entry (which is not to say that many aren’t; there are good examples).
You Can’t Keep Money Out Of Politics
Now that we’ve set up a framework for understanding The Politics of APIs, we can set the metaphor wild.
The first place this breaks down is where the money is spent: overwhelmingly organizations are likely spending their technology dollars on the local level, where they get the greatest short term returns. The global API space is for thought leadership, universities, and a lot of hand waving that this “isn’t the way it was supposed to be!” I kid.
But just because this dynamic shifts doesn’t mean the results are any different: business interests control the conversation. When we look at the Open API through this lens, and back through history, it makes sense:
If businesses could only operate under the global open standards, the internet wouldn’t have the rich interactive experiences, payment models, and other innovations we have today. They simply would have walked away from the table. Some would argue this would have been a better internet. We can’t turn back time.
Like government, business has a role in shaping the global standards based on their needs. Businesses large and small contribute to open source standards, protocols, frameworks and RFPs for the global community. The benefits to the Open Web are numerous, despite the tensions arising from their inception.
Furthermore, if a business could only acceptably release an API that was open in this sense, without terms attached, they would also choose not to participate. Want to be able to build software on top of your bank? No thanks. Software that participates in a multi-billion dollar advertising exchange? Pretty sure there will be terms attached to that.
A Living Document
And like politics and government, APIs and API Terms are living documents. They change based on the changing fabric of their constituencies and markers. Global concerns compete and work with increasingly local ones to react and project where we want our industry and companies to go. Amendments are crucial.
Of course, at a global level, we don’t want an API change to break applications. We don’t want a terms change to break the relationship between an application and its API. But these things happen, and as politicians of APIs— as constituents of APIs— it is incumbent on us to deal with change, to legislate it, and to peacefully demonstrate against it. We have a responsibility to participate in the conversation at levels of discourse.
I’ve glossed over some other important details here that are also open to discussion, many of which are being covered within the Big Boulder Initiative’s work on a social data code of ethics, which can generally be applied to all data interchange. These are the rights of individuals, of API consumers, providers, and everything in between.
We’ll be discussing some of these issues at the API Strategy and Practice Conference, in Chicago on September 24th, 25th, and 26th, 2014. In the meantime, definitely join the Big Boulder Initiative or the conference!