Sadly, I was not able to attend the recent Mashup Camp at MIT - it would have been great to return to Cambridge, and it sounds like I missed some amazing sessions. But I had to stay in the Bay Area for the First Round Capital CEO Summit, which was time very well spent. Josh, Rob, Howard and Chris may not pick EVERY company right, but the entrepreneurs in that room were an amazing group of people. The presentations were outstanding, and the interactions I had with my fellow CEOs and executives was incredibly useful. A special thank-you to the speakers who took time out of their day to talk to us - the content was highly useful.
Anyway, as much fun as the Summit was, I missed what sounded like a great panel at Mashup Camp talking about "Making Money from Mashups". John Musser has a great summary here. John's post should be required reading for anyone thinking of exposing an API for adoption by a developer community - all of the concerns, pitfalls, opportunities, and "dos and don'ts" of offering APIs.
The bottom line is that an effective API program is scalable and predictable. Remember, the reason people are embracing web services based application development is that it is supposed to be easy, scalable and economical...and they expect that they can build something successful.
Give developers enough free access to experiment and develop. Make the Terms and Conditions clear, and the opportunity for success real. If you are going to charge for access above a certain level, make sure people know what that charge will be, and when it kicks in. And make it very, very clear that the API is here to stay, and that people can realistically rely on it when building mission-critical applications.
Traditional software development platforms like Oracle or .NET or MySQL would never have thrived if the resulting software had limits set around how much they could be used - restrictions on how successful they were allowed to become. It is the uncertainty of the availability of web service components that cause developers to be reluctant to depend too heavily on an API that could vanish.
I'm reminded of an exchange between me and an audience member at the mapping panel I moderated in New York recently, an audience member asked me "so we are supposed to rely on these API providers, but how do we know they will always offer these sevices? We're trying to build great applications. How do we know when or if we'll be cut off?
Simple answer - "whenever it becomes mission critical to you, expect it to be cut off by them."
But that doesn't have to be. Many providers understand the importance of consistency and predictability. At the recent salesforce.com apex gathering in San Francisco, it was clear that salesforce.com is serious about getting a lot of people hitting its APIs heard, and about, as they said, "helping YOU to become the next salesforce.com. 500 applications have been deployed; they are getting over 50 new applications up each month.
A lot of this will shake out in 2007. Dialogs like this one will be key to managing the transition to this new opportunity. I'm looking forward to it!