I don't know. There are some major holes in this document. I read it as a very defensive positioning of .LRN, and not very effective at that. It also reads as a collection of notes pulled together in a haphazard manner.
IMO, it reads as a very poor technical position paper written by someone nontechnical. The arguments used were true at the time that ACS was done, but not very true now. For example, one of the articles referenced is from 2001!
I don't think it's terribly well organized. If the goal is to convince the client that OpenACS fits their needs, why not lead with the last paragraph and frame the discussion in that context? "These are the questions you need to consider and this is why .LRN is a good fit."
An argument /can't/ be won taking on PHP, Java, .NET and Apache head on.
For instance, "We use AOLServer instead of Apache because AOLServer performs better and is better supported for the large-scale production sites that .LRN typically runs."
It's totally false that Apache can't handle a site as large as .LRN installations are. People have built larger systems with Apache plenty of times. Bringing up Apache in this context sets up the whole gig for getting knocked down very easily.
Rather than obsess about what is popular, why not extol the virtues of the tools that we have?
A better approach would be "We love AOLserver because A, B and C. It compares favorably to Apache with regards to X, Y and Z."
Maybe it's just late and I'm being cranky, but I really don't think this is a very effective piece of literature. There is a good bit of information in this document that can be formed into a properly convincing paper, though.
talli
