It's pretty clear that Slack is not, and never will be, built for this use-case. Slack is for teams: small groups where everyone knows one-another by name, can be trusted with one-another's email-addresses and other contact information, can be trusted to only use @everyone triggers for important things, etc. A lot of Slack's features are built to assume this "small group with a shared purpose where everyone can be trusted to fiddle with things" paradigm.
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.)
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!
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.
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.
"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.
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.
> 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.
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.
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...
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 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.
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...
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.
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.
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.
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.
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.
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.
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).
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.
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.
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"
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 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.
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.
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.
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
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.
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?
[+] [-] derefr|10 years ago|reply
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.)
[+] [-] michaelq|10 years ago|reply
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!
[+] [-] _hadrian|10 years ago|reply
[+] [-] tchock23|10 years ago|reply
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.
[+] [-] greenyoda|10 years ago|reply
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.
[+] [-] Cthulhu_|10 years ago|reply
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.
[+] [-] nadams|10 years ago|reply
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.
[+] [-] x0x0|10 years ago|reply
[+] [-] pbreit|10 years ago|reply
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
[+] [-] mbesto|10 years ago|reply
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.
[+] [-] plorkyeran|10 years ago|reply
[+] [-] vacri|10 years ago|reply
[+] [-] andmarios|10 years ago|reply
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.
[+] [-] metasean|10 years ago|reply
[+] [-] nodesocket|10 years ago|reply
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.
[+] [-] cddotdotslash|10 years ago|reply
[+] [-] jonathanmarcus|10 years ago|reply
[+] [-] smm2000|10 years ago|reply
[+] [-] raverbashing|10 years ago|reply
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
[+] [-] dubcanada|10 years ago|reply
[+] [-] mtrpcic|10 years ago|reply
* 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.
[+] [-] joshstrange|10 years ago|reply
[+] [-] fredoliveira|10 years ago|reply
[+] [-] zak_mc_kracken|10 years ago|reply
irc is a dinosaur compared to what recent team communication software like Slack and Hipchat can do.
[+] [-] neilellis|10 years ago|reply
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).
[+] [-] wslh|10 years ago|reply
[+] [-] coned88|10 years ago|reply
Any irc or xmpp clients do not have these issues. products like Whatsapp and telegram don't have these issues.
[+] [-] dmourati|10 years ago|reply
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.
[+] [-] omni|10 years ago|reply
To be fair, it does seem here like the failure mode wouldn't have been reached until they moved all of their users over.
[+] [-] michaelq|10 years ago|reply
[+] [-] pavedwalden|10 years ago|reply
Everyone understands that "unlimited breadsticks" implicitly means "lots and lots but not infinitely many"
[+] [-] morgante|10 years ago|reply
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.
[+] [-] jlees|10 years ago|reply
[+] [-] skybrian|10 years ago|reply
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.
[+] [-] hrayr|10 years ago|reply
[+] [-] Sir_Cmpwn|10 years ago|reply
[+] [-] slyall|10 years ago|reply
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.
[+] [-] cactusface|10 years ago|reply
[+] [-] cechmaster|10 years ago|reply
[+] [-] eli|10 years ago|reply
[+] [-] Nemcue|10 years ago|reply
[+] [-] logicallee|10 years ago|reply
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.
[+] [-] modarts|10 years ago|reply