Last year I had the privilege of speaking at the Chicago CMS Expo, a yearly event that brings together experts from a variety of open source communities for learning and collaboration. In 2009, Joomla!, Drupal, and Plone folks had some great training and education tracks as well as interesting business sessions for the suits.

This year, WordPress has been added to the mix and the Drupal track features quite a few community luminaries. I'll be there in May along with Larry Garfield and Colleen Carrol of Palantir; Emma Jane Hobgin, co-author of Front End Drupal; Doug Vann and Matthew Lechleider; and Volacci's Ben Finklea. I've also heard a few rumors that a big name in the Drupal universe will be talking about the future direction of the platform... The list is pretty impressive and I'm looking forward to connecting, teaching, and hanging out with folks from various CMS communities.

If you're in the area and are interested in kicking various platforms' tires, it's one of the few events where you can hear experts from several CMS communities, rather than a few token visitors at an event dominated by one product. In addition, CMS Expo's banners are a pleasant, soothing shade of aqua. Check it out!

The rumors are true. I've gone over to the dark side. While this site -- jeff.viapositiva.net -- is still running Drupal until I can migrate all the content, I'll be moving over to a new streamlined blog over the next few weeks. That blog will be running WordPress.

Why? Have I abandoned Drupal? Of course not. I spend a lot of time working with Drupal -- building sites with it, helping clients figure out solutions to esoteric problems, writing new tools for other developers... It's easy, though, to get tunnel vision. When I joined the Drupal community a little over four years ago, I was an outsider. I'd been working on Windows software for years, and had spent time with tools like DotNetNuke, Rainbow, Xoops, Movable Type, and TikiWiki. Drupal's approach to solving problems like organizing content was a breath of fresh air. After some time juggling multiple CMS platforms, I made the 100% switch and never looked back.

During the first couple of years of my involvement in the project, I drilled deeper and deeper, submitting patches for modules and then Drupal core itself. Eventually I was rewriting key pieces of the core software itself and working closely with the Drupal ninjas who'd started the project. It's pretty thrilling to get involved, become knowledgable, and have an actual hand in shaping a tool that you love to use.

So, why the switch on my blog? Two reasons. Simply put, the Drupal community's biggest weakness is its insularity. The folks who are most knowledgable about Drupal, and spend the most time building and enhancing it, are the least involved in other projects, the least likely to be getting first-hand experience working with other tools like Wordpress, Django, Joomla!, Ning, and so on. There are exceptions to that, of course, and even a degree of tunnel vision isn't unique to Drupal. Matt Mullenweg of Wordpress fame isn't spending his days cruising the CCK issue queue, after all.

But as we look to build and improve Drupal, it's critically important that we keep our field of vision wide. When we talk about improving the Drupal administrative user experience, are we carefully studying other tools' solutions to the same problems? Are we just skimming screenshots and feature lists, or are we using those tools and becoming familiar with how they work in addition to how they look?

Beyond the goal of improving Drupal, there's a second reason. It's easy to allow my familiarity with the platform to blind me to better solutions; after all, I'm the guy who cloned Twitter in Drupal just to show it could be done. The fact that a Drupal expert can do something with Drupal doesn't mean that they should, however. Forcing Drupal into tasks it's not well suited for is like using a Swiss Army Knife to cook breakfast -- it demonstrates flexibility, yes, but it's also pretty frustrating. If my goal is to blog, quickly and simply, why not use WordPress? It's designed specifically for that task, and it does a great job.

Over the next few weeks, as I embark on my migration, I'll be posting more about my thoughts and experiences with the new platform. It should be quite the adventure!

Over the last year or so Drupal has gone through some growing pains. As more new users have poked their heads into the Drupal-tent to check things out, the long-simmering conflict between 'Drupal as a very customizable CMS' and 'Drupal as a framework for web-CMS developers' has become more apparent.

Developers are frustrated by the addition of features to Drupal Core that only appeal to end-users, and 'bloat' the underlying engine. Site admins looking for a tool to run, say, a forum, are frustrated by the emphasis on APIs and hooks rather than actual solutions in Core.

Ber Kessels is one of the 'inner circle' of Drupal developers by virtue of his contributions to the system and the level of activity and involvement in the system's ongoing development. He's recently started blogging about his experiences tinkering with Ruby On Rails, and what Drupal could look like if it transformed into a similar developer-oriented framework. Obviously, the 'core' Drupal build would stop being useful for Joe Schmoe looking to set up a web site. Instead, he'd use task-specific Drupal distribution that rolls together Core, appropriate contrib modules, themes, and whatever glue is necessary to make them work nicely together.

If that approach were taken, what should be part of the Drupal Core? Here's my stab at a list.

block.module
filter.module
node.module
page.module
path.module
search.module
statistics.module
system.module
taxonomy.module
user.module

These modules are a rough approxomation of what Drupal Core has enabled when freshly installed. Modules that cater only to multi-user community sites (blog.module, tracker.module, forum.module, and so on), and modules that cater to bloggy conventions (comment.module ping.module, and archive.module) have also gone poof. Throttle.module? Better to put it in a collection of modules and tools for high-traffic sites. Aggregator module? It's cool, but core doesn't need it. Same with Blogapi, Book.module, and so on. Page.module stays because (I suppose) it would be nice to have SOME default node-type, and the standard 'page' concept is pretty universal. It might be tossed, though.

Themes? Bluemarine, with its CSS file stripped down to remove the reams and reams of cruft necessary to support all the older core modules. Other modules would be responsible for including their own CSS, rather than depending on core. For developers, it might make sense to bundle dba.module and devel.module with the core distribution. Those are already must-haves for anyone working on the development side of a Drupal site, though most application-specific distributions wouldn't include them.

What's the end result? A relatively vanilla-looking web site engine with a lot of APIs and not a lot of UI. In my next post, I'll toss around ideas on how the rest of the modules currently in core would find a home, and what third-party contrib modules would complement them in various application-specific Drupal Distributions.