Mattermost 1.0 released – open-source Slack alternative | Hacker News Reader

Mattermost 1.0 released – open-source Slack alternative

mattermost.org

332 pointsshuoli84136 comments

http://getkaiwa.com/ is another Slack alternative that uses an XMPP backend, which IMO is much better than a custom backend. So far the only open source Slack clone I've seen that uses an existing standard for the backend

I'd rather have it the other way around: start from a solution that works (like Mattermost) and progressively plug XMPP into it. Mattermost and its friends have the huge advantage of having everything built-in and well working together, and if you take a good look at it XMPP should be more like a "compatibility protocol" on top of a working solution.

Mattermost v1.1 (ships Oct 16) has incoming webhooks support with samples (www.mattermost.org/webhooks/), and we're planning outgoing webhooks v1.2 (Nov 16), which provides the ground work for XMPP

Community has asked this for a while, we want to build an effective, well documented API to let the community create what they want: http://mattermost.uservoice.com/forums/306457-general/sugges...

https://github.com/sdelements/lets-chat is open source and supports XMPP as well. Tried it, it's very slick.

https://rocket.chat/ built with Meteor and with WebRTC videocalls, is another great open source alternative... The list of current and upcoming features is quite impressive:

https://github.com/RocketChat/Rocket.Chat#features

There are a slew of developers who tangled with XMPP and came away with very negative, well-founded reasons to dislike the protocol. Do you want XMPP because it is a standard, or you also have a contrary experience to these developers?

[1] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber

[2] http://josephg.com/blog/xmpp-in-wave-in-a-box/

[3] https://news.ycombinator.com/item?id=2069810

[4] https://www.reddit.com/comments/rvzdp

[5] https://news.ycombinator.com/item?id=10040302

For some balance, there are contrary opinions. This one seems to revolve around project governance.

[6] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber

And links [4] and [5] have a lot of people piping up saying they like XMPP just fine.

To be fair to XMPP, I strongly suspect it is a protocol trying to solve a very large, very messy problem space, and too many developers are trying to wrestle with it "raw" in its totality, unaware that for their specific problem domain, they only need a subset, and a specialized protocol/library that exposes only that subset to them. It's almost as if too few understand that XMPP is kind of the assembly language (or microcode?) of its problem domain, and most people need a $High_Level_Language_of_Choice instead.

I just like jabber because it's a standard. I have an app on my phone that'll do Jabber already. There's a lot of server software already out there to host Jabber, it's pretty robust, all we need is a reasonable frontend for desktop

The counter to that—and no doubt a factor for many like Slack—is that when you use a custom protocol/API you get to control the whole experience. You don't have to deal with bugs in third-party clients, wait for clients to get emoji support, and can control the look-and-feel (many of the Jabber apps I've seen aren't great).

This is obviously not ideal for everyone, but I suspect that outside of tech that using a custom client is possibly even a plus.

Here's another one: http://about.jabbr.net/ but for the Windows / Azure / AppHarbor platforms.

There's a lot of standards out there. Open is better than closed, and standard is better than ad hoc, yes...but that doesn't mean XMPP is automatically the best solution.

I'd honestly be more interested in seeing Mattermost try and write a really solid solution, and then work to standardise their protocol.

This is great. Also see: https://zulip.org

And the blog on why Dropbox decided to OSS it:

https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a...

> Every conversation in Zulip has a topic, so it’s easy to keep conversations straight.

Threads! Hooray.

Also my biggest feature request.

I tweeted it at Slack and they seemed surprised actually. (I didn't get the vibe like they're shipping it anytime soon.)

Props for open-sourcing, but I'm putting my money on http://matrix.org/

Matrix does look awesome.

There's also "friends": http://moose-team.github.io/friends/

So, open source version of the original Skype architecture but using web standards?

It's good to have options.

The takeaway I'm getting from this story, and Mattermost, is: 1. Export your critical data from SaaS services if you're business cannot exists without them. 2. Test that this works before putting years of data into a service.

There's nothing wrong with SaaS services, they just mean users must do their due diligence in any business partnership. I can't see how a game company can put their resources into delivering this as an open source project with no future plans for monetization. Frankly, without monetization, open source projects generally wither up and disappear. Then you're no further ahead.

http://www.mattermost.org/why-we-made-mattermost-an-open-sou...

I'm really hoping they charge for a hosted option? It would make sense.

>Export your critical data from SaaS services if you're business cannot exists without them

You know, my thinking on this has really changed. Consider how many relatively successful life-forms cannot exist without a very specific other species of life. It is also a good strategy to be flexible with your dependencies - but I think nature proves it's not required to survive and thrive.

Taking the long view, it's interesting to consider the possibility (which I'm sure has already happened multiple times in tech and elsewhere) when a company has absorbed it's dependency, and also when a dependency absorbs what was, at first, it's host, and successfully so.

The one thing that throws a monkey wrench into all of this is centralized human control, and a single mind is notoriously ephemeral, changing, and emotional. The CEO of your dependency might wake up one day from a terrible dream of humiliation and failure, and decide that he can't and won't just exist to serve his wretched, ungrateful customers in some insignificant and petty way, and will instead take a completely different path! (This risk is why greedy sociopaths make excellent corporate leaders: their drives are stable, predictable and unemotional, which makes them both competent and, ironically, safe.)

> Consider how many relatively successful life-forms cannot exist without a very specific other species of life.

Let's ignore how "many relatively successful [extant] life-forms" versus the ones that had "evolutionary challenges." There is an enormous difference between a species survival depending on the existence of a prey species and a species survival depending upon the existence of another species for uninterrupted, cooperative and coordinated behavior. Your relation to your SaaS provider is not similar to the blue whale's relationship with krill, it is more like the goby and the shrimp.

Why do I have to go to slack.com to learn what this is?

I clicked on this link, no explanation. I checked mattermost.org, no explanation. I went to slack.com, no explanation. Then I clicked on a "Product" link on top of the webpage. Finally some information what this actually is.

Even open source projects could benefit from a little bit of marketing.

Agree about the Mattermost page, but the first thing I saw on Slack.com was "A messaging app for teams"

This x100

It's marketed as an "open source Slack clone". I suspect that if you don't know what Slack is, you aren't really the target market (at least for this version)

i beg to disagree. i'm in the market for notification, chat, etc. service for an internal application that doesn't have any cloud dependencies and we'd be most happy if it could stay this way. apparently this thing fits the bill at least in some capacity.

Did Apple market the iPhone as "a blackberry with a bigger screen"? No, and by not limiting themselves to an existing competitor's market, they kind of crushed them.

If you don't what Slack is you are not the target audience for this tool, and that's ok.

Everyone saying "If you don't know what Slack is, they're not your target market".

Wrong. Slack has a target market. Mattermost should specify that market, along with its desire to be an open source Slack.

If what you really want is a pretty web-based way to access IRC, then you might want to check out Glowing Bear -- it connects to your WeeChat IRC client via websockets and works nicely on the Desktop and on mobile. It doesn't have a voice recorder, but it gives you the infinite possibilities of a mature IRC client. It's a project I've been contributing to for a while now and I still absolutely love using it.

https://github.com/glowing-bear/glowing-bear https://latest.glowing-bear.org/

It also supports Matrix natively as well as IRC, which almost gives you best of both worlds :) http://matrix.org/blog/project/glowing-bear-weechat-plugin/

Yep! It can do whatever WeeChat can do. Tor, who made the Matrix script for WeeChat, is also one of the core developers of Glowing Bear :)

There was a time when I thought something like this was a good idea. But after using Slack for about a week, there's no way I would give up all the benefits of a well-integrated centrally controlled service. All the clients work together perfectly. We have Slack channels with customers. It just all works much better than I can imagine any self-hosted, decentralized service would.

How a self-hosted service prevents you from having channels with customers or whatever else Slack offers?

The only upside of third-party SaaS is that you don't have to bother yourself to set things up and maintain them. Otherwise, I really don't see any limits that Slack can do but a self-hosted system can't.

I'm involved in a few communities that have slack setups. One of the other nice things that Slack offers is that I only need to have one login to all of them. That's something that none of the self-hosted systems can do right now.

Not sure I understand.

What prevents you from using a same identity to log in to multiple self-hosted instances?

I think it's the same. As far as I get it - haven't used Slack much - with Slack you either have to use different email address to create account for each team (subdomain), or you have to be explicitly invited. Or maybe I got a wrong idea. Either way, while I'm not sure all self-hosted alternatives have options to consume external identities (be it third-party leased ones like Google account or self-originating ones), at least some have those. Which means the authentication is fairly transparent.

I'm talking about using slack as a member of various groups, with very different focuses. The fact that it is centralized means I don't need to have Yet Another Server I have to remember the address to, the username, the password, etc, and enter in on my desktop, my laptop, my mobile, etc. Plus, if one of those decentralized instances has a mobile app, chances are, I'd have to put in configuration info there for each and every service. Self-hosted communications services quickly become a pain in the ass when you end up needing to deal with more than a couple, and sometimes centralizing things a bit is an actual benefit.

You still have to create accounts on all of them. And if you mistype your password on one, you'll have to change it, and either you have to remember that there's one with a changed password, or go and change your password on all of them. And what if someone's taken your regular name on one of them?

That's not really a problem though. Everyone uses 20 different communications platforms. SMS, Hangouts, Hipchat, Slack, Facebook, Twitter, Snapchat, Whatsapp, etc all have different logins.

It may be nice to combine them in one place but it won't prevent anyone from using them.

The problem is, there is no standard for truly owned identities besides usernames and passwords, and those are frowned upon as "different accounts". And many services seem to not want any interoperability at authentication layer and to accept third party (esp. competitors') assertions as credentials.

This applies to Slack too - to best of my knowledge, one can't log in there, using, say, GitHub identity assertion as a credential.

But I'm not sure how Slack has anything to do with this. You're right. They're just a yet another platform with its own non-interoperable account system. Don't see how it's better than anything other, except when everyone is already there, which I find hard to believe. (But any other platform that knows how to consume external credentials is wins in this regard.)

Doesn't prevent it. But since it's sub-optimal, it never happens.

Yeah, but is kind of expensive if you don't live in a developed country. If I lived in the US I would happily pay what they charge, but here in my country I would end up paying almost as much in Slack as in the office rent.

Where are you located? Slack is $7-9/mo a user iirc. Genuinely curious, that seems insanely cheap for rent.

Really? that's cheap for you? that's some thousands a year for any mid-size company. I always saw them as really expensive for something I'm used to get for free. And the paid alternatives like hipchat are like $2/month. I guess it's all a matter of perception.

http://www.npr.org/sections/money/2015/09/23/442921757/episo...

"Thousands a year" is a rounding error for any company that has the 20+ employees it takes to get to "thousands a year" in Slack bills. Those employees are costing tens to hundreds of thousands of dollars per month.

giovannibonetti's employees probably cost him "only" thousands of dollars per month, so his Slack bill would be 1/10th of an employee or so.

I think you are seeing it from the strongly-VC-backed startup perspective. In any company I've worked for that kind of expense needs to be justified. Sure, that's a small fraction compared to salaries, but there will be many such "needs" for many small fractions, and if they are not watched after they add up pretty quickly.

I think you are seeing it from the strongly-VC-backed startup perspective.

I feel I can pretty authoritatively answer "Betcha not" here. </cofounder>

It's trivial to justify Slack's pricetag at any software company. Your entire team lives in it continuously and it becomes the nerve center of the company... for freaking pennies. It's ludicrous. If you add it up the non-Starfighter companies I run spend like $50k a year on SaaS/hosting/etc ("everything with an API attached") of which Slack is like ~1%, and probably the most underpriced-relative-to-value service which does not quote its pricing in picodollars.

Aren't you down to appointreminder.org and Starfighter now? How's the alpha going?

That's how you get bloated budgets. Why spend thousands of dollars per year on a communications platform if you don't need to spend it?

IRC, mattermost, email, Gitlab, Wekan, Skype/Google Hangouts/BigBlueButton.... there are plenty of tools to communicate without spending loads of cash.

why use macs (or Dells) instead of a cheap china-built off-brand PC? Why use fancy Pilot G2s instead of 10/$1 bic pens? Why use ${SuperiorProduct} instead of ${InferiorProduct}? Because it has value outside of the immediate short-term economic value.

Of course, it is always a matter of perceived utility. I buy really nice food sometimes, because my happiness gained from the delicious steak is worth it.

I might hypothetically use an open source tool instead of Slack because it's not worth $2000 of productivity for 15 people per year.

None of those tools work as well as Slack out of the box. Some of them require significant work to integrate with other web services. That's time your staff is spending on those projects rather than your core product.

Seriously, Slack was the EASIEST things to justify as an expense when we proposed it to upper management earlier this year. And they are known to be very stingy.

And they clearly aren't as good, otherwise Slack wouldn't be so popular.

If it is ad-supported it is not free: https://news.ycombinator.com/item?id=7485773

And where can a mid-size company rent an office for only some thousands a year?

I'm located in Brazil. 30 users x $8/user/month x 4 R$/US$ = R$ 960/month (as a ballpark figure, a R$ is worth for a Brazilian about the same as a US$ is worth for an american)

U$ 240 / month is not cheap, and I'd seriously consider an alternative or asking for a discount, but it's nowhere near the price of an office in Sao Paulo or Porto Alegre (I live in Uruguay and was looking for office space in Sao Paulo earlier this year).

If you have to pay for customers, then it's way too expensive.

I've seen a remote-based company put Slack to VERY good use, integrating it very tightly with their development process, I believe it definitely pays itself then.

If it's just a glorified IRC/XMPP, then definitely not.

My first thought was that this is a viable alternative if and only if it were possible to self-host a central server.

I came here to say exactly this. We host a Slack team for local freelancers, and I'm part of a few communities.. and I currently can't imagine me using two different clients for this (2 desktop apps, 2 mobile apps, 2 admin web apps). So, Slack it's gonna be.

Hah. The history repeats.

We had non-interoperable web services, and then businesses offering aggregation of those (like various social media aggregators, or even Slack) had appeared.

Now we have non-interoperable mobile apps.

Maybe then this product isn't for you. Even that's a maybe. Fair to say it's needlessly discouraging.

Somebody made something, and is giving it out for free so that people can learn code, improve it or just use it. They haven't made the claim that this beats Slack today, but with a community of users and developers, it just might. Btw, it can be a success even if it doesn't fully outclass Slack.

Your comment is equally valid for the Linux kernel if it were 1991. Who would use a baby OS when they can get a well rounded commercial OS that crashes less often? Look at where we are now.

Linux kernel is completely different since there is little or no network effect.

You are fine with a commercial US company storing all your communications? I am not.

Yes. I can't imagine living life worrying about something like that.

You can't imagine working a French defence contractor? Or a bank anywhere on earth outside of the US?

Or someone who likes to freely express their political views, maybe even extremist opinions, but still would like to peacefully visit the US as a tourist some day.

I think Slack serves its stated purpose very well (smaller, business oriented teams), but many groups have started using it for larger communities, mostly because it has unlimited users for free. But it isn't made for that and there is no way that most of these groups would ever be able to pay for a premium subscription due to the per-user costs. 10K messages across all channels is surprisingly easy to hit, need the ability to ignore users, etc. I think this project has great potential to fill that niche if it is marketed properly. Slack is so close to working well in that area but really needs to pivot to be able to serve it well and make money doing it.

Yes, recently Slack even told Reactiflux that they need to move to another service as more than a few thousand users can not be handled by the Slack infrastructure.

That isn't true. My office slack has a few thousand users and it works just fine. I'm not saying it can scale to infinity, but it does handle a few thousand users without any issues.

I have no clue what the exact numbers are, but apparently it is an issue:

http://www.reactiflux.com/

I'm trying to decide if this is better than Zulip. They're both open source, backed by someone trusted, and I can run it on my own server.

Let's chat, Zulip, Kaiwa, Mattermost there are probably a hundred more.

Depending on the Scale, I'd personally go with an own Kaiwa Fork, backed by an Erlang MongooseIM Backend and LDAP.

We tried Mattermost at work, and it was pretty terrible. Things like "show new messages" didn't work, which sort of defeats the purpose of a chat app. After that we tried RocketChat, which seems a lot closer to Slack in terms of features and appearance. From our perspective they were just too rough around the edges for functionality, with a lot of things almost-working-but-not-quite. The caveat to all of this is that we wanted something that JustWorks, so while we did put in some effort to fix configuration and even some bugs in the software, we didn't commit to them 100% so YMMV.

We started up on Zulip when it came out a few weeks back, and it's been much better and more consistent. Streams and topics take a while to get used to, but they make it easier to have public conversations with some semblance of organization. If you don't like / can't afford Slack, or if you have privacy needs that make it a non-starter, I would recommend giving Zulip a try.

do you know if Zulip exposes an API ? We are currently using Slack as a chat dashboard for operations .. and we do some funky stuff like create channels,etc through the API. I wonder if Zulip allows that.

They have an API, not sure about channels specifically though.

https://zulip.com/api/

https://zulip.com/api/endpoints/

Channels don't exactly exist, but you can programmatically create topics within streams. Sometimes it gets to be overwhelming, like out GitHub bot that posts every PR for every repo under its own topic within the GitHub stream. It's definitely a new way of thinking about chat, and there's a learning curve of about a week, but so far it's been fantastic.

I've used Slack and HipChat previously, and AFAIK the integration methods are all roughly equivalent - post a message to a URL with a token.

Interesting that it will be a default feature of Gitlab.

That's a move that seems like it may push Gitlab ahead of GitHub in some ways (well, to me at least).

There are many OSS alternatives to Slack. Some are clones and some are different approaches and many of them are quite good.

The thing these and all other similar efforts miss is the importance of network effects. Everyone uses Slack because everyone uses Slack.

The real problem that needs to be tackled is one layer down: providing an open, distributed alternative for authentication, identity management, and data interchange that is secure and robust enough to provide a backplane for things like this and that is easy enough for anyone to use that it can be pushed out to the mass market. I can't stress the last point enough. It must be stupid simple easy to use or it will fail. It also must offer a good and simple developer experience (DX) or it will fail. DX is part of UX. Things like XMPP are nightmares for devs and sysadmins and fail badly here.

This is a huge missing piece of the web.

Well.... this is depressing -

Mattermost server is made available under two separate licensing options:

- Free Software Foundation’s GNU AGPL v.3.0, subject to the exceptions outlined in this policy; or - Commercial licenses available from Mattermost, Inc. by contacting commercial@mattermost.com

"To simplify licensing, we’ve responded to community feedback and the compiled version of Mattermost v1.0 is now under the MIT open source license" (Emphasis mine)

Why just the compiled version?

They also seem to use a hosted JIRA, but restrict some of the tickets from being viewed, and you need an account to file Jira's.

There is also no mention of it in the "getting involved" section, just a link to github issues

This is not how you do open source.

> This is not how you do open source.

Sure, maybe they should have never released this useful software at all. /S

Mattermost started, and is still developed AFAIK, as an internal app from a for-profit company, that they've generalized and started releasing to the community.[1]

Considering that they only just hit 1.0, maybe your tone is a bit harsh compared to their ever-so-slight mis-steps.

Let's be constructive.

1 http://www.mattermost.org/why-we-made-mattermost-an-open-sou...

Why is that depressing?

I guess the compiled version as MIT is to make it easier for people to deploy in enterprises that might have issues with AGPL, given that the consequences of MIT are easier to evaluate.

Since we are talking about open source software, maybe the guys that own the Mattermost account on Github could create a placeholder repo for Android (I wonder if this idea would work for iPhone, too) and accept Pull Requests until there is at least a beta native app.

Would be happy to move over to an open source alternative, but at the moment they don't seem to support mobile apps.

It would be very difficult for us to move because of this, we talk a lot on the move.

I wonder how this compares to Rocket.Chat, another open-source alternative: https://rocket.chat/

Doesn't this have some heavy hardware requirements? Three machines with at least 2 GB of RAM? Is that really necessary if I'm going to chat with five people?

This looks very nice. Is there any plans for an API/client protocol? Web client is all well and good, but I'd want to have a solid console client, as well as some command line tools (eg: "echo "Some message" | xmpp user@host -- where the equivalent for Mattermost would allow to set the topic, or message a group via a bot etc.)?

Thanks e12e!

We're working on shipping a high quality set of APIs. We're doing these in parts so we can design and document them well.

Mattermost v1.1 ships on October 16 and offers incoming webhooks as a start: http://www.mattermost.org/webhooks/

You'll find a link there to an open source sample app for customizing how you want webhook events from GitLab to appear.

Mattermost incoming webhook support ships with GitLab 8.1 on October 22.

For Mattermost v1.2 (November 16), we're working on outgoing webhooks, which could offer the ability to fire off console commands.

Overall I like it because they closely follow Slack's UI. However I question the choice of fully supporting Markdown. A comment isn't supposed to be documentation. Supporting things like bold, italic makes sense for emphasis or making code easier to read. But headings? When would one ever want really large text in a comment?

Perhaps you can submit a pull request disabling the markdown features you don't like

Mattermost team here,

We had dozens of community members upvote a feature to add markdown and we added it because it made sense.

Now we really love it and can't go back: http://www.mattermost.org/open-source-slack-alternative-adop...

Headings have a lot of uses for emphasizing text, and there's fun uses too like creating different sized emoticons: http://www.mattermost.org/wp-content/uploads/2015/09/sheep.p...

##### :sheep:

#### :sheep:

### :sheep:

## :sheep:

# :sheep:

What about text preceded by a # (eg. HTML colors, hash tags, numerals...)? Do you escape # if it's next character is not a whitespace?

Correct, escape if # is not followed by whitespace. Mattermost markdown is based on GitLab Flavored Markdown: https://gitlab.com/gitlab-org/gitlab-ce/blob/6-4-stable/doc/...

> We had dozens of community members upvote a feature to add markdown and we added it because it made sense.

What made sense? Is there a use case that requires full Markdown support? If so, what is it?

I use Slack's 'Posts' feature which is a full Markdown post that you can embed in a chat in Slack.

The reasons I use these are: 1. Rich content, organized & clean lists with outbound links for status updates about things I'm working on, linking to Asana/Github 2. Notes from one on ones, or general progress updates that I keep in a private channel and save basically as a stream-of-consciousness/reality log, having them there makes them readily accessible in product and having them in Markdown makes them very readable when I'm browsing through.

In short, I treat Slack rooms almost like I would treat a folder in Dropbox, they just happen to also include some chat between people :P

Headings don't actually imply really large text. They imply differentiation for different levels of text introducing the following section, which can be useful in similar ways as bold and italic. Most stylesheets for markdown do seem to implement the top couple headings with uncomfortably large text, though, which is a bummer. It would be great to see configurable styles for markdown in tools like this.

In my past job, I was desperately looking to get an open source Slack alternative. The ones I tested then (few months back) didnt hold up nicely against Slack. I'm happy to see that finally there's some good competition.

did you ever come across matrix.org? We are similar to mattermost in that we are open source and you can host your own server.

If it supports SSL XMPP it can be a drop-in replacement for a lot of companies.

Feature idea: a canvas where people could draw instead of typing a text.

The blog post is dated October 2nd; Is HN just learning of this announcement late, or is their blog displaying the draft date rather than the publication date?

So, what does this offer over Slack, besides being open-source? I see no mention of any actual features, besides basic chat features.

open-source, self-hosting, non-english channels, better markdown support. No limits on searching and self-hosting I think are the biggest things.

I've spent a couple of hours trying to get Docker running on my linode Ubuntu server to no avail.

A non-docker implementation would be nice.

I consider myself to be a person of reasonable competence and I find Docker to be confounding.

I have 30 years in IT, my friend who is a sysadmin also tried to get Docker running on my server. He gave up too.

Maybe give CentOS 7 a try? It's literally install the rpm, start the docker service, then run whatever container you want to run.

Ubuntu might be the problem there I'm guessing. On CentOS 7 or Fedora 22/23 it takes less than 15 seconds to install to a complete, working state. Then the command line tools are very basic to work with.

Besides being an excellent application, this is a valuable resource for anyone studying Golang.

Pull requests from Golang community highly appreciated, you can view our process and tickets accepting pull requests at: https://github.com/mattermost/platform/blob/master/doc/devel...

Does anyone know who the old provider was that locked in their data?

Why not just use IRC ?

Because this is better.

Why not use horses instead of cars?

Note, I'm not especially praising for this product, but I am for slack vs irc.

Is IRC supposed to be the car or horse in this analogy? I'm convinced of the former.

The main issue with IRC is that you have to stay connected all the time to recieve messages, and you have to leave your IRC client to see and search the logs (unless you have some intermediate IRC client server that runs all the time). It's just not as nice.

> intermediate IRC client

A bouncer? Usually pretty straightforward to install, and quite mature in features.

Yet it's not something that IRC provides out of the box.

I've got no issues running my own ZNC bouncer, but when you're choosing a product that an entire organization will use (including people who have no idea what "ZNC" means other than 3 letters), IRC is lacking a lot of features that get mentioned in every HN chat solution thread.

Just use screen and detach it :)

https://quadpoint.org/articles/irssi/

Yeah but if you suspend your machine doesn't it stop accepting connections? I personally set up a tmux window on a raspberry pi for this, but it's too much to expect a whole company to manage this (vs. a nice simple web GUI like slack)

Slack has seriously changed the way we work at my company and it's boosted our productivity by 100x.

Yes we had a IRC server for a while and no one was using it, so we always had to use emails for important communications.

You just got to try it to feel it. Some features on paper don't match with the experience of a product.

If you're worried about using it for large community projects (e.g OSS), then maybe IRC is still the better child for that particular audience, although there's already a couple of communities who have successfully moved to Slack entirely (Gopher comes to mind).

I think IRC is the Delorean of this analogy.

IRC stops short at certain features that are much easier to use / seamlessly integrated in these type of apps.

In return for stopping short on features, it's incredibly easy to extend (and the work has already been done in most cases). For example, there have been build and log IRC bots for many years before Slack existed.

Slack is even easier to extend than IRC, and all those IRC bots can be plugged straight into Slack.

A sufficiently advanced IRC client may be able to catch up to Slack in some of its essential features, such as formatted code sharing, image sharing (for screenshots and other things), document sharing, comments on uploads. etc.

But at that point, why not just use Slack or Mattermost.

And IRC is not even close to an adequate solution for what Slack does when it comes to non-devs. If you only ever talk to people who code, then perhaps you can work around IRC's deficiencies. But by using Slack, the conversation can be opened up to all sorts of non-technical people, and it enables them to communicate effectively so much better than IRC ever could. These non-technical people's contributions are essential to the functioning of almost all serious companies, meaning that for most teams, IRC will not work and Slack will.

IRC is a telegram network operating on Morse code compared to Slack's cellular network.

because there are no netsplits... /sarcasm

There aren't if you run your own server. How many workgroups require an entire multi server IRC network?

Can I get push notifications to my phone from IRC?

(Not sure if Mattermark provides them, but it's one of the reasons I use Slack)

yes, and I do.

I actually use slack via the IRC gateways, and the push notifications from IRC are nearly always 2-3 mins ahead of the slack ones.

Protocol limits, I suppose. For example, how IRC handles channel history? IIRC, the only way to reliably have it is to serve logs over HTTP or alike (i.e. outside of IRC).

XMPP MUC is not perfect, but I believe would be a better match.

You're not too far wrong, though IRC could do with some updating to get rid of some of its more severe limits and issues which prevent it from as useful as it could be for less technical users.

Can it send push notifications or other alerts to my phone?

Congratulations, Mattermost team! Huge accomplishment :)

Thanks mholt!! We're working every day to make something people want,

Just what we need, another solution to a problem that was solved two decades ago!

Reply on news.ycombinator.com