SOurceForge? That is, can it be used to support a large number of
open-source development projects? Key requirements will be to manage
source code files, especially through CVS.
The right platform for this is probably dotLRN, for scoping and
creation of developer communities and such. But you'll need to
develop reasonably large chunks of new functionality to match
Ben, could you please elaborate on this one. I don't see why dotLRN is the right platform and not OpenACS per se. The way I see it, is that dotLRN is a learning management system. Admitedly, it has features that could go back to the toolkit (OpenACS) but if we start moving everything that needs community scoping to dotLRN then there would be no OpenACS -- just dotLRN.
Though not wanting to get into a dotLRN vs OACS (vanilla) war, I would still tend to agree with Ben.
More important than just scoping, is the need to manage knowledge. What I think openACS gives you (from a tech perspective) is a platform (via subsites etc) on which to build systems like dotLRN. Most people using openACS would be using it to build web services, and would be 'borrowing' authentication, versioning, subsiting etc from the core.
dotLRN takes it to another level. While a lot of sites will not use subsiting, and might be a community site for one homogenous group, others do, heavily. dotLRN seems to give someone developing (for lack of a better expression) and asp for communities a leg up.
Some of the more interesting and appealing features in dotLRN (for me at least, include
The only thing I would add to dotLRN is the ability to categorise content, and so allow aggregation not only by community/project, but also along knowledge themes. eg, I am interested in all entertainment events, across all communities (this implicitly requires the system to allow tagging of an event as an entertainment event, or a news item being one on entertainment).
"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.
You can check this code out from CVS.
As far as the community management stuff implemented in dotLRN we'll have to take a look to see whether or not this can be generalized in a way that's useful for the toolkit at large. My reading of Ben's comment is that this portion of the dotLRN code would serve as a better starting point than the code that exists in OpenACS 4 today.
Certainly today's hardwired classes and clubs don't match the software project paradigm (and there is hardwiring in parts of the code) so it's not off-the-shelf a perfect fit for a sourceforge-ish project.
As to what goes back in the toolkit and what stays in the dotLRN tree ... the community will largely determine that.
I'm not in the least bit worried that vertical apps like dotLRN will fork the community or weaken OpenACS per se. Just the opposite will happen, IMO.
"I'm not in the least bit worried that vertical apps like dotLRN will fork the community or weaken OpenACS per se. Just the opposite will happen, IMO. "
I'm not worried either provided that we don't start moving any package that needs community scoping into dotlrn (note the *if* in my initial reply).