[Zope-dev] the Zope Framework project

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hi there,
> 
> Chris McDonough wrote:
> [snip]
>> I'm pretty sure a steering group and a rebranding of existing software is not
>> going to make us more effective. 
> 
> I'm proposing a deconstruction, not a rebranding; a new name is 
> introduced as an entity needs to be named, namely the Zope Framework.
> 
> What is going to make us more effective is:
> 
> * a recognition of current reality, i.e. the Zope Framework is not the 
> same as the Zope 3 application server and it serves a far wider audience.
> 
> * leadership

At the moment, the leadership in the "big tent" Zope community is
diffuse:  I will agree that we have a vacuum when it comes to leading
the direction of the "widely used" bits which make up part of the
current Zope3 release, mostly because folks are super busy.

One way people can contribute to the leadership needed here is to avoid
chipping in on pieces of the puzzle where they don't have a real stake:
 for instance, I would hereby disqualify myself from any attempt to
steer the bits which make up the Z3 ZMI.

>> - encouraging radical change for experimentation purposes, releasing folks from
>>   various constraints (backwards compatibility, style policing, historical
>>   ownership)
> 
> 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.

Avoiding the "stop energy" Chris metnioned is part of the "encourage
radical change."  One way to do radical change is to fork a project.
Such a fork has several benefits:

- - Existing consumers of the forked project are not perturbed, because
  the already-releasd old project serves their needs.

- - The new package can experiment with heavy refatorings, new APIs,
  etc., without the burdens imposed on "in place" upgrades
  (deprecations, BBB imports, etc.)

- - The develpoer can proceed with making the forked version work as
  well as possible without "asking permission" from anybody who feels
  ownership over the original version.

- - Until the fork is successful, we don't have any need to "steer" at
  all.

A failed fork is low-cost for the community:  it just dies on the vine.
 The only downside is namespace issues (e.g., zope.app.form vs.
zope.formlib vs. z3c.form).

Defining "successful":  I would say that a successful fork is one which
is being used in "real" projects in ways which displace the original
version of the package.  Once a fork reaches this stage, *then* we have
the opportunity to "steer":  should we try to re-merge the fork back
into the original (a la egcs)?  Or should we deprecate the original and
all switch to using the fork?

>> - discourage the contribution of stop energy (discourage
>>   the utterances of "don't", "stop", "this is wrong",
>>   "stop talking about this").
> 
> +1, though a simple discouraging of utterance can't accomplish it by 
> itself. What you need is active leadership that encourages such 
> experimentation.

Right.  I will note that Chris isn't being hypothetical here:  we have
seen a number of cases where folks who were motivated to improve a
widely-used package were discouraged from their efforts by such discourse.

>> - focusing on externalizing software; each egg should stand on its own as
>>   something that a non-Zope person would be able to understand and use
>>   in isolation.  This means documentation for each thing, as well as
>>   a sane dependency graph.  
> 
> Sure, I agree with all this. Does everybody? What if we get 3 times -1 
> and 3 times +1 in a discussion on it?

The -1 votes would be "stop energy."  Any package which satisfies Chris'
criteria is *still* useful in the bigger Zope framework, while the
converse is not true.  E.g., consider the current dependencies of
zope.component:  if I made checkins which stripped out the use of
'zope.deprecation', 'zope.deferredimport', and 'zope.proxy' (or made
them optional), the package would be more useful to people outside of
Zopeland (e.g., developers targeting the GSA, Jython, IronPython can't
use zope.component today because of hard C dependencies).  The tradeoff
would be that "old" Zope3 code might need to be updated (e.g., removing
use of BBB features, or relaxing security requirements).

>> This is *less* about giving this collection
>>   of software a group name ("the zope framework") and more about
>>   making people *forget* that it is a part of some larger thing.  When
>>   a piece of software does not have a purpose in isolation but still
>>   lives in its own egg, kill it off and merge it back into whatever
>>   thing its most closely related to.
> 
> Someone's still developing all this software: our community. Someone 
> needs to take responsibility for all this software. I'd say that group 
> is the Zope project.

I would say that *nobody* is developing all this software:  different
sets of people are working on different pieces / subsets of it.

> Who decides to kill something off? Who decides whether a merge is okay? 
> Who decides we should have a documentation website for a widely used 
> component.

In the end, only the people willing to do the work.  For instance, the
recent sprint on reducing dependencies made changes which, if discussed
ahead of time on this list, might have been "vetoed."  Because the
sprinters went ahead *without* discussion (outside the sprint itself),
they made progress which would have been much more painful, and maybe
infeasible, in a more heavyweight process.

>> - Stop trying to version control and treat all this software in some
>>   overall release.  Let each piece of software have its own life.  Likewise
>>   if a piece of software does not have its own life, kill it.
> 
> If you don't have a list of "known good" versions you don't know what to 
> test together, unless you maintain a separate list for each library, 
> which would require a lot of coordination overhead which a single list 
> does not.

The usefulness of the "single list" drops off fast for folks who don't
need the whole thing, or who need newer / older versions of one of the
packages.

> If you say we shouldn't maintain a known good set, then other systems 
> building on top of this will need to maintain their independent lists 
> all by themselves, and there's less chance that Zope 2's, Zope 3's and 
> Grok's list will agree. I think such an agreement is a good idea.
> 
> Just because *you* tend to use a few selective libraries for your own 
> efforts doesn't mean everybody else is. I think we should definitely 
> support your use case, but not only your use case. A steering group 
> would be aware of these use cases and balance them.

In the scenario I outlined above (a developer proposes stripping out
CPython-only dependencies from zope.component), how would a steering
group help?  The "vested" groups would see little benefit (*their* code
works already with the CPython-only code), and would therefore have
little incentive to encourage such an effort:  they would likely be big
contributors of "stop energy."



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrHNy+gerLs4ltQ4RAvwkAKCIcG83UaQgzVltDeQmZgt1cPAR1ACglJAv
gNhIH/oNtBpiqUZp/gyoncc=
=Q9Mk
-----END PGP SIGNATURE-----