[Zope] RE: [ZCommerce] RE: Philip leaves Arsdigita [snip]

Albert Langer Albert.Langer@Directory-Designs.org
Sat, 7 Apr 2001 11:51:12 +1000


[jimmie]
Walter, Albert, etc...

DC has committed no offense here. They've committed no fouls.

A few facts seem to be ignored in these pleas.

Ownership is really a poor term to describe truly open source software
such as Zope. Stewardship is a much better term.

DC has stated that:

1. Resources are limited.
    Read the list, there are many pleas for various
    things for which DC doesn't have the resources for.

2. They are willing to make accommodations for people who are
"contributing" to Zope and need something in core Zope to enable or
improve Zope for said feature.

3. They are concentrating on their core interest/skills which currently
is Content Management.

[albert]
Thanks for your comments. I recall your encouragement to take a look at
Zope in an OpenACS bboard nearly a year ago and am responding in detail.

I wasn't pleading but telling them about an opportunity, which Walter
confirmed by promptly waving money together with a detailed analysis
of requirements.

http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html

My understanding is that this is a common business model often used
for obtaining resources. Other models such as issuing IPOs are
becoming less and less plausible as time goes on.

In responding I'm also attempting to signoff from the direction that has
been taken in the thread I started so I can get back to the far more
interesting stuff in messages from Walter and other lurkers that
joined in, but seem to have been overlooked as a result of the absurd
preoccupation with rationalizing DC's position instead of dealing
with it's consequences. (I'm not referring to Chris's position, and
am assuming that is not what jimmie is defending). So this is an
attempt to summarize.

Re ownership/stewardship I'm using the term used by DC. My understanding
is that they are using it with a substantially similar meaning to
"stewardship". In this context it refers to someone being responsibile
for the ongoing maintenance and development of some software component.
(Not necessarily by doing it themselves but having both the authority
to take decisions about what must be done and the responsibility to
ensure that those decisions are taken and those things are done).

Whether rhetorically or not, the question Paul asked his customer
Walter is central:

"But concerning the remedy...is it *truly* the case that DC has to own
this effort?  After all, many of you know more about eCommerce than us.
We definately should participate, though."

My answer is "Yes" it is *truly* the case that DC has to own this effort
- taking it as obvious that DC knows very little about eCommerce at all
and that each of 1, 2 and 3 are also obvious truths which cannot usefully
be applied to resolve *any* specific issue. More on the specifics below.

"This effort" being integration of OpenACS4 with Zope with a view to
actually being able to meet requirements of the sort stated by Walter.

Specific customization in support of particular customers like Walter
can of course be done by anybody competent. He did mention that he
was heading off to arsDigita next week, after also mentioning that
they want at least $1 million up front for an approach that he
regards as inferior to a project led by DC based on Zope using ACS.
I don't think he'll have much trouble finding Zope contractors who
could do much better than arsDigita (together with arsDigita and
OpenACS developers), with that sort of budget.

I do think he'll get a less useful result, the spinoffs of which
will also be less useful to the Zope community
generally, if DC isn't involved in stewardship of the core
interfaces. It's clear he knows a lot more about ecommerce and
related issues than DC does and isn't particularly worried
about that.

People with any savvy don't bet their business on, and don't
put resources into, open source development based on APIs that
are not supported by a steward they can rely on to know how
it integrates. arsDigita wouldn't know how to integrate with
Zope, but DC should know how to integrate databases with
Zope since it already does that and even maintains an
Oracle adaptor for that reason.

The integration Walter's got in mind is specifically with the
Content Management System, which DC should know the most about,
though other contractors could also do it well. But if DC
doesn't take responsibility for core interfaces, Zope still
doesn't have an ecommerce capability, whatever Walter gets.

That is obviously not based on sycophantic admiration for DC
since I'm saying they are making a major blunder and have
copped a lot of shit for saying so. It's based on technical
judgment about what is needed for such an integration project
after having done some study of the issues.

Personally, I'm more interested in the opportunity to talk
about requirements with a domain expert like Walter that has
such an unusually thorough understanding of both the requirements
and some of the architectural issues than in either the
fate of DC or the fate of Walter's business. Most of the
requirements he stated happen to be useful for many other
things. I'll be proceeding to do so if he and the other interesting
lurkers that popped up are still around, even though I'm not
available as a contractor for this stuff.

I would have thought that DC would jump at the chance. Suspect
there is just some problem due to current upheavals with change
of CEO. Be that as it may I'm not impressed with the sycophancy.
It doesn't help either DC or Zope for people to offer rationalizations
for obviously dumb positions.

As for ignoring the 3 facts. I am responding to you with agreement that
these are indeed obvious truths because you are simply stating them as
facts that can be agreed on. I ignored them when stated by Paul and
focussed only on the specifics because I find it easier to separate
issues of merit and "attitude" that way. Repetition of obvious truths,
even when not accompanied by overt bristling, merely conveys an
attitude of not being interested in the specific issue being raised.

That of course is not an "offense" or "foul". However it does
inevitably result in people either concluding that there is no
point attempting to raise the specifics of an issue when it
simply won't be dealt with on it's merits, or else - if it happens
to be important enough not to just "get the message" and go away,
doing whatever else it takes to make them pay attention.

I have no problem with DC's general orientation. I just think they
are making a bad mistake on a specific issue against their own
interests and Zope's interests and I'm arguing the point.

[jimmie]
4. Their consulting projects have not entailed eCommerce.
     Which leads to their conclusion of priority of eCommerce for them.

[albert]
A similar point was made by Paul in relation to Postgresql. The
self-refutation included in the very same paragraph seems
sufficiently generic to answer your point:

"In fact, I don't believe we've had a single consulting customer that
deployed atop PostgreSQL.  You could certainly argue that, since we
don't do it, it naturally turned out that way."

[jimmie]
Paul never stated (from my memory) that eCommerce was an itch that he
had and would really like someone else to scratch it. The fact that DC
would like or appreciate an excellent eCommerce product for Zope doesn't
mean that they have any current needs of one.

[albert]
Here's the itch and (mildest version of) desire for someone else to
scratch it:

a) To me - while still "viewing this thread through the lens of hearing
"I've got a great idea for someone else to do.":

http://lists.codeit.com/pipermail/zcommerce/2001-April/000401.html
vvvvvvvvvvvv
> I would also guess that there would
> be at least *some* contracts that
> DC has *not* gained because the
> reason the customer wants the
> sort of things Zope does provide
> is closely connected with also
> wanting to charge for various
> goods and services that go with
> it and they decide they would
> prefer to deal with consultants
> that have a better track record
> on ecommerce.

Yes, you are correct.

> I'm just guessing of course. Only
> DC can determine whether these,
> and/or other matters might
> result in tangible monetary
> benefit to DC.

Yes, it would be a tangible monetary benefit.  One that might likely
offset the time invested.  Just like a long list of things that DC could
do.

But we're not a huge company.  We've done the Open Source route hoping
that folks like you, with a deep passion about a topic, will leverage
the work we're doing for free and add to it.
^^^^^^^^^^^^^

No problem with that mild version. Problem as explained previously
and below is that I don't believe it can be done without DC
ownership or stewardship of the relevant Zope APIs. That's the issue
that cannot rationally be discussed until someone at DC has
actually evaluated the ACS/OpenACS APIs and is in a position to
have an informed view as to what role DC should or should not
take in any effort to encourage people to put resources into
building on Zope in a way that (incidentally to the people contributing
their own efforts for their own reasons), scratches DC's itch for
"some" story on ecommerce.

Here's some stronger versions of the same "scratch my itch" theme
running through Paul's remarks to me so far:

vvvvvvvvvvvvv
> An entirely separate company has put major resources
> into an SQL data model that is freely available open source.
> That saves an awful lot of manpower, just as many
> companies using Zope have been saved a lot of manpower
> by the resources DC has put into it.

Agreed.  But conversely, if it was so simple, you could have done it in
the time it took you to type up these emails.
^^^^^^^^^^^^^^

vvvvvvvvvvvvv
> vvvvv
> > What more could a Zope guru want to persuade them to take a
> > look at the possibility of demonstrating how
> > much better that fits with Zope than with java or Tcl?
>
> Manpower.  ;-)
> ^^^^^
>
> Well manpower is one of the major benefits you could get
> from taking that look.

Perhaps.  Perhaps not.  Perhaps it could simply be DC doing all the
work.  Tell me, would *you* participate in the coding of the integration
if we took a look?  If so, are you interested in doing so *prior* to us
taking a look, and confirming that this is a great, easy idea?
^^^^^^^^^^^^

No Paul - I'm not interested in doing any coding of the integration
prior to you taking a look. In fact I'm not interested in doing
any coding at all, though I did spend a week working on UML
models of the OpenACS 3 and offered to spend another 2 weeks
and get them done nearly a year ago, with no response.

http://lists.codeit.com/pipermail/zcommerce/2000-July/000316.html

This time the modelling is a lot simpler for ACS4 - so I've just
provided links to the relevant design patterns. Their docs are
pretty good too.

For a totally bizarre version - "make it easier for me to
understand what to do about my itch", see below.

b) Responding to Walter as a DC customer known to Paul,
here again is the itch:

vvvvvvvvvvvvv
> It certainly seems to me that ACS is eating Zope's lunch in the market for
> "serious" eCommerce solutions - and now that the WorldBank is investing so

That's probably true.  eCommerce, as is obvious, hasn't been the place
we've chosen to compete.  But it's hard to be competitive in other areas
without some ecommerce story.

> much in the ACS through this "Gateway" project of theirs, with no
> corresponding investments in the Zope world, the trend can only worsen.
So
> it seems to this particular buyer in the market (small potatoes as i am)
> that incorporating ACS functionality into Zope, instead of just waiting
for
> someone to happen along and fund its development from scratch, is the

Understand, of course, that this applies to *lots* of things.  And
saying that DC has to eat it out of hide is OK, but there's a limit to
how much we can apply that strategy to.

> smarter way -- maybe even the only way -- to make it happen.  Without
> industrial-strength eCommerce and all that personalization stuff that goes
> along with it and is so important to everyone these days, i'm afraid that
> Digital Creations may be relegating Zope to the prospect of diminishing
> returns in a market that will just have to expand without significant
> Zope/DC participation.  If this is what you've been trying to tell Chris
> McD, then i'm afraid i have to agree.

You're certainly right that, if Zope wants to be competitive in
eCommerce, then it needs an eCommerce story.  The story is a bit murkier
for competing in other areas, but it's likely that Zope should have at
least *some* production-class story for eCommerce.
^^^^^^^^^^^^^
http://lists.codeit.com/pipermail/zcommerce/2001-April/000402.html

BTW I should mention here that the World Bank project is not
particularly about ecommerce but about a "Community" system
far more to do with "Content Management" - though of course
practically any such project is likely to want to be able
to take a credit card payment for buying a publication or
something like that without being told the only facility
available (Wampum) is "pre-alpha".

Also BTW, the Wampum docs mention that work on it was
sponsored by cash from DC, presumably because they know
that and knew that they would have to be the ones to
sponsor it if anyone was to come and build anything
that needs payment facilities.

My view is that they also have to finish it and do several
similar quite small things, before there will be much
more than prototypes available as a result of other
people's work, plus be the ringleader of a fishbowl
process similar to CMF if they want other people's
work to integrate with Zope, and CMF in particular,
enough to give them a "plausible story", as opposed
to just a "story" on ecommerce. If it's done right,
it could be a "brilliant story" because Zope is
ideal for the "Content Management" side developed
by DC that has a core competency in that - and
already has the necessary facilities to be able
to use SQL built by others with a core competency
in ecommerce and related SQL.

Walter, one of DC's customer's, has a clear
understanding of that but DC doesn't. They might
want to consult him as a source of expertize on
what could be useful to them in the market. I
certainly do (but I won't be offering to pay ;-)

[jimmie]
Anybody who uses Zope for website development receives monetary value
due to the fact they did not have to pay for Zope or any other web app
software. DC is a benefactor as such and not the beneficiary.

If DC were the sole beneficiary of Zope, there would be no community, no
one else contributing, no one else advocating, no one else desiring for
...

Anybody who has sufficient need of an eCommerce product and builds it
themselves in Zope is a beneficiary of building on the foundation of
Zope.

[albert]
Fine. Some people have already been doing that and I have no doubt
that work will end up scratching more than their own itch if DC
takes responsibility for what *it* needs to do. Until that happens
I do not believe this will result in anything that can be widely
deployed enough to make a real difference or to scratch the itch
that DC does have for an ecommerce story.

As evidence I cite the fact that it hasn't happened so far.
That ought to be sufficient for serious interest in discussing
what else might be needed.

[jimmie]
OpenACS is a testimony to the fact that "ownership" by the "creators of
the tool"TM is not necessary for success. OpenACS is a success in spite
of not due to arsDigita's stewardship.

[albert]
There are many highly successful free software projects and some open
source projects that are not dependent on stewardship by any particular
organization (though often a defacto stewardship by some individual
or small group within the wider developer community is critically
important - often known as the "core team" and in at least one case as the
"benevolent dictator for life"). Larger projects simply cannot do
without it due to obvious needs for architectural integrity and
stability in APIs.

OpenACS is a spectacularly bad example for your point. It has been
*completely* dependent on an ACS core developed essentially
in-house by arsDigita and simply released under GPL without any
significant "developer community" involvement at all. Up to now
OpenACS has simply been *porting* SQL to a different dialect and have
been severely hindered in that by lack of influence on decisions
by the stewards that could have made such porting easier. There
is nothing to port and therefore nothing for OpenACS to be
successful in porting other than the ACS itself developed by
arsDigita as stewards. Very little has been added, though much
more will be now that the main hurdles are being overcome.

Within OpenACS, porting of the "kernel" is entirely dependent on
work currently being done by a core team of 2 or 3. An impressive
team of developers for the rest of the ACS "core" is currently
lined up at the starting gate with the obvious technical necessity
of the core team deciding what has to be done undisputed.

Only after that, and based on it, will it be possible for others
to actually use and build on what the stewards are responsible for.
(I'm not sure how much has been added by users of OpenACS 3 in
using the core or how much has been added by the users of ACS 3,
but the core itself depends on the stewards).

Assuming that ACS really does want database independence, I would
hope the OpenACS porting work would be folded back in to ACS
(it has been designed to support *both* Oracle and Postgresql
and any others that people wish to do the porting for). There
would then be some complex issues about stewardship and avoiding a
damaging fork will depend on the wisdom of the stewards.

This whole area is murky at present as OpenACS is centered on
AOLserver/Tcl whereas ACS has abandoned that for a java platform
for the next major release, ACS 5.

One thing it highlights however is the essential independence of
the SQL for which arsDigita is undoubtedly the current steward, from
web application platforms that might use it (along with other things
they do), such as AOLserver/Tcl for which OpenACS is now the current
steward, and Zope for which DC could be the steward.

If Zope did integrate the OpenACS4 SQL and DC attempted to fork it,
that would be a flop. They are not its steward and do not have the
capability.

[jimmie]
There have been several consulting companies built up around ACS/OpenACS
without requiring blessing from arsDigita.

Rather than see DC go out and commit resources on eCommerce which
apparently does not currently impact any of their consulting gigs. I
would rather see them improve core Zope and continue on what they have
invested their knowledge and skills in.

[albert]
There may be several built up around Zope too. But neither they nor
the open source community built around Zope have more than a "voice"
in the clear stewardship of the Zope core by DC. DC is certainly
far more serious about putting actual resources into involving
a wider developer community than arsDigita. But it is quite clear
who is in charge of the core. Without somebody in charge of it
there would be no core to build on and that somebody is DC.

BTW while I agree with RDM's remarks "in theory". I don't agree
it is actually a correct response to Walter's earlier comment:

http://lists.codeit.com/pipermail/zcommerce/2001-April/000431.html

a) There is of course no question of DC prohibiting anyone
from developing anything based on Zope - and they have made
it clear they would be delighted if somebody else developed
ecommerce etc.

b) As stated in jimmie's fact 2, it is also clear that DC
would cooperate with any necessary changes to the Zope core.
(I'm not aware of any that would be needed for the sort of
things that Walter is looking for, but even if there turn
out to be, there's no reason whatever to expect anything
but cooperation).

c) It's true that if DC dropped Zope or tried to do
something bizarre there are enough skilled developers
around to be certain that it would continue being maintained
- which is a lot more reassuring for users of open source
software than for most commercial software - including stuff
from big companies.

But DC isn't just the biggest consulting firm using a product
that they happen to have developed as RDM seems to be suggesting.

They are also the main developers and anyone proposing a fork
would just be laughed at. (Which of course also doesn't prevent
anyone developing specialized variants or using bits of Zope like
ZODB independently).

Customers like Walter who want major enhancements added to Zope,
could certainly get them done elsewhere if necessary, but it
would take longer, cost more and be generally less satisfactory
than if project management was done by the people who know it
best. So he was being quite realistic in saying that if DC says
Zope isn't for ecommerce, there wouldn't be much point him arguing.

Once a toolkit is available people who want it specially customized
can certainly go to any consultants they like (though DC will still
have a "natural advantage" in being perceived as the most likely
to do a good job).

But Walter is looking for a system based on Zope plus ACS and is
already a customer of DC.

He wrote an extremely perceptive analysis showing a thorough
understanding of both his own needs and the strengths and weaknesses
of both ACS and Zope, explaining why he wanted a combination of both.

http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html

In that he also referred to thoughtful contributions that had been
made by others on the subject (no I'm not referring to the fact
that he was agreeing with me, though that is so unusual it may
perhaps color my view of him as a very perceptive person ;-)
- checkout that particular message and then look at his others
and those he referred to from the other lurkers that spoke up
at the same time.

The CMF is an "application" built on top of the Zope core, which
can itself work with other applications and applets. It didn't
happen just because DC needed it. They did need it and they put
significant resources into making sure it happened. Others no
doubt contributed to that and others will certainly build on it.

The issue is whether there is anything similar (even though much
smaller), in relation to ecommerce that DC would need to invest
their knowledge and skills in for others to also be able to do
so and whether DC should decide to do that.

That issue can only be resolved by DC and so far
they have not taken the necessary minimal steps in order to be
able to find out. A rational explanation for that would be if jimmie's
view that they have no such itch was correct. If they don't need
it and any benefit to them would obviously be far lower in priority
than other pressing concerns, there is no point even thinking about
it. Since that doesn't appear to be the case from Paul's explicit
statements, I would regard any such decision as irrational.

DC has to make it's own decisions about what it will commit to,
regardless of what either jimmie or I or anyone else may want.

But I would certainly agree that it would be a bad move for them
to get into developing (essential) SQL for industrial strength
ecommerce, personalization, workflow etc when:

a) They have no core competency in that area

b) An open source solution that they can just plug into
is freely available.

But that isn't what they are being asked to commit to.

Checkout the interaction with a DC customer right before our
eyes in this list and it's pretty obvious that DC does have
an itch. It's losing existing customers without taking into
account the obvious facts about what "Content Management" is
often used in connection with and the known facts about
customers who also have related ecommerce (and/or
"personalization" or "collaborative filtering")
needs and decide to go elsewhere because of that. Paul has
explicitly confirmed my "guess" that this would be the case.

Here's the example that happened right here, immediately
following above quote from Paul:

vvvvvvvvvvvvvv
> You're certainly right that, if Zope wants to be competitive in
> eCommerce, then it needs an eCommerce story.  The story is a bit murkier
> for competing in other areas, but it's likely that Zope should have at
> least *some* production-class story for eCommerce.
>
> For personalization, depends on you definition.  We might alread have
> some of it.


Whaddya got?  I've still got my ears on... |/|/


> But concerning the remedy...is it *truly* the case that DC has to own
> this effort?  After all, many of you know more about eCommerce than us.
> We definately should participate, though.
>
> --Paul

You certainly shouldn't be going it alone, Paul.  Without the interest of
both the developer community AND business people in search of solutions,
this effort would likely not succeed.  But, presuming for a moment that the
subscribers to this list could muster enough developers and business
solution-buyers to warrant it, might you be willing to dedicate project
management and technical expertise enough to do a proper opportunity
analysis?

IMO, unless DC is serious enough about this issue to make at least that sort
of commitment, this worthy project is probably a non-starter.
^^^^^^^^^^^^

http://lists.codeit.com/pipermail/zcommerce/2001-April/000408.html

It's as simple as that. Unless DC is serious enough about this issue
to at least be willing to do a proper opportunity analysis, it is
probably a non-starter.

[jimmie]
Someone with the need and skills for eCommerce should steward this
project. DC has already provided the forums and resources (ZWiki,
fishbowl, etc.) to permit someone to get this going. DC contrary to
arsDigita has been much better at stewarding it's community.

[albert]
>From what I've seen DC has not only been much better at encouraging
an open source community than arsDigita (which wouldn't be very
difficult), but also has an exemplary record in that respect.

So why hasn't anyone stepped forward to steward such a project?

Clearly it isn't the absence of forums, Zwiki and fishbowl. These
need not be provided by DC either.

There's also a Zcommerce mailing list and at least 3 individual
projects. Something must be missing or it would have happened.

I'd suggest what's been missing is DC *active* interest and
encouragement on that *specific* issue.

[jimmie]
I too would like to see eCommerce well supported. The website I am
currently working on will require such. When I get to that stage of
development, if one isn't available, I won't badger DC, I'll build what
I need. If it is good enough to contribute it back. I'll do so.

[albert]
Fine. That will make four. It still won't have happened. Whatever
is missing will still be missing.

[jimmie]
DC has been honest and forthright about this. They have given answers.
Don't badger them because the answers aren't what you wanted to hear.
They may be close to DC (Washington DC) but they aren't politicians. :)

If anyone here has unlimited resources (unlike DC), please contribute,
hire DC. I'm sure Paul (oops, just read the PR, maybe this should be
Brian) would be more happy to recruit more Pythoneers to work towards
building a better Zope.

[albert]
No problem with Paul's honesty or forthrightness. Problem is that
Paul has honestly and forthrightly confirmed he hasn't a clue as
to what needs to be done and honestly and forthrightly" demanded
that someone else solve *that* problem:

vvvvvvvvvv
My gosh, functions and triggers in Python?!!?  OK, Albert, score one for
you!  :^)  Thanks for bringing that on our radar.

I'd like to emphasize that Albert's idea has merit.  We'd like to learn
more about the idea, as we don't know as much as we should about it.
But someone needs to make it easier for us -- unfortunately, it's just
reality that we don't have as much time to investigate possibilities as
we would like.
^^^^^^^^^^

http://lists.codeit.com/pipermail/zcommerce/2001-April/000405.html

What the *fuck* am I or anyone else supposed to do, to make it
"easier" for DC to know as much as it should about an idea Paul
thinks might have merit, than spell it out as to where to send
someone to take a look?

Fred asked for tips so I repeated the original URLs for him.
They did get buried in the thread long before Fred could
have been expected to have seen them.

I'm not expecting a reply "please make it easier for me to
click on these links".

http://lists.codeit.com/pipermail/zcommerce/2001-April/000429.html

(BTW thanks to Michael Bernstein for rescuing the original
posting from the obscurity in which I jumbled it with
other matters that I am actually more interested in. He
is not to blame for the consequences ;-)

In case an "executive overview" is needed I also supplied (later) this.

vvvvvvvvv
A good starting point for understanding what ACS does along these lines
is Philip Greenspan's online book (also available as an elegant coffee
table edition for the suits, with the same stunningly beautiful and
irrelevant photos ;-)

http://www.arsdigita.com/books/panda/

Especially chapters 9 and 14. The whole book is also necessary reading
for a serious study of what ACS is (or was) about.
^^^^^^^^^^

http://lists.codeit.com/pipermail/zcommerce/2001-April/000413.html

If DC's investors need powerpoint slides to authorize a week's
time on checking out whether something like this might be
worthwhile, they should get some new investors.

Things are pretty grim for a lot of open source businesses
and are likely to get worse.
http://news.cnet.com/news/0-1003-200-5112816.html

But if DC hasn't got the resources to spend a week out of pocket
investigating whether it could meet Walter's requirements, it
probably has a legal obligation to file for insolvency. On a
any reasonable sort of contract that much work is usually done
out of pocket just in bidding for it.

I don't need Paul's "blessing" as to whether "Albert's idea
has merit". I'll close with the final words in his previous
response to me:

"I suggest you participate, rather than pontificate."

[jimmie]
No offense intended towards anyone here. I just wanted to state my
opinion on DC and on this matter. I have been a long time member of this
community, since it was a Bobo list, before Zope was open sourced.

Jimmie Houchin

[albert]
None given and none taken. Any vehemence is in summarizing as your
perfectly reasonable post provided an opportunity to do so.

I'm not a member of either Zope or OpenACS
communities but have been lurking for quite a while (since your
suggestion to do so in fact ;-)

If anyone wants to take offence, that's entirely up to them.
It would be more useful to respond to the arguments, and
even more useful to just respond to Walter's requirements.

I'm not planning to badger DC any further on this. Included
in the current links I provided for Fred are also links to
the stuff I posted nearly a year earlier:

http://lists.codeit.com/pipermail/zcommerce/2001-April/000429.html

I haven't bothered them since, until now, and I've said my piece now.
Not really interested in further discussion of DC. Am
interested in discussion of technical issues for ecommerce,
collaborative filtering, workflow etc, and on Walter's
requirements and the points raised by others that joined
in on that.

Now back to Walter's stuff, when I get some sleep.

http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html