In May 2009, I was 22, finishing my CIS degree at the University of Jordan, and I helped co-found an open source club. I stood in front of other students and explained why they should care about software they didn’t pay for, built by people they’d never meet, running on phones with 2.5MB of heap.

The stack we taught: Java — specifically J2ME — PHP for web, and MySQL because what else were you going to use. This is not a post about modern tooling. This is a post about what it felt like to be an evangelist for open source software in Amman in 2009, when most of the students in the room had grown up with pirated copies of Windows XP and thought Linux was for people who enjoyed suffering.

Why J2ME and not Objective-C

I get this question now, from people who weren’t there. “Why J2ME? iPhone was already out by 2009.”

iPhone was out. The iPhone developer program required a Mac and $99 a year. The phones our classmates actually owned — and the phones the users of any software we might build would actually carry — were Nokia Series 40s, Sony Ericssons, and the occasional Symbian device. J2ME was what those phones ran. MIDP 2.0, CLDC 1.1, and if you were lucky, a JTWI-compliant device with a halfway-decent camera API.

If you were building software for real users in Jordan in 2009, you were targeting J2ME. This was not a philosophical choice. It was arithmetic.

My own graduation project at the time was a GIS-based marketing platform with mobile clients for Windows Mobile and Symbian. I was writing the mobile frontend in Java. The web backend in PHP. The database in MySQL. So the curriculum we designed for the club wasn’t hypothetical — it was literally what I was building in the same semester I was teaching it.

What open source actually meant in that room

Here’s what made it feel edgy: most software people in Jordan at that time — students, professionals, everyone — operated in a world where software had a price tag and a serial number. Microsoft Office had a key. Photoshop had a key. The idea that something useful was just available, legally, for free, with the source code you could actually read — that required explanation.

I was not giving a lecture about the philosophy of Richard Stallman. I was explaining to a room of 20-year-olds that they could build a web app today with Apache, PHP, and MySQL and not spend a single dinar on licenses, and that this was legal, intentional, and the way most of the internet was already running.

The lightbulb moments were real. “So the code is just… there?” Yes. The code is just there. Go read it. Go break it. Go fix it and send the fix back.

The parts that aged well and the parts that aged badly

The philosophy aged well. The specific technology did not.

J2ME is now a museum exhibit. Symbian is a museum exhibit. The Nokia Series 40 is a museum exhibit. A full decade before smartphones completed their takeover, we were teaching mobile development on hardware that is now genuinely hard to find outside of a collector’s drawer.

But the principle — that you should understand the full stack, that you should be able to read the source of the tools you’re using, that shipping something real is the best education — that held. The engineers I’ve worked with who have the best instincts are almost always people who spent time reading source code they didn’t write. That’s not a coincidence.

The specific version of “open source as unusual pitch” also aged away, for obvious reasons. In 2009, convincing someone that open source was legitimate required effort. In 2024, trying to build any serious project without open source would require more explaining. The evangelism worked, collectively. We won.

What happens right after

Thirteen months after the club started, I was at EHS/HAKEEM writing MUMPS routines for Jordan’s national healthcare system. If you’re not familiar with MUMPS: it’s a language from 1966, it runs on VistA, it is still keeping hospitals running all over the world, and it is about as far from PHP as you can travel while remaining on the same planet.

The jump sounds jarring. It didn’t feel jarring. I’d been lecturing on “read the source code, understand the system underneath you” — and then I was in a system where the source code was 40 years old, written by people at MIT and the VA, and I had to understand it to do anything useful. The practice transferred even when the syntax was from another era.

I’ve been teaching in some form since before I had a job title. At AFAQ I was running architecture reviews that were mostly just structured teaching. At Bytro, modernisation workshops. At Talentera, working with the team on system design. The format changed. The instinct — explain the system, show the source, build the thing — stayed constant.

2009 to now

I was 22, standing in front of a whiteboard, explaining why a Java runtime that fit on a Nokia phone was a good thing worth your time. I am now 37, shipping distributed systems in Kotlin and Go, running a local-first agent control plane (Fulcrum) in my homelab.

The J2ME heap constraints are gone. The MIDP 2.0 APIs are gone. The Symbian client of my graduation project is gone. But I’m still explaining why you should read the source code, still believing that the best way to learn a system is to build something real with it, and still a little bit the guy who stood up at 22 and said “this is worth your time” about software you didn’t pay for.

Some instincts compound.