On Feb 9, 2006, at 5:20 PM, Edward Pollard wrote:
Since I really can't explain the environmental factors in any depth, let me rephrase: How do you sell Zope 3 as a solution?

It depends on the audience. It also depends on who's talking. The people who do this selling on a regular basis don't often hang out here. Here's an attempt by a developer.

Whoever you talk to, you can talk about the success of Zope 2, the CMF, and Plone.

If the audience is people interested in through-the-web programming, you steer them to a Zope 2 based solution (at least right now).

If the audience is comprised of experienced programmers, ideally with Python experience, and even more ideally with ZODB experience, you might mention the years of experience that went into the Zope 3 redesign. You might talk about the clean design, the excellent test culture, the emphasis on documentation, the better reuse options, and the embracing of other Python projects. You might point out the two Zope 3 books available in such a relatively short time after the Zope 3 release. If the audience is interested in the ZODB, you talk about the ACID compliance, the recent improvements to the conflict handling (MVCC), and so on.

If the audience is further comprised of people who work on big sites, you talk about the scalability of ZEO, and the open-source front-end options.

If the audience is concerned about yet-another-Zope-3-rewrite, you first acknowledge their are no guarantees. Then you can mention that Jim Fulton, Zope Pope, has said that he won't write a Zope 4. You can also talk about some of the Zope 2/Zope 3 efforts, which I mention below.

Maybe others can offer more. I'm just moving on to the next question. :-)

And what do you do to overcome the perception that our investment in Zope 2 will have little to no payoff in a Zope 3 developed project?

It's likely that you have four kinds of knowledge from your Zope 2 investment:

- Python knowledge (good for Zope 3)
- Templating knowledge (good for Zope 3: DTML and ZPT exist)
- ZODB knowledge (good for Zope 3)
- Zope 2/CMF tool knowledge (you'll want to forget a lot of this, although concepts like object publishing, tree traversal, object file system, and CMF tools carry over in some recognizable ways)

So you're losing part of the fourth category. The relative percentage loss that represents for you is something only you can answer. The return for switching is a clean, powerful, test-driven architecture: pretty exciting, to me.

There are two side issues:
First, ColdFusion and ASP are the other candidates, so while I don't want to encourage and dwell on specific comparisons, I would be lying if I said they wouldn't come in handy.

I'm afraid my knowledge of these is very out of date. Python is an obvious important differentiator, though perhaps .Net's CLR and the upcoming 1.0 release of IronPython might change that story.

Second, the existence of Zope 3 has completely shot any support for Zope 2 continuation out of the water in our environment. Is this fair, or is there life left to the Zope 2 tree we've developed some experience in? Should I be considering pitching a Zope 2 solution instead?

I don't know: that's a very hard question.

I'll mention a few interesting data points, FWIW.

I think most or all of the big Zope-based companies still make their living mostly on Zope 2 code. Some are moving towards Zope 3 via Zope 2/Five, and some are moving their applications piece by piece to Zope 3, whole cloth.

Jim Fulton, Zope Pope, works for a company like that, and has voiced significant interest in Zope 2 merging with Zope 3. Many others in the community feel that way too.

No easy answers. ;-)


Zope3-users mailing list

Reply via email to