[Zope-dev] the Zope Framework project

[Martijn Faassen]

Hi there,

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 last
> 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 
effort forward.

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 
half-test stuff.

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 frameworks, 

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 
libraries.

Regards,

Martijn