Image Source: Aggretsuko – Copyright belongs to Sanrio Co., Ltd.
Changing the world by sitting at home in front of a screen
First, I want to shed some light on my background.
I’ve been programming for about ten years, exploring many languages and projects across very different areas. But everything I did was entirely for myself — no collaboration, no feedback, almost no code that wasn’t written by me. I think you get what I’m trying to portray here.
What truly fascinated me from the beginning was operating systems. I started experimenting with them early on, and naturally, that grew into a deep interest in operating-system development and engineering. While I didn’t initially feel capable enough to contribute to a real OS project, I started reading and analyzing how they worked — how they transform bare metal into a usable interface for humans.
I began with Linux, but when I dug deeper into file systems, I quickly found its limits. My research led me to ZFS, which I discovered to be arguably the best file system available today. However, the licensing mismatch made running Linux on a ZFS root unnecessarily complicated. That’s when I found out that FreeBSD and OpenSolaris use OpenZFS natively.
Diving deeper into FreeBSD revealed a remarkably well-documented and elegant project — clean code, clear structure, and the kind of UNIX elegance I had been searching for. Before long, I had FreeBSD installed on multiple nodes and began experimenting with it, even writing my first little kernel module.
After reading through mailing lists, Bugzilla, and Phabricator, I finally gathered the courage to adopt my first port and start contributing. This was only three months ago — but it already feels like a journey.
When I learned that SchedMD had been notoriously difficult to work with regarding FreeBSD compatibility, and I was able to change that by pushing patches upstream and building strong relations, it hit me:
I was actually changing the world just by sitting in front of my screen.
And that’s an amazing feeling. My vision — to one day see data centers and research clusters migrate to FreeBSD — suddenly felt much more realistic.
Reality hits hard every day
Unfortunately, that ecstasy can quickly fade once real life comes knocking.
My biggest limiting factor is my work and studies. I’m currently pursuing a career in the pharmaceutical field, and I plan to combine that with my open-source work someday. In fact, I’m already laying the groundwork: I want to help universities and research clusters migrate to FreeBSD, creating a strong user base for high-performance scientific software — molecular simulations, protein-folding prediction, free-energy binding calculations, clinical modeling, and more.
But as you can imagine, studying pharmacy demands its own time and energy.
Combined with health issues due to a chronic medical condition, this can result in phases of lower open-source output — and right now, my development work is indeed stalling for those reasons.
Another aspect that’s always been part of me — and which I think deserves to be mentioned — is that I’m on the autism spectrum. It’s a double-edged sword, but one that ultimately led me here. My brain tends to hyper-focus on systems until I fully understand them; I can read documentation once and retain it for a lifetime if it’s something that interests me. That’s how I ended up diving into operating-system internals in the first place.
People sometimes tell me I sound a bit like a robot when I talk about technical things — maybe that’s true — but it’s also what gives me the precision and persistence I need for this kind of work. In a way, autism isn’t something that “gets in the way” of my open-source journey. It is the reason I’m able to pursue it at this level.
That focus — sometimes obsessive, sometimes exhausting — is also what made me see FreeBSD’s HPC potential so clearly. Where others saw “unsupported platforms,” I saw clean design waiting to be revived and integrated.
The night-hustler’s passion
Since open-source work is usually unpaid, most contributors have day jobs — and that means hacking at night. For me, that’s where errors sometimes creep in, simply from exhaustion. Luckily, that’s where the review process shines: reviewers have caught every fatigue-induced oversight I’ve made so far. It’s an incredibly valuable safety net that ensures my code is properly refined before it lands upstream.
It also helps me slow down. Waiting for reviews gives me forced pauses, preventing burnout or over-enthusiasm from turning into chaos.
Still, I’m far from perfect. I often keep multiple open fronts — trying to run at “steady mid-to-max capacity” so no time feels wasted.
During the day, I usually sketch my nightly To-Do list, which defines my mission before I log in. But sometimes, my expectations are bigger than my capacity. And those nights — when tasks remain unfinished — are the hardest ones to end.
At the beginning, I often sacrificed sleep just to finish one more thing. But I learned the hard way that some tasks are simply bigger than a night. Once, while working on a new OpenZFS encryption feature that allows sending encrypted datasets to unencrypted destinations, I stayed up all night — only to end up with a patch worse than the one I started with.
Now, I simply write “work on this” instead of “finish this.”
That subtle shift helps me stay healthy — and interestingly, I sleep more peacefully knowing I’ve done something meaningful, even if it’s incomplete.
The day-walker’s pain
Even without full all-nighters, partial sleep loss adds up.
Tiredness doesn’t pair well with studying pharmacokinetics or molecular binding models. Headaches are basically pre-programmed. Once, my sleep debt grew so large that I came home on a Friday, lay down, and woke up over 24 hours later.
It’s getting better — I’ve started managing my open-source pace better — but balancing it with my studies remains hard. Whenever I notice my academic performance slipping, I throttle back my open-source involvement. That’s why I created a personal rule:
never edit my To-Do list at night (except to shorten it).
It’s a small mental safeguard that keeps my workflow healthy and sustainable.
The value remains
Breaks might feel unproductive, but they’re essential.
They give me time to reflect on what I’ve already accomplished. Seeing my patches accepted and exchanging deep technical emails with peers reminds me that my work matters — and that it’s appreciated.
In the end, consistency beats intensity.
Finding the right balance between open-source and life is key, because burnout helps no one. Every lost contributor is a lost piece of potential progress.
You are not alone
Most importantly, remember: you’re not alone in this.
Every open-source contributor is juggling daily life with late-night code sessions. Everyone understands when someone needs a break. It’s part of the rhythm of volunteer collaboration.
And sometimes, seeing how much time others invest in your work gives you perspective — it’s a quiet way to measure how impactful your contributions are. Some people might even write blog posts about that balance, just like this one.
I’m only 23 years old, still learning how to master this balancing act, but I’m determined to keep advancing HPC on FreeBSD for as long as I can.
P.S.
It really feels like I’ve clicked into the community now — I can finally hold deep technical conversations with peers and share work efficiently.
That’s my last piece of advice: communicate visibly.
Start discussions about what you’re doing, and you’ll naturally attract others who care about the same problems. Splitting work doesn’t just reduce stress — it also makes your breaks feel productive, because progress continues even while you rest.
Special thanks to Laurent Chardon for unbundling prrte and pmix from OpenMPI — a foundational step that now enables a shared HPC runtime stack used by all other tools (including slurm-wlm).
FreeBSD’s future in HPC is slowly but surely unfolding — and it’s people, not corporations, who make that happen.
Generic Rikka is a software developer and FreeBSD enthusiast with a focus on high-performance computing and system engineering.
She primarily programs in C and C++, but also works comfortably with C#, Python, Java, PHP + MySQL, and various shell scripting environments.
Rikka maintains several virtualized servers—both FreeBSD and Linux—and began contributing to the FreeBSD Ports Collection in summer 2025. Her first major work involved modernizing and eventually maintaining the sysutils/slurm-wlm port.
Today she is actively engaged in expanding FreeBSD’s HPC ecosystem, improving upstream collaboration, and promoting FreeBSD as a modern platform for scientific and research computing.