I must admit also that Philip convinced me of this point at the last social. There is absolutely no reason to be religious about the language we use.
There are, however, reasons to be religious about maintaining a single version of OpenACS rather than encourage multiple versions written in various languages. It's actually sound engineering management to discourage such efforts.
The result would be a maintenance nightmare, one that even a large, well-staffed company would find difficult to deal with. A relatively small, mostly volunteer-staffed project like ours couldn't cope.
Will that change? Well, maybe, but if the market for OpenACS is so strong that the consulting companies involved grow to the point where they could afford to maintain multiple language versions then the argument to do so evaporates, in a sense. The market, in other words, wouldn't be so small after all 'cause lots of money was being made, and the resulting funds would be better spent on added functionality, etc.
Integration with .NET is probably inevitable, at some level.
As far as losing business because you're not working in the Windows market, well, MS still only has 25% of the web server market, so you're on the 75% side of that fence. And of course OpenACS will run on Windows - it's just not VB-based. What is needed are some Windows success stories for those who are interested in that market. I realize the market you're interested in is much more Windows-centric than others, so I don't have a good answer. Someone has to be the first guinea pig and as you mention that person will probably have to pay a lot more for development in the Windows environment than in the Linux environment.
Now, something that *might* make sense would be an MS-SQL port of the toolkit, along with resurrection/completion of the IIS interface to OpenACS. Supporting another RDBMS certainly does increase maintenance and development costs, but not nearly as much as supporting multiple language versions of the toolkit.
