This panel consisted of three people implementing open source content management systems, one trying to figure out what to do, a very smart guy from the W3C and, um, me.

Jennifer Lynch (U. of Missouri), has been implementing a Typo3 system. She and a colleague have built a substantial system in just a few months for a total cost of $5,000.

Marc Lavallee has been converting Boston.com to Zope. Twelve people have spent a total of 14 months (including a four month RFP process) building a system that will go live in ten days. He figures it is about a million dollar project, all costs included, a figure substantially lower than what it would have been had he been using commercial, proprietary software.

Hal Roberts from the Berkman Center has been installing a WebGUI system, which entails importing 175,000 static pages. He chose WebGUI in part because of its object orientation and because it lets you edit pages on screen, not in a separate editing mode.

Sam Quigley, of the Harvard Art Museums, is trying to figure out how to figure out which system to use. This raised the question of the value of consultants. I said I thought they could be helpful. Hal replied that it’s continuing expertise that ought to be brought in house. The audience had diverse opinions. I personally don’t disagree with Hal; in-house tech expertise can be crucial, especially if the project is big enough. But a consultant who keeps up with the field for a living can help match the application needs to the right application faster and better. (No, I do not consult in this field.)

Then Dave Winer sparked controversy — shocking, I tell you! — by saying that it’s like the early days of word processing when everything was hard and expensive. It shouldn’t be as technical as it is. It really should be a $200 solution, he said, that does the 80% of what actually needs to be done.

Hmm. I don’t think the users on the panel could get what they need in that 80%. They’re not looking for a desktop application like word processing. To them, CMS is a system, and it does something complex that will only get more complex. It manages documents and document fragments. It provides versioning. It handles permissions. It moves stuff through workflows. It worries about archiving and records management. It automatically lays out pages. It provides editing tools for content and for styles. It serves up personalized pages. It tracks hits. It enables cash transactions. It plops ads onto pages based on who’s seeing them and accounts for every view and click. It integrates with the rest of the office software environment. And if it doesn’t do all those things now, that’s where it’s headed.

We got a demonstration of why CMS will remain complex software. Someone in the audience asked if it’d make sense for his small college to get together with a bunch of other small colleges and come up with a set of app requirements so that they could share the cost of customization. The general sponse was: “It sounds like a good idea, but… ” For example, Hal and Marc both said that their own installations were unique. Someone in the audience agreed. I pointed out that this reminded me of the SGML wars of the ’80s when entire industries tried to build a shared DTD. It turns out that everyone’s needs and vocabularies are different enough that trying to produce a common spec is extraordinarily difficult.

Now, it certainly can get easier. I spoke afterwards with Bob Doyle of CMS Review who is trying to come up with CMSML, a way of describing CMS features that would work for all content management systems. Bob knows that there isn’t one ideal and perfect way of doing it, but believes that you could at least make it easier for customers and users to compare systems.

CMS is inherently tough and complex. Implementing a CMS system is always going to require someone with strong skills because it touches the way an organization thinks about and handles documents. It will always require looking at document processes, the social structure, and the power relationships in an organization. It requires understanding the legacy “document schema” and looking ahead to the near-term and long-term futures. CMS will resist commoditization for as long as I can see.

Which leads me to conclude: Did I misunderstand Dave’s comment? Do we disagree about the definition of a CMS? Or do we just disagree? Unfortunately, I’m about to leave for Chicago – the Digital Genres Conference – so I’ll be out of contact for the rest of the day…

Categories: Uncategorized dw