Hi Zope Folks, My apologies if this is not the proper forum for such a post. Please point me to a more appropriate list if you know of one. Also, sorry for the extended absence, things are hectic lately. I have been trying to keep up with the lists, but as you all must know, doing that well could be a full time job. Not to revive the "Zope needs an E-Commerce, Membership, etc." thread that flamed not far from here in the recent past, but something just turned up that is hard to ignore. So, I have a request for you each to kindly consider. Please try to set aside whatever pressing need you're currently focused on for a moment and look at the very big picture. Zope has such potential and is already serving so many with unparallaled power and flexibility, but is still "in the closet". Maybe that is the natural state for a rapidly maturing Open Source project. After all, Linux itself was a "labor in obscurity" sort of amateur project for nearly a decade. Please note, the true meaning of "amateur" derives from it's root word which is latin for "love". Linus is not the first to procalaim the value of efforts extended for the love of the art. If so, then "never mind" (as Gilda Radner used to say in the persona of the perenially confused Emily Litella). On the other hand, if you like myself remain mystified that Zope hasn't made a massive splash in the Application Server market, then maybe it's time to think about "the grand plan". This blurb struck a chord, and frankly kind of ticked me off: http://serverwatch.internet.com/news/2001_07_09_a.html Most of the substance is quoted below. 'the worldwide application server market bucked all trends and grew 128 percent, reaching almost $2.2 billion in 2000' 'on top of 1999's worldwide revenue growth of 110 percent to $957 million.' '"It's difficult to overstate the significance of this growth rate. When a market reaches the level of maturity that the [application server software platform] ASSP market reached in 1999, annual growth usually slows, not accelerates," said Steve Garone, IDC's vice president of Application Development and Deployment research."' '"Survival in the ASSP market requires more than just ASSP products. Vendors need to provide an e-business platform that includes all the functions necessary to build and deploy e-business applications, leveraging the ASSP as the foundation layer," Garone said. "BEA and IBM both understand this requirement."' Now for the big picture part. Certainly one of the great strengths of Open Source projects has been diversity, and scratching the assorted itches of a broad range of users. How could we truly appreciate Python, if there had been no Perl? ;) On the other hand, with a global cadre of talented Zope users toiling away, there is bound to be more than a little duplicate effort. How about treating some of the most critically needed Zope modules as a community project? Can a community wide process be adopted so that an architecture can be established, and the components then be built by individuals or small teams, and then dropped into place? Such a scheme wouldn't rule out duplicate effort, if folks think that the benefits of jovial competition and meritocracy are essential, but it could help point all the wonderful things that Zope contributors have and continue to create in a direction where more stuff plays nice with it's neighbors, at the very least. ZPatterns was intended to enable some of this, and of course there are other approaches as well. Getting Zope to a point where it's own elements can all "get along" would be a great first step, but the ultimate goal is actually much bigger than this. For example, see the work underway at GNU Enterprise (gnue.org). The GNUe project has settled on some of the finest that Open Source has to offer when selecting their foundation toolkit. The concept behind the GNUe Forms has echoes in the Zope world already. A GNUe form based application has it's "screens" defined as XML files, which can then be rendered by any of a number of cross-platform clients. An XML based application interface would be treated as an "aspect" of the implementation. There is no reason a Zope client could not be provided that would instantly empower the GNUe suite as a Zope plug-in, or Zope as a Web enabling plug-in to GNUe. If you are wondering why GNUe matters, take a look. The GNUe team is building nothing less than a GNU licensed Enterprise Resource Management system, along with virtually every critical business function from financials to B2B and EDI. Maybe flying under the radar is exactly the right place to be, if it empowers Open Source service providers to help small to mid-size customers to leverage a full ERP system. GNUe will be the kind of technology that only the GMs and GEs of the world have been able to afford, up to now. Unfortunately, my experience is that such customers are even less informed about the benefits of Open Source options, and thus even less likely to embrace a "no-name" solution. This gotcha calls for a second front, the "emerging from obscurity" part that must accompany the coordination and cooperation part. Treading carefully enough to become recognizable, but not enough to appear as a "threat" to the likes of the high end competition is a strategy that has worked before. See Quicken and Quickbooks, by way of examples. By adopting a service centered approach, and focusing on customers that the "big boys" weren't interested in anyhow, Zope and GNUe can gain a foothold in the conciousness of small business, and build toward the larger markets as maturity and experience are acquired. Zope can be "right in there", but it may take a degree of coordination and project management that up to this point has rarely been seen outside of DC's internally sponsored efforts. Just my $.02, Jerry S. P.S. As many of you have figured out by now, I am not a native speaker of "code". Studies of personality types have revealed that there are a few individuals (fortunately a small minority) that are permanently stuck in "big picture mode". That seems to be my "problem", and even though I can scrape by and make a living crunching code, I have had to face reality and admit that it will never be "second nature" to me. Instead, the best I can do is to leverage the one thing I'm inclined by nature to pursue, which is at the opposite end of the implementation spectrum. So, don't expect to see crystalline examples of code coming from my direction. At best I can attempt to explain the work of others in a way that more folks can grasp. Prose and analogy describing connections and implications are mostly what I'm up to. Do yourself a favor and skip any posts with this by-line if such are not useful to you. BTW, Thanks for your perseverence in getting this far!