How about doing a PHP port of OpenACS? The enormous popularity of PHP cannot be ignored
You would be suprised what can be ignored.
But seriously, here's an engineering answer: There are >250000 lines of code in ACS (source: pset 2. I'm not on a machine with GNU tools at the moment, I can't do a line count;). Porting them, and keeping them up-to-date would be non-trivial. It might be easier to add support for Tcl in PHP, and open the Tcl namespaces to the PHP environment, than to rewrite. But then what about the hypothetical people who start writing things in PHP on top of those interfaces?
Second problem is this: ACS is big on PL/SQL. To my mind, that is how it should be -- you should get as much work done inside the database as possible. But the unwashed masses, many of whom use MySQL and aren't even convinced of the needs of a real RDBMS, may differ. So they tend to write code implementing some segment of ACID way out in the webserver. Happy as I would be to have more people using ACS, dealing with more code like that would make me lose my morning bagel.
So although a port to a more popular language may attract more developers, I suspect that the real reason is that old demon, unwillingness to learn new tools.
and it will also give the whole ACS/OpenACS effort a lot more momentum. A PHP/PostgreSQL version of the ACS will make a huge impact on the web!
I think you misunderstand people's reasons for choosing a toolkit. So far, the only reason to choose ACS is if you _really_ want to run a community site, specifically a site that has community support worked into almost every component. Many many developers do not want/need that, at least not for what they are doing.
Now, do know at least one start-up in Mountain View who would like a PHP ACS, if only to access to a larger developer pool, but until they learn to work inside the DB, said programmers are still not useful.
Hope none of that was too inflammatory.
mmm.. bagels.
