ownCloud Core keeps Classic on PHP, and the tooling still assumes a full toolchain

Two major lines shipped on the same afternoon

The release feed holds three tags in a narrow window. v11.0.1 went out on 25 September 2026, then v10.16.6 on 6 October 2026 and v10.16.7 on 3 November 2026. That interleaving is the interesting part, not the dates themselves. Two maintained major versions of the same server, both receiving patches within weeks of each other, means operators are being asked to choose a support line rather than to assume the newest tag is the only one that matters. Consequence: nothing in this repository tells you which line a bare `make` produces. A developer building from master gets whatever the checkout holds, not a tagged release. If you are evaluating the project, decide the line first and build against that tag, otherwise your first run and your later upgrade can land in different major versions. Both tag names carry their patch level in the name itself, so the 10.x line is on its sixteenth patch while the 11.x line is on its first, and that imbalance is the more useful signal than the ordering of the dates. A site two years into a 10.x install has a long path of patches it already trusts, and jumping it to 11.0.0 means absorbing a major bump rather than a point release.

The one documented build command assumes a populated toolchain

Under the heading for development build prerequisites the project lists Composer v2, Yarn and Node.js at v14 or higher, then gives a single command:

make

That bare target is the entire build surface this repository documents, and it prepares a checkout rather than installing a server. No command for installing a running instance appears here at all; that task is handed to an external installation manual on doc.owncloud.com. The Makefile header repeats the same dependency list in comments and adds a warning that installing Node and Yarn from distribution packages is not recommended because those are often old versions. Consequence: the cost of first use is three tools installed outside the project plus the network access to fetch them, and a checkout on a machine whose distro package for Node sits behind v14 cannot be brought up by anything inside this repository. The one line you get tells you nothing about which major line you just built.

Four analysers resolve through vendor-bin directories

The static analysis and style targets are not global tools. Each is bound to a path inside a per-tool vendor directory:

PHP_CS_FIXER=php -d zend.enable_gc=0 vendor-bin/owncloud-codestyle/vendor/bin/php-cs-fixer
PHP_CODESNIFFER=vendor-bin/php_codesniffer/vendor/bin/phpcs
PHAN=php -d zend.enable_gc=0 vendor-bin/phan/vendor/bin/phan
PHPSTAN=php -d zend.enable_gc=0 vendor-bin/phpstan/vendor/bin/phpstan

Three of them also disable the Zend garbage collector for the child process, which tells you these are expected to be memory-hungry on a large code base. PHPUnit is bound the same way, to lib/composer/phpunit/phpunit/phpunit, and Karma to build/node_modules/.bin/karma. Consequence: none of these five targets work on a fresh clone. They become runnable only after Composer and Yarn have populated those directories, so a contributor who installs one global analyser and expects the make target to use it will get a missing file instead.

Tests default to one SQLite file and one SMB share

Two variables decide what the test suite actually exercises, and both defaults are narrow.

TEST_DATABASE=sqlite
TEST_EXTERNAL_ENV=smb-silvershell

The runtime story is a much wider claim than what the default make target checks. Four databases are named as supported, MySQL, MariaDB, PostgreSQL and SQLite, and the second variable pins acceptance tests to one external storage backend rather than to a matrix. Consequence: a green test-php run on an unmodified checkout tells you the code behaves under SQLite and against one SMB target. It tells you nothing about the connection strings, locking behaviour or migration path that MySQL, MariaDB or PostgreSQL will exercise in production. If your deployment is on any of those three, you have to override the variable and treat the first failing run as a coverage signal rather than a regression.

Five PHP files and one CLI binary sit at the repository root

The top level of the tree puts the whole request surface in the open. index.php, public.php, remote.php, status.php and cron.php are separate PHP entry points, console.php backs the command line tool, occ is the executable users actually type, and db_structure.xml plus version.php sit alongside them. Two dotfiles govern how the web server treats that directory: .htaccess and .user.ini. Consequence: the security posture of a deployment depends on the rewrite and ini directives in those two files. If you deploy behind nginx, or relocate any of these five entry points to satisfy a hosting layout, you are reimplementing the rules in .htaccess, and the file that tells you the server is alive, status.php, is one more file that has to survive whatever you do.

The README sends new deployments to a different repository

Two statements in the README bound what this project can become. It describes itself as the server-side component of ownCloud Classic, and it names ownCloud Infinite Scale, in a separate repository, as the next-generation ownCloud platform. The current file list is consistent with that split: the protocols named in the README, WebDAV, CalDAV and CardDAV, are Classic's server surface, and the plugin architecture is what the Activity, Calendar and Contacts apps plug into. Consequence: for a greenfield deployment the project's own guidance points away from this repository. You can read this code to understand Classic, extend it through the app architecture, or keep an existing install running, but you cannot get the next-generation platform by deploying this code, and choosing it means accepting a PHP runtime on the server path. The plugin architecture is the escape hatch in the other direction. Apps such as Activity, Calendar and Contacts extend the server through that layer, so a feature the Classic server does not ship can arrive as an app rather than as a fork you have to carry.

AGPL-3.0 is Category X and the relicensing has not landed

The Kiteworks Open Source Program Office, launched on 5 May 2026 under the ownCloud brand, is driving a move of ownCloud repositories toward Apache License 2.0. The README is careful about the current state: the licence file in the repository reflects the licence in force, not the target, and the target is Apache 2.0. It also names ownCloud's current licence as AGPL-3.0 and classifies it as Category X under the Apache Foundation's third-party licence policy, which means it cannot be included in Apache-2.0 works at all. Four prerequisites are listed for this repository: every past contributor must have signed agreements permitting relicensing, every AGPL or GPL dependency must be replaced or isolated, KDE-era copyrights need legal analysis, and the relicensing must cover all files rather than just headers. Consequence: if you need an Apache-2.0 dependency tree, this repository is not currently a candidate, and the audit has no published date.

Every contribution needs a signed key and a rebase

The contributor bar is set in the workflow section and it is mechanical. All commits must be PGP or GPG signed, every commit must carry a Signed-off-by line, and the sign-off command is given as:

git commit -s -S -m "your commit message"

The stated workflow is rebase: always rebase on the target branch before submitting a pull request. Dependency updates arrive through Dependabot and are expected to be reviewed promptly, and translations are not accepted as pull requests at all, since they go through Transifex. The GitHub Actions policy narrows continuous integration to actions owned by owncloud, actions published by GitHub itself, or actions verified in the Marketplace. Consequence: a contributor without a GPG key configured cannot produce a mergeable commit, and a workflow file that reaches for any other action will not pass review. Neither rule is negotiable through the pull request itself.

Editorial conclusion

ownCloud Core still fits three situations: an existing Classic deployment that needs to stay on PHP, an evaluation that wants to read the server source rather than deploy it, and a team already signed up for enterprise support through Kiteworks. It does not fit a new deployment that was told to pick the next generation, because this repository sends readers to ownCloud Infinite Scale, and it does not fit a compliance review that needs an Apache-2.0 dependency until the relicensing audit closes. Before committing, check three things: which of the 10.x and 11.x lines the operator already runs, whether the Category X copyleft dependency audit has moved for the components you intend to vendor, and whether your infrastructure can serve PHP alongside the databases listed here rather than a compiled binary.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. owncloud/core on GitHub
3. Project website
4. README
5. Releases