I don’t remember exactly when I started using WordPress.
I think it was sometime around 2004. It was before Kubrick became the default theme and before WordPress had the visual editor, much less the block editor experience most people now take for granted.
I do remember exactly when WordPress became more than software to me.
June 12, 2007.
I Was Looking for a Practical Tool
My path into web development wasn’t particularly deliberate.
I’d been interested in computers and code since I was a kid. By the time I found WordPress, I was building a web application for my dad’s trucking company. They shipped cars throughout the southwestern United States, and the application helped dispatch the trucks.
I was also doing client work. When I needed a content management system, WordPress did what I needed, used PHP – the language I already knew – and gave my clients something they could own and control after I handed it off.
That was it.
I wasn’t searching for a community. I wasn’t trying to become an open source contributor. I was trying to solve problems for clients.
At that point, my career had plenty of energy but very little direction. I took freelance jobs through sites like oDesk, Rent-a-Coder, and Freelancer.com, usually fixing something small or adding a bit of functionality. Getting work was difficult, and I believed the answer was to build a better portfolio.
I didn’t yet understand that my portfolio was only one part of my reputation.
A Very Small Patch
One of my clients had a site that tracked stock-market information and used unusually long post titles. Those titles exposed a bug in WordPress.
WordPress created a URL-friendly version of each title called a slug. When two posts had the same title, it added a number to make the second slug unique. But when a title was already at the 200-character limit, adding that number caused a problem. WordPress would save the second post with the same slug as the first. One of them could no longer be reliably found.
The fix was tiny. Literally one line of code.
On June 12, 2007, I opened my first WordPress bug report, uploaded my first patch, and had my first contribution committed to WordPress Core. Mark Jaquith reviewed and committed it.
All on the same day.
The code itself wasn’t especially impressive. What happened around it was.
Someone I didn’t know took the time to review my work. The change became part of software used by people I would never meet. A problem I encountered while helping one client became a fix that could help everyone using WordPress.
I liked knowing that a small fix for one client could help thousands of people I’d never meet. I wanted to do more of that.
The Software Led Me to the People
Until then, WordPress was simply a useful product. Submitting that patch introduced me to the project behind it and, more importantly, the people building it.
I started contributing more. I released free plugins. I got to know other contributors. By 2009, I was traveling to WordPress events, and by 2011, I was speaking at them regularly.
Those things also changed my career.
The work I did on WordPress and the relationships I built in its community started bringing client work to me. It wasn’t only my portfolio that opened doors.
Contributing to Core, maintaining plugins, helping other people, and sharing what I’d learned all became part of my reputation. Eventually, enough work was coming to me that I could be more selective about the clients and projects I took on.
That was one of the most important lessons WordPress taught me. Reputation isn’t only a list of things you were paid to build. It’s also how you participate, how you treat people, what you share, and whether your work makes the ecosystem around you better.
Once I understood that, I could be more deliberate about both my contributions and my career.
From One Line of Code to Something Much Bigger
That first patch led somewhere I couldn’t have planned in 2007.
Contribution had stopped being something around my work. It was becoming the center of it.
I eventually co-led the WordPress 3.6 release and joined the WordPress Security Team.
In 2016, I joined GoDaddy as a full-time WordPress Core contributor, which meant a company whose business depended heavily on WordPress was paying me to help improve the project itself. A few months later, I became the WordPress Security Team lead.
But the titles aren’t the most important part of the story.
The important part is that my relationship with WordPress changed. I started as someone using the software to solve a client problem. Contribution showed me that I could help shape the software, support the people using it, and strengthen an ecosystem that my own livelihood depended on.
Over time, WordPress also helped broaden my view of the work.
A patch can fix a bug. Protecting millions of users, sustaining an open source project, or building a product people trust takes more than code. It takes understanding users, coordinating organizations, building trust, communicating clearly, and helping businesses see that supporting open source isn’t charity. It’s an investment in infrastructure they and their customers rely on.
Those lessons eventually pulled me beyond development and into security, partnerships, product strategy, and leadership.
The First Patch Still Matters
I’ve worked with WordPress for roughly two decades now, but I still come back to that first patch.
It was one line.
It solved one unusual problem for one client.
That doesn’t sound like the beginning of a career-changing story. At the time, it didn’t feel like one either.
But contribution has a way of compounding. You solve a problem. Someone reviews the work. You meet the people behind the project. You help again. Eventually, you’re no longer standing outside the community wondering how to become part of it.
You already are.
WordPress began as a practical choice for me. It became a community, a career, and one of the clearest examples I’ve seen of what open source makes possible.