.NET Web Services uses SOAP, which is an Open Spec used on any platform - including Java. .Net is a lot more, it's also a brand new platform - much like the JVM. I'd say that this is the main thrust - and the main change that developers are going to have to deal with. It effectively signals the end of MFC and ATL as evolving libraries. The Web Service aspect is more marketing than anything else. Your point about who will pay for the services is interesting. It's has been pointed out that the current advertising model will no longer work for these services. Think about a search engine that publishes a Web Service, how do they get their money - what's their cost structure? I wouldn't say this is going to be a problem for .NET - more a problem for evolving the cost structure of the Internet itself. The only solution that I can think of is to pass the revenue down from the main client site down to the services that they use - this means that these services will not be free.

I think most people accept that C# and most of the .NET runtime technology is based on Visual J++ and it's JVM. Who would have thought that the future of the Windows platform would be born out of what Microsoft use to call 'Jakarta' ?!

In all honesty, I think the outcome will be become a irrelevent. We'll end up with the JVM stubs onto the .NET environment and vice-versa. Competing on implementations, rahter than specifications. "the eternal optimist" Joe

Clearcase was good, for large projects but its servers use a case sensitive filing system. This is a problem in VB/VC where the IDE tends to change the case of the files based on the entry in the project file. SourceSafe is nice and simple, but not so good for branching and large teams. One thing that I noticed about .NET... what's happening to Source Safe. At one stage there was a lot of talk about building version management into the Filing system??