There’s a really interesting interview with Flickr’s Stewart Butterfield over on the O’Reilly Network. It includes a lot of sound, practical thoughts on folksonomies and business models and working with developers and third parties, but I thought this answer on the Flickr API was particularly interesting:
On the strictly practical side, I think we had one person inquire about using the SOAP version of the API. I don’t know if any apps were actually built. There is at least one application built on XML-RPC. But all the others–I don’t even know how many there are–are built on the REST API. It’s just so easy to develop that way; I think it’s foolish to do anything else.
It’s really valuable for any new product or service to reach the hyper-geek audience, who are particularly influential. And for them, the open API is a sign of good faith, a sign that your photos and your data are not going to be locked up in Flickr–even though we don’t currently offer a feature to download your photos to your own computer (we will), you could develop one.
It makes a difference for us as a business that other businesses are interested in working with us because they can tell up front how much work it’s going to be. Basically third-party apps fall into one of two categories, useful or cool, and some things are both. Useful would include uploaders for a bunch of different platforms, a screensaver that pulls in your contacts’ most recent photos, and an application called 1001 for OS X that grabs the most recent photos from your contacts or specified tags, and it pulls from them like an RSS reader. And then there’s a bunch of applications that are just cool, like one that takes photos tagged with different colors and arranges them into the shape of a rainbow.
It makes a difference for us as a business that other businesses are interested in working with us because they can tell up front how much work it’s going to be. They can have their engineers look at the API and say, “This is what I want to do, how long do you think it’s going to take?”
On the flip side, there were a bunch of people we were looking to work with for printing and the people who didn’t have good, clean APIs, we just couldn’t work with them. We didn’t want to put in the cycles in dealing with their integration engineers on a one-off project and have them develop the functionality we needed and then start implementing. We wanted to get a document that specs it out and start going. We actually chose a print partner based on the quality of their API.
I’d never thought of an API as being a proof of good faith before, but when you think about it it makes perfect sense. And choosing a print partner on the quality of their API? I can see some web technical teams weeping into their expressos at that particular vision of Nirvana…