Jeff Shell wrote:

Yes it does. And I hate it. At Bottlerocket, we're a very small
company. We look at Plone and go "alright, how do we make it do less?
how do we turn this thing off, and this thing off, and this thing off,
and this thing off? why is it so slow? and it still doesn't do the
page we need to do. Let's just write our own CMS".

Apparently many people disagree with you.

Google hits:
**27,700,000* for **Plone****
***23,600,000* for **Zope**
*14,800,000* for **Zope -Plone**

For small companies that needs a small subset of what Plone can do, Plone might be a bit big. But for consultants/developers like me it is *far* easier to use Plone, remove some features and add those that are missing.

A fully finished system, that end users can install and try out, is the biggest succes story of Zope. There *must* be a lesson in that somewhere.

That Plone is difficult does not reflect that a big integrated system is the wrong way to go! It only indicates that the Zope/CMF/Plone stack is too big. Which is exactly why Zope 3 was developed, and I can hardly wait until something like Plone is running directly on Zope 3.

Then we will both have a big hunking end user system and a clean development model.

I know that something like Plone isn't the best solution for everything. Eg creating a task based intranet is impractical. But its still the most succesfull approach so far.

Plone has become a very precise communication tool between programmers. If your product works in a straight Plone installation, it can be modified with known patterns by other developers.

If everything is fragmented we will loose this "unification by example" and setting up big systems will be a lot more difficult.


hilsen/regards Max M, Denmark
IT's Mad Science

Zope3-users mailing list

Reply via email to