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. ;-)
Gary
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
