It sounds like more of an engineering issue. I'd imagine that unlimited-up-to-the-capacity-our-system-can-handle is reasonable.
The biggest takeaway from this should be: if you think you might be pushing a system, you should probably talk to a human first to get confirmation on how it will work for your specific scenario, and not just use their sales page.
Particularly when that tool is so important to your operations.
>> The biggest takeaway from this should be: if you think you might be pushing a system, you should probably talk to a human first
Two things:
a) I wouldn't blink at 10k if my line in the sand was "Unlimited number of people" (would I similarly ask a human if Amharic glyphs are supported if the advertisement suggested "chat in all languages"?)
b) It may behoove me to verify claims before jumping in, but it is absolutely 100% the responsibility of the organization to set expectations in line with what it can deliver
To be fair to slack, the quote is "there's no limit to the amount of people you can add to your team". They're saying that as you team grows, there's no limit.
Not students or subscribers. Not "public channel", or "chat room", or some sort of phrase that indicates a large mass of people.
If someone decided to sue them or something, I'd assume they'd have an easy defence saying they clearly meant a team of work colleagues. As many others are saying here, slack simply doesn't seem to be aimed at this use case.
It might if they were paying for 10000 users but only some power of 2 less than 10000 could actually sign up. And Slack refused to refund the difference.
False advertising regulations aren't a company destroying "gotcha" like felony theft, they are designed to protect consumers from fraud. Having some technical issue that doesn't impact the vast majority of consumers isn't what it's designed for.
On a service where all paid plans charge per user, starting to pay when you reach a point when their free plan is no longer suitable for your high number of users is always going to be a ridiculous proposition for even the cheapest plan. The Slack pricing structure is not designed for this use case.
Sounds like most of the issues were due to not paying for the product. Which is fair given Slack's freemium model but I wonder if they were throttling free users after a certain point, causing performance issues. If I was this guy I would've reached out to Slack's sales team and explained the situation to see if they could offer a compelling deal. They might've seen a huge discount as worthwhile given it would get 5000+ coders using Slack regularly, many of whom would then promote in other companies.
If you read the article, it's clear the user limit was a technical limit and not a freemium limit. So even if they did pay, Slack would still not have been able to accommodate all their users.
Which leads me to my old-timer question: What's wrong with IRC?
I like IRC, recently started using irccloud. That makes sharing files easier, also keeps a history of the irc channels you are in, and makes it look more pretty.
It's a combination of both worlds I suppose. So far I am enjoying it.
There's nothing wrong with IRC except for the fact that the user experience in an IRC client is generally horrible. They're not pretty, there's no good account system so users can easily spoof being someone else, the logging isn't great by default, sharing files is hard, and whether or not you can do media embedding depends on the channel setup.
There's a reason why companies like Slack have built billion dollar businesses doing ostensibly the same thing as IRC, and it's because IRC doesn't offer enough value even if it's free.
> there's no good account system so users can easily spoof being someone else
Probably the big one for me; I know my previous boss was asking if there was a SSO option because that would be the only thing he saw as limitation in IRC.
I contend that my question was slightly snarky. As someone who moves from computer to computer a lot, having a unified client is quite critical. With IRC and Bitleebee, I can combine a lot of protocols in one client, keep it running in a screen, and access it via SSH.
I realise my setup is hardly common, and I contend that the main issues with IRC are the clients and the account systems. However, both those issues (among other issues) could be resolved with the IRC protocol, allowing people preferring other clients to continue to user their clients.
Message logging and account management can be done server-side (e.g. closing connections on users if they don't log in), and with a dedicated client to this server, the logging in-part could be done rather seamlessly, even if posing slightly more 'troubles' for other IRC clients.
But as implied in the other replies to my post, but is there any money in that? Maybe licencing the servers? I dunno. I'd love to do something like that, but it would be a full time effort, I fear.
> With IRC and Bitleebee, I can combine a lot of protocols in one client, keep it running in a screen, and access it via SSH.
At which point you're not really using IRC. You're using the Bittleebee-commands-over-SSH protocol.
This protocol has a number of issues: it requires having a server with a unix user account running on it (which is a massive attack surface, no-one can offer a server like that for free or it will be used to DDoS other people etc). Its phone apps are poorly integrated and drain battery. Its UI in general is very undiscoverable; the logging interface is still pretty awful (e.g. tracking of how far you've read is pretty poor). Sending files or voicechatting is even harder than it is in vanilla IRC.
> both those issues (among other issues) could be resolved with the IRC protocol, allowing people preferring other clients to continue to user their clients.
Slack offers an IRC gateway, which gives about as good an IRC experience as any extended-IRC protocol ever could.
I apologise, I wasn't clear. I primarily use IRC, but I also use Bitleebee, but it isn't my primarily protocol(s). I just meant that I could combine all these protocols in one client.
As for Slack's IRC gateway, I think it's pretty decent, yes. I personally prefer it to Slack's own client (again, that's just me). But this is what bothers me about Discord, because that doesn't offer an IRC gateway, and I am forced to use their client(s).
And if you're like me - which apparently few are - and you are in many different communities, that use different protocols to communicate, having a bunch of different clients just means more hassle.
Most of the communities I'm part of are onto Discord now, and that's a lot nicer experience in terms of having them all in once place than Biteebee ever was.
I'm all for federation and open protocols, I wish Discord had gateways and I'm hopeful for Matrix. But I don't think IRC is the answer: it's inherently without identity, inherently text-only, inherently historyless. These problems can't be solved well without protocol changes, but for whatever reason IRC has developed a community that is hostile to any protocol improvements and preferes to encourage ad-hoc hacks for these aspects, none of which works well and most of which don't work at all.
I definitely agree that IRC would do well to have improvements, like an IRC/2.0 protocol. But no one is willing to get involved, likely because A) they don't want to develop a standard no one will use, B) get bogged in draft committees for years and C) they just aren't motivated.
I only proposed intermediate solutions, because I thought that would be more likely to actually amount to something. Kind of like when Google did SPDY to push for HTTP/2.0, but you'd need a player the size and with the interest of Google to do IRC/2.0. Someone to make the decisions.
It's almost ridiculous that something as ubiquitous as instant communication doesn't get more serious attention.
I don't think building it as a tower of IRC extensions will ever work. You get stuck on "good enough", and the IRC userbase is aggressively anti-centralisation (far more so than the HTTP userbase), anti-change even, and text-oriented.
I've long since given up on any effort to make IRC good. I think energy is more productively spent on ground-up protocols that can include the good parts of IRC but also solve the problems I mentioned. Matrix is where most of my hope is going at the moment.
Check out Kiwiirc, it's pretty good looking! A decent front-end team could build a nice interface.
Of course. But they haven't. Kiwi isn't bad for an IRC client, but it's way behind Slack.
I believe that NickServ takes care of this.
Nickserv is hard for a typical user to understand. The number of times someone thinks they've registered a name when they actually haven't demonstrates that. Ghosting makes it harder too.
I used IRC for about a decade. I used even more esoteric online chat services like telnet talkers and MUSHs too. They're great if you learn how to use them. But that's the key difference - you don't need to learn Slack. It works how you'd expect it to work. A user can just pick it up and do things with it. That's a massive difference, and possibly the main reason why Slack can charge a decent price for their product.
IRC lacks a well designed UX that works cross platform (desktop cross os, mobile, web) and an easy API to integrate and play with other services like Github.
Only if you use plain IRC. If you use something like irccloud, that is prevented. Which can be thought of as a "webwrapper" for IRC. I have been using it for some time now and I enjoy it.
I use WeeChat (https://weechat.org/, running on my server) and Glowing Bear (https://github.com/glowing-bear/glowing-bear) to connect to it from wherever I am (desktop or mobile), it works very nicely. Because it's self-hosted, it has higher setup overhead than signing up to slack, of course. But it does solve IRC's mobile and multi-device problems for me wonderfully. (I'm one of the Glowing Bear developers)
To be fair, Slack never really said it was made to support that many users. Even in my team of less than 20 on the free tier, we hit the 10,000 message limit really quickly. I can't imagine how that must have been with 8 thousand users.
The author's expectations just seem wildly unrealistic, I can't find much sympathy. Signed up for a pay service with a clear limit on the trial, yet was surprised by the limit, even though he knew how many Slack users he had and knew or should have known how many messages per day they were already sending. Put his community (customers) of thousands on the Slack team, even though the advertising and economics only make sense for internal teams. He is trying so hard to make his own mistake sound like Slack's fault.
They did hard code a limit, the API has a specific error for that. They just choose not to disclose it, and to advertise with the phrase "Slack is free to use for as long as you want for teams of all sizes."
This is a completely legitimate point. They are expecting "team" to be self explanatory, and it is a vague term that is not self-explanatory. If there's a size limit, it would be best if they stated that plainly.
But, come on, you have to admit that an online community of thousands of people does not fit even the most charitable interpretation of the word "team".
> But, come on, you have to admit that an online community of thousands of people does not fit even the most charitable interpretation of the word "team".
That is basically what the whole thread and article evolves about. Are 10k people a team? Really? Sure, you can argue all day that technically it may be the case, the whole world could be my team, some kind of super team and so a service shouldn't make any assumptions and so on, but reality is that everyone who hears "team" has a pretty good idea of a ball park figure how many people that will be and that freecodecamp doesn't fit into this. So, in the end it's just playing around semantics "but, but, but ... you said of any size .."
The whole world is not a team. You can only say that if you're making an intentionally, consciously hyperbolic statement.
I am not interested in long and un-ending pedantic arguments about the extreme corner-case definitions of words. I maintain that an online community of 10k people does not fit even the most charitable meaning of a working "team". If that doesn't work for you, then you're only setting yourself up for surprise.
This argument that "any size" should really mean "any size" amounts to someone walking into an "all-you-can-eat" buffet and expecting to be able to sit at the same table for 2 weeks eating all meals for the price of one, and then complaining that the 'all you can eat' advertisement should overrule all other policies the restaurant has.
It would be the same as someone seeing an ad for mini-golfing for $20 for a family of any size, and then bringing four thousand of your 2nd, 3rd, and 4th cousins, and demanding that the entire group gets in for $20. While there's a pedantic, technical truth to cousins belonging to your 'family', it doesn't meet anybody's common understanding of what an ad for family prices means, even the person trying to cheat the system.
If the author truly didn't even suspect that his 10k users is a massive stretch of the idea of a "team", the message limits should have been a clue, but instead of acknowledging he was pushing the limits, he blamed Slack.
"For teams of all sizes" is pretty deceptive. Even if the limit was disclosed somewhere deeper, advertising with a fundamentally inaccurate line is unfortunate.
While their language was poorly chosen, I think what Slack meant was that their free tier was under no additional restrictions than their paid tier for team size, which seems reasonable.
And signing people up with an undocumented API that skips a big amount of signup friction seems like a recipe for running into undocumented limits. Would we be upset with Slack for not supporting 1 million user teams? 1 billion? 1 trillion?
At a "team" size of 5000, the 10000-message limit means you each get 2 messages before things start disappearing. So I think the message limit pretty strongly implies a team member limit.
You appear to have not read the article. The very first complaint is about the 10k message limit warnings. The author then complains "Slack would aggressively archive messages, sometimes only minutes after they were sent." He's lucky the messages even went through. He asked Slack for guarantees, after the fact, on the free plan with no intention of paying Slack's rates. Even the user limit problem is silly. It's called a team and marketed for internal use, not as something you 're-sell' or offer customers. It's obvious that putting your users on a single Slack team is not going to scale to tens of thousands of people, as soon as you start using Slack. My point here is that the author did not do his homework before he moved his thousands of users to Slack, and your point falls squarely under this lack of effort.
His point, which you have missed, is that although the archive thing was a problem, it may been their own fault. However, the number of users allowed was not, plus paying for the service wouldn't change that the cap exists.
My point, which you have missed, is that the author should have uncovered this cap before moving his community. It was clearly on sketchy ground before he did it. You can't say anything about what paying would have done, because he had no intention to pay. And if he had paid the 0.5 million, I'd be willing to bet that Slack would attend to his needs. But none of that happened, so it's a straw man.
Please share your method of uncovering, in advance, undocumented limits inherent in software; it's desperately needed.
The guy left a free trial for another free trial; if he's at fault we're all at fault every time we change our go-to software. The lesson might be that "there be dragons" - you should guess that any "better" program or SaaS out there is less that half of what it says once unknown limits have been discovered.
Customer: Hello vendor, we're a customer with tens of thousands of active users and no intention to pay. How many users can you support in your free tier? How do you handle situations with high message volumes?
You should engage with the vendor. Perhaps there are intangible benefits to the vendor for you to use them even at no cost (PR, testing opportunity, etc)
Generally speaking, if you are dependent on a free service to do your business, you are fucked. A friend is a policy consultant who relied on Google Reader to be his knowledge repository. He bills the equivalent of $800/hr and was nearly paralyzed as it went away.
It's called "due diligence", and people do it all the time.
He didn't change his own personal go-to software, we're not talking about a trial of a video game here. He changed the software for thousands of his users. He put thousands of people on a free trial for something that was not obviously going to work.
You do have the option to investigate before you make that kind of move. If you choose not to exercise it, you don't have that much ground to stand on when things don't work out.
The due diligence in this case would have been researching the user limits which (as others have pointed out) were not published or advertised anywhere.
There's a reason it's called "diligence", because it typically involves trying. Personally, I don't count reading a company's ad copy on their own web page as being even remotely diligent or doing much research. Normally 'due diligence' involves talking to the party you intend to engage with, as well as talking to others who have experience with that party. The author didn't mention any of that.
Other users here also pointed out that there is a known specific API error message for the user limit. That kind of thing could be uncovered with a little diligence. Author could also have setup a fake team and tried to add many users before putting 8k real users on the team and just hoping.
He did finally start talking directly to Slack only after he started having trouble, and they responded and disclosed the existence of a team size limit. This obviously could have happened before hitting the limit.
The author expressed incredulity at what would be a $500k price tag, and yet completely fails to see why that is a massive glaring red flag. That alone should have been enough signal that his plan was skating on thin ice, but instead he drove right past all the warning signs and then blamed Slack for it.
Trying a huge number of users? How without migrating?
He could have asked innumerable questions all of which contradicted the description of what he was getting. He couldn't have known which was the right question. I very rarely query in person before a purchase; I did recently and was given a flatly wrong answer on one question, and then a very positive answer that wasn't logically coherent (strongly suggesting a no, in truth) on a second question. I'm buying anyway, but unless you can phone a corporate head, querying customer support for arcane technical information is rarely a great way to get the right answer, in my experience (sorry to say.) UNLESS you already have a proven fail, of course - which he did.
If it were my program there'd be an error message in there no matter what the upper limit was; I assume others are as competent.
I also don't follow your logic re the high price tag somehow logically entailing a secret limit on the free product - unless you're implying that it's a trap, a way of phishing for phools. (In my country, an illegal bait and switch, actually.) That's something that doesn't work too well when you're peddling to corporations, the pool is small and word gets around too fast.
Yeah me too, for things I buy for myself. But it's absolutely the norm for software purchases of $500k. That's what everyone does, it's extremely common practice for any org purchase of software for over 100 people.
If the author were actually looking to spend $500k, he definitely would have called first and done a bunch of research. Nobody spends that much without talking to someone. The only reason he didn't have that dialogue is because he thought he'd get the whole thing -- apparently a $500k value -- for free.
That's what I mean about the price tag being a signal. It should have signaled a phone call, at the very least.
Hahahaha! I upvoted you because that's funny. But word to the wise; this kind of comment, even if you're joking, can get flagged and backfire badly on HN.
If you're serious, I'd like to invite you to share your reasoning for your insult. I gave a direct answer to a direct question from @Nomentatus, and had no intention of saying something inflammatory.
You're correct, I did use sarcasm; I probably did come close near the edge. Certainly had I been appalled in a poor cause my comment would have been flaggable. So I'll bear your reservation in mind, although I do find wit too tempting to keep it to myself, usually.
My family is in part Prussian, and this is an example, now that I look at it, of fabled Prussian sarcasm, which I became familiar with (at the sharp end) from my grandmother, and didn't like, much.
Oh, hey, your comment was fine! Don't worry, you didn't do anything wrong. :)
My comment immediately above wasn't directed at you at all. I replied to @cammio who said only "troll" in response to me. His commment did get flagged and was later killed. I suspect when that happens, some people can't see the dead comment, depending on their profile settings. My comment was getting upvoted until the one I replied to got killed, and then it started getting downvoted, so I was suspecting other people also couldn't tell what I had replied to and mistook it for you. I should have quoted what I was replying to. C'est la vie.
> It's called a team and marketed for internal use, not as something you 're-sell' or offer customers.
Do you have a source for that information? One of the roles of Slack[0] is named "Member" not "Coworker".
> the author should have uncovered this cap before moving his community.
He tried: Slack said there was no limit, yet there was. Even Slack themselves mention starting with a "pilot team"[1] to demo; which wouldn't have discovered the limit either. How would you discover it?
How about "Slack for Teams is a single workspace for your small- to medium-sized company or team."? https://limnu.slack.com/pricing
But your question presumes that the word "team" isn't enough, and that the implied team size that comes with a 10k message limit also isn't enough. Why?
I think he's being a little bit to hard on Slack. He was really stretching a free trial offer beyond its limit. If he was a paying customer then I might have cut him some slack.
What I understand is that author did a trial and hit technical limitations in the desktop and mobile applications, I think that paying extra would not had help. Probably the slack developers did not tested with such a large number of users, it reminds me when I worked on a rss feed application and we were testing with 40-50 popular feeds, then a client shows up with more then 1000 rss feeds , I end up grabbing his feeds and testing with all of those and optimize the application(We did not expect someone would had so many feeds).
I switched over a large group of friends from using a gazillion hangouts to slack and it's mostly been an improvement. That being said, there's a lot less of us: around 30.
I'm definitely disappointed to hear about this. The pricing model sucks for us as well since it means $60 a head to add someone to the friend group if we wanted to pay for slack. If we could pay a fixed price and get a slightly better message history and more integrations, I'd gladly pay it, but per-head is just ridiculous.
We also use Discord for online gaming since it's easier to invite people outside the group. It's been absolutely fantastic, but we had issues with some people not having access at work.
Slack isn't intended for "friends". Their business model is clearly aimed at supporting teams inside businesses. $60 per head is absurd for a tool to chat with friends but pretty reasonable for a business that gets real value from the tool.
I think you're selectively reading what you want to see. Slack's title line is "Where Work Happens". Work, teams, and productivity normally are not terms you use to describe chatting with friends.
Similar situation on El Capitan.. it doesn't crash the browser but gives a lot of "Safari Web Content quit unexpectedly." I felt like it had to be just me because how could something so glaringly obvious be the case for everyone and they not fix it?
Try blocking Javascript for medium.com? I'm sure there's a plugin for that, but use Firefox for general browsing on all platforms where it's a thing, so can't make a specific recommendation. I do have the same problem in Safari on iOS 9.3.5, but I suppose that must have tab isolation, since the whole browser doesn't go down.
Ublock's advanced features are pretty nice + handy for selective script enabling/disabling. It does it by origin rather than kind of course, but if you're looking for a quick toggle you might already have one in your toolbar :)
Hm. Well, that made me a bit concerned to start, as I'm working on a Slack-based hack-and-slash RPG [1] that I'm planning on running entirely on their free tier, but I'm pretty sure that their use cases differ from mine significantly. I'm not worried about message archives (as it's just game history), and I have @here/@all locked down significantly.
The "max user size" thing is a bit worrisome, but MMOs have a history of sharding to solve that problem anyway, so hopefully that shouldn't be a problem either. (Players will be able to chat together in a shared Discourse forum, so sharding shouldn't really hurt community-building.)
I wonder if any progress has been made since then to support larger teams, though? It's been quite a while, and Slack's engineering team has been cranking out a lot of great features and improvements lately.
Are you planning on trying to make money with this? If so, you're in some amount of trouble, depending on how much you're looking at trying to make.
If you're not trying to make money, you still should check the agreements for Slack; this may constitute abuse.
You should also take a look at your architecture, too. You've got a clear message bus where you send things to and receive things from Slack. You may notice that where those messages go matters less to your code than you may think. If you find you can't go with slack, it may not be all that hard to simply set up a web site that plays your text-based game by shimming the message flow in and out, in which case you can do whatever you like, at whatever rate you like. Despite the slick name, you may not need Slack at all. You'd still have the conceit of the chatbot experience, which will definitely appeal to a certain niche, just as MUDs did.
(And that name may be too slick. I don't know how nasty Slack is inclined to be, but directly referencing brand names in your name like that is dangerous from a trademark perspective.)
I don't think I trip up the agreements anywhere, I've checked over them a few times and also emailed Slack to ask if it was cool if I made a game on their platform before I started. I didn't share too many specifics (I said it was MUD-like and was going to use their buttons), but they told me to go for it, so I think I'm in the clear there.
Also, while I haven't figured out monetization, I don't think there should be any real problems with that either. Other people charge for their slack bots and integrations, so unless they specifically have a problem with a game-style slackbot charging money, there shouldn't be anything preventing me from charging for stuff.
You very well may be right about the name, though. I've just registered "chatandslash.com" as a backup that I can switch to before too much marketing has gone forward, and I've already emailed Slack again to show them what I've come up with and for further confirmation that what I'm up to is fine and dandy before progressing any further.
Oh, and you're totally right about shimming out Slack with my own frontend. It's in the backlog of stuff to do some day potentially, but I think there's a lot to be gained in the meantime by explicitly staying with Slack in the meantime. "An RPG you play in Slack" is a lot more interesting than "An RPG that looks kinda like chat, I guess".
* No noticeable performance hit for high user volumes
* Wide variety of interfaces and integration bots to choose from
* Widely deployed and trusted across tech communities
It's called IRC.
Edit: I can tell more people are encountering challenges using Slack these days. In the past, a suggestion to use IRC would have been downvoted to hell and back!
A lot of people seem hung up on the history, file sharing, or some other feature that Slack has, so I thought I'd take a moment to expand on my ideal setup and how they translate from Slack:
* Long-lived documentation and important team knowledge: Wiki pages (which I prefer even when using Slack and pins or history search are available). Full history of edits is visible and it's easy to access/search.
* Discussions involving a large number of stakeholders: Email. Threads and the async nature of the protocol make it well-suited to discussions when users aren't all online at the same time and the discussion is more thoughtful and isn't moving quickly. Slack threads suck replies aren't very visible and history scrolls quickly in active channels.
* Discussions involving outages, current tasks, and other immediate needs: IRC. It's real time, cross-platform, etc. History can be archived for later searching, but CHAT HISOTRY != DOCUMENTATION. Post-mortems and that sort of thing should end up in a wiki or similar.
* File sharing can be done via some other service with a link pasted into chat. One extra step to paste the link manually isn't a big deal.
- Commonly addressed with logging bots and a link to the log in the topic
- Some clients have this: when you drag an image into Glowing Bear (a web frontend for WeeChat that I'm working on), it gets uploaded to imgur and a link to the image is pasted in the channel. It can also display images and videos inline if you wish.
- Easily handled with services like push{over,bullet}
The problem is that these things don't work out of the box and that there's a learning curve. It's just not a very friendly experience for newcomers.
* no native scrollback/history - IRC bouncers solve this problem, but it's not a plausible solution for most non-techies
* the last two issues also mean that mobile solutions are going to be lacking.
It's possible to have IRC as fully featured as slack, but it does mean either rolling your own solution, or using a lot of other software to accommodate everything and everyone.
If I want to ask my coworker René for a quick bit of knowledge, a phone call is too disruptive and too urgent, and an email might not be answered for a few hours. Slack/hipchat/irc are the perfect medium for "hey, do you know off the top of your head why X is Y?"
Sometimes I fail to answer slack messages for a good chunk of time, with email I only have to pay attention to one notification and can handle all communication from the same interface (and you have to use email anyway).
I don't think there is anything inherently slow about email, or that firing off one without a carefully crafted subject would be bad manners. Might be a personal preference, nevertheless I don't think there is any technical advantage in using an instant messaging service.
* file uploads in your chat client are misplaced at best, and "rich" environments with formatting and images are 99.999% distractions
* channel services can provide archiving and notifications.
* scrollback can be handled by a bouncer, yes, but it's up to the IT dept to set it up per-user
* there are plenty of usable irc clients for mobile, web, and desktop to satisfy this need.
source: Started using telegram/slack but productivity went down so work launched an internal ircd (inspircd). Internal wiki, git, and sharepoint for documentation/files/code where it belongs. Not the chat client.
> * file uploads in your chat client are misplaced at best, and "rich" environments with formatting and images are 99.999% distractions
Nope. They're extremely useful. Just offhand I can think of tons of times we've (a) pasted metric graphs, (b) pasted annotated screengrabs, (c) pasted snippets of code, (d) pasted snippets of test output. None of this is easy in IRC.
But once they're pasted in there, they can only be used there. It's barely harder to upload a file to any myriad of file sharing/hosting services and paste a link which most graphical IRC clients can be configured to auto-expand (and users who don't care/don't want a bunch of images can choose to handle links differently)
I want the text snippets to be shown inline. I'm fine with Slack owning the image assets, because I don't have to worry about permissions the way I would if I uploaded them somewhere else (unless it was to some other internal tool).
I've been on IRC since 1993, and I'm an accomplished programmer. I still find setting up and configuring ZNC and an IRC client complicated, error-error prone, and confusing. And it doesn't always work - sometimes it quits working for no reason and I have to restart things.
In particular, there are many settings that mention security, encryption, and certificates. It's unclear what combinations are sensible, supported, or necessary.
> file uploads in your chat client are misplaced at best, and "rich" environments with formatting and images are 99.999% distractions
We can agree to disagree, but I think that the wide adoption of things like Slack and Hipchat are strong indicators that most people side with me.
What sort of productivity problems did y'all have? Because I have a hard and fast rule - if someone tries to introduce a giphy bot into a channel, I will throw a full-blown tantrum and abuse it until it's gone.
I do agree with you wholeheartedly that Slack, etc., are not a place for documentation.
> Too much light hearted humor going on in your team's chat?
We have an off-topic room for light-hearted humor, and it generally gets more traffic than any of the work related channels!
> What's the problem with giphy? Is it too silly?
It's usually too irrelevant. Someone tries to do "/giphy smile", and the result is something that's not actually someone smiling. So they try again. And again. And then it's just people playing giggle roulette, without any actual content. Even off-topic, humor rooms need a decent signal to noise ratio.
IRCCloud solves a lot of these problems and you'd think there's a market opportunity for them to step in and offer their enhanced IRC experiences to "teams" and "communities" with an appropriately optimized fee structure.
Matrix[1] solves some of these issues, notably the archiving and native scrollback, and has a working IRC gateway. We're experimenting with it at our IRC network now.
This has been a sore point for many communities (see the Digital Nomads + React communities).
But if Slack were smart about it, they'll realise that there's an opportunity here. They are a very well-funded company and it wouldn't hurt to spend some resources to beef up their current code/infrastructure or to even spin up a separate product that they can profit from.
Speaking of Slack, what's an alternative with a different pricing model?
We have a core team that's always around, and for that Slack pricing is fine, but we have a significant number of "drive by" users that aren't worth paying $60 per year.
We're generally happy with Slack's features, so which are the similar services that charge something different than per-user?
Mattermost is a complete replacement for Slack. I really don't understand why people use Slack if they don't use the integrations, which in my opinion are quite unnecessary in many cases.
Like the author, I'm always "that guy" who plays a game or uses a program in a way that seems reasonable, or optimal to me (and often is very efficient) but is so unusual that the program eventually "falls off the edge of the world" and starts crashing all over the place because none of the beta-testers ever did anything quite like what I'm doing with the program.
Like this guy, I usually don't know at first just what is so unusual about my behavior, and often I never do find out. My favorite game (not yet a decade old) crashes every several minutes for me, playing the way I like. I just save extremely frequently and keep right on playing it.
The moral: Where business is concerned: "Be a smart herder" - don't make any false moves, or adopt odd implementations or uses of key software products (or software controlled products) because the minute your behavior is similar to only 1/1000 users (sometimes 1/100 users), you are using the equivalent of an alpha or beta product, and you should count on getting zero product support. Your complaints will, likely, not even be properly comprehended or will be understood, but labeled "impossible" and abruptly closed (I'm looking at you Open Office.)
132 comments
[ 4.7 ms ] story [ 245 ms ] threadhttp://www.theverge.com/2016/10/19/13330158/t-mobile-unlimit...
The biggest takeaway from this should be: if you think you might be pushing a system, you should probably talk to a human first to get confirmation on how it will work for your specific scenario, and not just use their sales page.
Particularly when that tool is so important to your operations.
Two things: a) I wouldn't blink at 10k if my line in the sand was "Unlimited number of people" (would I similarly ask a human if Amharic glyphs are supported if the advertisement suggested "chat in all languages"?) b) It may behoove me to verify claims before jumping in, but it is absolutely 100% the responsibility of the organization to set expectations in line with what it can deliver
Not students or subscribers. Not "public channel", or "chat room", or some sort of phrase that indicates a large mass of people.
If someone decided to sue them or something, I'd assume they'd have an easy defence saying they clearly meant a team of work colleagues. As many others are saying here, slack simply doesn't seem to be aimed at this use case.
False advertising regulations aren't a company destroying "gotcha" like felony theft, they are designed to protect consumers from fraud. Having some technical issue that doesn't impact the vast majority of consumers isn't what it's designed for.
Which leads me to my old-timer question: What's wrong with IRC?
I like IRC, but newer generations are used to having "full-featured" chats without setup (beauty is in the eye of the beholder).
I also like being able to do some simple markdown in my messages.
It's a combination of both worlds I suppose. So far I am enjoying it.
There's a reason why companies like Slack have built billion dollar businesses doing ostensibly the same thing as IRC, and it's because IRC doesn't offer enough value even if it's free.
Probably the big one for me; I know my previous boss was asking if there was a SSO option because that would be the only thing he saw as limitation in IRC.
I realise my setup is hardly common, and I contend that the main issues with IRC are the clients and the account systems. However, both those issues (among other issues) could be resolved with the IRC protocol, allowing people preferring other clients to continue to user their clients.
Message logging and account management can be done server-side (e.g. closing connections on users if they don't log in), and with a dedicated client to this server, the logging in-part could be done rather seamlessly, even if posing slightly more 'troubles' for other IRC clients.
But as implied in the other replies to my post, but is there any money in that? Maybe licencing the servers? I dunno. I'd love to do something like that, but it would be a full time effort, I fear.
At which point you're not really using IRC. You're using the Bittleebee-commands-over-SSH protocol.
This protocol has a number of issues: it requires having a server with a unix user account running on it (which is a massive attack surface, no-one can offer a server like that for free or it will be used to DDoS other people etc). Its phone apps are poorly integrated and drain battery. Its UI in general is very undiscoverable; the logging interface is still pretty awful (e.g. tracking of how far you've read is pretty poor). Sending files or voicechatting is even harder than it is in vanilla IRC.
> both those issues (among other issues) could be resolved with the IRC protocol, allowing people preferring other clients to continue to user their clients.
Slack offers an IRC gateway, which gives about as good an IRC experience as any extended-IRC protocol ever could.
As for Slack's IRC gateway, I think it's pretty decent, yes. I personally prefer it to Slack's own client (again, that's just me). But this is what bothers me about Discord, because that doesn't offer an IRC gateway, and I am forced to use their client(s).
And if you're like me - which apparently few are - and you are in many different communities, that use different protocols to communicate, having a bunch of different clients just means more hassle.
I'm all for federation and open protocols, I wish Discord had gateways and I'm hopeful for Matrix. But I don't think IRC is the answer: it's inherently without identity, inherently text-only, inherently historyless. These problems can't be solved well without protocol changes, but for whatever reason IRC has developed a community that is hostile to any protocol improvements and preferes to encourage ad-hoc hacks for these aspects, none of which works well and most of which don't work at all.
I only proposed intermediate solutions, because I thought that would be more likely to actually amount to something. Kind of like when Google did SPDY to push for HTTP/2.0, but you'd need a player the size and with the interest of Google to do IRC/2.0. Someone to make the decisions.
It's almost ridiculous that something as ubiquitous as instant communication doesn't get more serious attention.
http://ircv3.net/
I've long since given up on any effort to make IRC good. I think energy is more productively spent on ground-up protocols that can include the good parts of IRC but also solve the problems I mentioned. Matrix is where most of my hope is going at the moment.
It's an open protocol. Check out Kiwiirc, it's pretty good looking! A decent front-end team could build a nice interface.
> There's no good account system so users can easily spoof being someone else.
I believe that NickServ takes care of this.
As far as logging, and file-sharing. Yeah you're onto something. IRC isn't as bad as people make it out to be :/
Personally, I'd rather have accounting and permissions be a core part of the protocol, not a bolted on afterthought.
Of course. But they haven't. Kiwi isn't bad for an IRC client, but it's way behind Slack.
I believe that NickServ takes care of this.
Nickserv is hard for a typical user to understand. The number of times someone thinks they've registered a name when they actually haven't demonstrates that. Ghosting makes it harder too.
I used IRC for about a decade. I used even more esoteric online chat services like telnet talkers and MUSHs too. They're great if you learn how to use them. But that's the key difference - you don't need to learn Slack. It works how you'd expect it to work. A user can just pick it up and do things with it. That's a massive difference, and possibly the main reason why Slack can charge a decent price for their product.
(I'm not affiliated with irccloud in any way)
I have been using Slack for about a year now at work and I think it's great. I don't think irccloud would be a suitable replacement either :-)
edit: https://slack.com/pricing/enterprise-grid
https://facebook.github.io/react/blog/2015/10/19/reactiflux-... (October 2015)
To be fair, Slack never really said it was made to support that many users. Even in my team of less than 20 on the free tier, we hit the 10,000 message limit really quickly. I can't imagine how that must have been with 8 thousand users.
Also, previous discussion: https://news.ycombinator.com/item?id=9754626
But, come on, you have to admit that an online community of thousands of people does not fit even the most charitable interpretation of the word "team".
That is basically what the whole thread and article evolves about. Are 10k people a team? Really? Sure, you can argue all day that technically it may be the case, the whole world could be my team, some kind of super team and so a service shouldn't make any assumptions and so on, but reality is that everyone who hears "team" has a pretty good idea of a ball park figure how many people that will be and that freecodecamp doesn't fit into this. So, in the end it's just playing around semantics "but, but, but ... you said of any size .."
I am not interested in long and un-ending pedantic arguments about the extreme corner-case definitions of words. I maintain that an online community of 10k people does not fit even the most charitable meaning of a working "team". If that doesn't work for you, then you're only setting yourself up for surprise.
This argument that "any size" should really mean "any size" amounts to someone walking into an "all-you-can-eat" buffet and expecting to be able to sit at the same table for 2 weeks eating all meals for the price of one, and then complaining that the 'all you can eat' advertisement should overrule all other policies the restaurant has.
It would be the same as someone seeing an ad for mini-golfing for $20 for a family of any size, and then bringing four thousand of your 2nd, 3rd, and 4th cousins, and demanding that the entire group gets in for $20. While there's a pedantic, technical truth to cousins belonging to your 'family', it doesn't meet anybody's common understanding of what an ad for family prices means, even the person trying to cheat the system.
If the author truly didn't even suspect that his 10k users is a massive stretch of the idea of a "team", the message limits should have been a clue, but instead of acknowledging he was pushing the limits, he blamed Slack.
And signing people up with an undocumented API that skips a big amount of signup friction seems like a recipe for running into undocumented limits. Would we be upset with Slack for not supporting 1 million user teams? 1 billion? 1 trillion?
The guy left a free trial for another free trial; if he's at fault we're all at fault every time we change our go-to software. The lesson might be that "there be dragons" - you should guess that any "better" program or SaaS out there is less that half of what it says once unknown limits have been discovered.
You should engage with the vendor. Perhaps there are intangible benefits to the vendor for you to use them even at no cost (PR, testing opportunity, etc)
Generally speaking, if you are dependent on a free service to do your business, you are fucked. A friend is a policy consultant who relied on Google Reader to be his knowledge repository. He bills the equivalent of $800/hr and was nearly paralyzed as it went away.
He didn't change his own personal go-to software, we're not talking about a trial of a video game here. He changed the software for thousands of his users. He put thousands of people on a free trial for something that was not obviously going to work.
You do have the option to investigate before you make that kind of move. If you choose not to exercise it, you don't have that much ground to stand on when things don't work out.
Other users here also pointed out that there is a known specific API error message for the user limit. That kind of thing could be uncovered with a little diligence. Author could also have setup a fake team and tried to add many users before putting 8k real users on the team and just hoping.
He did finally start talking directly to Slack only after he started having trouble, and they responded and disclosed the existence of a team size limit. This obviously could have happened before hitting the limit.
The author expressed incredulity at what would be a $500k price tag, and yet completely fails to see why that is a massive glaring red flag. That alone should have been enough signal that his plan was skating on thin ice, but instead he drove right past all the warning signs and then blamed Slack for it.
He could have asked innumerable questions all of which contradicted the description of what he was getting. He couldn't have known which was the right question. I very rarely query in person before a purchase; I did recently and was given a flatly wrong answer on one question, and then a very positive answer that wasn't logically coherent (strongly suggesting a no, in truth) on a second question. I'm buying anyway, but unless you can phone a corporate head, querying customer support for arcane technical information is rarely a great way to get the right answer, in my experience (sorry to say.) UNLESS you already have a proven fail, of course - which he did.
If it were my program there'd be an error message in there no matter what the upper limit was; I assume others are as competent.
I also don't follow your logic re the high price tag somehow logically entailing a secret limit on the free product - unless you're implying that it's a trap, a way of phishing for phools. (In my country, an illegal bait and switch, actually.) That's something that doesn't work too well when you're peddling to corporations, the pool is small and word gets around too fast.
Yeah me too, for things I buy for myself. But it's absolutely the norm for software purchases of $500k. That's what everyone does, it's extremely common practice for any org purchase of software for over 100 people.
If the author were actually looking to spend $500k, he definitely would have called first and done a bunch of research. Nobody spends that much without talking to someone. The only reason he didn't have that dialogue is because he thought he'd get the whole thing -- apparently a $500k value -- for free.
That's what I mean about the price tag being a signal. It should have signaled a phone call, at the very least.
-- The Slack screenshot in the article.
If you're serious, I'd like to invite you to share your reasoning for your insult. I gave a direct answer to a direct question from @Nomentatus, and had no intention of saying something inflammatory.
My family is in part Prussian, and this is an example, now that I look at it, of fabled Prussian sarcasm, which I became familiar with (at the sharp end) from my grandmother, and didn't like, much.
My comment immediately above wasn't directed at you at all. I replied to @cammio who said only "troll" in response to me. His commment did get flagged and was later killed. I suspect when that happens, some people can't see the dead comment, depending on their profile settings. My comment was getting upvoted until the one I replied to got killed, and then it started getting downvoted, so I was suspecting other people also couldn't tell what I had replied to and mistook it for you. I should have quoted what I was replying to. C'est la vie.
Do you have a source for that information? One of the roles of Slack[0] is named "Member" not "Coworker".
> the author should have uncovered this cap before moving his community.
He tried: Slack said there was no limit, yet there was. Even Slack themselves mention starting with a "pilot team"[1] to demo; which wouldn't have discovered the limit either. How would you discover it?
[0] https://get.slack.help/hc/en-us/articles/201314026-Roles-and... [1] https://get.slack.help/hc/en-us/articles/217626298-Tips-for-...
But your question presumes that the word "team" isn't enough, and that the implied team size that comes with a 10k message limit also isn't enough. Why?
I'm definitely disappointed to hear about this. The pricing model sucks for us as well since it means $60 a head to add someone to the friend group if we wanted to pay for slack. If we could pay a fixed price and get a slightly better message history and more integrations, I'd gladly pay it, but per-head is just ridiculous.
We also use Discord for online gaming since it's easier to invite people outside the group. It's been absolutely fantastic, but we had issues with some people not having access at work.
+ For all kinds of "Work"
+ For teams of all types and sizes
+ Bringing people together to make them productive
Compare that to the messaging for say Hipchat:
+ "Team chat built for business"
+ Enterprise features
+ Loved by your IT team
(Edit - Formatting)
Do you know why it happens? Do those companies block Discord as an "unprofessional" website?
Worth noting that 1) the author's expectations were wildly unrealistic. 2) Slack has since come out with better tools to manage large teams.
The "max user size" thing is a bit worrisome, but MMOs have a history of sharding to solve that problem anyway, so hopefully that shouldn't be a problem either. (Players will be able to chat together in a shared Discourse forum, so sharding shouldn't really hurt community-building.)
I wonder if any progress has been made since then to support larger teams, though? It's been quite a while, and Slack's engineering team has been cranking out a lot of great features and improvements lately.
[1] http://www.slackandslash.com
If you're not trying to make money, you still should check the agreements for Slack; this may constitute abuse.
You should also take a look at your architecture, too. You've got a clear message bus where you send things to and receive things from Slack. You may notice that where those messages go matters less to your code than you may think. If you find you can't go with slack, it may not be all that hard to simply set up a web site that plays your text-based game by shimming the message flow in and out, in which case you can do whatever you like, at whatever rate you like. Despite the slick name, you may not need Slack at all. You'd still have the conceit of the chatbot experience, which will definitely appeal to a certain niche, just as MUDs did.
(And that name may be too slick. I don't know how nasty Slack is inclined to be, but directly referencing brand names in your name like that is dangerous from a trademark perspective.)
Also, while I haven't figured out monetization, I don't think there should be any real problems with that either. Other people charge for their slack bots and integrations, so unless they specifically have a problem with a game-style slackbot charging money, there shouldn't be anything preventing me from charging for stuff.
You very well may be right about the name, though. I've just registered "chatandslash.com" as a backup that I can switch to before too much marketing has gone forward, and I've already emailed Slack again to show them what I've come up with and for further confirmation that what I'm up to is fine and dandy before progressing any further.
Oh, and you're totally right about shimming out Slack with my own frontend. It's in the backlog of stuff to do some day potentially, but I think there's a lot to be gained in the meantime by explicitly staying with Slack in the meantime. "An RPG you play in Slack" is a lot more interesting than "An RPG that looks kinda like chat, I guess".
Thanks for the advice!
* Free
* Handles thousands of users seamlessly
* Archived via bot same as free Slack
* No noticeable performance hit for high user volumes
* Wide variety of interfaces and integration bots to choose from
* Widely deployed and trusted across tech communities
It's called IRC.
Edit: I can tell more people are encountering challenges using Slack these days. In the past, a suggestion to use IRC would have been downvoted to hell and back!
A lot of people seem hung up on the history, file sharing, or some other feature that Slack has, so I thought I'd take a moment to expand on my ideal setup and how they translate from Slack:
* Long-lived documentation and important team knowledge: Wiki pages (which I prefer even when using Slack and pins or history search are available). Full history of edits is visible and it's easy to access/search.
* Discussions involving a large number of stakeholders: Email. Threads and the async nature of the protocol make it well-suited to discussions when users aren't all online at the same time and the discussion is more thoughtful and isn't moving quickly. Slack threads suck replies aren't very visible and history scrolls quickly in active channels.
* Discussions involving outages, current tasks, and other immediate needs: IRC. It's real time, cross-platform, etc. History can be archived for later searching, but CHAT HISOTRY != DOCUMENTATION. Post-mortems and that sort of thing should end up in a wiki or similar.
* File sharing can be done via some other service with a link pasted into chat. One extra step to paste the link manually isn't a big deal.
- no history while you are not in a channel
- lack of modern features like sending images and lack of good UX
- no mobile notifications
Matrix.org solves these problems very well IMO, but it's adoption is abysmal too.
- Commonly addressed with logging bots and a link to the log in the topic
- Some clients have this: when you drag an image into Glowing Bear (a web frontend for WeeChat that I'm working on), it gets uploaded to imgur and a link to the image is pasted in the channel. It can also display images and videos inline if you wish.
- Easily handled with services like push{over,bullet}
The problem is that these things don't work out of the box and that there's a learning curve. It's just not a very friendly experience for newcomers.
* no built-in file uploads
* a bot is required for archiving
* a bot is required for notifications
* no native scrollback/history - IRC bouncers solve this problem, but it's not a plausible solution for most non-techies
* the last two issues also mean that mobile solutions are going to be lacking.
It's possible to have IRC as fully featured as slack, but it does mean either rolling your own solution, or using a lot of other software to accommodate everything and everyone.
If I want to ask my coworker René for a quick bit of knowledge, a phone call is too disruptive and too urgent, and an email might not be answered for a few hours. Slack/hipchat/irc are the perfect medium for "hey, do you know off the top of your head why X is Y?"
* channel services can provide archiving and notifications.
* scrollback can be handled by a bouncer, yes, but it's up to the IT dept to set it up per-user
* there are plenty of usable irc clients for mobile, web, and desktop to satisfy this need.
source: Started using telegram/slack but productivity went down so work launched an internal ircd (inspircd). Internal wiki, git, and sharepoint for documentation/files/code where it belongs. Not the chat client.
Nope. They're extremely useful. Just offhand I can think of tons of times we've (a) pasted metric graphs, (b) pasted annotated screengrabs, (c) pasted snippets of code, (d) pasted snippets of test output. None of this is easy in IRC.
I've been on IRC since 1993, and I'm an accomplished programmer. I still find setting up and configuring ZNC and an IRC client complicated, error-error prone, and confusing. And it doesn't always work - sometimes it quits working for no reason and I have to restart things.
We can agree to disagree, but I think that the wide adoption of things like Slack and Hipchat are strong indicators that most people side with me.
What sort of productivity problems did y'all have? Because I have a hard and fast rule - if someone tries to introduce a giphy bot into a channel, I will throw a full-blown tantrum and abuse it until it's gone.
I do agree with you wholeheartedly that Slack, etc., are not a place for documentation.
What's the problem with giphy? Is it too silly? Too much light hearted humor going on in your team's chat?
We have an off-topic room for light-hearted humor, and it generally gets more traffic than any of the work related channels!
> What's the problem with giphy? Is it too silly?
It's usually too irrelevant. Someone tries to do "/giphy smile", and the result is something that's not actually someone smiling. So they try again. And again. And then it's just people playing giggle roulette, without any actual content. Even off-topic, humor rooms need a decent signal to noise ratio.
1. http://matrix.org/
But if Slack were smart about it, they'll realise that there's an opportunity here. They are a very well-funded company and it wouldn't hurt to spend some resources to beef up their current code/infrastructure or to even spin up a separate product that they can profit from.
We have a core team that's always around, and for that Slack pricing is fine, but we have a significant number of "drive by" users that aren't worth paying $60 per year.
We're generally happy with Slack's features, so which are the similar services that charge something different than per-user?
Like this guy, I usually don't know at first just what is so unusual about my behavior, and often I never do find out. My favorite game (not yet a decade old) crashes every several minutes for me, playing the way I like. I just save extremely frequently and keep right on playing it.
The moral: Where business is concerned: "Be a smart herder" - don't make any false moves, or adopt odd implementations or uses of key software products (or software controlled products) because the minute your behavior is similar to only 1/1000 users (sometimes 1/100 users), you are using the equivalent of an alpha or beta product, and you should count on getting zero product support. Your complaints will, likely, not even be properly comprehended or will be understood, but labeled "impossible" and abruptly closed (I'm looking at you Open Office.)