This afternoon I am participating on a panel for Yahoo! OpenHack NYC titled “Building on Others’ APIs: A Strong Foundation or Recipe for Disaster."  That will make a good complement to yesterday’s discussion at the USV portfolio summit where we spoke about the importance of having an API.  In preparation for the summit, I asked Oren Michels from Mashery whether he had a good example illustrating the importance of having an API.  Oren kindly send along this impressive chart:

Now of course this does not qualify as scientific evidence, but it shows Compete’s growth starting to really take off exactly around the time that they open up their API.  Also, within the USV portfolio some of the fastest growing companies have a significant part of their growth coming from their APIs.

There are many benefits to having an API that can help account for the incremental growth.  By using the API, third parties can support additional use cases, user experiences and users that the company itself would not have the resources to pursue.  But the discussion also covered some of the potential issues.  If your service does not have sufficiently strong network effects or other tie ins, then having an API might reduce switching cost for users and allow others to create a "plug compatible” competitive offering.  Also if you believe that control over the user experience is critical then having third parties create potentially inferior or conflicting experiences might be an issue.  Finally, if you are trying to innovate very rapidly, then it might not be possible to offer a sufficiently stable and meaningful API to have adoption, or conversely if you have a massively adoped API it might hinder your ability to innovate.  While I agree that these are potential issues, I believe that in each case it would be important to question the relative importance compared to the growth benefits of having an API.

So what about building on someone else’s API (the topic of this afternoon)?  For starters everyone developing any code of course uses APIs all the time, if only the ones provided by third party libraries or say databases.  So the question would really seem to be about building on APIs that will supply core functionality for your service and for which you are betting on a single company which is providing them.  There seem to be two key risks in doing so:

• First, that the API goes down or is taken down and makes your own service unavailable as a result.
  
  

• Second, that the provider of the API will eventually try to extract a “tax” on your profits.

There are ways to reduce those threats, such as developing in a way where if competitive APIs become available you could switch easily, but ultimately these are risks that cannot be eliminated.  The more important question therefore should be why someone else’s API is central to your service to begin with and what this says about the ultimate value of your service.  In many cases, I believe the answer to that question is that it imposes serious limitations, in which case you should focus on minimizing the cost of launching and maintaining your service as the primary means of mitigating risk.

Should be a fun discussion and I look forward to seeing some you there (that is if not everyone goes and listens to Rasmus Lerdorf instead …).