The CNCF just celebrated its 10th anniversary. What started with Kubernetes and around twenty member organizations has grown into an ecosystem of over 230 projects and 300,000 contributors. It's also, for most platform teams, the first place things go wrong.
The landscape is the parts bin
If you've seen the CNCF landscape diagram (the one that tries to show every project in the ecosystem), you know the feeling it produces: not inspiration, but paralysis. It's the parts bin at the world's biggest hardware store, organized by category and completely silent on what you're actually building.
The projects are real, the communities behind them are doing important work, and many of the tools are excellent. Excellent and interchangeable are different compliments, and the landscape diagram doesn't tell you which one you're looking at. It shows you what exists. It doesn't tell you which combination works at production scale, on your cloud provider, with your team size, without subtle incompatibilities you'll discover six months in.
So platform teams evaluate. They read documentation, run proof-of-concepts, compare tools that were built to solve slightly different versions of the same problem and therefore can't quite be compared on equal terms. This phase doesn't show up in any project plan. It appears later as slippage: timelines that keep moving, roadmap items that keep getting pushed, and a growing sense that the foundation is taking longer than expected.
It is taking longer than expected. That's the pattern across nearly every team that builds a platform from scratch. The CNCF landscape is where the delay starts.
The community has noticed too
PlatformEngineering.org, the community most associated with evangelizing the discipline, recently announced they're building a consultancy to help teams navigate platform adoption. You can read that as straightforward professional services. You can also read it as an acknowledgment that the complexity of getting from "we should do platform engineering" to "we have a functioning platform" is significant enough to warrant an entire advisory practice.
That's not a knock on the community. It's evidence that the selection and integration problem is real, recognized, and not getting simpler as the ecosystem grows.
Vercel's CPO Tom Occhino framed the underlying pattern directly in a recent interview: almost every company building platform infrastructure is doing work that's fundamentally undifferentiated. The plumbing is generic. The differentiation lives somewhere else: in the products, the services, the things that actually face customers. Every week spent evaluating whether to use tool A or tool B instead of tool C is a week not spent on the work that compounds. We'd add one thing to that: undifferentiated work doesn't announce itself as undifferentiated. It shows up disguised as due diligence.
Choice requires a decision framework to be useful
Without a decision framework, more tools just add noise.
To turn 230+ projects into a production platform, you need to know which combinations work: not in theory, not in a proof-of-concept, but under real load, across upgrades, in the environments your workloads actually run in. You need to know which tools fail in subtle ways six months after deployment. Which upgrades break assumptions made by adjacent components. Which configuration choices made early constrain choices you'll want to make later.
That knowledge doesn't live in documentation. It accumulates through operating these systems at scale, across many environments, over years. The CNCF's own Q1 2026 Technology Radar, released at KubeCon EU in March, shows which tools developers are standardizing on. That's useful. It still doesn't tell you how they interact at production scale in your specific environment. In our experience across 150+ production clusters, the 6–12 months to production most teams experience doesn't start when they write code. It starts when evaluation does.
This is what curation actually means. Not picking popular tools from a list (anyone can do that), but making defensible choices about combinations, having tested those choices under conditions that resemble production, and knowing when the landscape has shifted enough that a previous choice should be revisited.
The honest trade-off
The CNCF ecosystem isn't the problem: its projects are the foundation of every serious cloud native platform, including ours. The community-driven development model produces tools that proprietary vendors simply can't match for depth, transparency, and rate of improvement.
The argument is narrower: abundance is only useful with selection. The landscape gives you the raw materials. What you do with them (which ones you choose, how you combine them, how you keep that combination healthy over time) is a separate problem, and it's a harder one than the landscape diagram suggests.
If you want to understand what that problem costs once you're past the evaluation phase and into the build and operational phases, the follow-up post breaks it into three distinct components. Each one has a different shape, and each one requires a different response.
The CNCF landscape is the parts bin, sorted better than most and still just a parts bin. The hard work starts when you try to build something specific with it.
