Hacker News Reader

It's worth mentioning that Zulip (https://zulip.org/) is a new open source option that has basically all the features IRC/Slack does. So using open source tools for open source development doesn't have to mean dealing with IRC's limitations.

(I'm one of the Zulip maintainers; happy to answer any questions about it).

I've been meaning to give Zulip a try. How many users can it handle?

Less importantly: What would you say its biggest missing feature is vs Slack? And conversely what does it bring to the table that Slack can't touch yet?

IMO, push notifications for mobile applications is a big hole. It's not an easy problem to solve, but as of right now I believe you have to release your own flavor of the mobile applications for this to work.

Yeah, the mobile apps support that on zulip.com but work needs to be done to make that work with running your own Zulip server...

I'll field the latter. I've used both Zulip and Slack in small team (5-20 people) settings and I much prefer Zulip.

In particular I like how the zulip UI is single-stream by default. Messages from different channels are interleaved, so you can read all new messages at a glance, but still well separated by visual elements including color - I don't find it confusing. And I can focus down to any particular channel , or reply to that channel, in one click.

It goes all-in on this "many streams, one view" model with the concept of topics - lightweight "subject headers" for individual sub-streams of a channel. This neatly avoids the "two conversations at once" problems that can occur in other systems occasionally.

Some more minor points are a wider range of markup available than slack (including syntax highlighting for code), and better support for short-lived private groups (ie. "a PM between Alice, Bob and Charlie")

As to what I think Slack does better: More one-click integrations (and likely other backend admin stuff that I don't see as a simple user). AFAIK Zulip doesn't have an irc gateway. Also when I last used it (over a year ago) Zulip's mobile client was quite poor.

I'm sure others can come up with more differences - to be honest I tend to treat slack as "slightly smarter irc" so I don't pay attention to all the bells and whistles.

Finally I should caveat that these same features I like are things people dislike about Zulip - it's more dissimilar to existing solutions and people will always have their preferred ways of doing things. I personally find Zulip amazing for me.

FWIW Zulip does have a beta-quality IRC gateway (bots/irc-mirror.py); anyone interested in working on improving that should check out this issue: https://github.com/zulip/zulip/issues/249

I especially like the concept of topics in zulip. It helps maintain different subjects in a given channel, which is way more readable imo. I'm a big fan.

Other answers address the big user experience advantages (e.g. threading) that it has over Slack, but there's a bunch of smaller features we have that I don't think Slack does (e.g. you can configure regular expressions to automatically linkify patterns like T123 to link to your bug/ticket tracker).

In terms of features Slack has that Zulip doesn't, I think the biggest ones are features that Zulip has today on zulip.com (which isn't taking new users) but you can't easily setup for your own Zulip server (e.g. the Android app doesn't support talking to a custom server without patching it yourself, mobile push notifications aren't available with your own server, etc.). Contributions on those things are welcome -- they're all relatively easy problems for someone with some mobile experience.

In terms of features that aren't just missing configuration in the run-your-own-server model, I'd say the biggest one is that Slack has a really slick onboarding experience and it has more slick integrations. It's hard to compete on onboarding with a company with like a hundred engineers, but I don't see the integrations piece as being a long-term advantage for Slack -- they're easy to write and I expect the open source community to produce a lot of them for Zulip over time.

I'm excited about Zulip as a Slack-style tool, especially for teams. (Separate from the discussion of whether FOSS project collaboration should be Slackish or IRCish.)

Are there any plans to support multiple teams / multiple servers from the native client? This is a particularly acute pain point on mobile; I'm reluctant to promote any tool that requires me to be logged in to only one project's instance of the tool at a time, because if it works well, it gets adopted for other projects, and then I'm having to juggle clients. I am unfortunately on two projects that use HipChat, and even there it's a huge pain that I can't be logged in to both simultaneously on my phone. (Some of their desktop apps finally support multiteam which is a huge help, but I still have to pick just one to participate in on mobile..)

Slack isn't perfect, but at least all the native clients will let me be logged in to 5 teams at the same time. (And no, opening multiple browser tabs is not an appropriate solution - it doesn't work at all on iOS, for example.) And obviously, this is something IRC does a great job of as well.

That isn't currently supported since it wasn't super important before Zulip was open sourced a month ago, but I definitely consider it one of the major problems that need work for both the desktop and mobile apps.

Very glad to hear that!

do you have an android sdk that someone can use to integrate chat into an app ? I'm kind of comparing you to Pubnub or Pusher.

> basically all the features IRC/Slack does.

First, let me say that I'm really happy zulip was opened up, and grateful for you and your team to support it.

But does Zulip support server federation? Obviously slack doesn't allow self-host, so if slack is the alternative, that doesn't really make much of a difference. But that is one feature that http://matrix.org/ does support.

Just to say - we would love to work with Zulip to federate it into Matrix :)

Ping me over email (tabbott@mit.edu) and we can discuss; I'd definitely like to add a federation story. Haven't looked at Matrix's technical approach before...

Ehh, as someone your age (a couple years younger even), I have a completely different take on IRC.

It's incredibly intuitive because it's so similar to all the other chat clients we grew up with (presumably because they're based on IRC).

Sure, figuring out bouncers and build bots is a little tricky at first, but so what? That's the fun part. It's kinda fun digging into the IRC protocol and figuring out how it works.

And ok, if that's not fun for you, there are plenty of really "click and install" tools for you (e.g. ZNC is super easy to setup).

Not to sound like an elitist prick, but if you can't figure out how to setup an IRC bouncer, I'm not sure I really trust you contributing to the linux kernel, yaknow?

Reducing friction is great: But the kind of friction we should be trying to reduce is bureaucratic friction. Throwing out PRs and yelling at people because they forgot to cc some particular maintainer - that's the kind of friction that sucks. Having to setup an IRC bouncer? Idk, I think that's fine.

Same age group: Which chat systems were similar to IRC, but not to Slack, outside of IRC clients?

And just because someone doesn't want to spend the time fiddling with IRC bouncers, IRC bots, getting clients to display things nicely doesn't mean that they are a bad developer. Just that they have different priorities for their time than you.

I'm not saying that Slack is perfect or frictionless, but neither is IRC. And especially if you don't do it all the time, getting people set up to work with Slack is way easier than IRC.

I really find these discussions half amusing and half depressing. 2 sides have something that is "good enough", both insist that nearly all you want can be solved with their solution, especially if you just do X1,X2,X3,Y1,Y5, and Z4 and you technically could build something that is perfect for both on top: but sadly (and understandably) no-one actually cares enough to do so. Because what they have is "good enough"(TM).

> Which chat systems were similar to IRC, but not to Slack, outside of IRC clients?

Slack is very similar to IRC at its core, so I'm not sure I see what you're asking here. I meant that IRC isn't foreign or alien to anyone who's familiar with chat clients - the basic concept of servers and channels and nicknames is pretty universal.

> And just because someone doesn't want to spend the time fiddling with IRC bouncers, IRC bots, getting clients to display things nicely doesn't mean that they are a bad developer.

I feel like I covered this point already:

> And ok, if that's not fun for you, there are plenty of really "click and install" tools for you (e.g. ZNC is super easy to setup).

> And especially if you don't do it all the time, getting people set up to work with Slack is way easier than IRC.

What are you referring to here by "getting people setup"? Like a corporate environment? It's fairly easy to setup bouncers and the like in a corporate environment using tools like chef, etc. I really don't feel like this is a strong argument for a corporate setting.

If you mean on a personal level for individual contributors to get up and running on contributing to FOSS, sure it's not 100% frictionless - but pretty much. Again, there are lots of bouncers that can be setup with <5 commands.

If the argument is that it takes an extra ten minutes to install ZNC vs. Slack, then I dunno - I guess I don't see that as very much friction when the tradeoff is using non-free software.

> I really find these discussions half amusing and half depressing

I feel the same way, but for different reasons. It's a little depressing to me how averse people are to spending 10 extra minutes to use FOSS, usually under the guise of "I have different priorities." I thought developers in the wild would at least be slightly more willing to invest the time, especially post-Snowden, to use FOSS. I guess that was just a college pipe-dream of mine.

I don't think you sound like an elitist prick, but rather the kind of person that enjoys tinkering with technology for fun. Perhaps unfortunately, this view is no longer representative of most people working in technology, and definitely not all of the users of Slack.

I think that's true, but I also think it's a little silly to contribute to FOSS but be unwilling to spend the extra time to use FOSS.

I guess it's kinda just sad to me that you'd be unwilling to spend the time to use FOSS while you're contributing to FOSS. If it was incredibly costly, sure, but IRC? I dunno.

We're interested in tinkering with a lot of technology. We're not interested in tinkering with boring (admittedly a very subjective judgment) technology like a chat server.

Good call!

I meant that software can be a philosophy or a project, and where you land on this concept will inform your decision making process. I agree with your above comment and don't find it contradictory to mine above.

Some great tools for software development:

* Microsoft * OS X * Linux * Free BSD

To some degree that represents a spectrum and I don't fault the author for having strong beliefs about how software should be built, and agree with them for the most part. I think he could have made a stronger point generally from a philosophical and technical angle, i.e the regular arguments for open source tools, and highlight Slack as an example.

IRC is quite similar to Slack, but for the reasons the author suggests, it is different.

tl;dr Stallman wouldn't use Slack.

Given how terrible the HipChat client is on Windows, it's really saying a lot that people end up choosing that over IRC.

Maybe Freenode could implement an enhanced IRC protocol and clients could opt-in to that.

I know at least one project that was very active on IRC, and they moved to HipChat for convenience. They also went full-on with the entire Atlassian stack (again, the fact anyone would choose JIRA is damning against everything else.)

I actively avoided IRC for years. I still avoid it whenever possible. And I've been developing and sysadmining for the web for more than 10 years now.

Frankly, it boils down to that I just don't like it. I'm more interested in getting better at programming, or learning about containers, or some other useful thing, than trying to figure out IRC's odd interface. Chat isn't something I should have to think about. It should just work.

So, I agree with most of what @vonklaus said, and disagree with the links pro-irc stance.

I've never used Slack, so I have no opinion on it.

You can master IRC with a few basic commands. In fact I rarely have to use anything more than /join, /leave and /msg <someone>. /me <some text> for announcing an action. That's about it.

(It probably helps that a lot of in-game chat interfaces use a lot of these same commands, as I'm a gamer as well as a programmer.)

There's a pretty nice web interface to IRC called irccloud.com which also persists your connection (so you can simply log onto irccloud.com somewhere else, and entire history is preserved).

For buildbots, it's not that hard. See http://docs.buildbot.net/current/tutorial/index.html

Instead of using slack, use IRC Cloud.

Does IRC Cloud allow new employees to get the entire history of the channel? I can't see how it would from looking at its page.

I don't believe so, but you should look into IRCv3. We need to fix this problem at the root.

http://ircv3.net/

That page/project desparately needs a bullet point list of what it wants to fix with IRC.

Agreed, but here is the list of specs: http://ircv3.net/irc/

I don't understand what on that page would let you read messages people sent while you're not connected, or let you participate in IRC over an unreliable connection such as a mobile network.

Why do people talk like this is some impossible feat for IRC?

1. Have a bot that's in the channel from the start

2. cd into the bot's log directory and type python -m SimpleHTTPServer

3. put the url into the channel topic

How do some developers fail to rise up to this level of problem solving? I am amazed.

I'm a developer. The problem is not that I'm "failing to rise up to this level of problem-solving". The problem is how much free time I have, and whether I can afford distractions from my main project to fiddle with IRC and get it to do what I want.

We use Slack because "it just works". You get invited, you join, and BAM! You're done. There is one uniform client for all platforms and a bazillion integrations already developed for you. And creating your own is usually a simple matter of sending a POST request to a channel's webhook using a unique token.

Essentially it comes down to this: IRC is a protocol that requires a fair amount of research and configuration to make it do exactly what you want it to do. Slack is a product that comes with the vast majority of features most teams need. That's why a ton of people are gravitating towards the latter.

But that's substantially less useful than Slack's search utility. Believe me, I've spent my fair share of time grepping IRC logs and it certainly works up to a point. What you describe is a pretty lightweight, low-utility solution (are you really going to download six months/a year/10 years worth of logs and depend on your browser's search?).

Plus, keep in mind there are other people besides developers. There are product managers, UX engineers, designers, translators, and any other number of people who might not be familiar with grep and would otherwise not need to be. Assuming that only developers need to chat is pretty naive.

What if I didn't have the foresight to put that bot into the channel in the first place?

Or what happens when the bot goes down? So now I really need to build some alerting into it so that someone can restart the thing when it dies, or the server is upgraded, or it's moved.. because I'm losing valuable history along the way.

Or I can just use Slack.

The snark about developer skill is an interesting one, as you failed to actually solve the problem in your hypothetical.

Seems you've only explored failures for the IRC option.

What happens when Slack closes? Or they change their payment plan? Or they decide that they don't like your project? Or they're acquired by Microsoft and stop supporting your OS? What if a rogue Slack employee spies on your chat and steals your secrets?

So slack manages everything for you with their service. They ensure their logger is always running, their web services is always available and a Miriam of other things.

What you want is to outsource your messaging service. If you want this to be managed in-house, you must monitor the service as well. You can outsource IRC as well however, and they'll manage the boys and infrastructure for you.

Not sure if I understand what the issue truly is here!

Can it be done? Sure.

Should I take the time to create a solution that not only works for me, but is a pleasant user experience for my entire organization? That is a piece of work that is bigger than "python -m SimpleHTTPServer".

Or, I can trade money for a team that is actively solving the problem already.

Or, people who care could get a group together to tackle the inadequacies of IRC for the business use case as mattermost is trying. But let's not pretend that IRC fits the Slack use case well.

> How do some developers fail to rise up to this level of problem solving?

It does seem to solve the problem of how to set up a channel log in IRC but I sort of find this quite a narrow redefinition of the problem. The problem could also be:

* What is the best technology to use for collaboration?

* What kind of software and tooling is in line with our project philosophy.

I don't find either this comment, nor the one it is in reply to something that can be applied more generally. This is, at best, solving a problem that is a component of a much more expansive problem.

Or use Quassel (an open source project very similar to the proprietary IRC Cloud) and you can easily import the entire history of a channel into the backlog for a new user.

I’ve done exactly that.

Neither does Slack, unless you pay.

Why do you want that? At my company I don't think anybody has IRC logs enabled, and it is highly suggested that you don't do so - chat, much like real life conversations, is inherently ephemeral.

I can't tell you how many times I've went back and searched for a solution to a similar issue we had six months ago and solved it through collaboration in slack.

Should this end up in a separate wiki? Maybe. Will it? Not always.

I wrote a bot to serve log history search requests in my local IRC channel, because I got tired of fishing through my logs on behalf of other people, who wanted my history for basically the same reason.

At which point I got tired of whitelisting people instead, after abuse issues compelled me to disable anonymous access...