I had assumed you received it and was annoyed that you didn’t respond, since I figured you’d understand exactly what I was saying in a way that most people wouldn’t, and because I saw the update on Scripting News today on a similar point but with no mention.

Anyway, I hope you read the whole thing. There’s some context here that I think is important and I’m hoping that that gets carried into the general conversation about it. No invective. Peace.

The issue isn’t so much letting people get their data out (we already do, and always have), nor is it specifically “making it easy”, but granting direct competitors (especially those with short or unknown track records) the ability to proxy for users’ login credentials.

I don’t know if you’ve ever looked at our authentication API. Basically the way it works is that third parties send users back to Flickr to check if they want to give the third party the credentials necessary to authenticate via Flickr on the users’ behalf. If they say yes, the third party gets an auth token for that user, tied to their API key and auth secret. Then they can call authenticated methods via Flickr’s API — essentially, they have the ability to login on the users behalf and do all kinds of stuff.

For partners or independent developers doing something complementary or any number of other, we eat the risk of them doing something bad with the API. For competitors, it’s harder to scrape together that trust. For competitors with no background or track record, it’s even harder. Imagine an app that deletes all your stuff off Flickr after importing since “you’re done with it”. That kind of sucks for Flickr, but it REALLY sucks for the user, and we’ll take the blame for it.

But more importantly, who gets API keys is kind of a red herring because custom implementations of vendor-specific APIs are not the path to true interoperability. Given your background, I’m betting you understand exactly what I mean. I wrote about that on Flickr:

That’s why you download an OPML file and upload it somewhere else. More generally, that’s why there .csv format, and XML all over the place, a zillion IEEE, ISO, ITU and IETF standards, and things like EXIF, DOPF, ITPC and XMP for photos. That’s why you export your blog from one service and import it to another.

And that’s why I was talking about embedding information in the jpg files - the only way you get real interoperability is with a standard. Most people with digital cameras use their PCs to manage their photos. What are the chances that Microsoft builds a Flickr API-based Flickr importer into Windows or Apple builds one into OS X? Or Adobe Photoshop Album, Picasa (the desktop client), ACDSee, Jasc/Corel Photo Album, Thumbs Plus, iMatch and the dozens of others do the same? Would all of them start coming bundled with web servers? Are we going to implement an import service for each of them in case someone changes their mind after making some changes?’

Anyway, there you go. We go way, way out on limbs all the time for users and we will continue to do so. We’re not trying to lock anything or anybody in. You said I’m “ignoring the interests of [my] customers” and that just ain’t true. There have been Flickr export tools since the beginning and we’ve never tried to stop anyone from making them (in fact, one of our employees developed one on the side and stuck it in CPAN). And we have zero interest in preventing a competitor from importing what we export. We’re just a little hesitant in making our API the main conduit for that. So, if you want to have a valuable discussion on this at BloggerCon, I think you have to do it with all the nuances and complexities intact. Otherwise it just becomes empty rhetoric.

(Also, less important, but still a correction: we never released the import tool from Buzznet to Flickr because it seemed like a cheap shot. We’re not changing any rules.)

Trust me in that I want to make sure everyone has access to Zooomr’s data at some level or another. I’m all for swapping API keys with Flickr (and any other entity, for that matter) and hope that in the end, users get a richer, more seamless experience from open standards.

If you would like to get to know me, please drop me a line — I’d love to discuss things further with you.

More anon,

Kristopher Tate
cto & founder — bluebridge tech / zooomr