Jeffrey Veen doesn't like open source CMS (OSCMS). He succintly states the most common of purpose of a content management system -- a statement that I agree with completely:

Ultimately, a content management system should be designed to empower writers and editors to do content creation and maintenance themselves. I'd like to see it take a step further: empower designers, information architects, and site owners with the ability to make the CMS work for them.

I couldn't agree more. These are the primary purposes of content management systems -- to allow content authors and managers to publish and manage content. Problem is many OSCMS are designed by and for techies. There is often not enough attention paid to designing for typical content managers, who are not usually technical people, but are people who want to work with a content publishing and management tool without needing to know how things work in the background.

The "of and by the programmers" characteristic is almost an inseparable part of most open source projects. The reason is obvious really. Open source projects are often created to fill a developer need and to provide a community for building the project together. The community codes what they want in order to serve their specific needs as developers who will use what they produce. OSCMS are therefore often unrefined tools until you have a programmer or consultant customize it to suit your needs. And although this probably generally true of OSCMS, I think these systems can be made to be more content manager-friendly without too much effort. But making it friendly enough for everyone seems to be difficult for developers of open source projects, and I can understand why they might see little incentive for doing this.

Take Drupal, for instance. At a high level, a few of us -- including some very talented and well-known web designers -- outlined how certain areas of Drupal could be made more usable. We documented these suggestions on my wiki. Some people wireframed and flowcharted the interaction of some of the components. Some of these suggestions seem to have made into the next release, but apparently not all.

I guess it's hard, with a community-driven effort, to simply make a suggestion like, "Installation should be driven by a wizard following this scenario" or even "Here's the flow and wireframes of the corresponding UI for function x. Go make it happen.". It's just hard to keep all these issues in mind. Dries made an offer to Jeff that he would get behind what Veen might suggest in a design review and make those changes happen. I'd like to see that happen. But I don't know. Adaptive Path exists to make money. Veen would have to buy into the idea that something like Drupal could be a tool they can exploit in their paid projects. But it should be obvious that getting behind it's design and helping guide how it works will mean they get to use a CMS created to suit the needs they try to meet in customer projects. He's first gotta believe that it's a tool worth backing.

I don't have a pitch for Drupal. I use it because I think it works well and I know how to configure most of what I need. Anything more and I usually get some decent answers on the Drupal forums.

Here's an example. I've been working with a customer to develop a document library. Take a look at these wireframes for the project (PDF, 84K) and then come back here. Really simple requirements for this project. Using Drupal 4.5, users are maintaining a repository of support documents. So far so good. These people hated using QuickPlace and we're finding that Drupal is a capable replacement. We can make it more usable, but the reason it's a viable tool is because the required functionalities are there. But it won't be usable until I get under the hood and customize how it looks and feels to the end user.

In my work as an in-house developer and IA, I've generally found that tools unfortunately *do* require both a designer/IA and a programmer to make them usable. They're very often created to suit some common-deonminator of needs, and therefore don't suit any specific needs very well until they're customized. This is perhaps one of the reasons groups with a programming staff might want to build versus buy. What you have with some of the OSCMS available to you out there are merely platforms -- they're only lumps of clay waiting to be molded into things of utility. That said, I believe a lot of the things that Jeff mentions are useful but perhaps not universal. Looking closely at my users' needs (in my case above I look at public users, moderators and administrators) helps me decide where to tweak the tool to make it more usable depending on levels of access (roles).