We Tried Slack and Regretted It
blog.freecodecamp.com
blog.freecodecamp.com
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 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!
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."
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.
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.
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.
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.
Why would you think all 100,000 of those students would need access to each other through a collaboration tool like Slack?
Any idea what their experience was like?
[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.
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.
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".
Larger groups are playing with that $5/user/month bonfire.
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.
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.
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.
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.
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.
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 someone prefers IRCCloud or Slack's features and support, it can absolutely be worth more than the sum of bandwidth, storage, and CPU.
Considering they have tens of millions in ARR, the market has proven you wrong.
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.
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.
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 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.
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?
forum/chat advertising is just not particularly valuable
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
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.
...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...
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.
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.
It would be interesting though to know how many students used slack for Harvard's online CS50 and how it worked for them.
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.
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.
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
* 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.
I always feel like IRC is a few protocol extensions and a few clients away from being relevant again.
/me goes back to Freenode
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.
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.
That being said, their pricing is probably no better than Slack's for this purpose ($5/user/month).
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 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.
irc is a dinosaur compared to what recent team communication software like Slack and Hipchat can do.
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).
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.
To be fair, it does seem here like the failure mode wouldn't have been reached until they moved all of their users over.
Everyone understands that "unlimited breadsticks" implicitly means "lots and lots but not infinitely many"
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.
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.
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.
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.
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.
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 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.
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.
Disclosure: I work for IRCCloud :P
(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.
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.
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.
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.
> 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.
Slack is made for teams who communicate furiously. Large communities are typically more passive and casual.
5000 users, plus 300-500 new users per day. In a chat.
Convenient real time communication, that is not.
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.
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)
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.
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.
Maybe Asana/plain IRC is a better solution.
http://webcache.googleusercontent.com/search?q=cache:94NVni1...
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.
It's also a good way of merging interesting channels from the 15 Slack teams I am member of into one.
Your solution to a problem you have with some software is to suggest they simple throw engineers at it is sadly pathetic.
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...
EDIT: I stopped reading after the first paragraph, looks like there was a user limit issue too :)
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.
My university uses Slack, and the "main" rooms see a few posts a day, but there are tons of small groupchats and DMs.
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)?
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.
This is the crux of it. All decisions are not made through consensus and I would wager that's true at most companies.
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.
And slackbot keeps on claiming any "thank you" that someone says, even if specified @someone, the greedy little bugger.
P.S. LAMP != shitty developers automatically
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, 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.
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 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?
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.
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.