Forum OpenACS Development: Re: FYI: My Vision and priorities for OpenACS
Most importantly, while Lars didn't get into explicity detail about this in his vision and priority outline above, it should clearly follow from what he did say about what he thinks is important - which I agree with - that the whole AOLserver vs. Apache thing should not be a priority.
You really think AOLserver is "the" sticking point? You already touched on the Tcl vs. PHP issue... Let me tell you what I think: Replace AOLserver with Apache (lots of work for no technical gain at all), and will OpenACS get many more users and developers? No. In reality, what would happen is that yet another insurmountable "the" sticking point will arise. PHP vs. Tcl vs. Python vs. Perl, PostgreSQL vs. MySQL, etc. And in the end, maybe even ultimately the plain old "I don't care how good it is, it's not what XYZ already uses" sticking point.
What it all boils down to in the end is that OpenACS isn't LAMP, nor is it .Net, Java/J2EE, nor whatever other language/environment du-jour will next spark the fancy of the IT trade magazines and programming masses. And as long as it isn't one of those things, there will always be yet one more "the" sticking point "preventing" OpenACS adoption. Going down that road is playing to OpenACS's weaknesses, fighting a losing battle, and I don't see any sense to it.
Better to stick with the high-quality underlying tools OpenACS has now (AOLserver, Tcl, PostgreSQL, Oracle), and - more importantly - the sound technical and practical reasons for picking those tools in the first place.
Now, yes, there are a minority of people who really genuinely want to run OpenACS on Apache, or MS SQL Server, or whatever else. And the work John Sequeira and a few others have done towards those ends is laudable and good - and may even help in some of the external sysytems integration goals Lars touched on above - but it can't be the central focus of any OpenACS strategy - not any successful strategy anyway. Or so it all seems to me.
Of course, to partially contradict myself, if good support for Apache, PHP, Python, FastCGI, and whatever else just dropped into our laps, that would be great and maybe very valuable! (In fact in my Copious Free Time I've even thought a bit about working on AOLserver Tcl/PHP integration, just because it's interesting and potentially useful. Not quite so interesting and useful as integrating both AOLserver's database support C code and OpenACS's db_api into a Tcl library useable from outside AOLserver, but still...)
I just don't think any of that makes sense as a central focus, goal, or plan for the OpenACS project as whole. Make this stuff a subordinate goal, sure maybe, but please let's not convince ourselves that focusing principally on any one of these Apache vs. AOLserver religious-type issues would be a good strategy.