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

Zope

[Big Sean O]

I know, I know. "Nobody knows python". Zope is fairly mature, so you can run it and do a lot without getting under the hood and mucking with the source.

Also, Zope allows you to write scripts in Perl or Python, so you can implement site logic you need in a language you already know. You can also use it to connect to existing databases.

Plus, it wouldn't hurt to learn a little python.

Zope will take out a lot of the busy work of rolling your own and you can concentrate on customizing it.

The Zope Book is on-line and the software is free, so the initial investment is just you time twiddling with it to see if it meets your needs. I looked at it this spring, but it was overkill for the project I was working on.

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

Content management is a bear pit....

[PinglePongle]

I was the development manager for a big site using Vignette as a content management system. What they don't tell you when you buy these products is that you will inevitably invest a huge amount of time in customizing the application for your requirements, and that - at the end - it will still not feel "quite right".

Besides the purchase price, you have to assume you will need signifant training and/or consulting support, and you will inevitably end up rebuilding your site from scratch to fit into the new framework. The standard consulting fee seems to be roughly 10 times the cost of the software (amazing how that always seems to work out...).

If your content creation processes are in any way complex, you will spend a significant amount of time and effort trying to create a tool that facilitates or at least accomodates this process; if workflow features are expected, you will have a serious amount of work to tackle.

You will also need data entry time (or at least the ability to convert all the exising content into whatever format the Content Management Server expects) for all 2500+ pages.

If what you're doing can be classified as business critical in any way, you will need at least one administrator for the Content Management System and whatever database it uses.

Because content management systems involve a lot of "dynamic" activity when serving pages, it's common for them to experience performance problems, so you may need to invest in additional hardware to serve the same number of pages. You will definitely be looking at how to cache your content - this is a whole bundle of joy in its own right.

In short - make sure you want to go down this route ! It may free you up from the tedium of cutting and pasting into a static HTML file and FTP-ing it, but instead you'll be feeding and watering this content management beast.

Unless your company makes its living from its content, the costs are unlikely to be recouped.

Of course, if you want to do it, I would suggest writing one from scratch; I'm working on a JSP/servlet based content management server right now, and it's a lot of fun.

N

Perl solutions

[m_ilya]

Since you have programmers who know Perl it makes sense to go with Perl solutions. I don't know your needs so I'll give your several choises.

• Bricolage
• Everything
• TWiki

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.

Get the best of both worlds

[Evan]

Hire Zope Corp. to build your CMS for you. That way, all of your money gets spent on training and development rather than licenses, and you end up with a completely Free solution that you can extend and maintain yourselves.

I'm surprised at how little attention Zope Corp. gets when people are discussing Open Source business models. They've gotten fantastic growth and exposure, to the point where they are regularly beating the likes of Vignette for contracts, by Freeing their core software. While they do sell support, that's not their primary source of revenue. They make money by building web systems and CMS applications using Zope. The fact that Zope is free (both ways) is a powerful selling point when used correctly, coupled with the fact that the engineers at Zope Corp. are naturally the most experienced Zope developers around.

(disclaimer: I worked for Zope Corp since back when they were Digital Creations. Great folks!)