Slashdot Mirror


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

4 of 77 comments (clear)

  1. Open Source Content Managment Conference by fuzzbrain · · Score: 3, Interesting

    I was just doing a quick search and found that there was recently a conference devoted to open source content management systems. A look at the conference agenda points to a number of interesting projects. Wyona and Bitflux sound especially interesting.

  2. Re:Zope by babbage · · Score: 5, Interesting
    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).

  3. Get the best of both worlds by Evan · · Score: 4, Interesting

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

  4. We rolled our own... by Richard_at_work · · Score: 2, Interesting

    The company i work for had a huge problem with information being lost, and a long standing solution to this was the development of a company intranet.
    Now we have a intranet that can handle almost anything you can throw at it, pdfs, word docs, excel files. The best thing is, its all due to the "bad" integration between office and IE. choose to view a word doc and it opens a word session inside IE.
    The actual intranet is nothing more than a PHP/mysql website on a small piii box. Took a month or so to develop and everyone is happy with it.
    As for being a maintenace nightmare? not really, its all documented, has its own api due to being OO coded, and not a lot needs changing anyway. Besides its a modular syste, cant work out howa page works, but know what it does? then replace the page.