Can't We All Be Buddies?
Microsoft recently announced its new real-time communications server. While this is a corporate server positioned to compete with a similar product from Lotus, ultimately it competes on a usage basis with AOL's AIM and ICQ products, Yahoo Messenger, IRC and a host of other products and networks.
It's time to get real about instant messaging: it's just not that hard. I'm not a particularly good programmer, but even I have built a chat system. There's just nothing that complicated about it, which is why there are so many chat systems out there.
Which brings me to the main point, the very basic question of why don't all of these systems interoperate by now? The only money being made in the space (and it isn't much) is through advertising in IM clients and that won't be affected by proprietary systems getting opened up. And I don't have to be an AOL subscriber to use AIM (or any other similar system provided by a membership based company) so it's not about inflating subscriber numbers (which is so late 90's anyway).
Chat is a basic and fundamental internet service, like email. Could you imagine what email would be like if you had to have an AOL account to email AOL people, an MSN account to email MSN people and a Yahoo account to email Yahoo people? Email would have died a long time ago as a totally useless service. It's a strong testament to value of instant messaging that it hasn't died yet. But it's time for all of the major services to put aside their proprietary systems and false rhetoric around open systems and actually develop a single instant messaging system.
In theory the principle of open systems should apply to all technology. We take open standards for granted in mature technologies -- all cars roll on rubber tires and no brand requires a special road. Plug a telephone into the network and it can communicate with any other telephone.
Ironically, complex or sophisticated technology, is less likely to adhere to a standard. More complex than Chat is word processing. The reason word processing software failed to fullfill the promise of efficient paperless systems is because software developers failed to embrace open standards. Document formats need to be open and standardized. Despite un-mitigated success in amassing great wealth, Microsoft is the greatest offender in this area. Their proprietary tweaks to any standard they touch are devastatingly bad for consumers. Under Microsoft domination of the market, software cannot compete on the same types of values that other products compete: efficiency, usefulness, elegance, price, etc. Businesses do not really have much choice about choosing software packages -- they need interoperability, so they forgo any other critieria they might use to choose, and impose a Microsoft suite on their employees. Of course, this means Microsoft has no incentive to make their products efficient, useful, elegant or price competitive.
Eventually, businesses and people who use software -- whether it is to chat, to process words, numbers, pictures, music, whatever -- will begin to demand that software be standardized, that it be priced competitively and that it be useful. Microsoft is not well positioned to be a player in that game, so their goal for the last decade has been to keep the game from moving that direction. It's self preservation that interests Microsoft. Not open standards.
Jabber provides an open platform based on XML.
I agree - your points have long frustrated me as I am building an open collaboration framework, but have to support 10 different IM platforms!
I wouldn't even mind if they would just easily communicate - they can all have their own little worlds, but let them *talk* to each other ... PLEASE!
Maybe Communication Server will open the dorr a little :)
====
= Maybe Communication Server will open the dorr a little :)
====
Doubtful. :(
MH
'have to have an AOL account to mail AOL members, etc.' pretty well describes email in the 1980s. Sendmail was originally designed to be a gateway between email flowing between different networks. O'Reilly used to publish a book on the arcane syntax required to email from one system to another, and it was pretty ugly. The book's title was a series of unpronouncable characters, something like "%!@*$"
In my efforts to build a enterprise IM gateway product I've had to dig way down into the protocols and get into the minds of the AIM, MSN and YahooIM developers. There are three different strategies and goals at work behind the three services, and I now have a much better understanding of why they don't interoperate (and why they don't really want to). Ok, maybe Yahoo wants to interoperate, but it's at the bottom of the totem poll and actually loosing market share and active users (especially in the business market where future revenues are likely to come from).
The MSN and AIM protocols are about as different as you could get, even if you set out to make them different. Their network architectures are widely different, each using multiple connections in completely different styles, etc. MSN's also gained the advantage of a later entrance into the market in creating a much more homogenous design for different services, compared with AOL's evolutionary protocol.
But a big difference in AOL's approach is its policing of use of the service. They don't police the content, but they have an entire section of the protocol dealing with transmission rate limits, packet and component sizes, retry and reconnect counts and on and on that the client has to conform to. Any violations of these limits results in the session being terminated. This has helped AOL in trying to keep the lid on chat spambots, protocol exploits and other malicious behavior that seems to run rampant on Yahoo (and to a lesser extent on MSN). The funny thing is that some of the earliest enterprise IM gateway technology actually came from IM agent companies that needed a proxy so that they could get around these limits and test their 'bots out without being kicked off the network.
Trying to combine these services together would obviously result in the lowest-common-denomintor feature, functionality and security; and would actually commoditize the carriers. Obviously they're not interested in either happening.
As David pointed out, the state of IM now is pretty much a rehash of email twenty years ago. My prediction is that the same thing that happened to email will happen to IM--it will decentralize--and the product I'm working on could turn out to be step toward the carriers' extinction if we hit our targets.