Some Problems with Mashups

Reader warning. This is a long, potentially boring discussion about mashups.  Mashups are a geeky new web development activity that fascinates me and a small community.  If you don’t know or care about mashups, don’t waste your time reading this.

There is tremendous interest in the developer community in the concept of mashups.  The upcoming and oversubscribed Mashup Camp, and its derivative Mashup Camp II, and Mucho Camp are all signs of the attraction of the idea of re-mixing Web data into new, richer user experiences. 

I, too, am fascinated by the promise of mashups.  (I didn’t quite move fast enough to make the 300 signup cutoff for Mashup Camp.)   But I see some real problems in turning mashups from an interesting parlor trick into a real business. 

Let’s begin by differentiating a mashup-as-feature from mashup-as-business.  Mashups as Features (MAFs) are great, but I suspect this is not why developers are so taken with mashups.  By a MAF I mean a feature like visualizing houses or jobs on Yahoo maps.  This is useful, but is really just a feature of a classifieds user experience.  This is logically equivalent to a click-to-call integration -- useful, but not a standalone economic activity. 

I have yet to see any “mashup” that is anything more than a MAF and I think there are several important reasons why.

Problem 1 – Can you add value?  Mashups sit on the shoulders of others.  The components of the mashup are real, substantial applications by themselves.  Ebay is a business (as in Ebay mashed with Yahoo).  Craigslist is a business (as in Craigslist mashed with Google.)   To be a Mashup as Business, the new business must add value beyond the value created by the sources.   That added value could be new proprietary data or new proprietary logic or both.  Merely joining two existing sources doesn’t add enough value to build a business.  It’s like buying hard disks, CPUs, and motherboards at Frys and trying to be in the computer business. Mere assembly of components is convenient, but not worth much, unless you're Michael Dell.

This is the challenge in mashing together consumer services.  Can you add enough value?  Have the sources left enough room for you to add value? If you have a proprietary new data source, you could integrate with other data sources and build a new experience.   Zillow is but one example, using tax assessor data to estimate home values.  Your value add is your data, not the data integration. If the data are not proprietary, e.g. job listings, you may be better off finding distribution channels for the data (syndicating the data) rather than mashing it yourself.  If the data are proprietary, e.g. sellers’ reputations (Ebay), then their value greater within a captive experience. 

Problem 2 – Can you build real applications? Developing a proprietary data source is a high cost route to differentiation.  The lower cost, tried and true route is proprietary process or application logic.  Integrate 4-5 web sites into a proprietary consumer experience.  This sounds straightforward.  But there are two key problems.  First, you can’t do this integration easily with browser-based technologies.  Polling data sources with AJAX is one thing, but executing application logic and maintaining state across sources is another.  Tracking long-running transactions is just too much bookkeeping to do client side.  Even if you did suffer the pain of doing all this in the browser, a large part of the source code to your application logic is now potentially downloaded by every user everywhere in the world!

Problem 3 – Consumer processes are simple. OK, even with these problems still you’ve decided to build a new consumer application mashing together four sites with your own application logic.  The next problem is the inherent triviality of most consumer processes.  Consider the following illustration.  I am buying a house.  The process is complex  --  house search, investigate neighborhoods, loan search, qualify, apply, etc. But how many people want a site to thread all these into a single process?  Which do you do first? The consumer choice process is to optimize each step serially, not globally optimize the process.  The real problem with consumer mashups a business is that consumer’s processes are rather simple, making it hard to add process or logic value.  If you disagree, do your own thought experiment.  Can you imagine four sites you visit where what you do on one depends on the results of the prior sites? That dependency is called process.  If you have counter examples, I'd like to hear from you.

Problem 4 – Consumer business models are tough on mashups.   I have written on this before.  When you use someone else’s API you become a reseller.    That is to say you provide distribution to their service.  Most web services don’t have business models for their APIs because they don’t have reseller business models, yet.  Consider the language in the API for Last.fm as a classic example of the conundrum. 

If you're trying to do anything remotely high-traffic, we'd very much appreciate a heads-up first. We don't have infinite resources to support this. 

Last.fm is not unique.  Google’s API FAQ contains the following:

Pricing Questions
1. Does it cost anything to use Google Web APIs?
No. This is a free beta service. However your program is limited to issuing 1,000     requests per day to Google.
2. Does Google have any plans to sell Google Web APIs as a service?
Not at this time.

So how would I build a custom music search experience that mashed together music search (Last.fm)  with concert search (Tickets.com) with web search for band member information (Google) with a group calendar (Trumba) and an invitation engine (Evite)?   Be successful, just not too successful.

I am also a huge advocate of the beauty of quick and dirty over never and elegant.  Mashups are quick and dirty SOA.  Let’s wave a wand for a moment and assume enterprises actually were buying software solutions from small companies again.  Then the enterprise would be a wonderful petrie dish for mashup businesses.  Processes are more complex, the alternative of deep integration is too brittle and expensive, and business models are clearer.  Mashup Siebel and Google Maps and Skype-In into a customer self-service application.  Mashup Great Plains and Salesforce and Fedex into a customer RMA/package tracking solution.   This will happen. And when it does, mashup technologies are going to do to enterprise applications what the PC did to enterprise computing – move the solution to the edge where quick and dirty has more value.

This may all sound like I am a Luddite about mashups.   Far from it.  I am bullish as can be. These problems are some of the biggest opportunities.  We have made four investments in the past year in and around mashups. And we expect to make more. A company that has an innovation to solve any of these barriers is likely to be a big important company in the evolution of the Web stack because the re-mixing of the Web is inevitable.

PS. A reader of this post named "Long Ago Y!" (a former Yahoo product manager) has another take worth noting if you are a developer playing with APIs

Mash ups and open API's allow goog and yhoo to get their integration ideas and product R&D done on the cheap. Open the API's, let people build mash ups and watch what happens. The cool apps, yhoo and goog will go and build themselves (they might buy out the developers, they might not), the lame ones? Free market research. Free prototype development and testing.

Worth noting.

Comments

[Peter Cranstone]

Thank you for an excellent article. I have a question – could you do a follow up piece that shows how you can evolve a business model from mashups that show “measurable, sustainable, profitable revenue from volume?”

I understand the volume aspect of mashups – lots of clicks. What I don’t understand is how “you” get paid. Essentially you are borrowing (leveraging) someone else’s work (content) mashing it with other borrowed content to provide new “content”.

As your business grows – you consume other people’s resources to sustain your business. I’m not sure this is a win-win. Maybe you could develop a micro-payment system that includes them in the transaction?

Secondly there is the issue of content – what happens when the other person turns off access to the content and in turn partners with someone else ( a competitor) to supply them with the necessary feed?

I can see a mashup as a service from someone who “owns” all of the content. FedEx, UPS etc. There are lots of better ways to join data together and make it more meaningful to the customer. However it’s their data – they can give it away for free, but can you charge for it?

Don’t get me wrong – mashups are cool. Maps and Restaurants all on the same page. Awesome – but what’s the revenue model? Advertising – works great on a desktop device – however on mobile the rules change – there real estate is precious so only “local” search results will count and who makes that decision on what to display and how to display it.

Prior to starting my latest business I took a serious look at mashups. My conclusion was this – great idea – but I couldn’t think of a sustainable business model that people would pay for.

That’s really the critical question I’m seeking an answer too. Content is almost free – bundling more, nearly free content together doesn’t change the price – just the convenience factor. If I don’t click on an Ad then how do you keep the lights on?

Thanks.

[walter]

...Even if you did suffer the pain of doing all this in the browser, a large part of the source code to your application logic is now potentially downloaded by every user everywhere in the world!

This is an interesting point because the best web applications - the applications that will scale (from a performance POV) and might be worth VC investment - are those which are client-loaded (where application logic and IP is in Javascript). Tim Bray has an interesting post that points the way forward for future web applications. While the implications for the Web-at-large are good - it doesn't look so good for VCs looking to protect IP investment.

[Long ago Y!]

I ran a product group at Y! in the late 1990s. In those days the mantra was innovate and then integrate throughout the network. Build a quote site, add links for quotes in biz news stories. Build a movie listing site, add listings to My Y!. That was simple to do when we were only a few hundred people. By the time I left (right near the peak in 2000), it was much more difficult to work this way. There was a lot of internal politics and a lot of friction between groups.

Here's my take on mash ups... Mash ups and open API's allow goog and yhoo to get their integration ideas and product R&D done on the cheap. Open the API's, let people build mash ups and watch what happens. The cool apps, yhoo and goog will go and build themselves (they might buy out the developers, they might not), the lame ones? Free market research. Free prototype development and testing.

[Don Geddis]

"Can you imagine four sites you visit where what you do on one depends on the results of the prior sites?"

Travel planning may be the best example. When trying to put together a vacation package, for example, I'm optimizing a multi-variable problem, each variable of which is accessible at different sites. What airline/times/prices do I want? Which city am I going to? On what dates? Are tickets available for the Broadway show on that date? What if I arrive later, and go to the museum instead?

A human travel agent used to help with some of these things, but they all lost out to self-service booking on the web. Only, now it's much more difficult to assemble custom vacation packages.

I don't know how to make a mashup out of this (much less whether it would be a good business, since your other comments still apply). But I've definitely tried to plan a trip myself, and wound up with four or five windows open at the same time, all at various stages of completing a transaction. When I finally put together a complete plan, I then want to finish each transaction at once.

[John Furrier]

Great post. We're at Mashup camp podcasting. It is a dynamic environment but I believe something very surprising will come out of mashups. A very positive trend in the developer community.

[Carl Hodler]

As Mashups become more widespread in the commercial environment we'll not only see companies offering enterprise level web services, but also the development of applications specifically for use in the commercial Mashup environment. The money will be in the companies that are producing applications, hosting the data and managing the services, due to the scope of revenue opportunities that are open to them.

[Jeff]

Check out iRadeon's AppPortal... http://www.iradeon.com ...an open source web app mashup with a subscription revenue model.