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@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 )