When I was a kid in Sicily, my mom and I would bike across the flight line at Comiso AB so I could play Frogger on a Commodore 64 at the BX.
That C64 became the genesis of everything for me: games, programming, running a school newspaper, and eventually discovering BBSes.
But there was one thing I wanted desperately and could never have.
Mario.
Yes, the original Mario Bros. (the one with the pipes and turtles) did exist on the C64. I knew that. But that wasn’t what I wanted. I wanted Super Mario Bros. The NES version. The one scrolling across the TV in every commercial, every magazine, and every other kid’s living room.
My parents could barely afford the C64, let alone a NES. I begged them to find me Mario, not understanding that Super Mario Bros. was locked to Nintendo hardware. No cartridge. No floppy. No port. It simply did not exist on the machine I owned.
That burned a hole in my little soul. Not because I felt entitled to it, but because the idea that software could be permanently tethered to one platform went against something fundamental in my nature, even before I had the vocabulary to explain it.
That feeling never left. It just matured.
I installed Debian 1.3 at the first opportunity and never looked back. Open source felt like the antidote: software free to run, modify, and port wherever you needed it.
Years of porting proprietary software to other OSes as a technician reinforced that lesson. I spent an inordinate amount of time running Windows apps under Wine, spinning up VMs to escape single-vendor ecosystems, and forcing closed platforms to talk to open ones. It was always the right call, even if it took longer upfront.
Here is what that childhood frustration taught me about architecture today:
▸ Defaulting to a closed environment limits your choices later. The bill always comes due.
▸ Open source is the ideal; open data formats are the minimum. If your data lives in a proprietary container, the vendor owns it. Not you.
▸ Being cloud and platform-agnostic takes more work upfront. It can be harder to scale initially, but you maintain ultimate flexibility.
▸ No vendor should ever control your data or IP. Full stop.
Dan McKinley’s concept of “innovation tokens” later gave me the language for something I’d been doing intuitively. Spend your few tokens on new tech wisely. Most of your stack should be boring, battle-tested, and portable.
Boring tech is good tech. Pair that with a distrust of vendor lock-in, and you’ve got an architectural foundation that stands the test of time.
I eventually did own a NES, and yes, Mario was everything I hoped he’d be. (Decades later, someone even built a proper, unbelievable port of SMB for the C64, which I’ll link in the comments!). But by then, the lesson had already taken root.
I still carry a deep-seated distrust of anyone who tells me their software only runs on their hardware, their platform, or their terms.
Mario’s loss was my gain.