[Zope-dev] Plone/Metadata/FUD

Joachim Werner joe@iuveno.de
Thu, 3 Oct 2002 19:23:14 +0200


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