Yes.

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

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

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.

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.

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

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 www.sussdorff.org. 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.

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

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.

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?

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 openacs.org server (i.e. set up /cvsroot/ACES or /cvsroot/ACS) once someone decides they'll do everything else that's necessary.

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?

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

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.

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.

- Richard Buck