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

Commercial content management systems

[fuzzbrain]

The main determinant in your choice shouldn't be cost but finding a system that meets your requirements. In addition to their price, alot of the big commercial content management systems are aimed at big commercial sites. For smaller sites, you're better off writing your own system or using an open source system.

Roll your own...sorta

[galaxy300]

I just went through the exact same decision process and we decided to go with a custom solution. We were going to pay to have one of the big packages customized anyway, so in terms of cost it was a wash. By building our own, we were able to control costs more closely and only implement the features that were most useful in the 1.0. We ended up selecting a developer who already had a library of customizable tools, so we don't pay the full development costs up front and the best thing? The source code is provided to us at the end of the project.

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.

cost of software + customization + training = $$$$

[kootch]

add the title up and you're probably spending 2 to 5 times more than you initially thought. and for what? a program/system that was modified to try to accomodate your needs.

what would be much more cost effective would be to sit down with a dev house (such as mine), determine a project scope, and roll your own open source solution.

why:
1. the cost will be less than the package you buy such as RedDot (which is awful, lemme tell you
2. it'll fit your needs better since it was designed for your needs
3. the code will be available for you to tweak down the road if necessary
4. there will be less training time and installation time required
5. you will have a company to call on for assistance or thousands of programmers available that could modify the system (since it is open source)