oroinc/crm: the OroCRM core package that expects you to bring an application

A composer package that refuses to be an application

The single most important sentence in the README is also the shortest constraint: OroCRM is a composer package that requires an application to initialize and run it. The repository is not a deployable product. There is no web server to start, no database to provision, and no installer to click through, because everything the project offers is the core functionality, packaged for inclusion in something else.

That reframing changes who the project is for. The audience is a PHP team that already intends to own an application, with the deployment, the routing and the release process, and wants CRM capabilities assembled inside it. The README points at crm-application as an example of such an application, described as simplifying initial project setup and configuration. The relationship is the way to read this repository: an example application for the required host, and a package for the actual functionality.

For anyone expecting a turnkey product, this is the wrong repository entirely, and no amount of reading the documentation will change that.

PHP on OroPlatform and Symfony, with OroTeam behind it

The README states that OroCRM is built in PHP on OroPlatform and Symfony, a full-stack web framework, and the repository topics list oroplatform and symfony alongside crm and crm-platform. The architecture is therefore layered: the generic application platform comes from OroPlatform, the web framework conventions come from Symfony, and the CRM domain lives in the package this repository holds.

The separation is visible in the repository layout as well. The src directory holds the PHP sources, composer.json and dev.json describe the dependency setup, and the root contains compatibility documentation, a CHANGELOG.md and a security.md file rather than an application entry point. There is no bin directory, no public directory and no index.php, which is what a framework package looks like and what an application would not look like.

The people behind it are named too. The README describes OroTeam as the team behind OroCRM, and states that they believe no two businesses are alike, which is the stated reason the application is flexible and highly customizable. That claim is the design rationale for a product aimed at eCommerce, retail, financial services and other industries, according to the README.

The product scope is a 360 degree customer view plus campaigns

What the package actually provides is described in the opening paragraph: a 360 degree view of customers across multiple channels, organization of the sales pipeline, management of account and contact information, communication with customers, marketing campaigns, and tracking of campaign performance.

Two observations are worth making about that list. First, it is a business application feature set, not a library surface, so adopting OroCRM means adopting a domain model with entities for accounts, contacts, opportunities and campaigns, and that model then constrains how your application is written. Second, the README frames the 360 degree view around channels rather than around a single contact record, which is the harder problem and the reason a customizable platform is offered in the first place.

The documentation itself is external. The README links OroCRM documentation, a contributing page and a page for reporting a security issue, all hosted on doc.oroinc.com. Nothing about the internals is described in the repository, so the feature list above is the full extent of what the project states about itself.

Upgrade cost is documented version by version

The most telling thing in the repository is not in the README. The root contains a long run of files named incompatibilities-2-1.md through incompatibilities-6-1.md, covering the 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 4.0, 4.1, 4.2, 5.0, 5.1, 6.0-rc and 6.1 lines. Each major version has a document describing what changed in a way that breaks existing customization.

This is a project that expects its users to customize it heavily, which is exactly why breaking changes are tracked in per-version documents instead of being left to the changelog. The CHANGELOG.md sits alongside them for the narrower history. For an adopter, the practical consequence is that an upgrade is a reading exercise, not a composer update: you work through the notes for the versions between yours and the target, and then fix whatever your own overrides touched.

The presence of a 6.0-rc document also tells you the versioning has reached the point where release candidates get their own compatibility review.

Travis, PHPUnit and Scrutinizer, with the config left in the repo

The development setup is visible in the file list. A .travis.yml drives continuous integration, travis.php.ini holds the PHP settings for that run, phpunit.xml.dist configures the test runner and bootstrap_test.php is the test bootstrap. The README also carries a Scrutinizer Code Quality badge pointing at the master branch. A .github directory sits alongside for issue and pull request templates or workflows.

That combination dates the project in a specific way, and it is worth being blunt about it. Travis CI as the continuous integration service and a Scrutinizer badge are choices that were common in the mid-2010s PHP ecosystem, and both point at a project whose original engineering practice predates the current generation of CI tooling. Nothing in the file list contradicts that, and the repository is not archived, so this is a live codebase that carries an older setup forward rather than a dead branch.

The test entry point is worth noting for anyone planning to run the suite themselves: phpunit.xml.dist plus bootstrap_test.php is the contract, and it is distributed in the repository, so the same configuration the project used is available to a fork.

A custom licence that GitHub cannot classify

The licence deserves a separate mention because the classification is unusual. The repository's licence is recorded as Other, a custom licence that GitHub cannot classify, with the LICENSE file at the repository root as the authoritative text. There is a separate security.md for responsible disclosure.

For an engineer this means the licence cannot be read off a badge. A team that normally checks for Apache-2.0 or MIT before using a dependency has to open the LICENSE file and read it, and a procurement or legal review has to treat it as a bespoke agreement rather than a known permissive licence. The NOTICE-style credits that usually accompany a permissive corporate licence are not something the README mentions, so the LICENSE file is the only place to look.

This is a factual boundary, not advice. What the licence permits or requires is decided by its text, and this project has chosen not to use a licence identifier that tooling can recognise.

The last push is current while the tagged releases are from 2017

The maintenance picture has two halves that need to be read together. The repository is not archived and the last push was on 2026-10-15, so work is happening on the branch. The listed releases are a different story: 2.0.6 and 2.0.5 were both tagged on 2017-04-14, and 2.1.0 on 2017-03-30.

Those tag dates are three years older than the incompatibility documents, which run to 6.1. The gap is consistent with the package model. The master branch carries the current development line, while published tags trail behind it, so pinning to a tag gets you the 2017 line rather than the code that the recent commits and the 6.x compatibility notes describe.

So the repository is not abandoned, and it is also not a project where a new dependency version appears regularly on a package registry. Which of those two facts matters depends entirely on whether you intend to build on the current master or to consume a published artifact.

Two ways in: compose the package yourself or start from crm-application

The documentation supports two concrete approaches, and choosing between them is the first decision a new team faces.

The first is to add the package to an application you already own. You write composer.json yourself, requiring oroinc/crm, and you take responsibility for bootstrapping the application, the Symfony kernel, the database and the configuration. The second is to start from the crm-application example, which the README describes as simplifying initial project setup and configuration, and which gives you a working host into which the package drops.

The difference in approach is one of ownership. The example application gets you running sooner but couples you to a scaffold that is not the package itself, and you will still own every upgrade decision. Building your own host costs more up front and leaves you with an application shaped the way you want. Both routes end in the same place, which is that a major version bump sends you back to the incompatibilities notes for the CRM-specific changes your own code has to absorb.

The README does not compare OroCRM with other CRM products or with other PHP platforms, so beyond this choice of starting point there is no documented alternative to weigh against it.

Editorial conclusion

OroCRM suits a PHP team that wants a configurable CRM core inside a Symfony application it controls, and that will read the incompatibility notes before each major upgrade. It is the wrong choice if you need something you can deploy and use on the day you download it, because the repository deliberately contains no runnable application. Before committing, check the LICENSE file, since the project uses a custom licence that GitHub cannot classify, read the incompatibilities notes for the version you plan to adopt, and start from the crm-application example rather than assembling the stack from scratch.

Frequently asked questions

Official sources

1. Issues
2. oroinc/crm on GitHub
3. README
4. Releases