criticizing the critics
I went out of my way to find out how some in the open-source community were responding to the interoperability message from Gates. although I did not do exhaustive research by any stretch, the comments I did find 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.
but the post I responded to was more general, which was the kind of comment I was after. and here was the original comment:
and my response:
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.
but the post I responded to was more general, which was the kind of comment I was after. and here was the original comment:
"The best interoperability... Still occurs when your software and protocols are open, and I can look at them and "interoperate" with them at will. Still, it was a very good letter, almost as convincing (and just as bogus) as the TCO garbage they were doing a bit ago. That got debunked, so they need a new non-sequitur to try and make real-that somehow, closed protocols are better at openness then open ones.
If I need to interoperate, the quickest way to ensure that is if I can get into BOTH your code AND mine. There isn't a better way, period, and no amount of FUD from Mr. Gates will change that."
and my response:
I'd like to respectfully disagree with you here, using my own personal example...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.
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.
posted by luke @ 1:00 PM
3 Comments:
meh.
When are you going to stop basing your opinion of "the open-source community" on comments posted by lord-knows-who at slashdot etc.?
There are Many pragmatic Responses to this bit of BS from BG, and now I'll add mine, fisk-style:
"Sometimes interoperability is also confused with open source software."
I can understand the confusion. If I'm able to read/modify/redistribute the source code to a piece of software, I can make it interoperate with anything up to and including my 3-year-old's BeOS machine if I'm so inclined. This is not to say you MUST have the source code, but it's a big help.
"Interoperability is about how different software systems work together. Open source is a methodology for licensing and/or developing software – that may or may not be interoperable."
I'll need that one explained to me. If I build Matt's Spectacular New Email Client and GPL it, you can make it interoperate with whatever. No, GPLing it does not mean that it already interoperates with your 3-year-old's BeOS machine, but feel free. After all, it's free.
"Additionally, the open source development approach encourages the creation of many permutations of the same type of software application, which could add implementation and testing overhead to interoperability efforts."
Barnett did this reply for me
The preceding is a little obvious. Your example of when opening the source code might not be practical is fine, as is your advocacy for XML, etc. But I'm mystified as to why you think Microsoft is really doing a 180 here.
"The single-biggest benefit Microsoft derives from its monopoly position is the leveraged use of undocumented protocols, APIs and file formats to tie their various products to the client operating system monopoly," says Anthony Awtrey, vice president of Ideal Technology, Melbourne, Fla.
Source
and an oldie but a goodie:
Decommoditization of Protocols
So...great great if they've all of a sudden got religion and are Right There With You on how cool it would be for XML/SOAP to dominate network transactions. But Events even more recent than this memo make me wonder.
my post in no way adequately encompassed my entire opinion of "the
open source community (tOSc)." it is only a small portion of my opinion, not the basis. rather, I only meant it to counter the
if(source == "open"){
program = interoperable;
}
argument. and it may be that this argument is not mainstream to "the
open source community," but the points you made seem to support it?
the interoperability of a program is not a characteristic of the nature by which the source code to the program is licensed. rather, it is more about how the program was written and designed. the two are separate. this is the point Mr. Gates made, so to take that a little further...
a GPL program DOES offer an additional, exclusive method of implementing interoperability that will never be available to proprietary software - the source-code modification method.
the GPL'ed MSNEC could "be made" compatible with BeOS via source code, BUT the GPL does not bestow any degree of compatibility by itself. that's what his statements mean. and the "making" part *could* be so burdensome of a task as to be, for all practical purposes, more difficult than a proprietary program.
that is why I went into lengthy detail about an interoperability scenario which uses the method of exchanging XML messages. it's significantly easier than me trying to invoke the correct sequence of methods inside their accounting program's source code.
but, in the other stated example, to port an email client to BeOS, the only method may in fact be to have access to the source code of the libraries on BeOS and to make the necessary changes to MSNEC's code to invoke the correct methods inside the BeOS library.
both methods have their own places and times to be applied.
I am shocked by the vehemency I seem to detect in the "source-code for interoperability" argument. especially in response to a post that does little more than ask for mere *recognition* of the *possibility* that source-code level solutions are not *universally* optimal. but then, it's a call on a basis of an ideology, never an easy sell to make.
I'm in no way saying that Microsoft has done a 180 and is *executing* better on the interoperability front than "tOSc," as I see Gates's release as just more empty promises. my comments that seem contrary are not in defense of Microsoft nor in offense of "tOSc." I am just of the perspective that Microsoft CAN be right about some things. and that if/when they are right, they need not be immediately dismissed with FUD and BS labels, or criticized for their own shortcomings (relevant or not). they may even need to be listened to.
they are talking the right talk about interoperability. if open-source programmers *only* consider addressing interoperability issues at the source-code level, I think it will be a big drag on advancement in the area.
my post in no way adequately encompassed my entire opinion of "the
open source community (tOSc)." it is only a small portion of my opinion, not the basis. rather, I only meant it to counter the
if(source == "open"){
program = interoperable;
}
argument. and it may be that this argument is not mainstream to "the
open source community," but the points you made seem to support it?
the interoperability of a program is not a characteristic of the nature by which the source code to the program is licensed. rather, it is more about how the program was written and designed. the two are separate. this is the point Mr. Gates made, so to take that a little further...
a GPL program DOES offer an additional, exclusive method of implementing interoperability that will never be available to proprietary software - the source-code modification method.
the GPL'ed MSNEC could "be made" compatible with BeOS via source code, BUT the GPL does not bestow any degree of compatibility by itself. that's what his statements mean. and the "making" part *could* be so burdensome of a task as to be, for all practical purposes, more difficult than a proprietary program.
that is why I went into lengthy detail about an interoperability scenario which uses the method of exchanging XML messages. it's significantly easier than me trying to invoke the correct sequence of methods inside their accounting program's source code.
but, in the other stated example, to port an email client to BeOS, the only method may in fact be to have access to the source code of the libraries on BeOS and to make the necessary changes to MSNEC's code to invoke the correct methods inside the BeOS library.
both methods have their own places and times to be applied.
I am shocked by the vehemency I seem to detect in the "source-code for interoperability" argument. especially in response to a post that does little more than ask for mere *recognition* of the *possibility* that source-code level solutions are not *universally* optimal. but then, it's a call on a basis of an ideology, never an easy sell to make.
I'm in no way saying that Microsoft has done a 180 and is *executing* better on the interoperability front than "tOSc," as I see Gates's release as just more empty promises. my comments that seem contrary are not in defense of Microsoft nor in offense of "tOSc." I am just of the perspective that Microsoft CAN be right about some things. and that if/when they are right, they need not be immediately dismissed with FUD and BS labels, or criticized for their own shortcomings (relevant or not). they may even need to be listened to.
they are talking the right talk about interoperability. if open-source programmers *only* consider addressing interoperability issues at the source-code level, I think it will be a big drag on advancement in the area.
Post a Comment
<< Home