Features
Part of How internet communities change: a reading framework
Internet communities updates: four transitions, named
Internet communities updates explained: four transitions — software, host, leadership, ownership — with named cases, what each one breaks, and a checklist.
A community rarely dies of a decision. It dies of a move: a change of software, a change of host, a change of the people who ran it.
Each looks operational. Each is a rewrite of the community's terms, by a small number of people, usually in a hurry, usually without words for what is at stake.
This page covers the internet communities updates that matter — a software change, a host change, a leadership change and an ownership change — what each one tends to break, and what can be done in advance to keep the damage survivable.
What to take away
- The four transitions are a software change, a host change, a leadership change, and an ownership change. They are frequently confused with each other.
- Whatever percentage of members you expect to follow a move, expect fewer, and expect the ones who do not follow to be the quiet ones.
- The archive is the thing most often lost, because it is the thing nobody is responsible for.
- Every transition renegotiates the rules whether or not anyone intended to, because the new container enforces different things.
The four transitions
What changes
- Software
- Threading, search, notifications, what a post can contain
- Host
- Address, uptime, cost, who can pull the plug
- Leadership
- Who arbitrates, and on what basis
- Ownership
- Whose interests the place serves
What is usually lost
- Software
- The old archive's structure, and habits built on the old shape
- Host
- Search rankings, inbound links, and members who do not see the notice
- Leadership
- The unwritten precedents the departing person held in their head
- Ownership
- Trust, immediately, whether or not anything else changes
The thing nobody plans for
- Software
- That the new tool enforces different norms by default
- Host
- That members find the place through routes nobody documented
- Leadership
- That most rules were never written down
- Ownership
- That the announcement itself changes behavior before any policy does
The last row is the fastest-acting. A change of ownership makes every existing rule provisional in members' minds, because the guarantee behind the rules was a person and that person is gone. Nothing has to actually change for participation to change.
Four community transitions compared
Software
- What changes
- Threading, search, post shape
- Usually lost
- Archive structure and habits
- Unplanned
- New norms by default
Host
- What changes
- Address, uptime, cost
- Usually lost
- Rankings, links, members
- Unplanned
- Undocumented arrival routes
Leadership
- What changes
- Who arbitrates disputes
- Usually lost
- Unwritten precedents
- Unplanned
- Rules never written down
Ownership
- What changes
- Whose interests served
- Usually lost
- Trust immediately
- Unplanned
- Announcement changes behavior
The transitions, named
The four types are easier to hold onto with cases attached, because a different thing goes missing in each one.
- Software.Digg's redesign pushed a large slice of its base to Reddit, and the history did not travel with them. Boards built on phpBB or vBulletin break the same way when they move into a hosted space such as Discord or Slack: threading, search and permanence all change at once.
- Host.Communities on free board hosts such as ProBoards, or on a server one volunteer pays for, change address. The domain may survive the move; the software, the imports and the permissions usually do not.
- Leadership.A subreddit's moderators turn over, or a forum's founder stops logging in. The rules page reads the same and the enforcement does not.
- Ownership.LiveJournal changed hands, and its users learned that the guarantee behind the rules was a company that could sell. Tumblr's restrictions on adult content sorted its population into those who would stay and those who would not.
What happens to the archive
The archive is the community's memory, and it is the asset with no owner. It behaves like any other common-pool resource: everyone benefits, nobody is responsible, and it degrades without anyone deciding to let it.
Why the archive usually does not move
- Archive is a common-pool resource
- Everyone benefits, nobody is responsible
- Moving it is somebody's unpaid weekend
- Converting it means losing structure
- Hosting it means paying for nothing
- Old container stops and record goes
Moving it is somebody's unpaid weekend, converting it means losing structure, and hosting it after the move means paying for something nobody posts to.
So it usually does not move. The old container keeps running until it stops, and the record goes with it. Members who thought the history was safe learn it was safe only while someone kept paying.
Whether anyone outside ever collected the material is a matter of luck. The Internet Archive Wayback Machine, which began archiving the web in 1996, holds copies of some community pages, but only the ones its crawlers reached; the kinds of collection that might hold a copy, and the gaps in each, are set out under internet culture archives.
The workable version is unglamorous: export before you need to, keep the export somewhere the community does not depend on one person to maintain, and accept a lower-fidelity copy over no copy. A plain export of the text with dates and thread structure is worth far more later than a perfect copy nobody made.
Export is also a legal question where members are in the EU: the GDPR's Article 20 right to data portability lets a person obtain and reuse their personal data across different services, though it covers personal data rather than the community's shared record. The mechanics are ordinary, though: a forum's posts and accounts live in a database that can be dumped with a standard tool such as phpMyAdmin or mysqldump.
In the US, a volunteer can host a community at all partly because Section 230 of the Communications Decency Act shields a platform from most liability for what its members post.
Who does not follow
Every move loses people, and the loss is not random.
Who leaves and who remains
Leaves after a move
- Reading habit
- Lurkers, no notice
- Route in
- Bookmarks, search, links
- Barrier
- Accounts, unfamiliar interface
- Ambivalence
- Any friction settles it
Remains after a move
- Reading habit
- Posters and regulars
- Route in
- Direct community ties
- Barrier
- Already committed
- Ambivalence
- Friction tolerated
The remaining group is the more committed, more vocal fraction, and it changes the place's character at once. It is often mistaken for the move going well. The place feels more engaged because the quiet majority has left.
This is ordinary selection bias applied to a group, not a dataset, and it is the same error described under generational digital culture: a changed population read as a changed attitude.
The rules get rewritten whether or not you rewrite them
A container enforces norms through defaults, and the defaults are different in every container. Whether replies are threaded decides whether arguments can be followed. Whether posts are searchable decides whether the past is usable. Whether moderators can edit as well as remove decides what a correction looks like. Whether anything expires decides what people are willing to say.
Defaults to decide before moving
- Whether replies are threaded
- Whether posts are searchable
- Whether moderators can edit and remove
- Whether anything expires
- Write down departing moderator's precedents
Moving without deciding these deliberately means accepting whatever the new tool assumes, and the new tool was designed for a different kind of group. The properties each shape imposes are worked through under internet communities, and the transition is the one moment when they can be chosen rather than inherited.
Leadership changes do the same thing more quietly. Most of a community's law is precedent held by whoever handled the last dispute, and it leaves with them. A departing moderator who writes down the ten judgments they are proudest of and the three they regret is handing over something no rules page contains.
A transition checklist
- Announce in the places people actually read,which includes wherever they arrive from, not only the community itself.
- Export first, and check the export opens.Before anything else is decided.
- Keep the old container reachable and read-only for as long as you can afford,with a pointer forward. Members arrive late, and a dead address tells them the community died.
- Decide the defaults on purpose,at least for threading, searchability, retention and who can remove what.
- Write down the precedentswhile the person who set them is still available.
- Expect the first month to be unrepresentative.The people who move first are not the community, and decisions made in that month get made by an unusual sample.
- Say what you lost.A note recording that the old archive did not come across is worth more than a silence that later reads as a claim there was nothing there. The general argument for stating what a record does not contain is under platform timelines.
Common questions
Is it better to move quickly or slowly?
Quickly for the announcement, slowly for the shutdown. Speed helps people find the new place; delay in closing the old one is what catches the stragglers.
Should the community keep both places?
Rarely for long. Two active places split the conversation and both feel emptier than one, which discourages people in both. A read-only old place plus one live place works; two live places usually does not.
How much of the archive is worth moving?
The parts people link to. In most communities a small fraction of the history is referred to repeatedly and the rest is never opened again. Move that fraction properly and export the rest as plain text.
What if the host closes with no warning?
Then you find out what you exported. This is the only question on the page with a purely preventive answer, and it is the reason the export step comes before the interesting decisions.
