The image is striking because of what it is not.
It is not a diagram. It is not a flowchart or an org chart or a network topology. It is people, standing in a circle in the dark, holding threads of light between them. The threads cross and overlap and form a web so dense in the middle that it looks like a single glowing mass.
Every thread is taut. Every person is holding their end.
This is what a network actually looks like when it is working.
The difference between a list and a pattern
A list of people is not a community.
You can have a hundred members in a group and a handful of relationships, most of them radiating from one or two central people. That is a hub-and-spoke structure. It looks like a network from a distance, but remove the center and everything falls apart. The connections are not between members. They are between each member and the hub.
A real community is a pattern. The connections are distributed. When you remove one person, the pattern changes but does not collapse. When you add a person, they do not just connect to the center - they connect to others who connect to others, creating new paths that were not there before.
The difference is not about size. Small communities can be genuinely distributed. Large ones can still be hub-and-spoke. The question is whether the threads run between people, or just to the center.
What distributed systems learned
Distributed computing arrived at the same insight through a different door.
Early computer networks were centralized: all traffic went through a main server. The server was fast and efficient, but it was also a single point of failure. If it went down, nothing worked.
The design shift toward distributed systems was not primarily about speed. It was about resilience. If every node could talk to every other node, and multiple paths could carry the same data, then no single failure would be fatal. The pattern would degrade gracefully instead of collapsing at once.
This is the engineering argument for distribution. But it describes community too.
A community where knowledge lives in one place, where decisions flow from one center, where events only happen when one person organizes them - that community is fragile. Not because the center is incompetent. Because the center is a single point of failure. When that person burns out, or moves away, or steps back for any reason, the pattern does not continue on reduced capacity. It stops.
The threads have to be real
In a thread-web, the connections are not symbolic.
They are load-bearing. Each person is holding their end, and the tension from one side affects what every connected person feels. If one person lets go, the threads they were holding go slack, which changes the tension for everyone connected to them.
In a community, this translates directly. When someone shows up consistently, brings questions, introduces people, organizes a small thing, follows up - their presence creates tension in the network in a useful sense. Others respond, connect, rely on the path that person represents. When they stop showing up, those paths do not automatically reroute. They go slack. Something that was easy becomes something that no longer happens.
This is why consistency matters more than intensity. One person who shows up every month for three years creates more structural load-bearing capacity than someone who contributes enormously for six months and disappears. The pattern learns to rely on what is reliable.
Consistency matters more than intensity. The pattern learns to rely on what is reliable.
Every node contributes differently
In any real network, the threads are different colors.
That difference is not decoration. Different connections carry different things - different knowledge, different ways of thinking, different resources. A network where every thread carries the same information is not a network. It is a broadcast system. What makes a network valuable is the diversity of what flows through it.
Communities that work have people who contribute differently from each other. The person who knows the technical deep cuts. The person who knows everyone and makes introductions. The person who shows up for the unglamorous work. The person who asks the question no one else is willing to ask.
None of these roles is more important than the others. Remove any one and the pattern changes in a specific way. The deep technical knowledge becomes less accessible without someone to translate it. The introductions stop happening. The organizational work accumulates until someone burns out doing it all. The uncomfortable questions go unasked until something breaks.
What building this looks like
A network like this does not assemble itself.
Someone set up the space. Someone handed out the threads. Someone figured out the geometry of where people should stand so the web would form rather than tangle. The visible result - the distributed pattern - required an invisible setup.
Building a distributed community has the same structure. The relationships between members do not emerge spontaneously. They require conditions: regular contact, shared context, enough low-stakes interaction that people develop trust before they need to rely on each other for something important.
The work of community building is mostly that invisible setup. Creating contexts where people can find each other. Making it easy for connections to form that do not go through a center. Ensuring that knowledge lives in multiple places, that contributions are visible to the network and not just the organizers.
The pattern, once it exists, generates its own momentum. But it needs someone to hold the first threads until enough others are holding theirs.
And then - if the design is right - you are no longer the center. You are one node among many. The pattern does not depend on you any more than it depends on anyone else.
That is the goal.
Related: Juggling Is Always Shared - on the peer-to-peer transmission that keeps skills alive. The Room Where Everyone Belongs - on flat hierarchies and what makes them structural rather than ideological.