Why Skype needed to kill off its developer program
Killing Skype’s developer program was an exercise in business discipline. You prune your tree of small, weak, sickly branches so nutrients and sunlight let the whole tree flourish. Skype’s developer program (SDP) has been bloodless for years. By every measure. Growth in programmers. Number of ecosystem products. Value contributed. What devalued Skype’s developer program? 5. Musical chair management. I’ve lost count of the number of managers who’ve taken a stab at leading Skype developer relations in the last six years. It takes time and focus to be good at devrels, to build your devrels organization, to establish rapport and relationships with prospective partners. 4. Underfunding. Skype’s management shortchanged the developer program for Skype’s first four years. DevRels never got the budget or headcount it needed to educate, evangelize and support developers. Software and hardware certifications, intended to promote the Skype brand and build trust, instead became a barrier to entry and a costly delay. Metaphor Bank:
Prune a tree,
Remove chometz,
A controlled burn,
Put down a diseased pet,
Excise a tumor,
Balance a project portfolio,
Dumping ballast,
set developers free (Schumpeter creative destruction). 3. Broken trust. Two steps forward, one step crushing partners. Skype me for the sad details of developers who bet on Skype’s constancy and lost. Lost money. Lost jobs. Lost careers. A trail of tears and dashed hopes. 2. Who You Know. Want to get something done with Skype? You needed an inside friend. Skype’s much better now that a process culture’s emerging, but it’s still true. 1. Six Year Old Technology. The perfect developer relations program cannot put lipstick on a pig. 1a. Client-only Calling APIs: So no putting Skype inside your app. Skype’s web services are all proprietary, off-limits to the ecosystem. Skype runs "naked Skype" server farms to support its Skype Lite mobile application. Skype Lite does most things a desktop client does, through Internet APIs, and without resource hungry user interfaces. It’s an internal Skype as a Platform service. Skype’s third-party developers want Skype as a Platform. A SaaP would bring Skype features and the Skype network to web and mobile applications. Web applications are nearly always better business than rich clients. They cost less, don’t have installation problems, are less prone to user failure, are always fresh, and take less time for customers to get their first Aha! experience. 1b. Closed Skype client: So no putting your app inside Skype. Skype keeps users from seeing third party developers. With the Adobe Photoshop Plugin and Firefox Extension architectures, for example, you can write apps that live inside Photoshop or Firefox. They improve a user’s productivity and alter the user experience. They bring specialist expertise to the exact point where users need them. While Skype’s Public API (downloadable SDK) lets your desktop program talk to Skype’s desktop software, it doesn’t let you change what users see and do. The Skype UI is off-limits, verboten, pristine. So you cannot offer inline language translation, extended emoji sets, inline Yahoo! Calendar reminders, or enrich contact profiles with updates about your friends’ activities. If you cannot put your enhancements where a user needs them, why build them? In short, the business and technology sides of the SDP were impaired to the point of irrelevance. Skype needs to reset the program. And its platform. More soon. tags: skype, devrels, developers, apis, saapCall me at +1-510-316-9773, Skype me, follow @skypejournal and @Phil Wolff.
Visit our Skype Journal private roundtable, one of the longest running public Skype chats.