[Zope-dev] the Zope Framework project

[Kent Tenney]

On Wed, Mar 4, 2009 at 8:43 AM, Andreas Jung <lists at zopyx.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - Show quoted text -
> On 03.03.2009 15:37 Uhr, Kent Tenney wrote:
>> On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer <dusty at qwer.tk> wrote:
>>> Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro:
>>>> On Tue, Mar 3, 2009 at 00:16, Martijn Faassen <faassen at startifact.com>
>>> wrote:
>>>>> Who is going to make that decision to encourage this? Allow this? You?
>>>>> Me? Who? Right now, *nobody* is making such decisions and nobody can
>>>>> properly get away with saying they allow it. Leadership is a way to get
>>>>> out of it.
>>>> I think open source in general has shown two things:
>>>>
>>>> 1. Communities can mostly take decisions without having official
>>>> authorities to do so. This is hyper democratic.
>>>> 2. When they can't, usually committees can't either. In those cases
>>>> somebody with a deciding vote is needed. This isn't democratic at all,
>>>> but efficient.
>>> Exactly. And that's what we currently don't have.
>>>
>>>>> +1, though a simple discouraging of utterance can't accomplish it by
>>>>> itself. What you need is active leadership that encourages such
>>>>> experimentation.
>>>> I don't know about that. I agree with you that there hasn't been
>>>> active leadership for a while. But look what has happened without this
>>>> active leadership.
>>>> * We have two cool new Zope 3 based frameworks. One which throws out
>>>> the whole concept of ZCML for doing configuration by radical code
>>>> introspection, and as a result making the Zope Framework immensely
>>>> more accessible. And another one which experiments with revamping the
>>>> way Zope publishes things, and a related effort of rewriting the whole
>>>> publisher. Both frameworks have during these experimentation reached
>>>> big audiences and gained widespread if still experimental acceptance
>>>> in the community.
>>> True - but to me it seems that this happened because someone took leadership
>>> in this scenario.
>>>
>>>> * Zope 2 has been eggified.
>>>> * Buildout has totally massacred all other forms of deployment of Zope
>>>> projects.
>>> All that is true and very positive, but what has not happened and maybe never
>>> will that way, is the aggregation of all those Zope 3 efforts, documentation,
>>> website and the like. And that is something very important in order to
>>> attract a broader user base.
>>>
>>>>> Who decides to kill something off?
>>>> If it doesn't get maintained, is dead. I guess you want somebody to
>>>> make it official. I'm not sure it's necessary in a component based
>>>> reality. With Zope 2 eggified for example, ZClasses gets a separate
>>>> module, and it lives as long as somebody maintains it. It's then just
>>>> a matter of deciding if it should be a part of the release or not,
>>>> which the release manager(s) decide.
>>> That's fine for one thing: Newbies don't know which packages are maintained
>>> and which are not. They find themselves confronted with a bunch of packages
>>> and don't know what they should use and what not. Example: zope.formlib vs.
>>> z3c.form.
>>> For instance, I decided to use lovely.remotetask - but I recognized that the
>>> last commit is quite some time ago and don't really know if it's actively
>>> used/maintained.
>>
>> I'll chime in as a newbie.
>>
>> It seems many of the comments preferring ad-hoc to structure
>> come from "we know what we are doing, we can take care of ourselves"
>>
>> I think Zope has the goal of attracting new users, and the proposal
>> has potential to make Zope more inviting to the uninitiated.
>>
>> Zope is very diffuse, making it a challenge to grasp. I know I would benefit
>> from any initiative which sought to provide an overview role.
>>
>>
>
> I started up with something for zope2.zope.org in order to bring
> sort out the various things a bit:
>
> http://zope2.zopyx.de/about-zope-2/the-zope-eco-system

That's very useful, and seems to describe the theory of the Zope world.
In theory, theory and practice are the same, in practice they are not.

My post was prompted by the mention of knowing which of several
similar components is preferred, deprecated, abandoned.

Maybe this doesn't fall within the proposal, but it strikes me as
an element of 'steering'.

I think that watching exchanges between a steering entity and the dev community
would be a good vantage point for getting a picture of the Zope landscape.

Thanks,
Kent

>
> Andreas
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk
> uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY
> =y1Df
> -----END PGP SIGNATURE-----
>