“build or buy?”

As to build vs buy, it depends on skills, inclinations, and the nature of the site. I run a magazine site that's doing about 300K pageviews/month using nothing fancier than a Perl script. But, this is possible because I've trained people to export the magazine content into a prescribed XML format that I can easily parse and repurpose. Behind the scenes, there's a very simple Zope application that editors use to post work in progress -- which must unfortunately go through a Quark production process (it's a paper magazine, after all) and then get exported for the Web. No real workflow, just a tree-structured readable/writable repository that supports HTTP file upload of text files and images. But it works well enough for a small staff who would otherwise do everything in email attachments.

The problem with tools, somebody once said, is that they do as much to you as they do for you. For somebody like me, that's true. I can't imagine any CMS doing just what I want out of the box, and since my needs are modest, I'd just as soon do stuff myself and get it done the way I want.

OTOH if I were doing a heavily dynamic news-and-views site, with new stuff flowing in daily (rather than monthly, as in the case of my magazine site), and with discussion linked to the produced content, then I'd be much more likely to buy, rather than build, a discussion-capable CMS. At which point, I'd be looking for something that was:

- inexpensive

- did the basic stuff out of the box

- was clearly capable of anticipated necessary customization