Last week, Aaron Brazell posted a blog entry about the state of the WordPress and PHP communities. At the same time, Keith Casey was in Redmond, Washington, where he was experiencing the Microsoft Web Developer’s Conference. As so often seems to happen with “Aha!” moments, both men came to pretty much the same realization at the same time: the WordPress and PHP communities need each other, but don’t do nearly enough to work with each other.
Keith made his point clear when I explained to him that I agreed with what Aaron was saying in his blog post, but that WordPress supporting PHP 4 was WordPress’ “fatal flaw.” In his…articulate way…he reminded me that WordPress existed and flourished, in spite of our attempts to attack their support for PHP 4. Their use of PHP 4 was certainly not a fatal flaw, as much as our arrogance as a community seems to be.
The one thing I hate about Keith is that he has a tendency to be right. And he was right this time.
The reality is that you can’t separate the success of PHP from the success of other open source tools like WordPress and Drupal. As they have flourished, so has PHP; the success of each is interconnected with the success of the others. Yet it seems that the PHP community is fond of attacking and demonizing these communities, which only serves to drive them away from the PHP language.
WordPress and Drupal could exist independently of PHP, if PHP didn’t exist as a language. The need was there; they would have been written in Python or Ruby on Rails, or Fortran; the language is irrelevant; the need was paramount. The fact that they were written in PHP is an accident of history, not a divine destiny. They were written in a time before PHP was widely accepted. And they were written with the tools available at that time.
In short, we, as the PHP community, need to lay off. And we need to put up or shut up. Hate the fact that WordPress still supports that “dead language” of PHP 4? Write a patch. Hate that Drupal’s UI would make a geek cry out in agony? Write a patch. These are open source projects; we each can look at the source and make them better. But we should never, ever attack these projects for not conforming to our standards. Especially if we’re not improving them.
And we need to be better about interfacing with the communities that surround these projects. Each has a robust community that doesn’t identify with PHP. They don’t understand PHP, and the reasons it works the way it does. Many of them blame PHP for the troubles of the product. We need to be proactive about reaching out to these groups, and interacting with them. We need to be receptive to their needs. And we need to work with them to improve PHP overall.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."