Comment by derefr | Hacker News Reader

Comment by derefr | Hacker News Reader

Parent Full thread

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.)

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!

I understand that you decided to use Slack. Maybe other communities are doing the same thing.

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."

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."

The primary complaint is an unpublished limit that is counter to a main selling point.

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.

I would complain if it had that limit and was called UNLIMITEDINT, for whatever that's worth.

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.

There's a golang http://blog.gopheracademy.com/gophers-slack-community/ Slack channel. Not 100 000s for sure but there are a lot of people using Go.

> Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did).

Why would you think all 100,000 of those students would need access to each other through a collaboration tool like Slack?

"Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did)."

Any idea what their experience was like?

> I want to point out that communities are increasingly using Slack, and many of them are also in the thousands of users.

[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.

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.

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.

> So we have no alternative but to switch.

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".

Yeah, but at the current growth rate, they would've easily hit 9000 active (logged in within 3 months) in less than a month

They where only using slack for two months and hit the limit (of almost 9000).

The 10,000 message search limit sounds like a nonstarter as well.

Larger groups are playing with that $5/user/month bonfire.

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.

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.

Reply on news.ycombinator.com