iDempiere: a community-run ERP, CRM and SCM suite in Java

A business suite grown from ADempiere and Compiere

The README describes iDempiere as an open-source Enterprise Resource Planning, Customer Relationship Management and Supply Chain Management solution built by the community, for the community, and the repository description adds manufacturing and point of sale to the list. So the scope is a full business suite rather than a single domain tool.

The history is stated too, and it explains the character of the codebase. The business logic evolved from ADempiere and Compiere, refined by years of real-world use. That lineage is the most important fact in the repository for an engineer sizing up the project. A suite with two decades of accumulated domain logic is not a codebase you adopt by reading documentation, it is one whose behaviour is learned by running it and by having implementors who already know it.

The homepage is idempiere.org, and the documentation is spread across a Docusaurus site at docs.idempiere.org, a wiki at wiki.idempiere.org and a set of real-world use case pages under the solutions section. The foundation is stated as Java with PostgreSQL or Oracle.

The licensing detail is worth catching early, and there is a discrepancy. The README badge reads GPL-2.0, while the repository listing records the licence as a custom one that GitHub cannot classify. Both the LICENSE.md file and a license.html file sit at the repository root, so the files are there to settle the question.

OSGi is the extension model, not a detail

The differentiator the README puts first after the community claim is the modular architecture, a flexible plugin system powered by OSGi. That single choice shapes everything else about the project.

OSGi is a runtime module system for Java, and treating it as the extension mechanism means functionality arrives as bundles that are installed, started and stopped at runtime, with dependencies declared between them. The repository layout is the proof. There are feature directories such as `org.adempiere.base-feature`, `org.adempiere.pipo-feature`, `org.adempiere.replication-feature`, `org.adempiere.replication.server-feature`, `org.adempiere.report.jasper-feature`, `org.adempiere.server-feature` and `org.adempiere.ui.zk-feature`, and each one is paired with the bundle it packages, such as `org.adempiere.base`, `org.adempiere.pipo`, `org.adempiere.replication.server`, `org.adempiere.report.jasper` and `org.adempiere.server`.

That is a very large surface for a single repository, and it exists because the suite is assembled from deployable units rather than compiled into one application. A second feature directory, `org.adempiere.payment.processor-feature`, shows the same pattern for payment processing.

The Eclipse Equinox fragment in the tree, `org.adempiere.eclipse.equinox.http.servlet`, identifies the specific OSGi runtime in use, since Equinox is the reference implementation. The practical consequence for an adopter is that the deployment model is a bundle repository rather than a war file, and that plugin versions have to be reasoned about rather than assumed.

The web client is ZK, and the model is generated

The user interface is built on ZK, and the repository shows it as a first-class part of the product rather than an afterthought. There is an `org.adempiere.ui.zk` bundle with its matching `org.adempiere.ui.zk-feature`, and the zk tag appears in the project topics alongside osgi, java, crm and erp.

The interesting companion piece is the model generator. The tree contains `org.adempiere.modelgenerator.app.xml`, and there is a `generate-ds.sh` script at the root, which is the kind of tool that generates the data structures the model layer expects. Alongside the generator there are dedicated bundles for the base process and the base callout, `org.adempiere.base.process` and `org.adempiere.base.callout`, which is the ADempiere pattern of separating business rules into process and callout plugins rather than embedding them in the core.

Together these say something specific about the architecture. The domain model is not hand written in one place; it is generated, and the rules that act on it live in pluggable units. For a business suite that is the design that makes third-party extensions possible, and it is also the design that makes a change to the core something you have to think about twice.

The client is served over HTTP, and the Equinox servlet fragment is the piece that exposes the OSGi HTTP service, so the web tier and the plugin runtime are bound together rather than layered.

Try it in a browser before installing anything

The getting-started advice in the README is unusually practical. It points to live cloud test sites, described as a way to experience iDempiere instantly with no installation required, and it links the official installation guide on the documentation site for anyone who wants it locally, with step-by-step setup instructions.

That ordering is worth taking seriously, because the interesting question about a suite like this is not whether it installs but whether its business model matches your organisation. The test sites answer that question in an afternoon, and the configuration work that follows is the real work.

The repository itself shows what a local setup involves. There is a `db` directory, a `migration` directory and a `migration-historic` directory, which is the record of the database evolution over the product's life, plus `adempiere-local-template.properties` as a template for local configuration. Two shell scripts at the root, `RUN_ImportIdempiereDev.sh` and `RUN_SyncDBDev.sh`, are the developer-facing import and database sync steps. The build is Maven, and the repository ships the wrapper as `mvnw` and `mvnw.cmd` rather than relying on a Maven installation on the machine.

So the local path is a Java build with a Maven wrapper, a properties file for configuration, and database scripts to run. That is more moving parts than a typical self-hosted application, which is exactly why the hosted test sites come first in the documentation.

Jenkins builds it, JIRA tracks it, Mattermost hosts the conversation

The tooling tells you how the project is actually run, and it is conventional in a good way. The README states that all continuous integration and automated testing are managed with Jenkins CI, and the build badge points at jenkins.idempiere.org, so the project's own CI server is public and you can watch it work.

Issues go through a tracker rather than straight into GitHub. The README asks you to discuss an idea or problem in the forums or the Mattermost channels first, and once it is confirmed, to submit the ticket to the JIRA tracker at idempiere.atlassian.net. The community channels are a Google Group for the forum and a Mattermost community channel, with the website, the chat, the contribution guide and the code of conduct all linked from the README.

The contribution guide and the code of conduct live in the repository, alongside a SECURITY.md for responsible disclosure. There is also a donations page.

One detail stands out for anyone evaluating how the project is maintained today. The top level contains AGENTS.md, CLAUDE.md, GEMINI.md and QWEN.md, along with a `.agents/` and a `.claude/` directory and a `.coderabbit.yaml` configuration. Several of the standard coding assistant instruction files, one per tool, sitting in the root of an ERP codebase, is a signal that automated assistants are now part of how contributions are made here, and it is a thing to weigh if you are evaluating the project as an upstream dependency.

No releases, a branch pushed the day before, and a decade of history

The repository is not archived and the last push was on 2026-10-22, so the branch is current. The repository has no GitHub releases, which is a notable gap for a project with this history and suggests that versioning is handled elsewhere, probably through the packaging and the release process around the OSGi bundle repository rather than through GitHub tags.

The default branch is master, and the tree tells you what a working checkout contains. Beyond the feature and bundle directories, there is a `lib` directory for third-party libraries, a `doc` directory, a `coverage-report` directory, an `event.test` directory, and OSGi application descriptors such as `org.adempiere.install.app.xml` and `org.adempiere.server.application.xml`.

The last two of those are the clearest statement of the deployment shape. An OSGi application descriptor is what defines the set of bundles that make up a running installation, and having one for install and one for server means the product is deployed as a described collection of OSGi applications rather than as a single archive.

The age is worth keeping in mind as well. The README describes the business logic as refined by years of real-world use and as decades of logic, and a system with that much embedded process knowledge is both the main reason to choose it and the main reason it is hard to replace.

Editorial conclusion

iDempiere fits an organisation that needs a full business suite, is willing to run a Java stack with a PostgreSQL or Oracle database, and can invest the months that a system of this depth takes to configure rather than merely install. It is the wrong choice for a team that needs something working this afternoon, and the wrong choice if the OSGi plugin model is something your operations team cannot support. Verify first which licence text applies, since the badge and the repository listing disagree, try the hosted test sites before committing, and budget for the configuration work the installation guide implies.

Frequently asked questions

Official sources

1. idempiere/idempiere on GitHub
2. Issues
3. Project website
4. README