eh... slack has consistently said that large communities shouldn't use its services. - http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...
Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem, and there is quite a few high quality mobile and desktop clients for IRC.
Apart from the tech problems with 1000+ sized teams, it's insane even considering the free tier with a 10'000 message limitation for 8000+ users.
So the team size isn't itself the problem; instead, it's the idea of wanting 8000 active subscribers in the same single channel that doesn't scale. Doesn't work on Slack; doesn't work on IRC, either.
At the scale of 8000 "viewers", you need the sort of specialized "presentation" software used for managing MOOC lectures and corporate shareholder calls, with fan-out servers, voting indicators, and the ability to "raise your hand" to ask the presiding officer to grant you a temporary +v.
That has nothing to do with Slack-like apps, and everything to do with Slack.
> Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem
I am part of many FOSS communities on IRC. None of them have "fixed" that problem. There might be one or two that archive the channel somewhere. That is no substitute for real in-app persistence and search.
There is a reason slack has a problem with that - scaling is hard.
There is also the advantage of not having silos - if I have a problem with a dependant library I can "/j #libname" and ask a question, instead of searching for what slack, or slack like tool they use, signing up, installing whatever app is needed to access it, and asking the question (and remembering what app they used, so I can keep it open for issues that run over a few days.)
Detachable screen sessions make up somewhat for it, but they're still pretty limited (you might have /joined the channel only later), and it requires a personal service running, that must be attended to & etc.