Thanks for posting this. (Thank you too Chris for starting the Zope 4
thread.) Despite the inevitable bike shedding, I think this is a
discussion worth having.
Here are my opinions, which build on the arguments you gave, even
though I disagree with some of your conclusions.
1. I hate "Zope Classic". It was a mistake for Coke and I think it
would be a mistake for us too. :)
2. I think Zope 3 the application should die. It should go the way of
3. I think the word "Zope" should refer to both the application
currently called Zope 2 and the Zope ecosystem, depending on context,
although I'm also fine with coming up with another name as long as it
doesn't imply obsolescence. :)
On Apr 8, 2009, at 9:31 AM, Martijn Faassen wrote:
> Hi there,
> There was some discussion recently on how to name Zope in the future.
> Here are my thoughts and suggestions.
> First of all some principles I tend to follow surrounding names.
> * I prefer not introducing too many new names at the same time. A
> renaming takes a while to percolate through the community and people
> gain full understanding of it.
> * I prefer naming something that already exists (or renaming
> as opposed to naming something that doesn't really exist yet. A name
> a handle on something that we can then use to talk about it and reason
> about it.
> * Naming discussions tend to lead to endless bikeshed discussion.
> stuff is easy so everybody has an opinion, including myself. It's not
> very productive. We don't have clear community mechanisms to make
> decisions either (the Zope Framework Steering Group isn't it; it only
> cares about the Zope Framework. Perhaps the Foundation can be it,
> but it
> can only approve initiatives from the community in this area, I think.
> In this context I'll mention the new name "Zope Framework" that was
> recently introduced and is probably not yet fully understood by
> The Zope Framework is a collection of libraries. It's shared by at
> the following web frameworks/app servers: Zope 2 app server, Zope 3
> server, Grok. Other systems such as bfg use a much smaller subset of
> these libraries.
> I see this as following the principles above:
> * it's only introducing a single new name. That's why it at least gets
> some acceptance now.
> * it's naming something that we were really already talking about.
> Unfortunately we conflated it with "Zope 3", the thing you start that
> has a UI and so on, which retarded the development of both Zope 3 and
> the Zope Framework itself. It's good we have a handle on it now as a
> separate entity.
> This "Zope Framework" name and concept is just now percolating through
> the community. Zope Framework is *not* the renamed Zope 3, even though
> it's entirely based on what we used to call Zope 3. Zope 3 continues
> exist, as long as there are people who are interested in creating an
> installation tool for it and care about its UI. Zope Framework is a
> *separate* entity.
> Zope 2 and Zope 3 do have confusing names. I prefer to tweak the
> of "Zope" to be a project identifier instead of identifying software
> directly: Zope is all of the stuff developed by the Zope project. We
> therefore have the Zope Object Database, we have the zope component
> architecture, the zope interface package. This doesn't work for Zope 2
> and Zope 3. It works for Grok by the way: I've been saying "Zope Grok"
> With Zope 2 and Zope 3, we have version numbers that are at the same
> time identifiers of a piece of software itself; they're not really
> version numbers at all. That's why I have been using terms like Zope 2
> App Server and Zope 3 App Server, but that isn't very satisfactory
> either. The 2 and the 3 still imply some kind of evolutionary
> progression that isn't quite what we are doing.
> In order to make Zope 2 and Zope 3 fit the pattern, it'd be nice if
> had names that fit the "Zope is a project, not software" pattern. We
> could rename Zope 2 to Zope Classic, as was suggested. I think we
> also rename Zope 3 to something else (that doesn't imply it's the
> future, as there are other alternatives at least as modern around that
> are more recently developed - we want to get out of that bind).
> I think renaming Zope 2 to Zope Classic will be easy. If the Zope 2
> developers are okay with this, let's go right ahead. Not much
> needed. Zope 2.11 becomes Zope Classic 11. It's a huge version number,
> but Zope Classic is over a decade old anyway. Nobody's going to
> mind. It
> looks impressive and it should be impressive; Zope Classic has been
> maintained for a long time by the community.
> I think it's going to be harder for Zope 3, as the "Zope 3" community:
> those people who care about Zope 3 as a piece of software that can be
> installed, hasn't fully formed yet. There's a tool called
> which is quite misnamed in the light of the above discussion. While I
> sometimes do use that piece of software, I'm far more interested in
> Zope Framework, myself.
> Anyway, I'm rather reluctant to post this as I fear this will be a
> pile-on bikeshed discussion. I'd suggest that anyone interested in
> naming Zope 3 something else should keep quiet for the time being. Go
> and form a Zope 3 interest group first, don't talk about naming too
> yet in that either, and come back to this topic later.
> Let's talk about Zope Classic and see whether renaming Zope 2 to
> that is
> a step we can realistically take in the near future. Who is in favor
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -