Mashups vs. Gnashups and The Dangers Of Google As Platform

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Mashups vs. Gnashups and The Dangers Of Google As Platform


From Wikipedia:  A mashup is a website or web application that seamlessly combines content from more than one source into an integrated experience.


From Dharmesh Shah:  A gnashup is a mashup that eventually causes gnashing of teeth because the developer thought she was building a viable business, when in fact, she was really conducting a controlled experiment for the benefit of Google and others.


Mashups are all the rage.  Many new startups are creating applications that leverage available web applications that provide APIs (like Google Maps).  These mashup applications put together pieces of web functionality like search, mapping, photos, news, shopping, etc. into a single, composite application.  These applications weren’t easy to construct “back in the day” as the web services required to power them simply didn’t exist.  Now, more and more companies are making interesting web services available for the aspiring mashup developer.


So, what do I have against mashups?  Nothing.  I think mashups, as a concept, are a fine thing.  As a user, I find them fun and interesting (and sometimes even useful).  My issue is that from an entrepreneurial perspective, too many mashup startup founders seem to be working under the misguided notion that they’re building a viable business – when in most cases, they’re not…


Here are my issues with mashups, and what might cause them to become gnashups. 


  1. Dependencies Abound:  At the heart of the mashup is the use of one or more “key” services that make the mashup possible.  In essence, the mashup depends on the existence of a set of web services in order to work.  If one or more of these services becomes “unavailable”, everything breaks down.


  1. Lack Of SLAs (Service Level Agreements):  The above dependencies wouldn’t be so bad if you could somehow have assurances or guarantees of certain “uptimes” and availability.  But, in most cases, there is no such guarantee.  In fact, many of the available services mashup developers use today can’t even be “purchased” (i.e. paid for), and hence there is little motivation for the providers to offer guarantees or assurances.


  1. No Good Way Of Dividing Up The Value:  Assuming that there was some possible business model here (I’ll put on my simple business guy hat and suggest that you might actually charge for your application someday), its still unclear how the value gets divided up and who gets paid what.  Even if you’re building a revenue model on advertising, how do the other service providers make any money?


Absence Of Malicious Intent Is Not Enough:  One of the common arguments I hear from mashup developers is: “Hey, Google has no motivation to cut me off.  They’re running a multi-billion dollar business.”.  I could even support this argument further by noting that part of Google’s core philosophy is “do no evil”.  However, as it turns out, this doesn’t really mean much.  


For example, lets assume you were writing an application for Microsoft Windows.   This application would be “consuming” software services (core operating system features) through an API and doing (hopefully) interesting things.  Sound familiar?  Remind you of mashups?  That’s because it’s a similar concept.  Software developers have been using third-party platforms and services for a long, long time.  Now, here’s what makes this interesting:


  1. Microsoft doesn’t know who you are:  When you write Windows applications, there’s no registration process.  You can simply buy the tools and build your app.
  2. Microsoft doesn’t charge you (directly):  There’s no “tax” to you as the software developer.  Microsoft makes its money from the customers that buy Windows.
  3. Microsoft doesn’t charge the customer (extra):  People that are buying your application don’t pay more for Windows.  More importantly, Microsoft can’t charge customers extra for using your application.  This is subtle, but critical.  Stick with me.  


Now, lets explore this a bit.  What if Microsoft made you “register” with them before you could develop Windows applications and use their API?  What if Microsoft could (from a technical perspective), turn off your access to their platform at will?  What if Microsoft could charge you a different fee for access to the Windows API than your competitors?  What if Microsoft could charge its Windows customers more if they are using your product vs. someone else’s?  Would you write Windows applications?  I certainly wouldn’t.  It’d be hard to build a business in these circumstances that was going to succeed beyond a certain point.  The other party (Microsoft) would have too much power.  [Note:  I’m going to be writing about strategic partnerships and dealing with 900 pound gorillas in a future article].


That’s the situation we have now with mashups that are based primarily on Google and similar platforms.  Back in the day, even if Microsoft hated your guts, it was very, very difficult for them to do anything about it, because if you were selling applications running on Windows, they had no real control over you as a developer.  Their software was already running on millions of desktops, and they couldn’t easily change it just to spite you.  Even then, companies like WordPerfect and Lotus felt vulnerable because Microsoft could have an unfair advantage over them. 


In a Google mashup world, lets see where we as developers stand:  They make APIs available.  But, to use their API, you have to register with Google and get an account.  Not a big deal.  Easy enough to do.  But, here’s the catch:  Every time your application does anything with the API, it’s getting implicit approval from Google to do so.  Though they don’t (currently) have any motivation or incentive to cut you off,  they could if they wanted to.  They could also charge you a fee, if they wanted to.  They could charge their customers a fee for using your product, if they wanted to.  They have the ability to perfectly price discriminate (a neat economics concept I learned at MIT) if they wanted to.  As such, your destiny is in their hands.  Sure, they’re likely a benevolent dictator, but as a business guy, that doesn’t give me the warm comfies (my own term, I didn’t learn this at MIT).


What surprises me most is that the same community of developers that is pushing for open standards and open source (Linux, PHP, Ruby, etc.) is also the same community of developers that at some level is willing to build on a closed platform where the platform provider has complete control.  What am I missing here?


Moral Of The Story:  Putting too much power in the hands of a few doesn’t seem particularly prudent for software developers and startup founders.  We shouldn’t let the current wave of innovation cloud the need for sound business strategy.



Posted by on Tue, Apr 18, 2006


Very true, but it isn't really a big deal. If Google were to become less benovlent, you could just switch to another service. They're not the only game in town. Yahoo's mapping API is also excellent. MapQuest also provides an excellent enterprise API that you can pay for if you're interested in the kind of service guarantees that you referred to.

posted on Tuesday, April 18, 2006 at 7:11 PM by Anonymous Joe

As for Microsoft not having control, you're forgetting that they have perfect control over what comes preinstalled with the OS and machines get upgraded every two years or so. They can deliberately kill backwards-compatability for certain APIs when they feel like it and replace an app with a preinstalled one. The only way you can win is to not compete with them on their terms, i.e. don't make office suites etc.

The same goes for Google et al; they'll humor you as long as it drives traffic. The two reasons I can think of for which they will kill you are either if you have too much control over the data, or if you are taking too much of the "pie". The reason they give APIs is to increase dependence on their data, not benevolence.

The value of the mashup depends on whether it is the "portal" for the information. A search engine is just a big mashup and the reason it is valuable is that it acts as a portal for "everything". I, as a website owner, have perfect price discrimination ability towards them but they have pricing power, because they control/channel demand.

If you, in your mapplication mashup, were likely to achieve a position where you can "channel demand", the platform provider loses their power and that's when they'll likely kill you.

posted on Wednesday, April 19, 2006 at 3:48 AM by Johan

Open standards and open source software do not equate to open platforms/services. They actually foster closed platforms/services. Open source software and cheap hardware has significantly reduces the cost in building and deploying closed/proprietary platforms.

Everyday a new web based service comes online. These new “platforms” may be developed on open source software and implement open standards but they are closed. Why, because you cannot “open source” a service. With a service there is no source code to “open up”. The service is consumed and that’s where the open standards come into play. The open standards allow for closed platforms to communicate thus again prompting more closed platforms.

The business models of these platforms are evolving. I believe this is where there is much room for innovation and where opportunities exist.

posted on Wednesday, April 19, 2006 at 9:07 AM by Dean Fragnito

Great thoughts! I have blogged something similar on my blog about SOA and Web 2.0.

While implementing SOA in the enterprises we insist on SLAs even between departments or vendors despite having much more control, we ignore this issue on Web 2.0. Though it's still an evolving story, perhaps there is a reason for this. As a Web 2.0 entrepreneur you are immensely benefiting from the services provided by others, and they will keep you afloat as long as it makes sense for them. As long as there is a healthy ecosystem of these services with competition and motivation on providers side this will continue to exist. And when there will be an imbalance, the market will figure out a way e.g. paid services, SLAs, advertising etc. So, if you have an interesting idea for a mashup just go for it, there is nothing you can do about the current situation. There might be some bumps ahead in the road, but it would be an adventurous ride nonetheless:-)

posted on Tuesday, May 23, 2006 at 9:06 AM by Abhishek Balaria

Yes, yahoo, google amazon technorati all give their API to developers. But they are not charging for using the API to avail their service. They just restrict the number of queries per day sent using their api. So in short their service is also just like open source platform, Am I right?

posted on Friday, June 08, 2007 at 9:46 AM by peterson from cheaphealthstore blog

Comments have been closed for this article.