// the find
apache/ofbiz-framework
Apache OFBiz is an open source product for the automation of enterprise processes. It includes framework components and business applications for ERP, CRM, E-Business/E-Commerce, Supply Chain Management and Manufacturing Resource Planning. OFBiz provides a foundation and starting point for reliable, secure and scalable enterprise solutions.
Apache OFBiz is a full-stack Java ERP platform covering accounting, order management, CRM, inventory, manufacturing, and e-commerce. It's been around since the early 2000s and targets mid-market enterprises who want an open-source alternative to SAP or Oracle. The architecture is highly metadata-driven — entities, services, and UI screens are defined in XML, with business logic in Groovy scripts.
The breadth of included business modules is genuinely impressive for an open-source project — GL, AP/AR, inventory, order management, and manufacturing all ship out of the box. The plugin system is reasonably well-designed: plugins are self-contained components with their own entity definitions, services, and UI, so you can extend without forking core. Active Apache governance means security patches get published and CVE tracking is taken seriously (OWASP dependency check is baked into the build). The Gradle build wrapper approach means zero local tooling requirement beyond JDK 17.
The XML-everywhere architecture is a major cognitive tax — defining an entity, its service, its UI screen, and its permissions requires touching four different XML files before writing a line of logic, and the mental model needed to trace a request through the stack is steep. The default H2 embedded database is fine for demos but migration to Postgres/MySQL involves manually editing entityengine.xml, which is brittle and not well-documented for production. The UI is dated JSP-era HTML with no modern frontend story — no REST API, no JSON endpoints, no SPA option; if you need a modern UX you're building a separate frontend and figuring out auth yourself. Groovy scripts as service implementations mix concerns badly: they have access to the full delegator and can do arbitrary DB work, making it hard to reason about transactional boundaries or test in isolation.