Hacker News new | past | comments | ask | show | jobs | submit login
Five Open-Source Slack Alternatives (okturtles.com)
316 points by shea256 on Nov 2, 2015 | hide | past | favorite | 172 comments

I wish that someone would build an easy-to-use layer on top of an open protocol like IRC or XMPP. The tool could manage setup, configuration, archiving, and notifications.

Instead of building a walled garden that is merely accessible via an open protocol, it would be more interesting to build a thin layer on top of an XMPP server that could even be removed or replaced later, if desired.

They have - e.g. http://vector.im/beta on top of the Matrix.org protocol. [disclaimer, I work on Matrix]

Not to be too negative but based on quick glance it would seem like the Matrix protocol is really "noisy" if compared to something like IRC (which admittedly is ridiculously spartan). How much data ends up flowing down the wires for a simple "hello world" message?

Good question. The data you send in Matrix when transmitting and receiving a message is just the event (message) type, the room ID, and the appropriate key value data for the contents of the event. For an m.room.message event this is msgtype and body - e.g m.text and "hello world". The raw data is therefore only a handful of bytes.

Now, Matrix allows arbitrary transports to actually put that over the wire - but mandates only the most comically simple (and inefficient) as a mandatory baseline. This is a plain HTTP PUT request of the above data encoded as JSON and a few URI parts. The reason for this is that HTTP is insanely ubiquitous and well understood; any random device or language these days can trivially send and receive messages.

However, there is nothing stopping you from using a more efficient transport for the data between your client and your server - we've been experimenting with everything from boring old JSON over WebSockets to COAP or MQTT and even capnproto. We haven't specced any of these yet, but we'll probably add them as optional profiles to the spec in future. Meanwhile plain old REST actually works pretty well in practice :)

The fun stuff in Matrix is all about the eventually consistent decentralised conversation history between servers rather than obsessing about the most efficient way to shove some key value pairs between a client and a server.

But why does it matter? Bandwidth is super-cheap.

"But why does it matter? Bandwidth is super-cheap"

If this comment is serious (and I have my doubts), I'm left speechless... Don't even know where to start. I'll just leave it here http://www.theverge.com/2015/10/28/9625062/facebook-2g-tuesd...

> I'm left speechless...

Oh please. Without even knowing much about the protocol, I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range.

> "Without even knowing much about the protocol"

> "I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range."

I'm pretty sure this this is almost certainly the least, or at least within range of, quite likely the least definitive statement I might have ever read (or at least one of the lesser definitive of statements I've read within the past year, or at least the last few months, or so).

We see what you did there.

It's not about the particulars of this protocol. It's about the statement "bandwidth is super cheap". I would have called it super-oblivious first-world thinking but that statement is absurd anywhere on a mobile connection.

You just linked to a 3.5 MB web page. That's more than the complete Shareware DOOM

Any reason not to have openid or persona signup? Its just annoying nowadays to encounter a site where it still wants only plain old username / password.

Matrix as a protocol supports arbitrary login mechanisms; Vector + Synapse can hook into CAS, SAML2, LDAP and OAuth flows already. Patches more than welcome to hook it into OpenID or Persona :)

Persona support would be great!

Pretty sure I heard somewhere that Slack uses a modified IRC bouncer (e.g., ZNC[0]) to implement accounts. Could be wrong about that, but if that is in fact the case, this whole Slack vs. IRC debate would take on a whole new level of absurdity.

[0]: http://wiki.znc.in/ZNC

Slack has never been about the underlying tech (which may well be IRC), it's all about the polish. A lot of comments I see here about Slack remind me of the infamous "you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem" ( https://news.ycombinator.com/item?id=9224 ).

> Slack has never been about the underlying tech (which may well be IRC)

Yes, and that's the gripe with Slack - because it should be IRC underneath, but it isn't. Instead of using an open, standard protocol they fragmented the communications space even further.

But yeah, that's how SV rolls these days. Locking people in.

Slack offers both an IRC and an XMPP interface. I don't think it would be possible to implement all the functionality over IRC. I do agree that the protocol should be an open standard though.

Slack already has the ability to do the opposite: https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...

There's some startups like https://grove.io/ that do it.

I think the biggest problem is the people who use IRC aren't the type of people to pay. Additionally, walled gardens are pretty nice when it comes to making a cohesive experience. As soon as you build on top of something else, you're beholden to its limitations.

Isn't there a more fundamental issue that IRC does not map to Slack? Mentioned over and over, but Slack backlog is crazy useful, and I don't think IRC the protocol has any mapping for that. There's also things like permission sets that don't map 1:1 (but you can find workarounds, of course)

There's also the whole way notifications work... basically Slack and IRC are only the same (or even similar) on an extremely superficial level.

IRC with a bouncer maps to it

I got pointed to irccloud.com the last time I asked about that.

I wish more people _would_ talk about IRCCloud in these threads. They don't have many people working on their product, but they give me hope that someone actually can modernize IRC. Their newly redesigned web UI is now snappier than Slack (on Chrome at least), they support emoji, cmd+k, and image/video/pastebin/gist/tweet/etc embedding. Only real downside is that they're currently developing the ability to search your logs. I know some people using it as a bouncer with their own client, but then taking advantage of mobile clients and push notifications.

Give the people what they want!

> I wish that someone would build an easy-to-use layer on top of an open protocol like IRC or XMPP.

They have: http://getkaiwa.com

Also, Matrix.org

Open, federated protocol, multiple client and server implementations, integrated IRC bridge.

this looks neat, and you can self-host it too.

Can someone explain the attraction that nerds have for Slack/Hipchat over a well-tended IRC server?


See more:







Which is kind of a frustrating answer, because Slack's UX sucks. Its desktop app is just a wrapped web page; the fonts and colors match nobody's operating system; the fffffffffffffffffriendly scroll bar; all the cutesy messages and iconography; "Reconnecting…"; etc, etc.

Yes, I understand that it's still friendlier to use than IRC, but there's a middle ground between "easy to use" and "still looks and works like a proper, professional desktop application." In fact, HipChat is pretty close, even though it's just a wrapped web page too.

It's kind of frustrating to see that all of these Slack alternatives are pretty much taking the same crappy UI cues from Slack. It's kind of like how, until the last few years or so, many common Unix/Linux desktops looked like Win95 rip-offs… You don't need to strive for familiarity if what people are familiar with sucks.

UX is not design. The fonts, colors, and silly features like emoji are gravy.

UX includes the cold experience. If you sign up with just one user, Slack creates a couple rooms and has a bot talk to you.

UX includes history management. Slack makes everything searchable and is good enough that most people can find what they want.

UX includes ways to level up your proficiency with the tool. Slack doesn't force integrations, defaults to 1-click OAuth integrations, and lets you explore writing code to integrate, without getting in your way before you're ready.

I don't think it's perfect, but having recently switched from Hipchat and hated on IRC-for-companies for years, they've done a lot of things right.

To maybe make the distinction clearer: UX and "interaction design" generally are more like what people think of as "game design" than what people think of as "graphic design." They're about choice-paths, affordances, reflexes, flows, etc.

US is also responsiveness and snappy feeling. None of which slack get right at all. The native app is merely a wrapper around their web-view, yet takes around 15 seconds to load. Then eats > 320 Mb of RAM and continues to eat more (it leaks somewhere). The web-app itself is far worse wrt speed and resource-usage.

That is unacceptable, especially when you look at the alternatives it replaces: IRC, XMPP/Jabber and whatnot.

I guess it mostly comes down to Slack choosing the "wrong" stack here: Web-technology is, as is shown quite often, simply not ready for such heavy UX/UIs. Sure, it can be done, but when compared to the simplicity and speed of "native" it simply does not cut it. Yet.

Regardless of which platform you're talking about, the Slack app is emphatically not merely a wrapper around the web view. The resource consumption of their various client interfaces can be improved, but what are you trying to compare it to? In that particular context, a better comparison of any of the Slack client apps (native/web) would be Outlook.

Slack is not replacing IRC or XMPP at all. Slack uses these protocols as part of a groupware suite. As discussed elsewhere in the thread, IRC-at-companies draws mixed reactions. XMPP is a protocol that has seen very wide adoption in the enterprise, with many implementations from a variety of vendors, with a variety of resource consumption issues. XMPP is very much a web technology in the sense you're talking about.

And you are correct that it proved to be a very bad stack for something like Slack, when Google first tried it in 2009: https://en.wikipedia.org/wiki/Apache_Wave

If you really think Slack has made poor technology choices, I'd suggest reading what Stewart had to say on the subject in this interview: http://www.gamasutra.com/view/news/182287/The_story_of_Glitc...

> but what are you trying to compare it to? > In that particular context, a better comparison of any of the Slack client apps (native/web) would be Outlook.

This differs for everyone. For me, it merely replaces XMPP/IRC: group-chat. That is in the last 3 teams where we used slack.

Others, and I guess mostly people who live in their email-inbox, may see Slack as a replacement for their Mail Suite. Again others may see it as a replacement for teleconferencing/skype.

It really depends where you come from. Me, I come from a simple, integrated IRC and XMPP client. Now we all use Slack and I have a poor experience compared to the Just Works[tm] chat (through empathy) on Ubuntu.

* Slack crashes 2, 3 times per week. Mostly memory issues. Empathy never crashed on me, that I can remember.

* Empathy is, AFAIK always on. I switch off Slack when not working because (1) it abuses resources and (2) it addds another icon to my toolbar (empathy integrates in Ubuntu's message icon).

* Empathy starts whenever I start my OS. Slack can be configured to do so. But when it does, its slow startup time and CPU-gobbling while starting makes my desktop appear sluggish.

I'm comparing it to a well integrated, thin and snappy XMPP client, which is what Slack replaces for me. And Slack comes out poor. All over.

Slack's UX is amazing.

What many people seem to miss about Slack, is that it isn't a replacement for IM/IRC. It is a replacement for email. (Email is pretty embedded infrastructure though, so it still exists as a lower layer system protocol.)

The reason the UI design of these tools looks like Slack is because they are trying to get some of Slack's thunder. But the wannabes are making the mistake of copying the UI without trying to copy the UX.

None of your comments about Slack's UX are actually about UX; they're about the UI.

Fair enough. How's this: If the UI of a desktop application does not match the standard appearance and interface of the rest of the operating system, a bad UX is almost a certainty, in my experience.

If I want to share a diagram with Patrick on our internal Slack --- which we set up in under 10 minutes --- I select the diagram on my desktop and drag it into the window for the Slack channel. Everyone on that channel sees the diagram immediately.

I do not give a shit what Slack's buttons look like. I can't do that with IRC. Even if we're all standardized on a modern OSX IRC client, we're still going to end up "sharing" URLs.

Just in case you don't know, several modern IRC clients will automatically fetch links posted in the channel and, if they are images (or even things like YouTube videos), display them inline. I don't know if any of them support automatically converting pasted images to links, though; it sounds sinple enough that I wouldn't be surprised if at least one did.

Of course, what you mentioned is only one of many things that Just Work in Slack and are at best a pain on IRC, but still.

Not all criticisms of Slack are "Use IRC instead!". Albright suggested HipChat as a better example.

I do care what Slack looks like though - the chat window has so much wasted whitespace that it doesn't show a lot of comms; add in a space-guzzling integration or two and it gets really hard to follow a conversation. Hipchat uses space a lot more efficiently.

Again, you can use HipChat and get something closer to the best of both worlds; drag-and-drop file sharing with a standard (well… more standard-ish) OS X interface. It's great for you that look-and-feel isn't so important to you, but it is to a lot of people, and that includes myself.

At any rate, on Slack, I once drag-and-dropped a text file with the output of a shell script that a colleague wanted to see. He started telling me how it was strange that the output seemed to cut off right in the middle of a line. lol, just kidding, Slack was just cutting it off like that, since Slack apparently can't show more than the first few K of a text file for some reason SO WHY IS IT SHOWING IT AT ALL ARGH

I'm sure Slack isn't the best available tool; I just know it's better than IRC.

For every kind of team sysops work I've ever done, I would say that Slack is indeed the best available tool.

Not every organization needs this kind of workflow though, so the best available tool depends on what your organization has to integrate. (Disclosure: I've never tried HipChat.)

How about this: A very strongly worded statement with a huge assumption stating almost certainty, with a small caveat of 'in my experience' allowing me to refute anyone who might spend time listing out all of the examples of how this is wrong.

In MY experience, it is Certainly good UX to not have to learn multiple ways of doing things, one for the in-browser experience, and one for the desktop experience.

I disagree. Microsoft Office hasn't looked like the rest of Windows for years. iTunes looks unlike any other OS X app. Photoshop has never used native UI. Non-native UI can be done very well as long as it's not entirely foreign, or an uncanny emulation of almost-native.

How odd that you used three applications with widely despised UIs as your examples.

You're saying: the efficacy of a UX can be predicted entirely by the UI's adherence to other UI.

Which is also an erroneous statement. I use vi(m) on OSX. vi's UI "does not match the standard appearance and interface of the rest of the operating system."

Thus, I predict that VI has a horrible UX. However, I am incorrect.

Why is this so?

"Proper, professional.." And what does that exactly mean? Beige isn't necessary to be professional. There are plenty of 'proper, professional' applications that have a horrible UX and an ugly UI. Not sure who the arbiter of 'professionalism' is. Is there an ISO spec to which we can refer? Or do we just find the guy who is still using MS DOS and ask for his advice? I'm stumped on how to uglify Slack enough to have it beknighted as 'proper and professional.'

True. But that's my personal problem with Slack, and I guess that of many others too - Slack could be just as awesome as it is if it used IRC on the backend. Instead, it just fragments the already shredded realtime communications infrastructure. For me, this smells of a typical SV startup that tries to "disrupt" something by locking people in and then extracting value out of them before eventually getting acquihired and hanging them out to dry. As it is now, the success of Slack and HipChat is a danger to communication on the Internet.

...except irssi and WeeChat offer substantially better UX*

* personal opinion, yes, but it seems quite obviously true.

Well not sure if there are enough repeated UX-es in there. If there would be, maybe 5 more, I'd be convinced, but so far not really.

UXUXUX... is also a feature of many open source alternatives.

You mean "Lets clone Slack's UI and say 'look we are just as good at UX as Slack!'"

This is the part where you offer a few links to alternatives and demonstrate why said "open source alternative" meets that requirement.

Otherwise, you have a noisy and unhelpful comment.

A well administered IRC channel has all of those, though typically you farm out to an image hoster for the pasting of images.

So we're hiring an IRC administrator now?

Hey. They're the only ones who can dish out k-lines!

How about searching message history? Notifications when you aren't at your computer? Where's the mobile client with push notifications?

It's amazing to me that people still don't understand the importance of user experience (and low friction setup processes).

Do you remember having to hand write your Xorg.conf files to setup a Linux desktop back in the day? Wasn't that a colossal waste of time? Aren't you glad that's not a thing anymore?

Sure, I could try to set up an IRC server and the relevant bots and scripts to attempt to emulate what Slack provides natively, and then look for mobile apps that will connect to IRC and send me push notifications on relevant activity, or I could just use Slack.

Exactly it. I don't have time to manage an IRC server. I don't have time to help people figure out IRC when they first join the team. I also don't want to waste time on something that adds zero value to the products we're building. I use Slack for the same reason I own a dishwasher. I could hand wash dishes and it might even be slightly better, but then I'm spending time washing dishes rather than using the time for higher value activities.

This rubbish about people worrying about Slack having access to your internal communications is just that -- rubbish. It's paranoid nonsense. The last thing anyone at Slack wants to do is read through 80 million lines of emojis and notifications and some private conversation about adding a counter cache to the Products table.

Slack itself probably doesn't care. What about the company that aquires them? What about the companies that will buy that data from them?

And obviously one doesn't actually "read" the conversations, we're not in the 80s anymore, we have software to identify the juicy bits.

Do you encrypt your email? Do all of your recipients?

Slack is sold as a replacement for email, in many cases - so I fail to see how it's any worse than sending unencrypted emails all over the interwebs.

And this tin-foil hat conspiracy insanity about how you shouldn't use external services like Gmail, or Slack because "Oh noes, they have our data" is just that - insanity.

Sure, if you're paranoid, you're free not to use those services.

But let's be honest, most of aren't working at Lockheed Martin, or the NSA. Our personal lives are inane and boring, and the majority of our work discussions are probably, outside of the context of our work groups, inanely boring as well. Nobody cares (which is fine).

On the list of things to worry about, from meteorite strikes to global warming, I'd put, my chat provider trawling through my personal chats fairly low on the list.

> Can someone explain the attraction that nerds have for Slack/Hipchat over a well-tended IRC server?

1. Nerds (like me) have to talk to non-nerds.

2. Nerds (unlike me, but not unlike my wife) aren't interested in complex solutions to simple problems.

And frankly, who is the "tender" of the "well-tended" IRC server? I don't want to maintain it.

My wife and I used slack as the primary means with which we communicate for "couple stuff." We've used it to: Plan our Wedding Ceremony. Plan our Wedding Party. Plan our Honeymoon. Plan for our first child. Plan our next house purchase. Manage our Finances. Plan Dates. Plan our Meals. Archive Recipes.

There would be no way my wife (a nerd) and I (a different type of nerd) could do this on IRC.

Interesting, because my wife (non-tech, but still nerdy EE) and I communicate a lot via IRC! I've never used Slack, but my assumption is that it's ephemeral messaging at the core. Could you expand on how you archive recipes?

I should probably expand that IRC for us is pretty stateful, since we both run our own irssi instances in screen on a VPS.

Ah, we just have a channel called "recipes" which we post links to. Search works pretty well to find them.

Admission: my wife is pregnant, so she really only wants me to make one thing. http://www.epicurious.com/recipes/food/views/corn-and-lobste...

Slack's design is exactly the opposite of ephemeral. Everything you post, including documents, is indexed and searchable.

Ok, that makes more sense. I had something like Skype in mind... in theory I have my entire Skype history, but going back more than 100 lines or so is cumbersome. I'd rather teach my wife how to grep logs than to deal with that.

Is the archive permanent or is it going to fall off the end of the earth? It sounds like a great replacement for PushBullet+Hangouts+Email.

For free accounts, I believe only the latest 10k messages are searchable. For $6 pp/month you can fully searchable unlimited messages.

Also Slack gives you $25 in credit for each person you add.

The second part of your question is a big part of the answer...an IRC server needs to be well tended in order to support the features that people want. I run a Technical Operations (DevOps, SysEng, whatever you want to call it) team...the last thing I want them spending their time doing is futzing with IRC software when there is a solution that takes 5 minutes to set up and is ready to go. Businesses should focus on their core competencies.

For me, the biggest problem was when my computer was turned off overnight, I had to go to some external source to read the transcript of the conversations that transpired rather than having it available immediately, in my application. DMs can also be sent when the user is offline, which is great for "hey, get back to me when you're back on."

I was able to solve some of these issues by setting up my own Quassel or ZNC server, but these were hacks and the clients were no where near as refined as Slack or HipChat.

Where I work, before Slack, we had Campfire and only us developers bothered to sign up for it, get the client, etc. We switched to Slack and suddenly everyone was on it. UX matters so much. We don't have time to tend an IRC server and act as support for it. Slack lets the whole company sign up ultra-easily and get on board – there's simply no contest.

I lament the passing of the age of new open protocols too, trust me, I really do. But IRC+ecosystem just isn't that good these days, and getting stuff done matters more.

I'd argue there's little reason one of the chat clones couldn't be backed by an IRC server and give us a similar experience.

Sure, but getting there takes a lot of work, something that Slack already gives you out of the box.

IRC generally means more futzing around than Slack and Hipchat. It's just a normal value proposition, like not growing our own food or making our own clothes or building our own cars, even if those things are possible.

For us, it's the difference between only developers using chat and the whole company using chat.

Sounds like a good reason to keep using IRC amirite?

Ad hominems aside, personally I like the multi-line block code pastes, the inline markdown, and the ability to post images from the clipboard.

I haven't frequented IRC much since the mid to late 90's so perhaps it has those features now.

So surprising more people don't mention multi-line messages (whether code blocks or not). IRC doesn't have this because the protocol itself simply doesn't support it.

The standard answer is "pastebin" but that raises the barrier to entry, so to speak. We use Hipchat at work but I assume Slack has feature parity here: If I want to paste a code block to discuss, I literally press paste (ctrl+v) and send (enter). The first few lines show up for everybody, with an "expand" button so they can see the whole thing.

No one has to have a specific client, no one has to visit a separate website (including me). It. Just. Works.

Same goes for images, by the way: I can post a URL ending in jpg/png/gif and it shows up for everybody, inline (and intelligently: resized, and animated gifs are hidden by default). I can also screenshot an image and paste it into chat, and it automatically converts to an uploaded file: take screenshot, press ctrl+v, enter, image is there.

IRC simply lacks important desirable features, making it poor for community building (given the existence of better alternatives). The two biggest missing features are persistence and search.

Other important missing features are ease of use in terms of creation of topic-focused channels, private channels, and high quality mobile and desktop clients.

> IRC simply lacks important desirable features, making it poor for community building (given the existence of better alternatives). The two biggest missing features are persistence and search.

A channel stays a channel until nobody's in it. It's trivial to make a bot that sits in a channel and logs it. And it's trivial to hook up a search engine to that bot.

> Other important missing features are ease of use in terms of creation of topic-focused channels, private channels, and high quality mobile and desktop clients.

Like on freenode #reprap , #3dscanning , and thousands of other topic based channels?

And setting private bit is easy as a channel operator to limit who shows up.

And with completely public and open protocols, anyone can make an awesome IRC client. I have one already on my phone.

And there's also bots that can store and send files via http or ftp. I could also make one that saves/retrieves via Box, Dropbox, or any other storage medium trivially. Node-red makes that easy.

> It's trivial to make a bot that sits in a channel and logs it. And it's trivial to hook up a search engine to that bot.

I have actually done that, and I know it's not trivial.

Few want to spend time tinkering with bots and hooking together archiving services. They want a nice Slack-type experience.

Well. Words are cheap. I do appreciate CDRdude speaking up for me.

Here you go. http://webchat.freenode.net room #hntesting

Files end up on Dropbox here: https://www.dropbox.com/s/ukffgmwntypfg4m/ircchatlog.txt?dl=...

Searching wouldn't be too difficult. That's just loading the data up in a Hadoop and then regurgitating it. The only 'doop cluster I have now is a semi-production one. Working on getting a 150 node set up at the hackerspace.


Edit: Added time date stamps, and indication/handling for private messages to the bot.

Privs now allow me to extend the functionality of the bot to do all sorts of things, like upload to MongoDB, email all logs, kick users, save to BOX, or manipulate the neopixel strip in my room.

Let me know how I can do that just by signing up, because my my job is to work on company problems, not emulate Slack in IRC all day long.

No matter how much you push and say that everything Slack offers is doable in IRC, doesn't change the fact that you still have to go through the troubles of setting that stuff up.

While I agree that setting up a bot isn't hard, I've done it for the IRC channel I created and still sit in daily, but fact of the matter is Slack is a matter of signing up and enabling a couple of features.

My job for my company is to build our product, not an internal chat tool. That's what Slack is for.

Oh please. The tools I use rapidly allow me to chain all sorts of stuff together to create things that surpass even Slack and other apps.

Where is a Slack that can do "sensitivity calculation" to alert users of possibly hostile tone? That's right. Not created yet. Give me a half hour and I could have the beginning of that. I also could get translation facilities built in so that English/French/German/Spanish could be seamlessly translatable.

The sky's the limit. And your negativity diminishes your ideas.

Yeah, I had that mentality once. "Why should I use 3rd party stuff when I am a developer and can do it all myself?!?!" Then I realized I was wasting time working on stuff that don't matter, instead of working on stuff that mattered.

If that's your thing, that's your thing and go do it. But it's not a lot of peoples, and that's why Slack is so popular.

> "Why should I use 3rd party stuff when I am a developer and can do it all myself?!?!"

But that's not what I'm doing.

Company A does really good semantic analysis. Company B does chat, say Slack. Company C file storage. Company D does search.

Now, I'm spinning up or using a current server. In this case, lets do IRC to Company Chat, B (bidi bridge). I connect to Company B with my user, and a user on IRC. Logging is turned on and saved, to Company C.

Whenever messages are sent, they are run through API from company A, checking semantics and feel. Score applied personally to help devs be more humane.

While all this is happening, search D is going through files presented and making a searchable DB of date/time, channel, user, and text.

And, I just created a new product.

> And, I just created a new product.

That's exactly the point. Is this what your day job is paying you to do?

If he's a sysadmin then yes. What he described is setting up communications infrastructure.

Someone set up Slack for the company. The same person could have set up an internal IRC server.

I do a great deal of R&D and work with emerging technologies.

I'm also one of the leads for IoT rollout. In essence, I look at many sectors and areas at the same time, and determine how it can be used in our org.

I was looking at message passing using IRC as a form of command and control. The hackers have used it successfully for controlling a force of DDoS clients; why not a server farm? I know that Ansible, chef, and others exist. But IRC is human readable, meaning status messages can be passively read.

Pretty much, I have a dream job. I can get funding for pretty much anything I want, have access to petabyte FS, access to 3 supers(HPC, not clusters), multiple clusters, and more. And then I'm asked, "what can you make with that?"

You learn quick in those situations.

You know that you can write bots for Slack just like you can write bots for IRC, right? This isn't a point on the side of IRC. Slack starts out with more features, but is just as extensible.

But when I have to pay to play, I'll pass.

It's a fools errand to extend a private platform like Slack. They're already adding IRC features to their system, along with running a modified IRC bouncer.

Why play catch-up or copy-target when I can just use IRC directly?

Hell, I could do what they're doing for $1/user/month just by hooking a RADIUS server up to my nickserv. Easy peasy.

It certainly wouldn't be trivial for me, but I can't discount kefka saying it's trivial. There are lots of developers better than I am, and their trivial tasks are my extremely difficult challenges.

I just did it :)

Come to https://webchat.freenode.net/ room #hntesting

I'm kefka, and my bot is hn_kefka_bot talk and PM, and then check the Dropbox log.

> making it poor for community building

eh... slack has consistently said that large communities shouldn't use its services. - http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...

Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem, and there is quite a few high quality mobile and desktop clients for IRC.

> slack has consistently said that large communities shouldn't use its services

Apart from the tech problems with 1000+ sized teams, it's insane even considering the free tier with a 10'000 message limitation for 8000+ users.

Our company (a three-letter megacorp) uses Slack with a 1000+-sized team just fine. However, that "team" represents our whole division; there are then hundreds of channels within it for different individual teams, prefixed with department names. Thus, no individual channel (#dept-team) has more than ~100 subscribers. Slack scales just fine when run this way.

So the team size isn't itself the problem; instead, it's the idea of wanting 8000 active subscribers in the same single channel that doesn't scale. Doesn't work on Slack; doesn't work on IRC, either.

At the scale of 8000 "viewers", you need the sort of specialized "presentation" software used for managing MOOC lectures and corporate shareholder calls, with fan-out servers, voting indicators, and the ability to "raise your hand" to ask the presiding officer to grant you a temporary +v.

> eh... slack has consistently said that large communities shouldn't use its services.

That has nothing to do with Slack-like apps, and everything to do with Slack.

> Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem

I am part of many FOSS communities on IRC. None of them have "fixed" that problem. There might be one or two that archive the channel somewhere. That is no substitute for real in-app persistence and search.

http://eavesdrop.openstack.org - all channels, all meetings, in a nice index and searchable format (i.e. google search with site:http://eavesdrop.openstack.org <query>)

There is a reason slack has a problem with that - scaling is hard.

There is also the advantage of not having silos - if I have a problem with a dependant library I can "/j #libname" and ask a question, instead of searching for what slack, or slack like tool they use, signing up, installing whatever app is needed to access it, and asking the question (and remembering what app they used, so I can keep it open for issues that run over a few days.)

Frankly, itistoday2 is right - the fact that I have to open an external website and open the multiple pages for the days I've been away, instead of simply scrolling up and continuing the discussion, makes for a terrible experience.

Detachable screen sessions make up somewhat for it, but they're still pretty limited (you might have /joined the channel only later), and it requires a personal service running, that must be attended to & etc.

> The two biggest missing features are persistence and search.

A well-tended IRC server has those via bots.

Other important missing features are ease of use in terms of creation of

> topic-focused channels

wut? This is totally easy in IRC: /join #topic-channel makes the channel

> private channels

I'm tempted to say that a bot can provide that... but sure.

> and high quality mobile and desktop clients.

Not buying that, sorry, I've been happy with my mobile/desktop clients; they are relatively full-featured.

Does your mobile IRC client notify you (push message) when you're mentioned or receive a private message, but only when you're idle or offline on your desktop client?

yes. and it is consistently faster than slacks push notifications.

Honest question: Which client would that be? I'm looking for a solution myself.

I looked in to it after that answer. Colloquy[1] was the top hit for my search, and yeah, it does it, but (of course) you've got to have a bouncer[2] running all the time and connected to any channels you want to monitor. Probably pretty nice once it's set up, assuming there's a way to run it on a cheap VM or Raspi or something rather than your workstation or laptop. Looks like their mobile client attempts to register its device ID with bouncers in a channel when it connects, so that's automatic. Not exactly a competitor with what Slack and similar are doing—not having to set up and manage this sort of thing to achieve those services' features is exactly why people pay them—but seems like a nice solution if you prefer IRC.

[1] http://colloquy.info [2] http://colloquy.mobi/bouncers.html

> The two biggest missing features are persistence and search.

At very least for the persistence part, there is a proposal to add CHATHISTORY batch type[1] to IRCv3 which should allow the server to replay chat history on join (or on request). Search is something else that probably need a little bit more work (especially for a server-side search), though.

[1]: https://github.com/ircv3/ircv3-specifications/pull/156

Not a single one with end to end encrypted DM's...

I use mumble for voice (encrypted to server, server is weakpoint), irc for chat on open networks (do it from a VPS, and use screen/tmux with irssi/emacs-erc for persistence), and am using bitmessage more and more. Haven't tried tor chat yet.

Tried Slack, and even for business purposes, adoption was horrible and it ended up being a wasteland. Honestly, I think this statement from the Slack twitter sums it up: "The idea is to have a public-facing channel that a user can participate in without being a team member!"

To me, webchat plugins for IRC accomplish this just fine, and to me, is more likely to get a user directly connected with a dev/engineer.

Maybe I'm just a leftover of the 90's though... I mean usenet is disappearing so fast, even though I still love it... but as a FOSS proponent, I will use a GPL product over proprietary even if it's harder, unless absolutely necessary.

Please, add ours: https://actor.im We also have Layer-like SDK for building your own mobile chat applications

Sure. We'll post a followup review with some of the ones we missed (including Matrix and Kaiwa).

Well there's part of the problem. "Should I use Slack or this long list of open source options, all trickily alike?"

The open source team (which I would prefer to win) would do much better if their message was "use this one, canonical, excellent option."

You say that like there's not fragmentation on the closed-source side as well, with Slack, Hipchat, Skype, etc.

The reason there's competition is because ~"let's only field one perfect option" sounds great if you think you're the one with the perfect product, or you're a user whose needs are exactly like that product's pitch. In reality, user needs are diverse: there's no singular perfect product.

In general you're totally right!

In this particular case though, note the title of the article. Wouldn't it be much more convincing as "A Superior Alternative to Slack (Which Happens to be Open Source)"?

EDIT: You're second point definitely does apply here though.

I think it should absolutely be noted that being open source is a key mark of superiority over Slack.

Realistically Slack's market share of the "IM technologies used by teams" world isn't that high anyway. I'm willing to bet that they remain well behind IRC even in their own market.

All of this is a response mostly to buzz. Slack looks great, and is absolutely popular. So we (the open source community) want something "equivalently buzzworthy" while forgetting that we are, in fact, the entrenched monopoly already.

I'm not losing much sleep, nor will I be retiring my IRC client or pastebin links any time soon.

for bunch of more alternatives, see https://github.com/cjbarber/hipchat-alternatives

I'm seeing "No e2e encrypted DMs" as one of the cons for most of these.. anyone have a solution?

The matrix[1] team is working on an axolotl implementation meant to be used pluggably: https://matrix.org/git/olm/


[1] https://matrix.org/

I searched for axolotl and got some cute pictures but not much information. Why this thing rather than OTR?

OTR has some major shortcomings - in the classic implementation, it doesn't do group chat and it requires both parties to be online at the same time to synchronise the cryptographic ratchet. The best explanation of why Axolotl is better is https://whispersystems.org/blog/advanced-ratcheting - or if you prefer a more comprehensive spec, we've published one at https://matrix.org/docs/spec/olm.html.

Anyone wanting to know more about Olm & Matrix's Axolotl support might be interested to flip to the end of https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E...

(p.s. hi!)

Hi indeed.

Are there any plans for formal standardisation, review or the like? The docs look cool but at this point I'm suspicious of any single-vendor cryptography.

yup, we will get it properly reviewed once complete.

There's just an inherent conflict there, because your DMs are indexed+searchable just like any other message, and really, you want them that way.

The only obvious solution, right now, is running your own private server if you want private indexes.

But the One True Way to solve this problem, in the fullness of time, is for every enterprise to run their own little PaaS with a standard API, and for SaaS providers to launch their app instances into the enterprise's PaaS using that API. This would be the cloud equivalent of the SaaS-provider selling the enterprise an "appliance" they can keep within their data-center. The enterprise gets full control of the data: their PaaS can be set up to not allow the SaaS-provider any way to exfiltrate the data the app creates, to determine rollout schedule for new app versions, etc.

(And note that when I say "enterprise", I could just as well mean that any individual user could own their own completely-automated black-box micro-PaaS, living "across" various IaaS providers and migrating to new ones as necessary, brought into existence for them by the first SaaS vendor to try launching something into it. Effectively, the ultimate evolution of a personal VPS, providing you with a "management interface" that looks like a cross between Heroku's dashboard and the Windows "Programs and Features" pane.)

For the usecase I see these to be useful, I don't see lack of e2e such a huge concern. I would assume that in most cases the server would be more or less trusted in the context they are used in, so TLS style client-server security would be adequate.

In other words, if I really wanted to have discussion secret enough to warrant e2e I probably wouldn't be using company/project chat for that no matter what sort of promises it gives.

That being said, of course e2e chat would be beneficial addition, and might help especially in larger enterprise deployments.

For less important things, I agree, run of the mill TLS is enough. But for things that are critical to the business, trade secrets, strategy, SWOT analysis of a recent breach, etc, I think every company should have an e2ee chat/file sharing app in their toolkit.

>if I really wanted to have discussion secret enough to warrant e2e I probably wouldn't be using company/project chat for that no matter what sort of promises it gives.

Why not, though? Assuming logging is disabled by both parties and the E2E is working as intended, you have something that's almost as secure as in-person conversation. The only weakness is if someone has malware actively on their machine recording the conversation as it's occurring... but then you also have many other issues.

Maybe give balboa.io a try, it's the closest I can think of. Not just DMs but also file storage and transfer. Kind of similar UI to slack.

Also, peerio.com, but they don't have a 'channels-like' interface, so maybe not what you're looking for.

The ones that support XMPP can probably have an OTR plugin built for them. Might be able to develop an Axolotl plugin too.

Does Slack even have e2e encryption?

Rocket.Chat does have an open issue with discussion about this: https://github.com/RocketChat/Rocket.Chat/issues/36

Mattermost has the advantage of being bundled with GitLab, so organisations opting for GitLab might be tempted to use it as well.

Also Potato, which me and a few friends have been developing for our own use for a while. It will be released as open source soon.

I will make a separate post once the source is released, but for now anyone that is interested can take a look at a small demo system I set up here: http://potato.dhsdevelopments.com/

The server is written in Common Lisp, client in Clojurescript. Storage backend uses CouchDB, messaging using RabbitMQ and the search uses Solr. More technical details here: http://blog.potato.network/

I wasn't sure when I read the headline if it referred to Slack Linux or Slack the music service. Apparently there is a communications client called Slack, just FYI.

Those other things aren't called Slack, though. Those are Slackware and Slack-time.

Kudos to author for including sandstorm.io and docker in his pros and cons. I can see it becoming one of the first things we might wonder about in the future.

Is it really open source in spirit if message auth relies on a hosted, closed source, proprietary application like github?

I was recently at a small development studio that closed down. We used slack to communicate and liked it. I set up an alumni team and the whole team joined up to keep in touch and it's still active months later.

Is anyone going to argue that if I'd sent out the irc channel that anyone would have tried to connect?

Why wouldn't they?

Because I worked with people with varying levels of technical ability. Slack is so much easier to setup and get everyone to use than irc.

The thing that keeps my company from switching to Slack or any of its alternatives is read notifications. Not having read notifications makes using the system a lot more painful. Any one know of a chat system (not Hangouts) that supports read notifications?

Slack says it's coming, but no idea when: https://twitter.com/slackhq/status/504407968150851585

Slack has some major design flaws. It's not developer-friendly either. I really don't get why hackers are not pushing for Gitter! It has SSO, it's developer-friendly, it's cheaper, it's embeddable, etc.

From one closed source system to the next.

True, it's just that Gitter is so much better for development. Yet, developers are still pushing Slack.

Anyway, wasn't Gitter open-source in the beginning though [0]?

[0] https://github.com/gitter/gitter

I find it curious that having a pure JavaScript implementation including the backend is listed as an advantage.

That's not listed as an advantage - just highlighting the technology.

My bad. I conflated the technology and pros section in my mind.

rocket.chat seems pretty cool. Just signed up however so I will have to dig deeper. Nice.

Rocket.Chat allows you to deploy your own instance https://[my_instance].rocket.chat if you go to https://rocket.chat/deploy. [disclaimer; I contribute to Rocket.Chat]

Could give yammer a chance. Not open but their freemium model is much better than slacks

Why not just use e-mail mailing lists instead?

You get great apps for all devices (e-mail clients), notifications, encrypted direct messages, ability to send images/binaries/whatever, threaded communication, search, censorship resistance, filters, etc.

I imagine most people use both [a combination of chat and email].

Real time chat channels are much better for fast moving ephemeral discussions and neither would I want that sort of thing in my inbox.

Even in the late 90s when we had IRC, ICQ, and AIM for realtime chats.

In 2015, it's trendy to use things that aren't email.

That hardly started happening just now in 2015. I absolutely loathe using email, but I don't speak for everyone.

Why is this even an issue? Slack has nailed team chat. Slack is easy to use, they have a free plan. If you want the premium features, their pricing is very affordable. Can we stop re-inventing the wheel, just because engineers don't want to pay for software. This is the fundamental difference between founders+engineer/engineer.

"While Slack offers many benefits to customers, there are also downsides to using the platform, including high subscription fees and the risk of a massive leak of private data if Slack’s servers are ever breached (again)."

Not everybody wants to pay to put their potentially sensitive data onto somebody else's systems, where they can't control the security of that data.

The one thing in terms of security that is even a blip on my radar is that slack does not encrypt data at rest (disks). [1](https://twitter.com/slackhq/status/467476452364279808)

Their reason that they couldn't search through data if it were encrypted is not true. They are using AWS, and can simply use EBS encrypted volumes (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryp...). Should be an easy flag to turn on.

The only thing that's on your radar. Do you speak for everyone else's needs or interests?

Not sure what exactly that buys in terms of security.

Both Slack and Amazon can steal all the data without being detected, regardless of whether the servers are encrypting it or not, since if the server can decrypt it, so can Amazon (just scan VM memory for the key from the hypervisor).

Slack itself was reinventing the wheel, so it's pretty hypocritical to bash others for doing likewise. Also, the OP gave some pretty good reasons why relying on an external proprietary service might be a bad idea. If you're happy with Slack that's great, but that's no excuse for being so gratuitously negative about alternatives.

It is a closed source proprietary software that requires to give up all your secrets to an unknown third party, and also pay per user for some of the features (and thus an unlimited amount if users are not employees).

Their ToS is also as abusive as it can possibly be, trying to take away your right to sue them in favor of arbitration (!), allowing them to terminate your service at any time, send your data to anyone unencrypted, disclaiming all liabilities and warranties, disallowing any content that is "objectionable", etc.

I don't think price is most people's problems. I think usually it's just

1. they don't want to depend on a third party's existence. If Slack Inc. goes under or gets sold to eBay, the team won't have Slack anymore, and

2. they want privacy. They don't want conversations being watched or sold, especially to competitors.

I'm pretty sure that's all it is. Someone correct me if I'm wrong though please.

Well, it's interesting that anyone would be concerned about (1) meanwhile probably 99% of open source projects use e.g. github, bitbucket, gmail, etc...

If it's an open source project then shouldn't everything be out in the open anyways? If that's not the case then it implies it's a private project in which case there should be a budget...

Maybe Im wrong though?

> If you want the premium features, their pricing is very affordable.

"very affordable" is up to each person to define. One of those premium features is a history with more than 10,000 messages.

I frequently interact with at least 25 people just to do my job. The cheapest paid plan is $6.67 per user per month. That works out to $2000 a year. And that's only for the people I work with on a regular basis. Sure, I could afford that, but it's certainly not trivial. Email looks like a good alternative at that price.

$6.67/month is less than $0.33/day (~20 workdays/month)!

That's an trivial amount to pay for effective communications in my book.

$0.00/forever is also trivial, with so many OSS alternatives out there.

How much time do you have to spend setting it up, maintaining it, documenting your set up, etc? While OSS has no upfront costs, it does cost in terms of dev and admin time.

You pay that for every Slack user, no matter how many or few messages you exchange with them. I don't think someone else is going to pay $6.67 to replace ten email messages.

"I frequently interact with at least 25 people just to do my job"

Frequently, not ten messages in total.

Email works fine for non important sporadic communication.

I'm a member of community Slack rooms with hundreds of people. It would cost thousands of dollars a month to switch to paid accounts. That's way too high for volunteer open source projects to pay.

Iteration is how software moves forward.

If slack didn't "re-invent" IRC, it wouldn't exist.

Also, not everyone is comfortable having data exist on a 3rd party system, that they have no audit access to. This is the fundamental difference between "founders" and people who know how systems work.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact