LicensingCommericalMashup

From MashupCamp

There were a couple of major discussion threads: - How to get more predicability and transparency to the terms and conditions for the web services that developers use; and - Some of the issues/requirements associated with building businesses out of mashups. As Hart Rossman of SAIC put it "How do you build a business model?"

On the first topic, one of the issues that emerge is the question of what is "commercial" use, a term used by a number of API providers but often ill-defined. Adsense and other forms of advertising and affiliate programs make the definition especially murky because they make it relatively easy to earn a "few" dollars. (A few do provide a more stringent and specific definition. For example, Google Maps draws a distinction between login on for a fee and more commercial uses.)

Dave Nielsen of StrikeIron (commercial API provider) framed the issue in terms of information providers trying to figure out how to keep from being ripped off. Discussion of payment based on the value of the API. (Issue is that it's hard to define the value; it depends how and where it is used.) David used to work for ebay and noted that ebay gave away listings API, but that some people abused so had to put in trigger. Also noted that some APIs are readily monetizable (by the consumer) but others are not. He also said, that from his perspective, visibility helps adoption, as do SLAs. But problems happen upstream as well. "When we go to publishers, a lot are seling data at a minimum entry of $10K. They are trying to partner with us based on the level of commercial use, but we can't calculate that."

Observation that there are analogs to pay-by-use. For example, ASCAP which collects royalties for song plays based on size, venue, etc. (And there are companies, e.g. Muzak) that will take care of the payment issues for companies that don't want to deal with themselves.

There were various suggestions to look further into some of these issues-perhaps a group to conduct research into these questions more closely. Stephen O'Grady observed that many of the API providers seemed uncertain about where to start--for example, in defining what is a commercial site. However, it was also observed that--especially with respect to the large API providers--there is mentally a balance of power issue. Comment that much of this ambiguity has perhaps arisen because the API providers "wanted to encourage quick adoption for free with a 'real' pricing model to follow." Perhaps they are afraid that they will lose quick adoption if they start instituting explicit pricing policies.

Also discussed was ways that the situation with the API providers is different from the "old days" with MSDN (and therefore the same development community models don't necessarily apply). Stephen observed that when Google Maps went up it consumed 2/3 of Google bandwidth overnight; i.e. consumption of APIs has real costs whereas programming on a client to a local OS or application API does not. Providers want to encourage use of their APIs but there is a cost involved as well. Perhaps possible "best practices" for providers from the POV of developers/consumers (wrt explicit limits, combination with other APIs, etc. would be helpful).

With respect to building businesses, a proposed question to ask yourself: "What are you thinking about in terms of APIs, service to users, and business models?" Distinction between hobbyist and business accepted, but the frustration arises when a hobbyist effort becomes wildly popular and the API provider provides no real transition plan--and just shuts off the API.

However, a lot of the debate kept coming around to whether something is being run as a potential business or not. David notices that most of the free APIs from Google, Yahoo!, etc. being discussed do have commercial alternatives. It's just a matter of paying for them. Businesses need to assess risk factors and put contingency plans in place. "There will always be lawyers negotiating things. And ambiguity." as one person put it.

Notes by Gordon Haff. Feel free to amend/append. I also did a blog post based on this session: [1]

John Musser also posted some notes @ ProgrammableWeb [2]