Update (May 2026): Both PRs have been merged into Magma's main branch.
I finally did it.
I clicked the green button. I generated Pull Requests #15813 and #15812.
For a student, this is a terrifying threshold. You spend years writing code that only you or your professor will ever see. It is code that lives in a vacuum, if it breaks, nobody cries. But open source is different. Open source is a living, breathing city. When you push code to a project like Magma, you aren't just handing in an assignment, you are attempting to renovate a building while people are still working inside it.
The contribution itself started as a mystery. Something was crashing, and nobody could tell you exactly why.
Magma is a mobile core network platform, built under the Linux Foundation. It sits between a cell tower and the internet — invisible infrastructure, the kind that only reveals itself when it fails. When it crashes, the silence is not an inconvenience. It is a dropped call during an emergency. A failed payment. A conversation that ends mid-sentence.
I was brought in as an LFX mentee, tasked with triaging a series of critical runtime crashes in the Access Gateway — the component that manages traffic between the radio network and the broader core. I started digging.
I found a C++ namespace collision.
A namespace, in programming, is a container for names. It exists so that two different programmers, working on two different parts of a system, can both call something "handler" or "config" without the compiler losing its mind. Namespaces are how large codebases stay sane.
But when a collision occurs — when two names exist in the same scope without explicit disambiguation — the compiler does not politely ask which one you meant. It either grabs the wrong one silently, or it crashes. The program reaches for something familiar and comes up holding the wrong thing entirely.
That was the first crash. An ambiguity the codebase had silently tolerated until, one day, it couldn't.
But the namespace collision was only part of the story. Following the root cause backward, I found incorrect linker paths. The linker is the step that assembles all the compiled pieces of a program into a single executable. If the paths are wrong, the linker cannot find what it needs. The piece exists. It was never deleted. The linker just cannot reach it.
I corrected both, documented the root cause analysis for the team, and then extended the work further: adding cross-architecture support across x86 and ARM processors. Two fundamentally different hardware architectures, two different instruction sets, two different ways of thinking about computation — the same codebase now had to work across all of it. Making that happen meant rethinking assumptions that had been baked in from the beginning.
The PRs were merged. The crashes stopped.
"The beginning of wisdom is the definition of terms." - Socrates, probably
And here is where it gets strange.
Because while I was deep in the collision, two identically named things causing a system to fail. I started thinking about what it actually means for something to have a name.
In a compiler, identity is ruthlessly enforced. You must qualify your names. You must be precise about what you mean and where it lives. The machine will not tolerate ambiguity. If two things share a name in the same scope, the system breaks. That is not a suggestion. It is the rule.
But humans are allowed to name themselves anything. We collect identities the way a codebase collects dependencies, student, developer, fraud, contributor, success, failure — and we rarely check for collisions. We stack them in the same scope without disambiguation, and sometimes, under specific conditions, the system crashes.
A breakdown. A panic. A moment where you reach for a version of yourself and grab something unrecognizable.
The compiler, at least, tells you exactly where the collision occurred.
And then there is the linker problem. The idea that something can exist and still be unreachable because the path to it is broken somewhere in the middle. A memory. A feeling. A version of yourself you haven't been able to access in years. It is not gone. The connection is just wrong.
Most people spend years trying to fix their linker paths. Therapy. Conversations at two in the morning. Journals full of attempts to trace the error back to its origin.
And the cross-architecture work is perhaps the strangest mirror of all. x86 and ARM are different in almost every measurable way at the hardware level. Different instruction sets, different memory models, different assumptions about how computation should work. And yet, the same code can run on both. The logic is universal. The substrate is not.
My PRs #15813 and #15812 are now in the repository, quietly doing their jobs. The crashes are resolved. The paths connect. The same program runs on different machines without complaint.
But it leaves you with an uncomfortable question.
If a naming conflict, a collision between two things occupying the same space, can silently destabilize infrastructure that thousands of people depend on, what happens when the same thing occurs in you?
When two versions of who you are supposed to be exist in the same scope who you were told to become, and who you actually and nobody ever writes the rule that says which one takes precedence?
Does the system just keep running? Quietly degraded. Slower than it should be. Until one day, under specific conditions, with no warning at all
It doesn't.
