As you know, I have been a fan of Clay Christensen’s work. His theories have helped me understand situations more than once. As I was reflecting on what was happening with one of the recent popular opensource projects, I kept coming back to VCE Theory.
Value Chain Evolution (VCE) Theory:
The core of VCE is that as a vendor in the early stages of a tech, companies must control the activities along the Value Chain either through direct control or very tight integration. They should also avoid unpredictable “interdependencies “ between activities. Example: For container tech to be adopted, the company pushing it must also control the underlying tech or rely on a proven tech. So, for a container run time, example of a proven tech is VMware, where a decent integration suffices. Example of a “not good enough yet” tech is the new breed of lightweight OS offerings. A container tech company must control the “what is not good enough yet” tech to ensure that their customers are getting the expected performance.
To summarize: Tightly integrate to improve what is “not good enough” and outsource what is “more than good enough”.
This will cause friction in the value chain participants that have “not good enough yet” technology, typically innovative tech that’s not proven fully and is still evolving.
Taking container company as an example, if they try to opensource the entire value chain, they will have no option other than to adopt a modular architecture and allow other players to integrate activities in the value chain. This means the user experience and customer expected performance will suffer. This is not a good outcome.
To summarize: Building entire value chain using opensource does not deliver optimal customer experience and it fails.
There are 3 options for them at this point to recover:
1. Integrate with what is good enough. In this case, VMware is more than good enough and declare it the Gold standard for running containers.
2. Own everything in the value chain. This will be a gutsy move. Go closed/single source on every element in the stack including orchestration, clustering, registry etc.
3. Give up complete control of the container tech to a foundation like Linux foundation. Compete on building a complete product using this “true” opensource container tech.
I see #1 as the safest move but reduces the excitement and overall TAM. #2 is the boldest move with highest rewards. #3 may be too late.
What are your thoughts? What other options do you think exist?