Implicit Web Service Contracts

Mashups are all the rage these days. People are going gaga over the veritable explosion of possibilities associated with leveraging multiple online services in tandem to deliver a unique class of derivative services. Programmable Web, the popular Web 2.0 developer destination, has over 500 mash-ups listed that leverage 178+ listed web services. From what I can tell, there are roughly 1-3 new mashups being created everyday. Maybe more importantly to some enterprising developers is that some very large VCs are paying very close attention.

Although this new breed of application is undoubtedly exciting, there are still a couple of issues that require some serious thought from the community - especially surrounding the use and monetization of constituent web services. A number of folks, such as Peter Rip, have started to address issues surrounding the complex ecosystem associated with mashup development, but there is a long way to go as the Global SOA begins to emerge.

One set of issues that has consistently come up - aside from business models – surrounds the obligations of service providers to their developer communities. In other words, "What if Google decides to pull the plug on the service you are using to create your mashup?" It is an interesting question and, frankly, a fair one. The short answer is, "I dunno." If Google, or some other provider, decides to cut the proverbial cord then mashup developers will be forced respective application. As an aside, this actually does not affect things too much with our platform. More on this to come. That being said, however, that scenario is pretty unlikely to happen - especially the longer the service is actively supported and available online. Why, you ask?

Implicit Web Service Contract - when a service provider posts an API online for use by the developer community, that action results in the formation of an implicit agreement with developers, or "contract," that promises a certain level of platform availability. In other words, I as the developer will create some value-added mashup application using your platform, but you as the service provider have to ensure some level of availability with respect to the service, or else.

Google Local (Maps - back in the day) has maintained an open API for some time now. As a result, a number of developers have created applications that leverage this API to deliver services with unique value propositions, such as HousingMaps. If Google was to decide that – one day – they were better off releasing their own set of "Mashups" to replace incumbent maps mashups and shut down their API, there would probably be hell to pay. Hundreds of angry developers that invested their valuable time and energy to create services would be screaming bloody murder as they marched through the Valley with signs saying "Do No Evil My @$$"

Ok, so maybe that is a bit extreme. But seriously, once a community develops around an API it is pretty hard to take down the service, or even change the API, without serious repercussions. The networking affect is huge and developers are an unruly lot. If a service provider, like Google, were to even change an API in a way that impacted developers negatively, some developers might consider walking away. It goes without saying that they would definitely think twice before using any other service(s) that the Goog made available. Not only would the move disenfranchise developers, but it would also damage the brand reputation of the service provider on the open web with early adopters. For anyone who knows the web, alienating those two communities represents a serious transaction cost with a very real bottom line impact.

So service providers beware - publishing an API is a great idea if you want to transform your service into a true platform, but walk carefully as making changes to your Implicit Web Service Contract can result in some rather expensive waves.

technorati tags:mashup, implicitwebservicecontract, web2.0