Community platforms list: Discord vs. Reddit by axis

The word "community platform" covers a hosted chat service, a self-installed forum, a mailing list, a group inside a larger social network, and a wiki with a talk page. A community platforms list that puts them side by side without saying how they differ is a list of things that happen to share a word.

The fix is a classification, and specifically a faceted one: a small set of axes, each with a short list of values, each answerable by looking at the service rather than by reading about it. What follows is the set that has held up, and the reasons for each.

What to take away

Axis one: where it runs

Hosted by the operator. The community lives on servers the platform company controls. The community's organizer has an account, not an installation. Cheap to start, nothing to maintain, and the organizer's authority is delegated from the operator and can be withdrawn.

Self-hosted. The organizer installs the software on infrastructure they control. The software's author may still shape what is possible, but cannot remove the community or read its contents. The price is running a server, which is a permanent job rather than a setup task.

Nested inside a larger network. The community is a feature of a general social platform: a group, a subforum, a channel. Discovery comes free from the surrounding network, and so do the surrounding network's rules, ranking, and account requirements.

Federated. The community runs on one server that exchanges messages with others using a shared protocol, which is all federation means here. The decentralized networks overview covers what this does and does not change.

Axis two: how conversation is shaped

Threaded and persistent. Posts accumulate under topics and stay readable for years. Good for reference, for questions with answers, and for slow conversation across time zones. Search matters enormously.

Real-time channels. Messages scroll past in rooms. Good for presence and quick coordination, poor at producing anything findable later. The archive is a by-product and usually a bad one.

Feed-shaped. Posts arrive in a ranked or chronological stream, sometimes with comments beneath. Inherits the properties of the social feed, including the fact that who sees a post is decided by something other than the poster.

Distributed by message. Email lists and their descendants, where the address is the membership and the identifier questions raised by messaging services apply directly. Every member receives every post. The oldest form and still the one with the most durable archive and the least platform dependence.

The message-distributed shape is worth picturing, because it is the one that makes the two axes visibly independent. Servers pass posts to each other, and each member reads through whichever server they hold an account on, so the conversation is one thing and the hosting is several.

A service that offers two of these at once (threads and channels, say) has two communities in one, and they behave differently. Record both.

Axis three: who can get in

Open. Anyone can read and anyone can join. Moderation carries the whole load.

Open to read, gated to post. The commonest arrangement for anything that wants to be found by search and still keep a coherent membership.

Invitation or application. Someone inside vouches, or someone applies and is approved. Membership becomes a curated set, and the curator becomes a single point of both quality and failure.

Closed. Invisible from outside. Discovery is by word of mouth, which limits growth and protects norms.

Note whether the gate is enforced by the platform (a setting) or by the organizers (a practice). A practice can lapse.

Axis four: who holds the power to remove

This axis is the one lists most often omit and the one that decides what happens on the worst day.

Operator and organizer. On hosted and nested platforms, the organizer can remove a member from the community, while the operator can remove the community from the platform. The two powers are separate, and the upper one is not appealable to the lower.

The organizer, on their own infrastructure. Self-hosted. The organizer is the last word, for better and worse, and there is no appeal past them.

Elected or rotating. Some communities appoint moderators by vote or by term. Whether the platform supports this or the community does it by convention is worth recording.

Distributed across instances. Federated communities have a local moderator and a set of neighbors who can each decide to stop listening. Removal from one server is not removal from the network, which is either the point or the problem depending on which side of it you stand.

Putting the axes to work

A classification is only useful if it produces a table a reader can filter. The minimum entry is four cells.

The entries below classify specific configurations, not every community that uses a service. Access settings and moderation practices can vary by community or instance.

Moderator selection is separate from ultimate removal power. A Discourse community can elect or rotate moderators by convention, while the organizer of a self-hosted installation still controls the server.

Two entries with the same four values are the same kind of thing, and a reader choosing between them is choosing on people, price, and taste. Two entries with different values are different kinds of thing, and a reader comparing them on features has skipped the comparison that matters.

The axes deliberately exclude size, age, and popularity. Those are properties of the community, not the platform, and they belong in a different record.

Testing the classification

Use Discord as the typical nested, real-time service; Discourse as the boundary case, since it can be hosted or self-hosted; and a Google Drive folder used only to share files as the excluded case, because it has no community conversation or moderator structure in that use.

If the typical one is easy, the boundary one produces a note explaining the call, and the excluded one fails a stated test rather than a feeling, the classification is ready. If any needed a fifth axis, add it, and re-run.

The community platforms overview covers what happens inside a community once it exists; this page is about telling the containers apart.

Common questions

Why not classify by what the community is about?

Because that is a property of the community, not the platform, and it changes without the platform changing. A platform built for open-source projects will host a knitting circle without noticing. Topic belongs in the entry for a specific community, not in the classification of the service.

A platform lets the organizer choose values on every axis. How is it classified?

By its defaults, with a note of what can be changed. Defaults are what most communities on it will have, and a reader needs to know what they get without configuration.

What about platforms that are not really for communities but get used as them?

Classify them anyway if a community actually runs there, because the axes do not care about intent.

A document-sharing tool hosting a real community with a real membership gate and a real moderator is a community platform for the list. A reader will find it more useful to see it classified than to see it excluded for not calling itself one.