The Citizen as Steward
Someone has to keep things running. The steward is the citizen who takes responsibility for a piece of the infrastructure — not because they were assigned to, but because they chose to. They monitor, update, fix, and document. They are the first contact when something breaks. In a self-organised stack, stewardship is not a burden handed to one person indefinitely — it's a role that can be shared, handed off, and built up over time as more people develop the skills and confidence to take it on.
Adoption
Stewardship's contribution to adoption isn't just keeping things online — it's turning the everyday mutual aid residents already give each other into durable capacity, so the infrastructure isn't gated behind the one or two people who happen to understand it. Where the help that happens through living is informal and incidental, learning as a steward practice is deliberate: pairing on a deployment, debugging with someone else, low-friction room to try things and remove them if they don't work. That's what makes adoption durable rather than a one-off win: a resident who gets help becomes a maker who experiments, a maker who experiments builds the confidence to steward something, and each new steward widens the base of people the next resident can lean on.
Responsibilities
Stewardship carries three kinds of responsibility: reproducing knowledge, maintenance, and organising. In volunteering and anarchistic contexts, knowledge doesn't reproduce itself automatically — there's no job description that says "document what you know," no manager to enforce it, and no direct personal incentive to do it. Knowledge is produced when someone builds something, and disappears when that person steps back. That's a structural problem, not a personal one: the answer isn't to demand documentation, it's to make learning together genuinely worthwhile.
Documentation
The biggest barrier to contribution is not knowing where to start. Lowering that barrier matters more than almost anything else: clear onboarding, an approachable setup, and an environment where asking questions doesn't feel embarrassing. Documentation exists to reduce that barrier — a well-documented system says: you don't need to already know this, you can figure it out. That's an invitation, but it isn't enough on its own: people learn by doing things together — pairing on a deployment, debugging something with someone else, showing a new person around the setup. The written record supports that, but it doesn't replace it.
Maintenance
The technical work of keeping things running: monitoring, updating, fixing, provisioning. They're the ones who run the updates whenever that's needed, and who build the little glue that was missing to make things actually work together. They're the ones who worry about backups and monitoring, and who press the reset button once something needs fixing. See Maintaining for what it actually covers.
Organising
Finding moments to work together on the infrastructure — not just in crisis but as normal practice — is what actually transfers knowledge. It keeps the system from depending on one person and makes it more likely that others will take initiative. For this there is a working group with a dedicated chat, and other ways to stimulate this should be found too — meetups, webinars, a hackathon, or just making space to build something together.
Capacity builds when people feel like they can make something new without asking permission — the practical side of that is covered under experimentation. The social side is a steward's to shape: creating a culture where initiative is welcomed and where people feel their contributions matter, not just their availability to maintain something someone else built.
None of this works without accountability. A steward isn't just responsible for keeping something online — they're accountable to the people affected by it, which is what keeps stewardship from quietly turning into ownership. See Governance for how that's meant to work.
Flourishing
Stewardship isn't a life sentence either. Handing off what you've built — deliberately, not just when you finally burn out — is as much a part of the role as taking it on was. A steward who never lets go becomes exactly the kind of bottleneck this stack is designed against, no matter how well they've done the job. Stepping back doesn't mean disappearing. A former steward who returns to being a resident who helps out, or a maker who builds the next thing, is still part of the same cycle — the one that keeps constituting new stewards out of residents and makers in the first place. That's what keeps the role a role, not a position.