Guides to running self-hosted community software
The parts of running community software that are decided once and then lived with: what to choose, how to connect it to what you already have, and how to move it without breaking what points at it.
Each of these covers a decision that is cheap to make correctly at the start and expensive to revisit afterwards. They assume you are the person who will actually have to operate the thing, rather than the person choosing it from a comparison table.
A guide here is not a review and not an installation manual. It takes one question that has to be settled before anything is installed — how big a platform has to be able to get, whether it can share accounts with a site that already has them, what leaving costs — and answers it concretely enough to act on. It names platforms where naming them is the only way to be specific, and says plainly where one of them is the exception to what it has just claimed.
They are meant to be read next to two other things. The catalogue lists what exists and what each platform is built on. The comparison puts two of them side by side on the rows that decide an installation: licence, runtime, what it takes to keep running. The guides sit underneath both, because the part of the decision that no feature table shows is what a platform asks of whoever maintains it once the novelty has worn off — how often it wants upgrading, how much of its plugin surface is load-bearing, and how much of the work is still there in year three.
Where to start depends on what already exists. With nothing installed, the guide on choosing a platform for a small community is the shortest route from a vague requirement to a shortlist of two or three. With a board already running and a reason to leave it, the migration guides matter more — and among those, the one about addresses matters most. Software can be swapped again later at a cost that is mostly effort; addresses that stop resolving take their inbound links with them, search engines read the silence as content that is gone, and there is no second chance to redirect a URL nobody records any more.
What is not covered here
Installation instructions. Every project documents its own installation better than a third party can, and those instructions change with each release while a guide written elsewhere quietly does not. Where a step here touches installation it says what to check rather than what to type.
Theming and customisation are absent for a related reason. They are specific to a platform and to a version, and the general advice that survives — keep the installation close to stock, because every modification is borrowed against a future upgrade — takes one sentence rather than an article.
Nor is there a ranking. A shortlist that is right for a club of two hundred people is wrong for a support forum attached to a product, and both are wrong for a board that has to federate with something else — so an ordered list would be answering a question nobody asked. What the guides do instead is name the constraint that actually decides each case, and say which of the catalogued platforms still stands once that constraint is applied.
Questions people actually ask
What do these guides cover?
The parts of running community software that are decided once and then lived with: choosing a platform at a given size, connecting it to accounts a main site already has, and moving it without losing the addresses search engines and old links point at. They assume you are the person who will operate the thing rather than the one choosing it from a table.
Are they specific to one platform?
No. Each one works from what the catalogued platforms actually do rather than from one vendor's documentation, and says where a platform is the exception. Where a claim can be read from a project's own repository — importer coverage, release cadence — it is, and the guide says so.
How often are they updated?
The prose changes when the subject does. The numbers inside them do not wait for that: importer counts, activity bands and release dates are read from the source repositories every time the site is built, so a figure in a guide cannot drift away from the data the rest of the site shows.
Which one should someone read first?
Whichever decision is closest. If nothing is installed yet, the small-community guide is the shortest route to a shortlist. If a board already exists and the question is how to get off it, the migration guides matter more — and the URL one matters most, because that damage is the hardest to undo.