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
http://www.mxm.dk/
IT's Mad Science
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
