FreeToastHost 4 is being developed in public, on GitHub, under the AGPL-3.0 licence — and it's being built specifically to be donated to the FreeToastHost stewards so the platform that has served clubs since 2004 can continue under the same hands, on the same domains, for the next twenty-two years.
FTH4 is being built to be given away. The codebase, the infrastructure-as-code, the deployment runbook, and the migration plan are all designed to be handed over to the FreeToastHost stewards — the volunteer team that has run toastmastersclubs.org and toastmastersdistricts.org since 2004.
Every architectural choice optimises for "easy to take ownership of," not "easy for us to lock in." The demo on this site exists so the stewards (and pilot clubs) can evaluate a working system before adoption. After handover, the platform runs on the existing trusted domains and the demo retires.
If you read no further on this page, that's the headline: this is a gift, with intent.
A short answer: AGPL-3.0 keeps FreeToastHost free. A longer answer follows.
If someone forks FTH4 and runs a hosted version of it, AGPL requires them to publish their source. A future commercial fork cannot quietly privatise the platform — the social contract Bo Bennett wrote in 2004 stays enforceable in code.
A club, district, or region can clone the repository and run their own copy of FTH4 on their own infrastructure, with the same software the donated production runs. AGPL just asks that any modifications you publish-as-a-service are themselves open.
Authors retain copyright to their contributions. We use a lightweight DCO sign-off on each commit (git commit -s) instead of a Contributor Licence Agreement — the same pattern the Linux kernel and most modern open-source projects use.
The "FreeToastHost" name and goodwill belong to the existing project. We use the name with the stewards' acknowledgement and do not register competing marks. AGPL covers the code; the trademark is honoured by convention.
FTH4 needs more than just code. Whatever your skills, there's likely a path in — and we've designed the contributor experience for Toastmasters first, full-time engineers second.
You know your club's site best. Open issues when something doesn't work the way you'd expect. Suggest features. Try the demo and tell us what feels off.
Help us pilot the platform on a real club site. Read the plan, push back on what won't work for your district, contribute to the deployment runbook.
Pull requests welcome — Rails, Hotwire, Postgres, accessibility, performance, tests. Issues labelled good first issue are curated weekly. Contributions go in under DCO sign-off.
The current FTH3 docs feedback channel has been silent for four years. We want to do better. Improve a doc page, propose a tutorial, or write an end-of-year officer-changeover guide.
FTH4 ships native i18n at v1. We're targeting Spanish, French, German, Mandarin, Japanese, Hindi, and Arabic first — native-speaker reviewers especially welcome.
UI/UX feedback, visual-design proposals, accessibility audits. The Toastmasters brand language is already a beautiful starting point; we want help carrying it through every screen.
Run a screen reader through the public site. File anything that fails. WCAG 2.2 AA is a launch requirement, not a roadmap item, and we need real-world testers to make that real.
Responsible disclosure via security@. We follow a 90-day disclosure policy. A public security advisory is published with each fix; researchers credited unless they opt out.
Don't see your skill on the list? Open a "I'd like to help with X" issue on GitHub. The contributor experience is a work in progress and we'd rather widen the door than miss a good contributor.
FTH4 picks technologies on three criteria, in order: can a small volunteer team operate it? · can the next maintainer learn it from the docs? · does it fix the specific failure modes of the past?
That's why Postgres is the only datastore. The queue (Solid Queue), the cache (Solid Cache), and the real-time pub-sub (Solid Cable) all run on Postgres. There's no Redis to monitor, no separate broker to upgrade, no Kubernetes cluster to maintain. Deploys go through Kamal 2 — Docker images pushed over SSH to any Linux host. A steward can run kamal deploy from a laptop.
Local development is a single command: clone the repo, run bin/setup && bin/dev, and you have a working FTH4 in under ten minutes on a fresh laptop. The contributor docs assume you've never built a Rails app before.
When the FreeToastHost stewards accept FTH4, the handover package includes everything they need to take ownership without surprises.
Source, history, issues, pull requests, releases, and decision records. Transferred to the stewards' GitHub organisation at handover, or kept where it is — their call.
Parameterised so the stewards can deploy onto their own infrastructure by changing the inventory file. No proprietary platform-as-a-service. Any Linux host with SSH and Docker will run it.
Written for a steward who has never deployed a Rails app before. Step-by-step. With the actual commands to run, what success looks like, and what to do when something fails.
A documented path from FTH3 production to FTH4 production under the stewards' control. Opt-in per club, batched, with long parallel-run windows. No big-bang weekend.
If the stewards prefer a different OSI-approved licence, we'll change it before handover. Default is AGPL-3.0 because it best protects the "free for clubs" social contract.
For 90 days after handover, the people who built FTH4 stay on the on-call rota at no cost to the stewards. After that, the stewards run it. We continue contributing as community members.
The repo is being prepared for public release. Until then, the plan documents and demo on this site are the public face of FTH4. Read the plan, send feedback, and watch this space.
Public repo will go live at github.com/<org>/freetoasthost4 once the stewards confirm the GitHub organisation name. Version history →