There are two broad types of software companies in the world, API companies and product companies. API companies are those who are focused on providing the best and most useful API’s possible. While they too might build product(s) on top of their own API, it is clear that their API comes first and foremost. Two prime examples of this approach is EchoNest and Amazon Web Services.
On the other hand there are product companies who are solely focused on making their product as good as possible and don’t care about the developer community. While some of these companies go so far as to release an API, it is obvious from their actions that they really don’t care or allow anyone to build anything great on top of it. Examples of companies/products in this realm include tumblr and Google+.
This distinction became clear to me after a recent experience I had with a company named Songkick. Songkick gathers data on upcoming music concerts in the US and UK. They expose this data via a web application at songkick.com along with having a developer API.
I have been kicking around some web app ideas in my head in the music space. After deciding on one I wanted to build in the concert space I headed over to Songkick’s developer page to get API access. I put in my email and a short blurb about my idea and submitted it. I was told I would “receive a decision in a few days.” Arg. It was at that point I should have realized this wasn’t going to end well.
Four days later I received an email from Songkick notifying me that my request had been denied because according to their representative “we're holding off on issuing API keys to services that are that similar to our own functionality.” Seriously?! Did my idea have some overlap with theirs, sure it did. We’re all using the same data from the same API after all, what did you really expect?
After giving it some more thought I realized that the issue isn’t Songkick being extraordinarily picky about who they give API access to, the problem is that they are a product company, that unfortunately happens to have an API. Product companies worry about others taking their API and making something better than what they’ve made with said API. Contrast this with the behavior of an API company, in this example Amazon Web Services. When AWS was first released it was just a set of API which developers could use to launch servers. Shortly thereafter the folks at RightScale and enStratus realized that they could build a nice web console on top of it to make the server creation experience simpler and easier to use. For a few years both of those services spent a lot time taking those APIs and building useful tools on top of them that make them even better.
A few years after the API release, Amazon decided to release their own web-based console. Did they revoke API access for RightScale and enStratus because they provided “similar functionality” to what the AWS Console provide, absolutely not. In fact, AWS Console is just another application built on top of the AWS API, they get no special treatment. As a cautionary tale to those considering making the switch from one to the other, lets talk about Twitter. From the very early days it was clear that Twitter was an API company. They had their flagship web app, but by releasing an API they allowed developers to create tons of different client applications. Web apps, iPhone apps, Andriod apps, and even entire devices dedicated to tweeting. This strategy was working great for Twitter and allowed tweets to be written and consumed from almost any device that was programmable.
Everything was going great until March of 2011 when Twitter “Drop[ped] The Ecosystem Hammer” on its developers. What really happened was that Twitter made the decision to transition from an API company to a product company. Unfortunately that transition was made abruptly and with little warning. Many developers who had spent years developing on their platform were upset and ultimately stopped making applications.
If there is one thing I learned from my experience with SongKick and that you’ve hopefully learned from this post it’s this: the decision between being an API company is an important one and if not done correctly it can cause a tremendous amount of strife between you and your developer community. Make the decision, make it early, and make it obvious to everyone else.