We Tried Slack and We Deeply Regretted It (2015)
medium.freecodecamp.com
medium.freecodecamp.com
Also, previous discussion: https://news.ycombinator.com/item?id=9754626
But, come on, you have to admit that an online community of thousands of people does not fit even the most charitable interpretation of the word "team".
That is basically what the whole thread and article evolves about. Are 10k people a team? Really? Sure, you can argue all day that technically it may be the case, the whole world could be my team, some kind of super team and so a service shouldn't make any assumptions and so on, but reality is that everyone who hears "team" has a pretty good idea of a ball park figure how many people that will be and that freecodecamp doesn't fit into this. So, in the end it's just playing around semantics "but, but, but ... you said of any size .."
I am not interested in long and un-ending pedantic arguments about the extreme corner-case definitions of words. I maintain that an online community of 10k people does not fit even the most charitable meaning of a working "team". If that doesn't work for you, then you're only setting yourself up for surprise.
This argument that "any size" should really mean "any size" amounts to someone walking into an "all-you-can-eat" buffet and expecting to be able to sit at the same table for 2 weeks eating all meals for the price of one, and then complaining that the 'all you can eat' advertisement should overrule all other policies the restaurant has.
It would be the same as someone seeing an ad for mini-golfing for $20 for a family of any size, and then bringing four thousand of your 2nd, 3rd, and 4th cousins, and demanding that the entire group gets in for $20. While there's a pedantic, technical truth to cousins belonging to your 'family', it doesn't meet anybody's common understanding of what an ad for family prices means, even the person trying to cheat the system.
If the author truly didn't even suspect that his 10k users is a massive stretch of the idea of a "team", the message limits should have been a clue, but instead of acknowledging he was pushing the limits, he blamed Slack.
And signing people up with an undocumented API that skips a big amount of signup friction seems like a recipe for running into undocumented limits. Would we be upset with Slack for not supporting 1 million user teams? 1 billion? 1 trillion?
The guy left a free trial for another free trial; if he's at fault we're all at fault every time we change our go-to software. The lesson might be that "there be dragons" - you should guess that any "better" program or SaaS out there is less that half of what it says once unknown limits have been discovered.
You should engage with the vendor. Perhaps there are intangible benefits to the vendor for you to use them even at no cost (PR, testing opportunity, etc)
Generally speaking, if you are dependent on a free service to do your business, you are fucked. A friend is a policy consultant who relied on Google Reader to be his knowledge repository. He bills the equivalent of $800/hr and was nearly paralyzed as it went away.
He didn't change his own personal go-to software, we're not talking about a trial of a video game here. He changed the software for thousands of his users. He put thousands of people on a free trial for something that was not obviously going to work.
You do have the option to investigate before you make that kind of move. If you choose not to exercise it, you don't have that much ground to stand on when things don't work out.
Other users here also pointed out that there is a known specific API error message for the user limit. That kind of thing could be uncovered with a little diligence. Author could also have setup a fake team and tried to add many users before putting 8k real users on the team and just hoping.
He did finally start talking directly to Slack only after he started having trouble, and they responded and disclosed the existence of a team size limit. This obviously could have happened before hitting the limit.
The author expressed incredulity at what would be a $500k price tag, and yet completely fails to see why that is a massive glaring red flag. That alone should have been enough signal that his plan was skating on thin ice, but instead he drove right past all the warning signs and then blamed Slack for it.
He could have asked innumerable questions all of which contradicted the description of what he was getting. He couldn't have known which was the right question. I very rarely query in person before a purchase; I did recently and was given a flatly wrong answer on one question, and then a very positive answer that wasn't logically coherent (strongly suggesting a no, in truth) on a second question. I'm buying anyway, but unless you can phone a corporate head, querying customer support for arcane technical information is rarely a great way to get the right answer, in my experience (sorry to say.) UNLESS you already have a proven fail, of course - which he did.
If it were my program there'd be an error message in there no matter what the upper limit was; I assume others are as competent.
I also don't follow your logic re the high price tag somehow logically entailing a secret limit on the free product - unless you're implying that it's a trap, a way of phishing for phools. (In my country, an illegal bait and switch, actually.) That's something that doesn't work too well when you're peddling to corporations, the pool is small and word gets around too fast.
Yeah me too, for things I buy for myself. But it's absolutely the norm for software purchases of $500k. That's what everyone does, it's extremely common practice for any org purchase of software for over 100 people.
If the author were actually looking to spend $500k, he definitely would have called first and done a bunch of research. Nobody spends that much without talking to someone. The only reason he didn't have that dialogue is because he thought he'd get the whole thing -- apparently a $500k value -- for free.
That's what I mean about the price tag being a signal. It should have signaled a phone call, at the very least.
-- The Slack screenshot in the article.
Do you have a source for that information? One of the roles of Slack[0] is named "Member" not "Coworker".
> the author should have uncovered this cap before moving his community.
He tried: Slack said there was no limit, yet there was. Even Slack themselves mention starting with a "pilot team"[1] to demo; which wouldn't have discovered the limit either. How would you discover it?
[0] https://get.slack.help/hc/en-us/articles/201314026-Roles-and... [1] https://get.slack.help/hc/en-us/articles/217626298-Tips-for-...
But your question presumes that the word "team" isn't enough, and that the implied team size that comes with a 10k message limit also isn't enough. Why?
* Free
* Handles thousands of users seamlessly
* Archived via bot same as free Slack
* No noticeable performance hit for high user volumes
* Wide variety of interfaces and integration bots to choose from
* Widely deployed and trusted across tech communities
It's called IRC.
Edit: I can tell more people are encountering challenges using Slack these days. In the past, a suggestion to use IRC would have been downvoted to hell and back!
A lot of people seem hung up on the history, file sharing, or some other feature that Slack has, so I thought I'd take a moment to expand on my ideal setup and how they translate from Slack:
* Long-lived documentation and important team knowledge: Wiki pages (which I prefer even when using Slack and pins or history search are available). Full history of edits is visible and it's easy to access/search.
* Discussions involving a large number of stakeholders: Email. Threads and the async nature of the protocol make it well-suited to discussions when users aren't all online at the same time and the discussion is more thoughtful and isn't moving quickly. Slack threads suck replies aren't very visible and history scrolls quickly in active channels.
* Discussions involving outages, current tasks, and other immediate needs: IRC. It's real time, cross-platform, etc. History can be archived for later searching, but CHAT HISOTRY != DOCUMENTATION. Post-mortems and that sort of thing should end up in a wiki or similar.
* File sharing can be done via some other service with a link pasted into chat. One extra step to paste the link manually isn't a big deal.
- no history while you are not in a channel
- lack of modern features like sending images and lack of good UX
- no mobile notifications
Matrix.org solves these problems very well IMO, but it's adoption is abysmal too.
- Commonly addressed with logging bots and a link to the log in the topic
- Some clients have this: when you drag an image into Glowing Bear (a web frontend for WeeChat that I'm working on), it gets uploaded to imgur and a link to the image is pasted in the channel. It can also display images and videos inline if you wish.
- Easily handled with services like push{over,bullet}
The problem is that these things don't work out of the box and that there's a learning curve. It's just not a very friendly experience for newcomers.
* no built-in file uploads
* a bot is required for archiving
* a bot is required for notifications
* no native scrollback/history - IRC bouncers solve this problem, but it's not a plausible solution for most non-techies
* the last two issues also mean that mobile solutions are going to be lacking.
It's possible to have IRC as fully featured as slack, but it does mean either rolling your own solution, or using a lot of other software to accommodate everything and everyone.
If I want to ask my coworker René for a quick bit of knowledge, a phone call is too disruptive and too urgent, and an email might not be answered for a few hours. Slack/hipchat/irc are the perfect medium for "hey, do you know off the top of your head why X is Y?"
* channel services can provide archiving and notifications.
* scrollback can be handled by a bouncer, yes, but it's up to the IT dept to set it up per-user
* there are plenty of usable irc clients for mobile, web, and desktop to satisfy this need.
source: Started using telegram/slack but productivity went down so work launched an internal ircd (inspircd). Internal wiki, git, and sharepoint for documentation/files/code where it belongs. Not the chat client.
Nope. They're extremely useful. Just offhand I can think of tons of times we've (a) pasted metric graphs, (b) pasted annotated screengrabs, (c) pasted snippets of code, (d) pasted snippets of test output. None of this is easy in IRC.
I've been on IRC since 1993, and I'm an accomplished programmer. I still find setting up and configuring ZNC and an IRC client complicated, error-error prone, and confusing. And it doesn't always work - sometimes it quits working for no reason and I have to restart things.
We can agree to disagree, but I think that the wide adoption of things like Slack and Hipchat are strong indicators that most people side with me.
What sort of productivity problems did y'all have? Because I have a hard and fast rule - if someone tries to introduce a giphy bot into a channel, I will throw a full-blown tantrum and abuse it until it's gone.
I do agree with you wholeheartedly that Slack, etc., are not a place for documentation.
What's the problem with giphy? Is it too silly? Too much light hearted humor going on in your team's chat?
We have an off-topic room for light-hearted humor, and it generally gets more traffic than any of the work related channels!
> What's the problem with giphy? Is it too silly?
It's usually too irrelevant. Someone tries to do "/giphy smile", and the result is something that's not actually someone smiling. So they try again. And again. And then it's just people playing giggle roulette, without any actual content. Even off-topic, humor rooms need a decent signal to noise ratio.
Which leads me to my old-timer question: What's wrong with IRC?
I like IRC, but newer generations are used to having "full-featured" chats without setup (beauty is in the eye of the beholder).
I also like being able to do some simple markdown in my messages.
It's a combination of both worlds I suppose. So far I am enjoying it.
There's a reason why companies like Slack have built billion dollar businesses doing ostensibly the same thing as IRC, and it's because IRC doesn't offer enough value even if it's free.
Probably the big one for me; I know my previous boss was asking if there was a SSO option because that would be the only thing he saw as limitation in IRC.
I realise my setup is hardly common, and I contend that the main issues with IRC are the clients and the account systems. However, both those issues (among other issues) could be resolved with the IRC protocol, allowing people preferring other clients to continue to user their clients.
Message logging and account management can be done server-side (e.g. closing connections on users if they don't log in), and with a dedicated client to this server, the logging in-part could be done rather seamlessly, even if posing slightly more 'troubles' for other IRC clients.
But as implied in the other replies to my post, but is there any money in that? Maybe licencing the servers? I dunno. I'd love to do something like that, but it would be a full time effort, I fear.
At which point you're not really using IRC. You're using the Bittleebee-commands-over-SSH protocol.
This protocol has a number of issues: it requires having a server with a unix user account running on it (which is a massive attack surface, no-one can offer a server like that for free or it will be used to DDoS other people etc). Its phone apps are poorly integrated and drain battery. Its UI in general is very undiscoverable; the logging interface is still pretty awful (e.g. tracking of how far you've read is pretty poor). Sending files or voicechatting is even harder than it is in vanilla IRC.
> both those issues (among other issues) could be resolved with the IRC protocol, allowing people preferring other clients to continue to user their clients.
Slack offers an IRC gateway, which gives about as good an IRC experience as any extended-IRC protocol ever could.
As for Slack's IRC gateway, I think it's pretty decent, yes. I personally prefer it to Slack's own client (again, that's just me). But this is what bothers me about Discord, because that doesn't offer an IRC gateway, and I am forced to use their client(s).
And if you're like me - which apparently few are - and you are in many different communities, that use different protocols to communicate, having a bunch of different clients just means more hassle.
I'm all for federation and open protocols, I wish Discord had gateways and I'm hopeful for Matrix. But I don't think IRC is the answer: it's inherently without identity, inherently text-only, inherently historyless. These problems can't be solved well without protocol changes, but for whatever reason IRC has developed a community that is hostile to any protocol improvements and preferes to encourage ad-hoc hacks for these aspects, none of which works well and most of which don't work at all.
I only proposed intermediate solutions, because I thought that would be more likely to actually amount to something. Kind of like when Google did SPDY to push for HTTP/2.0, but you'd need a player the size and with the interest of Google to do IRC/2.0. Someone to make the decisions.
It's almost ridiculous that something as ubiquitous as instant communication doesn't get more serious attention.
I've long since given up on any effort to make IRC good. I think energy is more productively spent on ground-up protocols that can include the good parts of IRC but also solve the problems I mentioned. Matrix is where most of my hope is going at the moment.
It's an open protocol. Check out Kiwiirc, it's pretty good looking! A decent front-end team could build a nice interface.
> There's no good account system so users can easily spoof being someone else.
I believe that NickServ takes care of this.
As far as logging, and file-sharing. Yeah you're onto something. IRC isn't as bad as people make it out to be :/
Personally, I'd rather have accounting and permissions be a core part of the protocol, not a bolted on afterthought.
Of course. But they haven't. Kiwi isn't bad for an IRC client, but it's way behind Slack.
I believe that NickServ takes care of this.
Nickserv is hard for a typical user to understand. The number of times someone thinks they've registered a name when they actually haven't demonstrates that. Ghosting makes it harder too.
I used IRC for about a decade. I used even more esoteric online chat services like telnet talkers and MUSHs too. They're great if you learn how to use them. But that's the key difference - you don't need to learn Slack. It works how you'd expect it to work. A user can just pick it up and do things with it. That's a massive difference, and possibly the main reason why Slack can charge a decent price for their product.
(I'm not affiliated with irccloud in any way)
I have been using Slack for about a year now at work and I think it's great. I don't think irccloud would be a suitable replacement either :-)
Like this guy, I usually don't know at first just what is so unusual about my behavior, and often I never do find out. My favorite game (not yet a decade old) crashes every several minutes for me, playing the way I like. I just save extremely frequently and keep right on playing it.
The moral: Where business is concerned: "Be a smart herder" - don't make any false moves, or adopt odd implementations or uses of key software products (or software controlled products) because the minute your behavior is similar to only 1/1000 users (sometimes 1/100 users), you are using the equivalent of an alpha or beta product, and you should count on getting zero product support. Your complaints will, likely, not even be properly comprehended or will be understood, but labeled "impossible" and abruptly closed (I'm looking at you Open Office.)
We have a core team that's always around, and for that Slack pricing is fine, but we have a significant number of "drive by" users that aren't worth paying $60 per year.
We're generally happy with Slack's features, so which are the similar services that charge something different than per-user?
The "max user size" thing is a bit worrisome, but MMOs have a history of sharding to solve that problem anyway, so hopefully that shouldn't be a problem either. (Players will be able to chat together in a shared Discourse forum, so sharding shouldn't really hurt community-building.)
I wonder if any progress has been made since then to support larger teams, though? It's been quite a while, and Slack's engineering team has been cranking out a lot of great features and improvements lately.
If you're not trying to make money, you still should check the agreements for Slack; this may constitute abuse.
You should also take a look at your architecture, too. You've got a clear message bus where you send things to and receive things from Slack. You may notice that where those messages go matters less to your code than you may think. If you find you can't go with slack, it may not be all that hard to simply set up a web site that plays your text-based game by shimming the message flow in and out, in which case you can do whatever you like, at whatever rate you like. Despite the slick name, you may not need Slack at all. You'd still have the conceit of the chatbot experience, which will definitely appeal to a certain niche, just as MUDs did.
(And that name may be too slick. I don't know how nasty Slack is inclined to be, but directly referencing brand names in your name like that is dangerous from a trademark perspective.)
Also, while I haven't figured out monetization, I don't think there should be any real problems with that either. Other people charge for their slack bots and integrations, so unless they specifically have a problem with a game-style slackbot charging money, there shouldn't be anything preventing me from charging for stuff.
You very well may be right about the name, though. I've just registered "chatandslash.com" as a backup that I can switch to before too much marketing has gone forward, and I've already emailed Slack again to show them what I've come up with and for further confirmation that what I'm up to is fine and dandy before progressing any further.
Oh, and you're totally right about shimming out Slack with my own frontend. It's in the backlog of stuff to do some day potentially, but I think there's a lot to be gained in the meantime by explicitly staying with Slack in the meantime. "An RPG you play in Slack" is a lot more interesting than "An RPG that looks kinda like chat, I guess".
Thanks for the advice!
Worth noting that 1) the author's expectations were wildly unrealistic. 2) Slack has since come out with better tools to manage large teams.
I'm definitely disappointed to hear about this. The pricing model sucks for us as well since it means $60 a head to add someone to the friend group if we wanted to pay for slack. If we could pay a fixed price and get a slightly better message history and more integrations, I'd gladly pay it, but per-head is just ridiculous.
We also use Discord for online gaming since it's easier to invite people outside the group. It's been absolutely fantastic, but we had issues with some people not having access at work.
+ For all kinds of "Work"
+ For teams of all types and sizes
+ Bringing people together to make them productive
Compare that to the messaging for say Hipchat:
+ "Team chat built for business"
+ Enterprise features
+ Loved by your IT team
(Edit - Formatting)
Do you know why it happens? Do those companies block Discord as an "unprofessional" website?
https://facebook.github.io/react/blog/2015/10/19/reactiflux-... (October 2015)
To be fair, Slack never really said it was made to support that many users. Even in my team of less than 20 on the free tier, we hit the 10,000 message limit really quickly. I can't imagine how that must have been with 8 thousand users.
But if Slack were smart about it, they'll realise that there's an opportunity here. They are a very well-funded company and it wouldn't hurt to spend some resources to beef up their current code/infrastructure or to even spin up a separate product that they can profit from.
http://www.theverge.com/2016/10/19/13330158/t-mobile-unlimit...
The biggest takeaway from this should be: if you think you might be pushing a system, you should probably talk to a human first to get confirmation on how it will work for your specific scenario, and not just use their sales page.
Particularly when that tool is so important to your operations.
Two things: a) I wouldn't blink at 10k if my line in the sand was "Unlimited number of people" (would I similarly ask a human if Amharic glyphs are supported if the advertisement suggested "chat in all languages"?) b) It may behoove me to verify claims before jumping in, but it is absolutely 100% the responsibility of the organization to set expectations in line with what it can deliver
Not students or subscribers. Not "public channel", or "chat room", or some sort of phrase that indicates a large mass of people.
If someone decided to sue them or something, I'd assume they'd have an easy defence saying they clearly meant a team of work colleagues. As many others are saying here, slack simply doesn't seem to be aimed at this use case.
False advertising regulations aren't a company destroying "gotcha" like felony theft, they are designed to protect consumers from fraud. Having some technical issue that doesn't impact the vast majority of consumers isn't what it's designed for.