Billionaire Brothers Want to Build a Cheaper Rival to Slack
bloomberg.com
bloomberg.com
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.
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.
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.
It makes me sad.
[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.
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.
XMPP 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
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.
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.
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.