Why “open-source ERP” no longer means one single thing

If you read most articles about open-source ERP, it may seem that the world is still divided into “off-the-shelf systems” and “custom development”. In practice, by 2024–2025 almost nobody thinks this way anymore.

Companies are no longer looking for an ERP as a product. They are looking for a way to assemble and maintain their business systems in an environment of constant change: processes, teams, integrations — and now AI.

That’s why this list deliberately mixes ERPs, platforms, and low-code tools — this is exactly how they coexist in real companies today.

Short on time?

Most teams don’t evaluate all options equally. They narrow the list down by context:

Pick what sounds closest:

What to focus on:

Choose an option above — I’ll highlight the most relevant systems.

If you recognize yourself in one of these, only a small subset of systems in this article usually applies.

Jump to:

Classic ERPs: still alive, but no longer universal

Odoo (Community Edition)

Odoo remains the most recognizable open-source ERP platform. It still works very well as an “entry point”: accounting, sales, inventory, basic workflows — everything is available out of the box.

The problems usually start not at launch, but one or two years later. When the business outgrows standard scenarios, Odoo becomes a product you effectively maintain yourself: custom modules, complex upgrades, and dependency on the ecosystem.

Good fit if: you need a fast start and relatively standard processes.
Poor fit if: business logic changes frequently and ERP must evolve rather than freeze.
Links: Site · GitHub

ERPNext

ERPNext is often chosen by teams looking for a coherent, well-structured ERP without enterprise-level excess. It enforces discipline: if your processes fit the model, the system behaves predictably and reliably.

The price of that predictability is flexibility. ERPNext does not like being constantly bent to new operating models.

Good fit if: the business is ready to standardize.
Poor fit if: processes are unstable and change frequently.
Links: Site · GitHub

Dolibarr

Dolibarr represents the lightweight end of open-source ERP. It is often chosen by small businesses that need basic CRM, invoicing, and inventory without operational complexity.

Its main strength is simplicity rather than architectural flexibility. Dolibarr works best when processes are clear and unlikely to change often.

Good fit if: simplicity matters more than extensibility.
Poor fit if: ERP is expected to evolve into a platform.
Links: Site · GitHub

metasfresh

metasfresh focuses on operational workflows such as logistics, procurement, and production planning. It is less generic than many ERPs, but strong in its core domains.

Teams usually adopt metasfresh when operational control matters more than broad functional coverage.

Good fit if: supply chain and operations are central.
Poor fit if: you need a generic business platform.
Links: Site · GitHub

Platform-first ERP: when ERP is the result, not the product

MyCompany (lsFusion)

More and more teams are realizing that ERP as a “boxed product” does not survive real life very well: changing processes, new channels, automation, and AI.

MyCompany is an example of a platform-first approach. Formally it is an ERP, but in essence it is a way to describe business logic so that it can evolve without rewriting the system.

This becomes especially important in an AI-driven context. Declarative, transparent logic is easier to analyze, explain, and automate — both for humans and AI tools.

Good fit if: ERP must grow and transform together with the business.
Poor fit if: you want a “set it and forget it” ERP.
Links: Site · GitHub

Tryton

Tryton is less popular, but architecturally very clean. It is often chosen by teams that want full control over the data model and are not afraid to write code.

It is not a fast start, but a solid foundation for long-lived systems.

Good fit if: you have an engineering team and a long-term horizon.
Poor fit if: you need ERP “yesterday”.
Links: Site · GitHub

Apache OFBiz

OFBiz is rarely used as a ready-made ERP. More often it serves as a foundation for building custom business systems.

It offers freedom, but requires a mature team and architectural discipline.

Good fit if: ERP is part of your own internal platform.
Poor fit if: you lack development resources.
Links: Site · GitHub

Openbravo

Openbravo is often used as an ERP core rather than a full suite. It commonly serves as a backend foundation for retail and distributed enterprise systems.

In practice, Openbravo is embedded into larger stacks instead of being used as a standalone product.

Good fit if: ERP is part of a broader enterprise architecture.
Poor fit if: you expect a ready-made system out of the box.
Links: Site

Low-code and internal tools: how ERP is built in practice

ToolJet

ToolJet is a good example of how companies actually build “ERP-like” systems today. Not a single monolith, but a set of internal interfaces connected to data and services.

It is not ERP in the classical sense, but this is often what a modern business operating system looks like.

Good fit if: ERP is a collection of internal tools.
Poor fit if: you need a single monolithic accounting core.
Links: Site · GitHub

NocoBase

NocoBase appears in similar scenarios to ToolJet, but with a stronger focus on extensibility and plugins.

It is chosen when ERP is an ecosystem of internal applications, not a single system.

Good fit if: you need a low-code layer on top of data.
Poor fit if: you are looking for a ready-made ERP suite.
Links: Site · GitHub

Budibase

Budibase occupies a similar niche — rapid creation of internal admin panels and operational interfaces.

Good fit if: you need to build interfaces for teams quickly.
Poor fit if: complex business logic must live in the core.
Links: Site · GitHub

Retool

Retool is not an ERP, but it reflects how many companies actually build internal business systems today: custom interfaces on top of databases and APIs.

It is often used alongside ERPs and platforms as an operational layer rather than a replacement.

Good fit if: ERP is a collection of internal tools.
Poor fit if: accounting must live inside the same system.
Links: Site

How choices were made in 2025

  1. If you need fast results: a ready-made ERP.
  2. If ERP is a living organism: a platform-first approach.
  3. If ERP is a toolbox: low-code and internal tools.

In reality, many companies use a combination of all three. And this is the main trend of recent years.

Conclusion: how to choose in 2026 (without illusions)

The key mistake when choosing ERP in 2025 was believing that there is one “correct” system that will solve everything once and for all.

Reality is different: modern companies build a business systems architecture, where ERP is not a product, but a layer of logic and data.

  1. If you need fast results right now
    Choose a ready-made ERP and consciously limit customization. This is a decision about speed, not perfect process alignment.
  2. If the business changes constantly
    Look for a platform-first approach. It is critical that business logic is declarative, readable, and explainable — not only for developers, but also for AI tools, which increasingly participate in analysis, automation, and system support.
  3. If ERP in practice is a set of internal tools
    Low-code and internal tools are no longer “temporary solutions”, but a full-fledged operational layer. They allow new needs to be addressed quickly without rewriting the system core.

Important:

Avoid mixing all three approaches.
Choose one as the core, and use the others only as supporting layers.

Pay attention to the readability and formalization of business logic.
What cannot be clearly described cannot be reliably automated — neither manually nor with AI.

What an owner should understand before choosing

  • How often do key business processes change?
  • Should the system explain its decisions to humans and AI?
  • Is the business ready to live inside someone else’s model — or develop its own?
  • Is ERP just an accounting tool, or the foundation of operational management?

The answers to these questions matter more than any feature list. They determine whether the system will support business growth — or slow it down.