IRC is free and what Slack is based on. There are plenty of nice clients, and it's easy to write "plugins" you just write for the protocol like a webapp.
> IRC is simplistic and hacked together (no proper spec covering everything) but you can talk the protocol manually via telnet to test things.
IRC is actually extremely well defined and documented. There is a whole collection of RFC documents related to it that are very well done. I would say it is at least as carefully specified as HTTP. [1]
There is any number of mutually incompatible servers out there, and I don't know of any of them that sticks to just the RFC's. The RFC specifies the wire format and basic messages relatively ok, but most IRC networks also rely on a variety of additional services that are largely unspecified.
The RFC you refer to is (one of several - it also includes at least 2810, 2811, 2813) retroactive attempt at untangling the gigantic mess of hack upon hack added by a variety of servers over the years since the original IRC RFC, because nobody relied on just the original RFC any more.
See sections 6 and 7 in particular - they did not even try to address the variety of extensions or compatibility beyond the reference implementation, which pretty much nobody used any more by the late 90's.
E.g. consider where in the RFC it says something about colour support in messages. It doesn't - that was a proprietary extension added by mIRC [1] that everyone then just adopted. As a result clients that implement the RFC and assumes they'll just get readable text will end up displaying control characters to users, like many clients id for years.
These RFC's also don't specify CTCP at all [2] (used for DCC and the like), which leaves you with a woefully incomplete client.
Here is another example of servers (EFNet in this case) deviating, by providing it's own timestamping mechanism [3].
The reality is that if you implement the RFCs you're only halfway there for a client, and may not even be able to talk to the network you want if you're writing a server (most networks won't let you use the server of your choice anyway). Client-to-server compatibility is better than server to server compatibility, but still requires a lot more than the RFCs to provide the functionality users expects.
It's true that you can mostly deal with this "manually". E.g mIRC colour codes does not require server side changes, and some clients could handle them just with macros, but that's less forethought and clean design and more a matter of the fact that IRC mostly just spews out to users what you pass in, and a whole lot of the reason server-to-server compatibility is so poor is that each major network has done a lot of independent work to work around the various abusive mechanisms people have come up with to take advantage of the woefully underspecified semantics.
The result is that, yes, you can handle a lot of services client side because IRC users are used to tolerating clients that show them control codes and the like if another client has added additional functionality that theirs doesn't support. Like mIRC color codes, which means messages includes ASCII 0x03 (^C) followed by colour codes, which will be visible noise on clients that doesn't support it, with no mechanisms for negotiating features.
To me that is a massive mess, that still has not been cleaned up, and likely never will be, because all current clients have papered over all the ugly cracks over the years.
Source: Written code to interface to IRC on and off since 1994.
I used IRC many years ago but hadn't used it for years. I got into it again recently as I've only just discovered that it's a great way to get help with open source bugs.
Anyway, I've also discovered that Slack and IRC are very different beasts. And IRCCloud account goes a way to helping to get you closer in terms of the history but it's still not the slack experience.
Don't get me wrong, I like them both and I far prefer the flexibility and lightness of IRC, but there's no way you're selling that in to a business that needs something that just works.
Ironically, Slack is begging to be hacked for industrial espionage so is a pretty dangerous place to have all your business conversations but you know, it's pretty....
We also used to use IRC, but then after realising that we wanted some of the features of Slack (a persistent, searchable log of messages for example), so we went and developed such an application that had all the features we needed. It even has some features that Slack still don't have, even though they have hundreds of developers and we were two guys working on the evenings.
If the only real differentiator is cost, I don't believe this to be scalable. Take, for instance, the fact that Microsoft, Facebook, Google .... own optimized cloud stacks (hardware, firmware, software, etc.). One can never match their cost of ownership and operation. So a battle relying on cost is not one flock can win, in my opinion
Yes, haha. For a story like this to be relevant to the general public, it needs unique elements and not just "startup launches slack competitor".
This one is "this guy is the new whiz kid. Watch out for him.". He channels Steve jobs individuality by always wearing the same clothes but has external validation with media.net.
When I read "cheaper", I immediately started thinking about power consumption. Slack is easily the most resource-guzzling app I've run, and lowering its resource requirements by 20% would probably save enough on electricity bills to run a small country.
I haven't found that to be the case -- my Slack app (which I use frequently) has been running for about 30 hours and has accumulated 30 minutes of CPU time, or using around 1.6% of my CPU and is using around 450MB of memory. Chrome has used about 5 hours of CPU time in that same 30 hours and is consuming around 3GB of memory.
Regardless, Slack uses .4% of my machine's CPU (forgot to take the quad CPU into account earlier) and less than 3% of my RAM. Not bad for something I use as often as Slack.
Discord is free. Gitter is free (for up to 25). HipChat is free. WhatsApp is free. There are already plenty of free (forget cheap) alternatives to Slack.
Nothing to see here. I mean, the thing reads like a sponsored piece anyway.
Notwithstanding the cohorts of (even large) corporate users that stay in the free plan, not so much because of the price (which isn't that high, but only if compared to the free plan) but because of the purchase process it would imply.
We actually moved from Mattermost to Zulip. Mattermost and Slack work fine for highly specific project teams but when used in an Enterprise for the day to day operation the poor threading solutions in both become a drag. Especially the ability to react outside of a thread created chaos for us.
We've switched to Zulip which has a real nice messaging threading model. For us it was really a productivity saver and I really recommend anyone to try Zulip!
Comparing Slack to WhatsApp or Discord seems disingenuous. For an employee, that means adding every other user in your company. And what about integrations? With slack it's easy to send messages to channels with an HTTP request, which (for me) replaces email spam.
WhatsApp? What company in their right mind would use a Facebook service for their proprietary communications? Have you read their terms and conditions?
Facebook already collects device-level usage information through their Facebook app in order to keep track of emerging competitors.. what’s to prevent them from using WhatsApp to further enhance their competitive intelligence?
But no, WhatsApp, for me - and many of my colleagues, is a complete no-no for professional communication. I have refused to join the team group many times and I am unapologetic about it. While I really don't find Slack much useful, to be honest is's another source of distraction, I definitely see its use case in a professional set up unlike WhatsApp.
The cost of Slack becomes significant only if you see it as "OMG! We're are spending $3000 / month on it". But, if you're already paying hundreds of thousands of dollars in payroll, why would you mind paying a few dollars/employee on a software that enables better collaboration. I have often seen management balking at spending on software and hardware in favor of a near-free and cheaper alternative. The end-result is 10X productivity loss but good luck convincing them to spend more.
On an additional note, how is this company so good at PR? Many companies are working on alternatives to popular applications but I find no reason for them to be covered in Bloomberg with such an exaggerated headline; as if they're revolutionizing the communication industry.
Does slack really enable good collaboration? It seems to destroy productivity in every environment I've ever been in. It is the workplace equivalent of Facebook shitposting.
IRC is by far and away my favorite method of communication. I'm only 25 so it's not because of a sense of nostalgia.
IRC in general is such an under-used resource. Everyone automatically goes to SO, which is fine for trivial problems. They don't realise they could go on IRC and get an answer from the actual dev team of whatever they are having issues with.
Yes, used right it does. A lot. Sure, you can use it for goofing off, too, so you should have some etiquette in place for which channels are kept serious, which aren't (and can safely have notifications turned off), which announcements warrants @channel or @here or @person and which don't.
A company where people who feels that it's OK to put a notification on 2000 devices to say "Good morning" or "Lunch, anyone?" can't be reprimanded is a sick company, with or without Slack.
It's important to keep in mind that these etiquettes are the same (or at least very analogues to) the ones that are required for email and especially email lists. A company where everybody puts everybody in the To: line of every email will feel that email is a destructive force, but one that cultivates decent distribution list culture and caution about CC'ing the world or replying to all will feel that it is much more useful.
Small teams benefit the most I feel, and even then I tend to agree it is very distracting. At an agency with many clients I am in the channel for most of them and only ever working on one any given moment. Muting a channel doesn't work as I still get highlights for my very common name. The trouble is I very often do have insight or help to provide in most discussions as I have been here a while, but I still get assigned a full workload plus constantly helping in Slack. I have taken to closing it for the majority of the day. Honestly couldn't imagine Slack in a corporate environment.
I keep seeing complaints like this with Slack and I think it's because teams need to focus on setting up the right rooms and the right conventions to go with those rooms. Then relentlessly explaining, encouraging, and enforcing them to keep everyone in flow.
As one example, to cut down on DMs, each of our team members has their own room where people can "drop in" messages asynchronously. This means there's no notification and no expectation of immediate response, but that's a good thing because we use an agile process where people should be able to focus on their daily goals without distraction anyway. DMs then become a rare & discouraged channel only for emergencies and sensitive conversations.
I'm using Slack every day in a major corporation of greater than 5000 users. Slack enables communication and discovery within such a large organization.
Problem with your mac? Go to #osx-troubleshooting
Got an IT problem? Check out #IT
Want to discuss an architecture problem with dozens of the smartest people in the entire company? Hop onto #architecture
Want to share the 5 extra pies of Pizza you had delivered for an undersized audience? Go to #freefood and watch it disappear.
We also use bots to surface data into the chatroom automatically as we're doing something collaborative. It's really quite useful when you setup the correct rules.
This may be the case, but they have a cost to set up and maintain, and for companies that aren't almost all developers there's a significant overhead in terms of teaching people how to use IRC/XMPP. Client software for them is often not written with UX in mind, and with the lack of features like uploads/document embedding, using them can be more difficult.
I used to be of a very similar mindset to you. Then I launched HR software for businesses that charges £3 per employee per month.
My logic in setting our pricing was exactly the same as yours, if a business is spending £XXXX per month on an employee, why would they possibly scoff at paying £3 per month to ensure that the HR and associated documents/policies etc are correct and compliant? I even went so far as to say if a customer is prepared to spend £3 per employee per month in getting their HR right, I don't want them as a customer (arrogant much?).
To cut a long one short, boy was I wrong. We've had to be steadfast with our pricing model because the comparison people make is not the one you and I want them to make. E.g. I spend X on my staff so this trivial expense by comparison is nothing. Instead people compare the cost of our HR software to £FREE or to that of our competitors - who are in a race to the bottom undercharging one another.
Slack is going to have the same problem unfortunately. Their's could be the best collaboration software in the world but businesses can and will find ways to achieve the same benefits for a lesser cost.
The problem with spending even $1 in a large organization is that someone's going to have to sign off on it. Its always easier to go for cheaper or free then, since you can argue fiscal due diligence (even if it may not be in the long run) and thus have a stronger case for whoever is making the call.
This is why gentlemen's agreements with clients to overbill a day or so instead of charging for travel expenses and the likes can be much better for everyone involved. (N.b. can be, it isn't always better.)
I agree. The barrier to spending £3 in a business is rarely the £3. It's the "we'll have to talk to procurement, fill out a PO, get three quotes, etc." admin nonsense.
I don't see any advantage on chat, who is using this in a company? it's not serious people don't know how to use it and they don't focus on work but chatting instead. Lost of time, lost of productivity. Don't want do a service request? yeah write me an Skype message instead... it will increase my work rate and put value in the business.
The only interruptions I get from Slack are when someone mentions my name. I subscribe to a number of Slack channels, but only see activity there when I'm looking for it. (Except for a production problem channel, where I get a notification for all activity in the channel.)
When I have time to check Slack, I can catch up on unread messages, I don't have to read them all in real-time.
The system need to be easy and people that have question can search Inside the FAQ. Why asking when you can search for that damn process, guideline. I check slak and the first that I see is a personn asking if he can bring the dog or cat at work. Who is stupid enough to ask these question and ask for something that he should know where it is. But no ask people for that they give shortcut, link. So much value added!
It's almost the same with email, people have never been trained and still send file over and over, don't communicate with the whole team, you need to push and ask the information because it's a nice tool but not correctly used.
I don't know, maybe the job you do is so trivial that you can put every question ever into a medium-side FAQ with added benefit of being able to employ dullards.
It's not like that at most Software Engineering places and knowedge transmission via common chat is invaluable.
I don't say chat is not valuable. This can help is a quick / fast organization very small compagny but the way the product is show in a big organization all the documentation, procedure etc is a critical key for that employee can work in a good manner. If the information is not well organize it's a mess, people complain, people loss all the day to find a small answer. Yes, they can chat and ask the question but I don't see value for answering question.
Usually entrepreneurs enter a market because they find current solutions deficient and they have a novel or exciting way to solve a problem.
Flock isn’t solving a problem. It’s just a me-too product — almost a copycat built just to cash in. Utterly uninspiring. “But it’s better!” They will exclaim. Perhaps. But if it is better, it is only marginally so. I can’t imagine any 10x innovation they have developed. Slight business model tweaks aren’t innovation. A super sales team isn’t an innovation. Nothing in the article even suggests they have done anything special to differentiate their product.
The the nonsense about the same clothes every day is just a Jobs and Zuck affectation. It’s completely drole. Even if you did wear a daily uniform, it isn’t worth mentioning in a Bloomberg piece. It’s like saying your office has a Nepresso machine. Big deal. I wear the same clothes every day but I’m not having my PR person mention it in interviews — it’s mundane. Nobody gives a shit unless you are some uneducated villager than somehow things such habits are relevant. It wad a bit interesting when Jobs did it in the late 1990s, but even then, it was a personal thing and not something Apple PR wrote about.
The bit about identical offices down to the last detail; just nonsense, just building an image of “quirky productivity monk” rather than “visionary tech leader.” As far as the custom desk built into the car; not even the President of the United States has that in his limos. If you are in the car long enough to actually need a desk, that’s a bit absurd or your day is badly organized. An actual desk? How about a fax machine too? They are “billionaires” — one would think their commute wouldn’t be that significant.
I don’t know these brothers and I am sure they are perfectly nice and smart people, but this emphasis on being hyper productive is just weird.
The photo with the founder in the back of what appears to be a Bentley just reeks of Rich Kids of Instagram but targeted to common people in order to protect an air of respectability and credibility. But to me it seems like the entrepreneurial equivalent of a photo of a solid gold toilet.
Does it support inline code formatting yet? It has only been years since that feature has been requested. Have they fixed the performance problems? How about notifications across devices?
Obviously “better” is subjective, but other than HipChat being installable in premise, Slack wins in terms f features that actually work.
I know of a really large company not far from San Jose that uses HipChat for the single reason that it’s on premise despite a number of teams that are practically begging Slack to create an on premise version.
I don’t know a lot of people that actually want HipChat. It usually used because it’s an afterthought add-on to all of the other Atlassian stuff.
I puked at the countless clothing references. Just another paid for article which didn't even showcase the tiniest detail of Flock or whatever the hell it is.
Similar yes, but I really liked the way the logo embodies everything the company is about. F for flock. The different sized lines look like message bubbles. All enclosed in a bigger message bubble.
Probably this logo is more appropriate for Flock than Feedly :)
After the Theranos debacle, when I see "x pairs of same clothes to save time and money" as a red flag for upcoming unicorn wannabepreneurs.
This piece of PR may have been more believable if they had skipped mentioning how Mark Zuckerbergesque or Steve Jobsesque these founders are.
In either case, good luck to this startup. If they can come up with native apps for their chat platform and thrive as a company without needing to resort to gimmicky PRs, it's still going to be a win.
71 comments
[ 2.9 ms ] story [ 56.9 ms ] threadXMPP is "cleaner" by many measures, and far better specified, but is verbose and complex.
Both have large ecosystems of software you can lean on, with different pros and cons.
People will have different preferences with respect to which is most suitable to build on.
IRC is actually extremely well defined and documented. There is a whole collection of RFC documents related to it that are very well done. I would say it is at least as carefully specified as HTTP. [1]
https://tools.ietf.org/html/rfc2812
The extension protocols that are built on top of IRC are also well defined.
"Simple" here is a function of well thought out design not the opposite. Things that are just thrown together would be a mess compared to IRC.
[1] Source: I used those RFCs to developer an IRC client a decade+ ago.
The RFC you refer to is (one of several - it also includes at least 2810, 2811, 2813) retroactive attempt at untangling the gigantic mess of hack upon hack added by a variety of servers over the years since the original IRC RFC, because nobody relied on just the original RFC any more.
See sections 6 and 7 in particular - they did not even try to address the variety of extensions or compatibility beyond the reference implementation, which pretty much nobody used any more by the late 90's.
E.g. consider where in the RFC it says something about colour support in messages. It doesn't - that was a proprietary extension added by mIRC [1] that everyone then just adopted. As a result clients that implement the RFC and assumes they'll just get readable text will end up displaying control characters to users, like many clients id for years.
These RFC's also don't specify CTCP at all [2] (used for DCC and the like), which leaves you with a woefully incomplete client.
Here is another example of servers (EFNet in this case) deviating, by providing it's own timestamping mechanism [3].
The reality is that if you implement the RFCs you're only halfway there for a client, and may not even be able to talk to the network you want if you're writing a server (most networks won't let you use the server of your choice anyway). Client-to-server compatibility is better than server to server compatibility, but still requires a lot more than the RFCs to provide the functionality users expects.
It's true that you can mostly deal with this "manually". E.g mIRC colour codes does not require server side changes, and some clients could handle them just with macros, but that's less forethought and clean design and more a matter of the fact that IRC mostly just spews out to users what you pass in, and a whole lot of the reason server-to-server compatibility is so poor is that each major network has done a lot of independent work to work around the various abusive mechanisms people have come up with to take advantage of the woefully underspecified semantics.
The result is that, yes, you can handle a lot of services client side because IRC users are used to tolerating clients that show them control codes and the like if another client has added additional functionality that theirs doesn't support. Like mIRC color codes, which means messages includes ASCII 0x03 (^C) followed by colour codes, which will be visible noise on clients that doesn't support it, with no mechanisms for negotiating features.
To me that is a massive mess, that still has not been cleaned up, and likely never will be, because all current clients have papered over all the ugly cracks over the years.
Source: Written code to interface to IRC on and off since 1994.
[1] http://www.mirc.com/colors.html
[2] Here is EFNets document on CTCP: http://www.efnet.org/?module=docs&doc=8
[3] http://www.efnet.org/?module=docs&doc=19
Anyway, I've also discovered that Slack and IRC are very different beasts. And IRCCloud account goes a way to helping to get you closer in terms of the history but it's still not the slack experience.
Don't get me wrong, I like them both and I far prefer the flexibility and lightness of IRC, but there's no way you're selling that in to a business that needs something that just works.
Ironically, Slack is begging to be hacked for industrial espionage so is a pretty dangerous place to have all your business conversations but you know, it's pretty....
We also released it fully open source.
https://github.com/cicakhq/potato
This is listed right under the headline - is this really a key takeaway for the article??
This one is "this guy is the new whiz kid. Watch out for him.". He channels Steve jobs individuality by always wearing the same clothes but has external validation with media.net.
Nothing to see here. I mean, the thing reads like a sponsored piece anyway.
We've switched to Zulip which has a real nice messaging threading model. For us it was really a productivity saver and I really recommend anyone to try Zulip!
Yeah, a lot of enterprises are using Mattermost these days. Uber left Slack and HipChat to use Mattermost for company-wide deployment: http://www.businessinsider.com/uber-ditches-hipchat-slack-to...
Also, Slack has a free plan, so Slack is free.
Facebook already collects device-level usage information through their Facebook app in order to keep track of emerging competitors.. what’s to prevent them from using WhatsApp to further enhance their competitive intelligence?
Also Gitter and Discord don't have a platform as powerful as flock does. https://dev.flock.com/
PS: I work for flock.
But no, WhatsApp, for me - and many of my colleagues, is a complete no-no for professional communication. I have refused to join the team group many times and I am unapologetic about it. While I really don't find Slack much useful, to be honest is's another source of distraction, I definitely see its use case in a professional set up unlike WhatsApp.
On an additional note, how is this company so good at PR? Many companies are working on alternatives to popular applications but I find no reason for them to be covered in Bloomberg with such an exaggerated headline; as if they're revolutionizing the communication industry.
Also, IRC and XMPP servers are cheap.
IRC in general is such an under-used resource. Everyone automatically goes to SO, which is fine for trivial problems. They don't realise they could go on IRC and get an answer from the actual dev team of whatever they are having issues with.
A company where people who feels that it's OK to put a notification on 2000 devices to say "Good morning" or "Lunch, anyone?" can't be reprimanded is a sick company, with or without Slack.
It's important to keep in mind that these etiquettes are the same (or at least very analogues to) the ones that are required for email and especially email lists. A company where everybody puts everybody in the To: line of every email will feel that email is a destructive force, but one that cultivates decent distribution list culture and caution about CC'ing the world or replying to all will feel that it is much more useful.
As one example, to cut down on DMs, each of our team members has their own room where people can "drop in" messages asynchronously. This means there's no notification and no expectation of immediate response, but that's a good thing because we use an agile process where people should be able to focus on their daily goals without distraction anyway. DMs then become a rare & discouraged channel only for emergencies and sensitive conversations.
Problem with your mac? Go to #osx-troubleshooting
Got an IT problem? Check out #IT
Want to discuss an architecture problem with dozens of the smartest people in the entire company? Hop onto #architecture
Want to share the 5 extra pies of Pizza you had delivered for an undersized audience? Go to #freefood and watch it disappear.
We also use bots to surface data into the chatroom automatically as we're doing something collaborative. It's really quite useful when you setup the correct rules.
This may be the case, but they have a cost to set up and maintain, and for companies that aren't almost all developers there's a significant overhead in terms of teaching people how to use IRC/XMPP. Client software for them is often not written with UX in mind, and with the lack of features like uploads/document embedding, using them can be more difficult.
My logic in setting our pricing was exactly the same as yours, if a business is spending £XXXX per month on an employee, why would they possibly scoff at paying £3 per month to ensure that the HR and associated documents/policies etc are correct and compliant? I even went so far as to say if a customer is prepared to spend £3 per employee per month in getting their HR right, I don't want them as a customer (arrogant much?).
To cut a long one short, boy was I wrong. We've had to be steadfast with our pricing model because the comparison people make is not the one you and I want them to make. E.g. I spend X on my staff so this trivial expense by comparison is nothing. Instead people compare the cost of our HR software to £FREE or to that of our competitors - who are in a race to the bottom undercharging one another.
Slack is going to have the same problem unfortunately. Their's could be the best collaboration software in the world but businesses can and will find ways to achieve the same benefits for a lesser cost.
This is why gentlemen's agreements with clients to overbill a day or so instead of charging for travel expenses and the likes can be much better for everyone involved. (N.b. can be, it isn't always better.)
Given the number of places I've worked that have migrated from Yammer / HipChat / etc. to Slack because of the cost, yeah, they might well.
In the end, it ended up costing more in company time just discussing it for 15 minutes than the actual upgrade would cost.
And just, you know, talk to coworkers.
The only interruptions I get from Slack are when someone mentions my name. I subscribe to a number of Slack channels, but only see activity there when I'm looking for it. (Except for a production problem channel, where I get a notification for all activity in the channel.)
When I have time to check Slack, I can catch up on unread messages, I don't have to read them all in real-time.
If it's important, they can message me directly, or use the #prod-problems channel where an "@all" mention will alert me.
It's almost the same with email, people have never been trained and still send file over and over, don't communicate with the whole team, you need to push and ask the information because it's a nice tool but not correctly used.
It's not like that at most Software Engineering places and knowedge transmission via common chat is invaluable.
It makes me sad.
Flock isn’t solving a problem. It’s just a me-too product — almost a copycat built just to cash in. Utterly uninspiring. “But it’s better!” They will exclaim. Perhaps. But if it is better, it is only marginally so. I can’t imagine any 10x innovation they have developed. Slight business model tweaks aren’t innovation. A super sales team isn’t an innovation. Nothing in the article even suggests they have done anything special to differentiate their product.
The the nonsense about the same clothes every day is just a Jobs and Zuck affectation. It’s completely drole. Even if you did wear a daily uniform, it isn’t worth mentioning in a Bloomberg piece. It’s like saying your office has a Nepresso machine. Big deal. I wear the same clothes every day but I’m not having my PR person mention it in interviews — it’s mundane. Nobody gives a shit unless you are some uneducated villager than somehow things such habits are relevant. It wad a bit interesting when Jobs did it in the late 1990s, but even then, it was a personal thing and not something Apple PR wrote about.
The bit about identical offices down to the last detail; just nonsense, just building an image of “quirky productivity monk” rather than “visionary tech leader.” As far as the custom desk built into the car; not even the President of the United States has that in his limos. If you are in the car long enough to actually need a desk, that’s a bit absurd or your day is badly organized. An actual desk? How about a fax machine too? They are “billionaires” — one would think their commute wouldn’t be that significant.
I don’t know these brothers and I am sure they are perfectly nice and smart people, but this emphasis on being hyper productive is just weird.
The photo with the founder in the back of what appears to be a Bentley just reeks of Rich Kids of Instagram but targeted to common people in order to protect an air of respectability and credibility. But to me it seems like the entrepreneurial equivalent of a photo of a solid gold toilet.
Obviously “better” is subjective, but other than HipChat being installable in premise, Slack wins in terms f features that actually work.
I know of a really large company not far from San Jose that uses HipChat for the single reason that it’s on premise despite a number of teams that are practically begging Slack to create an on premise version.
I don’t know a lot of people that actually want HipChat. It usually used because it’s an afterthought add-on to all of the other Atlassian stuff.
It will be sloppy, poorly designed and executed and, in general, a POS.
https://news.ycombinator.com/newsguidelines.html
[1] https://www.appsunveiled.com/wp-content/uploads/2015/04/Floc...
[2] https://s3.feedly.com/img/partnerapp-description-feedly.png
Probably this logo is more appropriate for Flock than Feedly :)
This piece of PR may have been more believable if they had skipped mentioning how Mark Zuckerbergesque or Steve Jobsesque these founders are.
In either case, good luck to this startup. If they can come up with native apps for their chat platform and thrive as a company without needing to resort to gimmicky PRs, it's still going to be a win.