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
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
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:
(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 :)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -