Why just MSN? What about supporting other protocols?

First of all, i have tried to write a multi-protocol IM. Turns out that the code was growing exponentially for each protocol i have added. For each different functionality one protocol implements, i had to create an abstraction layer for all of the protocols. I firstly tried to abstract the protocols creating one layer and plugging all the protocols into this layer. This path was wrong because the protocols (MSN, AIM, IRC, ...) are too different. Take for example MSN, it has the Switchboard, SLP, P2P, other protocols don't.

What about telepathy?

I'm sure they managed to abstract the protocols in a nice way with dbus. But telepathy doesn't implement each protocol special features. Take for example MSN, they do not implement custom emoticons, winks, nudges, ... For now they only have implemented the basics like messaging, contact list and of course video (which isn't so basic). I'm not criticising them here. This, i belive, was their goal and it is very useful for some mobile and desktop users. This makes me think on the next topic which is the target audience.

Target Audience

If you are reading this, you are probably a developer or someone that understands technical details about programming. Being a developer, you don't care much about winks, emoticons and all those silly things. But what do users think? Most users uses Windows and the official msn client which has support for a lot of "silly" things. Our users (the monkey messenger users) have friends that uses Windows and those friends wants to send our users love winks, funny winks, funny emoticons. They want to express their feelings with all those "silly" things. So, what is "silly" for us developers may not be silly for other users. Think about your younger brother or sister. I bet their IM client is filled with animated images.
Take for example Gaim. Does it suit for your little brother/sister? Do they understand that complex account dialog? Would they use it? Probably not. I always think about my mom. She has a doctorate and is a very clever woman, but would she be able to use a multi-im client like Gaim? No!
So this is our target audience, people that likes to express themselves, people that doesn't use more than two protocols (considering that they can use two clients, one for each protocol), people that doesn't want to use complex user interfaces or have to stop to think about how it works.

But.. what does complex UI have to do with multi-protocol?

There was another solution to implement a multi-protocol client which was abstracting the user interface so each protocol would communicate directly to the interface. This would work better i think, but it would still generates problems like code size, manutenability and specially usability.
Take for example MSN. It offers some user status like away, busy, out to lunch, on the phone, ... ICQ offers other users status like away with custom away messages which MSN doesn't have. Why a user that only uses MSN would want to type an away message? It won't be displayed to other contacts. We could set the MSN personal message to display this message, but this is not the purpose of display messages. So, the users ends having functionality in their multi-im client that they would never use, or that they will use and it will not take effect on the current protocol.
Just hide this options and make special cases for each protocol! There we go again, complex code, hight abstraction and exponential code growth and specially usability. The UI needs to be consistent, the user would be confused if sometimes an option is there for that protocol and sometimes it isn't for the other protocol. The user doesn't understands about protocols, they just want to talk with their friends and co-workers.

There are another ways to do it.

Think about galago. Take a look at Gimmie, picture the Novell Computer menu with a People tab page. Think! What is the real purpose of having a multi-im client? For me it's having all my contacts on only one place. That can be archived with multiple single IM clients having interfaces to interoperate with one single contact list.