Shopping API as canary in Yahoo!'s coal mine

Falling under the category of "is it still news if it is no news to anyone?", there has been quite a bit of buzz around yesterday's shocking, simply shocking announcement that Yahoo! is shuttering its Shopping API and transitioning Yahoo! Shopping to outsourced shopping syndication service PriceGrabber by March 2010.

What Yahoo! did right: They gave API developers 60 days notice of the upcoming Shopping Web Services closure, and let them know up front that a PriceGrabber shopping syndication service, and not an API, would be handling the feeds from now on.

What Yahoo! could have done better: handle some of the initial legwork for developers currently using the Y! Shopping API to smoothly transition to the new PriceGrabber shopping syndication services. If you can't make the migration backwards-compatible to make the transition seamless for developers, then auto-create new PriceGrabber accounts for developers who have built applications using the Y! Shopping API to help migrate to Yahoo!’s new method, then supplement with easy-to-use documentation for any "last mile" customizations developers need to handle themselves. Yahoo! has done this type of "make the transition easy on your existing userbase" migration with the egroups and flickr acquisitions in the past.



More than straight news, this is a potent example of a company where their compelling platform strategy cannot save them from a flailing business strategy. Yahoo! has made numerous successful and enviable overtures to developers, with internal and public hack days, the Y! Open Strategy of 2008, and useful data in the form of useful developer Web services and APIs.

Ben Metcalfe (subject of photo above and whom I apparently met at the public Yahoo! Hack Day on the Yahoo! campus in Fall 2006) has a great write-up on the Y! announcement from a developer POV. While I don't predict a spreading deadpool of public APIs as Ben does, Yahoo! as a company definitely will feel the chilling effects of developers being more hesitant to build on Y! APIs like delicious, flickr, YQL and BOSS. I thought this section of Ben's write-up quoted below is spot on, straight out of the implicit agreement between platform providers and platform participants from John's Hagel & Seely Brown's Shaping Platform Strategy theory published in Harvard Business Review:

"API Vendors need to consider their long-term strategy of what they are propositioning. That big “we’re so open it hurts” fanfare is going to cost you down the road if you can’t maintain it. In many ways, removing an API is worse then not offering it all.

API consumers need to consider carefully the viability of the services they are using, especially if they are leveraging them for commercial use or as an intrinsic part of their value proposition. Look for freemium models that indicate viability, or build agile adapters that can be quickly swapped out to a different vendor at short notice (assuming there is one)."

Yahoo! is the latest example that a company's platform strategy can only ever be as compelling and healthy as the business strategy it supports. Closing down the Y! Shopping API is less a comment on the state of public APIs generally or on the commitment of Yahoo! to API developers, and more of a signal about the overall health of the Yahoo! business. Y! is making tough business choices right now -- I don't think it is a surprise to anyone that Y! Shopping is being outsourced to PriceGrabber, so it makes sense that the API would also transition to PriceGrabber. What is unfortunate is that Yahoo! chose an outsourced shopping syndication solution that does not support an API, and that Yahoo! did not make the transition to their new outsourced solution more seamless for developers. Respect the ecosystem.

photo attribution: flickr/dotben