ownCloud Governance Charter: Principles and Transparency
ownCloud Community Governance Charter
ownCloud — a Kiteworks company
Status: Aspirational (v0.1) — This charter describes our intended governance model. We are implementing it in phases. Items marked with a target date reflect our current plan, not a commitment.
Principles
- Transparency. Decisions that affect the community are made in public. Roadmap priorities, architectural decisions, and policy changes are discussed in open channels. Where decisions must be made internally (for example, for security or commercial reasons), we explain the outcome and rationale as soon as possible.
- Stewardship, not ownership. Kiteworks is the corporate steward of ownCloud. Stewardship means investing in the project’s long-term health — funding development, maintaining infrastructure, ensuring security — while respecting the community’s voice in shaping the project’s direction. Stewardship is not the same as unilateral control.
- Earned authority. Maintainer status, reviewer rights, and governance roles are earned through sustained, high-quality contribution. They are not granted by title, employment, or tenure alone.
Roles
Contributors
Contributors are anyone who contributes to the project: code, documentation, testing, design, advocacy, or community support. All contributors are expected to follow the Code of Conduct and the DCO sign-off process.
Reviewers
Reviewers are experienced contributors who have demonstrated consistent quality and familiarity with a specific area of the codebase. Reviewers can approve pull requests but cannot merge without a maintainer’s sign-off. Reviewer status is granted by maintainers based on contribution history.
Maintainers
Maintainers are responsible for the security, health, quality, and direction of one or more repositories or components. Maintainers can merge pull requests, approve releases, and make architectural decisions within their scope. Maintainer status is granted by the OSPO in consultation with existing maintainers and based on a track record of significant, sustained contribution.
OSPO (Open Source Program Office)
The OSPO is the organizational body within Kiteworks responsible for ownCloud’s open source strategy, governance, licensing, community health, and ecosystem engagement. The OSPO sets policy, resolves disputes that cannot be resolved at the maintainer level, and serves as the interface between the community and Kiteworks leadership.
Decision-Making
Technical Decisions
Architecture, API design, and implementation approach are decided by maintainers within their scope, with input from reviewers and contributors through GitHub issues and PRs. Disagreements are resolved through discussion. If consensus cannot be reached, the relevant maintainer or maintainers decide. Decisions can be escalated to the OSPO.
Policy Decisions
Licensing, contribution rules, governance changes, and Code of Conduct enforcement are decided by the OSPO with input from the Community Advisory Board and the maintainer group.
Roadmap Decisions
Roadmap decisions are made by Kiteworks product management in consultation with the OSPO and the Community Advisory Board. Kiteworks sets strategic direction. The community influences priorities through the CAB, through GitHub issue engagement (upvotes, comments, RFCs), and through direct contribution.
We are honest about this: Kiteworks steers the roadmap. This is a commercially-backed open source project, not a foundation-governed one. What we commit to is that the roadmap is public, the rationale is explained, and the community has meaningful channels to influence it. If you build it and it is good, it has a path to merge — regardless of whether it was on the roadmap.
Governance Bodies
Maintainer Group
The maintainer group is composed of all active maintainers across ownCloud repositories. It meets regularly (monthly or as needed) to discuss cross-cutting technical issues and maintains a public list of maintainers per repository.
Target: Publish initial maintainer list by Q3 2026.
Community Advisory Board
The CAB consists of 5–9 members drawn from external contributors, institutional users, and technology partners. Members serve 12-month terms, renewable once. The CAB meets quarterly with the OSPO to review roadmap, governance, and community health. Meeting summaries are published publicly.
Target: Establish inaugural CAB by Q4 2026.
Open Source Program Office
The OSPO is led by the Vice President, Open Source Program Office at Kiteworks. It is responsible for governance policy, licensing, community health metrics, ecosystem engagement, and upstream contribution strategy. The OSPO publishes an annual report covering contribution statistics, governance changes, community health, and strategic direction.
Contact: moc.skrowetik@opso
Target: First annual OSPO report by Q2 2027.
Conflict Resolution
Disagreements are a normal part of open source. Our approach:
- Discussion. Most disagreements resolve through respectful discussion on the relevant GitHub issue or PR. Assume good faith.
- Maintainer decision. If discussion does not resolve the issue, the relevant maintainer or maintainers make a decision and document the rationale.
- OSPO escalation. If a contributor disagrees with a maintainer decision, they can escalate to the OSPO. The OSPO will review, consult with relevant parties, and issue a binding decision within 10 business days.
- Code of Conduct violations are handled separately through the CoC enforcement process. Reports go to moc.duolcnwo@coc.
Transparency Commitments
- Public roadmap. Maintained and updated at least quarterly. (Target: Q3 2026)
- Public maintainer list. Per-repository, kept current. (Target: Q3 2026)
- Architecture Decision Records (ADRs). Significant architectural decisions are documented as ADRs in the repository (already in practice for oCIS).
- Governance changelog. Changes to this charter, to licensing, or to contribution policy are announced publicly with a minimum 30-day comment period before taking effect.
- Annual OSPO report. Published publicly. (Target: Q2 2027)
Licensing Governance
New repositories default to Apache License 2.0. License changes to existing repositories require OSPO approval, a public RFC with a 30-day comment period, and Community Advisory Board consultation.
ownCloud does not use license ambiguity as a commercial lever. Licensing choices are public, intentional, and consistently applied.
Evolution of This Charter
This is version 0.1 of the governance charter. It will evolve as the community grows and matures. Changes follow the governance changelog process:
- public announcement
- 30-day comment period
- OSPO decision
We recognize that this charter is aspirational in parts.
Some mechanisms —
- the CAB
- the annual report
- the maintainer list
— do not yet exist. We are publishing the charter now, rather than waiting until everything is in place, because we believe transparency about where we are going is better than silence.
Implementation Timeline
| Milestone | Target Date | Status |
|---|---|---|
| Publish Governance Charter v0.1 | Q2 2026 | In progress |
| Retire legacy CLA, implement DCO | Q2 2026 | In progress |
| Publish AI-Assisted Contribution Policy | Q2 2026 | In progress |
| Publish Security Disclosure Policy | Q2 2026 | In progress |
| Publish initial maintainer list per repository | Q3 2026 | Planned |
| Publish public roadmap | Q3 2026 | Planned |
| Establish Community Advisory Board | Q4 2026 | Planned |
| First CAB meeting | Q4 2026 | Planned |
| First annual OSPO report | Q2 2027 | Planned |
| Governance Charter v1.0 (post-CAB input) | Q2 2027 | Planned |