I had an interesting conversation on Twitter earlier this week that indirectly helped me realize something very important.
We all know what API is and we all know lots of examples of successful services that were made possible by someone else’s API. We also could recall several examples when API backfired, at least in part. Take, for instance, Twitter itself and its relationship with their developer ecosystem, which probably could be best described as “rocky at times.”
But instead of looking at API from ecosystem’s perspective, let’s look at it from the point of view of a provider.
Imagine you lead a company that offers a way to consume your service’s functionality programmatically - i.e., through API or SDK.
It is indeed possible that your goal is to build an ecosystem around your main service. But, on the other hand, perhaps ecosystem is not in your plans. There are many services and use cases where it’s significantly easier to interact with a service programmatically. For example, when you are importing your HR data into a new system, you most likely want to automate this process, as opposed to manually enter each individual record one by one. In other words, maybe the reason you make API available is not to form an ecosystem but to allow your customers to automate their interactions with your service.
And here is the dilemma.
At the time API is introduced, a provider can’t credibly signal which way they want their API to be used - in other words, it can’t send a signal credible enough to indicate whether they want to foster an ecosystem or they only want to enable time-saving operations (history shows that executives’ interviews and blog posts are not credible enough).
Furthermore, while ecosystem-aspiring providers will never mind the use of its API for pure automation, automation-aspiring providers can’t control in advance whether their API is used by a developer to help kickstart an ecosystem, even against the will of the provider.
When a service puts up its API with the stated intention of growing an ecosystem, what they actually mean is “we want you developers to be a part of our ecosystem so that our audience grows and more people are using us (even if we share the spoils with you) but if you do something (and as of now, we have no idea what it might be) that we like and that we think we should have more control over, we will adjust the rules of our ecosystem as we see fit at that time.”
The dilemma is that a provider can’t outline its rules early enough to avoid having to change them in the future because it can’t know early enough what uses of its API it will like and what use cases it won’t want to tolerate.
In this context, you may want to revisit links from my blog post from about 2 years ago titled Ecosystems and Platforms.