The intangible aspects of mashups matter most

National Public Radio had a really good story yesterday about Platial and the Google Maps world of mashups.  Putting aside the fascinating aspects of this heretofore previously obscure phenomenon being increasingly spotted in mainstream media, the story actually got a lot of the spirit of the mashups world right.  As part of this, I've been looking at the various mashup APIs and components, watching how they get used, and also which ones are getting adopted most and why.  Some interesting trends have begun to emerge.

All of these actions made the mashup community believe in Google as a supplier to their Web sites and businesses.It doesn't take much to realize why mashups can be so valuable.  It's the sheer array of high value services that are available now which is driving it.  This includes the millions of available RSS feeds on the Web, which contain simple, structured data of literally every possible description. Or the advanced APIs from companies like Salesforce and Amazon, which can let you easily add functionality to your Ajax Web applications that originally cost someone a large fortune to develop.

Understanding the two major ways Web components can be mashed up is important to understand how they work.  When I wrote recently about the emerging world of Web components, I described how they are available for creating composite online software either 1) in the browser or 2) as a Web service somewhere out on the Internet.  Reusable brower-side components are often for visual elements, though they don't have to be, while server-side components are primarily sources of information used to power the software in the browser.  For example, Google Maps is a single-line browser side Javascript include that, once loaded in the browser, then talks to a Web service to load subsequent mapping information.

But the technology pieces are really only a small aspect of the mashup world.  Two intangible elements stand out as key forces. And tellingly, it's the exact same set of organizational forces that SOA efforts have to contend with inside the firewall as well. These elements are trust and credibility. As a mashup component supplier, having both of these in large supply is essential to get people to establish a long-term relationship with you.

There's been a spate of analysis recently trying to figure out why Google is the preminent component vendor of choice for location mashups.  Even when being there first is factored out, there were things Google did early on to encourage something it didn't initially expect (Google did NOT expect Google Maps to be used for mashups at all, but now it embraces it wholeheartedly.)

For one, once people started remixing and blending Google Maps into their online software, Google didn't harass them, ask them to stop, sue them, or anything else.  Google actually did the opposite and decided to take advantage of the phenomenon.  It began encouraging mashup developers by officially permitting the mashup of its Google Maps client, and they even created a proper software development kit complete with documentation.

Notably, Google also encouraged commercial uses, making it possible for people to start building real businesses (like the aformentioned Platial) around Google Maps. This so-called right to remix is essential for Web 2.0 style software to flourish, particularly as commercial ventures. Finally, Google's implementation of Ajax was one of the best examples in the business, making it clear they were the leaders and the right folks to be dealing with.

All of these actions made the mashup community believe in Google as a supplier to their Web sites and businesses.  And most continue to believe Google is the thought leader in this space, giving them enormous credibility with the development community most inclined to do this sort of work.

This is vital because it's pretty darn difficult to utterly and completely depend on others to always be there and always do the right thing so your application (and your business) will thrive.  I've previously described this problem as one of having to depend on the kindness of strangers.  This is where the hitherto boring and IT-bound world of governance, Service Level Agreements (SLAs), and supply chain management comes in.  Not things you'd expect to have to worry about in the world of the Web.  But our growing Global SOA requires that we start thinking in terms of symbiotic relationships and communities as opposed to bastions of monolithism which can act autonomously.  This latter is a model for software supply which is clearly a receding one.

What intangibles do you think are the crux to building composite online software?