Forum OpenACS Q&A: Planning a migration from ACS 3.4.x to OpenACS?

My understanding is that there is no migration path from ACS 3.4.x to
anywhere, and that any such effort would be extremely painful and
time-consuming. I'll still rather pissed that aD never offered a
migration path.

I'm curious what all the ACS 3 sites are doing development-wise. There
hasn't been a code repository for ACS 3 for over a year, and when I
inquired around about it, nobody seemed particularly interested in it.

It does seem like there were a lot of sites built on ACS 3.4, though,
and I imagine at least some of them must be under development.

So, my questions are:

1) If your site is built on ACS 3, do you ever have a plan to migrate
it to OpenACS?

2) If there are enough people thinking about this, wouldn't it make
sense to band together and create a migration guide / set of porting
tools to migrate as much of this data as possible to the new data
models? Perhaps we could share the pain and get it done more quickly.

3) If you plan to stick with your current platform of ACS 3, would you
be interested in helping out with maintaining a repository? Ybos has
volunteered to host it, but I don't think they have enough time to
maintain it. I'd be happy to help out, but I'm not sure how many other
folks out there are in the same situation as me. I'm already
maintaining a code repository for my own use. ;)

4) If I did go through all the pain of porting everything to OpenACS,
would I be rewarded with a platform that's going to have a migration
future? I'm not interested in another dead end... Is OpenACS 4 going
to be able to be ported to OpenACS 5?

5) I have a lot to contribute to OpenACS if there was a way to get
there from here. I've refined the Intranet portion of the ACS 3.4 code
full-time for over a year now, and developed the interface quite a
bit. I would love to bring these changes into the public domain so
other people could use it.

1) If your site is built on ACS 3, do you ever have a plan to migrate it to OpenACS?


2) wouldn't it make sense to band together and create a migration guide / set of porting tools

This sounds like a good idea. In particular, simple instructions about how to migrate/create group memberships and user bases to OACS4 would be most appreciated

No. Yes. Yes. Dunno.

Jade, please don't let the lack of repository stop you from sharing your work.  I would love to try your new intranet module.

Until the new website and a repository comes out, would you consider creating a classic acs 3 repository in at

Posted by Don Baccus on
I have no problem opening up space on the site for an ACS 3.4 repository.  At one point Ybos said they wanted to do it, I thought it might be more appropriate to have it here, and we never resolved it.  Since I personally am not working with it I have no *personal* interest in spending time on it, and haven't.

But that doesn't mean I have no *community* interest in spending a *small* amount of time on it.  Particularly since the community seems somewhat nervous about the possibility that the existing code at aD might become inaccessible in the future (i.e. the "preparing for aD's death" thread).  I was less motivated a few months ago when the issue was raised because, after all, if it were important to aD's user community one could argue that aD should step up to the plate and open up a CVS tree.  But it is clear now that this will never happen.

Does someone want to step up and offer to put together a tarball of the real, non-ACES 3.4? (Malte is hosting their improved ACES, which is based on 3.4).  Who should have commit access to a 3.4 tree if we build one?  I think we need someone in the community to step forward and take on the roll of caretaker and gatekeeper for the repository.  There needs to be some process for deciding whether or not, for instance, to put Jade's intranet changes into the tree or not.

This is where I duck out.  It's work enough having that role for OpenACS 4.x and Roberto probably feels the same as he has that role for OpenACS 3.2.x.  So someone from the ACS 3.4 user community needs to step forward if we're going to make this work.

Migration tools would be great.  A 3.4. repository should be "temporary"  in that "eventually" folks should migrate their improvements/packages to the 4.x framework.  (I use quotes because I realize that to some degree this is a fantasy, life's too short, but we should have this as a goal).

I'd prefer that someone more experienced than I in the ACS 3.4 core take this on, but if no one else steps up to take on this job, I will do it.

What this would mean, however, is that I would be biased towards all the changes I've made in the last year to the ACS :)

Maybe Malte can step in here but why do we need a separate ACES/ACS3.4 tarballs?  ACES doesn't take anything out, it just unpacks everything so you have a portals based workspace.  Even the old workspaces is still there and so is the old admin pages.

Its just like everything else in the ACS..if you don't need the education set-up then just don't use those pages.

BTW I've been working a bit with the 3.4 intranet pages and would be interested in anyone else's work.  I'd also be especially interested if anyone has done something interesting with address book and hooking it up better to intranet or using it for spamming.

If anyone is interested Scott and I put together a "Link Library" based on general-links "Goal Tracker" based on ticket tracker.

Posted by Don Baccus on
Well ... the fact that the ACES tarball from aD doesn't entirely  install due to errors makes me rather hesitant to host it here.  Out standards aren't the highest in the world, but they're higher than this.

Hopefully Malte's fixed those problems?

Also I don't think it's exactly true that you can just choose not to load the education stuff and then have a vanilla ACS 3.4.  It's been a couple of months since I worked on the code base for Sloan, but IIRC there were some hacks to things like registration that changes stuff.

A cleaned-up ACES code base would be fine with me (and, again, maybe Malte et al have done the necessary work) but the tarball as it exists  at aD has problems.

Okay, sorry for stepping in a little bit late on that issue. Nonetheless:
  1. We run on ACES. One strong reason we picked it was my conviction that MIT wants to migraate their current data into .LRN which will be OpenACS based. Which leads to
  2. yes, and we should work together with OpenForce, if they want to.
  3. We will keep an ACES 3.x version running and integration all the code we get from people. The current problem is time on our side. The way I see it, we have an improved ACES version from Sloan. Add to this bugfixes made on our ACES installation. Plug in Jade's intranet and Carolines other improvements. Should make a decent package. There are problems though, which I'll come too.
  4. In my opinion OpenACS is the way to go in the long run. At the current moment the only reason for sticking with 3.4.x is that it is running in so many different places realiably, why change. Just make sure you can migrate your data. And if I'm not mistaken, not only Sloan is migrating data to OpenACS but some other company starting with an A is working on it too.
  5. Hand over your intranet module. I'm more than happy to integrate it with the ACES package to ship it around.
Okay, now for the problems:
  • Our ACES version is geared towards performance. Permission model sucks big donkey balls, Subgroups work more or less. We run at 40.000 users with 6000 groups and an average participation of 10 groups per person. So we were forced to get rid of everything which looked remotly like "sophisticated" permissioning and group system. Bringing this back into the main trunck is a little bit more work down the road.
  • ACES Sloan does not install out of the box.
  • Who is to decide, what package version will stay in the distribution. IMHO I'd use improved ACES/Sloan as a basis, drop the old bboard (though we still use it), take the munich file storage (we have it), add general alerts and survey, take the new intranet and integrate Carolines source codes. But why should this be the wisest thing to do 😉.
  • Who is going to test this, where is it going to run live with users. My idea is to setup ACES for german universities to test it out. Like an ASP approach. But see my problem. ACES does not support multilinguality (well, with out patch yes, but who is going to wrap TRN tags around every english paragraph in the ACES). A fork (again) for a german version (oh, I forgot, I have a germanised version made by my students, this is I guess the 5th version of ACS 3.4.x we talk about)
So, where does this leave us? well, my current motivation goes into the direction of hiring an ACS developer in India, have him integrate all the ACES code into one package running out of the box and deliver it as a christmas gift to the community.

Still, I would love to see this stay an open process. So what I will do is upload the latest CVS checkout from the AIESEC.NET source as well as the ACES / Sloan package to Download it from there and play around with it. I can even start to host the CVS repository if you want. This would first consist of the ACES / Sloan package and further additions could be checked in by the various parties interested.

Malte, if there was some way we could work together on this, I'd love to.

However, I wonder if our goals are mutually exclusive. My company needs very strict permissions on everything and performance is a secondary concern. Your situation is the opposite. I'm not sure if it's going to be possible for the Intranet package to work on ACES.

However, I am interested in a migration path, and if there was any way we could resolve these differences, I'd be interested in it.

Jerry, I can tarball everything up and upload it, but I'd rather wait until I see what happens with this thread. If we can have a real system in place for tracking bugfixes and a repository, I can save myself a lot of duplicate effort.

Malte, same thing for integrating it with ACES. I'm happy to, but let's see how this plays out first.

Hello Jade,

our client wants to move to a more sophisticated permissioning sooner or later and if we start with the ASP approach for universities it is definitly a must, so our interest are not opposite, though my focus is at the current stage probably more on performance 😊.

Furthermore, I could setup SDM on the demo system we will come up with (and there needs to be a demo system, taking the request I already got in germany). And the CVS repository. Just bear with me after 1st of November as I'm pretty busy til then at least.

Always take in account that ACES is all about permissions, so integrating the Intranet Module with the ACES is a good idea. Though a different focus. Because the intranet module is just another portal to the functionalities of the ACS. Integration would be really nice if we could have the intranet homepage run as a portal. That would rock, so to speak. But thats even more dev-work.....

Okay, gotta head of for a few hours of sleeping beauty

If Malte and his groups are going to play a (or "the"?) significant coordination role, it would make sense for them to host the tree(s) (and he's going to do that in the short term, at least, anyway).

So while hosting it on the server is certainly possible, letting Malte do the hosting might make more sense.  We could alway link to his server - "looking for the Good Old Days?  You can find them over here!".

The permissions model's is going to be an issue in OpenACS 4, too ... not that I want this thread to diverge but I keep worrying about its scalability ...

On another thought. Why not use sourceforge for this [just a quick reminder. Throwing stones at people is a serious crime. And I doubt they would reach me in Germany for this blasphemie 😊] ?

I really wish I'd had your code a month ago when I started to hack in pieces of the intranet module into teamhydroski.  I may be back on that project shortly...or never...but I'd love to know what sort of functionality your module has.

Is it a package?  Can it be released as an "at your own risk alpah" package so if someone else is trying to create an intranet they have a starting point?

How hard would it be to integrate it into pre-ACES 3.4?

When I started using the customers code from intranet on my ACES installation I simply created a link to intranet/customers...fixed a few bugs so the pages ran...renamed some of the fields...and we were off.  For my little bitty company it was not necessary to actually create a portlet or anything fancy.  I fix the UI a bit every week.
I wonder if I would have had a better UI faster if I had had your code..even if I would have had to go fix a few things to make it compatable with my 3.4 version.


This is what I've found frustrating about not having a common code-base the last year. We could have been collaborating on this and benefited both of our companies (and made ourselves look better as employees as well).

Here are some of the changes I made to the Intranet:

  • A lot of interface fixes and improvements (this is mostly what the improvements are). I had to make it usable for a company of very computer illiterate folks, so I cleaned it up quite a bit.
  • Some bug fixes of course, and a few performance tweaks.
  • We wanted a way of keeping track of to-do items, so I adapted to ticket system to do this. Its interface is a little better, although one of the best changes is a hack that I know won't be portable. (it was early on when I was still learning the ropes)
  • We made projects so they can be hierarchical. I also added a lot of hour reports, so you can break down hours in all sorts of ways.
  • I added "ticket templates", so if you typically do something and need three other people to do something related to it, you can do it all at once, and then you have a master ticket which shows you the status for all the subtickets (the subtickets are what you assigned to everyone).
  • I added in the conference room package (that was developed at aD) and cleaned it up a little more.
  • The rest of the changes are separate packages that are proprietary for the company I work at.
I don't know anything about ACES, so I don't really know how hard it would be to set up. I haven't used SourceForge much, so I don't know whether to throw stones or not. Is it that bad? I would prefer the SDM and so on, but I'm openminded.
Perhaps we could share the pain and get it done more quickly.
Many months ago a few of us upgraded a production client from an acs3.2 base to acs4.0. At the time I asked Mike Bonnet to write up a summary of the work (which he did most of). For what it's worth, you can read about it at I haven't looked over much OpenACS code lately, but I suspect the bits about migrating users and groups will be relevant. There was also some weird incompatibility with ns_adp_parse/ns_adp_include and the templating system that we never figured out (perhaps you have?). Anyway, hope this helps.
Andrew, that is excellent. It is a kind of road-map to a conversion from ACS 3.x to 4.x

What I'd ultimately like to see is a step by step guide, similar to the original install guide, which shows exactly which steps to take in order to make the switch to OpenACS 4 or Classic ACS 4. Perhaps we can use an iterative approach -- the next person to do a conversion can use your guide, and improve upon it, and the next person can improve upon that, etc...

It would be nice to have a forum for discussing these issue, but perhaps we can use this thread for now?

What needs to be done:

1) set up a code repository (nobody responded to my query about sourceforge... is that a viable option?)

Crucial issues (for me): are ACES and ACS compatible enough that my Intranet code isn't going to need a lot of work to get running on ACES? Is the functionality required by the Intranet going to break what you need, Malte?

Once we've resolved the issues, who is going to set this up? Malte, were you interested in doing this?

2) set up a forum for discussing ACS 3.4.x development.

Aside: Can we agree to call the new version ACS 3.5?

Who is going to set this up?

3) What else?

Your intranet stuff should work OK in ACES, community-core and the like are the same as 3.4.

As for who is going to set it up, etc, I'd still prefer to do it here, I think.  We want this place to be "ACS Tcl central" if possible, don't we?  The more I think about it the more I think that's right.

I can spend some time setting up the basics on the server (i.e. set up /cvsroot/ACES or /cvsroot/ACS) once someone decides they'll do everything else that's necessary.

I'm willing to do whatever I can do to help out. I agree that having the ACS 3.4 here would make sense.

I'll have to do some work filtering through all my bug fixes and changes and check in all the changes that aren't proprietary. I'm more than willing to do this. I think you'll all be happy with the improvements to the Intranet portion in particular.

Don, I don't really care whether we go with ACES or ACS, so unless anybody else has any objections, let's go with ACES. Can we call it ACS 3.5, though? I think it's far less confusing.

I'm willing to be the person who manages the forum for ACS 3.5. I can help with the repository, too, although I'm not sure if I should be the person solely responsible for it.

I'm all for calling it ACS 3.5 It was a political decision to release it as ACES. At the time ArsDigita had made a policy decision not to do anymore work on 3x.  We got around it by making it the "eduction" release.
I do think it should unpack to a nice usefull portal rather then "your workspace", though proably not an education specific one.  The portal layout with portlets for many of the modules gives people a much more accurate first impression of what ACS can do.
21: Renaming ACES to ACS 3.5? (response to 1)
Posted by Walter McGinnis on
Uh.  I don't to mean to be a party pooper, but can you rename
ACES to ACS 3.5?  Doesn't the copyright holder for ACS have to
agree to this kind of name change?

On a side note, making a very specific configuration of ACS be
the name holder rubs me the wrong way.  ACS 3.4 can do a lot
that is not readily apparent in the ACES version.  I think you
actually create confusion by doing this sort of renaming.  The
lineage becomes fuzzy.

I guess people can always grab ACS 3.4 or OpenACS 3.x if they
want to have finer grain control of the configuration of their site...

22: ACS vs ACES (response to 1)
Posted by Jade Rubick on
I personally would rather have the code be based on ACS 3.4.10 rather than ACES. However, I also like the idea of having Malte et al involved in this.

We could always assign it a new name, like ClosedACS 3.5 :)

Or Classic ACS 3.5  If we make the official name a little different, will the copyright matter?

How many ACS developers are out there? How many ACES developers are out there? And how many want to play ball with us?

IMHO ACS 3.5 would be logical name for the stuff, if ACES would not come preconfigured with support for departments, handouts, assignments and the like. As for who is going to take care of it, if Don sets up CVS I will be more than happy to fill it. I dont think we should have a seperate repository for ACS and ACES. If someone does not want the education stuff, it is pretty easy to get rid of it again 😉.

Plan on our side still is to integrate whatever we can and release the stuff based on the ACES tarball I got from Sloan as the new stable release for ACS 3.x before christmas. Up til then I'd suggest populating the CVS with the ACES Sloan tarball and add whatever else we have (Intranet, Survey, you name it).

What do you think ?

P.S.: Concerning legal issues, well, what the heck. AD has abandoned ACS, Sloan probably would not mind to call it whatever we choose to name it. And as we repackage a whole lot of stuff together into a new release I doubt anyone would come after us.

24: Call for vote (response to 1)
Posted by Jade Rubick on
Could we set up a poll for this (so that we can vote on it)

Would you like the ACS 3.5 code to be based off of ACS 3.4.10 or ACES?

Proposed options:

1. I would like ACS 3.5 to be based off of ACS 3.4.10 and I would not participate in development if ACES code were used

2. I would like ACS 3.5 to be based off of ACS 3.4.10 but I would participate in development if ACES code were used

3. I would like ACS 3.5 to be based off of ACES and I would not participate in development if ACS 3.4.10 code were used

4. I would like ACS 3.5 to be based off of ACES but I would participate in development if ACS 3.4.10 code were used

5. I don't care one way or the other, I would still participate in development

6. Other

Posted by Caroline Meeks on
Sorry, I think you are confused about what “ACES” is.  To my mind ACES has two things it can potentially contribute to “ACS 3.5”

1. The code released under ACES contains the following new or improved modules in the form of packages:

Threaded bboard
File storage
News (also released separately)
Calendar (also released separately)

We can debate the modules one by one but I think most people will agree that it is valuable code and should be included in any new version 3 release.  There is probably some work to be done to test that it can run without “education” installed but that was the intention when the work was done.

2. In my opinion, ACES can also contribute the concept of having ACS unpack into a portals based view that immediately shows people windows into the functionality of ACS.  However, I think this might be worth having a poll on.

I don’t think anyone thinks that the next release should unpack into anything that says anything about “classes or terms”. I certainly don’t.

It should be a fairly small amount of work to turn “education” into yet another module that sits there until needed.

We do have some issues to work out between the various forks concerning permissions.  I think the ACES team, Jade, and Malte have all come up with different solutions.  Maybe we can have different permissions options turn off and on by parameters.

Posted by Ben Adida on
Good to see thought put into a very hard problem: migration. One quick question before I set up this poll: are there plans for significant further development? That's certainly anyone's right, but it seems like this time would be *much* better spent on a migration document to v4.x, and then on new packages for 4.x. Thoughts?
Ben, we (as in S&R) will definitly continue to do a little bit of custom work once the ACS 3.5 is out. Other than that, migration to OpenACS is definitly a strong issue, but as long as we have performance issues, there is not much sense for us to think about migrating {though this is where we want to go). I mean, this is why we started this thread in the first place 😉.
Ben, ultimately I'd like to be a part of the OpenACS 4 team, because it seems to just make sense to be part of a community of people developing a platform.

Unfortunately, getting there from here is still a little hard. I think that the fact that OpenACS supports Oracle is going to make the migration a lot easier (I don't have to port everything to both Postgres and OpenACS 4 at the same time).

I think once we get organized as a community, we should start developing a road map for getting all of us who want to get onto OpenACS 4. This will, of course, be beneficial for both the people already on OpenACS 4 and all of us stuck on ACS 3.4.  We have a rough outline of a migration plan already (thank you, Andrew), and it looks like all of us could improve upon it and get ourselves all moved up to OpenACS 4. I think in the process we'll have to improve a lot of the modules available for OpenACS 4. For example, I will spend a lot of time getting the Intranet up to speed.

Ben, are we going to be able to prevent this migration gap from happening in the future? Is OpenACS 5 going to be totally incompatible with OpenACS 4? Are we even planning an OpenACS 5 at this point, with aD effectively out of the picture? Should I be starting a new thread for this?

It looks like the poll might not be necessary. Apparently, I misunderstood how different ACES was. If you all think it shouldn't break anything, let's start with that in the repository, and let's try to get a working ACS 3.5 going.

On the legal front, I'm trying to contact aD's lawyer to get an official blessing for us to use the name ACS 3.4. Otherwise, I propose we name is something else... Arsdigita Community System is okay, but we could probably do better. But I also don't want to distance the name from OpenACS, so we might just call it Classic ACS 3.5 or something similar.

About the performance issues with OpenACS 4. Is this something that is intrinsic to OpenACS 4, or could it be improved upon? Since we don't have to worry as much about tracking ACS 4, perhaps this code could be rewritten?

I don't actually care, because performance isn't much of an issue for me.


I'm sure Ben would tell you this, but he (and the rest of the team and community) are pretty adamant about upgrade paths. We have made them for the 3.x series, we'll continue to do so for the 4.x series and on.

There's no OpenACS 5 formally planned yet, but with the experience we're gaining in OACS4, we sure are starting to form the ideas of what needs to be done for. But right now, all our focus is on getting 4 out the door.

Posted by Jade Rubick on
Okay, so let's go with ACES and call it ACS 3.5

I'm getting permission from aD's lawyer to use the term ACS. If that doesn't pan out, we can change the name.

How does this sound as a plan of attack

  • Anyone willing to help out with maintaining the repository volunteer here. Say how much you're willing to help, what modules you're familiar with, etc.. I'll help, and I'm mostly interested in the Intranet module, and with migration. We may need a critical mass here if this is going to happen.
  • Don has volunteered to set up the infrastructure on OpenACS. Who can provide him with a clean, working version of ACES he can upload?
  • We're going to need a place to organize who does what, etc... Anyone have any experience with this? I don't have any experience managing an open-source project, but I'm willing to do what I can. Perhaps we can have our own forum set up here on
  • Once we have a repository set up, let's work together to start merging in our code improvements in a coherent way. We'll need to make sure we have clean upgrade scripts for anything that affects the database, etc...
Anything I'm missing?
You're okay to call it ACS 3.5, Jade.  Thanks for asking.

- Richard Buck

Have a look at this thread for further info about ACS 3.5