Q: Is over-vendoring when you’ve had to much to drink?
A: Yes, too much Kool Aid.
There’s a lot of information here – skip to the bottom if you want to see my recommendation.
Last week on TheNewStack, I offered eight ways to keep Kubernetes on the right track (abridged list here) and felt that item #6 needed more explanation and some concrete solutions.
- DO: Focus on a Tight Core
- DO: Build a Diverse Community
- DO: Multi-cloud and Hybrid
- DO: Be Humble and Honest
- AVOID: “The One Ring” Universal Solution Hubris
- AVOID: Over-Vendoring (discussed here)
- AVOID: Coupling Installers, Brokers and Providers to the core
- AVOID: Fast Release Cycles without LTS Releases
What is Over-Vendoring? It’s when vendors’ drive their companies’ brands ahead of the health of the project. Generally by driving an aggressive hype cycle where vendors are trying to jump on the hype bandwagon.
Hype can be very dangerous for projects (David Cassel’s TNS article) because it is easy to bypass the user needs and boring scale/stabilization processes to focus on vendor differentiation. Unfortunately, common use-cases do not drive differentiation and are invisible when it comes to company marketing budgets. That boring common core has the effect creating tragedy of the commons which undermines collaboration on shared code bases.
The solution is to aggressively keep the project core small so that vendors have specific and limited areas of coopetition.
A small core means we do not compel collaboration in many areas of project. This drives competition and diversity that can be confusing. The temptation to endorse or nominate companion projects is risky due to the hype cycle. Endorsements can create a bias that actually hurts innovation because early or loud vendors do not generally create the best long term approaches. I’ve heard this described as “people doing the real work don’t necessarily have time to brag about it.”
Keeping a small core mantra drives a healthy plug-in model where vendors can differentiate. It also ensures that projects can succeed with a bounded set of core contributors and support infrastructure. That means that we should not measure success by commits, committers or lines of code because these will drop as projects successfully modularize. My recommendation for a key success metric is to the ratio of committers to ecosystem members and users.
Tracking improving ratio of core to ecosystem shows that improving efficiency of investment. That’s a better sign of health than project growth.
It’s important to note that there is also a serious risk of under-vendoring too!
We must recognize and support vendors in open source communities because they sustain the project via direct contributions and bringing users. For a healthy ecosystem, we need to ensure that vendors can fairly profit. That means they must be able to use their brand in combination with the project’s brand. Apache Project is the anti-pattern because they have very strict “no vendor” trademark marketing guidelines that can strand projects without good corporate support.
I’ve come to believe that it’s important to allow vendors to market open source projects brands; however, they also need to have some limits on how they position the project.
How should this co-branding work? My thinking is that vendor claims about a project should be managed in a consistent and common way. Since we’re keeping the project core small, that should help limit the scope of the claims. Vendors that want to make ecosystem claims should be given clear spaces for marketing their own brand in participation with the project brand.
I don’t pretend that this is easy! Vendor marketing is planned quarters ahead of when open source projects are ready for them: that’s part of what feeds the hype cycle. That means that projects will be saying no to some free marketing from their ecosystem. Ideally, we’re saying yes to the right parts at the same time.
Ultimately, hype control means saying no to free marketing. For an open source project, that’s a hard but essential decision.
Rob Hirschfeld 