Don, the license fees and security are both extremely compelling arguments, for sure, and will be used in liberal amounts during the sales engagement. From the perspective of the nontechnical administratives, I think it will be very easy to point to historical inseecurities and unreliability. This is, of course, also a very important technical argument, as engineering is evolutionary process.
However, I would really like to go in with some more exact technical arguments as to why the architecture is either intrinsically insecure or so immmature/underdeveloped that it would be foolhardy to accept it in its present state.
That is, during the technical sales engagement, it will be very hard to be a broken record saying, "look at the history, look at the history..." especially as MS is putting out new marketing/FUD about "secure and trusted computing."
MS is positioning the .NET architecture as a "revolutionary product" that will change "computing forever." (Ballmer was actually touting XML as "as big as the invention of the PC and of the Internet"). I guess what I am looking for is explanation, evidence or data that:
- How the .NET architecture fits within the context of MS architecture (which is unreliable and insecure)
- How this is different from the OACS/Unix philosophy
- What is good and/or bad about this?
I know these are quite open-ended questions, but I'm hoping the answers can be made vis a vis the OACS toolkit. I have developed good arguments/comparisons of OACS vs J2EE and OACS vs Zope, but don't really have one for .NET other than, "Uh, MS? I hear they are evil, but you'd have to ask George Bush about that..."
Jun, thanks for your points. Those are really helpful. I know the communities of .NET and OACS are very different, of course, but I hadn't thought of the fact that .NET extends beyond the web client/server model.
talli
I'd be happy to write up a OACS vs J2EE/.NET/Zope biznarse argument if this thread gets going.
