Although I meant it as an example of "marketing overrunning reality" and not as some absolute statement about Plone's actual place in any specific market, folks are taking exception to my assertion that Plone is not a content management system .

The CMS term is pretty fuzzy. I understand it to mean "a system that lets content editors edit and manage content in a structured way." Never mind that people have wildly different ideas about what "content", "edit", "manage", and "structured" mean, that's the 10000-foot view. And yes, Plone, literally does just this, and it does it really well. So technically, yes, I suppose it is a CMS.

But this is a technicality, it doesn't take into account the assumptions of the people who actually pay for "CMS solutions". The reason for a content management system isn't just to allow content editing and management to take place. The people who build content management systems don't just build them so lots of people can edit things and view those things in some highly-regular but also slightly ugly UI. No! That would be an "intranet". Plone is a great intranet solution. However, when people buy a "CMS", they're assuming that at some point, the content will be delivered to end users in a much different form. And it needs to be delivered quickly, because there are a lot more people who want to just look at the content than there are those who need to edit and manage the content (unlike an intranet).

You can coax Plone into doing content delivery for an application like this. But it's either hard or slow. This is due to things in Plone like the "globalize" hack, which does arbitrary stuff at main template load time (hilariously its docstring says "Pure optimization hack, globalizes entire view for speed"; it does the opposite). And other bits of the UI kick off the Archetypes reference stuff, which somehow in one application I've developed causes some insane number of catalog queries (over a hundred) for a single request (still working on that one). So, you have to replace the main template for retaily users. And you have to go create more sane view methods for some things. And you have to track all the other crap down by using the profiler and exorcising the stupid bits. Fine. But this takes a long ass time. It's bullshit. I'm wasting the customer's money. If the delivery requirements are far more stringent than the editing requirements, Plone is not the right platform. You'd be better off just starting the project off in a blank buffer than using Plone in similar situations, particularly if you have to change the content editing interface materially too.

So that's where I'm coming from with my "Plone is not a CMS" assertion, for better or worse. I think there are lots of things we can do to make the content delivery story better, and I hope to be able to talk about them at the upcoming summit.