Zope v OpenACS and nonprofit application developers
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. Any thoughts/comments would be extremely helpful. Thanks, Anders Schneiderman Information Manager SEIU International
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
I've been following ACS for a 2 years now. I've downloaded their software, read a ton of stuff about it, used Tomcat and Resin, and I still have a homepage on photonet. I have absolutely nothing negative to say about it. It is a great system. It is not an easy system and there is nothing inherently wrong with that.. almost all good, configurable systems have a steep learning curve. (Including Zope..as everyone knows.) And you are right, the complexity will pay off. (with either system) ACS was one of the systems we recently evaluated for our Intranet. We chose Zope but many parts of the Intranet will be built with ideas that are responsible for the success of ACS. And much of the evaluation of different systems included a lot of knowledge gained from Philip Greenspun's posts and his book, "Philip and Alex's Guide to Web Publishing." One of the most valuable things I got from the book is that in Greenspuns eyes, it not the web system (software) that is responsible for the glut of poor web sites, lousy software and billions of wasted dollars, it is the programming and design of the systems. (he is very blunt in his criticism of the software/programming industry as a whole.) He also stresses that ACS is not about a particular piece of software (Oracle), a particular server (AOL) or a particular language, (TCL or Java). It is really a philosophy centered around building online communities and he doesn't care what tool you use as long as it is done within that philosophy. He even emphasizes that if you are using ASP or some other system, don't switch, just learn. He gives you damn near every piece of SQL that goes along with this philosophy and tells you the why for almost every line of code. In some ways, the ACS users "concerns" are non-issues. If they followed Greenspuns philosophy, they'd know better. Read the ACS discussion forums to see how "easy" it is to use the built-ins. (and there isn't one of them that cannot be done with Zope/CMF and a few already built products. Scalability depends on dozens of other factors besides the "relational model." Both systems will scale if designed right and run over a solid infrastrucure. Having said that, ACS does have a history with large complex data driven sites, but hell, so don't a lot of other systems. Again, it depends more on who is doing the site rather then the tool used implement the design. Personally, I'd love to see more about the building and designing of complex scalable sites from the Zope community or even borrowing some of Greenspuns stuff and putting it in Zope terms. How about some Java as well? One final thought. Interestingly enough, when Greenspun talked about ARIA (OODB) he said, "Does this mean ARIA is the perfect tool? My biggest complaint with it is that I've already sold my site's soul to a relational database." Bob Campbell ----- Original Message ----- From: "Anders Schneiderman" <aschneid@pop.mindspring.com> To: <zope@zope.org> Sent: Thursday, August 02, 2001 8:17 AM Subject: [Zope] Zope v OpenACS and nonprofit application developers
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.
Any thoughts/comments would be extremely helpful.
Thanks, Anders Schneiderman Information Manager SEIU International
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (3)
-
Anders Schneiderman -
Bob Campbell -
Joel Burton