tasty morsels of goodness on open platforms, developer relations and motherhood 2.0

Tuesday, January 12, 2010

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.

Mash up or Shut up

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

Monday, January 04, 2010

2010 prediction: cloud to benefit from less haze and hype

The warning signs have been around since about 2008. My own truly worrying signal that the increasing buzz around cloud has officially kicked up too much dust came when, flipping through my beloved Economist recently (how will my new Kindle ever give me that crisp, snappy-paged satisfaction?), I read through The Economist Cloud Briefing: "Clash of the Clouds: The launch of Windows 7 marks the end of an era in computing—and the beginning of an epic battle between Microsoft, Google, Apple and others."

Attribution: Illustration by Ian Whadcock, Economist.com

Let's get this straight. The Economist -- as close to a journalistic beacon of integrity and excellence as exists, IMHO -- "and othered" Amazon to include Apple in its Top 3 battling it out for cloud dominance. DRM-imbued, closed loop, opaque Apple. Then, led its list of Top 3 cloud titans with Microsoft, who arguably is just getting started with cloud efforts, and is not yet apace with Google or Amazon. Or Salesforce.com for that matter. Isn't this the business equivilant of awarding Obama the Nobel Peace Prize, signalling sky-high expectations of players, most of whom haven't delivered much of anything yet?

You'll need to read the article to get a sense of the restricted way the author seems to define cloud computing solely as a mainframe-to-PC-to-cloud evolution, completely missing the context of cloud as a platform that is leveraged by other parties to create customer-facing applications (nicely echoed by vzach and AOtto -- benefits of the Web edition include the exposing of kindred reaction. :-)) Dion Hinchcliffe of ZDnet makes more accurate, compelling points that the clash of the clouds will be a "winner-takes-all" battle similar to previous platform battles, where immature battlefield rules of engagement, standards and definitions are still being solidified.

On top of leading and well-respected business publications clouding our understanding, additional murkiness came in the form of a pre-holiday duststorm around the December 18th Rackspace "cloud failure" that brought down major sites for the better part of an hour (again) when Rackspace failover plans seemingly did not include data center and peering redundancy for AT&T when their backbone failed ("FailT&T is the Ford Pinto of the internet" via @shamptonian.) Isn't redundancy a key prerequisite for something to be considered cloud, therefore making this not a cloud failure, but a hosting redundancy failure? (read: is it OK for virtual private server hosting to be re-branded as ‘cloud’ hosting when it is not in fact cloud-based via @john_mason_?)

My wish in 2010 if for cloud standards to grow up a bit, and for cloud as a platform to become less "developer-beware". May the best titan win, may they be as open as possible but not more open, and may cloud not suffer the fate of becoming the most overhyped, least delivered upon term of 2010.

Labels: , , , , , , , , , , ,