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).

SixApart's ears must be buzzing with all the talk about TypeKey lately. Mark Pilgrim writes some pretty sharp, lucid and hilariously written criticism of SixApart's plan to provide a centralized comment authorization service as a method for preventing the comment spam. On his Musings blog, Distler's calls it a lot of bother, for not a lot of benefit. Burningbird dives much deeper into why this is not a great idea. Everyone's concerns are valid. Centralized authentication may not be the right way for SixApart to go. I'm happy that Drupal requires authentication on my server. Preventing anonymous and unregistered user comments takes care of the spam issue. While I'm not sure that everyone thinks any kind of authentication is a good idea, it does prevent us from having to deal with comment junk.

In the end, will this matter to users of SixApart's applications? I would say it will matter a lot to people who use MovableType sites and care about this issue philosophically. For one, this means providing even more of your personal information to people you cannot be sure will protect your interests. What happens to all that information if SixApart ever gets purchased down the road? Secondly, why should anyone have to install a blog application relying on some external service for comments? That's really the only reason I like MT over Radio. If I install some content publishing system, I want control of it -- all of it, including the comments. Burningbird talks about more reasons why this doesn't make sense technically, but for me, ownership and control are the issues that would make me opposed.

I'm sure there will be many casual bloggers who won't think about this issue on a philosophical level and will just use TypeKey to prevent comment spam. But this solution is not the one they were necessarily looking for. They just want to prevent junk appearing in their comments (or a good way to remove the junk), not to require their users to go register somewhere for the privilege of commenting.

It's a hard call for SixApart at this point. One way they can go without requiring centralized authentication is to require registration on each MT site. That way the personal information of the commenters is registered with an individual site, but not sent over to SixApart. This does place a lot of burden on the part of the blog reader, and I can understand why people are against that idea. Many of us read 10s to 100s of blogs a day, so all that registration would mean added work. The ease of entering comments on MT sites is often cited by MT blog users as a reason to like MT over Drupal. But that was before comment spam crashed their party.

One question that lies at the heart of the matter for me is whether or not centralized comment registration is a bad idea for weblogs in general. I agree that, for instance, Microsoft's Passport registration was a pain in the ass, but a remotely accessed authentication doesn't seem a bad idea in theory. On the one hand, central control of your information by a commercial entity is probably not appealing to many bloggers. On the other hand, a single registration/login XML/RPC method would mean a flexible sign-on system a bit similar to what we have across Drupal sites. Well not really similar, but from a user perspective it could be similar. Drupal's is more of a decentralized model. The registered login can exist on any site in Drupal's network and not necessarily on one. Gary Murphy talks a bit about how Drupal distributed authentication works in comparison.

I guess it all comes down to trust. Do you trust that if you give SixApart your information that it will always be secure and never used for any commercial purposes?

Wow. There is an installer file for running Plone on an OS X machine. Sweet. Installs Zope and everything and gives you a start up icon.