Thanks for the thoughtful response!

I’m sure you guys have been very supportive of your commercial users. And I’ve heard nothing but good things about Flickr’s business practices.

I’m also very sympathetic to how hard it must be to write a policy that covers all the edge cases. I can imagine all kinds of truly disturbing applications being written with the Flickr API. ;->

Regardless, the current situation (where developers have no visibility into what their license costs will be) is not sustainable in the long term. As a developer/entrepreneur, how can someone commit to developing against an API without knowing what their final costs will be? I would never do that for a “regular” software API (say a java library or something). If I was working for someone else, my boss would never let me do something like that!

Hopefully this is a phase. eBay, for example, seems to have a pretty straightforward (if expensive) model of charging for API use, but it has emerged over a number of years. Maybe in few years, the Web 2.0 ventures will evolve more public pricing models. If I’m right, it will mean an order of magnitude increase in the number of organizations (as opposed to individuals) willing to code to your APIs, which would be really cool for all concerned!

This, to me, seems like a really big deal. In talks that I’ve had with several developers, it has barely come up. Many developers consider open APIs as *free* APIs, and thus think they can build whatever they want on top of them.

I wonder though, about how “value” will be defined here. You said that there are situations where there is no value for users or Flickr…what are the criteria for that? Imagine if I built an ad-based site using Flickr’s API that was getting a million hits a day, creating thousands of new users for Flickr? Would that be creating value, or diluting it? Simple example…I’m just wondering how that decision is made.

At any rate, the case by case basis way of doing things sounds like a safe approach at this early stage. I’m continually amazed at what people can dream up to do with other people’s data…

That’d be an interesting point if it wasn’t factually incorrect

We’ve granted many, many commercial api keys. Where it is a goal for the developer, we generally *want* people to make money using our API. If they make money, they can afford to improve their products or make new stuff, and that’s good for our users, and so it’s good for us.

There some possible commercial applications of our API that we don’t want. For example, a site built to sell ads around users’ photos using the metadata we’ve made available via the API would not be ok. Why? Because it’s not in the users’ interests (using their photos to make money without permission), it doesn’t add any value for us, but does cost us money to store and host the photos, run the database, serve the api requests, etc.

Finally, there are commercial uses of the API where a partnership or revenue share make sense. This would typically involve us distributing or promoting the application or service built on the API. I can say the number of these we’ve even considered is only a tiny fraction of the number of commercial keys we’ve given away.

Bottom line is that we haven’t been able to encapsulate all the considerations that go into the decision into a policy yet - it’s not simple to come up with an unambigious articulation that would cover all the different possibilities. So, despite the fact that we’d prefer a policy-driven approach (which would cut down the work for us) you still have to ask us about commercial api use first. Doesn’t mean we need a cut, doesn’t mean we don’t want to encourage commercial use.

Saturday, August 13, 2005

Posts from Jonothan Boutelle and Josh Porter highlight one of the biggest outstanding problems of Web 2.0, discu [...]

Maybe it’s both we are dealing with. Maybe, on the other hand, we are once again missing something that’s coming, business wise.

I am pretty sure companies like Google and Yahoo want to profit from what they offer us for “free”. I am not sure of the way(s) they plan to do so with their APIs.