[Zope3-dev] Re: Can we provide a Zope3 Collective?

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> 
>> Jim Fulton wrote:
> ...
> 
>> I agree with what Philipp said. That is not so much a reflection on 
>> behavior, but a reflection on perspective and image. This also counts 
>> in the open source world.
>>
>> For instance, if I check something into cvs.infrae.com or 
>> codespeak.net SVN has a vast difference in image, even though both 
>> packages may be licensed the same way.
>  
> We are talking about zope.org, *not* zope.com.

Yes, but after Digital Creations changed its name to Zope Corporation,
from a distance it starts to look alike. I know it's not, but I'm
talking about image, not actual behavior.

>> I agree that the zope.org repository has significant benefits. It also 
>> has drawbacks. A separate repositority has other drawbacks and strengths 
>  
> Yup.  I just think there should be some sanity in considering the 
> drawbacks.

Of course.

>> -- strengths that include a lower barrier to entry and a neutral 
>> position. 
> 
> It's the neutral position bit I have a major beef with.

Let me try to explain the impression someone might be getting:

zope.org is being run by the company called Zope corporation, that
requires you to sign an agreement before checking in, signing over half
your copyright to them.

To compare, imagine yourself checking something into a server called
'infrae.org', with a similar contributor's agreement for Infrae. Compare
this to placing your open source project on a server called
'arbitrarycode.org' which doesn't and invites you to check in code (and
you don't happen to be running a subversion server yourself). I'd argue
the latter presents more neutrality (and an easier barrier to entry) --
even though there are plenty of drawbacks too.

I'm not complaining about zope.org, though. I think zope.org is well
run, I'm grateful it is there, and is as it should be. I also think we
need other places besides it.

>  > Just by being *different* in its strengths and drawbacks is
> 
>> helpful by itself, as this may feed some projects into existence that 
>> might otherwise not happen.
>>
>> I think that the Zope 3 community will be stronger with this second 
>> repository. It's a significant sign of strength of the community 
>> itself to have people develop open source software *for* Zope 3 that 
>> can not in any way be construed to be a *part* of Zope 3.
>>
>> This is what we see in the Zope 2 community; a plethora of 
>> repositories. The different possibly incompatible licenses and state 
>> of maintainability is a drawback, yes, but it's also a strength -- a 
>> strength in diversity.
> 
> Including the diversity of products that are broken by new versions
> of Zope, in part, because they aren't adequately tested against new 
> versions.

Exactly. It's similar to the way the web was built. Links can break,
information goes out of date -- if they'd used a well-managed central
system to store all web pages in, that wouldn't have happened. But the
web wouldn't have happened either. Tolerating some incompatibility and
brokenness can stimulate growth, even though of course incompatibility
and brokenness suck.

With some more toleration, I could for instance now find some half-baked
code in a source code repository because someone felt okay at checking
it in, and I can go and fix it. I wouldn't even dare checking in some
half-baked new project into the zope.org repository. :) So now, we can
find modzope on the web:

http://codespeak.net/svn/z3/modzope/trunk

Anyway, all of us will hopefully be developing some Zope 3 systems
outside of the zope.org repository anyway -- hopefully also some open
source projects. So, see this repository as part of the growth of the
Zope 3 community. We're not aiming to take projects away from zope.org,
just growing the pie of Zope 3 projects that are in community shared
repositories.

Regards,

Martijn