When we talk about a Mashup we are talking of a website that utilizes one or more web services from one or more Web Service Providers, often in an innovative, interesting or unique manner. If you have seen ProgrammableWeb.com or Mashupfeed.com then you already know that mashups are being added pretty much on a daily basis. But don’t expect to create a website mashup and quit your day job just yet. Two major concerns with these mashup developments are:
1) Are they feasible as a long-term business plan?
I have classified Mashup trends into two types: Short-Term and Long-Term.
Short-Term Mashup
- No real business model or marketing plan.
- Showcases “cool” or new technologies simply because they exist.
- Usually does not add any value or content beyond the original data provided.
- Usually consumes 2 or more web services.
- Initial high spike in traffic, but is soon to be forgotten.
Long-Term Mashup
- Healthy relationship and contract with the Web Service Provider.
- Has a well thoughtout business model, possibly with investors or venture capital backing it.
- Generally adds value or content beyond that of the Web Service.
- Traffic is more stable, as users return because the mashup is useful.
2) Who really is in control of it, the developer or the service provider?
Of course the service provider is in control, they are providing you with critical information. But this does not imply the mashup developer is hung out to dry by any means… There is more to it than that…
I came across a blog entry by John Musser over at ProgrammableWeb titled Mashups Not In Control. It caught my eye, being a “mashup developer” myself. Anyway, he cited Richard McManus’ recent entry on ZDNet, titled Mashups: who’s really in control?
In it Richard states,
“In the mashup ecosystem, let’s get one thing straight. The data owner is ultimately in control, because a mashup developer is reliant on data owners to keep the supply of data flowing.”
Yes, that is correct. That is why it is important to have not only have a healthy relationship, but also a contract with the Web Service provider. While most developers click “I Agree” and just dive into working on things, it can be all for nothing if the web service provider does not feel the developer is utilizing the data in a useful manner.
Richard also goes on to say,
“So it seems that putting a heavy server load on the data source, particularly if you’re profiting off it but not giving anything back, is likely to land your mashup in trouble.”
I don’t really know what to say… If you are a developer doing this, and haven’t been booted, you should be. Mashup developers must remember, a web service isn’t some magic source of free content and data. A “web service” is still a service. If it is free, you bet the provider wants something in return. Traffic, exposure, revenue share… And if you are paying for the service, well then you are already giving them something in return- upfront. The web service is there so you and the web service provider can both profit from.
The keyword to remember in creating a mashup: partnership.
Technorati Tags: web2.0, mashups, web services, web service provider, developer, business model, business plan, venture capital, partnership
Comments(1) 
