en
Contact
ownCloud on GitHub
Blog
Search
Close

Contribution Guide

How to contribute to ownCloud: Guidance and Support.
Learn how to contribute to ownCloud with our guide on contributions, licensing, and DCO sign-off.

Who can contribute

We welcome contributions from everyone – developers, documentation writers, designers, translators, testers, and anyone who wants to help improve ownCloud. Whether you are fixing a typo or building a complete web extension, this guide explains how to contribute.

 

Licensing

Target license for new projects: Apache License 2.0

ownCloud is transitioning to Apache 2.0 as the default license for new repositories and components under the OSPO. Apache 2.0 is permissive, well-understood, compatible with most enterprise and public-sector procurement requirements, and widely adopted across the open source ecosystem.

Legacy repositories may retain their existing licenses during a transition period:

Repository / Component Current License Transition Plan
oCIS Apache 2.0 Already on target license
Desktop Client GPL v2 Under evaluation
Android Client GPL v2 Under evaluation
iOS Client GPL v3 Under evaluation
ownCloud Server AGPLv3 End-of-life; no license change planned

License changes for existing repositories will be communicated with advance notice and community consultation. We do not change licenses retroactively on already-released code.

No CLA Required – We Use DCO

ownCloud does not require a Contributor License Agreement (CLA). We previously used a CLA that included a full copyright assignment to ownCloud GmbH. That CLA transferred your entire right, title, and interest – including all rights under copyright – in your contributions to ownCloud. We have retired this practice. It is no longer required for any new contributions to Apache 2.0 licensed components.

Instead, we use the Developer Certificate of Origin (DCO). The DCO is a lightweight, per-commit attestation that you have the right to submit the code under the project’s license. It does not transfer copyright to ownCloud GmbH. You retain full ownership of your contributions – in the sense of the Apache 2.0 license.

To sign off on a commit, add a Signed-off-by line:

git commit -s -m \"Add photo metadata search support\"

(Ensure PGP is enabled: https://docs.github.com/articles/about-gpg)

This adds a line like:

Signed-off-by: Your Name <moc.liame@ruoy>

The DCO text (available at developercertificate.org) confirms that:

  • You wrote the contribution, or have the right to submit it.
  • You are submitting it under the project’s license.
  • You understand the contribution is public and that a record is maintained.

For contributors who previously signed the old CLA: Your existing contributions remain valid. No further action is required. New contributions simply need DCO sign-off.

For corporate contributors: If your employer has intellectual property policies, ensure you have permission to contribute under the DCO. Many organizations have blanket open source contribution policies. If yours does not, the DCO’s per-commit nature makes it easier to get targeted approval than a blanket CLA.

How to Contribute

  1. Find something to work on. Browse issues labelled “good-first-issue” across our repositories. Check the project roadmap and open RFCs for larger initiatives. If you have an idea, open an issue first to discuss it before investing significant effort.
  2. Fork and branch. Fork the relevant repository and create a feature branch. Branch names should be descriptive: feat/photo-metadata-search, fix/ocm-federation-timeout, docs/improve-deployment-guide.
  3. Develop. Follow the coding conventions of the repository (language-specific linting rules are enforced in CI). Write tests for new functionality. Document new features, configuration options, and APIs. If you are using AI-assisted development, follow our AI-Assisted Contribution Policy – disclose, comprehend, test, document.
  4. Commit with DCO sign-off. Every commit must include a Signed-off-by line. Commits without DCO sign-off will be flagged by our CI checks and cannot be merged.
  5. Submit a pull request. Write a clear PR description: what does this change, why, and how should it be tested. Reference related issues. Include screenshots for UI changes. Be responsive to review feedback.
  6. Review and merge. Maintainers will review your PR for correctness, code quality, test coverage, documentation, and architectural fit. This may take multiple rounds. That is normal. PRs that pass review are merged by a maintainer.

Types of Contributions

Code is the most visible form of contribution, but far from the only one. We value and recognize:

  • Documentation: Guides, API docs, deployment instructions, translations.
  • Testing: Bug reports with reproduction steps, test case contributions, exploratory testing.
  • Design: UX feedback, wireframes, accessibility improvements.
  • Community: Answering questions in forums, mentoring new contributors, organizing events.
  • Advocacy: Blog posts, conference talks, case studies.

     

    Code of Conduct

    All contributors are expected to follow our Code of Conduct. We are committed to a welcoming, respectful, and inclusive environment.

    Violations and concerns can be reported to moc.duolcnwo@coc.

    Communication Channels

    • GitHub Issues and PRs: Primary channel for technical discussion.
    • Documentation: doc.owncloud.com
    • Community Forums: central.owncloud.org
    • OSPO Contact: moc.skrowetik@opso

    Recognition

    • GitHub contributor graphs and release notes.
    • Security hall of fame for vulnerability reporters.
    • Community spotlights and event invitations.
    • Contributor pathways: active contributors may be invited to become reviewers, maintainers, or advisory board members.