While you are right that it's very similar to IRC etc you are completely missing the fundamental reason Slack et al are popular: user experience, especially for non-technical people.

Not everyone grew up on IRC with bouncers, irssi on a remote server, and their own server where they could upload attachments to in a single keystroke.

Now it's true that there are new alternatives for non-technical people such as IRCCloud, but (a) it costs money for individuals (b) it's frankly not as good, UX-wise. Hence not as popular.

THANK YOU. This is why slack is winning. They took many of the concepts of what makes irc great abd put a much better user experience on top.

Why is that so hard for people to understand?

This happens over and over again.

- Google wasn't the first search engine. - Facebook wasn't the first social network. - Microsoft didn't build the first operating system.

They all just did it in a way that appealed to mass amounts of users.

I have no idea why you were down-voted. It's the truth.

Now, to answer why is it so hard to understand? Many people here are programmers/engineers and fail to understand how marketing and nice packaging can sell. Especially if they are old enough to know how IRC works.

To extend what you wrote, I'd compare Slack with iPhone. All the tech. to build the iPhone was there, but Apple managed to put it all together in beautiful, easy to use package. Slack is the iPhone in its area.

Think of it this way. Did the Web Browser need to be a proprietary closed protocol in order for the massive improvement over Gopher/WAIS or other end user hypertext information systems back then?

No, Netscape/Mozilla didn't need to "own" HTTP and HTML completely, and turn the Web into a giant App Store in order to innovate in the Browser client, neither did Google, Apple, or MS. At various points, proprietary extensions were tried, and either failed, or got standardized when they became popular or proven their need.

All Praise to Slack's UI, I love all the flourishes, like auto-detection of paste of code bits and offering to create snippets. I get it, I really do.

I just don't think we need another messaging platform owned by a single company.

Actually, many features of the modern web (DOM, XmlHttpRequest, box-sizing: border-box) were implemented by IE first.

Unfortunately it's not in the best interest of anyone capable of engineering open/distributed platforms to actually do so. Why would they? It's way easier and more profitable to create something on your own terms, something you can control. I would risk that it's better for the customer.

People are flocking from WordPress to SquareSpace, from self hosted SMTP servers to Google, from private hosting to cloud hosting.

Is this a good thing in the long term? I don't think so either, but doing it any other way would be heroism and we are short on heroes.

I agree, but you can't blame them for trying to stretch their monopoly imo

I think you're missing cromwellian's point: you could have made the same thing while upholding open values.

For example if it was a rich client based on IRC, I could join in on a chat without being a slack customer. I could also be a customer of a competitor that would offer something similar, but more tailored to my usage. Now that would move the chat ecosystem further.

But that is not happening, because Slack's business model is hegemonic: they want everyone to use Slack to maximize profits.

But then you would need to handle all the trouble that come from multiple clients. What if somebody makes a CLI client that does not support file transfers? The experience of official client's users would be worse because now they can't be sure that the other side can do the same things they do.

If the protocol were to be upgraded then one would have to wait for all of the vendors to support the new features or we would end up working with the common denominator. Real world examples are hardly scarce, we see this thing in the open web with myriad (semi-) proprietary extensions. Samsung has also hard time getting developer support for their unique features.

In the end, the end users would suffer because of inconsistencies. Open platforms are good, but in my opinion they will always lag in user experience behind well executed proprietary solutions.

Additional features that can't gracefully degrade would be a selling point for slack. "Your client does not seem to support video calls, we do, purchase an account here". When it comes to file transfers, a simple link to download the file from slack.com is a good degradation example.

Once Slack is installed and the norm, you lose some choice. You're prisoner of the way they want chat to be.

I'm sure glad Firefox exists, because otherwise I'd have to hop in the Chrome bandgwagon and sell my data and habits to Google without a choice. The competition there goes further of course, as Mozilla upholds different values, and competing teams try to make their products faster and better.

And then, they fall. Look how Microsoft used to sell a product but now capitalizes on users' data. What will happen when Slack falls? What if I don't want my chat data hosted by some company, but in house, and my business partners use Slack? Where will the choices go?

There certainly are disaster scenarios that can happen. My point is disregarding that in favour of the general user experience. For me knowing that the person at the other side has all of the features I expect them to is great. This goes for support of file transfers or video but also for the fact that all of the buttons are on the same side. (I had to explain over and over where the Skype chat is because the Mac and Windows versions are so different).

If Slack falls then, well, we'll pay the price of migration, but seeing as it is a tool for ephemeral conversations I see it as less of a problem as migrating e.g. my e-mail.

Yes, we all know and agree with their statement, but it's also not what was being said.

UI is absolutely important to getting users on to a platform It's also a totally distinct issue from the network used for communication. There's no reason we can't have a good UX with an open protocol too, and that's what was being talked about.

Because it's a platitude that has been repeated ad nauseam, and we get it. The GP gets it. As he explains in OP's sister comment.

I understand why slack is popular, I use it. But Slack's success is it's UI, and that is not dependent on a centralized close protocol.

We could have a rich ecosystem of competing chat clients over a distributed messaging bus, it's just that there's no economic viability in it.

If SMTP were re-invented today, it would never be open and federated.

A big part of a good chat UI is the knowledge of how things looks in the other end.

Real world friendships have ended because of how emoji are rendered differently on different phones.

> Real world friendships have ended because of how emoji are rendered differently on different phones.

What's sad is that's so true. I overheard the other day my 13 year old niece saying she didn't like a certain girl hanging out with them anymore, because she's the only one "with green chat bubble".

Yes. They excluded a girl from their group, because she didn't have a blue chat bubble. (Essentially an iPhone).

... Did you just make that up?

Slack could still have an awesome UX and be open, people would use it out of choice because it has the best UX.

Not OP but my girlfriend and I are long distance and the 6.0.1 update for Android is causing serious strain on our relationship. I keep sending her taco emojis but all she sees are little boxes with x's in them. If Samsung doesn't push this update to Galaxy 6S soon, I don't know how much longer we'll be together...

Not your girlfriend but I thought I was receiving "envelope face"s.

I agree. We're building https://matrix.org (a free and open communication protocol) and we've realised that until we have a client with better UX than proprietary offerings, people just won't switch.

We hope that a Matrix-enabled client (https://vector.im is looking promising) will get the UI/UX right - and thus actually offer an open and free solution where you can run your own server (should you choose) and own and control your own data!

Wow. Vector is progressing along quite nicely! This new build has none of the rough edges that I remember from the last time I saw it. Congrats to the team for the awesome work!

My biggest issue with Matrix still has to do with its privacy properties though. Homeservers simply know too much about their users. End to end encryption from clients to homeservers appears to be optional in Matrix (and even with e2e encryption, metadata will still be fully exposed to homeservers), and message histories are stored in plaintext at rest.

Now, this probably won't be a huge problem in the ideal scenario where the Matrix network would be composed of a large number of small independent homeservers, but history has shown that decentralized systems that aren't fully decentralized tend to eventually converge towards centralization as it becomes more popular (just look at what happened to email). And in a world where Google, Facebook and Microsoft's homeservers might eventually have a combined market share of over 90%, the privacy aspects of Matrix leave a lot to be desired.

Yeah, it's pretty usable now. We moved from slack to matrix/vector about three months ago. The only complaint was text formatting and that has been fixed now.

My problem is that instead of building FOSS tools to improve the interface to the tools we love and use daily (irc, gpg, irssi/erc, emacs/vim, screen/tmux, usenet, etc) what has happened is people like slack take advantage that the FOSS interface suffers and gives the standard user an easy interface in a proprietary system. There is no reason for slack to not be fully open and still offer the same stuff, my main concern these days is proprietary lock in, for a myriad of reasons including business and personal ones.

As the surveillance engine grows, those of us who have gone through the pains of open-sourcing our workflows will be way ahead of everyone else... but I fear we aren't addressing this main issue which is ease of use/adoption for general user cases.

And no, giving me an API does not make it open.

Short story; we need better FOSS UI/UX.

I upvoted, but I don't think I agree.

There are lots of people building things on proprietary platforms all the time. Why single out FB and Slack? AWS is proprietary. Twilio is proprietary. It's not as if it's hard to find examples.

And so what if some small team implements an auto responder bot and gets a couple hundred thousand in investment?

You're not making fair comparisons.

FB and Slack are platforms in which you write directly for it and it cannot be used or moved elsewhere.

AWS provides many things but, unless you're directly integrating with them, you can move onto another service if you need to (and even direct integration you can later abstract and move away from many of their services to alternatives). Same with Twilio; they provide SMS and other like services but others do as well so you can move your app to any platform with, mostly, minor code changes.

You can't make a minor code change to move your Facebook or Slack app to another vendor / platform. In fact that wouldn't really make sense.

Fair enough. See my sibling comment about Salesforce and Github which I think are better examples. Or the iOS and Android platforms.

My point is that we have certain implicit biases (I too hate FB and Salesforce as platforms) but those biases aren't really based on some kind of general principle that "proprietary platforms are always bad and dangerous".

Proprietary platforms run by untrustworthy companies are bad and dangerous.

A trustworthy company is always one "being acquired by Oracle" away from becoming an untrustworthy, belligerent rent-seeker. Any dependency on another company for your own business must be considered a risk to be managed.

> Proprietary platforms run by untrustworthy companies are bad and dangerous.

But do proprietary platforms run by trustworthy companies exist? If so, what happens when a new CEO, product owner, etc takes over and makes changes that could ruin existing relationships? Seems inevitable for every platform to evolve to some degree; what if the evolution is simply not compatible with what you built? Does that make them untrustworthy?

It all seems kinda nebulous to me and I'm not sure I'd want to put all my cards in one basket :)

>>Proprietary platforms run by untrustworthy companies are bad and dangerous.

Where is this unicorn proprietary platform that is run by trustworthy company?

One difference is that with AWS you're the paying customer and have leverage. With FB or Slack, you're a non-paying "partner" and your leverage is almost null.

Good point. Maybe Salesforce is a better example. Or Github. Don't people build tons of integrations on it?

But companies usually pay for Slack? You pretty much have to to get full history.

Consumers pay for iOS, but Apple still bans you from selling your app in the store.

The gatekeeper function of the platform means they can shut you off at any time.

If instead, Slack published a protocol so anyone could author a client, then bots would just be normal chat users, for the most part, on par with regular users, and a bot would simply be something you deploy somewhere to sit in your channels, just like IRC bots.

I think Slack is a great app, very good UI, but I'm a little sick of proprietary messaging. We really don't need proprietary centralized messaging networks. Standardize a federated open protocol and let people compete on the clients and let the community agree on extensions to message payloads that clients pay attention to, or ignore.

Yeah it's a shame XMPP turned out to be unable to keep up with the shift from desktop to mobile. Maybe we should take a crack at a more modern alternative?

We are trying to make so at Actor (https://actor.im).

cool! we should interoperate :) (we being https://matrix.org)

ps. your https://actor.im/platform page 404s

that's exactly what https://matrix.org is trying to do!

Same as with Twitter; remember Meerkat and firehose access as examples.

I see Google using Slack for things like the Dart and Kubernetes projects. I understand the ease of use aspect (Slack is quite nice) - but one thing that concerns me is that the discussion that happens is no longer (easily) searchable.

Mailing list archives are handy when you are looking for a solution to a problem. With Slack, a lot of that knowledge disappears.

Do you even use Slack? I don't work for Slack but your comment is so misleading.

> but one thing that concerns me is that the discussion that happens is no longer (easily) searchable.

No it is not. Look at the top right and type your words. If you use free plan, only 10k message will be archived, other than that it will be deleted.[1]

> Mailing list archives are handy when you are looking for a solution to a problem. With Slack, a lot of that knowledge disappears.

Its a tool for direct communication for group, not for documentation. I think you miss a hammer for screwdriver.

[1] https://myabuy.slack.com/pricing

I use Slack often, and yes I know about the search feature.

How do I find the answer to a question that was posted two months ago, for an open source project that is not paying to keep more than 10K messages?

History vanishes with Slack. I get why this is very cool for internal communication. I just question the use of Slack for open source community driven projects.

Are slack histories indexed by google, like mailing list archives or large IRC channels?

They are not - this is exactly the problem I am alluding to.

And it's going to be extremely fun to watch when Slack gets acquired by one of the real big guys and the product itself gets grandfathered (or "absorbed" into something else).

Don't say "it'll never happen"...

"proprietary centralized system that can block or cut them off for any reason"

Chat and ChatOps aren't going anywhere, and Slack already has a gaggle of nascent competitors, both commercial and OSS.

If you build on Facebook or Twitter and they tell you to pound sand, it's game over. If Slack does the same, you can add support for everyone else - if you haven't already.

You aren't building a "Slack app," you're building a chat app which happens to support the Slack API. Huge difference.

One key difference is that people building Slack integrations adds a huge amount of value to Slack's product. If there's a tool that works with Slack that you want then you're much more likely to pay for Slack. Consequently Slack do better if they support developers. The same isn't really true for Facebook.

I've probably been on IRC longer than most people and I believe Slack is superior in most ways.

> a proprietary centralized system that can block or cut them off for any reason.

As a startup founder – chatlio.com – betting on the Slack "platform" I have to say that it feels pretty great to know that they are not planning on cutting us off tomorrow morning... :) Might happen anyway of course, but this announcement means we can work somewhat more serenely for a while longer. I see this as a kind of "stability pledge" to third party dev shops.

Hey, have you looked at https://matrix.org? If you build on us, you don't have to fear ever being cut off - we're completely open source and free! We do also have a slack-bridge, and we're building more bridges - our goal is interoperability rather than isolated silos!

The biggest problems of Slack are: being closed source, transferring internal communication to external servers and loading very slow. Here you can find the alternatives solving all problems: http://browsingthenet.blogspot.com/2015/05/slack-is-so-slow-...

So what? Atlassian has a thriving marketplace of extensions for their products and small developers make money out of it. Slack is not a social media site, it's a collaboration tool that is trying to build a platform for the enterprise.

This is an "apples and battleships" comparison.

> another incarnation of IRC chat bots, email listservs, and stuff that's been around forever as commodity autoresponders, only now it's worth millions in investments to write the equivalent of a weekend hack IRC bot because of artificial scarcity imposed by a non-open platform.

Nope, it has value because it can be used by people who aren't massive nerds.