Open-source ERP is ERP software published under an open licence, so you can run and modify it without per-user licence fees; ERPNext and Odoo Community Edition are the best-known examples. Custom ERP is built for your business from the start. Open source gives you a large product quickly; custom gives you a closer fit to your processes.
"Free" in open-source ERP refers to the licence, not the project. You still pay for implementation, hosting, customisation and support, just as you would for a custom build. The question is which starting point leads to the better system for you.
How are ERPNext and Odoo Community licensed?
ERPNext is published under the GNU General Public License version 3 (GPLv3). Odoo Community Edition is published under the GNU Lesser General Public License version 3 (LGPLv3), while Odoo Enterprise Edition uses a separate proprietary licence that requires a paid subscription. Check the current terms before you commit.
| ERPNext | Odoo Community | Odoo Enterprise | Custom ERP | |
|---|---|---|---|---|
| Licence | GPLv3 (stated in the ERPNext repository on GitHub) | LGPLv3 (Odoo's licensing documentation) | Odoo Enterprise Edition License, used with a valid subscription | Your contract with the developer |
| Licence fee | None | None | Subscription | None |
| Source code access | Full | Full | Provided to subscribers under its licence | Full, if ownership transfers to you |
| Who builds new features | The community and the vendor, plus your partner | The community and the vendor, plus your partner | The vendor, plus your partner | Your development team |
Odoo's own licensing documentation states that Enterprise Edition can only be used, including modified, with a valid Odoo Enterprise subscription for the correct number of users. That matters if a partner proposes Enterprise modules alongside a Community deployment.
Open-source licences also carry conditions. Copyleft licences such as the GPL generally attach obligations when you distribute the software or derivative works, and the LGPL has its own rules for combined works. If you plan to resell, distribute or embed modified code, take legal advice on the specific licence. For internal business use, the practical issues are usually support and upgrades rather than licence compliance.
If your processes do not fit a packaged product, our custom ERP software page explains the alternative. If you have chosen a package and need it deployed, see ERP implementation services.
Who hosts and supports open-source ERP?
You do, or a partner you pay. With open source there is no licence vendor who must keep your system running, so hosting, backups, security patches, upgrades and user support all need a named owner.
The common options are:
- Self-hosted on your own servers or cloud account, run by your IT team.
- Partner-hosted by an implementation partner, often with a support contract.
- Vendor-hosted cloud, where the product's maker offers managed hosting for its own software.
Whichever you choose, write down who applies security updates, who tests version upgrades against your customisations, and who answers users when something breaks. The same questions apply to custom ERP; the difference is that with custom software the team that built it usually understands it best.
How far can you customise open-source ERP?
Technically, without limit, because you have the source. Practically, every change you make to the core product becomes a cost at the next upgrade. The safe pattern is to configure first, extend through the framework's module system second, and change core code only as a last resort.
| Change type | Open-source ERP | Custom ERP |
|---|---|---|
| Configuration (fields, workflows, print formats) | Fast, low risk | Built in as part of the design |
| Extension modules | Common; must be retested at each major version | Normal development |
| Core changes | Possible but costly at upgrade time | Normal development |
| Unusual data model | Hard: you work around the existing model | Designed for your process from the start |
| Interface for a specific role | Possible, within the product's interface patterns | Designed for that role |
The ERP customisation vs configuration guide explains where the line sits. If you already run Odoo and the customisations are piling up, the Odoo customisation: when to rebuild guide helps you decide whether to continue or start fresh.
What does upgrading open-source ERP involve?
Open-source ERP products release new major versions regularly, and each one can change the data model, the interface and the extension framework. Staying on an old version eventually means running software that no longer receives community fixes, so upgrades need a plan and a budget.
A sound upgrade routine looks like this:
- Keep every customisation in separate modules, never in edited core files.
- Keep a list of modules, who wrote them and which version they were tested on.
- Copy production into a test environment and run the upgrade there first.
- Retest the processes your business depends on, with key users, before switching.
- Schedule the production upgrade at a quiet period, with a rollback plan.
Custom ERP has the equivalent work: updating the framework, libraries and runtime the system is built on. The difference is that you control the timing and the scope, and there is no product roadmap forcing changes to features you do not use.
What should you ask an open-source ERP partner?
- Which edition and version will we run, and is every proposed module available under that licence?
- Which requirements are covered by configuration, and which need custom modules?
- Who will host the system, apply security updates and take backups?
- How will our custom modules be tested at each major version upgrade?
- Who owns the custom modules you write for us?
- Could another partner take over support if needed, and what documentation will you provide?
When does open-source ERP fit better than custom?
Open-source ERP fits when your processes are close to standard practice, the product already covers most of what you need, and you have a capable partner or in-house team to host and support it.
Choose open source when:
- Most requirements are covered by standard modules with configuration
- You want to avoid per-user licence fees
- You have, or can hire, people who know the framework
- You accept following the product's data model and interface patterns
- You have a plan for testing and applying major version upgrades
When does custom ERP fit better than open source?
Custom ERP fits when the processes that make your business different do not match any product's model, when you would otherwise customise the core heavily, or when you want an interface and data model designed around your roles.
Choose custom when:
- Your core process (pricing, production, compliance workflow, service delivery) has no close equivalent in standard modules
- The customisation list for a package is already long before you start
- You need a specific interface for field staff, customers or regulators
- You want a smaller system that does exactly what you need and no more
- You want the code base and roadmap under your control
With custom development, confirm ownership in the contract. At Timeline Digital, project source code transfers on full payment and client data is the client's throughout; see IP ownership. Make sure documentation is part of the deliverables, so another team could support the system later.
Illustrative scenario: two companies, two answers
The scenarios are illustrative. A trading company with standard sales, purchasing and stock processes and a small IT team chooses an open-source ERP with a partner-hosted support contract. Its customisation list is short, and it accepts the product's way of working.
A testing laboratory needs sample tracking, chain of custody, instrument results and accreditation-driven approvals. Mapping that onto a general ERP would mean building most of it as custom modules on top of a framework the team does not know. It builds a custom system for the laboratory workflow and integrates finance with its existing accounting package.
What are the trade-offs to watch?
- Upgrade drag. Heavily customised open-source deployments can stay on old versions because upgrading is too expensive.
- Partner dependence. Open source avoids licence lock-in, but you can still depend on one partner who knows your customisations.
- Feature surplus. Large products include many features you will not use, which can complicate training and permissions.
- Build responsibility. With custom ERP, you fund every new feature and need a team to maintain it.
- Edition confusion. Make sure every module in a proposal is from the edition and licence you intend to use.
- Community modules. Third-party modules vary in quality and maintenance. Check who maintains each one, whether it supports your version, and what happens if its author stops updating it.
- Skills market. The availability of developers who know a specific framework varies by country. Check that you could hire or contract that skill locally, or remotely, if your partner changed.
How to start
Write your must-have requirements, then mark which ones a standard product would cover with configuration and which need custom work. If the custom list is long, compare a custom build directly. An ERP RFP template helps you ask both open-source partners and custom developers the same questions, and the Odoo vs custom ERP guide goes deeper on that specific comparison.
Then discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, which gives you a working comparison point against the open-source option before you commit.