Interface Remixers will Pay for Privilege of APIs

by Joshua Porter  |   6 Comments

Jonathan Boutelle brings up an interesting point after attending the BayCHI Web2.0 panel the other day: the Web 2.0 companies heavily promoting their APIs (Technorati, Flickr, Google) are glad to have developers create interesting new interfaces out of them…unless you want to make money from that interface.

This discussion is just the tip of the iceberg.

Think about this for a second. These companies are all testing the waters here in Web 2.0 world. They’re creating, maintaining, and optimizing their APIs for usefulness, while promoting developer adoption as fast as they can. Technorati is pushing tags, Flickr is pushing photo sharing, and Google is pushing maps. Developers, curious to know what they can create with these APIs, are making cool things such as Housingmaps.com and the Flickr tag browser.

The problem is that there has been no discussion about who can make money where. According to Boutelle, these companies don’t want you to make any money without talking to them first (which means they want some of it). This makes sense, of course, because that’s what the APIs are presumably being built for. So, anybody building remixed interaction interfaces ought to think twice about how they’re going to make money from it (if that is their intent).

Interestingly, not all companies ask for part of the pie in the same way. Amazon, for example, actually pays for developers to use their APIs by giving them referral fees for any products bought.

Another issue that Boutelle relates came from Paul Rademacher of Housingmaps. He pointed out that because remixers (those building interfaces atop of public APIs) don’t own the database, they compete on the functionality and utility of their interface only. This is a much more level playing field than if you owned the back end.

So, one lesson here is that even though these APIs are public, they’re not free, and it highlights further that a lot of business leverage in Web 2.0 is in the database, not the interface.

However, that’s not to say that for every useful interface paradigm we see, there won’t be a market there. For example, if a company comes up with the best real estate interface for Google Maps, say…Housingmaps…and they capture enough of the market before others can, they will begin to have leverage over other copycat interfaces simply because that’s what people use. Sure, they’ll pay royalties to Google, but the bigger they become the more leverage they have to negotiate with Google for future slices of the pie.

Comments ( 6 Responses so far )

1.  George Papadakis on August 11th, 2005 (Comment) #

A question born here is; Are those APIs providers giving away their APIs just to promote and support Web2.0, or is it all about making money (in the future) by gaining more brand value and causing hype?

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.

Pingback: Infinity Plus :: Net app developers ready for big business? :: August :: 2005

Pingback: Greg Yardley’s Internet Blog » Important API talk from BayCHI

2.  Stewart Butterfield on August 19th, 2005 (Comment) #

[I'm one of the founders of Flickr and run it as part of Yahoo. Was also one of the speakers at the BayCHI panel.]

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.

3.  Josh on August 19th, 2005 (Comment) #

Stewart, thanks for the clarification. Notice that I did back off my first provocative statement by pointing out that Bouttelle seemed to suggest that there needed to be a “discussion” before developers could build commerce on top of services like Flickr, as opposed to no commerce at all.

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…

4.  jon on August 19th, 2005 (Comment) #

Stewart,

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!

Add Your Comment

Accepted tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> .

Preview...

If your comment contains links, or if it is your destiny, your comment may not show up immediately. I'll approve it as soon as I can. (I delete dozens of comment spams per day)

Get updated when someone posts a comment: Comment Feed


ABOUT

Bokardo is the blog of Joshua Porter, a web designer/developer, researcher, and writer. I live in Newburyport, MA, USA.

WHAT IS SOCIAL DESIGN?

Social design is design that focuses on the social lives of users. It deals with the activities, behaviors, and motivations of people who work and play together through software interfaces. It is built on the observation that many of the decisions we make are greatly affected by those we surround ourselves with in our social lives: our family, friends, and colleagues. Exploring our motivations and how to design interfaces to support them is what the Bokardo blog is all about.

Designing for the Social Web

Building a social web site or application? I wrote a book just for you!

designing for the social web

Find out more or order from Peachpit or Amazon

Upcoming Events