On Thu, 2 Aug 2001, Anders Schneiderman wrote:
Just to add to Michael's post:
People who use openACS have raised two major concerns about using Zope. First, although Zope is easier when starting off, openACS comes a much more developed, integrated system of modules out of the box, and so althought it is more complex, the complexity pays off. Given that our goal is to build open source apps that work well for larger as well as smaller organizations, this is an important consideration.
The much more serious issue is whether openACS scales much better than Zope does. People who use openACS say that its model can handle much larger apps, due in large part to the fact that openACS is built on a very solid, thoroughly tested data model that uses a relational database approach. Given that at least one of the participants, techrocks, needs a platform that can handle tons of people, this is a pretty big issue.
So, as someone participating in the discussion over platforms, I'd be very interested to hear from people who have used Zope to build large scale applications. In particular:
1) How large of an application have you been able to build with Zope without seeing serious performance problems? I.e., how many users, hits per day/hour, etc.?
2) When you build a large-scale application in Zope, do you have to use a RDMS on the back end? Is there a point at which Zope's object system isn't enough anymore? The reason this is important to us is that there are lots of advantages of using an object system, but if you need to rewrite the backend into a relational database as the app gets larger, then openACS, where the database is there at the beginning, starts to look like a better deal.
We're a nonprofit using & teaching other nonprofits to use Zope. There are some very large sites using Zope now (zope.org >> techrocks.org, for instance), so I don't think that Zope isn't scalable per se. We use a RDMS (PostgreSQL, which scales up *very nicely*), but that has as much to do w/being able to get to our data via traditional database front-ends as it has to do w/scalability). OpenACS is a wonderful system; Zope is a wonderful system. Zope uses Python (a lightweight, easy-to-use, increasingly-popular scripting language and works great w/any database backend or no database backend.) OpenACS, on the other hand, uses Tcl, a lightweight, less intuitive, increasingly-less-popular scripting language (newer versions use Java, a non-intuitive, lower-level real programming language w/a much steeper learning curve). OpenACS requires PostgreSQL (tho' I understand that Interbase support may be added in the future.) [ take the point around languages seriously, IMHO. Compare a snippet of Python code to a snippet of Tcl code to a snippet of Java code. See which one makes sense to you. And regardless of what anyone tells you about ACS or Zope, you _will_ have to do some programming if you want to _really_ customize & use these products. ] [ also, keep in mind that ACS != OpenACS. With great respect to the OpenACS people (one or two who I know slightly from the PostgreSQL community, some of the 'massive-scalabilty' arguments made about ACS have to w/ACS (running on Oracle) rather than OpenACS (on PG). While PG itself scales nicely (there are huge installs out there, I don't know if there are proven huge installs of OpenACS. There might be; I don't know. ] We knew both, and we chose Zope. (Of course, you don't have to simply do as we do ;-) ), however, one of the strongest reasons we chose Zope was hearing the endless complaints of a large local dotcom that uses ACS (& this is with serious consulting w/ArsDigita!) about how messy, complicated, and just-generally-painful ACS was to customize and use. Zope, on the other hand, has been generally quite pleasant and the community has been responsive. If you're ever in the DC area, and want to see the underbelly of a medium-sized nonprofit Zope site (www.scw.org), email me -- we'd be happy to give you a tour. Good luck in your decision, and hth, -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington