the onda

As usual our friends over at TechCrunch have ignited a debate around web services, data, and the openness of APIs. This one centers around the fact that Zoomr, a Flickr clone, has been denied access to a commercial API key to export people's photos/metadata out of Flickr and into Zoomr. Since we've been mentioned a few times, and since the issue at the core of the debate (should Flickr allow a direct clone access to the data it has built up despite the clone's desire to "replace" Flickr) is a tricky one, I thought I'd give some quick impressions.

First, to the importance of official "openness" in an API: when we were doing early alpha testing, there were two applications that our lead users told us we had to integrate with: Flickr and Picasa. Flickr was no problem: they have a process for applying for a developer key, a clean and well-documented API, and a bunch of third-party libraries/apps that you can use as examples. Picasa? Well, that was a bit trickier. No documentation, no API, and no seeming desire to do anything about it. Fortunately for us, we have someone at Tabblo who relishes these kinds of challenges, and so with a couple of days work, he had it reversed-engineered and we were off and importing photos from Picasa.

So my first point is this: if it's important enough to your product/service to get at some of this stuff, you will find a way whether the company or service you are dealing with is "open," "a model Web 2.0 citizen," or not. Sure they may be a little more friction involved, but one of the great things about networked services is that at some point you have to get on the wire and push bytes, and when you do, it is not that hard for someone else to come along and learn how to speak your language.

Second, and this is the tricky bit to grok, when you use an API like Flickr's, the goal should always be to benefit the user and not to "jumpstart your userbase" or "blow out the metrics." In our case, we wanted to be able to integrate with Flickr for two clear reasons: 1. the avoid the user the hassle of re-uploading photos that they wanted to use in their tabblos, and 2. to avoid the user the hassle of re-organizing the photos with tags, dates, etc. But as far as where the data lived, the stickiness of the app, etc., we really didn't care (in fact, at first we wanted just to use thumbnails and metadata and leave all of the original file-serving on Flickr, something which we had to give up on only because it impacted the user experience.

And since this is a clear enough goal, I think that it should be ok for the person doling out the keys to the API to make a judgement call about whether you are in fact trying to do something that truly is going to benefit their users with the API. I realize that defining this is tough but just because the line in the sand in hard to draw, doesn't mean we shouldn't try. In my mind it has something to do with the nature of the features/functionality being offered by the API requestor, and whether there is a clear and demonstrated need on the part of the community of users for that sort of thing. At Tabblo, we talked to quite a few Flickr users who said things like "well I'd never leave Flickr as my primary place for photo uploading/storage, but what I'd really like to be able to do is ..." and it was the "..." that we listened to really closely.

Now the Zoomr guy may actually have a pretty good "..." to offer Flickr users, and if he does it may be the wrong thing to deny him the API key. But here is where I fall back to my first point– if it's really all that critical to get those Flickr folks in, just do what we did with Picasa and figure out how to get a minimal export working. If enough people start doing it, and given how well Flickr listens to its community, it won't be long before you get the keys to the data. Generally speaking the great thing about clued in companies born of the web (Yahoo, Google) unlike those born of the PC era (Apple, Microsoft) is that they listen and adapt quickly.

Of course this doesn't answer a lot of the hard questions that people are asking with respect to data storage on the cloud in this brave new world but unfortunately we are all ankle-biters when it comes to the really big questions here, and only the big guys can help make the right policy decisions about what should happen in the grand scheme. As more people from the clued-in companies climb the ladder at those places though, I have faith they will influence things in the right direction. Until then, we should all cut them a little slack.