Mashup vendors need to work with our frenemies or the bell will be tolling for us

I’ve had a nice long break over the holidays but now it’s time to roll up my sleeves, gird my loins and otherwise prepare to get back to work. And what better subject to start off the new year than turning enemies into friends, working with foes or partnering with competitors?

Gwyneth Dwyer has posted on this very subject. Back in the 90s we called it co-opetition. The new terms are frenemies and froes, meaning working with your competition, either on a deal-by-deal basis, or more likely, on a strategic basis as partners.

I’m sure the idea has been around since The First Floridians Met the Last Mastodons, but in the Web 1.0 dot-com era it surfaced again. The web was opening up everyone's horizons. It used to be hard for customers to find niche products, and for niche vendors to find customers. The web changed all that. With the web, little guys could not only innovate on a dime, they could get the attention of customers without going through an analyst firm. These same little guys didn’t have the pull to say ‘my way or the highway.' Back when TeamShare was a small vendor selling bug tracking software, customers used to insist we work with Rational, so of course we did. One day we'd work with them to promote our ClearCase integration, the next we'd be in fierce competition against ClearQuest.

Dwyer's post on the subject takes a collaboration spin. If you end up working with a competitor, and you likely will, be sure to set expectations, define boundaries, leave turf battles at the door, and finally, communicate, communicate, communicate. Sound advice for partner collaborations of all sorts, frenemies or no.

So what does this have to do with business mashups? I'm always asking that question. Sometimes the answer is obvious, sometimes obscure. In this case it's pretty straightforward. Co-opetition is at the very heart of mashups, whether the mashup vendors want it that way or not. Mashers don't care that some of their data comes from JackBe, some from StrikeIron hosted services, some from back-end SAP systems, all displayed on a GoogleMap and pulled together with process from Serena. Mashers care that they have accurate and timely data, widgets, and process from wherever they can get them.

Imagine trying to convince a masher that they could only use technology and content from a single vendor.

Oracle: I’m sorry, Mr. Masher, but you have to use the Oracle stack, Oracle applications and Oracle services to create your mashups.

Masher: Bite me.

Marketplaces and content aggregators like StrikeIron will have the upper-hand when it comes time for mashers to search for content. Kapow's open services will draw those same mashers. Will Kapow and StrikeIron work together or will they compete? The answer is ‘Yes.’

In a mashup world we are all connected. I’m reminded of a meditation about the island and the bell by John Donne. (Sure I’m taking it out of context, but I’m a masher as well as a blogger.) “No man is an island, entire of itself; every man is a piece of the continent, a part of the main.”

We in the mashup ISV world have to change to that mindset. We not only need to make our services open and usable by mashers, but we need to work together, defining standards to make it easy to mash content. It's not enough for us to publish our APIs. As I've discussed in a previous post, we need to work with other vendors on security standards, quality metrics and semantic vocabularies so mashers can pull content from pages painlessly. If we don’t do it, somebody else will, and we will wake up some day to find that we know exactly for whom the bell is tolling.

So JackBe, ready to let me review your software yet?