I think most people would agree that over the last year or so WordPress (WP) has been successful as an open source project. It’s been around longer than that, but it has certainly gained a lot more attention in the last 12 to 18 months. It was around that time that I switched to WP for this blog. The face of WP is definitely Photo Matt, he more than anyone else is who people think of as being the head of WP.
There are lots of good things about WP. It is fairly easy to install and from the user point of view it looks nice for the most part. But if you take a peak under the hood at the PHP code that makes WP happen, you’ll likely be very disappointed. There are very few comments in the code, making it hard to understand the literally hundreds of defined functions. I’m certainly not the only one to write about this, Martin Geisler posted a list recently.
Martin mentions things like excessive use of global variables through out the WP code. It is difficult and probably not even a good idea to get rid of all global variables, but minimizing their use is generally considered a good idea. He also points out some duplicate code issues. I haven’t looked at that too closely in WP, but I will tell you that there are a lot of wrapper functions in WP that will often do nothing but set an option or two for another function. I gladly join the band wagon on complaining about the use of very long lines in code. This only serves to make things hard to read. The last item he mentions is the mixing of PHP and (X)HTML in the code. I would have preferred that code not produce any (X)HTML except in a few well defined cases. Martin seems to agree with this idea.
Being a webapp, WP is also sensitive to performance. I’ve written about SQL query changes that could be done in WP before with a less than enthusiastic response. Recently the LightPress folks posted their own analysis of some of the WP SQL queries and received a slightly better response. Still there seems to be this idea though that there are bigger improvements to be found else where, so these improvements should be ignored. Granted, we’d all like to be able to find that awesome tweak that yields a 90% speed increase across the board, but those are few and far between. More often than not, an overall speed increase is found be making things a little better here and little better there. Eventually those all of those smaller tweaks add up to a faster overall speed.
So why am I dragging through all of this again? Because despite its rather hideous under belly, WordPress is a successful project with a growing user base. It works, it looks fairly nice and is reasonably simple to install and upgrade. I suspect there is a lesson to be learned here. You can get away with making some aspects of your software rather unpolished, as long as your get the important parts right.