We donated bpfman to the CNCF. We expected it to change how the project grew. It didn't - at least not in the ways we hoped. This is the honest version of that story.
The donation process
The CNCF sandbox application is less technical than you'd expect. The hard part of bpfman was always the engineering; the donation process was almost entirely governance and paperwork.
IP assignment. A governance model - maintainer ladder, voting process, how decisions get made. A code of conduct. A clear statement of who the maintainers are and what their responsibilities are. Contribution guides. The TOC asks questions about adoption trajectory and roadmap, but their main concern is whether the project is structured to survive without any single company controlling it. There are some fantastic templates available for this.
That last part is the real reason to donate a project to a foundation. Not marketing, not credibility - though those were things we hoped for - but neutral governance. A CNCF project doesn't belong to Red Hat, even if Red Hat built it. That matters for enterprise adopters who want assurance that the project won't be killed or forked the moment its corporate sponsor changes priorities.
Getting through the process took a few months. It was not the hard part of running the project.
What we expected
The theory of change was: donate the project → CNCF marketplace listing → discoverability → users → contributors. The CNCF has a large, active community. KubeCon is the biggest conference in the cloud native space. Getting the bpfman logo onto the CNCF landscape felt like it should mean something.
We expected:
- Users finding the project through CNCF channels
- Non-Red Hat contributors appearing, now that it wasn't obviously a Red Hat project
- Enterprise adopters being more comfortable evaluating it
- The wider CNCF community providing a pool of potential collaborators
What we got
The project got some additional visibility. The governance work was genuinely valuable - having a clear maintainer ladder and contribution process is useful. We had the opportunity to get a booth at the Project Pavilion at KubeCon Europe London 2024! I spent weeks on prep - making sure we had QR codes that linked to our docs pages, a list of good-first-issues, shiny limited edition stickers for any contributors. We had lots of interesting conversations, but maybe 1 in 100 of these yielded contributions.
The community didn't materialise at the scale we hoped. The same small group of people who had been maintaining bpfman before the donation were maintaining it after. External contributors appeared occasionally, made isolated contributions, and moved on. Nobody new joined as a sustained collaborator.
The CNCF didn't fail us. Our theory of what being a sandbox would give us was incorrect.
The actual problem: solving something people didn't know they had
bpfman addresses a real gap - the previous posts in this series explain what it is. But "real gap" is not the same as "felt pain."
Most teams using eBPF in 2023 were either using a single program loaded by a single tool (no multi-tenancy problem), or they were inside a large vendor who had built their own loading infrastructure (no distribution problem). The people who would benefit most from bpfman were the ones who hadn't run into the problems it solves yet.
You can't market your way past that. A CNCF badge doesn't create urgency in someone who hasn't felt the pain. Conference talks help - they show people what's coming before they hit it themselves - but the adoption loop is slow when the value is prospective rather than immediate.
We were, I think, a couple of years early. However, I'm confident that we will one day see a privilege escalation bug or similar through a popular tool that uses eBPF and then people will pay attention.
The unglamorous reality of maintainership
The thing nobody talks about in open source maintainership posts is motivation. Motivation is easy when PRs are landing, issues are being filed by engaged users, and there's a visible community forming around the project. It's hard when the repository is quiet.
Maintaining a project with low external engagement is a different activity than maintaining one with high engagement. The work is similar — reviewing code, fixing bugs, evolving the API, keeping the CI green - but the feedback loop is much weaker. You're making judgment calls about priorities without the signal that external users provide. And in the worst case, you're YOLO merging your code because no-one else is showing up to review it.
I don't have a clean solution to this. What I found is that the work itself needs to be intrinsically motivating, and the team around you matters more when external community isn't providing energy. The colleagues I built bpfman with were genuinely good - that's what kept it going.
What I'd do differently
If I were starting a project aimed at CNCF donation today, I'd treat community building as a parallel workstream from day one - not something that happens after the project is "ready." That means writing for discoverability from the start (docs, tutorials, worked examples), identifying the handful of other projects that have the problem you're solving and making integration easy, and investing in the human relationships that eventually become contributors. In fact, I'd go a step further and suggest that before even writing a single line of code that you find several other people that are feeling the same problem, acutely, and are motivated to solve it with you.
The governance and process stuff is worth doing regardless of community size. It forces you to be explicit about how the project works, which is valuable even when the only people following the process are the founding team.
And CNCF membership is a good thing, but it's a signal of maturity, not a growth engine. Don't rely on it to build your community for you.