Back from Easter, back to see what's been happening..... On re-reading the Zcommerce discussions regarding Zope, ACS and the nature(s) of e-commerce, it seemed an opportune time to flesh out some of the issues raised (particularly in Walter's analysis: http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html). I end with some recommendations. I am not a developer, but I am pushing for Zope deployments in various settings. I have tried to fill out the issues rasied with some examples - which has lengthened this comment. Overview ========= We are all agreed that Zope needs an e-commerce 'story'. The story has to be about something real and compelling and not simply hype or a hobbled 'add-on'. Zope has some special qualities. These is its 'meta-data facilities' and delegation. There is, I think, a deep link between the strong facilities for meta-data and delegation in Zope and the capacity to transform e-commerce from: (a) the servicing, via a shopping cart, of a (typically fickle) customer, to (b) enabling buyers to co-produce and augment, for themselves, the value in what they are buying. The example of Amazon.com illustrates this - many users enjoy browsing rather than just buying there and many buyers contribute reviews, lists, and auction items. In Amazon's 'engine' lies a collaborative filtering mechanism such that the very trail of purchases becomes part of the 'map' to inform others. The necessary SQL for building this is already in Arsdigita's ACS code. That is no surprise; after all, ACS is a community-building infra-structure rather than a content management system. Of course, the *whole point* is that these two (interactive web models) are converging. Now for some more detailed thoughts É.. Customer <===> Member ==================================== If e-commerce is seen as an 'add-on', I think a mistake is being made. Such an 'add-on' will look like some shopping cart with a 'back-end' that helps a solitary customer buy some 'thing'. Huge parts of the economy involve more than this. Many service areas - from financial planning, education, health, lifestyle, travel, welfare, etc - all involve service professionals working to transform a client. There is a tug-a-war going on in the economy as to whether 'clients' can be reduced to 'customers' or whether they get better service as 'members' of groups focussed on their problem. These services are labor intensive and thus, not very scalable. However they become easier to deliver and more profound in their effects if the 'clients' find a way to transform each other. Thus a classroom enlivened by discussion is easier to teach than one passively responding to the 'teacher'. The 'web' has pivotal role to play in these service settings. Unfortunately, the drive for 'web enabled service delivery' has missed the point of giving clients a voice and tried to commercialise the wrong aspects. It is only now with the kind of architecture offered by Zope that a path to authentic web support becomes feasible. The web appears to offer 'scalability'. While services may be labor intensive, what is labored over (ie The Content) appears not to be: vast numbers of web sites offer financial advice without the adviser, curriculum without the teacher, exercise regimes without the trainer, itineraries without the travel agent; health without the doctor etc. Yet this kind of web delivered Content is often "dead on arrival". Either interactivity is lost; content is not refreshed fast enough, there is not enough (any!) personalization, localisation or sequencing; the modes of delivery are too demanding or standardised, the 'Content' was just plain mediocre to start with etc. Sure initially, 'customers' feel they have choice, cheap deals and are freed from the condescension, price fixing and the repeat 'sessions' of service professionals. They are discovering that much of this was a costly chimera The challenge is to scale the service via a platform that gives voice to, and can collect money from, clients. If the web can enable clients to witness the effects of their collaboratively achieved self-transformations, then they are 'hooked' (for all the right reasons). This is where Zope has a compellingly powerful architecture - except for a 'blind spot' regarding 'e-commerce'. In my own experience, I have seen University curricula reduced to pedagogical pap through such web tools like WebCT: Courses as different as physiology and history all start to 'look and feel' the same. Zwiki's alone, make for a more compelling experience, let alone another design I have worked on: the Web Enabled Authoring of Research (WEAR) which exploits Zope's capacity to delegate authoring, editing and templating. In this way, using social data and field research, students can write chapters of real books and become 'authors' rather than memorising readers. In short, the WWW is currently full of 'scaled-up' content-for-service that have reduce clients to customers and lost service quality. Before highlighting the revolutionary potential Zope has in this context - of scaling up service enactment, rather than service content - it is worth contrasting what Arsdigita does in this regard. Arsdigita has a keen appreciation, that if people have a problem or puzzle, and they are given a 'voice' through which to share commonalities, then they begin to 'help themselves' (eg as the many thousands of photographers, mostly in small US towns can and do share their lives at Photo.net). Ironically, Zope is often described as a framework for "customers who have customers who have customersÉ." While the technology that achieves this, is superior to Arsdigita, the way it is talked about seems to me to be far less provocative to true to the architecture its describes. We need to emphasize the the value of, rather the capacity for, delegation, in a business context. Otherwise, the community creation capacity that goes with delegation (as implemented in Zope) is hidden. Indeed, I think, Zope's content management regime has the (unintended?) consequence of being a uniquely scalable "content-for-service delivery" regime. Service delivery in these contexts, means service consumption, which can mean transforming 'clients' into members. Regardless, they mostly want to pay. This is why there is a deep need for e-commerce to be intimately tied to content management More importantly, the meta-data tagging available in Zope enables 'contributions' to be assessed and potentially monetised as credits - thus enabling 'eager but poor' clients to pay through contributions of labor rather than cash - something Arsdigita has built into is customer relations module. Zope I am sure means many things to different users. I think there are good reasons for thinking it has a strategic role to play in being a platform for delivering the kind of content that gets used in various service transactions, not simply users 'browsing' for 'dynamic content'. The individualised, fickle, meandering, whimsical 'customer' can be left to the existing 'B2C' regimes (best exemplified by the deep experience in this area that pornography sites have). Incremental Featurism <===> Strategic Architectures ============================= Wish lists for software always abound: "wouldn't it be nice if we had this or that feature". Wish lists always get too long; developers get too busy, investors get too fixated on the 'winning formula'; and customers ponder on what is hype. One protection against this, that Zope has, is its development, focussed on architecture rather than features. With a sound architecture, features can be added easily. Without it, featurism creeps in and discussion lists get bogged in choosing between listed wishes. This architectural aspect is still missing from Zope's integration of, rather than just access to, RDBMS applications. E-commerce is one such RDBMS application (despite views to the contrary by some on this list). Were the integration to have architectural integrity, then developers could enjoy the kind of Rapid Application Development comparable to that provided for ODBMS applications which are so well catered for by ZODB. It is this part of the e-commerce story that Arsdigita ACS has such immediate value and relevance. If, as I argue, there is a strategic point to enabling 'members' to have voices (rather than just enable customers to confront things), then the 'community building' wisdom in ACS is worth investigating. The work-flow, customer support and e-commerce modules immediately reveal (in their extensive documentation) that they provide far more than 'shopping': they engender membership. Zope is already well suited to delegate the building of 'service bundles' to suit particular contexts (of members with particular needs). This will develop further as the web moves towards 'peer-to-peer' configurations. But even here, there is a need for a commercial infra-structure to service 'membership', otherwise developers will end up looking for 'micro-payment' mechanisms which, I think, are too onerous for users to routinely engage (even if 'micro-payments' looks like a 'cool' feature). Dot-Coms <===> Dot-Nets ====================== Dave Winer somewhere contrasts Dot-Nets with Dot-Coms. Dot-Nets are companies that have business models which do not require vast 'customer bases' (enticed with 'free stuff'). Dot-Nets harmonise and modulate the productive capacities that are already there - providing a medium for new synergies of production. In economic terms, it's the economies of Scope rather than the economies (and tyrannies) of Scale. Zope is a synergy-engendering platform. I think, there are many new markets for Zope in the 'old economy' offices and factories, rather than new economy 'dot-coms'. A nice example of this is 'call-centres'. They use phones, but they are still factories, (in effect). Their main source of 'energy' that powers these monsters of 'customer care' is the emotional toning of the telephonists (dealing with travel bookings, electricity bills, medial issues, appointments, etc). I have been trying to convince one financial institution (which has moved to 'call centres') to imagine that some kind of software (eg Zope) could 'dissolve', as it were, the whole phoney (sic) edifice of telephonically delivered customer care - replacing it with 'digital communities of care'. These in turn reduce the need for one-to-one consultations that are highly costly in service industries. In many contexts, clients prefer to set up their own information portal and meetings - if only they could get such an arrangement in place. Zope is precisely this kind of software. However for this to be operational, it desperately needs a transaction engine capable of doing e-commerce in the style noted above. Note that DC itself could never take responsibility for acquiring the core competency to deal with any one of the specifics mentioned above such as travel bookings, utility billing etc. Nor could it fathom the actual enterprise engines behind these service delivery systems. But DC does have a framework for the purely web side of any such project that is very suitable for Rapid Application Development and the evolution of web supported (real) services and transactions. In my case, I'm not a developer with a deep understanding of the technology issues. Nor am I one of these "dot.com" entrepreneurs who will disappear with the NASDAQ bubble. I sit on Boards and undertake social renovations in areas that are not very web-enabled (suffice for e-mail and browsing). One Board (of a superannuation fund) we are studying technology that I know is going to be critical to the future of this "old-economy" service industry that has "members" (contributors) with "information needs" about pressing life-planning problems. Many such sectors are still just "testing the water" with brochure style web sites. But those in the industry (for years) know a lot more about how business actually works than any "dot.com entrepreneur" and will be the ones paying for web development long after they are gone. At the moment it's difficult to get even small investments from Boards that don't yet understand what they are going to need. Worse, Dot-Com companies offer expensive but 'all-in-a-box' solutions that seem attractive until the inability to factor in localised business processes and understandings become obvious. Road Map and Stepping Stones ======================= First, make the e-commerce 'story' a real journey of development with the hallmark architecture that binds the other core components of Zope Second, adjust to the qualitative 'leaps' involved in thinking about an erector set for content management (Zope) with a web based community erector-set (Arsdigita). I think, by the way, Userland offers something of a bridge and supplement to both in various contexts. Third, develop a (sub?) group of z-commerce that can combine the business solutions issues (noted above) along side the technology issues so that we get a dot-net style development, as opposed to a dot-com. Fourth, I would recommend from a business standpoint that the e-commerce module of ACS be looked at seriously (and this includes the workflow and customer support modules in ACS). Fifth, pool any extant efforts in this regard into a common project (with DC's blessings). Sixth, by building this open source community and managing the content of the e-commerce story we will have enacted the structure that illustrates what we would then be selling. I'd certainly like to join in taking up proposals suggested in this list to start figuring out here, how we can get people who need business solutions together with people who understand technologies like Zope and OpenACS. We can then figure out ways and means of raising funds for what needs to be done together with specifying what the business requirements actually are. Richard Volpato 2 Park Street, FITZROY NORTH, VIC 3068