Re: The Zope Software Certification Program and Common Repository Proposal
On Mon, 20 Feb 2006 21:28:09 -0000, Stephan Richter <stephan.richter@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)
On Monday 20 February 2006 19:24, Martin Aspeli wrote:
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.
Please read section 2.8 carefully. Here is the most relevant part: Both, the requirements and process, are developed in a way that it should be also simple and fast to receive certification level 1 and level 2. The turn-around time of a request for being granted a certification level 1 or level 2 should be about 1 day. The certification of level 3 will usually take some more time, since it requires the certification manager to inspect the code in much more detail. However, the certification time should not exceed a couple of weeks. Overall, it is very important for the process to have as little overhead as possible and make the certification process a quick, easy and fun experience.
It may be perceived as too much centralised control, especially around licensing.
In the sense that the Zope Foundation is giving out the certifications, yes, it is centralized. But this is necessary, to make the process seem valuable/legitimate. All other certifications are centralized too, such as the TÜV controls the C2 security certification process. In terms of license, the ZSCP makes no assumptions. Even commercial projects can be certified if they show a certification manager their code. All of section 2 does not talk about a required license. A particular license will only be asserted on the Common Repository, like the ZPL is now for svn.zope.org or the GPL for the Plone core.
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.
Yes, I am surprised he posted that. He was on the pre-proposal committee and knew for a while this was coming. As you can see in Appendix 3, there were several Plone developers involved in the recent discussion.
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.
Yeah, probably. As far as I understand the Goldegg protocol, the goal is to develop generic components that could be under a different license. So ideally I would like to have those components live in the Common Repository, but they do not have to. I have mentioned that at various places in the repository.
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.
Great! I agree with your reservation; but we have to try and from the comments I got from the pre-proposal committee (which represent a wide range of Zope sub-communities) I was encouraged that we would find a general agreement. <snip discussion on Plone versus Zope 3 development>
eltism and a raised bar to entry. I think that balance is different in Plone than it is in Zope 3.
Yes, I agree. Thus the proposal clearly states in section 3.2: The Common Repository is *not* a replacement for other high-level repositories like Plone's or ECM's. It does not aim at assimilating everything in the wider Zope community. It is merely a place for high-quality packages that are supported by the Zope development team.
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 would never try to do this. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
participants (2)
-
Martin Aspeli -
Stephan Richter