You can’t Git clone a team
Let’s get this out of the way first: yes, mastering the entire software stack is technically hard. You can read why in my previous post:
Olivier Lambert
But let me tell you something even more terrifying—it’s humanly hard.
You’re not just fighting against CPU cycles or kernel panics. You’re fighting entropy, demographics, and a universe that seems hell-bent on making deep tech careers as attractive as a root canal.
This post is a bit of a side quest from my usual rants. Think of it as an important footnote with its own personality—kind of like when you discover the appendix of a book is where all the juicy bits actually are.
The myth of the full stack master
Sure, on paper, you might think “Hey, with enough coffee and willpower, someone can understand everything from the hypervisor to the orchestration layer!” But here’s the thing: coffee can only do so much. The real problem isn’t just complexity: it’s people.
The kind of expertise needed to build and maintain an entire virtualization stack is… rare. Like unicorns-with-a-GitHub-profile rare.
We’re talking about skills that span kernel-level programming, hardware quirks, low-level debugging, distributed systems, security, orchestration logic, even the capability to work with the UI/UX team... and the ability to explain all that without scaring interns. You can’t just hire for that. You have to grow it. Nurture it. Beg for it. Or in some cases, resurrect it.
Meanwhile, in the aging Open Source village...
Let’s look at the real-world landscape. In many low-level or system-related open-source communities, the average age of core contributors is steadily increasing. These folks are still sharp as ever, but they’re the same people as 10 or even 20 years ago. They’re aging. Just like vintage wine. Or your favorite PHP-based web panel.
But unlike wine, contributors eventually move on, retire or just burn out.
The problem? There’s not enough fresh blood coming in. Why? Because system-level stuff just isn’t sexy anymore. Not when you can train an LLM to roleplay as a pirate therapist in five lines of Python.
Hypervisors aren’t boring (even if you think they are)
Somewhere along the line, we decided hypervisors and other infrastructure pieces were "commodities." Neat little boxes that Just Work™. But they aren’t. They evolve. Hardware evolves. Security threats evolve. And pretending they’re frozen in time is a great way to get blindsided.
Worse, our education system often skips over this layer entirely. Many students don’t even know what a hypervisor is unless they trip over it while tinker in their home lab (if they have one!).
We’ve created an ecosystem that barely acknowledges the complexity of the invisible scaffolding that powers the modern world. And that has consequences.
System teachers: now rarer than RGB-free laptops
This lack of visibility creates a pipeline problem. Fewer students interested in systems. Fewer professors teaching systems. Fewer projects getting contributors. Less knowledge passed on. The whole thing spirals until the only person left who understands the bootloader is also the person holding your CI pipeline together with duct tape and an old Bash script.
Even when students are interested, many universities struggle to find anyone who can teach low-level concepts deeply. It’s not just a talent shortage—it’s a teaching shortage.
What we’re doing about it (before it’s too late)
Alright, enough doom. Here’s what we’re doing—and what you can do too.
🧭 Scouting early
We work with universities to identify system-minded students as early as possible—ideally by their third year. Internships (ideally 6 months long) help them get hands-on and figure out if they like wrangling real system bugs instead of just writing code that compiles.
Sometimes all it takes is a good internship for someone to fall in love with this field. (We call it “Stockholm Syndrome,” but the productive kind.)
🧪 Partnering with Universities and Research Labs
One of the coolest things we’ve been lucky enough to do is partner with real academic research teams—shoutout to the brilliant folks at the KrakOS team in Grenoble. This kind of collaboration opens doors you simply can’t unlock with in-house devs alone (even the caffeinated ones). It gives us access to PhDs and labs tackling tough, high-impact problems—like combining security and performance in a hypervisor, which is kind of like asking for a cake that’s both gluten-free and delicious. Spoiler: it's possible, but only if you're willing to invest in cutting-edge research. These partnerships are gold—not just for solving thorny technical issues, but also for building long-term knowledge transfer loops between academia and industry. Everybody wins: we get smarter products, students work on real-world problems, and the knowledge doesn’t get lost in a dusty Git repo.
By the way, we pushed to create the latest Xen Winter Meetup at Grenoble university, and it was a great success. You can read a recap in here:
Olivier Lambert
🐼 Partnering with the Xen Project
We’re also teaming up with folks from the Xen Project to explore ways we can bring more contributors—and especially juniors—into the fold. Think of it like a mini Google Summer of Code, but with more hypervisors and fewer T-shirts (unless we fix that too). Xen has actually been part of GSoC in the past, so there's precedent—but to make it work, we’ll need to put together a solid framework: topics, mentors, reviewers, all the behind-the-scenes magic. It’s some effort, sure—but the kind that pays off big time. And through Vates, we’re all in to support, promote, and help make it happen.
📣 Make your project sexy
Having a good community manager or evangelist is crucial. You need someone to showcase why this tech is cool. Show people real-world impact. Present talks at conferences. Make infrastructure look like the superhero it is.
Also: reach out to companies using your software. Get them involved upstream. Yeah, it's not easy. Upstream-first doesn’t always align with quarterly revenue goals. But it's worth pushing for.
🧰 Lower the contribution barrier (without sacrificing quality)
Projects like Xen have high standards (as they should), but we have to work hard to make contribution more approachable. That means better docs, cleaner tooling, clear guidance for new contributors. Otherwise, great ideas from outside the core team never make it upstream—and we lose out.
👨🏫 Find the mentors too
It’s not just about students. You need experienced engineers willing to mentor. These people are even rarer than the students. Job ads alone won’t cut it—you need networks. And sometimes, recruiting firms that specialize in deep tech can actually help, especially if they understand what you’re building.
💸 Revenue = Resources = Reality
Let’s be honest. This whole plan only works if you have the resources to fund it. None of the above comes cheap. But ironically, money isn’t the main bottleneck in system engineering—it’s availability of talent. Still, without revenue, you can't attract or retain the right people.
That’s why—coming from a former sysadmin, mind you—I’ve learned to appreciate sales and marketing. Because without them, you can’t fund the team. And without the team, you can’t build the product. Even if you have a brilliant idea and all the determination in the world, you can’t staff an elite ops crew on passion alone.
The stack is hard. People make it possible.
If you want to build and maintain a real full-stack system (and I don’t mean web dev’s idea of "full stack"), you need people. Not just smart people. The right people. From the enthusiastic intern to the seasoned architect.
It’s not just about code. It’s about culture, community, and continuity.
And it starts by making sure the next generation even knows this world exists.
Member discussion