I've been around the Zope/Python scene for many years. One thing I see this group suffer I believe if from the groupthink mentality. Imho Alexander Limi "2 cents worth" demonstrated Erik's point perfectly. applaud the effort made with plone. I believe it to be a spoon in which we can spoon feed newbies into the CMS side of the Zope way. Seem my post regarding Zopezen.org. Plone is slow. Zope with CMF is slow... Not as slow as plone, but the issue is with ZPT. There is no way around it Erik is right. Developer time being spent on speeding up plone in order to backport the improvements to Zope/CMF sounds... Well arse backwards. Plone has its place, but I suspect some doublespeak here, lets be realistic about it. I debated a long time ago about CMS being the core of Zope anyway, but lo and behold they pushed on with a "CMF" product. I see plone as being the same, a product. Now my understanding is that with Zope3, they will roll a lot of the CMF functionality into Zope3.... Hmm go figure? All that time wasted on maintaining 2 products Zope/CMF has proven cumbersome at the least imho. Now just imagine if the community would have listened to the lone voice James-then/Erik-now where we would be today. We all know that the decision back then was based on commercial interest for ZC and others trying to market some industry catch phrase. So I hear you Erik, you have these wonderful, bright people working on special interest projects, but not on the core issues that allow Zope to have that strong core that it needs to move it forward. With it being evident in how the "Release early/Release often" mantra has been thrown to the wayside, I'm left wondering what do I do next with my 2.5.1 site? Do I go the plone, 2.6, 2.7 or 3.0 route? Like I said before, as a qoute from Mr limi" you should not mix in the
Plone name if you do not intend to follow our guidelines. "TM. Plone is a major benefit to the community. Please keep up the good work and effort. I believe that the master minds behind it all should be working to make Zope3 a reality for the plone product and not the other way around, hence you'll screw up mixed-up people like me even more. I hope I'm making some sense with this. I understand that this is "free" software, but as I "community" we should work toward making sure that we all can have a voice and benefit from plone/zope 2.5-2.6-2.7-3.0/CMF/Thingy.
I'm sure I'll have to take a loan out on this, because it's more than 2 cents worth ;-). Peace, -- James I am a Washington State Citizen. Spamming this Email Address may be against Washington State Law Chapter 19.86, and 19.190 RCW. http://www.wa.gov/ago/junkemail/protect.html At 05:08 PM 10/2/02, Alexander Limi wrote:
<quote who="Erik Lange">
In the install-script for MMM Skins, we call it a "plone rip-off"... I've suggested that we change the product name to "Plone skin" to Alan, to recognize the fine work of Plone, and to make it clear what it is: A skin that gives your CMF-site a Plone-look, and nothing more...
As one of the two designers of the Plone skin, I thought I would send you my 2 cents on this.
Most welcome ! :-)
Not to be harsh, but calling your skin anything with Plone would just cause confusion, as it has none of the distinguishing marks of the original look, apart from the blue color.
Nevertheless people constantly assumes that we use Plone on our sites... so it must have something in common with the Plone 'thingy' ... Check: http://www.mmmanager.org/Members/erla/1018802975267402990/talkback/101882996...
You break almost every consistency rule and design decision in your skin,
Yep - the rules set up by Plone - not the rules of CMF ;-) That was what leed us to make the product in the first place...
and it is nowhere near being Plone, neither from a usability nor a design perspective.
Nope - and we're proud of that ;-)
I will not comment further on this, I find this discussion a bit far-fetched. Plone is a separate entity, and you should not mix in the Plone name if you do not intend to follow our guidelines.
I agree :-) And we don't intend to follow your guidelines.. sorry.. but why should we ? How about "CMF Zlone skin" for a name ? ;-) Or "CMF BTTF Skin" ? BBTF = back to the future ;-) Is it okay that we thanks Plone.org for the inspiration and basic layout in the next release ? Or should we simply just blame it all on Canada ? *ROTFL* Regards, Erik _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com
On Thursday, Oct 3, 2002, at 03:54 Europe/Paris, James Johnson wrote:
I've been around the Zope/Python scene for many years. One thing I see this group suffer I believe if from the groupthink mentality. Imho Alexander Limi "2 cents worth" demonstrated Erik's point perfectly. applaud the effort made with plone. I believe it to be a spoon in which we can spoon feed newbies into the CMS side of the Zope way. Seem my post regarding Zopezen.org. Plone is slow. Zope with CMF is slow... Not as slow as plone, but the issue is with ZPT. There is no way around it Erik is right. Developer time being spent on speeding up plone in order to backport the improvements to Zope/CMF sounds... Well arse backwards. Plone has its place, but I suspect some doublespeak here, lets be realistic about it.
The Plone people are a layer above CMF, which is a layer above Zope, which is a layer above Python, which is a layer above the C library, which is... Do the Plone people have responsibility for all the layers below them? Nope. If there was a bug in the Python compiler (and in the last six months, there was one), should Plone have to fix it? Should they also fix problems in the Linux virtual memory model if they find that too? Nope.
I debated a long time ago about CMS being the core of Zope anyway, but lo and behold they pushed on with a "CMF" product. I see plone as being the same, a
Two errors here: a. The Zope community, on the whole, doesn't want Zope narrowed exclusively to content management. b. The CMF isn't a product. It is a framework. It specifically intends to not be a product.
product. Now my understanding is that with Zope3, they will roll a lot of the CMF functionality into Zope3.... Hmm go figure? All that time wasted on maintaining 2
This isn't precise. The CMF machinery, the part not unique to content management, is going into Zope 3. The effort for content management in Zope 3 is being managed as a companion project: http://lists.zope.org/pipermail/zope3-dev/2002-September/002819.html I'll note that you are neither subscribed to the Zope 3 mailing list, nor have you commented on the email above. If you're not even participating, then you should be more circumspect when making assertions such as:
products Zope/CMF has proven cumbersome at the least imho. Now just imagine if the community would have listened to the lone voice James-then/Erik-now where we
...this. How can we listen to you if you're not participating? But to your point: the Zope community does not want, IMO, Zope and CMF merged. Content management is a piece of the Zope pie, not the whole pie.
would be today. We all know that the decision back then was based on commercial interest for ZC and others trying to market some industry catch phrase.
I have no idea what you are claiming. In fact, the reverse is true: ZC is focused on content management, but ZC realized others want to do different things with Zope. Thus ZC didn't turn Zope into a CMS-exclusive thing. Doing the CMF outside of Zope allowed the CMF to make rapid progress in a focused area without making promises that Zope itself would have to live with permanently. This has worked perfectly. We all now know a lot more about the patterns of content management. We can now refine them, and refine Zope, with the work on Zope 3. Tell me, do you think KDE should be merged into X11? It is exactly the same analogy. You're also claiming that Erik is voicing your opinion. I don't believe Erik wants a one-size-fits-all CMS product that everyone must support, nor do I believe Erik wants Zope to be focused exclusively on content management. However, I don't pretend to speak for Erik, so he can correct me if I'm wrong.
So I hear you Erik, you have these wonderful, bright people working on special interest projects, but not on the core issues that allow Zope to have that strong core that it needs to move it forward.
People work on what they want to work on. Alex Limi knows CSS and doesn't want to learn how the ZPT compiler should be optimized in C. It is unfair that you demand that he learn how to program in C. It is also wrong. Zope has more people that know C than know CSS well. We are lucky that Alex is filling an unmet need in the world of Zope.
With it being evident in how the "Release early/Release often" mantra has been
Explain how this is thrown by the wayside. You can, every single day, make a checkout of any part of Zope. Sure there was a gap between 2.6 alpha and 2.6 beta. But that's a single datapoint. Name another datapoint to support your conclusion.
thrown to the wayside, I'm left wondering what do I do next with my 2.5.1 site? Do I go the plone, 2.6, 2.7 or 3.0 route?
Going the Plone route is orthogonal to choosing a Zope version. Not a single person in the world of Zope claims that 3.0 could even run a prototype system, much less a production system. And there isn't even an alpha for 2.7. Thus you have two choices: a clearly-advertised-as-released 2.5.1, and a clearly-advertised-as-beta 2.6b1. It's up to you to make an informed decision between the two.
Like I said before, as a qoute from Mr limi" you should not mix in the
Plone name if you do not intend to follow our guidelines. "TM. Plone is a major benefit to the community. Please keep up the good work and effort. I believe that the master minds behind it all should be working to make Zope3 a
As noted above, the "masterminds" are trying. It would help if people would participate, rather than accuse. But alas, the latter is far easier.
reality for the plone product and not the other way around, hence you'll screw up mixed-up people like me even more. I hope I'm making some sense with this. I understand that this is "free" software, but as I "community" we should work toward making sure that we all can have a voice and benefit from plone/zope 2.5-2.6-2.7-3.0/CMF/Thingy.
I agree that there are too many choices in play, but these choices are meant to be discussions amongst insiders. I don't think anything on zope.org is advertising to the world that 2.7, 3.0, or even 2.6 are something they should care about. And as for Plone vs. CMF vs. Zope, they are all different pieces of the pie. Just like Zope is different from Python -- imagine telling the world of Python that they are merged with Zope. Now *that* would be pretty hilarious. :^) Plone and CMF and Zope are positioned exactly as intended, IMO. Plone is an end-user product. CMF and Zope are tools to build enduser products. In the world of Zope 3, this distinction will be even more clear. Zope 2 unfortunately tried too much to be an enduser product, causing confusion. Zope 3 will clearly say: "This is for developers." --Paul
Paul Everitt wrote:
...this. How can we listen to you if you're not participating? But to your point: the Zope community does not want, IMO, Zope and CMF merged. Content management is a piece of the Zope pie, not the whole pie.
And sooo right you are. If Zope became the CMF or Plone I would drop it in an instance. There are so many wonderfull things that can be done in Zope, when it is as it is now. And many of the things does not fit into the cmf frame of mind. Ie. I have a completely different idea as to how things should be done in Zope than how the CMF do it. When you start making a concrete implementation of something you make some decissions in the beginning, and those decissions influence how you make the rest of your decissions. So you get this complex web of layers of decissions that depends on each other. You sort of paint yourself into a corner. An evolutionary dead-end so to speak. If Zope gets forced to go in one different direction, like CMF, it will quickly hit an evolutionary dead end. regards Max M -- The reason I don't reach any higher is that I stand on the shoulders of midgets.
Hi! I could comment for hours on the postings in this thread (after rereading what I've just written below I actually did ;-)). But let me just take this to say what is most important to me:
In the world of Zope 3, this distinction will be even more clear. Zope 2 unfortunately tried too much to be an enduser product, causing confusion. Zope 3 will clearly say: "This is for developers."
Paul, you are talking about a point that is very critical to Zope's future. Many of us started using Zope in the first place because it was a cool, out-of-the box product. Zope 1.x, as well as the early versions of Zope 2.x, could be described as a feature-complete, easy-to-customize content mangement system for a small number of users, with support for integration of data from SQL and other external sources and for writing nice little dynamic apps. You just needed some DTML, not really do any real programming, be it in Python or DTML. And the separation of programming vs. just customizing was rather obvious. With the limited possibilities of DTML it was impossible to do real coding, which was a good thing. The Zope Management Interface (ZMI) worked fine if you had just a few templates, like a customized index_html, standard_html_header, etc. The Add-list was short, and even security worked fine with just a few Products installed and just a few users to map roles to, which you would have to map Permissions to. Then a lot of stuff was added, most of it very cool, but not always fitting into the original concept. ZClasses where the best and the worst idea of all at the same time. And they also are a good example of a Zope component that was over-hyped at first and then dropped like a hot potatoe (others are XML support, Mozilla support, and to some extent even the CMF). Before ZC started the documentation efforts, a Zope newbie would have no clue whether it was better to work with ZClasses or file-based products. Now things are, to an extent, even worse. To work with Zope and really get the most out of it, you need to know Python (even in the ZMI, as Python scripts are the preferred way of coding little helper methods), DTML (because ZPT can't do everything), and ZPT. This is really confusing for a lot of people. The thing I hate most is that there are really useful helper methods and classes in lib/python/App (and also in some other obscure places) that are frequently used by the ZMI itself. But this stuff is mostly undocumented and obviously written by ZMI-designers for ZMI-designers. E.g.: Zope copy&paste support is cool. But there is no easy way of using it in customized user interfaces, as all the methods return you "back" to some ZMI page. So while obviously Paul is right that Zope 3 should be focussed at the developer and mainly provide well-tested, well-documented, low-level tools for doing great things, Zope (3) will only survive if we get a lot of a lot people using it. And as most people are NOT developers, they will need end-user products that are based on Zope. Otherwise Zope will get lost. If Zope 3 is meant to be a developer's tool then it will play in the league of BEA WebLogic, IBM WebSphere. Those products are powerful and expensive. And they are so complicated to use that you need experts to work with them. So the market segment is very interesting, but limited to large corporate clients. Most of the users Zope currently has are probably using it as an alternative not to an application server but to either Apache+PHP/Perl or to a CMS. Virtually all the hosting customers we have at iuveno run no custom products. Some of them use existing ones like Squishdot or the CMF, some use ZClasses. So for them Zope IS the product, not the platform. Most of the consulting jobs Zope services companies can get will not be in the 100.000-1.000.000 EUR or $ range, but smaller in size. So the budget is large enough to customize an existing product, but not to write one from scratch, regardless how cool the platform is. I am quite sure that you can write a lot of stuff much quicker in Zope/Python than you'd get it done in Java, let alone C. But still that's not good enough to survive. My opinion is that what we as Zope-using services companies will need to survive is ready-to-use products we can easily customize. Plone is one of those, though I personally don't like all of it that much, Silva is another. And now comes the part where the Zope community can fit in: Most CMS I know, Zope-based or not, just try to do the same thing in slightly different ways. I am positive that as an open source community we could do MUCH better if we shared more of the development, not only on the Zope-level, but also and maybe even mainly on the application level. For me, Zope 2 is not perfect, but good enough to base applications on. So I would not necessarily need Zope 3 from that point of view. It is also hard for me to contribute to Zope 3 if it stays so abstract. An example: Contributing to the object hub is hard if you don't know what to do with it in the first place. But let's say we are working on a Zope-based CMS and need better querying or personalization support. Then we'd know exactly what we need to get improved in the Zope object hub, and we could get a customer pay for it. Currently there is a dangerous gap you can get into when you are using Zope as a software consultant: At first glance, Zope offers you so much at so little effort. But then you realize that most of it is "demo". So it works, but not always as well as you'd expect. Two examples: - Versions in Zope seem to be a good idea, but don't work with more than one or two content managers involved. Find that out too late in a project and you are lost. Add to that that versions do not like sessions and vice versa, which also have sucked for most of the time (they just wouldn't be reliable on high-load systems). - Building highly complex, fully dynamic stuff in Zope seems to be (and is) easy, building highly compley, fully dynamic stuff that is high-performance is not that easy in Zope, even with ZEO. Sometimes using a faster, but less complex tool, e.g. PHP, can get you a better performance, while many of the bells and whistles that make Zope so (relatively) slow are not always needed (security, DTML, ...). To put it in my own experience: I was really happy with Zope and Zope performance in particular, until I had to write a really high-performance, 500 editors, 3000 pages, fully dynamic CMS. I thought it would be rather easy as it had been easy to build these little, cool web sites we had done before, but it wasn't ... (to get me right here: it would not have been easy to get that thing done in Java either, and there are loads of examples for bad-performance Java applications, but at least with Java I'd not have EXPECTED it to be easy ...) Let me conclude my rather lengthy posting with some theses I have come up with in more than three years of working with Zope. Those might not seem to be in context with what I have written above, but nevertheless they are: - Zope-based products can and might be sold for profit. But at the same time you should make them (or the larger part of them) open source because you NEED to get them used by a lot of other developers (if you are not employing lots of developers on your own that is). Not all of us really do this. Plone is open source, Silva is, our Kontentor is (though the world is still waiting for a release, sorry about that), Squishdot is. Others are not ... - What the world needs from us is easy-to-customize Content Mangement, Groupware, and Document Management applications. For doing the easy things the world already has PHP and ASP.net (and for easy things nobody pays good money any more ...) - Zope can be a good platform to build these applications, and at the end we'd have an application framework that is more versatile and more customizable than anything else on this planet, which would be the beginning of Zope world domination, which would be the first step to Python world domination, which is a GOOD THING (TM) ... as long as we are part of it ;-) EOT Joachim
participants (5)
-
James Johnson -
Joachim Werner -
Max M -
Paul Everitt -
Simon Michael