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