Sunday, March 26, 2006
Bashing Mash-ups
Everyone is talking about “mash-ups” as if the idea of combining two or more web information sources is revolutionary. It isn’t. Granted, thanks to web services and asynchronous JavaScript and XML, it is now possible for people who are not professional programmers to overlay local data to create intriguing applications using Google maps, Flikr, Firefox or other “platforms.” But there’s a continuum with standard XML schemas, WS-* specifications, and composite applications with choreography on one end and microformats (or roll your own tags), REST, and mash-ups on the other. No matter how clever the mashers get, enterprise applications are not going to be built that way. I don't think that SAP or Oracle think they are doomed because of mash-ups. They aren’t going to take over the earth.
I’m not opposed to the idea of mash-ups. Raymond Yee is teaching a new class this semester called "Mixing and Remixing Information” at UC Berkeley’s School of Information (where I also teach), and students seem to be having a great time in it, including those who didn’t enjoy more traditional computing courses. There is definitely great appeal for a user to mash-up in a couple of days an application that might have taken a real programmer weeks or months in the old days. But I guess I’m just “old school” because I still advocate substantially more systematic and analysis-intensive methods for designing and implementing web applications.
And I am truly amused whenever I hear that some mash-up has been acquired for some ridiculously large sum by Google or Yahoo or someone else. It’s like 1999 all over again when an interesting web site or even just the idea for one could pass for a business plan. I still have on the back of my office door one of Hal Varian’s classic monthly “Economic Scene” articles from the NY Times (from February 2001). It is titled “Comparing the NASDAQ bubble to tulipmania is unfair to the flowers” and ends with this:
The Internet was supposed to remove all barriers to entry, encourage competition and create a frictionless market with unlimited access to free content. But, at the same time, it was supposed to offer hugely profitable investment opportunities. You do not have to have a Ph.D. in economics to see that both arguments are rarely true at the same time.
So if a mash-up can be done with almost no effort, then it isn’t going to enable any sustainable business advantage. Smart entrepreneurs will avoid calling their composite applications “mash-ups” if they are looking for investors or acquirers.
-Bob Glushko
I’m not opposed to the idea of mash-ups. Raymond Yee is teaching a new class this semester called "Mixing and Remixing Information” at UC Berkeley’s School of Information (where I also teach), and students seem to be having a great time in it, including those who didn’t enjoy more traditional computing courses. There is definitely great appeal for a user to mash-up in a couple of days an application that might have taken a real programmer weeks or months in the old days. But I guess I’m just “old school” because I still advocate substantially more systematic and analysis-intensive methods for designing and implementing web applications.
And I am truly amused whenever I hear that some mash-up has been acquired for some ridiculously large sum by Google or Yahoo or someone else. It’s like 1999 all over again when an interesting web site or even just the idea for one could pass for a business plan. I still have on the back of my office door one of Hal Varian’s classic monthly “Economic Scene” articles from the NY Times (from February 2001). It is titled “Comparing the NASDAQ bubble to tulipmania is unfair to the flowers” and ends with this:
The Internet was supposed to remove all barriers to entry, encourage competition and create a frictionless market with unlimited access to free content. But, at the same time, it was supposed to offer hugely profitable investment opportunities. You do not have to have a Ph.D. in economics to see that both arguments are rarely true at the same time.
So if a mash-up can be done with almost no effort, then it isn’t going to enable any sustainable business advantage. Smart entrepreneurs will avoid calling their composite applications “mash-ups” if they are looking for investors or acquirers.
-Bob Glushko
# posted by Bob Glushko @ 5:48 PM 
Comments:
<< Home
I think the mashup culture will end up like the car culture.
Making a car is the hard engineering problem, as is creating a map or a flickr or an upcoming.org service.
On the other end of the spectrum, pinstriping/lowering/exhaust-modding is accessible by the average consumer, and millions do it. Seems like one in every 5 cars is mashed up these days, thanks to the tire, exhaust, paint, and suspension APIs provided by car makers.
Car manufacturers like Scion are embracing this and taking it to the next level (e.g. http://www.scion.com/culture/dashboard/).
In between are the facilitators who create products and know-how that can be applied by the millions. Some are serious entrepreneurs and businesses, some are hard-core hobbyists.
Like car culture, which I think is good for customers and good for business, re-mixing software is a good thing. So why bash them? Why burden folks with the need for a business model or a document spec? Let's let the culture broaden and fill out and find itself. There's room for the spectrum, from the commercial zillow.com to the semi-commercial weatherbonk.com to the fun project dudewheresmyusedcar.com. And everything in between.
IMHO the most important piece, and the one that Document Engineering aficionados should be jumping for joy about, is that the engineers behind xyz maps/flickr/last.fm/upcoming.org have found the room in their schedule and business models to created APIs in the first place. These days a new service without an API is an incomplete service. This is a huge shift from a couple of years ago and is a good thing from Document Engineering's point of view, no?
Making a car is the hard engineering problem, as is creating a map or a flickr or an upcoming.org service.
On the other end of the spectrum, pinstriping/lowering/exhaust-modding is accessible by the average consumer, and millions do it. Seems like one in every 5 cars is mashed up these days, thanks to the tire, exhaust, paint, and suspension APIs provided by car makers.
Car manufacturers like Scion are embracing this and taking it to the next level (e.g. http://www.scion.com/culture/dashboard/).
In between are the facilitators who create products and know-how that can be applied by the millions. Some are serious entrepreneurs and businesses, some are hard-core hobbyists.
Like car culture, which I think is good for customers and good for business, re-mixing software is a good thing. So why bash them? Why burden folks with the need for a business model or a document spec? Let's let the culture broaden and fill out and find itself. There's room for the spectrum, from the commercial zillow.com to the semi-commercial weatherbonk.com to the fun project dudewheresmyusedcar.com. And everything in between.
IMHO the most important piece, and the one that Document Engineering aficionados should be jumping for joy about, is that the engineers behind xyz maps/flickr/last.fm/upcoming.org have found the room in their schedule and business models to created APIs in the first place. These days a new service without an API is an incomplete service. This is a huge shift from a couple of years ago and is a good thing from Document Engineering's point of view, no?
So if a mash-up can be done with almost no effort, then it isn’t going to enable any sustainable business advantage.
So if I use an easy-to-use API, you can't have a sustainable competitive advantage, but if you use an XML document using an (let's say) oasis standard schema, that is somehow "better?"
Post a Comment
So if I use an easy-to-use API, you can't have a sustainable competitive advantage, but if you use an XML document using an (let's say) oasis standard schema, that is somehow "better?"
# posted by 
: 4:20 PM
: 4:20 PM << Home
