July 2008

"The Web was originally designed to be mashed up. The technology is finally growing up and making it possible."

Aaron Boodman, Greasemonkey creator

The TIM Lecture Series provides a forum that promotes the exchange of knowledge between university research and technology company executives and entrepreneurs. Readers outside the Ottawa area who are unable to attend the lectures in person are invited to view upcoming lectures in the series either through voice conferencing or webcast.

On June 11, 2008, Michael Weiss from Carleton University delivered a presentation entitled "Open APIs, Mashups and User Innovation". This section provides the key messages from the lecture. Michael's lecture examined the structure of the mashup ecosystem as well as implementation issues, including licensing.

User Created Value, Open APIs, and Mashups

The first section of the talk focused on the value provided by mashups where the innovation comes from the self-interest of users instead of from the application designers. Successful mashups change the economics of innovation as the value isn't in the applications per se, but in providing contexts for interaction. Moreover, opening the underlying API (application programming interface) creates unique value as differentiation to under-served users. This differentiation can occur in the long tail and allow users to help themselves.

With mashups, the focus is on adding value rather than learning a new language or investing time in coding an application. The value provided needs a clear demarcation point between free and monetized content. The Freemium model isn't the only, or necessarily the best, monetization model.

Mashup risks include: i) dependence upon API sources; ii) becoming a victim of an open API which isn't open source: when the API disappears, the mashup becomes useless; and iii) if mashups are so easy, how do you differentiate and attract users? While no mashup has been patented yet, there are companies trying to patent mashups. Licensing still needs to be ironed out for combining data and it needs to be understood in simple terms. For example, Google's terms of service does not allow you to use their APIs with their ads removed. This brings up the issue of API licensing and the fine line between enabling in order to create value while protecting your monetization. There is also a need for research mashups to find research knowledge.

When opening an API, it needs to be simple and well documented. As to support required to release APIs, you need to create well documented tools with constrained functionality in order to reduce usage errors.

Other key messages from this section included:

  • client side mashups eliminate the need for n-tier infrastructure
  • Jakob's Law implies that instead of spending money on web design, you should spend effort on getting linked everywhere
  • the programmable web has nearly 800 APIs to choose from

Small is the new big. Start small and then attract content. Even Google started small--it was able to leverage its value as it grew.

User Innovation & Mashup Ecosystem

The second half of the lecture provided many practical considerations when working with mashups. Key messages from this section included:

  • start with an under-served niche as these are your early adopters
  • start with well established APIs
  • mashup early and often and see what attracts users
  • mapping the mashup ecosystem offers important insights into introducing your own API or mashup
  • you can become a victim of your own success if mashup becomes popular; Twitter suffers from this problem of providing reliable infrastructure to handle traffic requirements

While tools are available to visualize APIs and mashups, it is hard to tell whether or not mashups are refactored over time from the data at the programmable web as many refactored mashups are shown as new mashups.

Users should be aware that mashups do not deal with inconsistencies in data. In the future, service level agreements (SLAs) can be used to provide reliable data.

Mashups may be a backlash response to the complexity introduced by web standards. This can also be seen in that Resource Oriented Architecture usage is outstripping SOAP.

After geospatial, the next big thing in mashups will probably be social networking. However, maybe the next big thing is not a particular application category, but the use of APIs and mashups as a way of creating extensible products.

Finally, licensing combined data is a yet unsolved problem. Mashups may provide a way to launder data as its original source becomes harder to trace as it goes through various mashups.

Recommended Resources

Case Study: Mashups Interoperability and eInnovation

Why Mashups Matter

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!