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.
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...
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.
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.
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.
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.
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).
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?
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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...
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.
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.
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.
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.
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 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.
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.
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...)
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.
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.
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.
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.
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.
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...
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.
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.)
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!
> 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.
"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.
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."
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.
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.
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.
> 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.
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".
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 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.
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.
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).
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.
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.
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?
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.
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.
(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.
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.
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.
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.
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.
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.
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?
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.
>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.
>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...
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)
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.
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
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.
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.
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?
191 comments
[ 2.2 ms ] story [ 224 ms ] threadUnbelievable 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 :)
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)?
This is the crux of it. All decisions are not made through consensus and I would wager that's true at most companies.
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.
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.
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.
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.
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.
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.
* 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.
You should kick them out for repeated DDoS attempts on their IPs, like any sane host does.
irc is a dinosaur compared to what recent team communication software like Slack and Hipchat can do.
Slack is made for teams who communicate furiously. Large communities are typically more passive and casual.
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!
[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.
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.
Any idea what their experience was like?
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.
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.
Why would you think all 100,000 of those students would need access to each other through a collaboration tool like Slack?
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.
Maybe Asana/plain IRC is a better solution.
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?
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.
(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.
Disclosure: I work for IRCCloud :P
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.
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.
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.
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...
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.
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
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.