First, go read the post, if you haven’t already, by Google’s Steve Yegge. What was supposed to be an internal memo was accidentally made public, and now the world can benefit from it.
A short excerpt:
I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.
But no.
What I’m struck by is the difference between being a product company and being a services company.
Of course everyone pays lip service towards being a platform/services company, but what Yegge’s post puts a finger on is that there are good API’s and there are bad API’s. By forcing the entire company to make API’s a core competency, Amazon has come up with a fantastic set of API’s for both their storefront and web services. Their storefront API’s allow merchants like Target to set up stores on Amazon.com and leverage their infrastructure. Their AWS API’s are even more extensive, allowing whole companies to exist reselling Amazon services (Heroku, Engineyard, etc).
And that’s the power of the “cloud” – having always-on services that can interact with each other means that I can schedule posts for Twitter and Facebook for an hour when my friends are actually awake, initiated by my news reader. It means that I can click a button to deploy my source code from Github to an Amazon server managed by Heroku. And it means that if your product doesn’t have an API, it won’t be invited to the party.
In addition, as Steve mentions, platforms increase accessibility. And for consumer applications, accessibility is king. Well, one king, anyway.
“Start with a Platform, and Then Use it for Everything.”
How do you know that your platform is sufficient? Try to build your own app on it. Any time you find yourself needing private API’s, it’s time to extend your platform. An insufficient platform is incredibly wasteful, as it wastes internal resources building something that people won’t use and developer goodwill as people realize that they can’t build what they want.
At Astrid, we’ve had people submit patches that expose new API’s for functionality they needed, such as displaying user tasks in a widget. Then, we take these API’s and extend then to cover a wide range of similar problems. By being open about adding new API’s, and providing support and information to those who are developing with them, we’re ensuring that the user needs that we are unable or unwilling to meet are getting met one way or another, expanding the appeal and stickiness of our app turned platform. Yes, thanks to Android, our mobile app is also a platform for storing and manipulating tasks.
Yegge’s blog post resonates deeply with me. As a company that goes head to head with Google (who doesn’t?), hopefully his ideas don’t catch on too quickly, but I think writing like this advances the entire state of the industry.
