Interesting conversation.
Allow me to add my own comment.
I am the CIO at a medium sized company in Canada, 400 to 600 employees. We are definately in the minor league here with respect some of the institutions using OACS and .LRN
Currently we run Lotus Notes as our groupware solution but we are evaluating ditching that beast. Basically Notes/Domino is really a wonderfull idea, run by a top heavy, closed organization, hugely expensive, and a system that once you get heavily invested you are tied to it.
Luckily we are not heavily invested in it, so we have choices.
We have looked at everything under the sun here in terms of an 'Enterprise Class Application Server' and various technologies.
I understand where you guys are coming from, but you really are missing the boat in your discussions here. Some thoughts from a non educational organizations perspective:
- Anything on .NET is a no go for us. MS has shown it self to be a proven and consistently immoral and untrustworthy company, and we won't be part of anything from withing their sphere of influence. Anyone that deploys anything on .NET is putting on their own shackles of slavery - MONO alternatively is not production ready.
- Java based solutions ... too many options to discuss, however I don't see anything from that toolset that really does what OACS does.
- LAMP ... this is fine for task specific stuff. If you want CMS, Mambo Server or Typo3 are amazing, if you want project management you have tons of options, if you want frameworks the options are amazing. For Python alone there are something like 8 frameworks available and Python isn't even used as a web language per se!!!
I love the LAMP stuff, but the community seems large and active only because there are a ton of tiny and a few big projects that completely reinvent everything every time. If you are going to start anyting on LAMP, at worst you will rewrite an OACS type of framework your self, or at best use someone elses that is either too small to have any mind share, too young to have been tested, or if its something that is successfull like Typo3 or Mambo server, well they reinvented their own frameworks and I dare anyone to merge anything from those two projects into the other. For that matter, I dare any one to get any two separate LAMP project to work together.
For us, I could deploy a few LAMP applications, but in the end, we will be maintaining each one separately, patching each one separately, coding each one separately and administering each one separately. They won't talk to each other, they won't have the same permission system ... etc.
LAMP is a no go for anything other than quick and dirty, but to be fair OACS has the quick and dirty down better than anything in LAMP.
- Standalone frameworks/apps like GNUE.org. Okay I personally love this project, I think they have the right idea and I think they have some potential for delivering strong solutions. The project is old and is fairly stable, yet at the same time it's still is lacking in certain features that people look for in things like that. Many other apps/frameworks in this category are in similar positions. This is a wait and see category still before I make up my mind about it.
- OACS ... I think everyone needs to go and read up on some of the history of AOL server again, and why its such a terrific base to have a framework on.
AOL Server - probably the most powerfull and scalable web server available out there ( maybe outpowered by Zeus ).
TCL - if you can dig into python, you should be able to understand TCL. Learning TCL is a non issue, from what I can see it's very simple, if you can learn Ruby or Python you can dig TCL.
OACS - one single integrated framework, on one single language ( I know there is a Python binding out there, but there really is no need for it TCL seems fine. Perhaps some expert programmers can fill me in on TCL'S shortcommings but so far I haven't been able to google anything more than WAAAH, NO ONE USES IT, I'M NOT L33T) on one of the worlds fastest and most scalable webservers.
All tested, all production proven, a single permissions system, all applications are a subset of OACS and are organized and function similarly ... WOW!
Do you guys even realize what you have here? Holy shit!
I'm just a PHB, and it took a bit, installing the .LRN package in debian is one command, got it up and running, figured out that .LRN is just a SINGLE APPLICATION built on OACS, uninstalled .LRN from the framework, installed a good number of applications my self via web gui, and setup permissions and a few sub sites all with little or no help from IRC.
I created a NEW APPLICATION with the click of a button, following the introductory application tutorial, and restarting the DOTLRN service in Debian and VOILA! I have my own application ( okay it's just the tutorial example files but they work ) running.
Hello? This is amazing!
Look, what this project lacks is sex appeal. Here are some things that might help and probably have been mentioned already:
- sex appeal. Look https://www.sitepoint.com/mambo-server-cms/ - it's lickable and the OACS site needs the same treatment.
- the .LRN debian package and the .LRN instance needs to stopo presenting it self as a separate instance of OACS because it is not. It should only be, and is, an application available from the OACS repository. Nothing more, nothing less, just a beautiful, well thought out nicely programmed.
- LORS needs some debugging and integration into .LRN. Once you add the ability to deliver SCORM class content via .LRN you have a Moodle and Sakai killer. .LRN already exists and works, Moodle is simply an instance of LORS and as such lacks the scope of .LRN, so when you merge the scope of .LRN with the ability to deliver online course, you can just "apt-get install dotlrn" and have any potential organization running in minutes with a basic server for testing blow away everyone at the presentation. This is huge, I can't underscore this enough.
- The overall user interface needs a rethink. I've spoken to quite a few people on the IRC channel, everyone knows this but no one has time. Fine, but this is minor and easily fixed.
- The applications in the repositories needs to be further debugged, further push towards bug fixing made, although everything is mostly good and mostly works. For us, .LRN, Project Management and a few other packages work great and will be Piloted in the next month or two if not sooner.
- OACS needs to make some noise. Never mind the negative crap, there is nothing out there like OACS. You can't deploy any framework faster, you can't get a framework with the production proven scalability of OACS and AOL server, you simply can't develop applications as fast as you can on OACS. I just don't think anyone knows about OACS. Holy christ, if i had this back at the Web Development firm before the dotbomb took place we would of killed all our competition!
We could of delivered websites almost instantly by simply reusing various applications, and perhaps adding a few more and concentrating on just creating the look and feel while charging for development time as well.
Okay that's it for now. Sorry for the rambling post, but it's 6am.
What I'm getting at is that OACS is so far ahead of any other framework out there that it's funny! Any shortcomings already mentioned in this thread I don't see as significant at all. Just tell people about OACS and they will come, which brings up the last rather interesting point, would you like to know how I found about OACS and AOL server?
I had no clue it existed, I was evaluating opengroupware.org and via some misunderstanding of their documentation ( they as well reinvented their own application server yet again! ) i googled up AOL server, by which I found OACS, by which i discovered that it has a unified security model, by which I discovered .LRN, LORS, and a ton of other applications, all that I installed with a few simple commands.
Just tell them you exist godamnit!
