Sustainability
Current status: protocol specifications (draft). Runtimes are planned deliverables — not yet available.
Faberio is designed to remain useful after the initial release — through open licenses, living specifications, operator-maintainable deployment, and a clear path to expanded scope in later phases.
After the initial release
Phase 2 and Phase 3 produce durable public artefacts, not a proprietary prototype:
| Deliverable | Sustainability mechanism |
|---|---|
| Protocol specifications | Published under CC BY 4.0; revised as an open, living document |
| Reference Runtime, SDK, NixOS module | Published under Apache-2.0; operators can deploy and patch without a vendor |
| Federated Community Hub demo | Open source reference application; patterns reusable for production Community Hubs |
| CI and operator documentation | Reduces long-term maintenance cost for self-hosters |
Maintenance after the initial release focuses on keeping the reference implementation aligned with the spec, fixing validation regressions, and publishing security updates for dependencies — not on operating a centralized SaaS for end users.
Community and adoption
Sustainability does not depend on a single commercial operator. The project is structured for community and operator adoption:
- Self-hosting — NixOS module and container image let communities run nodes on their own infrastructure.
- Open protocol — independent Runtime implementations can emerge without permission from a central vendor.
- Operator governance — administrator approval for nodes and users keeps trust boundaries under information space control, not Faberio-as-vendor.
- No tracking or exploitation — self-hosted infrastructure without mandatory vendor telemetry or platform-layer data monetisation; see Threat Model — No tracking or exploitation.
- Documentation site — public specs and architecture docs lower the barrier for contributors and implementers (https://faberio.dev).
Community growth is expected after the reference Runtime proves multi-node operation — contributors need a working baseline, not only draft specifications. Repository: github.com/faberio-platform/faberio-docs. Contact: info@faberio.dev.
Phase 4 and beyond
The Implementation Roadmap deliberately limits the current scope to server-side Runtime, NixOS deployment, and Federated Community Hub validation. Phase 4 is planned as a follow-up phase for expanded platform capabilities:
| Phase 4 area | Purpose |
|---|---|
| Flutter Runtime (mobile — iOS, Android) | Full device Runtime after Laravel server validation |
| Production Community Hub | Real workloads beyond the minimal web demo |
| Local Civic Platform, Emergency Collaboration & other business applications | Civic, resilience, and domain-specific operational scenarios beyond the validation demo |
| Hardening and scale | Performance, operational tooling, extended security review |
Faberio's phased roadmap is designed so each release cycle delivers complete, publishable outcomes before expanding scope — avoiding simultaneous delivery of mobile clients, full Community Hub products, and production hardening in a single cycle.
Long-term model
Faberio is infrastructure, not a hosted product. Long-term sustainability means:
- Operators maintain their own nodes (updates via NixOS/container channels).
- The protocol and reference Runtime remain openly maintained.
- Application authors build on stable SDK/API surfaces without lock-in to one provider.
- Phase 4 expansion proceeds as a separate development phase rather than stretching the initial release across mobile clients, full Community Hub products, and production hardening simultaneously.
See Threat Model for high-level security assumptions that inform maintenance and hardening priorities.