Politics of APIs

In preparation for a fireside chat with Tyler Singletary at API Strategy & Practice next week I’m reviewing many of what I consider the political API building blocks, and reading some of my past stories to refresh my thoughts on the most pressing topics in the space.

The technical building blocks of APIs are pretty clear at this point, and the business of APIs has been being hammered out over the last five or so years, by API infrastructure providers like 3Scale, but the politics of APIs are an aspect of the API economy we are going to see become more and more of a hot topic as the space continues its growth.

There are a handful of building blocks that are clearly driving how APIs are used (or not used):


These building blocks are the acting as the control valve for API ecosystems, setting the tone for how much access, control and influence both developers and end-users wil have when it comes to API operations.

There are other elements that will affect an API, and its community, like the amount of transparency a provider embraces, and externally from laws and regulation from the government, but these seven building blocks will have the biggest impact on what is possible when integrating with an API. 

The interesting thing about the politics of APIs is the overlap with the business and tech of APis. There are political building blocks that are more technical:

  • oAuth
  • Rate Limits
  • Monitoring
  • Stability
  • Error Codes

Then there are building blocks that have more to do with business, than the tech, but go along way in influencing the politics of an API:

  • Self-Service
  • Communication
  • Support
  • Roadmap
  • Communication
  • Changelog
  • Budget
  • Revenue-Share

These are all related to busines operations but will all play important role in the internal and external politics of API operations. While every API building block contributes to overall politics in some way there are a small group that I think truly overlap the tech, business and politics of APIs:

  • Github
  • Consistency
  • Security

This is why Github plays such an important role in API operations. It isn't just about code anymore, it is about the operations, reaching and supporting customers, and defining the licensing around API operations--all critical elements vital to achieving a political balance that necessary for a thriving API community.

As with the business of APIs, it will take us years to figure out all the finer points of the politics surrounding APIs, and with each new business sector that APis evolve into, we will find new struggles. Some of the issues we've seen emerge between API providers and consumers in ecosystems like Twitter, security challenges like Snpachat, and legal battles like Oracle vs. Google are just the tip of the iceberg.  

We need to have more tools, services, and open resources to help API providers and consumers navigate terms of service, as well as more open dicusssions around content, data and even API interface licensing. This is why we do API Strategy & Practice--to have open conversations between API leaders, and discuss the biggest challenges we face in the space.

I'm stoked to have Tyler come to Amsterdam and continue conversations with me on the main stage, around the politics of APIs. Like me, Tyler is extremeley passionate about the legal and political challenges we face, but even though we don't always see eye to eye, I thoroughly enjoy our exchanges because of his passion and understanding of the space. Tyler has some pretty important ideas like robots.json, that we we need to explore, and some serious experience in the space from running Klout, that we can all learn from.

As always let me know if there are any issues you'd like to see me cover from the politics of APIs, it is why I started API Voice, and I am happy to even bring it up on stage as we discuss the politics of APIs in Amsterdam next week at #APIStrat.