Is Skype a parasite or a Trojan?

In those days of web 2.x, I often feel that those practicing high doses of ideas mashup usually end up with brain jam. I have had found another good example with this fine piece. Obviously, there has been some discussion going on around IM interoperability lately, which in turn has brought back all the bitterness about our inability to easily and instantly communicate. But have you ever noticed how the same recipes always make for headline of “tabloid blogging”. This one starts with an aggressive title using a few recuperated clichés such a “cold war” and “détente” to awaken old instinctive fears inside the reader. The post follows with a spread of unrelated references, which relevance and validity were obviously never questioned. It goes on enrolling some fellow bloggers unwillingly, citing them partially and out of context. After this the author can pretend to pose as a pundit. Well... Some have different views and present alternatives hypothesis. I personally believe there is one approximately true statement and two major flawed assumptions to justify a lot of conjecture in this paper.

Beyond the tectonic plates’ image, declaring that IM interoperability is a business issue is probably true. Very simply, because this is a matter of toll gates, which is usually solved by a financial transaction. This is turn is business. Am I missing something?

The first flawed assumption is to present LCS as the enterprise federator, and by consequence, suggesting SIMPLE as the federating protocol. In the context of gatekeepers business, it is normal for Microsoft to claim its LCS as the universal federator for an enterprise willing to access public IM networks. This was only a matter of deep pockets and separate negotiation with every “entrenched interest”. Skimming through the recently discovered interoperability guide for LCS 2005 has somehow persuaded the author that LCS was “the” technical interoperability solution. I would only say that it may be a hasted conclusion. LCS (and other federating EIM servers) does not allow federating between public IM clouds, as inter cloud communication is specifically restricted by every individual business agreement. A second hasted conclusion is to use Google’s (very real) inaptitude at marketing Google Talk as a reason to look at XMPP with contempt. Jabberites, you would certainly be happy to learn that “with just 3.4 million [GTalk] users, who really gives a damn what you do”! Beyond the arrogance of the statement, Google is not interested in building communities; it is interested in driving traffic though its sites to increase its advertising broker’s exposure. Google has just opened the door to millions of XMPP users. This was a smart move and was received as a friendly gesture, re-enforcing their “not so evil” perception as a web company. Obviously, seeing this requires thinking outside the IM box. Which in my opinion, neither the IM incumbents, nor this author, have shown a good aptitude at doing.

The second flawed assumption is to present the Skype protocol as the “white knight” of interoperability. When writing about IM interoperability, it would not be wise nor popular to support any one of the competing incumbent public IM protocols. If so, what is left in the protocol landscape to fulfill that interoperability role for the public IM crowd? SIP has been ruled out as a contender (look at the bottom of the post). XMPP has been dismissed above. Only Skype remains to take up the role of the messiah. But now that its protocol has been hacked, I personally think Skype will pay a ransom to this group of Chinese hackers and buy them. This is in line with the recent wave of extortion based virus activity. Hacking a proprietary protocol is the just another flavor of it. But Skype could also make their protocol specification public and disable the threat, couldn’t they? They won’t do it, as they would have to admit publicly that their protocol’s client exhibits a singular cross between a parasite and a Trojan’s behavior. For the Skype network protocol, any node is a potential relay for any other node. There is nothing wrong with this design. But there is something very wrong with hiding this behavior from the end user. Aside from the questions of ethics and privacy, it steals from the user by using the computer's memory resources and also by eating bandwidth as it relays traffic via the user's Internet connection. Because it is using memory and system resources beyond the specific user’s need, the client operation may also lead to general system instability. Hence Skype’s relative reluctance to documenting the protocol...

Two approximations in one post make me feel suspicious. However, I know some peoples also define a truth as “an ingenious compound of desirability and appearance”, adding immediately that

Discovery of truth is the sole purpose of philosophy, which is the most ancient occupation of the human mind and has a fair prospect of existing with increasing activity to the end of time.

Who knows, the author may just be a philosopher in the making ;) As a conclusion, his conjectures provided sources for an additional demonstration that IM interoperability is not about technology. The solution to interoperability will never be resolved by interests entrenched in vendors’ consortia, be it Cisco behind SIMPLE, any other incumbent public IM or Skype. In the same way mail clients are on every personal computer, IM consumers and developers would only benefit when they will have the same kind of protocol: free, open and standard.

Technorati Tags: XMPP, Jabber, SIP, VoIP, Skype, Interoperability, Antecipate