[Zope-dev] Another open letter. :-)

[Danny William Adair]

Hello Lennart,

On Monday 03 December 2001 05:06, Lennart Regebro wrote:
> After the discussion here I'm slowly starting to form a picture in my mind
> of how to "solve" the "problems".
>
> First some basic facts of life:
> - Zope corp needs to do what Zope corp thinks it can make money on.
>
> - "We" (that is the Zope community) need to get some features into the base
> of Zope because:
>     a. It's not effective that we all solve the same problems
> independantly. b. Some features are hard to do as products.
>
> - It is imperative that there is a single point of control for Zope, ie no
> branching.
>
>
> This means Zope corp needs to control what goes into Zope, but the
> community needs to tell them what should go there, and the community has to
> help to put it in.
> To achieve this, we need better community support systems. That is, we need
> a proper community site, with discussion forums, a merged
> collector/proposal application with proper threaded discussions and applied
> workflow for proposal states.
> The projects that get started also need their protected areas on the site
> with discussion forums and their own CVS trees.
>
> In all, this would support a better inflow of comments from the community,
> it would make it easier for community members to see the responses to their
> input, and it would be easier to start projects with non ZC people involved
> in programming.

Definitely. And definitely there needs to be more technical "infrastructure" 
on zope.org to support this way of working. As another result, less people 
would find it necessary to move their projects to sourceforge. Just imagine 
sourceforge functionality plus wikis, plus fishbowls, plus collector. I like 
the fishbowl's standardization of a common workflow, and I would love to see 
more integration of all the other parts. I believe this could speed up and 
stabilize Zope development drastically. Sometimes I even find _navigating_ 
through _what's_there_ hard, and I'm afraid to spend time writing something 
that someone else may have already written, and which might just be hidden 
somewhere in the haystacks...

>
>
> Here are some things that I feel should be introduced into Zope:
> - Workflow support. (Because everybody needs it)
> - Versioning. (Because it's hard to do as a product)
> - Internationalization. (Because it's hard to do as a product)
> - Better user management. (Because everybody needs it)

- Documentation
(Because everybody needs it - at some point of his/her Zope life)

>
> Also, Zope would benefit from the inclusion of several products that
> improve the products included in Zope. Many people have found some objects
> lacking in functionality, and added that functionality and put it up on
> Zope.org. Many of these improved products could easily replace the products
> that come with Zope today, thereby giving a better "wow" factor to Zope
> without much effort.

I think I am not the only one that's afraid of straw fires when it comes to 
Zope's "wow factor". The decision, which patch/product/add-on should make it 
to the core and which shouldn't, is not easy. This decision has always been 
made by ZC, and for the time being I found this fair enough, though it seemed 
to me that they have been clobbered over the head with patches so much that 
it became just too much work to review every single one in detail (there are 
_still_, for months now, so many patches to the tree tag, that enhance its 
functionality exactly the way that - imho - the tree tag was meant to work, 
and they still haven't made it to the core). It looks as if out of 
desperation(convenience?) the burden of proof is being put on the patcher.

What I would really love would be a regular poll for developers so that ZC 
can find out what "the community" would like to see move into the core. And 
not too abstract (I don't want to vote for "Internationalization", I want to 
vote for either "ZBabel" or "Localizer", we're not in parliament here). Pick 
20 patches/products, and let the community decide over the priorities. Let ZC 
be the final judge, but let the jury pass their decision ("advice") first.

You will always have the problem of this or that patch to apply to a very 
specific problem of yours. That's why you wrote it. Okay, this patch is 
essential for your site to work properly, but 99% of the other developers 
don't need it. If this is the case: tough luck. Pray that they run into the 
same problems some day. But for the time being, I don't see this causal 
coherence when it comes to "should and if yes then when will this be taken to 
the core". So who do I blame? Some people were very quick with their decision 
here... (see last threads on this list)

>
> I also feel there are things that could be removed. And now I'm gonna say
> bad things about parts of zope some people probably love, and they will
> hate me for this, but I'll have to live with that. This is my view only. I
> have on occasion been known to be completely wrong. :-)
>
> - Don't do any  more work on ZClasses, and eventually drop it. To me they
> do not seem easier to work with than Python, they are messier and not as
> flexible.

Not much has been done on ZClasses in the last months (sorry if this sounds 
insulting to someone who has actually worked on them ;-)), so I don't think 
that there has been much time "wasted" here. If you don't like ZClasses, if 
they don't seem easier to work with than Python: Ignore them. To a lot of 
people they are a nice introduction to object-oriented programming under 
Zope, and for simple tasks (like subclassing and adding/overriding one 
function of a class) they are quite a handy thing to have around the house, 
imho. I think that a lot of your concerns will dissolve with the upcoming 
Component Architecture.

>
> - I feel that CMF is a failure. It doesn't do what is promised, it's very
> hard to understand and many parts of it are simply designed so badly and
> incorrectly that they are practically useless. Drop CMF. Take the good
> parts and integrate them directly into the Zope base to make Zope a better
> platform form content management applications, and forget about the rest.

The CMF can only be a failure if it fails its goals.
Well, what are the CMF's goals?

Have you seen this interview?
http://www.zopera.org/site/Members/odeckmyn/iv_paul_2001
(recently announced on this list)

Quote:
"Regarding CMF, we expect it to disappear in its current form, ..."

Introduced to us as the "Portal Toolkit", later labeled as "probably evolving 
into a commercial product" (couldn't find it in the archives when I tried a 
minute ago, but I know I wasn't dreaming when I read it), then renamed to 
"Content Management Framework" and the out-of-the-box solution for site 
developers that need membership, skinning, an easy content management 
interface, and pluggable add-ons, Paul Everitt now calls it "a big prototype 
for the new architecture". Although I think that this is not how it all 
started, not even how it meant to be less than a year ago, you see that your 
concerns are no longer something to worry about. The "good things" will be 
taken to the Zope core, the rest will remain interesting only for people who 
actually "implement".

Danny

>
>
>
>
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )