Content Management Software - Build or Buy? 77
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.)"
It only takes one issue to kill you... (Score:2)
Re:It only takes one issue to kill you... (Score:1, Informative)
Commercial content management systems (Score:2, Insightful)
Open Source Content Managment Conference (Score:3, Interesting)
Zope (Score:4, Informative)
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 [zope.org] is on-line and the software [zope.org] 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 (Score:5, Interesting)
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 [slashdot.org] 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).
Re:Zope (Score:1)
As far as programmers are concerned, I'd have them take a good look at MaxM's Easy Product [zope.org] writeups.
I kid you not, the above product is nigh-indispensable to programmers who need to make custom Zope objects, but have trouble with some of the overhead of rolling products entirely from scratch. GO READ IT IF YOU'VE HAD TROUBLE OF THIS SORT.
Anecdotally, witness the difference between these threads on the Zope list, both from the same user: Before [zope.org], After [zope.org]
Re:Zope (Score:3, Informative)
Plus, I would think about getting paid zope consulting to get you of from the ground and continue yourself later on.
Let someone build the hard parts (business logic etc.) and do the easy parts yourself (presentation logic).
Whatever sales droids of proprietary content management system may tell you, they don't work out of the box - at least not more than zope does.
You'll always find things which don't work the way you want them to, making custumization needed, like adaption to your business' processes or whatever.
In reality, many of the important CM makers make most of their money by consulting etc.
Take a look at zopes content management framework [zope.org] which is an add-on more tailored to typical content management use cases - oh, and ignore the ugly side, something new is in the works.
It all comes down to:
$total_cost = $cost_of_license + $cost_of_consulting + $cost_of_own_time
With zope, $cost_of_license == 0 at least, and I guarantee that zope gives a very good start to get the others quite low.
Roll your own...sorta (Score:2, Insightful)
Content management is a bear pit.... (Score:4, Informative)
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
Re:Content management is a bear pit.... (Score:1)
ThreeRing Monument (Score:2)
They also have a smaller application called Torpedo [threering.net] (also open-source .NET) which is suitable for weblogs, small business sites, etc.
No, it's just Vignette... (Score:2)
I'm an aD/OpenACS guy myself.
Oh, Vignette is POS indeed - (Score:1)
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.
Perl solutions (Score:4, Informative)
Re:Perl solutions (Score:2)
Re:Perl solutions (Score:2)
BTW Bricolage is build using Mason.
Re:Perl solutions (Score:1)
http://www.metadot.com
http://www.metadot.net
Who is your authoring audience? (Score:5, Insightful)
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.
Re:Who is your authoring audience? (Score:2)
Somebody mod up dmorin.
Re:Who is your authoring audience? (Score:2)
Tools costing a fortune (Score:2)
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:
Re:Tools costing a fortune (Score:1)
Stellent
I was involved in a project using Stellent (when it was Intranet Solutions' Xpedio).
Run -- don't walk -- away from this dog.
It's far too complicated for its own good. It's ugly. About the only selling point that I could see -- and it's a dubious one -- was its ability to use Office (Word, Excel) as content editors. Documents would be created with custom style sheets and and the import process would transform the applied styles into HMTL.
It's not worth it.
Another Option
If you're considering the high priced spread, you might want to consider Eprise [eprise.com].
Eprise is pretty sleekly done. All the content is in an RDBMS. the display layer is isolated from the content. Security and workflow are built-in (you need to model it to suit -- both can be as complex as you like.) Version control is built-in as well.
Access can be constrained down to the element level on the page -- users of different classes may see different content on the same page. If you have edit authority, you may even see a 'edit this page' button on the page itself (or an 'add new page like this' button).
Content is dynamically gen'd from the DB on request, so once a change makes it through workflow and is approved/published, it is instantly available.
In summary, I liked Eprise. It's biggest shortcoming is the model is awfully complex -- there's a steep learning curve. You'll need to hire the Eprise consultants to help get it set up and take the Eprise training classes. Once set up, though, the complexity is hidden from ordinary users (eg, content managers/editor). It's only complex if your's developing/configuring your Eprise application itself.
Disclaimer: I've got no interest in either of these products -- good, bad or ulgy -- except as a user.
Outsource... (Score:1)
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.
One size fits all....not (Score:1)
.pk
You might want to consider outsourcing your CM (Score:1)
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 [atomz.com]. 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.
Midgard, maybe? (Score:1)
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
General notes (Score:2)
- 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.
Why not roll your own? (Score:2)
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.
Zope use can be simplified even more. (Score:2)
Give it a try! It also has superb debugging capabilities...
Screenshots of Zope editing... (Score:2)
cost of software + customization + training = $$$$ (Score:3, Insightful)
what would be much more cost effective would be to sit down with a dev house (such as mine [confluentforms.com]), 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)
Get the best of both worlds (Score:4, Interesting)
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!)
Look into CodeCharge Studio. (Score:1)
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.
Re:Look into CodeCharge Studio. (Score:1)
WhatIf: Already hand-rolled added commercial.. (Score:1)
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.
AxKit (Score:1)
Avoid Zope and especially Squishdot (Score:2)
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.
Re:Avoid Zope and especially Squishdot (Score:1)
Re:Avoid Zope and especially Squishdot (Score:2)
Features? We don't care about features. We care now about stability, and ability to recover from disasters. Slash is the stuff that runs Slashdot, so it should cope just fine with our load. Other strong contender was Scoop, but that hasn't got a stable branch yet.
This is production machinery. Features are candy :-)
Zope Community? (Score:3, Informative)
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 [cbsnewyork.com].
As far as the article topic, Zope has the CMF [zope.org] 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...
Re:Avoid Zope and especially Squishdot (Score:2)
In a perfect world, we probably could have done something else. But in this one, Squishdot is a POS and something more robust is called for.
Re:Avoid Zope and especially Squishdot (Score:2)
I'm really glad this topic came up, because my site needs the exact same thing. Zope CMF sounds promising, if it can output static html.
We rolled our own... (Score:2, Interesting)
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.
Postnuke! (Score:1)
Kinds of content management (Score:2)
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 [documentum.com] is the leading vendor of these, but it has many competitors.
Re:Documentum (Score:2)
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.
Documentum? (Score:2)
I believe the leading vendor in the CMS space is Interwoven.
Content != Documents?!!! (Score:2)
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.
cvs? (Score:2)
openACS (Score:2)
Look at openACS [openacs.org]. 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 [openacs.org] and its cousin ACS classic.
Roll your own CMS! Off the shelf is a nightmare! (Score:1)
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....
CMS-list (Score:2)
I've done something similar (Score:1)
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!
Plone is a CMS built on ZOPE (Score:1, Informative)
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)
Don't use PHPNuke or derivatives! (Score:1)
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
Re:Don't use PHPNuke or derivatives! (Score:1)
-gregor
Disclaimer: Im a PostNuke developer.
Re:Don't use PHPNuke or derivatives! (Score:2)
I don't recommend PHPNuke, for the very reasons expressed in the parent post.
I've been using PostNuke for almost 1 year now. I started with the
Honestly, PostNuke really shouldn't be considered among the *nuke derivitives any longer, because its now very different and will only further set itself apart in the future.
DynaBase!! (Score:1)
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.
Zope / Something Simple (Score:1)
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
Another vote for roll-your-own (Score:2)
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 [jmm.com] from Jupiter Research, an internet industry analysis firm. Here's one interesting quote from the article:
WebTool (Score:1)
anyway, check it out.
HTML::Mason (Score:2)