Tabiwa, sorry I tend to disagree with that point of view. You see, the C in the openaCs stands for Community. I did mention that there are features in dotlrn that could be back-ported to OpenACS. Now onto your points:
"fairly generic starter apps (calendar, file storage, news, forums tc) which most communities would find useful. It is therefore quite useable straight out of the box."
These generic starter apps are already available in OpenACS. AFAICS, dotlrn just adds wrapper procs (using service contracts) for portlets/applets which can be moved to OpenACS as soon as the portals package is.
"a framework to allow one to create portlets for apps to make them scoping/subsiting friendly. This is a good thing (tm). If everyone has their own mini-dotlrn-type-app running, then there is less sharing in the community as their code would be useless to anyone else."
The framework that you mention is the portals package and the portals package is a general package that should be part of the original toolkit as far as I'm concerned. Provided that the new-portal package is moved back to the toolkit you can make your apps scoping/subsiting friendly as well.
" ...
* an easy way of creating and deleteing multiple communities. This is really useful as it allows managers and not techies to manage the uber community. Try telling someone to create a subsite, and mount packages x, y, and z..... With all due respect, given a choice between Jun's hack and dotLRN, I would choose dotLRN anyday.
* a fairly simple way of administering individual communities. Again, this allows admin to be done by those in the trenches.
* personally though, the most important feature is the ability to easily aggregate content from communities and subcommunities into a single personal portal. You can imagine a software project with subprojects for UI, documentation, bug fixing, testing etc. dotLRN would allow you choose which subprojects, including the core you wanted to be involved in. So you suffer less from useless-information-overload, and can track your interest in that project from one page. Actuall, arguing this to the extreme, you can have a mySourceForgePage where you can keep track of all the communities you are interested in.
..."
Well, you see, IMHO these things that you mention have nothing to do with a learning management system. The fact that they were developed to enable the development of dotlrn (the learning management part) is a good thing of course and we are indebted to OpenForce for undertaking the task. [Furthermore, AFAIK, some of the tasks were already scheduled for OpenACS and OF kindly accepted to work on that track.]
Ending this note and after Tapiwa's response, my question(s) still remain. I would appreciate if someone (Don, Ben) could comment on this so that there's no confusion between the roles of OpenACS and dotLRN.
