Skip to main content

Why a Public Stack

Most software today is delivered as a managed service: a vendor runs the infrastructure, handles the updates, and charges per seat. Convenient, but control, data ownership, and long-term flexibility all sit with the vendor, not with you. For a democratic organisation that's not a minor trade-off, it's a fundamental one: an organisation built on collective ownership and self-organisation ends up renting its own infrastructure back from a vendor whose interests aren't its members'. Now imagine the alternative — infrastructure the organisation actually owns, shaped by the people who use it and accountable to nobody but its own members: technology as democratic as the movement running it.

Comparison

Managed (SaaS)Self-hostedFOSSCustom-built
SetupInstantRequires configurationRequires configurationRequires development
MaintenanceVendor handles itYou handle itYou handle itYou handle it, alone
CostPer-seat subscriptionInfrastructure + licence feesInfrastructure onlyAI/development time + infrastructure
DataOn vendor's serversOn your own serverOn your own serverOn your own server
ControlLimited to what vendor allowsFull (software terms apply)FullFull
Lock-inHighMediumNone — can fork and modifyHigh — only you understand the code
Auditability✓ Source is public✗ unless deliberately opened

In short

Self-hosting FOSS software, documented under a Public Stack framework, gives a democratic organisation the same thing it tries to build everywhere else: collective control over the conditions members depend on, rather than dependency on someone else's terms.

  • Values alignment — the tools, providers, and decisions can reflect what the organisation stands for: sovereignty over data, environmental sustainability, transparency, and privacy.
  • Cost — infrastructure is paid for, not per-seat subscriptions. For an organisation with many occasional users, a flat cost beats punishing per-seat pricing.
  • Freedom — data is yours, formats are open, and the organisation can shape its tools and information into something that actually fits it, rather than adapting itself to what a vendor provides.
  • Capability — maintaining your own infrastructure builds real skills, spread across the people who do it, not concentrated in a vendor's support team.
  • Memory — writing down why these choices were made means the reasoning outlives any one contributor.
  • Common ownership — choosing FOSS over closed custom code, even when AI makes the latter easy, keeps the effort feeding a shared commons instead of a private one.