Flickr, Zooomr and API Parity

The following is republished from the Tech Times #141.

An issue I touched on in my editorial on Web 2.0 Connectedness bubbled to the surface this week with news that Flickr had denied a request from competitor Zooomr for access to the Flickr API so that Zooomr could import users’ Flickr photos and metadata (e.g. tags) for them.

Now before you hit the warpath, I should point out that Flickr has approved requests for API access from other competitors like Riya and Tabblo in the past. Something about the directness of the competition that Zooomr represented for Flickr tipped the scales, however, and Flickr made the call. Via email to Zooomr:

…we choose not to support use of the API for sites that are a straight alternative to Flickr.

Founder Stewart Butterfield even shared his reasoning on the FlickrCentral forums:

With respect to granting a commercial API license to a direct competitor: we might not. […] In the case of a truly direct competitor (and, so far, we have very few), we probably wouldn’t. And I don’t see that as malicious on our part: why should we burn bandwidth and CPU cycles sending stuff directly to their servers?

This, understandably, sparked some serious discussion. When responsible companies like Yahoo! claim that their services are open, allowing users to retrieve whatever data they put into them, do they have the right to make it less convenient when what you want to do with your data is move it to a competing service?

After some internal discussion of the issue, Butterfield reconsidered his position:

I actually had a change of heart and was convinced by Eric’s position that we definitely should approve requests from direct competitors as long as they do the same. That means (a) that they need to have a full and complete API and (b) be willing to give us access.

The reasoning here is partly just that “fair’s fair” and more subtly, like a GPL license, it enforces user freedom down the chain. I think we’ll take this approach (still discussing it internally).

This proposal that API openness between competing services should be a two-way street was applauded by O’Reilly’s Marc Hedlund, and dubbed "API Parity".

While the symmetry and inbuilt fairness of the arrangement does look attractive at a glance, and should resolve the issue to the benefit of the users quite neatly in the Flickr/Zooomr case, I’m not convinced this is a conclusive solution to this issue in general.

I’m not going to argue that all web-based services should be forcibly compelled to open the content created by their users for easy export. I certainly believe that it’s the right thing to do, and will ultimately contribute to user confidence in the service, but as Nicholas Carr points out, vendor lock-in is a proven business strategy that is unlikely to die anytime soon. But there will also always be a segment of users that insists on their data being openly available to them, and services like Flickr will cater for such users.

What I will argue against is any such open service intentionally putting up roadblocks for certain uses of a user’s data. Returning to the Flickr/Zooomr case, Flickr’s objection to providing unilateral API access to a competitor on the basis that it "burns bandwidth and CPU cycles" just doesn’t hold water. Flickr’s servers will run just as hot whether a user downloads the data and then uploads it to the competitor manually, or performs a direct transfer to the competitor via Flickr’s API. The only difference Flickr makes by denying its competitors API access is to arbitrarily reduce the convenience of its service when users want to take their data elsewhere.

So while so-called API Parity is certainly something to be strived for, it should not be a condition for an open service like Flickr to provide API access. It’s not fairness to its competitors that Flickr should be concerned with: it’s fairness to its users. A service just isn’t open unless that openness is provided uniformly and without bias.


Category: programming Time: 2006-06-21 Views: 1

Related post

iOS development

Android development

Python development

JAVA development

Development language

PHP development

Ruby development


Front-end development


development tools

Open Platform

Javascript development

.NET development

cloud computing


Copyright (C), All Rights Reserved.

processed in 0.121 (s). 12 q(s)