In 2004, about three and a half years ago, I skinned Plone for ifPeople. Plone 2.0 had recently been released, and they had decided that it was now mature enough to bet their not-only-for-profit company on it.
I had a couple of years of solid Python experience, and I knew Zope from having evaluated it for other projects where I had worked; I started learning Plone for this new project, which included enhancing an existing Plone-based product to do things in a rather peculiar way that ifPeople favored.
A while later I helped design and led the implementation of a business directory which works with Plone but doesn't (or rather, didn't) depend on Plone, because the client wasn't yet sure whether they wanted to be so tied down to this incumbent CMS thing.
Still later I guided the first steps of a Plone-based development that helps NGOs index and search really large, distributed collections of documents. Parts of this development are today free software; parts are still being polished to that end.
It's been quite a trip; while I was doing this, or because I was doing this, I started a family, and a business; we dragged our twins from incubators to day care, and we grew from the initial three founding partners to our current five partners, two partnerships, and 11 employees. I've trained 8 of these people into at least some of the aspects of Plone. In this presentation I'm trying to distill both my experience and the experience of the people I trained, several of which are today active and productive Zope and Plone developers.
Before I continue: Plone is great. Plone is awesome. Plone is the my-Mom's-chocolate-fudge-cake of CMS. So if you've come here to jeer and gloat, go away; every single other CMS sucks much, much, orders of magnitude worse. So scram! Thank you.
So where was I? Oh, yes, my experience and that of our team.
Plone is amazingly complicated and complex. This isn't only because it is huge, and multifaceted, and not really a single product but a bag of mixed nuts built with a framework that reinvented itself something like three times before deciding to rewrite itself. It also is tremendously undocumented and, what is worse, misdocumented to the point where often the only way to find out how something works is wading through the sourcecode; it behaves, from a programmers perspective, in ways that are often either surprising, counterintuitive, or magical, and sometimes all three. And it truly is imponderable; if you're a designer skinning a Plone site, and something stops working because you stepped on a bug in an underlying Python library, you might as well close shop and go sell cookies door to door; you'll feed your family earlier that way.
Some of this complexity actually comes from Zope; certainly a lot of the unexplained magic comes from that direction.
Some of this complexity comes from Plone trying to do things against the Zope way (just ask the dudes in #zope what they think of Archetypes, or of Plone's abuse of ZCatalog).
Plone has a large amount of arcane baggage; if you need to change a certain behavior, you may find several implementations of that behavior, all rather similar, but different in subtle ways, spread across different products; sometimes you actually need to modify all of these implementations to effect the change.
Often you'll find that you need to say something twice or even three times, because otherwise things just don't work right. And way too often you'll find chunks of code copied and pasted, which when you ask what it's for, you'll be told "it won't work without it", or "dunno, it works without it, but the tutorial includes that so I left it in".
And sometimes, infuriatingly, there is only a single way to do things that you can't quiet have work the way you want to (so you've got to go and reimplement the whole product... reducing the problem to the previous case).
Plone is big: in codesize alone, by the time you count Plone and Zope you're into something like 750k LOC, mostly in Python. That is a lot of code; more than anybody can keep in cache.
Plone is slow: a default install on reasonably fast and large hardware will still take several seconds to chuck a page at you.
On a dual 2.8GHz pentium D with 4 gigs of RAM, just shy of three seconds for a single request on an otherwise unloaded system. [recheck - something is fishy]
Plone is heavy: just getting that default install up will cost you about 64MiB.
Once you have everything working the way you like it and go on to deployment, you'll find that hosting a Plone site is expensive; while you can get cheap-ass (need I say PHP?) hosting for less than a dollar a month, and fairly good Django or Ruby hosting for something like five dollars a month, you'll need to shell out three times that much for the privilege of using Plone. And if you get a moderate amount of traffic, or have a lot (over a gig) of content, you'll find yourself smack in the big leagues, paying more than 100 bucks for your small NGO site. No matter what the NGO does, that is a lot of money.
You can't just use zopectl on a production site; you need to run some kind of monitoring software such as monit or daemontools that restarts your instance when (not if) it fails, and in bigger installations you might find that you need to schedule a restart of your ZServers, staggered around the clock to avoid downtime.
I remember when Apache behaved like that, and it was a bug, worked around first and later fixed. I think we've got to the worked-around stage, but somehow I'm not sure we're working to fix it (maybe we are?).
Complicated & Complex
Several things are improving. One big step forward is Zope 3; unfortunately, it has increased the overall suckiness because now you've got to learn Zope 2 and 3, which are very different beasts, but hopefully at some point everything will be Zope 3 only, and all will be well, and components will be comprehensible again.
There still is a huge learning curve, something like rapelling up a glacier. But I think it's getting better---other people, however, aren't so sure.
Maybe it's that I know the path up, now. However, finding that path recently got a lot easier, thanks to the huge improvement that is the recent documentation reorganization on plone.org.
(I think this covers Arcane Baggage too, so I'll skip that)
Big, Slow and Heavy
Another bit of good news (that isn't actually new, but "olds" doesn't work) is that caching a Plone site will improve its speed a lot, and that it is actually very simple to do; there is even a very neat package called CacheFu that helps you tie Apache, Squid and Plone together into a tightly night wad of speed happiness. And you can also use Apache's disk cache, if you don't have a cartful of RAM hanging around idle. Or use more exotic combinations, like plone.org's nginx + varnish combination.
And what is better, Plone 3 is about 50% faster, by any reasonable metric.
Expensive
Here I'll just go ahead and plug Xarope, a Free Software solution we're building at Except to lower the barrier to enter the PZP hosting business. The idea is that with very little more than what you need to know to install a LAMP server you can be off hosting Plone inside little Xen instances, which is great, and ultimately aims to lower the price of this kind of entry-level hosting solutions.
Fragile
Hmm, not much you can do here, except that the monitoring solutions work. I still think they are a workaround to what is probably a collection of bugs, but it's tolerable.
Or, maybe I'm just used to this particular suckage; if you find it completely intolerable, and can find the time to fix it, great! :)
Inspite of everything I've just said, I still stand by my statement that Plone is awesome. Why?
Well, to start at the bottom of the stack, Python rocks. The productivity you can reach with Python while churning out readable, quality code is flabbergasting.
Next up is the ZODB, the Zope object database, which is actually part of Zope but I think it deserves a metion in and of itself. Not having to think your objects' relationships in terms of a relational data model frees you in ways you can't really comprehend until you've made the leap.
Then comes Zope. Zope is scalabale, and has a very powerful security model, and in general provides an impressive metaframework, a framework to build frameworks on. And acquisition! We love that thing.
One of those frameworks, the framework that is actually the reason behind having Zope in the first place, is the CMF. This is a framework for building content management systems, that already solves most if not all of the problems common to those. It is very much developer oriented, and in general is clean and consistent (if less than well documented -- but the source is usually a joy to read, so it's not like you're SOL). Also note that I said developer oriented, not programmer oriented; the skinning capabilities of the CMF are a joy in themselves.
Finally, there is Plone itself. Plone takes the awesomeness and CMS geek wet dream that is the CMF, and focuses it on the end user. The end result is often staggering; end users can download Plone, test it, and see that it fills their needs. We're talking about a inmensly complex software stack that offers a huge amount of flexibility, an impressive list of features, from AJAX search to customizable workflow, with even quite complex configurations supported out of the box, and installable in a few minutes by complete newcomers. That is rare.
And then, when the user has tried out Plone and sees that it does almost everything they want but oh! they'd like a psychic calendar, or any other weird, strange and specific thing, chances are if it isn't already available as an add-on product, somebody has already done most of the work for you. The ecosystem of third-party products is another awesomeness source.
And it looks good, too. Especially the soon-to-be-released Plone 3; have you checked it out? It is several levels of awesome, right there.
So, yeah, we like Plone. We're still not over the nightmares from having worked with other, PHP-based CMS wannabes, and Plone is a warm soft blanket we can suckle until the feelings of despair remembered pass.
And yet, Plone sucks. So let's make it better!