Governance and Oversight
The Public Stack focuses on outside supervisors: society keeping a grip on digitalisation through government, social organisations, and citizens, with supervisors given the mandate and means to provide oversight throughout an initiative's life, not just at launch. We're more focused on governance on the inside — making it participatory, grassroots, self-organising, and democratic. We're focused on what brings an organisation to life and invigorates it with imagination and experiment.
Governance
What defines that way of governance is an anarchist principle: self-organisation over hierarchy, transparency over gatekeeping, accountability to the people affected rather than to a technical authority. We locate the supervisor in the citizen herself: through the act of living in the technology, using it daily, and experiencing its effects directly, she exercises a form of oversight no external regulator can match. She knows when it works and when it doesn't, when it serves and when it extracts — and that knowledge, made visible and acted upon, is the most direct form of supervision there is.
The rules for how that supervision works don't need to be invented. Governance of the tech stack is not a separate domain — it is an extension of the organisation itself. The union's existing culture of democratic participation, distributed responsibility, and accountability to members applies directly to the infrastructure it runs. The stack is governed the same way the union governs itself: a commons, held collectively, governed by those who use and maintain it, and shaped by norms the organisation already holds.
Oversight
The principles that guide the larger union will also shape the technology. Organisation and technology mutually influence each other, over and over, in a feedback loop — and together, they shape our people just as much as our people shape them. These are a few examples:
Mutual aid — the tech stack is not a service provided to members; it is something members collectively maintain and benefit from. Contributing to it is an act of mutual aid, in the same way as any other contribution to the union. Using the technology generates a responsibility to take care of it.
Self-organising experimentation — initiatives don't need central approval to start. Someone with an idea and the capability can try something. What works gets adopted; what doesn't gets dropped. At every level — services, applications, or infrastructure — the technology stack is as open as it can be securely, and doesn't require gatekeeping.
Direct action — if something is broken, fix it. If a tool is missing, deploy it. If a process is bad, change it. The structure is designed to make action cheap and waiting unnecessary. As the infrastructure grows and more people can wield it, other actions are amplified — when the tools are yours, you can really rebel and change things.
Hierarchies are avoided and corrected — including technical ones. A situation where only one or two people understand the infrastructure is a power imbalance, not a virtue. Knowledge and access should spread, not concentrate — the tools are there to do this: code is open, documentation is clear, architectures are mapped, and you can get into it easily.
Relational — we focus on building relationships and deep networks, because that's where ownership and capacity actually come from, not from a policy declaring them. That requires holding a tension: between the local and the distant, and between the personal and the public — to allow identities to grow, and to eventually federate.
Prefiguration — we choose to imagine another way and live it out, without a smooth blueprint to follow. We're often kept captive by terrible technologies because our attention is kept captive by the old ones — which makes the new one hard to even understand.
Commons — shared resources are collectively owned and governed, rather than left to a market that has no reason to protect them. The stack is a commons in this sense too.
Opportunities
Governance is something we'll actually have to explore and learn how to do in this model. Plenty of decentralised methods already exist — agile among them — built precisely because central planning of complex systems didn't work. But most of them still assume a centralised power structure underneath, just a faster or friendlier one. We explicitly don't want that, and that forces us to rethink a few things:
How to shape the organisation — formally or informally. The formal shape is usually a cooperative or an association.
How to coordinate decisions — local groups each make their own, and coordinate only where it actually makes sense to by federating.
How to make decisions — democratically, through consensus or consent: local groups are dominant, making their own choices rather than deferring to the larger structure.
How to plan — planning and goal-setting happen locally too: groups use and build what's interesting to them and their stakeholders.
How to design — this especially should allow a local identity and policy to arise. They can present that to the larger federation, but don't need to.
How to experiment — they just execute, with no inhibition to do so, because everything is open and available.
How to evaluate — that freedom comes with a responsibility too: to check whether it does what it needs to do, and doesn't cause harm.
How to monitor — in the same vein: how will it perform in the long run, will it stay online, and who will take care of it?