Akeneo PIM Community: the repository where the product itself is built

A development repository, not a project template

The most important thing to know about akeneo/pim-community-dev is what it is not. The README says plainly that the repository is used to develop the Akeneo PIM product, with the source code in the src/ directory, and anyone who wants to start a new PIM project based on Akeneo PIM is directed to akeneo/pim-community-standard instead. That distinction decides the audience: maintainers, partners and contributors who intend to change the product, rather than a team that wants a running PIM on its own infrastructure. Contributions go through a fork and a pull request, and translation work is handled on Crowdin, which is a sensible split because the string catalogue is large. The rest of the README is a set of pointers: system requirements, installation, upgrade and test documentation all live on docs.akeneo.com, and this repository holds the code those pages describe.

The stack behind the product

Akeneo PIM is a PHP and Symfony application with a JavaScript front end, and the repository carries the configuration for both halves. The Dockerfile starts from a Debian bullseye slim image and installs PHP 8.3 with the extensions the product needs, including intl, opcache, mysql, zip, xml, gd, grpc, curl, mbstring, bcmath, imagick, apcu, exif and memcached, plus ImageMagick, Ghostscript and the aspell dictionary set. The base environment sets a 512M memory limit, a 60 second maximum execution time and a 40M upload and post size limit, which tells you something about the intended workload. On the front end, yarn drives webpack and less compilation, jest runs the unit and integration suites, behat drives the acceptance tests and cypress covers the browser side, with a selenium image for the browser tests. Static analysis is handled by phpstan, with a separate deprecation ruleset.

Bringing the stack up with Docker and the Makefile

The documented local entry point is a Docker image built from the Dockerfile in the root:

docker build --target dev -t akeneo/pim-php-dev:master .

The dev target produces the image that docker-compose.yml then orchestrates, with a php service running php8.3, an fpm service running php-fpm, a node service on node 18 for the front end, and a selenium service for the browser tests. Every service bind mounts the working directory into /srv/pim, so the code on the host is the code being served. The Makefile is the layer above that, and it warns that its targets are optimised for docker 19 or newer:

make help

The help target lists the rest, including node_modules, assets, css and front, where front is the combination that prepares assets, compiles less, builds the front packages and starts the development webpack server. Custom targets can be dropped into the make-file directory, which is where a team with unusual needs is expected to put them.

Calendar versioning and the habit of pinning

Akeneo PIM uses calendar versioning in the form vYYYY.Minor, and the README is unusually explicit about what that means: the project does not follow semantic versioning and does not guarantee backwards compatibility between any two versions, and breaking changes may arrive in any release. The published versions follow that shape, with v2026.4 dated 2026-08-28, v2026.3 dated 2026-03-30 and 2026-2 dated 2026-02-10. The documented defence is to pin the dependency in composer.json, so the recommendation given is to require one exact version:

"require": {
    "akeneo/pim-community-dev": "v2026.3"
}

There is also a version.txt in the repository root and a lock file, and a composer.json whose package version field still reads 7.0.0, a leftover from the pre-CalVer numbering that tells you how the scheme was introduced.

The upgrade path and its migration debt

Upgrading is a separate procedure with its own documentation page, and one trap is called out in the README: moving from the 7.x.y series to the new numbering requires that all existing migrations from the 7.0 branch have been applied first, which means a long-lived installation carries a queue of migration steps before it can take a modern tag. The repository supports that work directly, with an upgrades/ directory, an UPGRADE.md file at the root and separate CHANGELOG files for the 5.0, 6.0 and 7.0 series. The 7.0 series is also where the number of releases under the old scheme ended, so the CHANGELOG files cover exactly the period that the new scheme replaced. For a team that upgrades annually this is manageable; for a team that skipped several versions it is the part of the migration that needs planning rather than a scheduled job.

Where the community development setup falls short

The friction is structural and worth naming before anyone forks. The front end is served by a webpack development server, so the workflow assumes a running node service and a writable bind mount, which is comfortable on a workstation and awkward on a shared build agent. The selenium image is pinned to a 3.141.59 tag, an old Chrome build, so the browser tests will not exercise a current browser, and the PHP side is pinned to a 8.3 image tag for the same reason. The Makefile itself says the targets are optimised for docker 19 and newer, which quietly narrows the set of machines this can be developed on. And because the project states that it does not guarantee compatibility between any two versions, every dependency bump is a migration project, not a patch.

Akeneo PIM Community next to a plain PIM installation

The genuinely documented alternative sits in the same organisation: the standard distribution repository, pim-community-standard, is what the README tells you to use when the goal is to create a PIM project rather than to change the product. The difference in approach is packaging rather than capability. The standard repository is a project skeleton with a versioned dependency on the product, so you get a running PIM and an upgrade path that follows the tags; the development repository is the product source with a Docker dev image, a Makefile and the full test matrix, so you get the ability to patch the code and a workflow built for contributors. A team that only needs to model products should take the standard route. Forking the development repository is justified only when the change cannot be expressed as configuration, a bundle, or a connector.

Licence terms and the contribution route

The licence here is not one GitHub recognises: the terms live in a LICENCE.txt file in the repository root, and a project that ships its own licence text instead of a standard identifier deserves a read before you build on it. Contributions are made by forking and opening a pull request, and the CI configuration sits in a .circleci directory with the test entry points wired through the Makefile, while translation strings are managed on Crowdin. The last push was on 2026-10-12 and the repository is not archived, so the product is being worked on continuously even though individual releases land only a few times a year.

Editorial conclusion

akeneo/pim-community-dev fits maintainers and partners who intend to change the Akeneo PIM product, and it does not fit a team that simply wants to run PIM, because the README points those users at akeneo/pim-community-standard instead. Before forking, read LICENCE.txt, because GitHub cannot categorise the terms this repository ships under, and pin your dependency to an exact CalVer version rather than a range, since the project states that it does not guarantee compatibility between any two versions. The first thing to verify locally is that the Docker image builds with the dev target, because the whole workflow hangs off it.

Frequently asked questions

Official sources

1. akeneo/pim-community-dev on GitHub
2. Issues
3. Project website
4. README
5. Releases