Why do we have our own separate chat system rather than going with IRC? What does the current chat client offer that IRC can't and what benefits could this choice have in the future?
What is meta?
- Any Stack Exchange user can ask a question
- The community provides support, votes on ideas, and reports bugs
- Your voice helps shape the way Stack Exchange operates
First of all, you're comparing apples to biology books. IRC is a protocol. So the question
is like saying
That said, there are many reasons why the Stack Overflow chat infrastructure is not based on IRC. Here are the (in my view) most important ones:
1. The technology stack
Almost all of Stack Overflow's / Stack Exchange's technology runs on Windows, IIS, and ASP.NET MVC. Now, anyone can think that this is an inferior technology, evil proprietarism, or waste of money – it doesn't matter what they think, because the bottom line is: It is how it is.
And when a company offers a product, they have to support it. And for obvious reasons, almost all Stack Overflow's developers have long-time experience with this stack (myself being an exception). So building the product with the same technology makes sense.
Of course you can throw in a "best tool for the job" argument here, but matter of fact is: "the job" is not only "offer a chat service", but "offer a chat service that integrates well into the rest of the company's toolchain/development process/support mechanisms/infrastructure".
There are many features that we want to have in the Stack Overflow chat that are not (or not without a big hassle) supported by IRC. rchern has named some of them in her answer. Others include
3. Parent site integration
This somewhat ties in with 2), but is important enough to be its own point.
The Stack Overflow chat is not just a stand-alone application. It is intended to be supplemental to Stack Overflow itself.
4. End user accessibility
Please don't tell me IRC is good at making it easy for people to jump in and start chatting. Because it's not.
To somewhat effectively (let alone efficiently) use IRC, you have to get comfortable with a bunch of commands and conventions. Of course there are clients that assist in hiding some of the complexity, but in the end, if you don't have an at least basic understanding of the underlying technology, it's pretty easy to misuse IRC.
Let me quote Steve Krug here.*
*Steve Krug, Don't Make Me Think, 2nd ed., New Riders, pages 26 & 28
When a user comes to the Stack Overflow chat, what they want to do is chat, period.
This gets even more important as the Stack Exchange network expands outside the traditional technology geek area. What percentage of cooking / biking / saltwater aquarium enthusiasts have ever even heard of IRC?
But even within the geek/programmer community, the whole "They like to figure out how it works and have no problem with digging for results" idea is a myth in my experience. Even we want to get things done. And I think that the overall response to the launch of the Stack Overflow chat (both in terms of sheer numbers and in terms of the very positive reactions) is another proof of this.
I may not agree with the choice necessarily and I won't get into that, but this seems to be turning into oh, oh, that says irc...downvote!! despite it being a perfectly valid question, so here's a couple things. They each have their own strengths and weaknesses.
Personal opinions on how these things could be handled not included.
Disclaimer : I still didn't use the chat system, so this is only reflecting my point of view.
As flexible as IRC could be, doesn't offer modern perks of modern community chat service :
As bad as it could be to "reinvent" the wheel against using a proven protocol: Provide a web interface that is familiar to user (integrated), instead of try to integrate a web interface based on protocol limitations :
Plus pushing an all microsoft solution looks very good for MSFT, so they would be more willing to support the website (technically or financially).
But my emphasis would be security. IRC still reeks too much "social engineering".
Two good reasons not mentioned so far.
One: web-based chat is supported out of the box by all modern browsers. IRC requires you to install additional software, certainly on Windows at least. (On my Windows 7 machine, neither IE nor Firefox nor Google Chrome recognise irc:// links.)
Two: web-based chat operates by HTTP through port 80. IRC requires other ports, which are much more likely to be blocked by corporate firewalls.
Wow, you all REALLY hated this. Impressive negative response! This was just my opinion. My point was that some people expressed interested in IRC -- sorry for offending you all :(.
(This should be a comment on balpha's answer, but it's too long. So I'm posting it as a response instead.)
1: Technology Stack
There are a few good points here, but basically, there is no reason you cannot write an IRC server in pure ASP.NET MVC, or whatever. There's no rule that you have to use some IRC server in another language. I don't think this really counts as an issue.
Again, with your custom C# IRC server, many of these become trivial to implement as well, making logs available and searchable is just a few extra steps. Once you re-create the chat.stackoverflow.com website -- even as just an enhanced IRC client -- you can do the same integration with the website.
3: Parent Site Integration
As the post says, you could just have NickServ use OpenID. At this point, it's not that hard. Again, all of this can have a great UI on the client-side webirc client at chat.stackoverflow.com, and a much poorer one on a standard IRC client. That's fine. The people who are using IRC to connect to this are the ones who can figure it out.
4: End User Accessibility
Similarly, the chat.stackoverflow.com IRC "client" can create that nice experience. No more confusing commands, it offers a easy-to-use, well-designed way to get chatting quickly and easily. No hassle. The only difference anyone would notice using this type of setup would be that you can connect using your favorite IRC client.
And that would get you at least one more person idling and answering questions.