[Zope-dev] the Zope Framework project

[Chris McDonough]

Tather than reply in kind here, let me summarize:  I'm glad we agree more than
we disagree, and I apologize if I've attributed to you beliefs that you don't
have.  It's heartening to hear that you're in favor of most of the things I'm
also in favor of.  But we do have real differences in opinion I think.  I'd
rather be constructive than obstructionist here: at the end of each item below I
ask for an opinion based on a suggestion.

1)  I'm not in favor of a single steering group for the *entirety* of all Zope
software.   We've tried a similar thing in the past (via the foundation
structure); it didn't work and I'm not sure how we'd expect things to turn out
any differently this time.  Instead, perhaps the focus of groups should be on
some much smaller subset of Zope-related software (e.g. the
zope.interface+zope.component group, the zope.schema group, the ZODB group,
etc).  Could we consider this?

2) I'm also not in favor of a giant lockstep set of software versions shared
between notional releases Zope 3.5, Grok, and Zope 2.12.  I can only see this as
continuing our mistakes of old by trying to treat some collection of software as
"Zope" as opposed to letting parts of it survive or die on their own based on
merit; it'd be more effective to just let each framework use (or disuse!)
whatever versions of stuff that work best for it.  That's why the software is
broken out into individual components in the first place; we should encourage
diversity in component usage.  Instead of trying to legislate and bless some set
of components as a "version", we should just work to make each piece better and
worthwhile to use independently; it's value would be in its actual usefulness
rather than some belief that it works well with the other components in the
"version".  Could we at least agree that lockstep versioning of a huge set of
Zope eggs to be shared across many frameworks is not optimal for the long term
and that it would be better if each framework could pick and choose whatever
components and versions it actually needed?  Could we also agree that this would
tend to result in better dependency partitioning ("X depends on Y, I don't need
Y, I just need X, let's fix that")?

- C


Martijn Faassen wrote:
> 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
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>