Hi Michael, I’ve created a placeholder JIRA task [1] for the suggested change so that we can gather all related discussions and information in a single place. I don’t want to proceed further if this change is not considered beneficial for the overall project health.
However, based on my past experience working with various clients and implementations, I strongly believe this direction could be highly beneficial for community growth and increased OFBiz adoption. [1] https://issues.apache.org/jira/browse/OFBIZ-13305 Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Fri, Oct 24, 2025 at 12:23 PM Deepak Dixit <[email protected]> wrote: > Hi Michael, > > Thank you for sharing your detailed feedback, > I completely understand your perspective and agree that OFBiz’s > configurability and the strength of its data model are major advantages. > > > You’re right that components can be disabled selectively; however, > there are still inter-component dependencies that often prevent fully > isolating or unloading specific modules without impacting others. > > This means any customization usually requires patching or maintaining a > separate vendor branch, which complicates upgrades and long-term > maintenance. > > My suggestion to move applications out of the core framework isn’t > intended to weaken OFBiz, > but rather to make it more modular and flexible, > enabling users to adopt it as a true framework for building ERP or > microservice-based solutions without being constrained by the default > applications or the 750+ database tables that come bundled by default. > > While I agree there are other frameworks available, positioning OFBiz this > way could increase adoption and community engagement, > especially among teams looking for a lighter and more customizable > foundation. > > You’re right that application maintenance could become a concern, > but as we’ve seen, there hasn’t been significant new functionality added > to the default applications in recent years. > Users who want the default apps can still use them, while others could > easily include only what they need, with upgrades remaining unaffected. > > We could even consider adding Gradle tasks or scripts to clone or include > applications dynamically, making customization cleaner and easier to > maintain. > > I believe with proper planning, we can find a balance between flexibility > and maintainability that benefits both framework and application users. > > Kind Regards, > -- > Deepak Dixit > *www.hotwax.co <http://www.hotwax.co/>* > > > On Fri, Oct 24, 2025 at 2:18 AM Michael Brohl <[email protected]> > wrote: > >> Hi Deepak, >> >> interesting thoughts although I have difficulties to follow the reasoning: >> >> If you want to build a custom ERP and don't want to use the default >> applications, you can simply configure the system to not load the >> applications. Since the datamodel is already decoupled from the single >> applications, you can still use the datamodel. >> >> If you also don't want to use the datamodel (which I see as one of the >> strength of OFBiz and essential for an ERP system), you can also >> configure it to not being loaded (as a whole or for parts of the >> datamodel). >> >> I am sceptical if the core OFBiz framework would be adopted as a >> framework as there are some strong alternatives out there. In my view, >> it ist the framework plus the datamodel, API/services and the >> backend/webtools making OFBiz so special. >> >> We are using OFBiz for nearly 25 years now, building complex custom >> projects using more or less parts of the datamodel/services and >> sometimes even without any UI to serve as a database plus REST API >> (using a very much enhanced REST-API plugin). We never had any issues >> with "too much functionality" because of the configurable loading >> mechanisms. >> >> And the datamodel is always a strong companion when it comes to the >> design of business cases because of it's generic design end the >> enhancement mechanisms. >> >> So, I do not the any "constraints" preventing anyone from using OFBiz in >> many different ways. >> >> What I see as a potential problem is that the applications will suffer a >> similar fate to the plugins and will no longer be maintained. Some >> plugins have even been gradually deactivated because no one wanted to >> deal with maintaining them and fixing bugs and security vulnerabilities >> anymore. >> >> I honestly would not be happy to see the project going this way. >> >> Best regards, >> >> Michael Brohl >> >> ecomify GmbH - www.ecomify.de >> >> >> Am 23.10.25 um 14:02 schrieb Deepak Dixit: >> > Hi Team, >> > >> > I would like to propose restructuring the OFBiz architecture by moving >> core >> > applications out of the main OFBiz framework — similar to how plugins >> are >> > currently managed. >> > >> > This change would enable developers to build *custom ERP solutions* >> without >> > being tied to all the default applications and their associated 750+ >> > database tables. By decoupling applications from the framework, we can >> > provide a lighter and more modular foundation for building >> domain-specific >> > or microservice-based solutions. >> > >> > I strongly believe this approach will *significantly increase OFBiz >> > adoption* and flexibility, allowing users to leverage the framework >> purely >> > as an enterprise-grade development platform rather than being >> constrained >> > by bundled modules. >> > >> > >> > Thanks & Regards >> > >> > -- >> > >> > Deepak Dixit >> > >> >
