Core, Complement, and Context: Channeling Geoffrey Moore on Open Source
Geoffrey Moore wrote Crossing the Chasm in 1991. He might joke in his presentations that he's been milking the idea for 15 years, but it remains a classic. (I've lost a company in that chasm. It's real and real ugly.) In the book, he builds out a simple idea that a business can drive it's success by delivering a "whole product solution" to the customer, i.e. the core and all its complements.
When we say "core" here, we're talking about the "core value proposition". It is by definition customer facing. And there are a wealth of things one can do to provide all those complements. Based on experience at Microsoft, I would observe that one can:
- Use traditional buy-versus-build strategies through the vendor’s own brand, regardless of whether the complement products are offered as add-ons or bundled directly with the core revenue stream for “free”
- Develop a rich ecosystem of add-ons by encouraging developer and partner networks to provide a bigger whole solution
- Publish proprietary specifications enabling more partners to develop stable businesses in the complement spaces.
- Provide developer tools that help add complements to the ecosystem.
- Create certification programs around the core technology creating service professionals to help customers complete and support their solution
- Develop a consulting services arm for part of the solution
- Develop training programs and train-the-trainer certifications
You can see Red Hat and MySQL AB doing these things as well, as they grow their respective businesses. Free and open source software provides interesting new ways and opportunities to develop out the complement space. For example:
- To buy-vs-build you add “borrow” and “share”
- Companies that participate in communities
- Can rapidly develop complements to core offerings in their solution network (without necessarily building complete products)
- Can amortize dev/support/maint costs of complement components across customers/partners/competitors (e.g. IBM and Apache and Websphere)
- Get to interact directly with like-minded customer prospects in community, influencing customer/partner developers
- Companies that participate deeply in communities better influence those communities (e.g. participate, hire, or acquire)
- Companies can use open source projects to reduce the cost of sales by allowing users to try easily and pre-qualify themselves as customers
- Open source projects are an interesting publication strategy against competitors from an IP strategy perspective
- New companies with lower margin business models (compared to the incumbent) can use open source components to rapidly develop products that either serve new markets or serve the bottom end of an over-served market and then evolve over to or up into an incumbent’s market space
Over the years, Moore has delivered other excellent books, shifting from helping a company survive the chasm, to surviving its success in how to think about operational success and what they need to think about and do differently. (Indeed, this is what I love about both his work and Christensen in both the Dilemma and the Solution. They look at a company in the context of history over long periods of time in dynamic markets.)
Moore's latest is "Dealing with Darwin". Here he begins to contrast "core" with "context", and pleads the case that over time a company's core becomes context as they evolve. He drives towards a view of open source in his related presentations that encourages companies to make open source in areas of context. This is still great advice, BUT I would offer several caveats along the way:
- Here he's talking about "core competency/asset" not "core value proposition". The first is what enables the second.
- A core competency or asset is inward facing -- not customer facing like a core value proposition.
- Making open source as a vendor means different things to making open source as a consumer.
- Companies need to understand the difference between these two "core" ideas and do the right things in each space.
Examples obviously help here (and my apologies to each company for somewhat oversimplifying their worlds.)
Core value proposition: The ubiquitous desktop (now laptop) computing device for a "document" computing metaphor. (The historic message was wonderfully crisp in this regard: A PC on every desktop and in every home. Customers knew what they were buying and employees knew what they were building.)
Core competency/asset: Delivering a software "appliance" that runs on thousands of PC with thousands of devices attached, and successfully runs thousands of useful applications. The testing matrix cross product of the hardware compatibility list with the applications compatibility list requires extraordinary discipline, process, and capital. This also extends to the development side of the house. It's easy to get instant on/off to work on a Mac when there are about 20 Mac designs on the planet and you control the end-to-end UI through OS to hardware. Now think about it from the Windows dev team perspective and the 1000s of machines to be supported. (To be clear: I still own a Mac. I may be sympathetic to the engineering problem, but I don't have to live with it as a consumer.)
Core value proposition: The ultimate advertising machine in the web world. Remember the company's customers are paying for advertising. It's the TV network business model for the web.
Core competency: The ultimate search engine on the web. The asset/competency is the algorithms and people tuning/evolving it and the server farm on which it runs. (Again, just like Microsoft's capital investment in the delivery infrastructure, so to does Google have a reasonable barrier to entry here.)
It's really important to understand the difference here. You can't publish/share (and by extension "open source") your core competency. Google can't share the algorithms at the heart of their search engine today. Once they've "indexed all the world's information" and the data [über-annotated-indexes] becomes the core asset, then they might be in a position to consider it.
But this is also why I maintain that Microsoft could now publish most of their software using open source licenses to advantage -- including Windows and Office (were it legally possible). Their core competency today is actually tied up in the capital (human knowledge and physical) and processes that enable the Windows and Office distros and support to be delivered through the global channel, and no longer in the source code base itself. Microsoft could use open source communities to re-invigorate the franchises.