Why Office Unbound · Open source
Build on what already works.
Build what is missing.
Office Unbound uses established open-source projects for the hard, mature parts of a productivity platform — mail transport, document rendering, file storage, messaging, identity — and puts its own development into what those projects do not provide: one platform that a business can actually run.
Project status Component selection and license review are Phase 1 work, under way now. Every upstream project named on this site is a candidate, not an installed component.
Build on, don’t rebuild
The principle behind every technology decision in the project.
Reliable mail delivery, Office-format rendering, file synchronization with conflict handling, federated messaging and standards-compliant single sign-on are each the product of many years of engineering by dedicated teams. Projects such as Postfix, LibreOffice, Nextcloud, Matrix and Keycloak have handled real production workloads for years, and have found and fixed bugs a new implementation would have to rediscover one at a time.
Rewriting any of them would take years, produce something less tested, and leave the project maintaining code that duplicates work the open-source community already maintains. So Office Unbound does not write its own mail server or document editor. It selects among established projects, integrates them, and contributes back where its integration work exposes problems upstream.
That choice has consequences, and the project accepts them: Office Unbound depends on upstream projects’ release schedules, security response and licensing decisions. Managing those dependencies well — tracking upstream releases and advisories, testing combinations, keeping components replaceable — is part of the job.
Who builds what
The division of labor between upstream projects and Office Unbound’s own development. The full list of candidates, with their licenses, is on the technology page.
Provided by established projects
Each function has one or more candidates Under evaluation
- Virtualization and operating system
- Identity provider, SSO and MFA mechanics
- Directory services
- Mail storage, transport, spam and malware filtering
- File storage, sharing and synchronization protocols
- Document, spreadsheet and presentation editing
- Chat and channel messaging
- Real-time audio, video and screen sharing
- Telephony and SIP
Built by Office Unbound
The project’s own components Planned
- One identity across every service, with consistent roles and policies
- A unified interface and navigation over the separate workloads
- Central administration: users, groups, policies, audit, updates
- Multi-tenant provisioning and delegated administration for MSPs
- A management and provisioning API, including integration with MSP platforms such as clientst0r
- Migration assessment and execution from Microsoft 365 and Google Workspace
- A branded desktop client, reusing open-source sync technology where suitable
- Deployment, update orchestration and packaging for the initial Proxmox VE target
- Documentation, SBOMs and security advisories for the integrated platform
How candidates are chosen
Features are only one criterion, and rarely the deciding one.
- Maturity and maintenance
- Years of production use, an active maintainer team, regular releases and a history of handling security issues responsibly. A capable project with one maintainer is a risk to every customer that depends on it.
- License
- Whether the license permits the way Office Unbound will be distributed and the way MSPs will host it, what obligations it carries, and whether important features sit in a separately licensed commercial edition.
- Standards and protocols
- Support for the open protocols — IMAP, CalDAV, CardDAV, WebDAV, OIDC, SAML, LDAP, Matrix, SIP, WebRTC — that let data and clients move between implementations.
- Multi-tenancy
- Whether one installation can serve several customers with proper separation, or whether tenants need separate instances. This matters most for MSP deployments.
- Operational footprint
- Resource use, upgrade behavior, backup and restore, monitoring hooks — how much work it is to run well, year after year.
- Integration surface
- APIs and extension points that let Office Unbound provision accounts, apply policy and present the service consistently without patching upstream code.
What open source does not mean
Three assumptions worth correcting before they shape a decision.
Not free of cost
An open-source license removes the per-user software fee. It does not remove hardware, storage, bandwidth, backup, administration or support — and those can add up to more than a subscription for some organizations. Some upstream projects also sell commercial editions or support subscriptions. Cost and licensing
Not automatically secure
Public code can be inspected, but that does not mean anyone has. Security comes from review, testing, prompt patching and careful operation. Open source makes those checkable; it does not perform them. Security and transparency
Not free of obligations
Open-source licenses grant rights with conditions. Copyleft licenses require sharing modifications; some, such as the AGPL, extend that to software offered over a network. Trademarks and branding are usually reserved separately from the code.
Working with upstream
Integrating someone else’s project carries a responsibility to that project. The intended practice is to contribute fixes and improvements upstream rather than maintain private changes, to keep any unavoidable patches small and documented, and to follow upstream release and security announcements closely enough that customers hear about relevant advisories through Office Unbound’s own advisories.
Upstream projects’ names and trademarks belong to their owners. Office Unbound refers to them descriptively, and its own branding applies to its own components and to the integrated platform, within whatever branding permissions each upstream license and trademark policy allows.
When an upstream project changes
Open-source projects change maintainers, change direction and occasionally change license. A platform built on them needs to survive that. Keeping services modular, using standard protocols between them and evaluating more than one candidate for important functions — two mail servers, two office editors — is how Office Unbound intends to keep the option of replacing a component without replacing the platform.
No license has been selected for Office Unbound’s own code yet. The choice is being made alongside the review of upstream licenses, because it has to be compatible with the components it integrates and with MSP hosting. It will be announced on the project updates page with the reasoning behind it, and the source repository will be published under it. Until then, nothing on this site should be read as a promise of particular license terms.
There is no public Office Unbound repository yet. Any repository claiming to be Office Unbound’s before an announcement on this site is not the project’s.
Contributing
Once the repository is published, the project will need code, review, testing, documentation and packaging help — and testing against real Microsoft 365 and Google Workspace migrations will matter as much as code. Developers and integrators can register interest now; the community page describes how contribution and security reporting will work.
Community and contributions
Office Unbound for developers and integrators
Want to help build it?
Register your interest in contributing code, review, testing, documentation or packaging. We will be in touch when the repository opens.