Coopetition, commercial opensource free software and the 'channel'
"Much of the ability to create and maintain valuable brands, as a consequence, has migrated away from the product and to the channel because, for the present, it is the channel that addresses the piece of added value that is not yet good enough" The Innovator's Solution, Page 164-165
Introduction
It was the year 2000 and in May I was working in Manhattan for e-Vantage, a recently-acquired UK middleware startup that was selling consulting and body-shopping consultants on IBM MQ and Websphere technologies. The bubble had not yet burst but there was a 'smell' in the air and savvy consultants were no longer looking for share options and wanted cash as an incentive to join organisations. The labour market was significantly under-supplied and it was a seller's market.
My job was to develop business in the North American market and primarily leverage the IBM premier partner relationship with their global services team to help them deliver projects by providing the human resource. My second remit was to explore new business beyond this. In the process of meeting various companies I realised that the challenge of the 'bench' and having the right people was preventing these service companies from winning new business.
In early June I had various meetings with senior executives about the concept of cooperation and collaboration between a group of service companies, the premise of this was that if we shared my/our human resources we'd improve utilisation, get the right people and deliver more projects. It was an example I would later come to realise was atypical of co-opetition.
In 1996 Adam J. Brandenburger and Barry J. Nalebuff published a book titled "Co-opetition", the term was first coined by Ray Noorda, the founder of Novell. Co-operation with competitors is called “co-opetition,” a contraction between cooperation and competition, meaning that we are competitors but we cooperate. I read this book sometime between 2002 and 2005 and was inspired and enthused by what I read. I'd rather not get into reviewing the book right now and the comments at Amazon.com should be a nice teaser. I do highly recommend reading it and gaining a grasp of what is discussed in terms of 'game theory' and 'added value'. I've mentioned the book as it has had a significant influence and further inspired the ideas I'm about to share.
During the decade of 2000 I spent a considerable amount of time on software product marketing, working with Michael Hart (an expert on channel sales development), witnessing the finesse of the Microsoft marketing machine and supporting the DotNet platform evangelism team. This exposure to the extent of support a vendor can provide their 'channel' as well as witnessing the collaborative style of Michael further fuelled my thoughts, experience and passion for the concept of co-opetition as I moved ever-closer to the open source ecosystem.
At the end of the decade I had the fortune to consult to Mark Darby, author of Alliance Brand, who established a system for channel metrics based on his MBA research. My favourite take-away from my work with Mark was one of the things he used to often say which was "all boats rise together".
Let's fast-forward to DrupalCon 2009 where I took the opportunity to meet Dries Buytaeart, the founder of Drupal and discuss co-opetition in the Drupal ecosystem. My point to Dries was that we witness phenomenal collaboration at a product level in the drupal community i.e. hacking code, creating documentation, providing translations, sharing designs etc.; what is missing is the "elephant in the room" for the commercial open source ecosystem: where is the collaboration amongst the commerical people, what are the commercial / business people doing that imitates their technical / product peers' ability to collaborate successfully? I was impressed that Dries grasped my point immediately and after a brief moment of contemplation he expressed to me what I suspect many people believe. To paraphrase... Dries said this is a difficult subject because of the competitive nature of business and the agendas of each and every entrepreneur in the ecosystem to win business. With that said I think the commercial open source ecosystem is missing quite a few tricks here and it's time to wake-up and acknowledge that the opportunities far out-weigh the risks people perceive. [I promised Dries and later Kieran Lal that I would elaborate further in a whitepaper I was going to write though sadly I did not get this done, as it happens today is the day I am rectifying that promise, in part].
Sometime later a respected blogger, the VAR guy, put finger to digital ink and wrote a blog post to Matt Asay during Matt's tenure as Canonical COO about how to further commercialise Ubuntu. I couldn't resist to chime in with my perspective on what is missing in terms of a unified, collaborative channel strategy and fostering that ecosystem.
At the end of March 2011 Florian Piroth and Jean-Pierre Navarro from Intel were on the Paris leg of their roadshow reaching out to the global ISV community, their modest goal being to facilitate collaboration in their ISV ecosystem and invite external ISVs to join them. Once again I took the opportunity to soundtest my thoughts on collaboration with Florian, I was pleased to get rather positive feedback from him. This has been the catalyst for me writing today as I promised to share my notes on this subject with Florian - thus I can't keep on promising and should now write this up.
A few days back, one Saturday afternoon, I grabbed the opportunity to make some notes which I think help create placemarkers for the various aspects of co-opetition which I will share below:
Co-opetition
There's that old adage "what's in it for me?", let's expand on that...
- What can you do for me ?
- What can you do for us (my commercial ecosystem) ?
- What can I do for you ?
- What can we (my commercial ecosystem) do for you ?
- What can you (your commercial ecosystem) do for me ?
- What can you (your commercial ecosystem) do for us (my commercial ecosystem) ?
- What can we do for them ([your and my] our clients) ?
- What can they ([your and my] our clients) do for us ?
What do we want to hear in response to those questions?
- Time to market
-
Responsiveness (to...)
- client needs
- partner needs
- organisation needs
-
Competitive intelligence
-
awareness
- market intelligence
- challenges / constraints
- components / products / services
-
best-practices
- business processes and artefacts (such as contracts, policies)
- product / service / organisational management
- talent management
- etc.
-
awareness
-
Quality
- fit-for-purpose
- fit-for-use
-
Experience
- satisfaction
- brand awareness / perception / penetration
Goals of co-opetition
This is obvious, huh!?
- Increase revenues / profits / marketshare
- Protect / defend market(s)
What will drive 'increases'
-
client demand
- changes in client needs
- changes in client market
- changes in client governance (organisational change inc. M&A)
- supplier / partner
- product / service innovations
-
internal (organisational) optimisations
- productivity improvements
- cost and material improvements
- legislation
- organisation structures / governance
-
organisation
-
capabilities
- execution
- client / partner services
-
reputation
- perception
- brand
- quality
-
capabilities
Co-opetition is SHARING
Why share? See above re: goals :-)
What to share? What are the assets that an organisation can share?
The commercial open source free software ecosystem can (and some already do!) exploit collaborative marketing by co-developing collateral such as working on whitepapers, producing benchmarks, documentation and training materials that feature complementary open source solutions as part of the solution stack - providing visibility to decision makers of what the solution stack consists of and how to engage this in a professional relationship. Co-sponsoring events, adverts etc. to raise the profile and visibility of open source. In my role at OW2 I proposed the idea of OW2 projects preparing presentations for Solutions Linux 2010 that featured cross-project collaboration taking place in the OW2 community, "Partnership Success Stories" was a great success and very well received by the audience.
Other assets we might consider sharing takes us back to the question of what can be offered which is discussed above such as the points listed under competitive intelligence. For example providing the ability to share service level agreeements, contract templates and sales workflows are just some of the artefacts and knowledge of an organisation that could reduce time, cost and improve quality for other vendors in the market which in turn improves the perception and adoption of commercial open source free software.
So, ultimately is there a way for organisations to collaborate on lead-generation - how can the open source free software ecosystem learn from the lessons of co-opetition and their product / technical peers to drive sales by collaborating on the lead-generation, pre-sales and account management processes? How can complementary and synergistic channel strategies be developed that improve the execution and quality of service provided by these vendors?
... and that's where I've got to thus far on this quest of co-opetition amongst open source free software entrepreneurs.
Thanks for reading. Do comment below!

I liked the article. It helped me re-structure my knowledge about co-opetiton since I'm still learning about the subject.
I have a question: from what I understood, in a co-opetition several companies form an ecosystem to cover for each others' weaknesses and market their strengths together. Is that right? Does that mean that no two firms with conceptually identical products (like two ERP provider company) can be in the same ecosystem? If yes, there will no competitions at all and it will be more of an alliance not an ecosystem.
Now if my last assumption is wrong, would you please elaborate on how that scenario is possible?
Thanks,
--
Bahman
Two firms such as ERP vendors can come together to collaborate while still competing, they might faciliate the evolution of common open standards in ERP technologies as part of a membership in an industry body.
They might work on some co-funded integration work with another open source component to improve market reach.
Where they can choose to be more bold is to prepare a general campaign on ERP and co-fund this to improve visibility of ERP solutions, prepare collateral that promotes the benefits of ERP and share the cost, distributing it to their respective targets and using the combined knowledge of their organisations in the creation of the content.
The ERP companies could share their sales contracts (perhaps redacting pricing first), share their service agreements, even inform them of bad customers to protect the other company from the risk of having a costly client to service.
A more far-reaching partnership might even be an agreement to pass leads from one territory to another where the local vendor has a greater presence and ability to support the client, though that is much less of an issue with today's internet. That said, if ERP A has a better knowledge of the automobile industry than ERP B then ERP B might work with ERP A to deliver a better solution to their client(s). The point here is to be creative in how one finds and leverages the value available.
The relationship to co-opetition is the added-value of collaborating as opposed to not collaborating, which encompasses the choice to form alliances as part of the process of co-opetition where the added-value is greater in doing it than not doing it which provides the incentive to do so i.e. to create value.
Post new comment