I agree that people should only build what they need. The nice thing about Zope being open-source is that it evolves well to its communities use cases; I would argue that Zope-based solutions would adapt to user communities that are not a bunch of software engineers working for software companies. I used to work as a developer for an R&D company and now work for a dot-com doing the same sort of work, but my priorities are very different. Zope, frankly, is a more pragmatic solution than committing to the Java platform for a variety of problems faced by those of us not working for software vendors, and I think is better suited to an open-source user community. Two particular things: One: Enhydra seems ideal if you have investment in the Java paradigm (i.e. you have Java coders in house). The thing is that Zope has a lot of strengths in the ODB that you can't get with your typical OO Java servelets combined with an RDBMS back-end. For complex relational data, the Java app server approach might make sense, but the thing that sells me on Zope is the fact that their are problem domains that are a total misfit with a relational data paradigm, like online content publishing (media sites), intranet collaboration (workflow objects associated with discussions associated with content created via content management) - not to mention the entire problem domain of XML in general. So, java app servers make sense if you meet all of the following criteria: - have data structures that are tabular, or have a small set of relations to other data - have a full-time DBA - have a full-time Testing Department (test manager, testers) and Formal Software Testing - have at least a senior Java programmer or two - Have a fairly technical project manager that understands how the app server works, in order to divide up work - Fully implement formal documentation standards, including UML, requirements & design docs, and EXTENSIVE API documentation - willingness to work on a deadline that is not as tight, putting quality always before expediency In other words, java app servers might make perfect sense for those working in an R&D company, ISV, or other vendor selling software, but it creates complexity when you want to extend this to an open development model because the learning curve is steeper, and it's easier to screw something up. If you work with limited resources, and are not building a product that is going to have an expected sale value, but rather only internal use value (i.e. you are a web company trying to get a site up versus a software company selling a $25,000 shrink-wrapped box). When in that position, you need content management built-in; you need portions (like the interface layer) to be as easy as possible (Why should one be required to compile an html file into a DOM binary - why not just use an ODB???); you also are not going to have a testing department, you will have a stricter deadline, have less technical project management, and no docs, and more employee retention problems. The attitude is get it done, with the best possible balance of doing it "right" and getting it up live. Zope fits the bill for most folks who have to work in a pragmatic world of building and constantly refining software for their own use. I'm not saying that we shouldn't have formal docs, testing, etc of software, but that some of us have to maximize quality under certain constraints that guarantee that the Java app server approach would be flawed; Zope fits (python is easy to work with, the presentation layer concepts in Zope are improving, etc). Zope also maps to open-source ideas better, because it allows for a less centralized formal development model, and the idea of constant refinement. In the future, especially in certain vertical markets (like mine, publishing), the folks that comprise your community will not be trained software engineers - they will be folks like librarians, part-time web developers, designers, project managers, and production engineers/sysadmins - and in that open source world, we need to be able to create scalable software systems, but not raise the barriers to entry to make them inhuman. Zope isn't perfect in this regard, but at least it's leaps and bounds better than the alternatives. Two: Perhaps the biggest gripe I have about the "why-not-zope" arguments is simply that they make the assumption that Zope is somehow a product, and so they complain about what it cannot do, rather than realize that zope's primary asset is a strong community and a strong, swift software process; I have seen Zope evolve quite rapidly over the last year-and-a-half; I use that as empirical evidence that Zope grows with its community member's use-cases. Gripes about things like through the web editing, cvs, etc will likely be things of the past in the not too distant future. I think Zope has some advantages over both other approaches in that it has an approach that targets a different set of uses. While we can argue about Zope's fitness being a "general-purpose" app server, but when it fits the needs of its users, or adapts in order to do so, what's the point? Sean -----Original Message----- From: Terrel H. Shumway [mailto:tshumway@octavian.ICS.UCI.EDU] Sent: Friday, December 29, 2000 11:10 PM To: corey@axcelerant.com Cc: zope@zope.org; tshumway@octavian.ICS.UCI.EDU Subject: Re: [Zope] Zope vs. Enhydra Flame bait? Catch this: I have recently been reaching the disillusionment phase with Zope, so please take it all with several grains of salt. I happened upon an article in the ArsDigital Systems Journal that I thought was a fairly neutral review of Enhydra. http://www.arsdigita.com/asj/enhydra/index.adp The more thought-provoking part of the article was a reference to a fairly disparaging view of application servers in general. http://www.arsdigita.com/asj/application-servers What got me to ArsDigita was AMK's Zope frustrations. http://www.amk.ca/python/writing/why-not-zope.html (BTW, some of these issuses are being addressed.) Which also lead me to Chuck Esterbrook's musings http://pywx.idyll.org/advocacy/why-not-zope.html http://pywx.idyll.org/advocacy/why-not-zope-2.html Chuck Esterbrook created webware as his answer to Zope's limitations and complexity. http://webware.sourceforge.net/ Titus Brown advocates use AOLserver and Python (instead of TCL) http://pywx.idyll.org/advocacy/ IBM developerworks has a couple of Enhydra articles (which I have not read yet) http://www-106.ibm.com/developerworks/library/enhydra.html http://www-106.ibm.com/developerworks/library/w-friend.html?dwzone=web In summary: Don't build what you don't need -- do the simplest thing that could possibly work. Evaluate potential solutions in terms of business value to YOUR customers, not in terms of market hype. HTH -- Terrel Shumway _______________________________________________ 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 )