I thought I should highlight this characterization of the Zope project
because I agree with much of it but also disagree with much of it.
Chris McDonough wrote:
> I have no faith whatsoever that staying on the course we've been on for the
> 9 years (
9 years is a long time, and while I agree that some cultural
deficiencies (bad presentation) have lasted a very long time without
much awareness of them, other deficiencies we're aware of and we're
making progress on.
> large interconnected codebase,
You might've noticed a certain effort back in 2007 to split up our large
interconnected codebase into small components, and efforts over time to
try to break the connections in this code base. I think we could've been
further along the breaking connections if we'd have some people with an
overview of what's going on and an active interesting in driving that
Anyway, this is a characterization of where Zope technology is now, but
it's a mischaracterization if you think that's where it wants to be or
that no effort was spent on improving the situation.
> backwards compatibility at all costs,
I agree that have erred on the side of too much backwards compatibility.
That increased the overhead of changes tremendously and blocked innovation.
That said, I also see a lot of value of having a lot of components that
can work together, and we do have quite a collection of those in the
Zope ecosystem. This is why Grok is so careful to stay compatible with
Zope 3, so we can share that pool of components.
I'm in favor of an evolutionary approach where backwards compatibility
on occasion is broken and it's clearly documented what developers should
do to fix things. I'm also in favor of an approach where due to proper
dependency factoring we can dump whole chunks of code (in particular ZMI
chunks) in a large step.
> lack of any consumable documentation at a package level,
I agree that most package-level documentation could be improved
tremendously by focusing on writing real documentation instead of
That said, we also have a tremendous level of package-level
documentation and interface documentation, and it's a
mischaracterization of the values of the Zope project to say we haven't
cared about documentation at all. We innovated with interface-level
documentation and doctests and making those available on PyPI. You've
said in the past that this is a sort of "false optimum" that stops
people from really fixing documentation issues, and I agree.
We should make an effort to change our culture and redirect our
documentation efforts to go beyond doctests.
I'll also note that documentation for the whole *system* has
traditionally been lacking (how to get started, install it?). I know you
don't like the whole Zope 3 system anyway, but it's also something I
think we could improve (and we've been doing so for Grok).
> not much curiosity about how other Python web frameworks work,
I'm not sure whether this characterization is accurate or not. Because
Zope was there sooner than many other Python web frameworks, it's
probably partially true we've ignored the competition.
I've personally been quite interested in seeing how the cultures
surrounding other web frameworks work and trying to adopt lessons from
this. I've also played with some other web frameworks and used
TurboGears 1 for real work, but not as much as I should, perhaps.
I've been able to apply the things I've learned from other web
frameworks far better in the context of Grok than I have been in the
context of the wider Zope community, and I wish that would change.
> not much real cooperation with folks that maintain other Python web
What is "real cooperation"? It's hard to judge this one, though we can
definitely do better. I'd note that the culture of cooperation between
other Python web frameworks has started really taking off surrounding
WSGI, and we've been trying to make use of this technology but haven't
had the full benefits yet.
Anyway, it's hard to say how much of a goal "real cooperation" should be
for our community. I think we should do our best to integrate other
technology in our own stuff, and we've had some progress with things
like WSGI, Twisted and SQLAlchemy. Maybe Repoze is next, but I hear they
think very badly of us indeed. :)
> a constitutional inability to attract new users
I share that concern very much. It's good that the Zope technology is so
central to other projects which do attract new users so we still have at
least some influx here. Part of the reason is our lack of attention to
documentation, proper web presentation, and our "here's a giant toolbox,
you figure it out" approach.
I'm not sure how the collection of libraries I dubbed the Zope Framework
would operate in this regard. Individual libraries should present
themselves to attract new users. At the same time the larger collection
(the ball of 70something of them) tends to get new users through Zope 2,
the Zope 3 app server and Grok. We should make sure that we are aware of
these users and listen to them. We can also provide common
infrastructure so that individual libraries can present themselves more
easily, as well as point out their picture in relation to other related
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -