It's ambitious as it is sensible -- to have Zope use expand tenfold. But a 10x zope base needs to be clearly defined. It impacts on markets, architecture and community. Talk about moving from a cathedral to a bazaar is confusing (despite Raymond pitching it). A Tenfold (10x) expansion can happen in three distinct ways - via quantity (10x more downloads & deployments), via architecture (10x more functions), or via commitment (10x more active in community). The trick is to set in place initiatives that harmonize and reinforce these three directions. Zope is too big and complex to be sold by advertising (even informal) alone. Ease-of-use is the critical success factor here. Relevance to specific application domains is another. The CMF (and skins), Zope Page Templates, and an eventual 'zope-in-a-box' will drive the download/deployment rate. A tenfold increase is also possible if all the zope instances currently operating expanded in functionality. Imagine a world with 4000, rather 400 Zope products. Here the critical success factor is a Zope Product Manager. Secondarily, there is a pressing need for a better taxonomy of products. Currently the taxonomy used at Zope.org is refers to Zope rather more than its applications. A third dimension is one wherein the interaction between zope services and components was 10 times better. Here is the land of 'new religion', components and frameworks, of Transwarp etc. The sooner components and generic services arrive the better. So far, so obvious. The difficulty lies in not pushing on one of these dimensions and thus undermines another. For instance, a zope-in-a-box can undermine 'commitment' (and community numbers) by expanding the user base and yet contracting the questions they pose. Similarly, more components need to be prioritised to extend functionality (and thus breed more community) rather than re-factor what is already there (and provoke arcane debates on the list about architectural issues that are beyond most of the community). To get the balance, more opinion needs harvesting from the mass of people that *use* Zope to solve specific problems. I, for one, have been working on finding application domains that enable 'mega-products' to be built: ZAPPP - Zope Activated Participative Planning Platform, that enables local government planning regulations to be transparently changed and kept consistent with state-wide planning imperatives, ZELBA - Zope Enabled Location Based Assistance - that enables local communities to mobilise tiny fractions of 'spare time' (of locals) to massively increase the opportunities for volunteer responses, or ZEAR - Zope Enabled Authoring of Research - templated systems for students to write and publish 'articles' while learning research skills. ZOCCO - Zope Orchestrated Client-Centered Offices - by which dispersed care professionals can operate bookings, follow-ups and counselling work in the 'human services' sector. etc etc These kinds of possibilities still use the web - but they are some distance from simply 'dynamic web publishing'. I expect a 10x growth surge will move down these application 'furrows' as much as the wide plains of web-serving. This much is clear: it isn't a matter of cathedral vs bazaar, it is a matter of having *both* - suitably located around a piazza of application discussion. So we need: A) Zope_Series-in-a-box (focussed on application domains and easy to deploy for that reason) B) Zope Product Manager with the options to focus products around 'mega-product' lines (again that's easier) C) A component architecture wherein generic services can be marshaled to meet specific domains of challenges that relate to some real problem in the world The main missing piece here is a dedicated zope list about 'applications' (under which all kinds of "Zapplications" might be discussed thus giving direction to developers and users alike). Oopps, this has got 10x bigger than I had expected. Hope length of argument is matched by breadth of relevance and height of possibilities :) Richard Volpato