[Zope-dev] the Zope Framework project

[Martijn Faassen]

Hey Tres,

Tres Seaver wrote:
[snip]
>>> - 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.

Sure.

 > Such a fork has several benefits:
[snip benefits of forking]

Besides forking, there's simply starting a *new* project that builds on 
what's already there, see for instance Grok. Five is an older example of 
such an effort. Both provided a space for experimentation.

> 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?

Yes, learning lessons from forks, or adopting them wholesale, is good.

I think that this goes beyond just forking, but also applies to ideas 
and directions.

Leadership plays a part to recognize say, the success Repoze had in 
taking Zope concepts and radically simplifying them making them more 
easy to comprehend, and then seeking ways to bring some of that back 
into the Zope Framework (or Grok or whatnot). Or the success of 
WSGI-happy approaches and adopting that as a way to solve 
comprehensibility issues in the zope publishing stack. Or to recognize 
that the ZMI isn't really going anywhere fast and encouraging 
alternative more limited approaches such as the Grok UI.

>>> - 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.

Yes, this sense of stop energy is shared very much by me myself, so I'm 
not at all hypothetical about this either. It drives my effort to try to 
change our culture. One way to avoid stop energy is to have a group of 
people (or one person) with decision making powers that can and will say 
"yes". (often: "yes.. but do this detail that way so it doesn't hurt 
other effort X").

>>> - 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. 

It'd be nice to have a way to go forward without running into trouble 
then. It shouldn't always have to be forking just to avoid stepping on 
toes. A clear mandate for making a change from someone who has the 
authority to give that mandate, and who displays the pro-active behavior 
*giving* such mandates almost before it's asked for, should help.

[snip]
>>> 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.

It's both: we're a community who cares about a lot of packages together 
and how they work together. At the same time we're a community of 
smaller communities with interests in individual pieces. But those 
smaller communities need to coordinate things together, especially if 
they want to change bits deeper in the stack that are shared by lots of 
people.

>> 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.

Yes, that was an explicit decision on my part. I made it clear at least 
to some that I was going to work on this in general, but avoided us 
proposing specifics on the mailing list as there'd always be people 
saying -1 and endless discussions on details people not involved in the 
sprint would only understand halfway.

It was also the decision of a bunch of people to take that 
responsibility. And I agree with you that people in open source tend to 
get responsibility where they take it.

It worked this time. Will it always work?  Not everybody would've felt 
confident they could've gotten away with it, and some of these people 
would've done good work. I know my reputation in this community is 
secure enough, but what if I were newer? I'd have been more comfortable 
if someone had told us in advance: "we trust you, please go ahead".

Leadership is also about channeling and encouraging energies that are 
already there. Keeping the fire burning, and putting on a bit more fuel 
once every while. Part of this is to give people the confidence they can 
go on without getting into trouble.

>>> - 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.

We do have a whole lot of people who do need a bigger list. If you need 
a few newer versions, you can probably get away with just overriding a few.

>> 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."

I think there are a number of answers here:

* decisions need to be made that are unpopular with some group anyway. 
Not everybody is going to be happy always and that's a reality we can't 
avoid. Having someone there with the responsibility to balance interests 
should at least make better decisions than the "no by default" that all 
too frequently we get now.

* Such decisions can provide security and sometimes allow other progress 
while leaving it in the middle may not.

* If you know who is making the decision, there's also a less amorphous 
group to convince. I only needed to convince Jim when I wanted to rename 
some attribute in zope.interface so it would be compatible with Zope 2, 
not everybody else, and eventually he agreed, though it took a while as 
Jim had another vision about how such integration should work. Then we 
got Five.

* leadership could help sustain efforts like "we want the Zope Framework 
to run on Jython" and make detailed decisions based on this. Nobody 
right now can really decide on this.

This requires vision and a certain quality of leadership. We might not 
get it. But at least we'd have the potential for sustained vision where 
now we have little of that.

Regards,

Martijn