Forum OpenACS Q&A: OpenACS as SourceForge

Collapse
Posted by Sunil Arvindam on
Can OpenACS be customized to provide the same functionality as
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.
Collapse
Posted by Ben Adida on
The answer to your question is "obviously yes, OpenACS can be
customized to do anything!" That said, it can't do it quite out of the
box. First of all, we don't have source code management
integration in v4 (and we only had very little stuff in v3 anyways).

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
SourceForge.

Collapse
Posted by Jun Yamog on
Hi Sunil,

Yes you can.  I have done something a bit like that.  Although to a
smaller extent.  It uses bboard, file-storage, ticket tracker lite
and acs-subsite.  Basically each project is a subsite and have 3
tools on their hand.  Since its a subsite each site can change their
templates.  Its a fast hack but it works.

If you want I could give you the code.  Although I may have to
remove client specific info here and there.  But if you think the
stuff that I have described will help then I am happy to share.  I
also left out other features on it and in some cases I need to go
into psql to correct the perms, groups, etc. each time I add a
project.  But there is no black magic on this so you can easily
create the correct admin pages in about a week.  Its a working
solution and the non admin pages are good and ok.  The admin pages
suck though since I did not have time and some parts still needed
psql stuff.  Its still based on beta1 code so you may have to
upgrade it.

Collapse
Posted by Neophytos Demetriou on
"The right platform for this is probably dotLRN, for scoping and creation of developer communities and such. "

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.

Collapse
Posted by Tapiwa Sibanda on
Neophytos,

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

  • 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.
  • 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.
  • 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.
You might well argue that one can do this with the standard toolkit using subsites, and portal... true. Why though duplicate the effort when you can use dotLRN to give you a boost?

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).

Collapse
Posted by Neophytos Demetriou on
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.

Collapse
Posted by Dave Bauer on
new-portal and forums are already in the development branch of OpenACS 4.

You can check this code out from CVS.

Collapse
Posted by Dave Bauer on
Oops. Also a new package bugtracker is in the openacs development branch.
Collapse
Posted by Neophytos Demetriou on
Thanks Dave, I last updated from the CVS head 4 hours ago and new-portal was not there.
Collapse
Posted by Neophytos Demetriou on
Dave, I just updated from the CVS HEAD and new-portal is not there. Is it under a different name? Actually, I was surprised by your post since I tend to update my CVS copy at least three times a day.
Collapse
Posted by Dave Bauer on
argh, I seem to have made a mistake. New-portal is not in the OpenACS CVS yet.
Collapse
Posted by Don Baccus on
The portals stuff will move back to the OpenACS tree after PG porting of various dotLRN pieces are finished.  It will certainly be included in OpenACS 4.6 (now that 4.5 is out 4.6 seems hardly as mythical as it might've seemed a few weeks ago).  Other pieces will move back in, to.

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.

Collapse
Posted by Neophytos Demetriou on
Don, thanks for the reply.

"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).

Collapse
Posted by David Kuczek on
now that 4.5 is out 4.6 seems hardly as mythical as it might've seemed a few weeks ago

Don, can you tell us a little bit more about 4.6 objectives?

- What are the major improvements/enhancements beside bug fixing?
- How does the not-so-mythical timeline look like (if it already exists)?
- How will the dotLRN integration into 4.6 proceed (if it has been planed already)?
Collapse
Posted by C. R. Oldham on
...and what are the compatibility objectives for 4.6?  Could I upgrade the core and would my packages keep working?
Collapse
Posted by Don Baccus on
  • Compatibility - yes, that's the goal
  • When - several of this talked about this in Amsterdam. There seemed to be consensus among that group (Collaboraid, myself, Peter Marklund, Bruno Mattarollo were all there I think) that bug fixes and integration of dotLRN components for both PG and Oracle were desired. If the dotLRN integration appears to take too long, we should hustle out a 4.6 bug fix release followed by a 4.7 dotLRN integration release. "September-ish" is the goal.
Collapse
Posted by Don Baccus on
The stuff in my previous note is up for discussion, of course, I'm just reporting what a group of us felt comfortable with in informal discussion over coffee about a week ago.