. although I did not do exhaustive research by any stretch,
confirmed my initial thoughts as to how the open-source community would react, for the most part.
some comments just shortly, and without explanation, ridiculed MS for whatever un-related reasons they could - marketing, security, or just nothing. I tried not to look at these as the open-source official response, but open-source being what it is, there really is no official stance or response. I had to just go thru as many individuals' comments as possible.
one of the main themes that seems to be going on Slashdot is comparing Linux distros' interoperability, with many people citing the inconsitencies in some bash commands, or package management, or system use, or whatever. most people over there are focused on Linux and OO, and uses those as their examples.
I'd like to respectfully disagree with you here, using my own personal example...
I need my system to interoperate with a customer's system. I need to receive an electronic PO from them, acknowledge it, do our internal business process, send an invoice, receive acknowledgement, then wait for electronic payment. if we can get our systems to electronically interoperate in this way, we can save over a dozen man-hours/week spent on paperwork.
my system is a mix of ColdFusion pages on Windows 2000, PHP scripts on Red Hat Enterprise 3, and Informix 9.1 on Solaris. amongst the scripts and stored procedures is a lot of proprietary business logic for determining prices, markups, profit/loss figures, etc.
their system uses Oracle (both database and business apps), and webMethods, and maybe a slew of other languages/platforms on whatever operating system(s) they use, and it probably contains their own proprietary business logic as well.
in this situation, not only would opening up the source code be a privacy concern, but it would also do no good for me to see their Oracle or webmethods or "programming language X" code, unless I spent hours trying to figure it all out.
so opening code in this situation is not the best interoperability solution, and in fact, it would be a very BAD approach.
but, your title/comment is 95.8333% correct. "The best interoperability...Still occurs when your software...protocols are open, and I can look at them and 'interoperate' with them at will." I removed the "AND" because it is really only important for the protocols to be open.
and in this respect as it applies to my example, I'm sorry, but Mr. Gates's approach is 100% correct - XML. by establishing a protocol based on XML, ie. SOAP, the systems can easily interoprate without having to see the code underneath. this is indeed what we did and what we do with many partners, and it takes about 30 minutes to get the systems talking. no source code exchanged at all.
as for Mr. Gates's other assertion, that open-source development encourages "permutations" which cause interoperability problems, I can't really speak to it. I haven't used enough open-source applications to experience it.
even if it is true, and open-source applications fork and become disparate, XML can still be used to integrate these similar-but-incompatible systems, just as it is now being used by Microsoft to integrate their similar-but-incompatible, spaghetti-code product line!
the great thing about XML is that it is not Microsoft-specific. in fact, it transcends nearly all platforms.
by using open-source software, you get a huge range of options in products, meaning you can choose the best application for your needs. by using XML for interoperability, you get to use that best application with all the other best applications you've chosen. Open-Source and XML is the best of both worlds.
sorry to go off on such a tangent, but if open-source software is going to really progress in the interoperability area, it would do so best by letting go of the idea that interoperability is everywhere and always best addressed at the source code level. it's just not universally true.
letting go of this impractical ideology towards interoperability will be ANOTHER good step in making open-source development models viable for traditional commercial enterprises.
I would also add that the thought of replacing current systems with open-source systems is probably not as attractive to enterprises as augmenting their existing systems with very cheap, open-source applications that will very cleanly interoperate with the proprietary systems. If open-source developers continue to insist on source-code-level interoperability, it's not going to happen, and proprietary vendors will still be relied on to make the improvements.