[Zope-dev] Re: The Zope Software Certification Program and Common Repository Proposal

[Martin Aspeli]

On Mon, 20 Feb 2006 21:28:09 -0000, Stephan Richter  
<stephan.richter at tufts.edu> wrote:

> I have spent the last two weeks working on a proposal that defines a Zope
> Software Certification Program (ZSCP) and a Common Repository that  
> implements
> this process. The proposal is attached to this mail. I welcome any  
> comments
> about it!

Hi Stephan,

I have only skimmed the document, since it's 1am and I'm going to the  
mountains tomorrow. I expect a triple-digit post count in this thread when  
I return. :)

I think the proposal is very well put-together. I think it admirably tries  
to make the Zope 3 community more inclusive of more peripheral developers  
who simply use the framework, and I think this will benefit Zope immensely  
if done right.

My immediate concern is about resources: Who will have the time or  
incentive to police the common repository and grant certification? It  
seems to be a non-trivial process that may end up being quite  
time-consuming. It may be perceived as too much red tape. It may be  
perceived as too much centralised control, especially around licensing. At  
times it may also be open to debate, and a means of resolving disputes  
would seem necessary. There are certainly a lot of tick-boxes in your  
table! :-)

Secondly, and partly because I'm expecting this to come up in my absence:  
your proposal is eerily simlar to Alan's two-level Plone collective post  
to plone-dev, about having an "approved" list of contributors and packages  
in a fenced-off repository, in addition to the collective.

One obvious parallel here, by the way, is with the svn.plone.org/plone  
repository. That one is controlled by the Plone Foundation, requires a  
contributor agreement, and imposes restrictions on license and quality  
(albeit not as formally as you do). I think this is possibly a more valid  
comparison than with the Collective.

I'm actually +1 on your proposal in spirit (if it can be shown to work,  
and if there is a broad consensus in the community to support it - in  
fact, this is important: if there is too much division, the proposal would  
likely be self-defeating) and -1 on his.

The reason is that the Plone world is quite different from the Zope 3  
world (although there are hard-core Plone developers who sit in both). The  
Plone community is much larger but naturally also more dispersed. The  
software is much more narrowly defined (depending on your point of view I  
suppose, but I mean - it's a CMS, Zope 3 is a framework) and the  
components developed for it are much closer to the user.

Plone thrives on the size and vibrancy of its community. A very large part  
of its success comes from third party products that people find and marry  
with Plone to solve their problems. Without the low bar to contributing  
such components, without an open and very democratic Collective, and  
without "meta-data" on http://plone.org/products, I don't think this would  
be possible, certainly not as successful. The uptake of third party  
product users and contributors, and I think maybe also the quality, has  
improved quite significantly since we introduced the Products section on  
plone.org.

A framework like Zope 3, and framework-level third party components,  
thrives more on control and consistency in vision and implementation. (In  
part, you're solving that with better guidelines around how to write code,  
guidelines that Zope 3 adopters also benefit from.) I think that the lower  
down the stack you go, the higher the degree of centralised  
quality-control needs to be. This, however, is at the expense of perceived  
eltism and a raised bar to entry. I think that balance is different in  
Plone than it is in Zope 3.

Put differently, I think that *some* Plone components ought to move lower  
down the stack, target re-usability in different systems, and thus be  
subject to somewhat different rules. Perhaps these components shouldn't  
have been Plone components in the first place, or perhaps their evolution  
would start in Plone and move down the stack. But I think it would be  
damaging for the Plone community, given its current shape and culture, to  
impose those rules across the types of components that are higher up the  
stack - arguably those components which should be "Plone" components still.

I'd also note that we solve (or try/continue to solve) some of the  
visibility and evaluation problems on http://plone.org/products (which is  
of course open source, albeit GPL, and you can re-use any of this you see  
fit). Some of those same things, you solve with more technical means -  
automated testing, common file layouts, XML metadata files. Again, I think  
these approaches work better at the  
small-component-high-reusability/framework level than they do with the  
types of user-facing components that typically land in the Collective.

Although you proposal is not technical in design, it's technical in  
implementation (so to speak). Perhaps it would be fair to say that the  
Collective is almost entirely social in its implementation. I think it's  
worked very well. For Plone.

Martin

P.S.
If you have specifics you'd like me to respond to, please cc me, since I'm  
offline until Sunday night (and it was just getting interesting, damn).

-- 
(muted)