We need to talk about Individual Identity in WordPress. For some reason, the standard advice in our ecosystem has shifted from celebrating the person behind the code to highlighting the logo on their paycheck. It is a subtle architectural debt in our culture that is starting to affect how we build, contribute, and—ultimately—how we ship software.
I’ve been around since the 4.x days, and I’ve seen this project grow from a community of hobbyists into a massive corporate-sponsored machine. While sponsorship is the fuel that keeps the lights on, we’ve inadvertently created a system where the “Company” field is overshadowing the “Contributor” field. When a core developer feels that their unpaid, spare-time contribution is less recognized than a corporate-pledged hour, we have a logic error in our community core.
The Badge Problem: A Design Logic Error
Recently, a “Self Employed” label on a WordCamp badge caused a stir. It’s a perfect example of a bad UI choice reflecting a deeper systemic issue. Why is the company name the primary identifier? We are software people; we should be celebrating personal identity through our Individual Identity in WordPress—our usernames, our personal websites, or even our hometowns.
In the past, badges prioritized the human. Now, they prioritize the sponsor. This isn’t malicious, but it’s an unintended consequence of our push for corporate involvement. If you’re wearing a company t-shirt, I already know who you work for. I’d much rather know the URL of the project you’re proud of or your .org handle so I can actually follow your work.
Measuring Inputs vs. Results
One of the biggest bottlenecks we face is how we measure success. We celebrate “hours pledged” in initiatives like Five for the Future, but hours are just an input. In development, we don’t care about how many hours a function took to write; we care about whether the code is performant and if it actually solves the user’s problem.
By emphasizing participation and process over actual results, we’ve created a “Race Condition” in our workflows. More people are involved, yet things seem to move slower. This isn’t a new phenomenon. As Fred Brooks pointed out in The Mythical Man-Month back in 1975, adding manpower to a late software project makes it later. When we prioritize inclusive consensus over decisive execution, the overhead of communication eats our productivity.
If you’re curious about how we can fix this, you might find my thoughts on the WordPress contribution pipeline relevant to this discussion.
The Cultural Refactor
We need to stop treating Individual Identity in WordPress as a secondary transient. We need to go back to celebrating the “spare time” volunteers who built this house. Without them, we’re just another corporate CMS.
- Focus on Impact: Change the Five for the Future testimonials to highlight what was shipped, not just how many hours were “pledged.”
- Reclaim the Badge: Prioritize personal websites and .org usernames over corporate affiliations.
- Analyze the Noise: Regularly check if our increased participation is actually moving us toward our goals or just creating more process for the sake of process.
I’ve often asked myself: “How have I been complicit in creating the conditions I say I don’t want?” As a developer, it’s easy to focus on the ticket and ignore the culture. But the culture is the infrastructure. If the infrastructure is crumbling, the code won’t matter.
For more data-driven insights into how the project is evolving, check out my analysis on WordPress Core numbers.
Look, if this Individual Identity in WordPress stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Final Takeaway
The strength of WordPress has always been its individuals. Let’s make sure our systems reflect that. We need to reward impact over activity and humans over logos. It’s time for a major version release of our community values. Ship it.
