Why ownCloud Is Launching an Open Source Program Office — and Retiring the CLA
Today, from Regensburg, Kiteworks is launching a formal Open Source Program Office (OSPO) with a published Governance Charter v0.1, retiring the Contributor License Agreement, introducing a Developer Certificate of Origin contribution model, a formal AI-Assisted Contribution Policy, and many more. The OSPO functions as a governance body alongside an active production line currently consisting of: ownCloud Infinite Scale with quarterly releases, ownCloud Classic with an upcoming upgrade to PHP 8.3, iOS and Android in the pipeline, the MCP Server with a beta release, and much more. This post walks through what is delivered today, what is in progress, and what contributors, customers, and partners should expect next.
Key Takeaways
- The OSPO is a structural commitment, not a marketing exercise. The Governance Charter defines roles, decision-making, and transparency commitments with a path to v1.0 following Community Advisory Board input.
- The legacy CLA is going to be retired. Contributors will use DCO sign-off (git commit -s) and retain ownership of their work. No copyright assignment to ownCloud GmbH anymore.
- AI-assisted contributions are welcome. The policy sets four requirements: disclosure, comprehension, testing, and licensing compliance, and applies the same review bar as any other PR. We understand inclusion beyond development capabilities.
- The security programme is operational. The VDP at security.owncloud.com, the YesWeHack bug bounty with tiered rewards up to $5,000 for critical findings.
- Two platforms, one commitment. ownCloud Classic runs on PHP 8.3 and is actively maintained; oCIS is the modern database-free, Go-native architecture. A supported ownCloud Classic to Infinite Scale migrator will be available very soon under https://github.com/owncloud/migrate_to_ocis and in the ownCloud 10 Marketplace.
- Introducing a Community Advisory Board, the public product roadmap, and the annual OSPO report are milestones with committed target windows, not claimed achievements.
ownCloud has been through two forks — Nextcloud in 2016 and OpenCloud in 2025. We have reflected on both. The short version is that commercially stewarded open-source projects need inclusive governance and consistent public communication in writing, not just in intention. The OSPO is the operational answer to that.
The OSPO sits under Kiteworks and is funded by Kiteworks. We are not a foundation-governed project and we do not pretend to be one. What we commit to is that steering happens in public, that every rationale is documented, that the community has meaningful channels to influence direction, and that every governance artefact is open for comment and revision. The word we have chosen for this relationship is stewardship: Kiteworks as the corporate steward of sustained engineering, security, and governance investment, with clear written boundaries between the open-source projects and commercial enterprise layers for human and AI data governance, control, and compliance.
The launch ships with a multi-document manifesto suite: the Vision & Mission, the Manifesto, a Foreword from Kiteworks CSO Tim Freestone, a Product Vision for oCIS, the Governance Charter, a Code of Conduct, a Contribution Guide, the AI-Assisted Contribution Policy, the Security Disclosure Policy, and Empowerment and Engagement documents. All of them are today, and all of them are subject to the 30-day public comment period that the charter requires for any future change.
Retiring the CLA: What DCO Actually Changes for Contributors
The legacy Contributor License Agreement required contributors to assign copyright to ownCloud GmbH. It worked in a narrow legalistic sense, but it was a friction point for enterprise procurement teams and independent contributors alike, and it was inconsistent with the governance posture we want to hold.
Contributions now use the Developer Certificate of Origin — a per-commit attestation that you have the right to submit the work under the repository’s licence. It looks like this:
git commit -s -m "Add this awesome implementation to ownCloud Infinite Scale"The -s flag appends a Signed-off-by: line with your name and email. That is it. You retain copyright. You attest to provenance. Reviewers can verify the sign-off in CI. It is the same model the Linux kernel has used for two decades. Prior contributions made under the old CLA remain under their original terms; everything going forward is DCO.
New repositories default to Apache License 2.0. Existing Repos will be relicensed in the foreseen future to Apache 2.0. That said, it will take some time, as it requires individual review of all prior commits and signed CLAs, licenses, used third-party licenses, and origins.
The governance charter defines four roles: Contributor, Reviewer (can approve PRs), Maintainer (merge authority and architectural decisions within scope), and OSPO (governance policy, dispute resolution within 10 business days). If you disagree with a maintainer decision, you can escalate; the OSPO will review, consult, and issue a binding decision on the clock. Governance that takes 90 days to resolve a contribution conflict is not governance: it is attrition.
The AI-Assisted Contribution Policy: Welcoming the Tool, Raising the Bar
We are also publishing something that most commercially stewarded open-source projects have so far avoided: a formal position pro AI-assisted contributions. Ours is straightforward. AI-assisted contributions are welcome, and they are held to the same quality bar as any other contribution. The review process does not care how the code was written. It cares that the code works, is tested, is documented, and is maintainable.
The policy sets four requirements for any AI-augmented pull request:
- Disclosure. State in the PR description that AI tools were used, and name the tool: Claude Code, GitHub Copilot, Cursor, or another. This is not a stigma; it is transparency, and it helps us improve our review processes.
- Comprehension. You have to understand what the code does. If a reviewer asks why a function handles an error the way it does and the answer is “the AI wrote it,” the PR is not ready.
- Testing. AI-generated code needs tests — unit tests for logic, exploratory testing for UI. CI will catch what you forget, but it is not a substitute for thinking about what the code should actually do.
- Licensing compliance. You are responsible for the provenance of every line in your PR. Verify that your AI tool has not introduced code copied from an incompatible licence.
oCIS has already been merged through this workflow, and the full developer methodology is published at owncloud.dev. Our internal engineering teams use these tools as well and hold themselves to the same standards: disclosure where appropriate, full comprehension of generated code, and human accountability for every merge.
The subtext matters. There is a real risk that AI-assisted development becomes a gatekeeping argument that projects quietly reject AI-helped contributions as a proxy for rejecting less-experienced contributors. We are choosing the opposite posture. If you have a vision for improving ownCloud and AI helps you bring that vision to working code, we want your contribution. What we cannot accept is contributors who disappear during review. The human accountability is the whole policy. But senior-level coding ability should not become a tool for exclusion. Open source was, and still is, about inclusion.
Two Platforms, One Commitment: Building the Future with oCIS, Maintaining Trust With Classic
The OSPO launch is also the right moment to be precise about the portfolio. ownCloud Infinite Scale (oCIS) is the current platform: written in Go, Apache 2.0, with a database-free, Go-native architecture that stores metadata in message pack files on the node itself through the DecomposedFS abstraction. There is no central SQL database holding platform state, which removes a class of database-related operational issues: no schema migration on upgrade, no SQL bottleneck under load, no database-level privilege escalation path, and metadata that travels with the file under standard filesystem operations.
The same compiled binary scales from a single process on a small server to distributed microservices on Kubernetes. Production storage backends include POSIX/NFS and S3-compatible object storage (AWS, MinIO, Ceph). CERN EOS is available as a Tech Preview backend, not a production one. Authentication is OIDC-exclusive. Policy is programmable via OPA/Rego through the File Firewall. Federation uses Open Cloud Mesh. Office integration runs through hardened WOPI with Collabora and ONLYOFFICE. Audit logs ship as structured JSON designed for SIEM ingestion. Every interface the platform exposes — WebDAV, OIDC, OCM, CS3APIs, LibreGraph, OPA/Rego — is an open standard or a published specification. The platform is in production at research-computing scale, including at CERN at over a billion files and multi-petabyte scale, and in public-sector deployments including the Bavarian school cloud (ByCS).
ownCloud Classic — the Linux, Apache, SQL, and PHP platform — is an upgrade to PHP 8.3 and actively maintained, continuing to receive security and maintenance releases. A supported Classic-to-oCIS migrator is close to seeing the light of day. Customers (Community and Enterprise) move on their own timeline when the migrator is generally available.
How to Get Involved
The mechanisms that do not yet exist are the ones that need you in them once they do. A few concrete next steps:
- Watch the GitHub repositories at github.com/owncloud: oCIS, Classic, the clients, the web extensions. Issues labelled good-first-issue and help-wanted are genuine asks.
- Read the published policies. The Governance Charter, the AI-Assisted Contribution Policy, the Security Disclosure Policy, and the Contribution Guide.
- Submit a vulnerability report to the VDP or the YesWeHack bug bounty if you find something.
- Apply for the Community Advisory Board formation for Q4 2026 — five to nine external members on 12-month renewable terms; nominations will open publicly.
- Reach the OSPO at ospo@kiteworks.com. For Code of Conduct matters, use coc@owncloud.com. Organisations evaluating an enterprise subscription can use the contact us page — but that is a footnote, not the ask.
Frequently Asked Questions
Because forks are not, by themselves, proof of failure. In open source, forks are often a stress signal. They tell you where trust, governance, communication, or strategic alignment broke down. ownCloud’s own recent public narrative now says exactly that: The first fork in 2016 grew out of governance and transparency concerns, and the second fork in 2025 again shaped by communication and trust issues. The important point is not to deny that history. It is to show that the project has learned from it.
What makes ownCloud credible now is not “please trust us anyway.” It is the combination of continued product delivery and visible governance correction. ownCloud’s April 2026 community posts explicitly recommit to transparency, clearer communication, community input, and “making ownCloud yours again,” while also pointing to continued releases and ongoing investment rather than abandonment.
There is also a more concrete governance signal: ownCloud has publicly announced to retire its CLA and is moving to the Developer Certificate of Origin, framing that as a reduction of power asymmetry between company and contributors. That does not magically erase skepticism, but it is the kind of structural move serious communities look for when judging whether a steward is changing behavior rather than just changing tone.
Nothing retroactive. Your prior contributions remain under the terms that applied when you made them. Going forward, every commit to every ownCloud repository uses DCO sign-off (git commit -s). You retain copyright in your work.
No. We will review it to the same standard as any other PR. The four requirements — disclosure, comprehension, testing, licensing, compliance — are how we make sure the tooling raises quality rather than lowering it. oCIS has already received merges through this workflow.
Yes. ownCloud Classic is on PHP 8.3 and actively maintained, with ongoing security and maintenance releases. The Classic-to-oCIS migrator is very close.
Publicly, on https://github.com/orgs/owncloud/discussions. The OSPO reviews and responds to every comment in writing before publishing. Email ospo@kiteworks.com if you need a pointer to the specific issue tracker.