Making Money From Mashups

John Musser, January 18th, 2007   Comments(11)

A well attended Mashup Camp session hosted by Stephen O’Grady of Redmonk and StrikeIron’s Dave Nielsen lead to an active discussion on questions and issues around commercialization and business issues of APIs and mashups. Below are my rough notes from the session.

• How are developer ecosystems best managed. Analogy made to old Microsoft Developer Network (MSDN) as a model of a classic, well-run developer program.
• Concern from couple audience members about lack of responsiveness from API vendors. If I’m running a business, who do I talk to? Usually when they’re small the providers don’t respond to them. Sometimes developers have choices: easier to swap providers (ex one map provider to another), sometimes no alternatives.
• Differences in new vs. old models software models: used to just distribute and install software, now in a hosted model there’s additional costs such as bandwidth and ongoing operational costs (desktop vs. SaaS).
• Alan Taylor creator of the excellent Amazon Lite, got a friendly cease-and-desist from Amazon for integrating Amazon data with links to Netflix and iTunes.
• Providers have contractual obligations that get baked-into terms of service, like no real-time geocoding mapping from map platforms because this treads on navigation system deals (besides the system load issues). Thus API provider downstream commercial interests and agreements need to be protected.
• Noted that Amazon and eBay have internal tools and dashboards to monitor API usage. Allows them to monitor usage by mashups. If something gets either accidentally out of control or becomes wildly popular, they can contact the developer (or shut them off if need be).
• Worry about vagueness and open questions about terms of service: in the future will the provider be lenient with me in the grey areas or will they take my house.
• Should there be a defined ‘transitional space’ that allows a mashup developer to be protected from an inconvenient API shut-off if they become successful (even what if they get dugg and traffic spikes).
• There’s a need to develop ‘monetization models’. Examples given is how well defined the models are in the music industry (ex: ASCAP) or with financial data (ex: up-to-minute costs more). Suggestion made to create a collection of resources and examples drawn from other industries that can be used as basis for this type of discussion. Note: we may continue this as discussion thread on ProgrammableWeb or other means.
• Question: what’s the definition of a ‘commercial site’? Does running Google AdSense ads alongside of mashup make a ‘commercial’? None of the API providers’ terms of service list give a definition of this yet it’s often one of their constraints on use. Thus the onus shifts to the developer. Such as Google Maps TOS explicitly limiting free use if you are asking users to pay for access to your site that uses their API.
• Discussion about Terms of Service issues such as how often they change and can take effect immediately, thus catching developers off-guard.
• Balance of power: providers initially wanted to use APIs as a means encourage adoption, but have the real control at end of day.
• Issue: no API price listed, just ‘talk to us’.
• Traditional data providers are considering this market, but, it is a chicken-and-the-egg problem — they want proof of ROI in advance.
• What would be best practices from providers: we will provide notice in advance of shutting you off for TOS issue; grace period when TOS change.
• The “accidental business”. Often developers today don’t expect to build a more formal business. Try it out first, if successful, then we’ll deal with that later. Often these are handled on a case-by-case basis.
• A lot of mashup developers don’t understand risk factors: provider risks, terms of service, switching costs, data availability, etc.

For a bit more on this session and the camp see Stephen O’Grady’s post here.

Share This