Content Management Software - Build or Buy?

WallyHartshorn asks: "I'm the web coordinator for an agency (1,200 employees) with a web site consisting of roughly 2,500 static HTML pages, plus a few hundred Acrobat files, a dozen CGI scripts, etc. Currently, updates are done manually by a staff of 2 full-time web developers (including me) and 5 non-IT employees who have web page development as about 25% of their job responsibilities. We have been considering purchasing some web content management software, probably something on the lines of RedDot, eMPower, or Microsoft Content Management Server. We've also been considering using Zope or building something ourselves from the ground up. We only have two Perl programmers and nobody knows Python. Given the current budget limitations, we might have more luck getting permission to spend a few months writing our own software than we would getting approval to spend thousands of dollars on a pre-built package. On the other hand, I could also see a "build from the ground up" project turning into a maintenance nightmare. What experiences have people who run web sites of a comparable size had with building their own web content management software versus purchasing one? (Please keep in mind that we are not running a blog, a news site, or a community site, so something like Slash would not work.) Our content consists primarily of reference material and services.)"

Comments

Who is your authoring audience?

[dmorin]

There are at least two major reasons to use content publishing -- either it's just a convenience for the developers who otherwise would know how to fire up emacs, hack some HTML, and then ftp it to the server...or else you have an audience of content authors who, even if they do know how to ftp files, probably shouldn't, because it'll be IT's job to fix it when the process screws up.

If your case is the former, then you likely fall under the "scratch your own itch" category and could seriously benefit from rolling your own, because you likely know exactly what you need.

However, if you fall into the latter category, then I suggest looking at what's already out there, because odds are you're not going to be able to simulate all of the tools that your users want. For example:

• have you considered workflow? In many places content needs to go from an author through an approval manager, through compliance, before getting out to production, and you'll need a workflow management system to handle that.
• How about virtual documents? In most instances you'll find that your author has changed a dozen or so items and wants to make sure that they all get rev'd and workflowed as one big unit.
• Will you be integrating with existing editors like Dreamweaver? What about ftp, will your authors be able to ftp large amounts of content into your system?
• How will your alert mechanism work? When something has been pushed through to my area of approval in the workflow, can I get an email that tells me I need to do some sort of action? Can I perform that action simply by replying to the email?
• Something bad went out to the front page - a news story that turns out to be wrong. What's your rollback procedure?
• Speaking of which, how about backups? You can't take the docbase down for hours a day to do a backup, but you always need a full backup available because you'll have authors cranking out new content faster than you could imagine. How do you plan to solve that little dilemma?
• Do you have an object model and metadata strategy in mind? Will everything be just 'file' or 'page' or 'image'? Or can your authors create an object of type 'news story', which has attributes for 'headline', 'date', and so on?
• Oh, and don't forget drag and drop.
• And security. Group X can edit files of type Y in folder Z, but group Y can edit files only of type Z in folder Q.

Get my point? I've been tech leading an ecommerce team for about 4 years now using Documentum as the content management system for over a dozen production sites. Everything I mentioned above has been a question or issue at one time or another. I highly doubt you're in a position to buy one of the commercial packages, since all of them cost an absolute fortune (Documentum, Interwoven, Vignette to name a few). If you hadn't even considered most of the issues that I just put up there, then perhaps you should at least look at some of the better existing systems, because they most likely have, and when it turns out that you do need feature X, it's already there.

Re:Zope

[babbage]

I'll second this -- Zope is great stuff. I read a copy of The Zope Book from my friendly neighborhood library (remember those? they're grand... :-) and it's a decent primer on the system for two of the three audience types that'll be using the CMS: those doing presentation (web design, templates, etc), those doing content (source material that gets poured into the templates), and those doing logic (programming and sysadmin stuff). Unfortunately, the original commenter sounds like a programmer, and his is the audience that comes up a bit short in this book. Still, it does a good job of explaining why these jobs should be broken apart and how Zope helps you to bring them back together, and it fleshes out how this is done from several different standpoints.

Still, any shortcomings of the Zope Book detract nothing from the goodness of Zope itself. By default it gives you a nice, featureful web-based management system. "Web-based" can often be a hindrance (complex UI's over the web don't always work very well) but in this case you can get pretty far without having to screw around under the hood, so to speak. One thing to get to terms with is that Zope, written as it is in OO Python, gets to take advantage of a lot of useful, but sometimes confusing, object inheritance trickery. Like for example you can create a user account at a certain level of your site, and inheritance will allow that user's priviliges to cascade down into lower levels of the site but not higher ones. Kind of an obvious feature to want, but the details of how such things get fleshed out are subtle and worth trying to get your head around.

Like the commenter above notes, "it wouldn't hurt to learn a little Python". In many case you can just use Perl, but you may find in the long run that Python feels like a better fit for Zope anyway (seeing as the source code is largely Python in the first place). In any event, the semantic similarities between Python and Perl are much stronger than the semantic *and* syntactic differences you're going to see between Perl and the scripting language offered by most other CMS offerings. And you're actually considering Microsoft CMS? Please.... :-)

There are of course other good comments in this discussion, but this is the only one I see endorsing Zope, and I want to second that notion. If the first wave of dynamic web content was CGI, and the second was mod_perl, then the next one along that track seems to be Zope, which really allows you to work at a *much* higher layer of abstraction (which is of course a good thing, and for the same reason that almost nobody writes web stuff in C or assembler). Zope offers a rich high level toolkit -- object persistance (that you might even prefer to standard DBMS storage, though it's there if you want it), templates (some tending towards "HTML with code", others towards "code with HTML"), a mechanism for distributing your content across multiple servers,security controls, etc. It would take *a lot* of work to reproduce all this functionality in-house, and even if you did it would be hard to guarantee that it was as robust as Zope (or, to be fair, many of the other CMS offerings).