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

whit whit at burningman.com
Tue Feb 21 08:47:39 EST 2006

Martin Aspeli wrote:
> 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! :-)

I would say an inhuman number of tick boxes.

the idea is to automate this as simply and effectively as possible 
rather than have people do it. Stephan has taught the doctest module to 
give tutorial, so I trust he can teach svn to rate code...

All half-joking aside, we all use a variety of metrics to judge code, 
from checking dates of checkin, reading svn logs, running tests, etc. 
This would just take those common things we developers do everyday in 
the wild west of the collective, and automate them.

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

alan's purgatory is similar, but I would argue, complementary rather 
than duplicative.  we the gardeners of plonistan could stand doing a 
little cleanup of our backyard.

Purgatory is a process that has to do with evaluating what developers 
want to move forward to zope3 / adapter land (and organizing support 
around this), the zscp proposal is where this stuff would eventually land.

purgatory can happen whenever. zscp requires a bit more overhead.

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

the collective has definitely been a success and most of it's problems 
are from it's success (much as plone).

where the collective (and I would argue, plone also), start to fray 
around the edges is due to the fact that social interactions, though 
powerful, have limited scope and the more people in a group, the less 
likely communication will be effective.

what hopefully zscp would do is allow a code commons at one end (ala 
collective, easy entry, friendly to experimentation) and a fully 
certified set of components at the other.

In between, there would be well defined process for how software moves 
from the primordial ooze to canon.


More information about the Zope3-dev mailing list