5 things to check in community platforms

Every community platform decides the shape of a room. How many rooms exist, whether people can see in from outside, whether what is said stays on the wall or evaporates, and who can ask someone to leave.

Get the shape wrong and no amount of good software rescues the community. Get it right and the community survives mediocre software indefinitely.

This page organizes community platforms by the five checks that decide whether a group of people will actually talk, not by brand.

What to take away

The five things to check

1. The shape of the room. Chat, forum, feed, or email list? Discord and Slack are chat: immediate, and hard to read a month later. Discourse and phpBB are forums, where a question and its replies stay on one page. Reddit and Facebook Groups are feeds. Groups.io and Google Groups are email lists.

2. The archive and the search engine. Does a message stay findable in a year? Public Discourse and Reddit threads get indexed, so an old answer recruits new members without anyone writing anything. Discord history sits behind an invite and rarely reaches a search engine.

3. The membership record. Can you export a contactable list? Discord and Facebook Groups tie membership to their own accounts and hand a server owner no email addresses. Discourse lets an administrator download users and posts. Groups.io lets a list owner export the member list at any time.

4. Moderation power, and the hours behind it. Slow mode, mute, hide, ban, delete. These are not the same instrument. Slack's slow mode calms a channel without ejecting anyone. A typical thread board with clear rules runs on about 1 to 3 moderator hours a week per 1,000 members. An open chat with anonymous signups takes 5 to 10.

5. The exit. What happens when you leave? Check whether an export keeps threading and authorship, whether old links still resolve, and what the terms say about republishing member posts. Substack and Groups.io let an owner take the subscriber list. Facebook Groups and Discord hand over posts but not addresses.

The five checks line up across the named platforms like this.

The five room shapes

The single room. Everyone is in one place, in one conversation, in real time. Easy to start and immediately alive.

It stops working at a size that surprises people, around the point where two conversations want to happen at once. After that the loudest topic crowds out the rest, and the quiet members go silent before they leave. A small Discord server or a single Slack channel lives here.

The room with topics. Many channels, one membership. Discord servers and Slack workspaces are built this way.

Crowding goes away and a new problem arrives: nobody knows where to post, and the same question gets asked in four places. Someone has to prune channels, which almost never happens. Dead rooms pile up and make the whole space feel abandoned.

The thread board. Topic-first, durable, asynchronous. Discourse, phpBB, and NodeBB run this way.

Someone posts a question, answers accumulate under it, and the whole thing is still readable and findable years later. Slower and less exciting than chat, and much more valuable over time, because search engine indexing can reach it and the archive then answers the same question for everyone who arrives afterwards.

The feed with comments. A stream of posts ranked by something, with discussion attached underneath. This is the shape the large general-purpose services converged on.

Reddit and Facebook Groups are the largest examples. It scales enormously and produces very little continuity: participants share an audience rather than a room, and rarely recognize each other from one day to the next.

The list. Email or its equivalents, which is where the identifier questions raised by messaging services apply directly, because the address is the membership.

Groups.io and Google Groups are the working examples. This shape is unfashionable, and it is the only one of the five where the operator cannot silently stop delivering to the people who asked for it. Weak discovery, strong ownership.

Most real communities are one of these with pieces of another bolted on. When a community feels wrong, the cause is usually that it is being run in the wrong shape for what it is trying to do: a support group in a feed, a chat channel expected to work as documentation.

The properties that decide the shape

Identity is the row that changes the character of a room most. A space where people post under the name they work under behaves like a professional network whether or not it calls itself one.

Moderation is a job, not a setting

Every platform in this category advertises moderation tools. The tools are not the hard part. Content moderation is a labor problem before it is a software problem: the hard part is unpaid work done by people who also have lives, and every design decision either adds to that work or reduces it.

Things that reduce it: durable archives so a moderator can answer with a link, clear and few rules, and small numbers of rooms.

A joining step that costs a newcomer thirty seconds helps, and so does a way to slow a conversation without banning anyone. Slack's slow mode is the common version of that second tool.

It grows with real-time-only formats that demand immediate decisions, and with unlimited anonymous signups.

Ranked feeds that reward the most inflammatory post in the room do too, as does any structure where moderators cannot see what happens in half the channels.

When you evaluate a platform for a community, count the moderator hours per week it will demand at your expected size. That number, not the feature list, is what will decide whether the community is still running in two years.

Before you move a community

Moving is the moment where everything hidden becomes visible. Work through this before, not during.

Reading a community's health from outside

If you are cataloging communities rather than running one, size is the least informative number available. Better signals:

Common questions

Chat or a forum?

Chat if the value is in being present together, a forum if the value is in what gets written down. Communities that need both usually end up with both, and the mistake is treating the chat as the record. It never does; nobody scrolls.

How small is too small?

Density matters more than headcount. A group of thirty where a third post weekly is alive. A group of thirty thousand where the same six people talk is not. Judge by participation rate, not registration.

Should the archive be public?

Public archives recruit: most people find a thread board by searching for a problem and landing in an old thread. Closed archives let people speak more freely. You cannot have both, and pretending otherwise produces a semi-public space where members are candid without realizing they are on the record. Pick one and tell members clearly which it is.