Everybody likes “the new hotness.” Everyone loves a new car, or a new computer, or the state-of-the-art video gaming console. It’s why people camp out for days to get their hands on a new iPhone, when they could just buy one the next week off the shelf. People love to have the hot thing, right now.
Perhaps, then, it shouldn’t be so surprising that people get tremendously excited when a new version of PHP comes out. People look forward to the new features, whether they be the trailing commas in list() syntax or counting of non-countable objects.
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.