“Sliding Scale: Needs, Features, Extensibility, and Price”

Jon Udell said:

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

OK, I definitely agree that if the needs of the site are very modest, and are not likely to expand significantly, then something very simple like what you've described will work as a homegrown CMS.

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

Sure, as a programmer I have to agree with you. An established site with existing workflow and production requirements will (practically) never have its needs met by a product exactly as it ships.

If we make that a "law", a rule to guide how we consider this issue, then we're really saying that a pre-packaged CMS is worth buying if it offers:

• the lion's share of your immediate requirements
  
• a significant percentage of your near-term requirements
  
• a cost low enough to justify the development resources needed to add whatever's missing (whether you do it yourself, or pay someone else to do it)

(In other words, since a pre-packaged CMS can never be everything that you need, you must make the above list part of your requirements.)

That last point is important, because it includes some hidden details. If the pre-packaged software is hard to customize, then the cost of customization is higher. Also, if the cost is exceptionally low, and the software is extremely easy to customize, then the first two points can be adjusted.

Of course, these are still just general guidelines. If the system is incredibly easy to customize, but includes very little of what you already need, and your needs are significant, then the system won't do... it's too much like starting from scratch.

Art Pena made some very good points in his posting last night: don't reinvent the wheel. Find a good product with a lot of promise, and backed by a development company or group (if it's open source) with a good attitude towards improving the product to meet the customer's needs, and you'll almost always be in a better position than you will be if you write it yourself.

I'd say that applies to your magazine site, too. Unfortunately, your site's needs were so small that you'd probably not find a CMS cheap enough to justify buying. You could always consider a CMS ASP! (hint, hint)

>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:

I appreciate the mention of "discussion linked to produced content", but I have to point out that at this point, that's not really the point of Conversant's discussion tools, which are intended to be the core of the CMS, the system that manages the content, rather than a tool for managing a very active public discussion forum. Hundreds of messages per day are fine, but the very busy sites that get thousands of messages per day would probably overwhelm Conversant's current system (though we've never tried it, and so I probably shouldn't say that).

>- inexpensive
>
>- did the basic stuff out of the box
>
>- was clearly capable of anticipated necessary customization

I realize that I said the same thing earlier in this message, but I wanted to point out the importance of using that sliding scale. Also, where you say "the basic stuff," I say, "percentage of your immediate requirements".

Still, I think we agree on most of this. Now we need to convince the publishers to stop designing their own systems and go with something that's already written and has a future, like Conversant, Zope, or Manila (all of which have very different strengths and lots of room to grow, IMO).

Seth