RobustMQ Is an Exploration
Lately I've been thinking: "We have lots of ideas, but code progress doesn't seem that fast. Are we thinking too much and doing too little?"
I thought about it. That's not quite right: Thinking is on the road, code is on the road. Thinking is fast, code is slow. These don't conflict—they reinforce each other.
Thinking Moves Faster Than Code
Since RobustMQ started, we've written many technical articles: on storage engine design, on multi-protocol unification, on AI scenario exploration, on our vision of being definers rather than followers. Some see this constant flow of ideas and feel our direction keeps changing.
Actually no. Our core direction has been clear from day one: build an All-In-One unified message platform. That vision has never changed.
What changed were the details of design and the path of implementation.
At first we thought "support multiple protocols," then deeper thinking revealed that the key isn't simply supporting many protocols—it's designing a protocol-agnostic unified kernel. At first we thought "do MQTT first, then Kafka," then we realized we should design the kernel first, with MQTT as the first validation scenario. At first we thought a unified storage layer would suffice, then we found different scenarios have too different needs—we had to make storage pluggable.
Engaging with AI scenarios showed us new technical validation directions. Thinking about being definers rather than followers clarified our positioning. These are adjustments and refinements at the detail level—but the core goal of "unified message platform" has never wavered.
Thinking is fast because ideas can iterate quickly. Today we have a design, tomorrow we find problems, the day after we adjust. That's normal and necessary. Before writing code, more thinking and adjusting helps avoid wrong turns.
Thinking is exploring the optimal path, not wavering.
Code Is Written Line by Line
We've been implementing the MQTT protocol for almost two years, and it's still not at 100%. It's not that completing MQTT takes that long—most of our time went into thinking about how to implement our kernel more solidly, how to go further. Constant refactoring and adjustment. The storage engine framework is being built, every abstraction repeatedly refined. The multi-protocol unified kernel—hand-written line by line, every design decision validated.
Why so slow? Because we're building foundational software; every line of code must stand up to scrutiny.
Performance must be optimized to the extreme. Stability must withstand production validation. Architecture must support future evolution. All of this takes time—testing again and again, optimizing again and again, polishing every detail.
Code is just that slow. But this slowness is necessary, the unavoidable path to good foundational software.
The Cycle of Thinking and Practice
Fast thinking, slow code—this isn't a contradiction but a virtuous cycle.
Thinking guides practice. We think the storage engine should be pluggable, then we implement it. During implementation we discover problems with interface design, performance guarantees, error handling—these problems drive us to keep thinking, to improve the design.
Practice validates thinking. We believe multi-protocol unification is the right direction, but is it really feasible? Only code can tell. When we implement MQTT on the unified kernel, we find which abstractions are reasonable and which need adjustment. Code is the most honest feedback.
Friction generates new ideas. We write our thoughts into articles and share them. Some agree, some question. "Your direction is too aggressive," "Won't pluggable storage hurt performance?" These responses make us rethink and adjust.
It's an ongoing cycle: Think → Practice → Friction → Adjust → New thinking.
Our ideas start out immature, full of uncertainty. But through continuous thinking, practice, exchange, and adjustment, we gradually mature. We stay open, keep sharing ideas, accept questions and suggestions, and advance through friction.
Patience Is Our Weapon
We're not a fast-to-commercialize project. We're exploring something that might be right.
Fast rollout is possible. Pick a mature direction, build "Kafka in Rust," and you could have something in six months. But that's not what we want. We want to build something truly different—something that defines new standards, something that builds differentiation from the kernel up.
That takes time. Lots of thinking, trial and error, adjustment. Exploring multiple directions to find the right path. Polishing every core component to perfection.
So we give ourselves a long runway. No rush to results, no rush for outcomes. Patience is our weapon.
Thinking will be fast—maybe new ideas every month, shifting focus every quarter. But code will be slow—maybe one protocol completed per year, maybe months spent optimizing a single core module.
This rhythm of "fast thinking, slow code" is exactly what we need. Fast thinking keeps us correcting direction; slow code makes every step solid.
Being on the Road
We don't know where RobustMQ will ultimately end up.
Maybe multi-protocol unification will be validated as right and become a new standard. Maybe we'll find some ideas impractical, need to adjust, and eventually fail. Maybe we'll find a breakthrough in some scenario and build influence from there.
We don't know where the destination is, but we know we're moving forward.
Every thought corrects our direction. Every line of code validates ideas. Every piece of feedback tells us right from wrong. Every adjustment brings us closer to the goal.
This is an exploration, not executing a plan. We'll stay open-minded, adjust based on reality, admit mistakes when we hit walls, pivot decisively when we find new opportunities.
But one thing won't change: We're seriously doing something meaningful, doing technology the right way.
Building differentiation from the kernel, hand-writing every critical line of code, finishing one protocol to 100% before the next, continuously sharing ideas for validation—these principles we'll stick to.
The Process Matters More Than the Result
I hope these articles show the complete process of going from zero to one in thinking and implementing ideas. This process matters—perhaps more than the final result.
How do we think about architecture design? Why choose compute-storage separation? How to weigh pluggable storage? How does the multi-protocol unified kernel abstract? What problems did MQTT implementation encounter? What discoveries in AI scenario exploration? The thinking behind every technical decision, the reasons for every direction adjustment, the challenges of every implementation step—we're happy to share.
Maybe in ten years, RobustMQ will become what we hope. Maybe it'll become something else—but something fully thought through and validated. Maybe we'll succeed. Maybe we'll fail. But as long as we're on the road, we don't lose.
Success or failure isn't something we can force. What we can do is think carefully about every technical problem, write every line of code solidly, accept every piece of feedback openly, adjust every direction honestly.
Look up at the stars, keep walking the road. The stars are our direction; the road is the present. We'll keep walking.
RobustMQ is exploring possibilities for the next generation of message platforms. Clear direction, patient execution. Follow us on GitHub to witness this long-term exploration.