What could justify the complexity of Plone?

Question

Plone is very complex. Zope2, Zope3, Five, ZCML, ZODB, ZEO, a whole bunch of acronyms and abbreviations.

It's hard to begin and the current state seems to be undecided. It is mainly based on Zope2, but incorporates Zope3 via Five. And there are XML config files everywhere.

Does the steep learning curve pay of? Is this complexity still justified today?

Background: I need a platform. Customers often need a CMS. I'm currently reading "Professional Plone Development", without prior knowledge of Plone.

The problem: Customers don't always want the same and you can't know beforehand. One thing is sure: They don't want the default theme of Plone. But any additional feature is a risk. You can't just start and say "If you want to see the complexity of Plone, you have to ask for it." when you don't know the system good enough to plan.

Answer 1

I see four things that can justify an investment of time in using Plone:

• Plone has a large and helpful community. Most of the things you need, somebody else
  already did at some time in the past. He probably asked some questions and got helpful answers, or he wrote a tutorial. Usually that leaves traces easy to find. about how he did it.
• You won't need to understand the whole complexity for many of your customizing needs.
• Plone developers are aware of their complex stack, and are discussing how this can be reduced. Plone has proven in the past that it is able to renew itself and drop old infrastructure in a clean way with defined deprecation phases.
• There are many local user groups with helpful people.

Oh wait, I was told the plone developer meetings are one of the best! Like that one

Answer 2

If you want to see the complexity of Plone, you have to ask for it. For most people, it's just not there. It installs in a couple of minutes through a one-click installer. Then it's one click to log in, one click to create a page, use a WYSYWIG editor, and one click to save. Everything is through an intuitive web GUI. Plone is a product.

If you want to use it as a "platform," then the platform is a stack of over one million lines of code which implements a complete content management suite. No one knows it all. However, all those "acronyms" and "files" are evidence of a software which is factored in components so that no one need know it all. You can get as deep or shallow in it as you need. If there's something you need for some aspect of content management, it's already there, you don't have to create it from scratch, and you can do it in a way that's consistent with a wide practice and review.

Answer 3

I found an anonymous comment here which is much better than that post itself, so I'm reposting it here in full, with a couple of typos corrected.

---

This summer my chess club asked me to make a new website, where the members of the board should be able to add news flashes, articles, ... Sounded like a CMS. Being a Python developer, I looked at Plone and bought the Aspeli book Professional Plone development (excellent written btw).

I took 3 weeks of my holiday the study the book and to setup a first mock up of the site.

After 3 weeks I realized that Plone has some very nice things but also some very frustrating things On the positivie side

• if you don't need to customize Plone, Plone is great in features and layout
• Plone has a good security model
• Plone has good off the shelf workflows
• Plone is multi language (what I needed)

On the downside

1. Plone is terrible slow. On my development platform (a 3 years old Pc with 512 MB RAM) it takes 30 seconds to launch Plone and it takes 10 to 15 seconds to reload a page
2. you need a lot of different technologies to customize or develop even the simplest things
3. TAL and Metal are not state of the art and not adapted to the OO design of Plone.
4. Acquisition by default is wrong. Acquisation can be very useful (for e.g. security) but it should be explicitly defined where needed. This is a design flaw
5. Plone does not distinguish between content and layout. This a serious design flaw. There is no reason to apply security settings and roles on e.g. cascading style sheet or the html that creates a 3 column layout and there is no reason why these elements should be in the ZODB and not on the filesystem
6. Plone does not distinguish between the web designer and the content editor/publisher, again a serious flaw. The content editor/publisher add/reviews content running on the live site. The web designer adds/modifies content types, forms and layout on the test server and ports it to the live server when ready. The security restrictions Plone put in place for the content editor should not be applied for the web designer, who has access to the filesystem on the server.
7. Plone does not distinguish between the graphical aspects and the programming aspects of a web designer. Graphical artists uses tools that only speak html, css and a little bit of javasccript, but no Python, adapters and other advanced programming concepts. As a consequence the complete skinning system in Plone is a nightmare

I assume that Plone is so slow because of points 4, 5, 6 and 7.

Points 6 and 7 made me dropping Plone. I looked around for other options and eventually decided to develop my own CMS on Pylons, which is blazingly fast compared to Plone. On the same development server I have a startup time of 1 second, and a reload page time is not measurable.

The site www.kosk.be is running (it is in Dutch). The CMS behind it, named Red Devil, will be launched as a separate open source project beginning next year

Answer 4

From a system administrator standpoint, Plone is just shy of being the absolute devil. Upgrading, maintaining, and installing where you want to install things is all more painful than necessary on the Linux platform. That's just my two cents though, and why I typically prefer to avoid the Zope/Plone stack.

Note: it's better with newer releases, but older releases.... ugh

Answer 5

Accretion.