How did this report come about? Well, some of my OACS sites were actually ACS sites and have been upgraded since 1999, before OACS was even a reality. I therefore have not just history, but a vested interest in OACS.
Users have always complained, but generally it was ignored. The systems worked, so don't rock the boat. Now, though, things have changed. If your system looks like crap, is still stuck in the year 2000 for technology, or is just plain hard to use, end users will not use your system. Most likely, they will talk to their friends and request the system be changed to use more friendly alternatives like using mash-ups.
As much as I hate PHP and MySQL, they have the killer apps. Wordpress is one of them, so are the several forum apps. Lay people see these apps and want them. They are not interested in the geek speak about the benefits of embedded TCL and database support. They want a solution now, sadly OACS doesn't provide one.
Even in its role as a toolkit, it fails in many regards. To quote Jim Davidson (one of the architects of AOLserver) in a recent forum posting to the AOLserver list (slightly edited):
Anyway, I've spent some time with LAMP recently -- quite clever all that PHP/MySql stuff.
To compare, AOLserver:
-- Still has a scalable architecture and good underlying code quality
-- Is tightly woven with Tcl which appears less and less popular each year (I could be wrong)
-- Is lacking many extensions or has cruddy alternatives (e.g., ns_http instead of curl)
-- Has horrible, incomplete, and often misleading documentation
-- Isn't so easy to install and configure
-- Has great documentation with threaded discussions
-- Relies on PHP which, fair or unfair, appears quite popular
-- Has possibly too many overlapping extensions
-- Is hard to install and configure unless you're using that xampp stuff
The infrastructure is old and showing its weaknesses. Whatever technical head start AOLserver had is not very important anymore. People are not looking for community sites anymore, but rather ways to facilitate social networking.
Many of the offline conversations I have with other OACS users and ex-users revolve around the fact that OACS is now a third class citizen, with almost all development going to dotLRN. To make matters worse the toolkit is so far behind technologically many have started using other alternatives.
I also understand many of the people actively writing code work for companies who work almost exclusively with dotLRN. That is fine, but when dotLRN dependent code gets into OACS, it becomes a community problem.
What can be done?
- I already have written on xowiki (see http://jongriffin.com/articles/oacs-needs).
- More of the core needs to be re-factored using xoTcl.
- A logical theming/templating system needs to be created. Most LAMP applications use smarty templates. OACS has a better template system that could maybe be created as a separate from OACS stand alone module.
- The css is a mess, too many independent files that if you change, get written over with upgrades. LAMP uses a /templates directory, OACS should follow this. No packages should have css or resources in them.
- Templates should be editable from the browser, this includes css. There should be no need for shell access for a designer to change something.
- Split out any modules that don’t require database access into standard AOLserver modules.This will allow other developers to use the codebase of OACS without the overhead of the entire toolkit (i.e. I only want a blog)
- Think about moving to naviserver. This project adds many extensions that could be useful for OACS.
The above is just some of what needs to be done. Am I volunteering, well no. I don’t really have time.
I am mentioning this as someone who likes and uses OACS, so don't take it the wrong way. Most people just try it and dump it and never say anything. Also, ex-users just see the whole aolserver/tcl problem not worth fighting.