API Keys for Direct Competitors

Sat

Jun 17
2006

listen

API Keys for Direct Competitors

In a FlickrCentral discussion thread about Picasa Web Album, Google's new photo hosting service, Stewart Butterfield from Flickr says something very interesting about whether Flickr would, or should, give a direct competitor a Flickr API key for the purpose of moving a Flickr user's data to that competitor's service:

[T]his is something that we've never had any set policy on and this thread has sparked a lot of internal debate on the team: some people felt that it was unreasonable, some people felt like it didn't matter since Flickr should win on the basis of being the best thing out there.

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).

I love this, and would love to see this idea discussed more and more broadly. The discussion seems to me to overlap directly with this (long but very worthwhile) exchange between Mark Pilgrim and John Gruber: When the bough breaks, And Oranges, and Juggling oranges. Mark and John are talking about desktop applications, and Stewart and his interlocutor, Thomas Hawk, are talking about web applications, but that's where the differences end. In both conversations, they're talking about freedom and ownership of data (a topic on which you should expect to see me write much more, very soon).

There are license lawyers who will jump all over this with a GPL derivative, and given the success of the GPL at promoting its core ideas, there is some place for that. But at start, the discussion of data freedom and ownership should continue. It's important. Eric's API Parity solution is a great one.

tags: meme wars | comments: 9 | Sphere It
submit:

Previous | Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4743

Comments: 9

Antonio Rodriguez [06.17.06 07:57 AM]

Hey Marc,

While I think that this is a great idea for big cos. when they are dealing with each other, I'm not sure that it makes sense when one party is a small scrappy startup for two reasons:

1. small startups barely have the resources to keep things going and evolve their own products. Asking them to also develop/test/maintain a full API seems like it might be unrealistic (Flickr deserves a gold medal for having done this and I think their success came from mostly "eating their own dog food" internal to the app).

2. small starups tend to have highly dynamic products and freezing an API at any point would almost destine it to be obsolete right away. Things just change too quickly.

For big cos., or established services/offerings though, this seems like a really good idea.

Marc Hedlund [06.17.06 08:23 AM]

Thanks for the comment, Antonio. I certainly agree on resource allocation. The thing I find interesting in this discussion, though, is the question of what the companies holding our data should do; it need not be the case that they all do it at once, nor from the very start of the company.

You're right that a small company has a lot of very good reasons to want to establish a position in the market first. But, even a small company can post a manifesto or "bill of rights" for how they intend to treat their customers' data. The core promise, that customers own their own data, and can take it with them should they choose to leave, requires only the right intentions. The engineering can come later.

Michael Randall [06.17.06 09:12 AM]

I wonder if there's a need for a sort of standards body for this stuff, who could make some sort of "Data Freedom Certified" logo, and license use of the logo to companies that meet a set criteria for being able to (at least) export all of your data into a format that can be imported elsewhere. Maybe a kind of 'gold' rating too, for companies that (as Flickr are considering) will directly support their competitors grabbing your data, with your permission, to allow you an easy migration away.

One of the first things I look for in a service is often how easy it will be to get away again later if they stop being good, get bought, or close up shop. It often takes a while to find the information, though, and you can often only do it by signing up, putting some data in there, then *trying* to get it out again.

In RSS readers for example, an OPML export option, tested as working by the 'Data Freedom Foundation' would give them the right to display the basic logo on the site, and maybe an API that would let another reader connect, grab your feeds, and any ratings/comments/tags/etc along with them, would let them show the 'gold' logo.

Isaac [06.17.06 09:14 AM]

I will definitely move all my flickr photos to future picasa album from a common user's perspective, if P keeps free and integrate with Gmail's contact sharing. I don't think it's an API key game, since Google will always be open on interface. Then the final decision is in user's hand.

Before/after Yahoo's acquisition, Flickr has very good community, but seems very stubborn on user's comments and ideas to improve itself. They insist on their own ideas so much. I guess Picasa will give more rights to end users from the observation of other product lines.

Perrin Harkins [06.17.06 09:37 AM]

A better question might be how could Flickr stop them? If the data is on the web and the accounts to view it are free, preventing people from downloading it is pretty near impossible.

Marc Hedlund [06.17.06 09:50 AM]

Perrin,

There's a lot of discussion of that question (why a direct API is or isn't better) in the thread linked above.

Patrick Tufts [06.18.06 09:49 AM]

Eventful is doing something similar. When you create a new event on their site, they give you the option to upload it to their competitors as well.

It's the right thing to do. It ensures that people come to Eventful first. When I want to advertise an event, I just have to go to one place.

Javier [06.20.06 08:06 AM]

I don't see that this opening to everyone-but-competitors would lead us very far. Who will define what a "direct competitor" is? I'm afraid the judge will have to, more often than not.

Like the GPL indeed, it would only enforce freedom inside its own world, and people with different practices or different constraints will be requested to stay out of the game until this new model expands and includes their way of doing business.

Either you bet that you'll keep the leadership (because your company values can't be copied) and you open your API with faith, or you don't think you can limit greedy competitors, and you limit the openness, at the risk of being less attractive to your users.

manan [10.12.06 07:51 PM]

what to know who r the major competitor of api?
can u help me out with these.
thanks