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):
Legal
 |
Branding - Along with the other business assets made available via an API ecosystem, the API owners brand is also being put on the on the line. Branding Guidelines set the tone for how partners and developers can use the resources and assets made available via an API. The branding guidelines will provide a framework for attributing the API owner, how resources can be displayed and provide visual assets to support the company brand. As with terms of use and privacy policies, branding guidelines need protect the API owner but also provide developers with enough freedom to innovate. |
 |
Terms of Use / Conditions - Terms of Use provide a legal framework for developers to operate within. They set the stage for the business development relationships that will occur within an API ecosystem. TOS should protect the API owners company, assets and brand, but should also provide assurances for developers who are building businesses on top of an API. Make sure an APIs TOS pass insepection with the lawyers, but also strike a healthy balance within the ecosystem and foster innovation. |
 |
Privacy - Privacy policies protect the rights of partners, developers and platform users while also protecting the API owner from damaging activity via the API platform. Like API terms of use, privacy policies need to strike a balance and protect everyone involved, but also allow for innovation and commercial activity. |
 |
Service Level Agreement (SLA) - A service level agreements (SLA) provides a legal framework for describing what service(s) is being offered by an API provider, with details about level and quality of service, includingwarranties,disaster recovery, and steps fortermination of agreement. SLAs may vary based upon multiple levels of access to API resources, and different API user groups. |
 |
Data License - A data license defines how data resources available via an API can be used. A data license sets the expectations with API consumers regarding how they can use data, and also protects API providers and their partners intellectual property. I recommend taking a look at Open Definition for an assortment of data and content licensing. |
 |
Code License - You should make sure al yuor code samples, libraries and SDKs have a default license that helps defines how your code can be used. A license for the cdoe sets the expectations with API consumers regarding how they can use code generated by a cmpany, and also protect API providers and their partners intellectual property. I recommend taking a look at Github's open source licensing pagefor a nice overview of the options, especially since this is one possible location you will be providing access to your code. |
 |
Deprecation Policy - An API deprecation policy sets expectations with API consumers about when and how API resources will be deprecated and shut down. These policies help build trust with API consumers, giving them an idea of how much they can depend on an API resource, and what they can expect when it reaches the end of life. |
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.
