Drupal

The community will begin to realize (in part due to the above stalled project) how much design debt Drupal has accrued over the past several years of rapid expansion and development. While the problem will not be solved in 2008, the realization that it IS a problem will help prevent a long-term meltdown. - Jeff Eaton January 4, 2008

Design Debt and Drupal.org
Indeed as Jeff suggests, this "realization" seem to be a bit of a challenge at the moment for parts of the Drupal community right now, at least if the reactions to Harry Slaughter's post regarding a Drupal module ratings site which John Forsythe just launched are taken into account.

Given the possible reactions it was disappointing to me that some people chose to attack Harry and John (e.g., the messengers) rather than the processes which have lead to a situation whereby one of the largest open source software projects on earth can't get SOMETHING up to help it's users deal with their number one feature request for Drupal.org. As John, myself, and any number of people have proven there has been no lack of volunteers, or lack of resources, but rather just grid lock on this issue. (for instance, this thread was just one of many that tried to get the ball rolling).

Contrast how this scenario with module ratings works with how core development works. With core - people submit patches, other people give opinions and review, but eventually one person just makes a judgment call on whether or not the patch is committed and life moves on. With the module ratings it's been more a game of 'waiting for consensus' of a handful of well intentioned people who all each seem to have the power to hold things from going forward but none of whom have the authority to 'just call it' - and thus move the issue on toward *actual* implementation. Thus more time passes by without a solution...

While on the subject of design debt - design debt and Drupal 6/7
Drupal 6, a great release in it's own right, is unfortunately not production-ready for many site-types due to the lack of some very important contributed modules. Since my time with Drupal (4.5) I've never seen anything quite resembling the lag between a Drupal release and it's 'production readiness' that I'm seeing now (Views is not even out of alpha - and CCK is waiting for views to be done before finalizing itself).

Won't pretend to know what needs to be done to fix it all, but from my own personal perspective I can't fathom being concerned with anything regarding Drupal 7 and probably won't be able to until I've got some productive months of being able to use Drupal 6 under my belt. This is NOT to say that current development for Drupal 7 is a waste of time - I do see the value of forward-thinking development, but I also feel there is a rapid rate of diminishing returns for it at the moment.

If there is any point to the above statements, it's that a) I don't think that I'm alone in my feelings and, b) I'm somewhat concerned about Drupal achieving an 'Emperor has no clothes' moment in the near future if these issues aren't eventually addressed.

The Advanced Theme Construction Kit, which integrates a derivative of the Yahoo grids CSS library within a Drupal framework, was updated and released for Drupal 6 today.

The Drupal forum.module has become, well, somewhat infamous for less than awesome scalability. Recently I had a chance to see this firsthand, and track down a solution for managing the long page load times for a client who has a highly trafficked forum. This was not a case of a site that was un-tuned - actually this particular site had a lot of good work and performance enhancements already done to it, including block caching and even some modifications to the forum module that were allowing to work better than it would have without them. But still 5-6 second page load times on /forum persisted.

I've been wanting to upgrade to MySQL 5 for a while now, and after hearing that MySQL 5 is required for Drupal 7 I decided to bump up my upgrade schedule, pronto. If all one wants is MySQL 5 then that is easy enough -- go download MAMP and you're done. But what if you want to be able to dev on MySQL 4 for projects that require it for whatever reason (e.g., clients who are run it and are not willing/able to upgrade MySQL at the moment)?

Well, with not a lot of effort - it very easy to have a PHP 5, PHP 4, MySQL 5, and MySQL 4.1 environment - all sharing the same doc root and servernames (e.g., urls):