It's pretty clear that Slack is not, and never will be, built for this use-case. Slack is for <i>teams</i>: 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.<p>Slack can <i>handle</i> "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.<p>Slack is emphatically not for <i>societies</i>: 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.<p>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.<p>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 <i>one Slack team for each instance of each course</i>. (The one thing I <i>do</i> 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>"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."</i><p>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.
Here's the problem I have with this:<p>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".<p>2. Yet, one of the organizers of the company (?) states <i>"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."</i><p>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).<p>EDIT: Upon further review it looks like the person in question has a bit of an agenda...<p><a href="http://www.quora.com/What-are-the-pros-and-cons-of-MEAN-javascript-stack-vs-LAMP-stack/answer/Quincy-Larson?share=1" rel="nofollow">http://www.quora.com/What-are-the-pros-and-cons-of-MEAN-java...</a><p><a href="http://www.quora.com/Having-built-web-stuff-the-old-way-PHP-MySQL-back-in-the-day-and-wanting-to-build-a-new-account-based-web-site-app-that-can-handle-scaling-Whats-the-best-tech-approach-these-days/answer/Quincy-Larson?share=1" rel="nofollow">http://www.quora.com/Having-built-web-stuff-the-old-way-PHP-...</a><p>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.
I think you should have ran the math before switching to Slack.<p>A max limit of 10,000 messages history for your 8,500 free users, premium cost at $60/user/year.<p>An engineer designs a product for the specifications she/he is given. Slack's engineers were given the specs above and obviously designed and optimized their product for much smaller teams than yours.
A perfect illustration of the "entitled developer complex". Failure to properly research Slack, a bad use-case, complain about pricing, then publicly bash.<p>I've seen this repeatedly with my own startup (<a href="https://commando.io" rel="nofollow">https://commando.io</a>), 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 <i>not</i> to make a decision. Zero forethought of future needs? Check. Picking a solution not designed for the problem? Check. Complaining that something that wasn't designed to do x isn't doing x? Check.
What a hyperbolic post. There is no reason to put a company on blast like this. There is a real team of people likely working exceptionally hard to operate Slack. You could have just written a post extolling the benefits of Gitter, and gone about your day of adding more campers to your project. I'm guessing Slack didn't beg for your business or community endorsements.
I'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 <i>many</i> communities are using their free option with huge numbers. Rightly or wrongly.<p>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.<p>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.<p>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).
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.<p>Any irc or xmpp clients do not have these issues. products like Whatsapp and telegram don't have these issues.
Two things.<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.<p>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.
Look what I found: Slack's free tier pricing page explicitly states "There's no limit on how many people you can add to your team on Slack." <a href="https://twitter.com/FreeCodeCamp/status/612758062214950912" rel="nofollow">https://twitter.com/FreeCodeCamp/status/612758062214950912</a>
It sounds like they didn't do any research into what Slack's limitations are.<p>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.
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.<p>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.
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".<p>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!<p>It's not like slack is ad-supported, free is not its basic model.
Drama Queen post of the year, good lord. Why don't you try figuring out what parameters the software you're using is designed to operate in before throwing such a public shit fit?
I find it super weird that new chat and messaging applications keep finding popularity.<p>It seems like most of the features could be had by using a sufficiently featurefull IRC and email client.<p>hmm. That could be an interesting project. Implement a social network using nntp, using public-key cryptography (with tight integration in the client) for access control. But seriously, I can see how some features of social networks would be hard to implement with nntp and clients... but I'm kind of missing out on why most of the newer chat networks are better than IRC.
I've always wondered why Slack gets so much love from engineers! It's noisy, it's expensive, and did I mention "noisy". It started as a copycat and didn't do much beyond that. The only thing I'm thankful to Slack about is that it's pushing HipChat to innovate. Finally we got multi-account support in there! Yes, I openly do like HipChat better - it's free, it's less noisy, it's coming from Atlassian, it integrates nicely into the Atlassian ecosystem, but there are alternatives like the open-source Rocket Chat [0] and Let's Chat [1], but Gitter is [2] is the best of those (like most of us) who use GitHub most of the day. Not sure why it doesn't get the love it deserves (but Gitter is expensive as well)!<p>[0] <a href="https://sdelements.github.io/lets-chat/" rel="nofollow">https://sdelements.github.io/lets-chat/</a><p>[1] <a href="http://rocket.chat/" rel="nofollow">http://rocket.chat/</a><p>[2] <a href="https://gitter.im/" rel="nofollow">https://gitter.im/</a>
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.<p>Slack is made for teams who communicate furiously. Large communities are typically more passive and casual.
We have adopted Slack recently with a small 12 person (and everyone knows everyone) team and it works great. It really brings down distraction of people coming over to ask questions, they can just ask the question of a group and get it resolved by someone. We have Lync as a company wide (1000s) community messenger but for small teams this works great for collaboration of small groups. I am actually shocked that Microsoft doesn't have a solution like Slack built into Lync (Skype for Business now.) I mean it's possible they could buy Slack...but anyhow Slack is made for smaller teams. If you want a community use IRC (non-corporate), Skype or Google (corporate), etc.
"<i>No way were we going to spread our community across a bunch of disparate Slack instances. The entire point of a chat room app is convenient real time conversation.</i>"<p>5000 users, plus 300-500 new users per day. In a chat.<p>Convenient real time communication, that is not.
Been using Circuit [1] for a while and have to say I've been impressed, if the people over at Free Code Camp are reading this. The document sharing and solidly built iOS app sold me on it. Switching teams on the iOS app for Circuit vs Slack was far faster too which I always found frustrating on the Slack app. Document searching was really well built on Circuit too.<p>[1] <a href="https://www.yourcircuit.com/" rel="nofollow">https://www.yourcircuit.com/</a>
I really like Slack. Where I work each team has its own Slack chat with various channels. I work in IT, our more general team is about 30 people and my more focused team is 7 people. We have specific channels for each focus group, and then a general channel for the entire team.<p>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.<p>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.<p>I like Slack, and reading this blog post I couldn't help but feel this was more a mismatch for the author's use-case than a problem with the application.
BabelJS support chat that used gitter moved to slack, Reactiflux a React community uses slack. If think there is a real opportunity for slack to do like reddit with their subs for opensource software, they could monetize it with jobs offers. But for now if slack is more slick and fast than gitter we loose google searching, history.
Their first clue that maybe this was an issue is they had to hack an undocumented API to even get people onto the system. Slack is going to need to do something about this because they're increasingly being used for communities of strangers around a common interest.<p>Despite Slack doing everything they can to discourage this use case, there's a clear need there which Slack is filling. I'm currently part of 3 separate slack groups where this is the case. Either a "Slack for communities" forms to absorb that niche or Slack needs to start thinking of a service offering for these communities because they aren't going to go away and they're going to complain as vocally as free code camp when they don't get their way.
I kind of think that Gitter is a joke and I'm not convinced they can do better than Slack. I mean their Android app has the balls to ask you to write your GitHub credentials.<p>Maybe Asana/plain IRC is a better solution.
Why not use IRC or some form of XMPP? Heck, just make a channel on Freenode and call it a day. Want integrations? Everything works with IRC already (maybe not all the one-click integrations).
Site does not resolve for me, here is the google cache link:<p><a href="http://webcache.googleusercontent.com/search?q=cache:94NVni1b_A4J:blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-and-we-deeply-regretted-it.html+&cd=1&hl=en&ct=clnk&gl=us" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:94NVni1...</a>
The one thing that has me mostly abandoning Gitter is that switching channels is incredibly slow on the browser.<p>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.
After reading this I have but one request; please stop teaching people to code.<p>Your solution to a problem you have with some software is to suggest they simple throw engineers at it is sadly pathetic.
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.
Slack's "sticker shock" is pretty big. I'm not sure if it's autodetecting and giving me Australian dollars in it's pricing, but in the first paid band it's showing me $6.67/user/mo for annual (who knows how many users a small team will have in a year?) or $8/user/mo for month-to-month (the usual pricing). $8/user/month for chat. And it's double that to get business-level SLAs. With 25 users in the account, including external teams and contractors, that would mean we're paying $200/month ($400 for business SLAs). Per month. For <i>chat</i>. Crazy.<p>And slackbot keeps on claiming any "thank you" that someone says, even if specified @someone, the greedy little bugger.
Is the author paying for this service? If so - oh boy. Slack should have been more closely monitoring clients this big to ensure they don't reach self-imposed limits. That's just, heh, slack.
OK sure, I get that Slack wants to make money and doesn't want too many 'free' users. The restrictions themselves are acceptable to me.<p>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.