If you ask the average PHP developer what they think about WordPress, you may be disappointed with their answer. Their answer may make you think that WordPress is the bastard child of PHP, totally unloved and unwelcome in the PHP community. They’ll cite code quality, community, even personalities in their argument. I’ve even heard stories of a WordPress developer asking a prominent member of the PHP community about using their tool to improve WordPress. The response? “WordPress needs a rewrite.”
And I should know; I’ve been quite vocal in my frustration with the fact that WordPress still tells people it’s okay to use old versions of PHP. And yet, despite WordPress’ shortcomings, it has definite advantages that the PHP community needs to recognize and embrace.
To say that I love Github would be a bit of an understatement. I more than recommend it when describing code review processes. At Mozilla, the web development team uses Github for our code reviews, since line notes and pull requests work perfectly with our code review requirements. Github allows a large distributed team to work independently while still working together.
However, recently Github has experienced some issues with it’s performance. Thankfully, most of these issues have been minor. But the issues highlight a serious potential flaw in using Github for critical development processes:
This past week saw a huge dust-up over the issue of whether or not WordPress themes are GPL. It’s not my goal to rehash the debate, or even to discuss it in particular; instead, my goal is to share some thoughts I’ve had about software licensing, and in particular, licensing going forward as a result of the WordPress theme dispute.
The reality of the debate is that many, if not most of the participants are software developers of some kind – that is, they derive a considerable amount if not the majority of their income from developing applications of some kind. Given this liklihood, it makes much sense that they have a “dog in this fight” as much as anyone else. And so, the community is doing what it seems to do best: disagreeing, sometimes civilly, sometimes not, and trying to work out a solution.
In November of 2009, I wrote about why developers should write their own frameworks. I pointed out at the time that often developing a framework forces developers to make the kinds of architectural choices that frameworks require, which helps them better understand the architectural choices in the most popular frameworks.
I haven’t stopped believing in the power of doing as a learning tool. But in the past few months I’ve had an opportunity to move into more of an understanding of frameworks like Zend Framework, and I’ve come to another realization:
Leaders of the open source community are always trying to encourage others to contribute. Volunteer contributors are always in short supply, and most open source projects are driven by volunteers, so recruitment is a big component of any open source project lead. Elizabeth Naramore put together a great list of reasons why people tend to shy away from contributing and did a great job highlighting some solutions. I want to add my own voice and experience about one of the truisms of open source development:
When it comes to making open source easier, architecture matters.
Recently, I began working alongside Wez Furlong here at Message Systems. One of the many tools we use is Mtrack. This tool is a port of Trac into PHP, along with the addition of some great new features. Spearheaded by Wez, it’s a great tool that we use internally for our projects, and since it’s stable, it’s worth mentioning to the world.
Mtrack is still in it’s early stages of development, but is certainly a stable piece of software that gets the job done. Having used it for a few weeks, I can say that it’s easy enough to learn, and has some distinct advantages to it over Trac for PHP developers. First and foremost, it is written in PHP, which makes it easier to administrate and maintain than a Python-based application. Second, it allows for multiple projects in the same installation by default, which is a significant improvement over Trac. Third, it allows you to have a repository on one server and an Mtrack instance on another server, and still be able to use that repository in your Mtrack instance. Mtrack also offers some great features, including built-in support for Agile-like development and a plugin architecture that makes writing plugins easy.