

Exclusive interview with Joshua
« Kakarot », founder of QBCore
A few months before GTA 6 ships, the FiveM scene is bracing for a transition no one really knows how to read. Joshua, known online as Kakarot, is one of the few voices that can speak to it from experience. He founded QBCore, the open-source framework that today powers the majority of roleplay servers in the ecosystem. He agreed to talk to us.
A former PC technician and custom gaming-rig builder, who found FiveM by chance as a player, Joshua looks back with us on seven years of framework, on what made QBCore the standard, and on what, in his view, will survive when the ecosystem changes engines.

Can you introduce yourself and explain how you got into the world of FiveM and roleplaying?

« My name is Joshua, I grew up with technology as a constant in my life. Before QBCore I was running my own IT business, repairing computers, building custom gaming PCs, working with clients hands on. I wasn't a software engineer by formal title, I was just someone who understood systems deeply and enjoyed solving problems with technology. I actually found FiveM the same way most people did, as a player. I wasn't looking for a development platform, I was just looking for something interesting to play. But the more time I spent in that world the more I started seeing the gaps. The experiences server owners were trying to create were outpacing the tools available to build them. That gap between ambition and capability is what pulled me from the player side to the developer side. Once I started building I never really stopped. The same instincts that made me good at diagnosing a broken system or architecting a custom PC build translated surprisingly well into framework design. At the core it's all the same thing, understanding how components fit together and making sure the foundation is solid enough to support whatever gets built on top of it. »

How did your journey unfold leading up to the creation of QBCore?

« Before QBCore, ESX was essentially the only serious framework option and it had limitations that frustrated me as a developer. The architecture felt dated and it didn't give server owners the flexibility or performance they needed to build the experiences they were imagining. I started building tools to solve my own problems first, and eventually it became clear that what I was building was a framework in its own right. QBCore wasn't launched with a grand vision from day one, it was the result of solving real problems iteratively until something cohesive emerged. The turning point was when other developers started building on top of it and the community around it started forming naturally. »

Why has QBCore become so dominant?

« Honestly I think it came down to timing, architecture, and community. ESX had been dominant for a long time but it carried a lot of legacy decisions that were hard to work around. QBCore came in with a cleaner foundation, no database dependency for static data, more accessible player metadata, better performance for large servers. But the technical side alone doesn't explain the dominance. The community that formed around it was genuinely collaborative. Developers were building resources, sharing knowledge, and improving the ecosystem together. That network effect is what turned a good framework into the standard. »

Has this position changed your perspective or decision-making process?

« Significantly. When you start something as a personal project you make decisions quickly and for yourself. When thousands of servers depend on what you build, every decision carries weight you didn't sign up for. You become more conservative about breaking changes, more deliberate about documentation, more aware of how your choices ripple out to people you've never met. It taught me a lot about the responsibility that comes with building infrastructure that others depend on, something that has shaped how I approach engineering problems well beyond FiveM. »

How do you analyze the evolution of roleplaying on FiveM in recent years?

« The ceiling of what's possible has risen dramatically. When I started, a well-running server with basic job systems was impressive. Now server owners are building full economies, legal systems, housing markets, and social ecosystems that rival the complexity of standalone games. The bar for what players expect has risen alongside the tools available to developers. QBCore was part of enabling that evolution but the creativity of the community is what actually drove it. Developers pushed the framework further than I anticipated when I built it. »

With GTA 6 arriving, are we heading toward continuity or a break with the past?

« I think it depends entirely on what Rockstar and the FiveM/cfx.re relationship looks like going forward. The roleplay community has proven it has genuine staying power, it survived years of uncertainty and kept growing. If modding support exists in some form for GTA 6, I believe the community will transition and rebuild. The people who built these ecosystems aren't going anywhere, they'll just have a new canvas. The break won't be with the community or the culture, it'll be with the specific tools and frameworks that were built on GTA 5's architecture. Everything gets rebuilt. That's not a death, that's an evolution. »

Where does QBCore stand today and how do you envision its place when GTA 6 releases?

« QBCore today is in a strong position, actively maintained, widely adopted, with an ecosystem of resources and developers that sustains itself. As GTA 6 approaches the honest answer is that no GTA 5 framework carries over directly. What carries over is the knowledge, the community relationships, and the architectural patterns. QBCore's legacy will be in the developers it shaped and the standards it set for how a FiveM framework should be built. Whatever comes next will be informed by what QBCore established. »

Are you working on strategies to anticipate the GTA 6 transition?

« The transition is something the community is collectively thinking about. The smartest thing any developer or server owner can do right now is invest in understanding the underlying principles rather than being dependent on specific implementations. The patterns that made QBCore work, clean separation of concerns, event-driven communication, modular resource design, those are transferable regardless of what platform comes next. My focus has shifted toward broader game development, which puts me in a good position to contribute to whatever the next generation of this ecosystem looks like. »

What makes you most proud of QBCore's journey?

« That it outlasted my direct involvement. The fact that in 2026, developers are still maintaining it, building on it, and writing tutorials for it without me driving it, that's the truest measure of whether you built something real. Any project can survive while its creator is tending it. The ones that matter keep going on their own. Beyond that, the developers who cut their teeth on QBCore and went on to build serious careers, that matters more to me than any metric. »

What message would you like to convey to server creators and developers today?

« Build with intention. The FiveM ecosystem rewarded people who approached it like real engineers rather than hobbyists, and that's true of any platform. If you're a developer, treat the work seriously, the skills you build here are real and transferable. If you're a server owner, invest in understanding your stack rather than just consuming resources. The servers that stood out weren't the ones with the most scripts, they were the ones where someone actually understood what they were building and why. »

What were the most challenging moments and what advice would you give those starting out?

« The hardest part was never the technical problems, it was the weight of community expectations with no compensation, no team, and no obligation to continue. Open source maintainers carry a burden that users rarely see. There were periods where the volume of issues, pull requests, and community demands was genuinely unsustainable for one person. The advice I'd give to anyone starting out is to set boundaries early. Define what you will and won't support. Build in public but protect your time privately. And don't let the community's dependency on your work become your identity, because the day you need to step back, that identity becomes a cage. »

Bonus, parallel projects?

« Beyond QBCore I've been working in Unreal Engine, applying the same architectural patterns that shaped QBCore, event-driven systems, scripting layer design, API frameworks, to commercial game development. It's been a natural evolution from what I built in the FiveM space and has reinforced that the underlying principles of good platform engineering translate across any engine or environment. »
