Why we build on open-source ERP
Every ERP conversation eventually arrives at the same fork: licence a product, or build on an open-source core. We have taken the second road for years, and it is worth explaining why — including the parts that are harder.
The usual argument for open source is cost, and it is the least interesting one. Licences are a line in a budget; the real cost of an ERP is the decade you spend living inside it. What matters is whether you can still change it in year seven, when the business has changed and the original consultants have moved on.
With a licensed platform, that answer is set by someone else's roadmap. Custom logic lives in whatever extension mechanism the vendor sanctions, upgrades are events you brace for, and your data model is documented as far as the vendor chose to document it. When the fit is good, this is fine. When your business is genuinely unusual — cooperative member pricing, consignment terms, multi-company postings that follow local rules — the gap becomes an annual negotiation.
With an open core such as Apache OFBiz, the data model is in front of you. Two decades of supply-chain and retail modelling are already there: parties, products, facilities, order and invoice lifecycles, accounting transactions. You are not starting from a blank page — you are starting from a domain model that has survived contact with a lot of businesses.
The discipline that makes this work is restraint. Every line you write away from upstream is a line you carry forever. We keep customisation in clearly separated components, we prefer configuration to code and code to forks, and we write down why each divergence exists. Projects that skip this end up with a private fork nobody dares to upgrade — which is exactly the trap they were trying to avoid.
The honest trade-off is that open source moves responsibility to you. There is no vendor to escalate to at midnight; the operator has to be competent, and someone has to own the upgrade path. That is precisely why we do not hand over a system and leave. Building it and running it are the same job, and separating them is how systems rot.
What customers end up owning is the thing that matters: the source, the schema, the deployment pipeline and the runbooks. If they ever want to take it in house, or hand it to someone else, the answer is a handover — not a rebuild.
