the Onda

Adam, who is out at Mashup Camp, has been trying to get me to think about mashups for a while now. I think more than anything it's been the fact that he was willing to get into a tin can and fly 3,000 miles to an ad-hoc "camp" that has me finally getting over my "yeah but we did this 10 years ago with Perl scripts" bigotry and really trying to suss this out.

Before I get to where mashups click for me though, I should mention that it's nice to see that even while inhaling that west coast vibe, Adam has stopped to think about the fact that with the exception of Amazon, source component providers like Google, Ebay, and Craig's List don't have a real clear economic incentive to continue providing their data and compute cycles for free beyond a certain yet-to-be-determined point. This is a very valid and important observation which Peter Rip picks up in a nice post on the challenges associated with building a mashup-based business.

Now one might argue that allowing for core functionality to be exported serves a real long tail purpose. People who mix up Google Maps with anything else are perhaps the best example of this-- after all, while one could argue that the Google Maps team may have seen apps like Housing Maps coming, there is certainly no way they saw the Jacktracker (an intensely enjoyable site for 24 fans). I think the long tail argument is good (as is Eric von Hippel's related user-led innovation argument) but I think that mashups provide these big source service providers an even bigger benefit: the ability to attract an audience for their core functionality that is way out of the swath inhabited by their average user: the geeks.

Geeks are amongst the more discerning and most marketing-proof people you can find out on the web today. They're also among the most passionate, and with the emergence of the blogosphere, they are definitely the most vocal. Businesses have been built on the hypothesis that understanding geeks really matters. And yet, trying to build an application that has high geek appeal and that also serves a large market of "regular" users can be a bad idea for one of two reasons: either the application already exists and has won their hearts and minds (think photos and Flickr, bookmarks and del.icio.us) or it is just too far out there to have any sort of "regular" person appeal.

Exposing core functionality in the form of an API that facilitates mashups cuts this Gordian Knot in a productive way. It makes a potential service provider focus on what's really important and differentiable with an influential and discerning crowd. And at the same time, it lets the product team focus a more tightly integrated web application on the core constituency.

And so, here's what's been most useful to me about trying to get my head around the impact of mashups: thinking through the hypothetical of when geeks might want to mash up parts of what we're working on. It encourages clarity (in terms of what it is that is unique) and enforces modularity (so that we can easily export this core functionality without going crazy). And most importantly, it gives us hope of finding a nice way to serve two equally important (but very different in terms of needs) audiences.

Post a comment