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.)"
I love the idea of a roll your own solutions, but you are right about the cost involved. If you have no experience with a commercial tool, then you shouldn't even try to roll your own. I trusted my code to be in working order, QA tested the product for more than a month before it went production. Soon after they approved it, we lost 7 months worth of historical documentation. The only copy of our web content, was what was sitting on the web server the day my rolled CMS died. I have rewritten the code, but I'll never get a chance to test it. we now use a tool called CCC/Harvest. It's a great tool, but it's also more expencive then free beer.
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.
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.
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.
My father is a blogger.
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.
seriouslyexcited.net
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
It's all very well in practice, but it will never work in theory.
--
Ilya Martynov (http://martynov.org/)
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:
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.
www.HearMySoulSpeak.com
You should outsource your job to a qualfied vendor to do the work for you. It will definatly cost less then developing it on your own plus that frees you up to handle the rest of your responsibilities.
I just so happen can recommend you to a great vendor that can definiatly handle your needs. The vendor is called Navistream Corporation (http://www.navistream.com). Let them know that RedWolves2 sent you.
Good luck on your project.
All good comments but the bottomline is that there is no "one size fits all" when it comes to content management. Take the time to get your workflow and requirements outlined (or get someone else to do it) then do a thorough selection and evaluation process, pit the open source stuff against the commercial offerings by using a weighted evaluation model(requirements carry different weights and the solutions are scored on their ability to meet a particular requirement). The overall scoring will knock out the solutions that don't come close then put the finalists in a celebrity deathmatch/vendor bake-off)and then make your (informed) selection.
.pk
You might want to take a look at one of the ASP-style CM vendors. The advantage is that you have a solution right away, but since it is an ASP, you don't have to use any capital budget to get it. The costs are all expensed. The one company that I have direct experience with is ATOMZ. One of my clients is using them to rebuild their site of around 4000 pages. It's all web-based (which can be a double-edged sword) and includes workflow functionality, so that content creators can be assigned specific tasks. Their templating language is reasonably easy to learn but does have a few drawbacks such as a dearth of control logic.
You might have a look here. That's a (Free Software|Open Source|Whatever) CMS (licensed under GPL), very professional, and with a host of features. It's very promising (although a bit oversized in contrast to simple blogs like SlashCode or DaCode : you'll need a library, an Apache module, etc.). Still, I haven't had enough time to test it correctly, so I won't comment on how well it fares...
:-)
Oh yeah, and it's PHP4, so if you only know Perl, you'll need an adaptation period. But I don't think it really matters: PHP is damn easy to learn, especially if you already know another programming language (really! Two weeks were enough for me to build working sites, and saying I'm not a genius is an euphemism
Xenu brings order!
- Whenever possible, use an off-the-shelf product, and a mature one if available. Advantages: It has evolved, and there's a community of users out there to help you via forums, mailing lists, and so on.
:)
- Looks like you've got a total of 3.25 virtual people maintaining about 1000 pages apiece. I worked on a project of roughly this order of magnitude by myself, and it nearly did me in.
- When content contributors do their own page production and uploading, standards can go out the door. Basically, you have to control their access severely. This has always been true. I've seen camera-ready copy that an engineer has run through his typewriter to "correct"--at NASA no less.
- Don't forget low-tech alternatives: for instance, photocopied forms which your content generator co-workers fill out and pass to you. Since your site consists largely of reference material, the pages are probably pretty standard and tabular. Whether this would work depends on factors like the number of pages/week that need updating.
- Mid-tech: set up some strictly controlled forms in Word on a server, used the same way as photocopies, only you can generate the HTML straight from Word (then use another program to clean it up, of course--Dreamweaver does this, among others). That might be a function for your Perl programmers--let the employees "Save As HTML Document," and upload. Then you run everything in the upload directory through a de-Wordjunk script periodically before it goes live. You would have to look over the results, but then no program no matter how expensive removes the need for quality control.
- I hope you're already using style sheets
- It all depends on how many people need to modify page content and how often.
I would suggest looking at Boa constructor as a tool to manage Zope sites. It has "Sophisticated Zope object editing integration" made simple.
Give it a try! It also has superb debugging capabilities...
Here and here are some screenshots of the Zope editing capabilities of an older version of Boa-constructor.
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)
I think the second link should be: here
Because unless you personally do it yourself you'd have to be riding herd on a programmer or a team of programmers as well as 3000 web files and a company full of content producers.
You'd have to make them:
- Write something with the features YOU want and not the features they think would be a good idea.
- Stick to a deadline.
- Design an interface that your content contributors find intuitive, navigable, and non-ambiguous--unless you want to go into the training business too.
It would be worth several tens of thousands of dollars not to have to do this.
Disclaimer: I like programmers. I respect programmers. I enjoy working with programmers. But I don't have illusions about it being easy.
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!)
I have to admit. I've always hated IDE's and code generation tools, until I tried out CCS 1.16 and 2.0.
Now, CCS Studio really looks like a professional environment that could probably cut your coding down to 1/5, perhaps to 1/10.
It also does some content management.
In our company I've got a slightly more aggravating problem. We already had a mature piece of CRM software which had been developed in shop. Next our management decides that they really want a commercial product so they go out and purchase ACT (with the WiredContact package that allows for web use without client side software needs)
Did they ask us if we could add the requisite features to our existing sytem? No. Did they check to see if maintaining synchronicity between the two systems would be manageable? No.
ACT! does provide an API for communicating directly with the ACT database (which BTW looks kinda like an Access DB but really isn't) Unfortunately this API is in C so to access it from our Java code I need to write a semi massive amount of JNI. Not to mention the fact that synchronizing two systems that contain slightly different datasets presents all the usual problems of "Who's authoritative?" "Does maintenance have to be frozen on the old system to account for synchronicity?" "How often do you synch-up? Constant? Daily? etc."
We could have very easily added the additional features they wanted as well as coding a web interface for easy on the road access with significantly less expence than the ACT! package and built on top of an existing stable system that wouldn't have to deal with the sychronicity issues.
Management.. SMACK! ow.. I'll go back to my cave now.
You may want to try out AxKit. Its probably better geared for your environment. Its relatively small, it is also perl based.
Archie - CIO-for-hire
Build it inhouse, just make sure you get the design/concept right before any code is written. I can't imagine a project like this taking very long after design stage has been established!
We're currently trying Slash. It's horrible in its own ways, but if we can make it a bit less ugly then at least it'll generally stay up.
Squishdot and Zope: JUST SAY NO.
http://rocknerd.co.uk
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.
While still in its beta-development phase Postnuke is proving to be a secure and interesting open source CMS to keep an eye on.
They also have a smaller application called Torpedo (also open-source .NET) which is suitable for weblogs, small business sites, etc.
Got Rhinos?
This is important for a couple of reasons. One is the obvious one: different CMS applications have different needs. But conversely, they also share needs. Which is why you shouldn't limit your research to specialized web CMS solutions. There are generalized CMS platforms that can be easily to web applications, and might be good compromise between off-the-shelf and roll-your-own solutions. Also a good choice when there is no off-the-shelf solution for a particular CMS problem, which is often the case. Documentum is the leading vendor of these, but it has many competitors.
I know this sounds really simple, maybe I'm not getting something. But I've helped set up a couple websites with just CVS and a few scripts to update the content. It works for scripted stuff and static pages just fine. It wouldn't be so good for a news site, but it sounds like just what you need. Plus it's simple for anyone with unix experience to set permissions and stuff so that people don't go updating things they shouldn't. We didn't even need perl, just plain old shell scripting.
Look at openACS. Its a fast evolving toolkit, with a lot of features out of the box. The current project website is not the best looking, but the toolkit has been used to develop a lot of interesting sites.
Methodology ... shake the customer by his feet and see how much money falls out, then charge another $50 000k for support.
If I were you, I would stay away from the Vignettes and other off-the-shelf CMSs. To paraphrase Phil Greenspun, these guys pricing works along the lines of
I would also not be in a rush to implement a totally custom solution. Building from scratch is usually a dumb idea(tm). No point in reinventing the wheel. Having said that there is a slight difference between a Michelin-clad Ferrari wheel and a 0BC Roman chariot's wheel...
I agree with you, do not go for the slashdot look. That virtually rules out most of the nukes (phpnuke, postnuke, drupal, slashcode etc). It is
so boring
so overused
suitable for weblogs and news sites but not for more mainstream content sites.
oss is good ..... just for good measure.
The beauty of using OSS toolkits is that you get a head start. If any consultant (read salesman) tells you that their product fits your needs perfectly, then a. shoot them, b. chop them into little pieces c.feed them to the snakes d. shoot the snake
The best that you can hope for is to have a basic and solid foundation that you can build on.
decisions
Some of the things to look for include the following:
For each toolkit, look at sites that have implemented it. If they *all* look the same, steer clear. Its a sure sign that templating was poorly implemented, or that the toolkit is difficult to customise.
Post a couple of questions on the boards. If the tone is friendly, then you know that if you did pay these guys to do work for you, the service would be great.
If you are building a proper CMS, its going to be painful.
and you win an all expenses paid tour of some of the sites built using openACS and its cousin ACS classic.
Live today. Tomorrow will cost a lot more!
I'm at a large media company, and we've had nothing but nightmares attempting to implement a purchased CMS. Along with the CMS, we also contracted with the vendor's recommended integrator to help us set the system up.
The integrators are competent, and the system is ok in a generic way, but we are not a "generic" shop -- and I don't think any shop really is. If we had simply set aside a few months for one of our in-house developers to build the system from scratch, based on our needs and environment, we would have exactly the sort of functions that we wanted, plus have easy extensibility. Instead, we've spent almost two years, and an enormous amount of money and manpower, on this system and we still have almost nothing in production that uses this system.
One reason that we were pushed to purchase this outside system was that the non-technical management was afraid that if one or two expert coders in our organization were to leave, the site would be in crisis from the loss of specialized information. However, our coders work in Perl -- there are lots of Perl coders around there (though our team is VERY good) -- and now we are dependent on people who are expert in this proprietary system; now we have a vastly reduced pool of people with the necessary expertise to hier from.
The worst part of the whole situation is that instead of making our work easier, it is actually slowing down the specific tasks that we have been able to do for quite some time. We spend so much time trying to massage this tool into doing the things we need to do that we are able to get much less done in general.
There is no real end in sight -- or if there is, it will be quite messy; our division has invested so much money and manpower into this project that we will look VERY bad if we simply abandon it.
Very depressing....
I've found the mailing list and #Zope on the Openprojects.net irc servers invaluable for solving problems with Zope. Remember the Zope Corporation and other have used Zope for high profile projects such as CBS New York.
As far as the article topic, Zope has the CMF project which might give a good headstart on what they are after.
Aha, I see other threads are pimping Zope and the CMF so I'll leave it at this...
Bleh!
The cms-list might be a great place to do some further research. The mailing list archives are online and provide a decent resource of questions, observations and general flamage regarding CMS.
Bleh!
I'd suggest simply going with CVS and rsync.
If your current skills are mainly Perl then I've got a suggestion: Mediasurface are London, UK outfit who do an Oracle-based solution that uses a perl-based API (with a pretty decent lib of pre-built functions) for templating the dynamic bits of Web pages. They've got an equivalent java taglib (for JSPs) too. Not sure what the licence costs are like. -j
A reference site needs simplicity and clarity: you want to get to the info fast.
I worked on the premise that everything would be categorised by topics that became directories on creation so that you could type a directory structure as a url eg /important/stuff and go there immediately.
This also lets you set permissions by category.
You can decide in advance (together with your users) how all the information will be categorised and then only show categories with information when called for display, but show all when you're deciding where to put a document.
For displaying info I used templates that were set on creation of a category. Each category comes with an introduction, list of PDF's that are available in that category along with other stuff like a glossary with terms relevant to the topic/intro, news items (what is new to the topic, whatever) etc. All PDF's have to have some introductory text to give users a snapshot of the thing to help them decide if it's what they're after.
All this searchable by keywords, glossary terms, related items, etc.
Users are able to upload PDF's, manage categories, add news, new pages of text (which can be written to static html), etc.
You can ask to be emailed when stuff is added to the category.
An added advantage of rolling your own is deciding how to integrate those 2500 pages without redoing them!
The largest amount of scripting by far goes into the administration system of course, but it's all very manageable and do-able in 2 months.
I used php/mysql, use what you like - in the end it's the ease of use, both from the admin and user side, that counts.
Have fun!
It's the end of the world as we know it, and I feel fine.
http://plone.org/
the Plone Content Management System built on top of ZOPE is very 'out-of-the-box'. Very little programming is necessary. Lots of customization (workflow, permissions, presentation, template modifications) are all done through-the-web.
It is built on ZOPE so loads of the stuff is in Python but all-in-all its pretty elegant and looks marvelous! The higher the level you can program (Plone is very high level) the less maintenance you have to keep up with. Doing it yourself is a waste and some stuff is non-trivial. Working with languages that are object oriented will help.
If you are PERL guy.. try bricolage or midgaard..
I prefer PageTemplates and Python over mod_mason/perl (as they tend not to seperate concerns very well)
I was once a member of the myPHPortal team (anyone remember it) and have followed PHPNuke's development with great interest, and after almost two years following it I would have to recommend NOT using either PHPNuke or its derivatives, including PostNuke.
The *Nuke systems are all based on a hodge-podge of individual components badly stitched together, and even the "wonderful" PostNuke has rediculous errors, like using variables before initializing them, and reloading the same file five-or-so times (should only be done once). PostNuke has lauded a cleaner code base, but they still haven't cleaned up most of the base code, rather they've added more and more bells and whistles.
One of the worst things about them, and is true of many PHP systems, is that many bugs are ignored, and thus the code is allowed to be poorly written, because they recommend turning the error checking level down really low so the errors aren't shown! This is like putting a bandaid on a headache, it just doesn't help.
If you want a PHP based weblog, go with something else, like PHPslash, which might be written better, or roll your own.
Damien
Not sure about it being the leading vendor - for a document-centric, hard-core integrated with paper system, perhaps it can be. It's certainly there in the top right of the Gartner magic quadrant. But for a web-based system which isn't too worried about paper, it's not the first thing I'd choose, even if I were going for a tier-1 solution.
The only thing you can accurately describe as "Scotch" is a sticky tape made by 3M. And it's
You're right, those 3 do cost a lot. Each of them will cost maybe US$300k in licenses for a first time customer, plus 50-350 man-days development time for a complex system.
But it's worth noting that since Microsoft came into the market, enterprise CMS prices have been sharply dropping. Those vendors used to charge $500k+ for a first time customer...
If you want to go below the Vignette/Documentum/Interwoven troika, take a look at:
The only thing you can accurately describe as "Scotch" is a sticky tape made by 3M. And it's
Has anyone look into Oracle9iAS Portal for content management?
Oracle has stated that its portal solution can handle many content management features.
Here are their main features:
1. publish documents
2. check-in and check-out documents
3. set document publish or expiration date
4. workflow
5. use built-in search: a) keywords, b) text, and c) Ultra Search
6. Group documents into categories (i.e. the document subject type) and perspective (i.e. the interest groups that like to view the documents)
Hey, try Dynabase!! It is really good and stuff and the company(www.ebt.com) that makes it is really cool to work for. UNTIL THEY LAID ME OFF AND WENT OUT OF BUSINESS!!
Seriously, I used to write the code that does this kind of thing and it isn't too hard. Just , like anything else, don't expect it to be done overnight or something.
I believe the leading vendor in the CMS space is Interwoven.
bp
You throw out a distinction between "content" and "documents" as if it's perfectly obvious. I'm afraid I don't see it. And I've never seen the distinction drawn in technical or marketing literature -- of which I've been reading rather a lot lately.
Are you drawing a distinction between big thick highly-structured printed manuals and loosely-organized web sites? Documentum can be used with either. I don't know if it's the best platform for most web site apps, but it is widely used as such.
Perhaps you're thinking that Documentum just doesn't count as a Web CMS because that's not what it originally designed for. Well, a lot of CMSs didn't originally target web content -- most of them predate the web!
There is a certain tendency to emphasize web CMS over other CMS application, even for products that originally targeted traditional CMS apps. Not suprising, since that's where the big customers are. But it makes life just a little difficult if you're hoping to find an off-the-shelf CMS for a simple technical publications process.
If Zope doesn't appeal to them, I'd check out E Z Publish. Of all of the PHP-based systems, it's the one that impressed us the most. The web site supporting it is pretty crappy, so make sure your programmers check out the API documentation to get a sense of what it's capable of doing.
Alternatively, given the relatively small number of contributing users you have, I'd go for something very simple, and I'd make sure that whatever they build is set up so that they could move out of it and into something else down the road if your needs change or if someone comes up with a really great CMS system that makes everyone happy (I don't think we're there yet). For example, there are a number of systems where articles are stored in a sane XML format so a smart hacker could get the info into another system.
The biggest lesson I learned from several months of looking at CMSes and talking to people who were struggling with the same question is that nobody's figured this out yet. The same names--Zope, openACS, Midgard--kept coming up and so did the same frustrations. So if you don't think you've found a great answer, that's a good sign.
Good luck!
Thanks,
Anders Schneiderman
We've decided that the best thing to do is roll your own. Not to write a CMS from scratch, but rather to perform a tactical application of best-of-breed Open Source products (perhaps some inexpensive commercial ones where necessary) in a componentized fashion, using a database as the central hub for data and state information.
We're not the only ones in this predicament. Evidently this is quite common. See this recent press release from Jupiter Research, an internet industry analysis firm. Here's one interesting quote from the article:
bp
Sounds like we work at the same place!
Content management can indeed be a bear pit, but so can anything else. The problems you've had are familiar- mostly to users of Vignette. Frankly, it's a badly designed, bloated, buggy piece of shit. The only thing it ever had going for it was marketing dollars- someone decided they could be the Peoplesoft of content management, and they just about succeeded- except for the product, which sucks. You'd have better luck with just about anything else. Sorry you got sucked in. It happened to a lot of good folks.
I'm an aD/OpenACS guy myself.
although on a much smaller scale, i simply needed something that would help manage a template driven site. I think i've found exactly what i need in WebTool. I dont need craxy user management or user polls or top-10 lists or any of that community junk, i just need an organized way to publish pages as easy as possible.
anyway, check it out.
You said you have perl programmers so you might want to look at Mason. I don't know if it does what you need but I haven't seen anyone mention it yet, so check it out.
(and it wasn't improved by the millions of dollars we spent on a top-brand consulting firm who implemented it), but the problems are pretty generic. Vignette does a particularly bad job of solving them, but content management is inherently tricky.
I guess most of the history of computer science has been concerned with maths and databases, so we know pretty well how to model an accounting system or calculate PI to a zillion digits. THe softer stuff - how do people actually create "words" and how do they access and manage those words is something you can't look up in an algorithm book or a pattern repository.
I had a look at OpenACS - it looks pretty cool. After working with Vignette though, I have sworn of TCL as a web language for ever.
It's all very well in practice, but it will never work in theory.