Can Skype become a platform-driven product?
How much of a programming platform does Skype offer? Not much, never enough. Skype developers voiced this since day one. Skype has treated their API and platform strategy as an afterthought. It shows in:
- The client feature count growing faster than the number of API features
- Features added to the API weeks, months or even quarters after they're introduced into the Skype Windows client
- That many of the APIs Skype promised remain exclusive, vaporware, or placeholderware.
- Slowly and underdocumented Skype APIs.
There has been progress, such as the hiring of a technical communicator to work on documentation projects. But Skype's API remains a token one, changing glacially.
Skype has three strategies to choose from.
- Craft a modest subset of what is possible, and publish as an API
- Commit to promptly adapting new plumbing and user experiences to an API
- Roll capabilities into the API before rolling them into user product
A. The Afterthought Strategy.
Skype saves on API programmer headcount and runs new features straight to production code. This starves the APIs to the point that partners and developers have little hope of ever using the juicy stuff coming out of Tallinn. As competition creates alternatives, and word of API starvation spreads, defections will outpace recruitment.
B. API follows closely.
No bets, but Skype may try to close the gap. They can add bodies and money, improve communication between the product and API teams, strengthen direction. This solves much of the problem. There is always a gap, but it's short and consistent. As teams work to expose most of the plumbing and user affordances, the API stakeholders will develop confidence in the stream of features, in their window to all that Skypey goodness.
C. Ambition and Leadership.
How can Skype embrace platforming?
Adopt a service architecture. Modularity at heart, starting inside the application, extending to outside interfaces.
Build features for the API first, then build the rest of your application on top of your own API. As user requirements and experience breakthroughs pop-up, this drives development to weigh heavily their architectural value. Can this new behavior be used in many ways by many systems? The API-first model turns complexity into an enduring asset.
So far I've identified four levels of a Platform Program Maturity Model, with Zero/Zed being the complete absence of programmatic interface. Skype is at PPMM Level 1, the API as afterthought, never catching up.
Other factors in a Platform Program Maturity Model
Leading with your API isn't enough to bring you up a PPMM level. You must also improve your developer communication, frequency of API updates, breadth and richness of the API, prompt and useful documentation, licensing, and support of underlying platforms (operating systems, hardware devices).
Platforming as a Market Force.
Skype isn't alone, so this is an incomplete view. Microsoft, Yahoo!, and Google have all committed to not only making their chat/talk/video clients better than Skype (better strongly influence by their respective values and design aesthetics), but also to platforming. Microsoft Live Messenger's first API should come out in Q2. GoogleTalk's API is already out and the Google Desktop API . Yahoo! published APIs for just about everything but Messenger. Can't wait to see how much of Apple's iChat AV is scriptable.Telcos are offering their own softphone offerings, mostly without APIs. High volume online retailers and tech support sites are adopting push-to-talk tools. Hardware makers are creating Skype phones in many form factors.
As our definitions improve and stabilize, it will be easier to document and compare platforms for the opportunities they promise to developers and other partners.
