Hacker News new | comments | ask | show | jobs | submit login
Slack Platform Launch (slackhq.com)
366 points by thejosh on Dec 16, 2015 | hide | past | web | favorite | 219 comments

Facebook F8 all over again in the sense of startups throwing the success or failure of their company onto a proprietary centralized system that can block or cut them off for any reason.

Or rather, 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.

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.

Every program attempts to expand until it has an app store. Those programs which cannot so expand are replaced by ones which can.

Abrkn's law was born.

Brekken's Law (assuming that's his surname from the email in his profile). It's a snowclone of Zawinski's law of software development[1]:

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

It really is true. My previous employer had a dream of turning their extremely specific web app into a platform, with an app store and everything. I assume that being a platform means big bucks, idk.

[1] https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_la...

It's a snarky observation that hides an important insight: email is the most important thing that the internet does.

Wouldn't the general form of this be every program expands until it implements a plug-in system?

Any examples of programs which has started out as an app in an app store, and then expanded into an app store of its own, and then the app store had swallowed the original app store?

Trying to find the proof of abrkn's theorem

Don't think that's necessarily true. Yes, lots of programs implement app stores or plugin systems. But often the users also don't want to fiddle with add-ons, their installation and settings. They want a good and well-integrated out-of-the box experience. Especially if they are not from the tech domain.

E.g. let's look at Eclipse: It was based purely on AddOns right from the beginning. And still many people want to replace it with other things (probably without AddOns).

I feel like the world has lost it's mind slightly. When a 2 year old startup launches an $80m fund. I mean I understand they want to be a platform and can see the strength in funding projects that will empower a platform model but still. This is the point at which I think we're really in a boom heading in that bubble direction, and I was never one to fall in to the trap of calling it a bubble before. Love slack, love the platform play, but my God this is getting crazy.

Slack makes a ton of money and it is unimaginable to me (and many others) that it's not going to be a massive force. It has been a revelation to literally every entrepreneur I know - and I'm from Virginia not SV (although I recently moved to NYC - same deal).

Now that it has established itself beyond almost any doubt, its INVESTORS have established an $80M bet around those who make the company a core component of their strategy. Slack, which has very low burn, seems to have contributed to this fund but we can safely assume it was a small amount (if at all).

This is a sign of strength. We're still creating transformational companies with real revenue models, and these companies often facilitate other great companies. Tech is strong - valuations may be wrong one way or another, but tech is a great place to deploy capital.

Genuine question -- how how is it been a revelation? It seems to be very similar to HipChat, which was just an iteration on previous chat systems.

The difference is people like using it. UX counts for a lot.

The massive amount of integrations for it helps a lot too. Their goal, from what I've read, is to be a giant log for everything in your company, not just a chatroom service.

"Their goal, from what I've read, is to be a giant log for everything in your company..."

Why would you ever want to entrust a log of everything in your company to a third party service? Honestly curious.

Because the expected loss from a malicious actor with access to those logs cloning your product (without any access to the actual people who thought up your product!) is often more than balanced by the expected benefit from getting everyone on a knowledge base with a brilliant UX.

Sure, you wouldn't have wanted to host the Apollo Program's lab notes on Soviet servers, but your cat selfie startup isn't quite as high-stakes as that.

Unless your cats are taking selfies on Mars. In which case, yeah, maybe developing an in-house chat service is worth the investment.

But Slack isn't just used for discussions. It's used for sharing. People send files through slack -- files that probably contain sensitive data, code, financials, etc. People pass secret sharing URLs (think Google Docs' "anyone with the link can access") through it. If we're being honest, probably some people exchange passwords over it. People directly grant OAuth access to other services for "integrations". Some people do "ChatOps" -- literally controlling production servers through chat -- over Slack.

And then what if Slack gets hacked?


    Q: Were my messages taken/read/accessed?

    If you have not been explicitly informed by us in a separate
    communication that we detected suspicious activity involving
    your Slack account, we are very confident that there was no
    unauthorized access to any of your team data (such as messages
    or files).
So. Slack has been hacked, and at least some people's logs were evidently stolen.


Yeah, what you just said is probably the case for the majority of Slack's users, and I get that.

My perspective is framed by working with an EMS provider (PCB design & assembly) who does business in some highly regulated fields. We've started using Slack in the last couple months for some of our teams, and love it, but the idea of using it as a catch all strikes me as questionable.

If we used Slack for actually talking about the design/assembly portion of the business, and not just coordinating sales and marketing efforts, our customers would flip shit. And rightfully so.

I own a contract manufacturing company in China, had similar concerns. We implemented an open source Slack alternative that runs on our own server. Project is called Zulip --> https://github.com/zulip/zulip

I feel like I came across that as I was weighing the various options for us to try haha. Zulip is the kind of thing I'd love to give a shot, but I have to take into account people who won't be tech savvy enough to use something like that. Therein lies Slack's value to us.

At the end of the day, Slack is really useful, but I just don't see its use getting expanded much. At least for us. There's lots of stuff that just shouldn't get communicated across there. Coordination across the sides of the business that don't use Slack wasn't an issue in the first place, it was never really even considered afaik.

(Zulip committer here) Definitely agree that user onboarding could use some work, feel free to send feedback.

hn-username @zulip.org , or https://groups.google.com/group/zulip-devel

Another self-hosted alternative you might like is MatterMost, which is quite similar to Slack in look-and-feel, but free software and self-hosted.

> Sure, you wouldn't have wanted to host the Apollo Program's lab notes on Soviet servers, but your cat selfie startup isn't quite as high-stakes as that.

I find this to be a pretty interesting comparison. To the best of my knowledge, the entire stakes of the space race were "we might lose face".

That, and "Soviets are going to launch satellites loaded with nuclear weapons into space and end the cold war".

Slack is classic "shadow IT". It isn't introduced or managed by IT. It is introduced by users. If IT departments were in charge of Slack, you'd have to have seven layers of managerial interference before you could open a new channel and it'd have the usability of Lotus Notes.

You are right, a lot of companies would walk away from that pretty quickly as long as it's a third party thing. Github launching it's self hosted enterprise is what really enabled it to reach the larger companies, as they tend not to trust their valuable data to exist outside of their control.

Slack has said before that they're going to release a self hosted version at some point, so they have to know this is true. I think it makes sense for them to focus on the larger market (personal use and the SMB sector) for now though, even though the enterprise market will really make them money, because it's a much lower pressure space where they can afford to experiment.

First, because the (perceived) risk is relatively small, both of damage and the chances of damage.

Second (this is the point I think hn-like forums grossly underestimate) is because the alternatives are not really alternatives. In practice the likelihood of using Irc or some open source chat within a company with the same wide buy in as slack (or Skype etc) is 0.

The way to judge this is adoption.

HipChat is a real on premise alternative.

It may not be quite as "slick" looking, but it works very well.

I moved my company off Slack to Hipchat as the latter has more useful integrations for us, and does not have the same limitations (you are not limited to ten integrations on the free version of Hipchat) or the stupidly high price of Slack.

There are parts we don’t like about Hipchat (the shortcuts for the emoticons are just weird), but we are using it company-wide where Slack was just used by developers (and Hangouts was used by everyone else).

> the stupidly high price of Slack.

really? $7 per active user per month? How little do you pay your staff? At the median wage, save an average of 90 seconds a day per person through better communication and it pays for itself. And it's pretty likely any team members using slack are at a 2-10x salary multiplier on that, a $100K engineer only needs to save 24 seconds a day...

If the choice was between $0 and $7, you might have a point. It isn’t.

As a company we are not short of options: Slack (the dev team liked it, but no one else used it and even a large part of the dev team didn’t use it), Google Hangouts (what everyone else used), Skype (no one here uses it), and now HipChat—which everyone in the company uses. This means that we weren’t choosing between $0 and $7, but:

• $0 (Slack) which provided something most people in the company didn’t use, and whose limitations we in the dev team hit fairly quickly (both 10k message chat history and the limited number of integrations).

• $0 (HipChat) which provides something most people in the company do use, and whose limitations we have only recently hit (the last six weeks) and are not currently bothering us (the limitation is just the 25k message chat history).

• $0 (Google Hangouts). Not really $0, but we already pay for it as part of GApps so it’s an incremental $0. The group chat functions suck, and there’s no integrations to speak of, but it is available.

• $2/mau (HipChat). Adds video/voice calls and screen sharing and unlimited chat history. We only need the chat history, and that isn’t bothering us.

• $7/mau (Slack). Just removes the 10 service integration limitation (which IIRC was 5 a few months ago) and the chat history and a few other features we don’t really care about but nothing to write home about. There’s also the $12/mau level and they are working on an Enterprise level.

There is absolutely nothing that Slack provides—except a bigger bill—that HipChat doesn’t provide as well for less. (And, even if Slack were better than HipChat, it isn’t 3x better. Sorry.)

This isn’t to say that Slack is a bad thing, just that it’s stupidly expensive and/or limited compared to other hosted options.

Your strawman implies that his team would save time in Slack versus HipChat, but you ignored the justification he already gave about the integrations that are more useful to them edit and that the whole company was happy to go to HipChat. It's possible those integrations help them save the time that makes the difference, but having every user there would surely help.

I cost justified a tesla that way. How much I spent on gas gong to mountain view, plus time in the carpool lane, but time I rent it in getaround. Blah Blah Blah. Doesn't mean it is right or worth it.

Would you mind giving some examples of what are more useful integrations for you that Slack does not support? I am curious because we--at work--have been using HipChat for around two years and have integrated HipChat into our processes, yet now that we are exploring and using Slack (for another project), we find the integrations and APIs so much better to work with.

The issue that I’ve had with Slack is more related to text like this from the New Relic integration:

This integration will allow you to receive updates in a Slack channel when an alert is triggered in New Relic. If you would like web, transaction, server, and mobile alerts to be posted in separate channels, you will need to set up separate integrations.

You can quickly hit the limit of ten integrations on the free service by having to set up a separate integration for each channel you want things to appear in. So…between GitHub, Bitbucket, Semaphore, a custom API integration, and a couple of others we ended up hitting the limit of 5 integrations (which is what the limit was as of May or June when we made the switch to HipChat; it’s double that now, but we’re starting to use even more tools, so it’s the same problem).

> a giant log for everything in your company

The lawyers and Congressional subcommittees are going to love this.

big companies [in the US] already largely deal with retention/e-discovery requirements.

there are many, many offerings, like Google Apps Vault, to facilitate this.


For me, by far the biggest difference is the notifications. In HipChat, notifications are both buggy and almost completely unconfigurable[0]. If I sent a message to a colleague while they were offline, they would never get notified of it[1]. Slack notifications always work how I expect and are configurable to the degree I desire.

Slack also has a nicer UI and better integrations for us, and generally just always works how I want. I don't know if I'd call it a "revelation", but it's way better than any comparable product I've used.

[0] - I think HipChat recently added support for more granular notification settings, but I don't use it anymore. Also, it took over 3 years of this being their 1st or 2nd most requested feature before they addressed it, so I don't give them any credit for having it now.

[1] - They might get an email depending on their settings, but the HipChat app would never give a notification.

We've been on hipchat for about two years. Never had a problem with offline notifications. I get both an e-mail instantly and an IM when I log back onto the chat client. I don't recall this ever being a problem or ever not being there.

I dunno what notification settings hipchat is missing, but I'm not sure I need whatever it is missing. If I get tagged in a message, I get notified. Not sure that I want more than that. We have our deploys and a few other things hooked up to hipchat - at first when we started using it we went crazy with the third party integrations, than realized we didn't actually need all the noise the integration notifications gave us and turned a lot of it off.

We don't even pay for it and we get all of this.

Slack is one of my most annoying and least-effective tools because every single message has a pop up that blocks off a corner of my screen.

Slack's notifications lack customization which makes them annoying. Either you get the whole package, intrusive desktop pop up and all, or you get no notification. Where's the option to have sounds but no pop ups? Where's the option to lump notifications so you don't get spammed?

totally agree about the lack of customization.

A portion of the difficulty is owing to them using a web app in a SSB (single site browser) instead of a properly native desktop app.

I would love to be able to tile different channel/message windows, like we all did with IRC clients. Unfortunately this is fundamentally intractable in an SSB-architected app (including Electron, node-webkit, et al.).

Agreed. I wrote a blog post outlining a way to get around this. (https://medium.com/building-things-people-want/slack-is-too-...) The gist: turn off all notifications then flip them back on by channel. Still doesn't address de-coupling of pop-ups and sound, though.

Loved the article. check out www.spacechatapp.com would love to pick your brains on how to filter through the noise. we're building it.

Your site shows cloudflare errors.

Yeah after we started hooking it up now I get all these notifications for builds, etc. I don't need any of this notifying me but I need notifications for other types of messages.

Right now I'm not seeing a difference between this and HipChat but everyone seems to love it so I'll use it I'm just kinda indifferent and unimpressed with it thus far.

you can do quite a lot of customisation if you split out automation messages into channels - each channel has per-user-device notification preferences

If you use OS X, go into System Preferences -> Notifications -> Slack and set slack alert style to "None".

There, you now have sound and no banner-style alerts. You can customise a lot more and all apps that are able to do notifications go through there.

Maybe you can't customize notifications extensively in Slack itself (I found them okay, yet slightly lacking), but if you're on a Mac, you can definitely comfigure Desktop notifications per App, which I also did.

Everything you said about notifications in HipChat is false.

I first used HipChat more than 2 years ago, and the notifications worked perfectly and were as configurable as I wanted them to be. Offline notifications worked well.

We tried Slack when it came out and couldn't figure out why anyone would use it over HipChat, since it had no native client at the time.

We have been using HipChat for the last two years for one of our two major products at work and have very recently moved to Slack for the other. While notifications on HipChat work most of the time, they are still very patchy. I personally use the Mac client, while others in my company use the web, Windows, and Linux clients and we've all been bitten by missed notifications on applications one too many times to actually become a nuisance for us. Until the very last update to the Mac client, I became used to frequently finding the client freezing up on me. The windows clients, on the other hand, is even more infamous for this. Plus, the iOS app isn't something I really look forward to using (judging by the fact that I've had it installed on my iPhone for far longer than the Slack app, yet I leave it signed out almost completely, while I enjoy using the Slack app).

I used HipChat on Windows, Mac, and Android for 1.5 years and never experienced any of that. My team didn't, either. Those issues must have started happening after I stopped using it. Maybe Atlassian hasn't prioritized HipChat after buying it.

They certainly appear to have been working on it, judging from the updates being released. I feel they have a long way to go, though.

Sounds like HipChat has the unfortunate distinction of being the Friendster of the chat space, sometimes the gods are fickle.

My current theory is that HipChat was purchased (and marketed) to be part of the Atlassian suite. They may have believed there wasn't enough upside in a chat client to market it as a standalone product.

For me, one of the reasons why I don't like Slack is that in moving to Slack from Hipchat, I lost configurability in notifications. Slack chat window notifications are terrible. They consume immense amounts of space, and yet aren't clearly colour-coded for relevance. Hipchat notifications were tight and concise, and could be clearly colour-coded.

A pattern I have seen in Slack that never happened in Hipchat is "Let's put notifications into the channel" > "ugh, this channel is impossible to talk in because of the notifications! let's create a new channel with no notifications". Kind've kills the point of notifications.

Aside: does 'notifications' need to become 'n10ns'?

Hipchat is awful and Slack is phenomenal. I mean I know that probably isn't what you want to hear but it's so hard to describe it any other way.

UX/integrations/apps/speed/etc might all be the answer but it was visceral for me.

At least on Windows slack has pretty terrible performance. I wish i could go back to hipchat. I regularly experience perceptible lag when typing, which doesn't happen anywhere else.

EDIT: This is a fairly recent problem. A month or two ago, I had never experienced this.

Not recent. May have gotten worse, but last I tried it was heavier than hangouts; yeah, text chat chewing up more cpu than streaming video. Pretty rough.

Folks on Macs had no idea what I was complaining about though. Go fig.

Once you add history to Slack, it's performance is just awful. One of the worst performing apps I use. It can take over a second to switch rooms.

If I have to cycle through 4 rooms to get to the conversation I want, it can take seconds just to Option+UpArrow there.

Plus I can't manually reorder rooms as I like. I don't get why everyone talks about the Slack UX. Slack has snippets. Which I find mostly useless. Especially since they kill performance. But HipChat lets you reorder rooms as you see fit. Which is something I actually used and miss desperately.

At least Slack has finally gotten rid of the useless Channel vs Group distinction?

Honestly, also not being in SV, I think it could be the biggest thing for companies since email. Nobody in our 400 person shop wants to use anything but Slack. Its completely changed the company culture, brought together different teams, opened up a real time log of what ops is doing (employee worth), consolidated communications, searchable file server. The list goes on and on. Nobody wants to use email and most people despise JIRA (in our small company). Everybody from every department is trying really hard to integrate everything they do into Slack and Slack keeps making it easier.

As someone who has used both, I really prefer Slack; it feels like a more polished product

I think comparing feature for feature isn't the right way to understand why Slack is a disruptive innovation.

Often it's an innovation along some other dimension - process, business model, etc. In this case it's Slack's business model and "platform" strategy. Other tools like HipChat were just that, a tool. Slack is a platform in the sense that it enables businesses and developers to leverage and extend the platform, thereby adding additional value to the platform. This leads to so-called "Network Effects" where as more apps are built on the platform, the more valuable the platform and the more likely others will want to build on that platform, etc. in a virtuous cycle.

You definetly work in PR. You have the quality of taking something trivial and describing it as if it is a big deal.

With free self-hosted open source alternatives like Rocket Chat and Mattermost entering the scene, along with easy internal installation from Sandstorm, does a new business really need Slack?

> does a new business really need Slack?

How many man-hours am I going to spend fracking around Rocket Chat, Mattermost, and Sandstorm?

I think I'd much prefer just paying Slack to worry about that for my hypothetical new business with 10 employees. 6.67 * 10 * 12 = $800/annum.

Peanuts. Especially compared to the value of my time or my employees time.

Less than 30 minutes for your tech team.

1) Install Sandstorm (curl https://install.sandstorm.io | bash)

2) Install Rocket Chat (one click)

3) Set up a domain. Done

Regarding maintenance: I set it up 2 months ago and it's still running smoothly.

This is how long it takes to spin something like this up, but you're forgetting maintenance, domain knowledge, internal documentation, etc.

People underestimate the costs of "rolling your own" or even going FOSS. It's absolutely never "set it and forget it."

Most of these services that charge nominal fees ($5 - $100/mo) are interesting because you don't have to control your own support procedure and ostensibly they're build to scale.

> It's absolutely never "set it and forget it."

Have you tried Sandstorm? It is in fact designed to be "set it and forget it" -- that's a major goal of the project. Everything auto-updates, you never have to edit config files, it can configure DNS and fetch/renew SSL certificates automatically, installing new apps takes one click, etc.

(Disclosure: I'm the lead developer.)

The "How It works" wasn't bad. But nonetheless: does it distribute itself (and my data) to multiple VMs? If it needs a kernel patch, does it appropriately plan downtimes and/or shed load from that VM before applying the patch and rebooting the instance? Does it handle machine failure?

We actually have tools to do all of that -- high-availability / fault tolerance / load balancing, entirely transparent to users, admins, and apps -- which we use to run Sandstorm Oasis, our paid managed hosting service. We are working on productizing these tools to sell to "enterprise" customers.

For individual users and small companies, single-machine Sandstorm is pretty reliable, but it's true we don't automate kernel updates yet (which will require scheduling reboots for off-hours). We'll add that eventually.

(Sorry for all the vaporware.)

Sandstorm's updates are closer to Chrome's than regular open source software. Stick to the 'release' channel can you can be sure that you're always up to date. And Sandstorm locks its apps down so tightly that they often don't suffer from the same security vulnerabilities the same apps do outside Sandstorm.

That being said, to roll your own you'll need to run a box somewhere, select secure defaults, and keep on top of patching the box itself. It's not worth it unless you're really willing to spend the time to do it correctly.

Eh, honestly, if you're not running anything else on the box, you probably don't have to be overly proactive about maintaining it. Sandstorm handles updating its own dependencies and mitigating most kernel bugs. Maybe if you're leaving sshd open to the internet that's something to worry about, although if you read HN you'll surely know when that needs patching. :)

That said, we plan to build a "Sandstorm OS" that auto-updates everything including the kernel, and doesn't even have an SSH interface (wouldn't be useful anyway).

It does if there's a whole ecosystem of bots and services built on top of slack that don't run on the alternatives.

For sure! I wonder which services people love in Slack that aren't available in Rocket Chat. So far in this thread there aren't many details. Bots are mentioned, and that's available in Rocket Chat too via Hubot.

I think it is a useful way to double down on an investment.

Rather than putting more money into the mothership, you bet on external tools that will help the mothership grow.

It is also a way to reduce the costs of acquisition of the best integrations. If the majority of slack shareholders hold the majority of the shares in the best integration, it effectively lowers the price of acquisition to turn the tools built on slack into internal products/features.

This. $80m invested in a Slack ecosystem for these investors is likely to generate even more than that in returns (on their existing Slack equity) even if the investors never saw a dime out of the $80m invested.

That's the difference from being just a tool, or a platform. The former is easy to copy and replace, the latter goes in monopoly position once you have an ecosystem around you (see Salesforce, Facebook).

$80M is the price they have to pay to go in monopoly position as soon as possible and become a platform.

> I feel like the world has lost it's mind slightly. When a 2 year old startup launches an $80m fund.

Slack was founded in 2009 and has raised over $300M (yes, three hundred million dollars) [1]

[1] https://www.crunchbase.com/organization/slack#/entity

Wow, what did they need 300m for? This is nuts.

The CEO is quoted as saying "we don't need it but the terms were so good that it would be foolish to refuse the money. Also it buys safety during a downturn."

Slack has an insane amount of money, and they don't need any of it. They've put massive amounts of cash in the bank to stay safe in a downturn, and are well on their way to profitability. They really DO have the cash to burn, and this is a great way to spend it on many fronts.

At 2M DAU, there's a lot of upside in building a bot for that audience. We just launched a simple expense management slack bot last week and in the past few days, our engagement has gone up... will post some numbers shortly. https://medium.com/trippeo-blog/introducing-expense-manageme...

I think it's a fantastic idea, but I struggle to comprehend how they can possibly think that $80 million is an appropriate amount of money for such a venture.

570,000 paying customers.

As someone who has been through the hype and then crash of dotcoms in 2000, this does feel like a bubble.

Slack is not 2 years old. It's a pivot from a company started in 2009.

I don't think it's reasonable to say we're in a bubble because of a $80M fund around developing for a new platform. Few companies truly become platforms, and it's a misnomer to call it a bubble if this only happens to one company. It takes a lot of money or momentum to develop one. Facebook had by far the most compelling one in the last ten years, and the obvious incentive there was it's >300M users at the time. The case is less compelling for a B2B platform like Slack, but it makes sense as many of these investors also invest in B2B startups that can gain huge visibility through the Slack platform.

By having six investors in the fund, each fund can mitigate risk of Slack's platform not getting traction while lowering the barrier for developers to enter. This slideshow by A16Z outlines why the venture capitalists (including some on the list of Slack fund contributors) are tightening their belts around investing and telling companies like Slack to generate reliable business models rather than IPO prematurely.

This premature IPO behavior was the reason for the last bubble, and I think this investment fund is proof that we are NOT in a bubble. The new strategy for these investment funds is to allow their startups to generate revenue on a much more stable basis without the need to go public (and get cash for equity) for this to happen. Most B2B companies would eventually benefit from a recurring-fees model built around the Slack platform, and this enables smaller, fledging companies to scale much more quickly towards long-term cashflow positivity.

In all, the kings of tech companies are those that find some sort of platform or natural monopoly. Slack may be next in line to follow Airbnb, Uber, Twitter, Facebook, and Google respectively. Overall, by allowing a method to build these platforms while not going public, investors increase returns for their companies in the short AND LONG term while maintaining a course of innovation!

A good comparison that hasn't been mentioned much in this thread is Salesforce's Salesforce1 Fund, which launched with $100M in 2014 to encourage people to build around the B2B app-creation platform it had launched a year earlier [0]. As the parent post mentions, it's important to make the case "compelling" for building best-in-class integrations with a relatively-recently-launched platform (whether or not that platform is sponsored by a historically huge corporation or not).

It's an interesting point that bringing multiple sources of external capital to bear on an ecosystem via a multi-sponsor fund, rather than into the business itself via an IPO, allows the business to grow at a natural rate, and avoids Slack contributing to a "bubble" in which companies race to go public to launch their own platforms. I think we've learned from the last time around that the public markets aren't the best place to manage expectations in technology.

As for why the sponsors made this investment, there's a very good case to be made that (a) efficient free-form communication within agile teams at small and large companies is a pattern as crucial to developing modern businesses as a CRM, and (b) Slack is perfectly poised to capture and hold this new market in the same way that Salesforce was. Certainly worth a $13mm commitment that's diversified amongst companies whose teams could still pivot should Slack not work out.

[0] https://www.salesforce.com/company/news-press/press-releases...

Please guys, no. Don't build your startup on top of another platform. Remember Facebook? Remember Twitter? That 80M is a farce by the VCs that actually re-contributes back into Slack, not so much for you.

People are going to get riled up about this statement since it is vague. Better to say: don't build a missing feature on top of a "platform." You will be consumed.

Now, if there is "synergy" with that integration, then it makes sense, but this assumes you have a profitable standalone business to begin with.

If your app is another way to poke people, you will lose. If your app was the first way to post pictures on twitter, you're screwed.

Agreed. Read my other comments on this thread and you'd think I'm a super Slack fan, but be wary - other people's platforms when they're this young are opportunities but you don't know what the next few years bring.

ON THE OTHER HAND: Twitter and Facebook make money on ads, and that's what caused them to change course. Salesforce apps are still a huge business and that's closer to Twitter/FB than Slack.

It depends, if having a slack integration will benefit your business and theirs and they are willing to help fund it, seems like a win win.

Of course you are correct that you would never want to bet your business on their platform.

Until they are in your business also...

It's a risk of failure. There may be other benefits that outweigh that risk. I don't know why you'd make a general rule about that.

Remember Salesforce?

No need to build your entire startup on Slack but a solid integration can drive serious initial revenue for your startup especially if you do not get a lot of direct traffic. "One click install" is what helped Woocommerce and others get massive growth on the back of Wordpress through top exposure in the plugin directory.

Slack is still very much at the bottom of the growth curve. I have seen electrical contractors who need a way to chat with onsite workers at various projects switch from using WhatsApp/SMS to Slack. If one click job scheduling apps start appearing in the Slack App Store they will be quickly adopted by these businesses. I would be surprised if Slack or something like it has not completely wiped out internal email in 5 years.

I too am bullish on Slack and am with you right until "wiped out email." I've heard this said about Slack before and don't get it. Asana is a real email killer in that it's both realtime (instant) and structured (i.e. it wholly replaces email threads). On a meta level, why is it that it's so important for Slack's marketing that they "replace email"? Why isn't it enough for them to "go beyond email" (which is totally realistic and honest and still a potentially huge business)?

I don't know whether it's important for Slack's marketing to claim they are replacing email.

What I can tell you is that it factually has wiped out internal email for our team at Charge.

And I think that's pretty common for most teams that have used it. Why write a slow clunky old email when a Slack message will do?

> Why write a slow clunky old email when a Slack message will do?

Because email is threaded conversations, while slack is not. I can write 5 different emails and respond to each thread individually, but I can't do that in slack: I can write 5 messages, but my peer(s) can't answer each one individually - they can just write 5 messages and I have to figure out what they respond to.

Email has the added benefit of working nicely when you're on a connection that's not always available (mobile, traveling, etc.) I can write the message and have it sent later, download all messages and read (and answer) them without a connection. Slack (and other chat applications) just falls flat on it's face when the connection drops from time to time.

Now, all of that might be properties that you don't need because you're never traveling and always on the same schedule, so that you're able to answer questions in real time - but don't assume that's true for everyone.

We have a prototype threading implementation for Slack. Drop a line to <hn username> @gmail.com if interested to test.

Realtime threaded conversations is a need?

I'm sure I can accomplish this with a simple Google search (and I'm going to do that next) but I do want to put a request out there. I'd love to see some use cases of successful, complex Slack integrations and how the organization has saved time/money by making Slack a part of their workflow. It seems to be a tool built for developers, at least I see a lot advocates that are developers. I want to know how personnel across multiple departments feel about using the tool.

Kind of funny for people to say that a new startup launching a fund means there's a bubble. That's exactly what Twilio have been doing even since 2010: https://gigaom.com/2010/09/23/got-a-twilio-based-app-get-som...

http://techcrunch.com/2013/03/01/twilio-and-500-startups-lau... http://recode.net/2015/05/20/twilio-launches-50-million-deve...

So if I build something on top of this that actually turns out to be popular and turns a good profit, what is to protect me from Slack then building it in the core product that cutting me out or shutting me down?

Not much I guess. Twitpic anyone? [1].

1. https://blog.twitpic.com/2014/09/twitpic-is-shutting-down/

Does anyone know how you can apply for a Slack Fund grant?

I'd love to create a Browserling integration. Browserling (www.browserling.com) is a live interactive cross-browser testing service and this integration would let you embed a live browser directly in Slack.

Use case: Let's say a user reports a bug in IE10 on Windows 7 in your webapp. You just use `/browserling windows7 ie10 URL` command in Slack and that will embed a real interactive IE 10 on Win7 that runs your webapp at `URL` directly in Slack.

I would use this. And I'm going to check out browserling now, too. This looks really useful.

Great! I'll build it. We've already built all the necessary pieces.

1. We've browser sharing scheme:

For example:

(Loads Hacker News in IE 9 on Windows Vista)

2. We've Live API (https://www.browserling.com/api) that hundreds of people use and that let you already embed real browsers in your webapps.

Combining these gives you great super powers.

You can email them slackfund@slack.com

Have you or anyone you know gotten a response? Do you know what exactly you should send them?

Awesome, thanks!

Can you give me a pitch why I'd use Browserling instead of Browserstack?

We're the first company to offer live interactive testing starting 2010.

We're mad open source fans and have open sourced hundreds of libraries including browserify, dnode, node-png, and many others (http://www.catonmat.net/blog/browserling-open-sources-90-nod...).

We're constantly inventing new things (http://www.catonmat.net/blog/top-10-browserling-inventions/).

We're a small and enthusiastic team, so we can quickly respond and adapt to our customer needs.

Zero inbox, quick response times is how we roll.

Our customers love us and we love them.

I give my phone number (415-423-1954) to everyone. Call me at night to chat about yesterday's football game or to yell at me that IE6 doesn't work on XP.

And finally we love to have fun at Browserling and we started our own nerdy webcomic about web developers and browsers https://lol.browserling.com.

Slack is great and all, but I personally don't feel like it's revolutionary. It's just an iterative improvement over a chat client, nothing groundbreaking there.

As in most other popular things, there's little actual substance undergirding Slack. Slack lives off hot air. Lucky for them, I suppose.

2 points:

1. Remember when Dropbox was dumb, because rsync? (Bunch of naysayers here citing fee alternatives).

From what I'm seeing, bots and integrations are great and here to stay.

Businesses will gladly pay money in exchange for time and complexity not spent rolling your own.

2. This seems like a boon for us happy slack users!

Will somebody please explain the use cases for slack bots to me? If they are basically glorified command line scripts, the I get it. But are there genuine and important use cases that require/can benefit from a richer dialogue?

There's a pretty good talk on "chatops" by the guys at GitHub[0]. Basically, it provides a dialog around a "shared command-line" where developers from learn from each other by simply watching chat. I think it's more beneficial to distributed companies.

However, my question for those using chatops is basically how do you keep the repository for the bot "tame"? It needs access to _everything_ if you want it to be useful, which means having lots of secrets exposed to the bot.

[0]: https://www.youtube.com/watch?v=NST3u-GjjFw

Give the bot runtime (not in the repository, environment variable or something) credentials for a secret storage tool of some kind, where it can then fetch credentials for whatever it's allowed to do.

Securing the bot itseld is definitely a larger challenge, but a heavily shielded box and tools like Vault can go a long way. It's actually not much different to securing other solutions to the problem like Capistrano or Chef, and definitely still better than giving root SSH access to your developers.

Some of it is contexual, at my last office, everyone was on slack even though we weren't a software company. The execs used a bot (Birdly maybe? I wasn't that involved) to track their expenses. Previously it was up to each exec to keep paper receipts, input them manually into a spreadsheet and submit it to our accounting department. Afterwards, they just shot a picture of each expense and let the slackbot manage it, submit for approvals for big expense and deliver it to accounting at the end of every month.


The New York Times has a queryable Slack bot that can tell their editors what topics/stories are likely to be popular. The backend is a machine learning algorithm.

This is essentially a command line script, as you say. But having that functionality and being able to discuss the results amongst your fellow editors is very powerful.


I use bots to make it easier for non technical personnel to perform complex operations, and also to provide some rooms with extra context. For example, if someone mentions "HS 201" in chat, our bot responds with a link and summary of HelpScoit conversation #201. If it's [A-Z]{3}-\d{1,4}, he replies with a link and summary info for a Jira issue.

I hear that about Dropbox all the time, but honestly I don't remember a lot of nay-saying when it first came out. What I DO remember is the crap sync-ware before it, around 2000-2001.

There was a fair bit when it was first announced here (although maybe not as much as this thread):


That's 80M against the commoditization of hosted chat. Smart way to put up barriers to entry.

Their dev blog post [0] mentions an AWS Lambda Blueprint to go along with a chatbot framework (BotKit) and an "Add to Slack" workflow. This (AWS Lambda) is a smart move; it reduces the friction of writing a quick integration with Slack considerably, making it almost a commodity-level feature. This bet on AWS Lambda will likely be a big deal for general AWS Lambda adoption, given how insanely popular Slack integrations are.

[0]: https://medium.com/slack-developer-blog/launch-platform-1147...

Really like the announcement of botkit[1], I was just looking at adding a vote bot to our slack and only found a really old example that ended up not working.

1. https://github.com/howdyai/botkit/

I hope that the official blessings of botkit doesn't negatively impact other bot frameworks that user the Slack APIs. Lita (https://www.lita.io/) is an excellent way to write Slack bots in Ruby. It supports other chat services and protocols too, so your bots don't lock you in to Slack.

Author of Lita here. Lita's Slack adapter isn't going anywhere. :}

It's stupid easy to build bots with this...

It is yammer all over again http://i.imgur.com/DKODqy3.png

I can't help but post this based on my experience pitching to vendors to join an app store.

Slack CEO: Yammer made $1.2B. We need to make $12B. For that I need to make a hit song with 10,000 background dancers with me on the stage.

Board: How much can you pay each dancer?.

CEO: $10/hr

Board: Ok. Announce an App Store.

You are already a hero and there are hundreds of them to jump on stage to dance with you in that 5 minute song.

CEO: Now you are talking!

We were looking at a company communication channel to replace Yammer and Google Chat a while back, and briefly played with Slack. In the end trading in one cloud service for another seemed unwise.

Because we already used self-hosted GitLab when they announced the inclusion of MatterMost (FOSS self-hosted alternative to Slack) we simply activated that and have been quite satisfied with it.

I summarize Slack this way generally:

- If you've never used Hipchat, Slack is completely revolutionary. - If you've used Hipchat, Slack is still cool...and then you see the price comparison and ponder...WHY?

My company has both! Why buy one when you have two for twice the price!

Interesting, could this be the beginning of something like WeChat for businesses, where every business function you think of can just be completed on Slack? I doubt there's anything about the U.S. market that makes these non-open / corporation controlled platforms undesirable (as some other comments suggest); after all, Windows dominates the business landscape. Its just a question of whether Slack can go from convincing start ups x,y and z to use these apps, to convincing Fortune 500 companies to take the plunge.

I've never used slack and don't know what types of apps they want to integrate but it seems like a disruption of a nice chunk of a market that ERP vendors have ventured into (the job productivity/project management etc. branch). That sounds good because quite frankly often the stuff ERP vendors offer in that space is somewhat lackluster "well we have to be in this area" material.

I think the slack platform could eventually branch out into more traditional ERP areas (accounting, production etc.) and it could be an interesting potential shift from "everything from one hand" to "let's configure our ERP from different services"

Building a platform like this is nontrivial and there's tons of problems ahead but I like the general idea.

I feel an App ecosystem definitely helps to expand the functions. However I also feel it is opposite of a nimble app which does one thing clean. In general we have always had this conflict and it is difficult to choose to stay lean and simple especially when you decide to grow and scale to engulf everything. Its almost like 'Let me grab as much as I can before some one comes' sort of thinking. Only the market can prove if this is the right thinking in the long run. But when you see it in the short span, you do not have much choice.

How does BotKit compare to slack-client[1]?

[1] https://github.com/slackhq/node-slack-client

Can someone who uses slack comment on the value over skype for example?

It seems like text chat is hard to get wrong, and with so many options, I wonder why (real) people choose slack specifically.

In the 90s Internet Relay Chat (IRC) was extremely popular, you connect to a public server, and join a #channel and chat with people, send files, share links etc. There were thousands of ways to extend IRC, through custom clients, bots, scripts.

Slack builds upon a lot of core concepts that IRC had but differs in a few ways. 1) Simplicity, you can get up and running in a few minutes and have your whole team connected. 2) Managed hosting, maintenance and client updates 3) Excellent UX, features are intuitive and new features are introduced with guidance 4) Cross platform support and fast mobile clients 5) Integrations, being able to push and pull data across you apps from the place your entire team can communicate is incredibly powerful. The discoverability and ease of deployment (some can be deployed in a few minutes).

I think they have a great position in the SMB market. Surprisingly some enterprise organizations still use IRC internally due to the control they have over server/data etc. There is probably an opportunity for Slack to develop an on-premise solution for enterprise.

I was a bit hesitant first when our company first started using Flowdock (a Slack competitor), but it turned out to be just great. For example: flows (or chat rooms) with inbox for integrations to e-mail, GitHub, CI and so on -- discussion can be directly related to a certain item, such as a failed build!

And of course, discussion threads. This is something Slack still doesn't have, and is a one of the reasons to stay with Flowdock instead. Everyone knows what happens with IRC channels when there's hundreds of people and multiple simultaneous discussions. Good luck trying to follow the conversation if you weren't following it realtime.

That said, it sadly seems that Slack will eat the whole pie, and it is probably the most future-proof choice at the moment.

I use Slack in my own company, but often use Skype with companies that I do contract work for.

Searching your conversation history in Skype is terrible. Slack really does this well.

Does anyone know if this comes with an initiative to fill in the gaps in Slack's administrative API so addons can be created around that, too? I'm working with SlimerJS to audit message retention and a few other settings.

Slack has a great core experience and I understand why it's doing so well. But it's weird to see an $80m fund to invest particularly in Slack addons when a lot of existing features don't yet have API support.

I used Slack for a few months this year. A customer didn't use email, preferring Slack. Slack is an awesome platform, but I missed the asynchrony of email. When I code I like to have 30 to 40 minute uninterrupted work periods and I found an always on Slack took me out of the flow. Using Slack with specified "turn it off" quiet times would solve that issue however.

Just keep it open in a tab of the same browser window where you check HN ;) (and don't enable the desktop notifications, of course)

The fund is a great play for Slack to become the next enterprise app store. A welcome alternate to the Salesforce AppExchange IMO.

Interesting idea. I love the thought of integrating everything over to a text chat interface as opposed to salesforce's godawful web UI.

I really like! I'm imagining, say accounting integrations which are cryptographically signed by the accounting software and go into a channel.

I bet I'll be paying for an enterprise inside-the-firewall version of slack in the next few years, or wrestling with some competitor that's not quite as good, one way or the other.

Slack team did a great job with this.

Here's a fresh integration with Slack Button in Ruby, https://github.com/dblock/slack-bot-server serving a "Hello World" bot. Hope it helps someone.

Nice move by Slack and great opportunity for slackbot developers. We discover zero interfaces and just launched analytics bot – http://www.brobot.io You can use it with Google Analytics, Mixpanel, New Relic.

Wonder if their stack is still PHP/MySQL etc?[0]

[0] https://twitter.com/SlackHQ/status/426469205005705217

In this thread: a lot of people who haven't used Slack attacking it...

Evernote had a developer conference. They wanted an ecosystem, and kind of had a platform. They bought sucessful apps.

Past tense! Much better/realistic parallel, than Facebook F8.

I've never used Slack, but people keep saying that it's good because of the apps. What sort of apps are those?

They are pretty much integrations. Access APIs of different platforms and manipulate / gather data.

I definitely witter a new IT bubble

Looks like SHOW HN will be crowded more than often after this weekend.

Christ, they just don't get it... What we need isn't "apps for Slack" what we need is onprem Slack. Because sending confidential information to "the cloud" is all kinds of stupid and potentially violates a bunch of laws

folks at atlassian (hipchat) are already doing this...it depends which markets one pursuing...slack and hipchat are totally on different scale. Atlassian even didn't make hipchat user numbers public during IPO proceedings

I'm sorry, I've scoffed at other valuations and investments, but I'm just completely beside myself. Why does a chat room need "apps"?

It's kind of weird actually. There's two sorts of people that defend these announcements, I've found:

The first thinks that they are going to build an "amazing" platform some day and that they'll follow this model for "growing revenue". So of course they defend it.

And then there's the second group that has some "great idea" who plans to build on Slack's platform. Personally, I look forward to 2 years of stories about how Slack was unfair to them, or changed the rules on them, or broke an API. Or didn't review fast enough, or any of the other complaints that pop up monthly about other closed platforms.

1) Take 300m in VC money. 2) VCs want their money back 3) Pull your hair for a a while. 4) Figure out a genius plan. Now you are an ecosystem! Nobody ever thought of that. You are a true silicon valley legend! 5) Profit

Or not.

Have you ever even USED Slack? The apps are amazing, it's 50% of why people use Slack. There have been apps since I've known about it which has been almost since it launched.

Slack's integrations are less powerful than many alternatives. Every chat system has integration options. They have very little to do with Slack's popularity.

50% that's a stretch.

Useful, yes, 1/2 of interactions, questionable.

Parent didn't say 50% of interactions were integrations, just that the integrations are 50% of the reason people use Slack and I agree. There are other somewhat comparable products that are a lot cheaper, yet don't deliver the same value with regards to integrations.

Didn't say 50% of interactions, 50% of why I use it over other methods of chat. Other 50% is UX.

Why not fix all the bugs that are there before lunching new products/features?

Something that's in the middle between a bug and a missing feature (imho) is that Slack's failure to support Github-style markdown.

GitHub does a great job with markdown, especially with programming-language-specific highlighting. And even things like strike-though text and URL's, which aren't specific to software development.

It's one of the few aspects of Slack that has me open to alternative services.

that's a bit inflammatory to say; especially without offering a single example.

Applications are open for YC Summer 2019

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