A little over two years ago, when I got involved with the MontreAlers (note: yes, site broken... read on), the homebrewing club in Montreal, I was quickly nominated to be the sucker who would help take their aging and mostly-neglected web site, and make it somehow useful.
At the time, the choice was simple: custom code or Drupal. Because custom code takes quite a bit of the most valuable commodity in life—time—and because I had (and continue to have) very limited spare time, I chose Drupal.
I hacked together a custom theme (based on one of the prepackaged templates), spent a few hours configuring modules, and spent probably an equal amount of time shaking my head at the procedural and poorly-designed (for small values of "design") plugin/extension API. I grabbed some pre-built modules, and cobbled together a reasonable community site. We didn't need much, and Drupal + a few plugins solved most of our problems.
The site was a hit. Membership in the club has climbed from a handful of members to what's often a troublingly large number of attendees to our monthly meetings. There's no direct correlation to the site, but I think all of the MontreAlers would agree that it has played a role in connecting with new likeminded people.
As with any project whose maintainer doesn't have sufficient available time, the site got dusty over the course of the first few weeks, then dirty over the next few months, and before we even realized, the site was in a state of partial disrepair. Databases were upgraded, hardware was swapped, DNS was migrated, and PHP versions were updated. Each of these tasks of regular maintenance were met with heightened amounts of finger crossing, cursing and furious patching. After upgrades or changes, I'd usually get inquiries about why certain functionality mysteriously stopped working, which often lead to more furious patching, cursing and finger crossing.
Over time, minor inconveniences can easily snowball into what seems like one large, insurmountable problem. The last straw for ongoing my relationship with Drupal was upon upgrading the PHP version on my server to 5.3.
Admittedly, 5.3 is fairly young, but I was ready to take on the challenge. I'm handy enough with PHP's changes that I felt confident that I'd be able to take on any problems that Drupal presented. The obvious first step, here, was to update Drupal to the most recent release. I don't remember the exact date of the upgrade, but I do remember my feelings clearly. It was the day I started actively searching for a Drupal replacement.
The upgrade was extremely painful. There was no clear path to upgrading from our old, stagnant Drupal install to the newest version. Updating the code was a bit painful, but possible. The Drupal upgrader/installer did take care of the database update, which was my biggest worry, and there was some documentation on how to do this on the Drupal site, but I had to dig pretty deep to find it (and I've since lost the links, so I apologize that I can't link to the references I used).
There were two main pain points: I had to manually patch Drupal to work on PHP 5.3, and some of the third-party Drupal modules the club now depended on were not possible to upgrade.
The patching for PHP 5.3 was not entirely unanticipated, and was reminiscent of making fixes in broken array_merge()s when jumping from 4.3 to 5.0. The real problem here is that Drupal still maintains its code in CVS, so I gave up on submitting my patches upstream shortly after diffing and trying (to no avail) to find their subversion or Git repository. I thought PHP was the last significant project to move from CVS to SVN, but I was obviously wrong.
I fully expect Drupal will (or maybe already has) catch up to the current release of PHP (aside: they had plenty of notice to get their code up to speed—PHP 5.3 was certainly long in the tooth by 5.3.0). The real problem with the latest upgrade was that some of our modules not only didn't work with the new version of Drupal, but there was often no available upgrade for them. Our event calendar went missing, user maps (home addresses for club meetings) disappeared, our photo gallery is completely AWOL. There may be suitable replacements (read: alternative functionality in other modules) for some of our wants and needs, but the fact remains that maintenance is painful, and "upgrades"—often for the purpose of plugging security holes—take much more time and effort than I have to give.
The underlying code in Drupal is old. It seems brittle. It doesn't do things I'd expect modern software to do such as have a good inheritance model (hint: it's [almost?] all prodedural code), have self-documenting or intuitive APIs, and it does tons of things that I simply don't care about (I'll probably blog on this last thing as a general poisonous open source trend in another episode). It's more pain than it's worth at this point, and I just need it out of my life.
So, Drupal, we're breaking up.
But I don't have anyone else to go (more on my short list in a near-future entry).
(Here's the rhetorical paragraph.) Is it too much to ask for PHP code to actually be well-written? It doesn't even need to be perfect. Habari is certainly far from perfect, and it has warts, but on a whole, it's good code. Is the barrier to entry for most projects too low? Or is there just a huge lack of experience in knowing how to do things right? Maybe all of the best people are too busy doing other things? Or maybe it's a community-management problem...? I don't know.
When it comes to software, and especially web software, I find myself always settling for "Least Worst." Habari is Least Worst. Trac is Least Worst. MediaWiki, PHPMyAdmin, Roundcube: all arguably best-in-class, but under the hood, they're often painful. I suspect my expectations are simply too high. Should I just lower them? I don't know that either.
