I've mentioned in passing that we've been looking into new systems to replace the aging hardware that runs TidBITS (all our servers use pre-G3 PowerPCs) and cobbled-together software (FileMaker, Lasso, HyperCard, AppleScript, and Retrospect). The hardware decision is easy - an Xserve ought to do everything we want and more, and it will slot nicely into a rack at digital.forest, our server hosting service. But the content management software is another story.
A content management system is a collection of programs for storing, managing, displaying, and archiving various types of content. A full content management system generally includes a database for storing the content, middleware software for extracting and presenting the content, and a Web server for the actual serving. We have articles, polls, and TidBITS Talk messages, along with collections of those items in issues, article series, and message threads. Plus, we publish our content in different formats (setext, HTML, RSS, and more) and in different venues (email, Web, FTP, Usenet news, and so on).
The need for a content management system has become increasingly common as the Web has matured. Content producers realized they needed tools that help put content on a single Web page (Claris HomePage or Symantec's Visual Page, for instance). That expanded to needing tools that help manage an entire site (Adobe SiteMill or the modern day Adobe GoLive or Macromedia Dreamweaver). Now, however, many needs have grown once again to include software that helps to manage content on a regular basis, simplifying the process of adding new content, archiving old content, and providing access to both old and new content in appropriate ways.
Everyone's needs are different, of course, but the need for some sort of content management system turns out to be remarkably common. Whether you're an individual trying to maintain a personal weblog or a business trying to maintain a catalog of your products, you need a content management system. That's why so many software packages call themselves content management systems. Some are designed for local newspapers, while others aim at providing information systems for entire college campuses. Some are so proprietary that you can use them only if you contract with the developers to build and host your system, whereas others adhere to open source precepts (unfortunately often including the one about documentation being for losers and fools). Add in a myriad of blogging programs and you can see how difficult it is to find the perfect content management system for a particular purpose.
After long discussions about how to plan and create our new content management system, Tonya and I finally decided to work with our friend Keith Kubarek, who had spent 16 years working at Cornell University but recently left to concentrate on his Web design and development company, One Bad Ant. The process has been going well, and it's been tremendously helpful and educational to watch someone else try to figure out precisely what TidBITS does - we're too close to our systems to view them objectively. Keith's business analysis of what we do was particularly interesting for the way it helped us clarify not just what we do now, but those areas in which we hope to do different things in the future.
Initial Technical Analysis -- Now that we've completed the business analysis, Keith has moved on to the technical analysis, in which he's evaluating existing content management systems to see which deserve further investigation and possible adoption for some or all of our eventual solution.
What are our primary needs? Along with the basics of storing, managing, displaying, and archiving content, we need features like rock-solid integration with email for issue distribution, user account management so users can manage their own subscriptions, links between articles and between TidBITS Talk messages, management of sponsorship appearances, unified circulation statistics, support for different issue formats and venues, integration of PayBITS, and more.
Trying to figure out which content management packages provide these features (or can be extended to provide these features) is a Herculean task. Luckily, we were able to eliminate many of the seeming contenders based on two simple criteria.
Platform. We will be using a Macintosh and Mac OS X. Others need not apply, and if Unix developers couldn't be bothered to state clearly whether or not Mac OS X was supported, they were dinged instantly too.
Price. We're not opposed to the concept of spending some money, but only within reason, so we ditched packages priced above $2,000 right away (some ran as high as $50,000!). Other pricing problems included annual fees and traffic-based pricing schemes, since our income isn't directly related to our level of traffic.
Narrowing the Field -- After that initial level of winnowing, we applied additional criteria to narrow the list further. These criteria weren't as all-or-nothing as the previous ones, but if a program failed on several counts, it fell off our list.
Basic coherence. If we couldn't figure out the basic capabilities of the software from its Web site, it was hard to muster enthusiasm for using it.
Documentation. Some programs came closer to being dropped from our list thanks to poor, incomplete, or non-existent documentation.
Email. Many content management systems look no farther than the Web, which may be fine for others. For us, though, email is essential. We don't necessarily expect full mailing list capabilities, but we need some way to send content to subscribers via email, manage subscriptions, and handle bounces.
Customization. This one's a balancing act. We don't want to shoehorn TidBITS into some other publication's mold, but at the same time, we don't want to spend huge amounts of time or money on a custom site written for us from scratch.
Available knowledge. All other things being equal, we'd prefer to use a system that others who we know are also using so we can learn from them or get help as necessary. It's even better if those experts are people who read TidBITS regularly and appreciate what we're trying to do. Open systems generally win out over proprietary systems in this regard.
Maintenance. We want to spend our time researching and writing, not baby-sitting our server. Simply running on an Xserve in Mac OS X should do away with some of the problems we face now, but we don't want to sign up for more if at all possible.
Stability, reliability, and performance. Determining how any given application performs in these respects ahead of time is tricky, but we'll look more at these criteria as we get closer to final candidates.
Current Contenders -- So here's where you come in - after all, TidBITS readers are the people who will use whatever we end up creating. We've come up with a short list of packages that deserve additional investigation, but we're under no illusion that we've even identified every possibility. If you know of something else that might fit our needs, let us know and we'll check it out. Similarly, if you have educated opinions or deep knowledge about any of these packages, we'd love to know that as well. I plan to be holding these discussions primarily via TidBITS Talk (please send comments to <tidbits-talk@tidbits.com>), so if you want me to keep your message private, just say so and send it to me personally. Here's the list.
Aegir is an end-user content management system based on the Midgard development framework, which in turn relies on Apache, MySQL, and PHP. Although Aegir doesn't talk about Mac OS X specifically; Midgard does, so we assume both should work.
<http://www.aegir-cms.org/>
<http://www.midgard-project.org/>
Bricolage is currently used by Macworld magazine as their content management system. It uses the PostgreSQL database to store content. Bricolage is actually built on Mason, which is a Perl-based Web site development and delivery engine.
<http://www.bricolage.cc/>
<http://www.masonhq.com/>
Cofax is an open source package developed originally for Knight Ridder's newspaper Web sites. Although Cofax's Web site doesn't talk about Mac OS X specifically, Mac OS X-compatible software like MySQL and Mac OS X's Java implementation should be able to meet its requirements, and it was sufficiently interesting to warrant a closer look.
Blue World's Lasso now works with SQL databases, including MySQL. We currently use Lasso with FileMaker Pro, so we might be able to reuse some of that code. Lasso also has tight integration with Dreamweaver and GoLive, which could prove useful.
PHP-Nuke and its offshoot PostNuke are weblog/portal/content management systems that run on PHP-enabled Web servers. They can work with a variety of databases, including MySQL. Both offer numerous pre-built modules for specific functions like polls, searching, site statistics, and so on.
<http://www.phpnuke.org/>
<http://www.postnuke.com/>
Xoops is yet another PHP-based content management system that can sit on top of a variety of different databases.
Zope is a Web application server written primarily in Python. It includes its own Web server, but can also run on Apache. A content management framework is available for Zope, and a full-fledged open source content management system called Plone runs on top of Zope and its content management framework.
<http://www.zope.org/>
<http://www.plone.org/>
4D is best known as a database, but the current version is actually an application development and Web development environment so it might be able to meet our needs.
The Next Step -- We realize that the current set of contenders represents a jumble of options for scripting languages, underlying databases, and supported technologies, and our heads are spinning as we try to analyze the possibilities. So tell us what you think, and we'll be sure to write more about our progress.