We Tried Slack and Regretted It(blog.freecodecamp.com)
blog.freecodecamp.com
We Tried Slack and Regretted It
http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-and-we-deeply-regretted-it.html
191 comments
very well said! I've worked in a team and we used slack, exactly as you explained... we knew each other, it worked great with Hangouts, Bitbucket and Asana integration.
But for this use case in the post, it's obviously not such a great choice.
I authored this blog post. There is a lot of merit to your criticisms of my decision making.
I want to point out that communities are increasingly using Slack, and many of them are also in the thousands of users. Slack does nothing to discourage this, aside from posting warnings about archiving messages.
The real problem is that they have an undocumented user limit. Like I said, I'm pretty sure we're the first community to hit this limit.
Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did).
Slack may be able to fix its sluggishness for these other communities, and someone might build integrations that routinely export then delete messages so as to stay below the 10,000 message limit and remove the warnings. But it's too late for us. We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit. So we have no alternative but to switch.
The main reason I wrote this post is to provide a cautionary tale to other open-membership organizations who are considering using Slack. Slack doesn't seem to be intended to do this! Please don't do this!
I want to point out that communities are increasingly using Slack, and many of them are also in the thousands of users. Slack does nothing to discourage this, aside from posting warnings about archiving messages.
The real problem is that they have an undocumented user limit. Like I said, I'm pretty sure we're the first community to hit this limit.
Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did).
Slack may be able to fix its sluggishness for these other communities, and someone might build integrations that routinely export then delete messages so as to stay below the 10,000 message limit and remove the warnings. But it's too late for us. We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit. So we have no alternative but to switch.
The main reason I wrote this post is to provide a cautionary tale to other open-membership organizations who are considering using Slack. Slack doesn't seem to be intended to do this! Please don't do this!
I understand that you decided to use Slack. Maybe other communities are doing the same thing.
But that does not mean Slack is under any obligation to support your use case, especially when they are pretty clear about what Slack is for.
It's right there on the homepage: "Slack is a platform for team communication."
A course with hundreds of thousands of students is in no way a "team."
But that does not mean Slack is under any obligation to support your use case, especially when they are pretty clear about what Slack is for.
It's right there on the homepage: "Slack is a platform for team communication."
A course with hundreds of thousands of students is in no way a "team."
I might be misreading the post, but my interpretation was that the audience is other large communities, MOOCs, and other loosely affiliated organizations that may want to try Slack, not the Slack team itself. They're providing useful information for the former, particularly if several other organizations have made similar mistakes.
The post certainly seems to attempt to lay blame on Slack. If their goal were just to educate large communities, it would be titled something like "What Slack isn't good for."
The primary complaint is an unpublished limit that is counter to a main selling point.
Most 'unlimited' things still have some max. Using a BIGINT for your primary key will get you a max of 18446744073709551615. Should we complain that we can't go higher in any application that uses one of these?
Slack's advertisement for unlimited users was based on their product's design. Their hard limit is perfectly reasonable because the interface wasn't really designed to handle 10k users in the first place.
To complain about this is like buying a sailboat and complaining when you sail it into a hurricane.
Slack's advertisement for unlimited users was based on their product's design. Their hard limit is perfectly reasonable because the interface wasn't really designed to handle 10k users in the first place.
To complain about this is like buying a sailboat and complaining when you sail it into a hurricane.
I would complain if it had that limit and was called UNLIMITEDINT, for whatever that's worth.
You seem to be missing the point. I'm saying there's literally NO application that claims 'unlimited' that doesn't actually have SOME limit. There are always going to be technical limitations. Even if it's unlimited in practice (as in, no customer will ever reach the limit we've set) there is going to be SOME limit.
Marketing materials are designed to show the intended audience how they may use something. Slack was created for use by teams, teams that know each other and that need to collaborate. Within that context, a limit of 10000 users is pretty reasonable because it IS 'unlimited' for their target audience who will never need 10000 accounts.
Again, the sailboat analogy. I was sold on my sailboat being 'seaworthy'. Does that mean it can literally handle anything the sea throws at it? No. It's a label used to show the target audience how they may use it. If I choose to sail into conditions it wasn't designed to handle, it isn't the builder's fault, it's mine.
Marketing materials are designed to show the intended audience how they may use something. Slack was created for use by teams, teams that know each other and that need to collaborate. Within that context, a limit of 10000 users is pretty reasonable because it IS 'unlimited' for their target audience who will never need 10000 accounts.
Again, the sailboat analogy. I was sold on my sailboat being 'seaworthy'. Does that mean it can literally handle anything the sea throws at it? No. It's a label used to show the target audience how they may use it. If I choose to sail into conditions it wasn't designed to handle, it isn't the builder's fault, it's mine.
I'm OK with "effectively unlimited". But I don't think Slack meets even that with its user limitations.
With a 10,000 search limit, I don't see why Slack needs to limit users. Without search, it's mush less useful and borderline unusable with over a thousand users or so.
With a 10,000 search limit, I don't see why Slack needs to limit users. Without search, it's mush less useful and borderline unusable with over a thousand users or so.
[deleted]
> I wrote this post is to provide a cautionary tale to other open-membership organizations who are considering using Slack
I hope for their sake, The Odin Project (http://www.theodinproject.com) heeds this advice. They recently announced that they started a Slack community of 20,000 members, so they'll probably be hitting the message thresholds quickly.
I hope for their sake, The Odin Project (http://www.theodinproject.com) heeds this advice. They recently announced that they started a Slack community of 20,000 members, so they'll probably be hitting the message thresholds quickly.
There's a golang http://blog.gopheracademy.com/gophers-slack-community/ Slack channel. Not 100 000s for sure but there are a lot of people using Go.
[deleted]
> Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did).
Why would you think all 100,000 of those students would need access to each other through a collaboration tool like Slack?
Why would you think all 100,000 of those students would need access to each other through a collaboration tool like Slack?
"Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did)."
Any idea what their experience was like?
Any idea what their experience was like?
> I want to point out that communities are increasingly using Slack, and many of them are also in the thousands of users.
[citation needed]
> Slack does nothing to discourage this
http://i.imgur.com/aXO4IFd.png
> We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit.
You're popular because you're free. You've transferred that logistical problem to another team who happened to offer a free plan without your use case in mind. You've made your problems the engineering problems of another team, except in the other team's case, they're accountable to investors and a bottom line.
[citation needed]
> Slack does nothing to discourage this
http://i.imgur.com/aXO4IFd.png
> We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit.
You're popular because you're free. You've transferred that logistical problem to another team who happened to offer a free plan without your use case in mind. You've made your problems the engineering problems of another team, except in the other team's case, they're accountable to investors and a bottom line.
While I agree that they had totally unrealistic expectations (and you forgot to highlight the 5 service integrations bit that he also complained about later), slack does also advertise "no limit on users" when they do in fact have a limit.
http://i.imgur.com/kNTkFGT.png
"Small teams" and "no limit on users" aren't really compatible, and it's pretty normal for people to just read the bit they like and ignore the rest.
Slack should probably just put a 100 (or even 500) user limit on the free plan to discourage people from signing up with such unrealistic expectations.
http://i.imgur.com/kNTkFGT.png
"Small teams" and "no limit on users" aren't really compatible, and it's pretty normal for people to just read the bit they like and ignore the rest.
Slack should probably just put a 100 (or even 500) user limit on the free plan to discourage people from signing up with such unrealistic expectations.
> So we have no alternative but to switch.
It seems unlikely that all 5000 people are actively using their Slack account - if you started automatically deactivating accounts that haven't logged in after 3+ months (a pretty easy Cronjob using the API), you would most likely stay well south of the limits. You can always Email people with something to the effect of, "Hey! We've turned off your account, if you visit the site again, we'll turn it back on, no big deal".
It seems unlikely that all 5000 people are actively using their Slack account - if you started automatically deactivating accounts that haven't logged in after 3+ months (a pretty easy Cronjob using the API), you would most likely stay well south of the limits. You can always Email people with something to the effect of, "Hey! We've turned off your account, if you visit the site again, we'll turn it back on, no big deal".
Yeah, but at the current growth rate, they would've easily hit 9000 active (logged in within 3 months) in less than a month
They where only using slack for two months and hit the limit (of almost 9000).
The 10,000 message search limit sounds like a nonstarter as well.
Larger groups are playing with that $5/user/month bonfire.
Larger groups are playing with that $5/user/month bonfire.
Agreed - Slack is awesome for small teams that need to communicate frequently, but it's definitely not ideal for larger "societies" (as you define them).
I've been invited to a bunch of Slack groups recently, from post-conference groups to ongoing groups around a specific topic (SaaS startups) and every single one of them is a ghost town now, often within a matter of days.
It seems few people have the bandwidth to actively participate in these "societies." I much prefer traditional forum-style software for this purpose, leaving Slack (and real-time communication methods in general) for team-based communication.
I've been invited to a bunch of Slack groups recently, from post-conference groups to ongoing groups around a specific topic (SaaS startups) and every single one of them is a ghost town now, often within a matter of days.
It seems few people have the bandwidth to actively participate in these "societies." I much prefer traditional forum-style software for this purpose, leaving Slack (and real-time communication methods in general) for team-based communication.
"The only way to make this go away is to pay slack's cheapest plan, which is $5 per user, per month. That's $5 x 12 months x 8,462 campers = $507,720 per year, just for our current campers. Until then, Slack aggressively archived messages, sometimes only minutes after they were sent."
Do people really expect to receive full service and support for 8462 users for free? How can a company like Slack survive if it gives away resources like this? Usually, "freemium" services are offered so that users can try out the service without having to pay for it, but if you expect unlimited support for 8462 users, it makes sense to have to pay.
Do people really expect to receive full service and support for 8462 users for free? How can a company like Slack survive if it gives away resources like this? Usually, "freemium" services are offered so that users can try out the service without having to pay for it, but if you expect unlimited support for 8462 users, it makes sense to have to pay.
Doesn't any IRC server ever do this? I mean 8500 users... isn't actually that much. Even if the free IRC servers don't support this amount of users, you could just set up a reasonably cheap server (for way less than half a million (!) a year) to do exactly the same thing.
And that's just the thing. Most people will see Slack as IRC chat, but a bit better. And nobody will consider IRC chat worth $5 / user / month. Doubly so if your chat channel is open for everyone and you don't know who your users are.
And that's just the thing. Most people will see Slack as IRC chat, but a bit better. And nobody will consider IRC chat worth $5 / user / month. Doubly so if your chat channel is open for everyone and you don't know who your users are.
Slack is a lot better than IRC when used as intended.
Also, my favourite IRC client (IRCCloud) is, in fact, $5/user/month, and I know I'm not even close to their only paying customer.
I recognise you're engaging in hyperbole when you say "nobody will consider IRC chat worth $5 / user / month", but when you're saying stuff which is so blatantly wrong (and trivially disproven), it undermines your entire argument.
Also, my favourite IRC client (IRCCloud) is, in fact, $5/user/month, and I know I'm not even close to their only paying customer.
I recognise you're engaging in hyperbole when you say "nobody will consider IRC chat worth $5 / user / month", but when you're saying stuff which is so blatantly wrong (and trivially disproven), it undermines your entire argument.
$5/mo for an IRC client? That's just silly.
Geek cultured called -- they want their technology back. Apparently startup culture has corrupted our industry to a degree that people think $5/mo for a hosted IRC client is a fair exchange of value.
Geek cultured called -- they want their technology back. Apparently startup culture has corrupted our industry to a degree that people think $5/mo for a hosted IRC client is a fair exchange of value.
The market determines prices based on what people are willing to pay. Apparently the companies who are paying Slack $5/month think it's a good value, since they've chosen Slack over all the alternatives. They may even buy it for purely intangible reasons, like their employees enjoy using it and thus communicate more effectively.
If you think you can offer the same services that Slack does for $1 a month, maybe you have an opportunity to start a business that successfully competes with them.
You talk about a "fair exchange of value". Is it fair for Apple to charge you a 50% markup on an iPhone? Is it fair for Starbucks to charge $4 for a latte? Do you know of any for-profit business that sets its prices based on an abstract notion of fairness rather than supply and demand? If your company was fortunate enough to make a 50% profit next year, would you offer to return some of it to your customers?
If you think you can offer the same services that Slack does for $1 a month, maybe you have an opportunity to start a business that successfully competes with them.
You talk about a "fair exchange of value". Is it fair for Apple to charge you a 50% markup on an iPhone? Is it fair for Starbucks to charge $4 for a latte? Do you know of any for-profit business that sets its prices based on an abstract notion of fairness rather than supply and demand? If your company was fortunate enough to make a 50% profit next year, would you offer to return some of it to your customers?
I pay shy of $5/mo for a VPS to run a BNC with my preferred config and serve a few files.
If someone prefers IRCCloud or Slack's features and support, it can absolutely be worth more than the sum of bandwidth, storage, and CPU.
If someone prefers IRCCloud or Slack's features and support, it can absolutely be worth more than the sum of bandwidth, storage, and CPU.
> And nobody will consider IRC chat worth $5 / user / month.
Considering they have tens of millions in ARR, the market has proven you wrong.
Considering they have tens of millions in ARR, the market has proven you wrong.
A single IRC server can trivially handle 8500 users in total, but most ircds would explode horribly on 8500 users in a single channel. There's probably at least one that can support it, but it's not really a use-case they're designed for.
What makes you believe that? 1,000+ user channels are common on Freenode.
Slack comes with more features than IRC though, but you raise a good point. Maybe this customer should use IRC.
> Do people really expect to receive full service and support for 8462 users for free?
There are several service I can think of that have a large user base and support for free (github comes to mind). However, I have to play devil's advocate and say that even some paid services have horrible (or non-existent) support and service.
> How can a company like Slack survive if it gives away resources like this?
Perhaps what should have happened was that slack should have worked out a deal with this group to display advertising. If the quotes of their user base was correct - I'm sure any advertising group would drool over that kind of user presence. However, this could spin out of control with the wrong manager with dollar signs as their eyes.
There are several service I can think of that have a large user base and support for free (github comes to mind). However, I have to play devil's advocate and say that even some paid services have horrible (or non-existent) support and service.
> How can a company like Slack survive if it gives away resources like this?
Perhaps what should have happened was that slack should have worked out a deal with this group to display advertising. If the quotes of their user base was correct - I'm sure any advertising group would drool over that kind of user presence. However, this could spin out of control with the wrong manager with dollar signs as their eyes.
> Perhaps what should have happened was that slack should have worked out a deal with this group to display advertising. If the quotes of their user base was correct - I'm sure any advertising group would drool over that kind of user presence. However, this could spin out of control with the wrong manager with dollar signs as their eyes.
Why on earth would they waste time and effort on doing that?
It's 100% clear what Slack is doing. From their homepage, they're building "a platform for team communication."
Why should they waste time and engineering effort on supporting massive non-teams when it is in no way their core focus?
Startups are about focus. Chasing non-paying non-customers is not a part of that model.
Also, the difference with GitHub is pretty clear. GitHub is the tool for social coding. They don't say it's only for small teams—Slack does.
Why on earth would they waste time and effort on doing that?
It's 100% clear what Slack is doing. From their homepage, they're building "a platform for team communication."
Why should they waste time and engineering effort on supporting massive non-teams when it is in no way their core focus?
Startups are about focus. Chasing non-paying non-customers is not a part of that model.
Also, the difference with GitHub is pretty clear. GitHub is the tool for social coding. They don't say it's only for small teams—Slack does.
> Why on earth would they waste time and effort on doing that?
Marketing? That's another stamp they can put on their list of users. Now look at what happened - instead of making slack look good now this blog post will show up showing how unprofessional they are.
> Why should they waste time and engineering effort on supporting massive non-teams when it is in no way their core focus?
If they can't handle an arbitrary number of users - then they shouldn't be advertising it. They are the ones offering as a free service and advertising it as "unlimited".
Don't get me wrong - unlimited is a ridiculous claim (I would never ever claim any service I offer is (publicly anyways) unlimited - and if we had a marketing department that made that claim they would all be fired) but for the majority of their users they probably only account for less than 1% of usage. It's the same game with shared hosting - 1000s of people on the same server but 99.9% of people only use 1% of resources.
> They don't say it's only for small teams—Slack does.
Their marketing is contradicting - they say "small teams" then they say
"There's also no limit on how many people you can add to your team on Slack."
and
"Slack is free to use for as long as you want and with an unlimited number of people."
So...which is it? (rhetorical question because any sane person signing up would assume unlimited number of users as it says right there in one sentence with no exceptions or asterisks).
Marketing? That's another stamp they can put on their list of users. Now look at what happened - instead of making slack look good now this blog post will show up showing how unprofessional they are.
> Why should they waste time and engineering effort on supporting massive non-teams when it is in no way their core focus?
If they can't handle an arbitrary number of users - then they shouldn't be advertising it. They are the ones offering as a free service and advertising it as "unlimited".
Don't get me wrong - unlimited is a ridiculous claim (I would never ever claim any service I offer is (publicly anyways) unlimited - and if we had a marketing department that made that claim they would all be fired) but for the majority of their users they probably only account for less than 1% of usage. It's the same game with shared hosting - 1000s of people on the same server but 99.9% of people only use 1% of resources.
> They don't say it's only for small teams—Slack does.
Their marketing is contradicting - they say "small teams" then they say
"There's also no limit on how many people you can add to your team on Slack."
and
"Slack is free to use for as long as you want and with an unlimited number of people."
So...which is it? (rhetorical question because any sane person signing up would assume unlimited number of users as it says right there in one sentence with no exceptions or asterisks).
The impossible-to-miss headline says "small teams". I interpret the more detailed description in that context: no arbitrary limit on small team members. No sane person would argue that 500+ is small team.
The limit in place seems like a technical limitation to me: Slack is for teams, so they figured the number is well above any real-life use and probably applies to paid accounts as well.
The limit in place seems like a technical limitation to me: Slack is for teams, so they figured the number is well above any real-life use and probably applies to paid accounts as well.
> The impossible-to-miss headline says "small teams".
Actually when you go to slack.com the first thing you see is:
"Slack is a platform for team communication:..."
and
"Slack is free to use for as long as you want and with an unlimited number of people."
With 2 textboxes for me to sign up for the service. Nothing to suggest that slack is for "small teams" only.
> The limit in place seems like a technical limitation to me:
I don't think you'll get any argument from me - there are only a finite number of CPU cycles, RAM, bandwidth, and hard drive space. But - they should have designed to be a scalable service where all they have to do is spin up some VMs or dedicated systems to increase captivity. Yes - this costs money, but when you offer a free unlimited service - I feel like that's the cost of doing business.
> no arbitrary limit on small team members. No sane person would argue that 500+ is small team.
They need to clearly define what small team means in their terms of service. The carriers were slapped for the "unlimited is not really unlimited"
This is what I found in their TOS:
"The total number of users is limited to the maximum number permitted for your account."
Which is what exactly? What is the limit for free vs paid?
Actually when you go to slack.com the first thing you see is:
"Slack is a platform for team communication:..."
and
"Slack is free to use for as long as you want and with an unlimited number of people."
With 2 textboxes for me to sign up for the service. Nothing to suggest that slack is for "small teams" only.
> The limit in place seems like a technical limitation to me:
I don't think you'll get any argument from me - there are only a finite number of CPU cycles, RAM, bandwidth, and hard drive space. But - they should have designed to be a scalable service where all they have to do is spin up some VMs or dedicated systems to increase captivity. Yes - this costs money, but when you offer a free unlimited service - I feel like that's the cost of doing business.
> no arbitrary limit on small team members. No sane person would argue that 500+ is small team.
They need to clearly define what small team means in their terms of service. The carriers were slapped for the "unlimited is not really unlimited"
This is what I found in their TOS:
"The total number of users is limited to the maximum number permitted for your account."
Which is what exactly? What is the limit for free vs paid?
Even if ads could cover the costs+, they might not want to have a lot of people to get the mindset of Slack==Ads. For many of those users, the ad-laden version of Slack might be their first impression of Slack.
you're almost certainly wrong about the advertising, viz stackoverflow's issues monetizing that way
forum/chat advertising is just not particularly valuable
forum/chat advertising is just not particularly valuable
Also, do people really expect to pay sticker price for 8k users? I mean, I have no idea what slack might have offered, but a quick email would have found out.
For instant messaging, possibly.
But there's a huge risk here for larger groups in that it goes from $0 to, in this case $500k/year with apparently nothing in between
But there's a huge risk here for larger groups in that it goes from $0 to, in this case $500k/year with apparently nothing in between
Here's the problem I have with this:
1. You have an organization (can't tell if for profit or non-for-profit) that explicitly states that it helps people "become a Software Engineer".
2. Yet, one of the organizers of the company (?) states "we blithely shepherded 300 to 500 new campers into our Slack every day, hopeful that this messaging company, now worth $2.8 billion, would hire more engineers to flog their LAMP stack application into shape."
Thanks for this...you're now creating a culture of developers who "blithely" makes architectural decisions with little proper thought and publicly trash technology choices (in this case, LAMP).
EDIT: Upon further review it looks like the person in question has a bit of an agenda...
http://www.quora.com/What-are-the-pros-and-cons-of-MEAN-java...
http://www.quora.com/Having-built-web-stuff-the-old-way-PHP-...
I appreciate that people are stepping up to the plate and getting more people involved in coding, but this is seriously dogmatic and potentially harmful.
1. You have an organization (can't tell if for profit or non-for-profit) that explicitly states that it helps people "become a Software Engineer".
2. Yet, one of the organizers of the company (?) states "we blithely shepherded 300 to 500 new campers into our Slack every day, hopeful that this messaging company, now worth $2.8 billion, would hire more engineers to flog their LAMP stack application into shape."
Thanks for this...you're now creating a culture of developers who "blithely" makes architectural decisions with little proper thought and publicly trash technology choices (in this case, LAMP).
EDIT: Upon further review it looks like the person in question has a bit of an agenda...
http://www.quora.com/What-are-the-pros-and-cons-of-MEAN-java...
http://www.quora.com/Having-built-web-stuff-the-old-way-PHP-...
I appreciate that people are stepping up to the plate and getting more people involved in coding, but this is seriously dogmatic and potentially harmful.
They even explicitly list the fact that Gitter uses Node.js as one of the advantage of them. I really hope they aren't teaching their students to pick third-party SaaS offerings based on whether or not they like the same tech as you do.
I saw that too, and I had to laugh. I like node.js, I use node.js, I've shipped large projects with node.js as part of the stack, and I'll very likely select node.js for elements of future projects. But...
...someone has been drinking way way waaaay too much of the koolaid. All it was missing was the phrase "web scale".
Edit: Heh. http://www.quora.com/What-is-the-tech-stack-behind-Slack/ans...
...someone has been drinking way way waaaay too much of the koolaid. All it was missing was the phrase "web scale".
Edit: Heh. http://www.quora.com/What-is-the-tech-stack-behind-Slack/ans...
Wow.And here I've been starting to get worried about future employment prospects if I keep accepting LAMP+jQuery jobs. Reminds me of [this tweet](https://twitter.com/agentdero/status/174965036928868352)
Cut'n'pasting a perfectly relevant answer (that gives reasons to use both stacks) from a previous question is hardly 'an agenda'.
I think you should have ran the math before switching to Slack.
A max limit of 10,000 messages history for your 8,500 free users, premium cost at $60/user/year.
An engineer designs a product for the specifications she/he is given. Slack's engineers were given the specs above and obviously designed and optimized their product for much smaller teams than yours.
A max limit of 10,000 messages history for your 8,500 free users, premium cost at $60/user/year.
An engineer designs a product for the specifications she/he is given. Slack's engineers were given the specs above and obviously designed and optimized their product for much smaller teams than yours.
They do mention in the write-up that, "We also held our breaths as we waited for Slacks' teased support for large open source communities like ours." and show the FAQ addressing their use case - https://www.evernote.com/l/AHQa0WlJiC9IRZyu8Us7Xm3xOAD31_cX8...
Where did Slack tease support for open source communities with thousands of members? Because seeing that FAQ makes me think "oh, hey, cool, potentially cheaper plans for open source teams", not "move a GIANT group over in anticipation".
I agree though, Slack probably could have communicated that a bit better, at least if they contacted Slack beforehand. Even if the answer had been "We actually have no clue what happens if you try to join 10k people.", the problems certainly sound like that's the case.
I agree though, Slack probably could have communicated that a bit better, at least if they contacted Slack beforehand. Even if the answer had been "We actually have no clue what happens if you try to join 10k people.", the problems certainly sound like that's the case.
The screenshot you quote is about open source projects, not communities. If I understand correctly, even a large project like the Linux kernel has only a few hundred active developers at a time and the rest are one-time small-patch contributors.
It would be interesting though to know how many students used slack for Harvard's online CS50 and how it worked for them.
It would be interesting though to know how many students used slack for Harvard's online CS50 and how it worked for them.
Why would you jump ship for something that hasn't even arrived yet?
A perfect illustration of the "entitled developer complex". Failure to properly research Slack, a bad use-case, complain about pricing, then publicly bash.
I've seen this repeatedly with my own startup (https://commando.io), and honestly this user profile is the worst. They won't pay, or will pay very little, and expect the most. They complain about the underlying codebase and stack (PHP), and fail to solve actual problems. They get stuck on details that don't matter.
I've seen this repeatedly with my own startup (https://commando.io), and honestly this user profile is the worst. They won't pay, or will pay very little, and expect the most. They complain about the underlying codebase and stack (PHP), and fail to solve actual problems. They get stuck on details that don't matter.
Wow, this should be a textbook example of how not to make a decision. Zero forethought of future needs? Check. Picking a solution not designed for the problem? Check. Complaining that something that wasn't designed to do x isn't doing x? Check.
What a hyperbolic post. There is no reason to put a company on blast like this. There is a real team of people likely working exceptionally hard to operate Slack. You could have just written a post extolling the benefits of Gitter, and gone about your day of adding more campers to your project. I'm guessing Slack didn't beg for your business or community endorsements.
I agree
The title should have been "We pushed Slack for a use case it was never designed for and it broke"
Yes, sorry, sometimes limits are hit
Maybe a better solution to them would have been to use IRC
The title should have been "We pushed Slack for a use case it was never designed for and it broke"
Yes, sorry, sometimes limits are hit
Maybe a better solution to them would have been to use IRC
Slack is a 2.8B dollar company and not a small scrappy startup anymore. They can handle all the hate in the world and should not get a pass for sleazy behavior (the same is true for Microsoft, Google or Exxon). Not putting max number of users on website or in documentation is not fair to customers.
Did you consider the possibility that it's a technical limit that they didn't even anticipate ever hitting in real life, because Slack is for small teams?
Let's be fair here: the 10k visible messages limit means that Slack is basically unusable when you hit the user limit, as this post also says (messages archived within minutes of appearing). The pricing is clearly insane with this amount of users too.
Let's be fair here: the 10k visible messages limit means that Slack is basically unusable when you hit the user limit, as this post also says (messages archived within minutes of appearing). The pricing is clearly insane with this amount of users too.
Why not just use IRC? Is it not made for the sole purpose of having lots of users talk with each other.
I agree that IRC would have been a good fit, and with modern IRC clients like LimeChat and Slate, it's not the "legacy" experience a lot of people remember. IRC also would solve all of the problems this guy faced:
* Free. You can hop onto an existing tech-focused server like Freenode, or if you want your own control, throw it on your own server(s) for pennies. If you do the latter, you have full control over all logging.
* Logging. Every client can choose what they want to log, what format the logs are in, where the logs live, etc. No more archived messages. Some IRC clients are smart enough to pull from the log to "back-fill" the messages.
* Modern Clients. Like a said above, LimeChat is a really nice IRC client. It doesn't have all the features of Slack, but do you really need all the features of slack?
* Bot Surplus. There are hundreds of bots written for IRC, in nearly every conceivable language. This was the first "integration" anyone ever used for chatting, and can integrate with anything if you put the time in. You don't get it for free, but for a community focused on programming, that's not the worst thing.
* Free. You can hop onto an existing tech-focused server like Freenode, or if you want your own control, throw it on your own server(s) for pennies. If you do the latter, you have full control over all logging.
* Logging. Every client can choose what they want to log, what format the logs are in, where the logs live, etc. No more archived messages. Some IRC clients are smart enough to pull from the log to "back-fill" the messages.
* Modern Clients. Like a said above, LimeChat is a really nice IRC client. It doesn't have all the features of Slack, but do you really need all the features of slack?
* Bot Surplus. There are hundreds of bots written for IRC, in nearly every conceivable language. This was the first "integration" anyone ever used for chatting, and can integrate with anything if you put the time in. You don't get it for free, but for a community focused on programming, that's not the worst thing.
The slow demise of IRC is sad. Clients like WeeChat excel on the text side of things, but where's the knockout web, desktop and mobile client? Something with the UI of Gitter would go far.
I always feel like IRC is a few protocol extensions and a few clients away from being relevant again.
/me goes back to Freenode
I always feel like IRC is a few protocol extensions and a few clients away from being relevant again.
/me goes back to Freenode
I'm happy IRC is dying, because it's a giant attack surface. As a hosting provider sysadmin, dealing with IRC servers was among the absolute worst parts of my job -- mitigating DDoS attacks against them, extensive hacking attempts directed at their infrastructure and later, mine, when they couldn't get in, credit card fraud associated with the accounts, IRC networks designed specifically for command and control of botnets and trafficking in child pornography, FBI raids against said networks we hadn't yet discovered...
There are exceptions, like OFTC, but merely waltzing into the wrong place on EFnet these days is enough to get 10+ Gbit of UDP traffic directed at your IP address. I used to be fairly okay bouncing on a vhost, but now even the 12-year-olds have enough traffic to knock over a 40 Gbit port channel. An increasing number of datacenters are just filtering 6667. I'm on board with that.
Seriously, let IRC relegate itself to the dark corners of the Internet on shitty hosts and stay there, IMO.
There are exceptions, like OFTC, but merely waltzing into the wrong place on EFnet these days is enough to get 10+ Gbit of UDP traffic directed at your IP address. I used to be fairly okay bouncing on a vhost, but now even the 12-year-olds have enough traffic to knock over a 40 Gbit port channel. An increasing number of datacenters are just filtering 6667. I'm on board with that.
Seriously, let IRC relegate itself to the dark corners of the Internet on shitty hosts and stay there, IMO.
From my experience I haven't seen anything like this in the last few years. Botnets are controlled primarily from C&C web services or other SSL/TLS (+encrypted messages) transport via web.
The brute force ddos attacks I've seen are on illegal private server emulators and Minecraft et al. Maybe this is just a completely different experience by being in differnt part of internet.
The brute force ddos attacks I've seen are on illegal private server emulators and Minecraft et al. Maybe this is just a completely different experience by being in differnt part of internet.
This does not sound related to IRC at all. It sounds related to a specific network and unintended target audience. This in no way would affect a corporation or organization that decided to use IRC. You can determine on your own IRC who is authorized to connect, make channels, etc.
I wonder if this is an argument against IRC, or just against EFNet.
I think IRCCloud has a UI significantly better than Gitter. (Then again, I'm not a fan of Gitter's UI, at least as far as their desktop OS X client goes...)
The IRCv3 work group is making some good progress: http://ircv3.net/ .
IRC servers are easy to start up but managing them is not a piece of cake. Also clients aren't that great and features like chat sync all have to be built on top of IRC and have no standard implementation. It has similar issues to jabber which "supports" group chat but I've yet to come across a client that exposes this into something as nice as IRC/Slack/Hipchat/etc rooms.
This is the real mystery here. I'm a huge fan of what Slack has done and was a big advocate for it when it was starting up. But it feels off that people with high realtime chat needs don't just use IRC, which has been around for ages, is super stable, and deals with this amount of users easily.
Is there any web client you can easily deploy that comes close to Slack in comfort for the users? IRC is cool, but getting thousands of users comfortable with it sounds like quite a challenge.
A number of people in my company use IRCCloud, which is a web-based client with mobile apps. It also has built in bouncer functionality - it stays logged in even when you don't have the page open.
Have to second IRCCloud as being a great IRC client.
That being said, their pricing is probably no better than Slack's for this purpose ($5/user/month).
That being said, their pricing is probably no better than Slack's for this purpose ($5/user/month).
IRCCloud staffer here!
Glad you like it, this year is going to be a big one for us - we're actively looking at how we can better serve large open communities, and I would suspect that will result in some nice changes to both free accounts and the pricing of paid accounts.
If anybody is interested in making IRC suck less, we've got a designer-shaped hole that needs filling... https://www.irccloud.com/jobs
Glad you like it, this year is going to be a big one for us - we're actively looking at how we can better serve large open communities, and I would suspect that will result in some nice changes to both free accounts and the pricing of paid accounts.
If anybody is interested in making IRC suck less, we've got a designer-shaped hole that needs filling... https://www.irccloud.com/jobs
I think IRCCloud is really neat and as soon as the BNC comes along you got my money. Till then I'm hosting my own with ZNC, I just can't give up my weechat client, love it too much.
We run our entire real-time communication infrastructure on an internal IRC server with ZNC. We have literally everyone in the company on it in various rooms, from #backend to #support; engineers and HR alike.
I don't think it takes much to be comfortable with IRC, given the huge mix of people we have using it every day successfully. The IRC clients are really good at making users feel at home - Textual is set up for everyone in the company, although some people prefer to use Weechat.
I don't think it takes much to be comfortable with IRC, given the huge mix of people we have using it every day successfully. The IRC clients are really good at making users feel at home - Textual is set up for everyone in the company, although some people prefer to use Weechat.
You can try to use ours: https://news.ycombinator.com/item?id=9757243
irc supports pretty much nothing besides text. With Slack, you can format, highlight code, upload pictures and documents, it supports Google Docs out of the box, there are plugins for Trello, git, and who knows what else. And it works flawlessly on all mobile OS (good luck getting a decent irc client running on iOS).
irc is a dinosaur compared to what recent team communication software like Slack and Hipchat can do.
irc is a dinosaur compared to what recent team communication software like Slack and Hipchat can do.
Although I don't necessarily disagree with you, none of these things are particularly difficult to implement. In fact, most of it could be done very easily if you had a client that could render/inject markdown. Git and trello bots are very easy to write -- almost kata level scope.
Famous last words, but surely this is not hard given that there are 3rd party libraries for everything you need... I'm almost tempted...
I'm very disappointed with the level of comments here - the emotional attachment to Slack is just not neccessary; same for the ad hominem comments. For sure they have a great tool that I love and use but they have been slow to act upon the fact that many communities are using their free option with huge numbers. Rightly or wrongly.
Slack just simply need to decide whether they are supporting this model or are happy to hand it over to Gitter to deal with. I suspect Gitter will be more than happy.
Personally I think they could offer a fixed fee for public rooms. But hey that's up to them, it's their business model to decide.
I think the problem is just the lack of clarity about how they are going to manage what they definitely know is going on (I have asked).
Slack just simply need to decide whether they are supporting this model or are happy to hand it over to Gitter to deal with. I suspect Gitter will be more than happy.
Personally I think they could offer a fixed fee for public rooms. But hey that's up to them, it's their business model to decide.
I think the problem is just the lack of clarity about how they are going to manage what they definitely know is going on (I have asked).
I think now it is time for Slack to make a "paradigm shift". It seems Slack, like GitHub, is filling a place that was reserved to free open source offerings in the past (e-mail, IRC, newsgroups, etc) so they need to expand their freemium features.
Personally we use slack at work and it's a terrible product. Yes it's nice that we can see pictures and gifs inline with the text but the client is not great. The mobile client is even worse. The bloody thing just doesn't work. I'll get a message via the desktop app and 10-15 minutes later get the push notification on my phone. Then I can only see some of the push notification on my phone and when I go to click the notification to read it. The entire channel or DM it came from is not up to date. So if I do have service which I may not have I have to then wait for the messages to download and for it to reconcile what has been read.
Any irc or xmpp clients do not have these issues. products like Whatsapp and telegram don't have these issues.
Any irc or xmpp clients do not have these issues. products like Whatsapp and telegram don't have these issues.
Two things.
1. The decision making process here was unsound. You need to follow the one, some, all approach of rolling out changes. Jumping in on multiple thousands of users was irresponsible.
2. Slack should provide some guidance earlier in the process about user limits. They are known for their friendly UI/UX. An email to the admin saying: "Hey, we've noticed you reached 50% of our maximum users for your instance, are you sure you are on the right path?" would have gone a long way.
1. The decision making process here was unsound. You need to follow the one, some, all approach of rolling out changes. Jumping in on multiple thousands of users was irresponsible.
2. Slack should provide some guidance earlier in the process about user limits. They are known for their friendly UI/UX. An email to the admin saying: "Hey, we've noticed you reached 50% of our maximum users for your instance, are you sure you are on the right path?" would have gone a long way.
> 1. The decision making process here was unsound. You need to follow the one, some, all approach of rolling out changes. Jumping in on multiple thousands of users was irresponsible.
To be fair, it does seem here like the failure mode wouldn't have been reached until they moved all of their users over.
To be fair, it does seem here like the failure mode wouldn't have been reached until they moved all of their users over.
Look what I found: Slack's free tier pricing page explicitly states "There's no limit on how many people you can add to your team on Slack." https://twitter.com/FreeCodeCamp/status/612758062214950912
With many freemium services capping free accounts at single-digit numbers of users, "no limit" is a reasonable way to let people know that they can stop looking for the catch. It would be more confusing if they said "up to 5,000" users, which sends the wrong message about who their service is targeting.
Everyone understands that "unlimited breadsticks" implicitly means "lots and lots but not infinitely many"
Everyone understands that "unlimited breadsticks" implicitly means "lots and lots but not infinitely many"
Do you work for AT&T? Unlimited means unlimited. If there are limits, they need to be disclosed in advance. Especially if you are explicitly claiming that there are no limits..
A footnote would be nice. Say "no limit" and then in small print " actually 5000. this is for teams not communities."
That's a crock. Please show me one other service that explicitly states "no limit" that actually has a hidden limit. The 10,000 message search limit makes it mostly unusable for groups in the 100s or even 10s so why even enforce the user limit?
Every shared web hosting company out there. Just giving you an example. They have been doing this for 10+ years.
Can you point to one and explain the discrepancy?
Sure...
www.hostgator.com - unlimited disk and bandwidth. Never truly unlimited.
They limit the types of content you can host (no media sites), they set inode limits (http://support.hostgator.com/articles/pre-sales-policies/rul...), they will suspend you if you use too much server resources. Pretty much anything to keep you from using "unlimited" resources.
There are a ton of other examples. I would check out www.webhostingtalk.com if you want to see all the issues with these type of hosts.
www.hostgator.com - unlimited disk and bandwidth. Never truly unlimited.
They limit the types of content you can host (no media sites), they set inode limits (http://support.hostgator.com/articles/pre-sales-policies/rul...), they will suspend you if you use too much server resources. Pretty much anything to keep you from using "unlimited" resources.
There are a ton of other examples. I would check out www.webhostingtalk.com if you want to see all the issues with these type of hosts.
They do explain that other limits make it essentially impossible to actually utilize "unlimited disk/bandwidth". And they don't mention unlimited on the home page. But fair enough, you found one.
Imprecision is fine in informal (face to face) discussion but bad in a business statement.
It sounds like they didn't do any research into what Slack's limitations are.
Also, frankly, if I were Slack I would not invest in supporting this use case at all. Massive free chat rooms are not a profitable space to be in.
Also, frankly, if I were Slack I would not invest in supporting this use case at all. Massive free chat rooms are not a profitable space to be in.
It depends on the community. For this one, it's a bunch of folks learning to code and getting coding jobs; I can imagine many of those ending up working at tech companies who might be great Slack customers, and evangelising because they had such a great experience using it - so the investment of supporting a 'free' chat room could pay off over time.
I don't know if that makes long-term sense.
The OP sounds very entitled: "We'd endorsed Slack to thousands of people on our Twitch.tv streams, and even mentioned it in interviews with the media."
Of course Slack must provide them with free chat rooms in perpetuity, they've even been mentioned in interviews!
It's probably better to be rid of "customers" like this sooner rather than later.
The OP sounds very entitled: "We'd endorsed Slack to thousands of people on our Twitch.tv streams, and even mentioned it in interviews with the media."
Of course Slack must provide them with free chat rooms in perpetuity, they've even been mentioned in interviews!
It's probably better to be rid of "customers" like this sooner rather than later.
I really don't think Slack cares about one customer mentioning them in interviews. Especially a freeloading customer. Why not simply have each user pay their own $5 per month?
They are not customers they are users, and it's important to make sure your users are happy, lest you run out of them before you run out of money catering to their every whim.
This whole concept of a 'customer' sounds very interesting, I hear they appreciate the services companies provide so much that they are willing to hand over actual money, instead of using the service they got for free to bitch about the service they got for free.
This whole concept of a 'customer' sounds very interesting, I hear they appreciate the services companies provide so much that they are willing to hand over actual money, instead of using the service they got for free to bitch about the service they got for free.
> It's probably better to be rid of "customers" like this sooner rather than later.
Agreed. This is more or less an example of patio11's "pathological customer": they won't or lack the resources to pay, have an unreasonable use case and overinflated expectations, and proceed to throw a fit loudly and publicly when they don't get their way.
Agreed. This is more or less an example of patio11's "pathological customer": they won't or lack the resources to pay, have an unreasonable use case and overinflated expectations, and proceed to throw a fit loudly and publicly when they don't get their way.
You realize that this one example actually proves the rule, no? In order for the math to work out in this instance you need a large, tech-focused community that might one day turn into a workforce of engineers that might then bring their Slack preference into new companies. At which point assuming the company isn't already using Slack, which is a very big IFF, you then hope that the coder builds enough clout in the company to evangelize Slack and convince the company to move off of whatever they are currently using.
If I were Slack I would generate migration assistants to get organizations like this OFF of Slack and on to something like Gitter ASAP. Seems like the return on that investment (in purely good will) would be much more predictable and scalable.
If I were Slack I would generate migration assistants to get organizations like this OFF of Slack and on to something like Gitter ASAP. Seems like the return on that investment (in purely good will) would be much more predictable and scalable.
I love reading stories like this. While it could have been worded better, it's important to share information about migration failures, so that other people can learn from them. When done right, it's called a postmortem. We need more of them.
I also think it's proper to point out that bandwagon effects played a role. Marketing shouldn't be used an excuse to skip due diligence, but in practice, it's often a factor in bad decisions.
I also think it's proper to point out that bandwagon effects played a role. Marketing shouldn't be used an excuse to skip due diligence, but in practice, it's often a factor in bad decisions.
You can't really use a product outside of it's use case, then complain about it when you reach "outside" it's walls.. I mean you can complain all you want about it, but don't blame it on the product itself. The manual invitation form is clearly designed to discourage mass open ended invitations. A product designed for teams with 500-1000 users in mind, is probably going to get bogged down by 10,000+ users.
Every chat system since IRC has been worse than IRC. Without fail. Just use IRC, people, stop chasing shiny things.
I'm afraid not. eg for me the 3 killer features on hipchat have been (a) Ability to scroll back and see what happened when I was offline (b) Ability to post pictures/files (c) search.
Now all 3 of these could be implemented on a ICR server client. But they are not simple, not supported with all clients and not something that your marketing guy can easily use.
With hipchat/slack/etc they are all out of the box on minute-one and easy to use.
Now all 3 of these could be implemented on a ICR server client. But they are not simple, not supported with all clients and not something that your marketing guy can easily use.
With hipchat/slack/etc they are all out of the box on minute-one and easy to use.
Mentioned elsewhere in this thread, but IRCCloud.com almost exactly fills these use cases (search will launch soon).
Disclosure: I work for IRCCloud :P
Disclosure: I work for IRCCloud :P
(a) Use screen or tmux. Log.
(b) Post links. Everyone in IRC has been doing this for 30 years. Works fine.
(c) Have your client log, or have a bot log to something with HTTP access. You can then use grep or a fancy web app or anything in between to search.
I'm with the parent. Scalable chat is a solved problem; it was solved in the open, via open source and open networks, over 20 years ago. Everything since has been focused not on the technical problems of chat but on the business problem of making money from chat. The fact that someone out there wants to make money on chat does not mean you need to give them money to solve your chat problems. Paying for things of value is fine, but in this case you simply don't need to. Sometimes the best things really are free.
(b) Post links. Everyone in IRC has been doing this for 30 years. Works fine.
(c) Have your client log, or have a bot log to something with HTTP access. You can then use grep or a fancy web app or anything in between to search.
I'm with the parent. Scalable chat is a solved problem; it was solved in the open, via open source and open networks, over 20 years ago. Everything since has been focused not on the technical problems of chat but on the business problem of making money from chat. The fact that someone out there wants to make money on chat does not mean you need to give them money to solve your chat problems. Paying for things of value is fine, but in this case you simply don't need to. Sometimes the best things really are free.
> (a) Use screen or tmux. Log.
This is not something "your marketer guy can easily use". And even for techies it has issues like lack of notifications (fixable), lack of non-suck mobile support, and, extremely important for me even if apparently not for some, typing latency (mosh is a partial solution but not good enough for me).
There are a few applications that use a daemon running a custom protocol to fix the scrollback issue: Quassel, Smuxi, weechat remotes, others. This is a decent approach in general, and the one that I use (weechat + Glowing Bear), but I haven't found any such applications with good mobile support or which are very high quality in general.
Maybe IRCCloud is the answer - has a spiffy web client and iOS and Android apps. It's a hosted service and non-free so I am not willing to use it myself, but most people don't care that much about such things, and it's not like Slack is any better on that front.
This is not something "your marketer guy can easily use". And even for techies it has issues like lack of notifications (fixable), lack of non-suck mobile support, and, extremely important for me even if apparently not for some, typing latency (mosh is a partial solution but not good enough for me).
There are a few applications that use a daemon running a custom protocol to fix the scrollback issue: Quassel, Smuxi, weechat remotes, others. This is a decent approach in general, and the one that I use (weechat + Glowing Bear), but I haven't found any such applications with good mobile support or which are very high quality in general.
Maybe IRCCloud is the answer - has a spiffy web client and iOS and Android apps. It's a hosted service and non-free so I am not willing to use it myself, but most people don't care that much about such things, and it's not like Slack is any better on that front.
Semantically, an issue with posting links instead of files is that your users then need to go ahead and upload the file somewhere manually. HipChat takes care of this by adding the file to an S3 bucket when you drag it into the client. Way less hassle, especially for non-technical users.
Scalable chat itself has been solved, but the features the GP wanted were not part of that solution. For example "post links" means you now have to add an external service - that's not a "solved" feature. Likewise, screen/tmux is not a solution for non-techies like the stereotypical 'marketing guy'. Most people don't even know what a terminal is.
Any technical person in the organization could set those things up and have everyone, even the marketing guy, using it on IRC without any trouble in the course of maybe an hour.
This was actually a really entertaining telling of a boring old story about capitalist competition. Act I: We tried A, then we outgrew it. Someone said B was better. Act II: We tried B, then we outgrew it. Act III: By this time A had caught up to our needs, so we went back to A. End Credits
Yeah dude, wtf, 5000 users and you think you can get away for free?
OK, but if Slack has a user limit there's no reason it should be secret.
I'd guess it's not so much "a secret" rather than a natural limitation or just a "put a big number there that should be enough for everybody" (until it isn't)
Maybe it isn't intentionally a secret, but it should be documented. If you take the time to code a hard user limit (with its own API exception code, etc), you can take the time to mention it in the docs.
At least intuitively one doesn't think it would cost half a million dollars for a year.
This title is extremely misleading and should read "We Switched Our 8,000 Campers to Free Slack and Regretted It".
Even in a tiny organization (like <50 people) that starts using Slack, the plan would be to switch to eventually paying for it or look very hard at the limitations. Who builds a freemium service tier into their stack without looking at the limits!
It's not like slack is ad-supported, free is not its basic model.
Even in a tiny organization (like <50 people) that starts using Slack, the plan would be to switch to eventually paying for it or look very hard at the limitations. Who builds a freemium service tier into their stack without looking at the limits!
It's not like slack is ad-supported, free is not its basic model.
Drama Queen post of the year, good lord. Why don't you try figuring out what parameters the software you're using is designed to operate in before throwing such a public shit fit?
I find it super weird that new chat and messaging applications keep finding popularity.
It seems like most of the features could be had by using a sufficiently featurefull IRC and email client.
hmm. That could be an interesting project. Implement a social network using nntp, using public-key cryptography (with tight integration in the client) for access control. But seriously, I can see how some features of social networks would be hard to implement with nntp and clients... but I'm kind of missing out on why most of the newer chat networks are better than IRC.
It seems like most of the features could be had by using a sufficiently featurefull IRC and email client.
hmm. That could be an interesting project. Implement a social network using nntp, using public-key cryptography (with tight integration in the client) for access control. But seriously, I can see how some features of social networks would be hard to implement with nntp and clients... but I'm kind of missing out on why most of the newer chat networks are better than IRC.
I've had the pleasure of dealing with the Gitter team, and they are an awesomely talented bunch of devs.
I've always wondered why Slack gets so much love from engineers! It's noisy, it's expensive, and did I mention "noisy". It started as a copycat and didn't do much beyond that. The only thing I'm thankful to Slack about is that it's pushing HipChat to innovate. Finally we got multi-account support in there! Yes, I openly do like HipChat better - it's free, it's less noisy, it's coming from Atlassian, it integrates nicely into the Atlassian ecosystem, but there are alternatives like the open-source Rocket Chat [0] and Let's Chat [1], but Gitter is [2] is the best of those (like most of us) who use GitHub most of the day. Not sure why it doesn't get the love it deserves (but Gitter is expensive as well)!
[0] https://sdelements.github.io/lets-chat/
[1] http://rocket.chat/
[2] https://gitter.im/
[0] https://sdelements.github.io/lets-chat/
[1] http://rocket.chat/
[2] https://gitter.im/
Having used HipChat and Slack, I prefer Slack as a much better designed product. It's more stable, less buggy, and has more features.
> did I mention "noisy"
You did, but I have no idea what you mean.
> it's coming from Atlassian
One more reason to prefer Slack. I've had a lot of experience with Atlassian tools, and it's almost all been negative. Everything about Atlassian is slow: Their products, their support, and the pace of development. Submitting a bug report to Atlassian is an exercise in futility; if it's critical and affects hundreds of people, you MIGHT get reply within 2 years; you certainly won't get a fix that quickly.
One bug I hit was opened in 2007, got an official response saying "maybe we could look into trying to fix that" in 2009, was officially added to their backlog to fix in 2010, and was announced as officially fixed in 2011. Spoiler: It wasn't fixed, and for all I know, it's still broken.
The worst thing to happen to Hipchat was being purchased by Atlassian; it's when they stopped innovating and started stagnating.
> did I mention "noisy"
You did, but I have no idea what you mean.
> it's coming from Atlassian
One more reason to prefer Slack. I've had a lot of experience with Atlassian tools, and it's almost all been negative. Everything about Atlassian is slow: Their products, their support, and the pace of development. Submitting a bug report to Atlassian is an exercise in futility; if it's critical and affects hundreds of people, you MIGHT get reply within 2 years; you certainly won't get a fix that quickly.
One bug I hit was opened in 2007, got an official response saying "maybe we could look into trying to fix that" in 2009, was officially added to their backlog to fix in 2010, and was announced as officially fixed in 2011. Spoiler: It wasn't fixed, and for all I know, it's still broken.
The worst thing to happen to Hipchat was being purchased by Atlassian; it's when they stopped innovating and started stagnating.
People use JIRA and Confluence, because they are fully-featured, and complicated. It's easier to created a dumbed-down faster tool. Plus, they've been around for years. I'm sure one day they will rewrite them from scratch, but HipChat is not slow at all.
Using Slack for communities and groups of people who don't know each other is incredibly clunky. It still feels like trying to fit a square peg in a round hole.
Slack is made for teams who communicate furiously. Large communities are typically more passive and casual.
Slack is made for teams who communicate furiously. Large communities are typically more passive and casual.
We have adopted Slack recently with a small 12 person (and everyone knows everyone) team and it works great. It really brings down distraction of people coming over to ask questions, they can just ask the question of a group and get it resolved by someone. We have Lync as a company wide (1000s) community messenger but for small teams this works great for collaboration of small groups. I am actually shocked that Microsoft doesn't have a solution like Slack built into Lync (Skype for Business now.) I mean it's possible they could buy Slack...but anyhow Slack is made for smaller teams. If you want a community use IRC (non-corporate), Skype or Google (corporate), etc.
Seconded. I've used Slack at two companies, both with a small, single-purpose team (< 10 people). In each case I and the other users were quite happy with the features available, and the overall design of the app. It isn't for everyone, but I whole-heartedly advocate teams examine Slack for their communication needs.
"No way were we going to spread our community across a bunch of disparate Slack instances. The entire point of a chat room app is convenient real time conversation."
5000 users, plus 300-500 new users per day. In a chat.
Convenient real time communication, that is not.
5000 users, plus 300-500 new users per day. In a chat.
Convenient real time communication, that is not.
Been using Circuit [1] for a while and have to say I've been impressed, if the people over at Free Code Camp are reading this. The document sharing and solidly built iOS app sold me on it. Switching teams on the iOS app for Circuit vs Slack was far faster too which I always found frustrating on the Slack app. Document searching was really well built on Circuit too.
[1] https://www.yourcircuit.com/
[1] https://www.yourcircuit.com/
I really like Slack. Where I work each team has its own Slack chat with various channels. I work in IT, our more general team is about 30 people and my more focused team is 7 people. We have specific channels for each focus group, and then a general channel for the entire team.
Since we've used Slack I feel more up to date and more in the know because I can keep up with what everyone is talking about. I have keywords that give me an alert when someone mentions my name or specific things in which I specialize. I've been able to quickly offer help to those who might not have immediately thought to bring their issue directly to me as a result, and have had the same happen in regard to problems I bring up in channel. It reminds me very much of hanging out on IRC when I was a teenager, but an IRC built for business.
Sharing files, code, screencaptures, etc is easy and intuitive. The integrations are useful: GitHub, Zoom video conferencing, Dropbox - having these items easily available only make Slack blend more seamlessly into my day.
I like Slack, and reading this blog post I couldn't help but feel this was more a mismatch for the author's use-case than a problem with the application.
Since we've used Slack I feel more up to date and more in the know because I can keep up with what everyone is talking about. I have keywords that give me an alert when someone mentions my name or specific things in which I specialize. I've been able to quickly offer help to those who might not have immediately thought to bring their issue directly to me as a result, and have had the same happen in regard to problems I bring up in channel. It reminds me very much of hanging out on IRC when I was a teenager, but an IRC built for business.
Sharing files, code, screencaptures, etc is easy and intuitive. The integrations are useful: GitHub, Zoom video conferencing, Dropbox - having these items easily available only make Slack blend more seamlessly into my day.
I like Slack, and reading this blog post I couldn't help but feel this was more a mismatch for the author's use-case than a problem with the application.
BabelJS support chat that used gitter moved to slack, Reactiflux a React community uses slack. If think there is a real opportunity for slack to do like reddit with their subs for opensource software, they could monetize it with jobs offers. But for now if slack is more slick and fast than gitter we loose google searching, history.
What did you expect? You can't expect to hit such a ridiculously large number and not pay anything.
Au contraire.. People expect it all the time. They have a hard time getting that these "free" services are built by people that need to get paid and eat. Adding 8000+ users for an implied PR benefit is silly. What's the ROI? Not going to be very high, almost guaranteed. Because these free users might evangelize other free users because the service is "free."
You can have thousands of users working together on other platforms for free (e.g. Github) and Slack clearly advertises "$0 - no limits on time or users".
It still would be a very good idea to contact them before and ask "We're considering moving a few thousand users to your free plan. You sure you mean what you write there?", but they are sort-of saying that it is ok to do. (EDIT: especially since they say that the intend for that offer is for small teams)
It still would be a very good idea to contact them before and ask "We're considering moving a few thousand users to your free plan. You sure you mean what you write there?", but they are sort-of saying that it is ok to do. (EDIT: especially since they say that the intend for that offer is for small teams)
So I go to an all you can eat buffet, and stuff my face until I literally burst. "Hey it was written there clear as day!"
Yes, that is the idea behind an all-you-can-eat buffet.
And I don't complain about restaurants that don't offer them anymore or are not putting out unlimited amounts of expensive food (just like I can totally understand Slack not spending much effort to support these guys), but in the same way a restaurant offering them made the choice to do so and has to live with people stuffing their face.
To stay with the restaurant examples, for me OPs situation is more like they turned with a large wedding party to a pub and are now surprised not everybody gets a place at the bar and people have to wait for their beers.
And I don't complain about restaurants that don't offer them anymore or are not putting out unlimited amounts of expensive food (just like I can totally understand Slack not spending much effort to support these guys), but in the same way a restaurant offering them made the choice to do so and has to live with people stuffing their face.
To stay with the restaurant examples, for me OPs situation is more like they turned with a large wedding party to a pub and are now surprised not everybody gets a place at the bar and people have to wait for their beers.
Their first clue that maybe this was an issue is they had to hack an undocumented API to even get people onto the system. Slack is going to need to do something about this because they're increasingly being used for communities of strangers around a common interest.
Despite Slack doing everything they can to discourage this use case, there's a clear need there which Slack is filling. I'm currently part of 3 separate slack groups where this is the case. Either a "Slack for communities" forms to absorb that niche or Slack needs to start thinking of a service offering for these communities because they aren't going to go away and they're going to complain as vocally as free code camp when they don't get their way.
Despite Slack doing everything they can to discourage this use case, there's a clear need there which Slack is filling. I'm currently part of 3 separate slack groups where this is the case. Either a "Slack for communities" forms to absorb that niche or Slack needs to start thinking of a service offering for these communities because they aren't going to go away and they're going to complain as vocally as free code camp when they don't get their way.
I kind of think that Gitter is a joke and I'm not convinced they can do better than Slack. I mean their Android app has the balls to ask you to write your GitHub credentials.
Maybe Asana/plain IRC is a better solution.
Maybe Asana/plain IRC is a better solution.
Why not use IRC or some form of XMPP? Heck, just make a channel on Freenode and call it a day. Want integrations? Everything works with IRC already (maybe not all the one-click integrations).
Site does not resolve for me, here is the google cache link:
http://webcache.googleusercontent.com/search?q=cache:94NVni1...
http://webcache.googleusercontent.com/search?q=cache:94NVni1...
I am guessing there will be a post slamming blogger soon since that is the only page that is currently working.
The one thing that has me mostly abandoning Gitter is that switching channels is incredibly slow on the browser.
If Gitter had a standalone client, I'd be willing to give it another shot, but until then, I'm a proponent of using IRC & Slack.
If Gitter had a standalone client, I'd be willing to give it another shot, but until then, I'm a proponent of using IRC & Slack.
Mike from Gitter here. We've improved the performance of this quite a lot over the last few months and will soon start implementing local caching that will make this pretty much instantaneous.
Gitter does have standalone clients:
https://gitter.im/apps
In my experience they're no better than the web view.
I (and many others) keep up with Gitter rooms and IRC channels (Freenode, mostly) by bridging them to Slack or Kato with sameroom.io.
It's also a good way of merging interesting channels from the 15 Slack teams I am member of into one.
It's also a good way of merging interesting channels from the 15 Slack teams I am member of into one.
It does seem to be a bad fit. That's too bad for them, I really enjoy using Slack.
After reading this I have but one request; please stop teaching people to code.
Your solution to a problem you have with some software is to suggest they simple throw engineers at it is sadly pathetic.
Your solution to a problem you have with some software is to suggest they simple throw engineers at it is sadly pathetic.
[deleted]
I really wonder what the din of an 8500 person chatroom would be like...
This is what IRC if for numb nuts.
Jesus, what a mess. Sounds like someone made a decision without doing even a modicum of research into pricing. Bowing to peer pressure just means someone is managing by consensus.
Yep. Jumping to a platform about which you know nothing is asking for trouble, no matter the context.
Hard to really fault him since he ran into an undisclosed max user limit, no?
You can definitely fault him for not researching pricing. Even if there were no limit to teams the pricing alone does not work for his organization. Why would you switch everyone over?
No, slack free plan only allows 10000 messages to be saved at any one time. Nothing to do with user limit.
Unbelievable that a service like this would change the key part of their platform without even checking the pricing page to see what free plan restrictions were...
https://slack.com/pricing
EDIT: I stopped reading after the first paragraph, looks like there was a user limit issue too :)
Unbelievable that a service like this would change the key part of their platform without even checking the pricing page to see what free plan restrictions were...
https://slack.com/pricing
EDIT: I stopped reading after the first paragraph, looks like there was a user limit issue too :)
Except if you read the whole post, he ran into a previously undisclosed explicit user limit. The client was crashing. Slack ideally should warn you if you have too many users, before the point where the client crashes and the backend fails to send messages.
Even if they hadn't, the 10k message limit is well publicized and would have forced them into an insanely expensive pricing model.
Slack's pricing model and the ad copy of their website makes it obvious to me that it's a communication tool intended for small teams, not a chat room for thousands of users.
Slack's pricing model and the ad copy of their website makes it obvious to me that it's a communication tool intended for small teams, not a chat room for thousands of users.
But who runs a chat with 5000+ users? The signal to noise would be insane. If each user posted 1 message per hour, that's 5000 messages per hour. For a group that size it seems like Twitter makes more sense. I can't imagine 5000 people needing real time communication. Kind of the mother of all edge cases for a team chat service.
I don't think they are talking about 5000 users chatting in one chat room, but about 5000+ users having a common place to talk to others in small groups and maybe read announcements in a main channel.
My university uses Slack, and the "main" rooms see a few posts a day, but there are tons of small groupchats and DMs.
My university uses Slack, and the "main" rooms see a few posts a day, but there are tons of small groupchats and DMs.
It's usually 50-200 users online at a time, and out of that maybe 20-50 are chatting at least once a minute, so no, not 9000 users actively chatting at once.
There's plenty of IRC servers (which is probably the closest analogue to Slack) with more than 5000+ users. Sure, most of them have a #general channel, but nobody will see that one as the main channel; most will go to a more topical / relevant channel. That's how IRC works, that's how Slack should work.
The 10,000 message search limit probably limits this realistically to 5 or 10 person teams. I would think I would want at least a week or even a month's worth of searching (ideally indefinitely, of course).
[deleted]
Sorry slightly off topic. But I need to know this.
wait wait wait ... managing by consensus is .... bad?
Where can I learn more about this to build consensus at my office that this is bad (because consensus is how all decisions are made)?
wait wait wait ... managing by consensus is .... bad?
Where can I learn more about this to build consensus at my office that this is bad (because consensus is how all decisions are made)?
>because consensus is how all decisions are made
Not in any place were there is a hierarchy.
In most companies for example, there are CEO, managers, and middle managers, etc. They make a decision and you get to implement it. Ideally they'd like your consent to, but even if you don't consent, you don't get much of a say to what the company will do.
Not in any place were there is a hierarchy.
In most companies for example, there are CEO, managers, and middle managers, etc. They make a decision and you get to implement it. Ideally they'd like your consent to, but even if you don't consent, you don't get much of a say to what the company will do.
> because consensus is how all decisions are made
This is the crux of it. All decisions are not made through consensus and I would wager that's true at most companies.
This is the crux of it. All decisions are not made through consensus and I would wager that's true at most companies.
If there is real consensus on what should happen then nobody is managing, things are just happening.
But "managing by consensus" is forcing everyone to say they agree (hah!) about what the manager has already decided on. Depending on how much the manager has bought in it may either be 1) veiled authoritarianism or, worse, 2) a cult where they think this is helpful.
I can work with you without having been forced to agree.
But "managing by consensus" is forcing everyone to say they agree (hah!) about what the manager has already decided on. Depending on how much the manager has bought in it may either be 1) veiled authoritarianism or, worse, 2) a cult where they think this is helpful.
I can work with you without having been forced to agree.
But you should always move fast and break things, don't look before you leap. It's the startup mentality and it's the way real scrappy entrepreneurs do things.
That's just knee-jerk mentality, not necessarily associated with startups.
I was being a bit sarcastic, its just that sometimes I read these highly critical blog posts about "we made X decision with Y product and it sucks" where really the person who was responsible for the decision could have anticipated the consequences with five minutes of evaluation.
Slack's "sticker shock" is pretty big. I'm not sure if it's autodetecting and giving me Australian dollars in it's pricing, but in the first paid band it's showing me $6.67/user/mo for annual (who knows how many users a small team will have in a year?) or $8/user/mo for month-to-month (the usual pricing). $8/user/month for chat. And it's double that to get business-level SLAs. With 25 users in the account, including external teams and contractors, that would mean we're paying $200/month ($400 for business SLAs). Per month. For chat. Crazy.
And slackbot keeps on claiming any "thank you" that someone says, even if specified @someone, the greedy little bugger.
And slackbot keeps on claiming any "thank you" that someone says, even if specified @someone, the greedy little bugger.
Does Slack really use LAMP?
Why are you surprised? LAMP stack, only at this scale is not a bottleneck. Who knows, maybe they are not even using HHVM, yet. I would be blaming actual code, not the stack for the current trouble.
P.S. LAMP != shitty developers automatically
P.S. LAMP != shitty developers automatically
I was merely asking a question, not referring to the obvious downsides of LAMP.
However Slack seems to be really unstable for being an enterprise product. Communication is a backbone of any business and should therefor be rock-solid. 5000 user maximum? Seriously?
However Slack seems to be really unstable for being an enterprise product. Communication is a backbone of any business and should therefor be rock-solid. 5000 user maximum? Seriously?
Given their pricing model i don't think they expected anyone to try to have 5000 users...
Is the author paying for this service? If so - oh boy. Slack should have been more closely monitoring clients this big to ensure they don't reach self-imposed limits. That's just, heh, slack.
OK sure, I get that Slack wants to make money and doesn't want too many 'free' users. The restrictions themselves are acceptable to me.
However, their platform seems super brittle and janky if it can't handle the users in the first place. Seriously? 5000 users, 10,000 messages is a "Use Case" now? Sending out emails without fucking up needs "engineering"? Um. OK. Personally, I would be embarrassed if I put my name on a product that couldn't handle such an extremely light load for a platform that basically transmits text.
However, their platform seems super brittle and janky if it can't handle the users in the first place. Seriously? 5000 users, 10,000 messages is a "Use Case" now? Sending out emails without fucking up needs "engineering"? Um. OK. Personally, I would be embarrassed if I put my name on a product that couldn't handle such an extremely light load for a platform that basically transmits text.
Have you ever thought that they put those limits in there precisely so that situations totally inappropriate for slack don't occur?
I love how programmers are always "embarrassed" about the limitations of billion dollar companies, have you ever though that these limitations might be vital to their success?
I love how programmers are always "embarrassed" about the limitations of billion dollar companies, have you ever though that these limitations might be vital to their success?
It's difficult to argue that the limit is essential to their success if only a single user has ever hit it, and that only recently. Of course, we don't know that's the case.
There's nothing wrong with limits. Every piece of software has them, and even learning what they are is a major step. Known or explicit limits should be documented, however. It seems that in this case they were not. That's an error on Slack's part.
There's nothing wrong with limits. Every piece of software has them, and even learning what they are is a major step. Known or explicit limits should be documented, however. It seems that in this case they were not. That's an error on Slack's part.
>I love how programmers are always "embarrassed" about the limitations of billion dollar companies,
In my mind I picture a station wagon outracing a Ferrari. That would be cause for embarrassment. Your quotes seem to serve no purpose as far as I can tell.
>have you ever though that these limitations might be vital to their success?
You have much lower expectations than me. I don't see Slack doing something that is in any shape or form particularly challenging from an engineering standpoint.
In my mind I picture a station wagon outracing a Ferrari. That would be cause for embarrassment. Your quotes seem to serve no purpose as far as I can tell.
>have you ever though that these limitations might be vital to their success?
You have much lower expectations than me. I don't see Slack doing something that is in any shape or form particularly challenging from an engineering standpoint.
>Seriously? 5000 users, 10,000 messages is a "Use Case" now?
Slack has millions of users and billions of messages -- working alright.
5000 users were seeing slowdonws for a SINGLE team -- not across Slack. And 10.000 is a limit put by Slack intentionally in place as a freemium boundary.
All systems have breaking points, especially if they weren't designed for some specific use. You might as well ask "Twitter can't handle more than 140 characters now, seriously?".
>Personally, I would be embarrassed if I put my name on a product that couldn't handle such an extremely light load for a platform that basically transmits text.
Your answer doesn't show any understanding of network services at all, including as some guy already pointed out, the "basically transmits text" part, as if that is something trivial at scale...
Slack has millions of users and billions of messages -- working alright.
5000 users were seeing slowdonws for a SINGLE team -- not across Slack. And 10.000 is a limit put by Slack intentionally in place as a freemium boundary.
All systems have breaking points, especially if they weren't designed for some specific use. You might as well ask "Twitter can't handle more than 140 characters now, seriously?".
>Personally, I would be embarrassed if I put my name on a product that couldn't handle such an extremely light load for a platform that basically transmits text.
Your answer doesn't show any understanding of network services at all, including as some guy already pointed out, the "basically transmits text" part, as if that is something trivial at scale...
I said that I would be embarrassed. Your opinion does not change that. You obviously seem to have lower expectations than me.
Slack can handle "communities"—effectively groups with a "team"-sized aristocracy and a bunch of rarely-visiting people who mainly interact in a hub-and-spoke fashion with the team. But it's still not built for that.
Slack is emphatically not for societies: groups big enough that people only know a small percentage of others, groups that must create "laws" to prevent random strangers abusing your shared infrastructure, etc.
In fact, very few pieces of software are designed to cope with use by societies. Maybe Usenet (as a whole), IRC (an entire server, not a single channel), and Reddit (the code-base, run on your own server) are for societies.
If I were to come up with a way to host a chat adjacent to a MOOC, though, I'd still probably use Slack; I'd just have one Slack team for each instance of each course. (The one thing I do think Slack is missing, is a way to easily share your "Slack identity" (username, avatar, client display prefs, etc.) between multiple Slack teams you're concurrently logged into. Then you could be in two "classes" and be sure the same person is the same person in both; or Slack could even consolidate their Direct Message threads into a single one shared between both teams.)