I help where I feel I can help most, and take everything I learn along the road with me.
I have been programming for myself for eight to ten years — digging
through documentation, deciphering source code, researching portability
gaps across operating systems. How does kqueue compare to
epoll? Why does a libc assumption that works on Linux silently
break on FreeBSD? These are the kinds of questions that pull me in.
Almost a year ago I crossed the threshold into open source contribution. My current road has led me to FreeBSD ports development, specifically in HPC and scientific computing — because this is where I feel I can help science the most from where I stand right now.
I run FreeBSD on everything. It started with servers, then became my daily driver. The moment I first read about FreeBSD I was curious — I went straight into the handbook, forum posts, mailing list archives. That curiosity never left.
FreeBSD as a first-class HPC platform.
FreeBSD has the technical foundation. The kernel is solid, the networking stack is excellent, and the system's design philosophy aligns well with the reliability demands of compute clusters. But the HPC software ecosystem on FreeBSD has gaps — some ports missing, some outdated, some never properly upstreamed.
Why it matters
Scientific computing clusters demand stability, predictability, and performance. FreeBSD's design delivers all three — but only if the software stack exists. Right now researchers who want FreeBSD on their clusters have to maintain their own patches. That shouldn't be necessary.
Where the gaps are
UCX, OpenMPI, PRRTE, PMix, Slurm — the core HPC runtime stack. These tools are Linux-first and carry glibc assumptions that break silently on FreeBSD. Portability is not glamorous work, but it is necessary work. Someone has to do it carefully.
What I am doing about it
Porting, upstreaming, coordinating. Every patch I send upstream is one fewer patch the ports tree has to carry. Every committer relationship I build makes the next submission easier. It is slow, methodical work — and it is exactly what the platform needs.
What I have built and upstreamed.
UCX — Unified Communication X
Created the FreeBSD net/ucx port from scratch — no
prior port existed. This is the heaviest port I maintain and the
one I am most proud of. UCX is the high-performance transport
layer underpinning most modern MPI implementations.
Beyond the port, I am a named contributor in the UCX
AUTHORS file with a signed CLA. My upstream
portability PR targets FreeBSD libc, musl, and Clang environments
— fixing silent assumption failures that would otherwise require
ongoing downstream patches. Getting UCX into the ports tree
was itself a process that required persistence.
Slurm — SchedMD workload manager
Maintaining sysutils/slurm-wlm and building a
working relationship with SchedMD upstream. FreeBSD-specific
patches submitted and merged. Slurm is the workload manager
that ties the HPC stack together at the job scheduling layer.
OpenMPI · PRRTE · PMix
Coordinated the unbundling of the monolithic OpenMPI port into discrete ports for PRRTE (PMIx Reference RunTime Environment) and PMix. This work produces a cleaner dependency graph and makes each component independently upgradeable — the right architecture for a ports tree that needs to track upstream independently.
Reaper — userspace process introspection
Merged reaper userspace introspection support into the FreeBSD base system. src-level work is a different discipline from ports — it requires understanding the kernel interface, the userspace contract, and how changes propagate through the system.
net-snmp
Full audit of the net-mgmt/net-snmp port patches
against upstream master. Identified which patches were already
merged, which were obsolete, and uncovered two previously unknown
upstream bugs in the install machinery — now being submitted as
separate upstream PRs with clean separation of concerns.
FreeBSD HPC quarterly reports
Two merged documentation contributions to the official FreeBSD quarterly HPC ports modernization status reports. Documentation is not my strongest suit — I lead with code and patches — but I contribute to it because visibility matters for the platform.
Methodical, cooperative, quality-first.
Upstream first
Every patch that can go upstream, does. Carrying downstream patches is maintenance debt. I research the right fix, coordinate with maintainers, and push for the merge — even when that takes multiple review cycles.
Portability over workarounds
I dig into the actual source of an incompatibility — a glibc-specific macro, an epoll assumption, a missing POSIX abstraction — and fix it properly. A correct portability fix helps every non-Linux platform, not just FreeBSD.
Real hardware testing
I test on actual silicon across multiple architectures — no QEMU, no emulation. If it works on real hardware, it works. This matters especially for HPC, where performance characteristics are part of what you are validating.
Coordination, not isolation
I reach out to committers, co-maintainers, and upstream maintainers before submitting. I try to be maximally cooperative in review — responding thoroughly, making requested changes, explaining the ones I push back on. Quality and cooperation are not in tension.
Looking for a detailed portfolio?
Full contribution history, references, and contact information are on the portfolio page — built for employers, universities, and applications.