Hi Devs, Based on all the conversations, I think we can at least start by looking at the plan. As Deepak suggested, he will either put notes on the Jira ticket or create a Confluence document to share the plan. And then we can discuss his proposals and reach a conclusion.
Since Deepak plans to make minimal changes to the existing codebase to separate the framework independently from the applications, I think it's a good time to review and discuss the plan together. I vote that we start by discussing the plan. I would love to see Deepak's plan. If others are interested, please vote for it. Thanks -- Divesh Dutta On Mon, Nov 3, 2025 at 3:50 PM Jacopo Cappellato < [email protected]> wrote: > Hi Michael, > > Thanks for your message and for sharing your thoughts. > > Just to clarify, I’m not directly involved in the separation work that > Deepak is proposing, so I don’t know all the details of his current > implementation efforts. My understanding, however, is that he will > work closely with the community, as he has already started to do, and that > his progress and findings will continue to be discussed and refined through > the usual collaborative process. In that sense, the outcome will naturally > be shaped and controlled by the community. > > From what Deepak has shared publicly and from a few direct exchanges I’ve > had with him, my impression is that his first and main goal is to make a > minimal set of changes to the existing codebase to allow building and using > the framework independently from the applications. I believe this limited > and practical objective is something we can rather easily agree on as a > good first step. > > After that, of course, there may be different opinions about further > work—for instance, which parts of the data model belong in the framework, > or whether the framework should include any data model at all. I’d suggest > that we defer those broader discussions to later stages so we can stay > focused on the specific and achievable changes needed to reach the initial > goal. > > Best regards, > Jacopo > > On Sat, Nov 1, 2025 at 1:29 PM Michael Brohl <[email protected]> > wrote: > > > Hi Jacopo, > > > > I might have missed to make my points clearly enough so I try to do so > > inline. > > > > Thanks and regards, > > > > Michael Brohl > > > > ecomify GmbH - www.ecomify.de > > > > Am 30.10.25 um 09:06 schrieb Jacopo Cappellato: > > > Hi all, > > > > > > It's great to see there are valuable ideas and perspectives being > shared. > > > > > > I believe it would be difficult to address all the interesting > questions > > > and concerns each of us may have at this stage. It might be more > > effective > > > to tackle them progressively, as the community gathers more information > > on > > > specific topics and we can take more informed and better-targeted > > decisions. > > > > I strongly belive that core questions should be adressed and answered > > *before* we make such an impactful change to the codebase. We should > > have a clear plan and common understanding on the outcome and the up- > > and downsides. > > > > We should also have a clear plan on how to support the users who built > > their projects on the actual setting. > > > > > Moreover, some (even important) topics may not be directly relevant to > > the > > > framework/application split itself, for example, how to organize entity > > > definitions or how to structure utility classes. These are certainly > > worth > > > discussing, but perhaps in a separate context. > > > > With organizing entity definitions in this context I meant: which > > entities (and functionality) will be part of the framework and which > > will not. > > Where do we want to draw the line between framework and applications > > concretely? > > > > Which code will be part of the framework in the future and which will > not? > > > > > Even very relevant questions, such as “where is the dividing line > between > > > framework and applications?” or “which parts of the applications and > data > > > model will belong to the framework?”, might be more productively > > discussed > > > as we proceed with concrete steps. When we start working on specific > > areas > > > that require modification to achieve a cleaner decoupling, these > > questions > > > will naturally become clearer. And of course, our view on aspects like > > the > > > “dividing line” may evolve as we gain a better understanding of the > > system > > > along the way. > > > > I am not sure if I entirely understand this approach. > > > > I fully recognize that there may be work on the code that does not > > result in any external changes, but internally results in cleaner, more > > structured code. However, the time will come when the actual split is to > > take place, and then there should also be a concrete idea of what impact > > this will have and how we want to deal with it. > > > > > With that said, I think it is important to start this effort now, > keeping > > > as our guiding principles the core software design concepts of high > > > cohesion (within components) and low coupling (between components). I > > > believe we all agree that these principles would be beneficial. OFBiz > was > > > originally designed as a composition of various components (both > > framework > > > and applications), but, unfortunately, over time their internal > cohesion > > > has decreased and their coupling has increased. Starting to move back > in > > > the opposite direction, even gradually, seems like a desirable and > shared > > > goal. > > > > I completely agree with that on this fundamantal level. > > > > > We can defer some of the higher-level decisions, such as whether we’ll > > end > > > up delivering two separate products (e.g., OFBiz Framework and OFBiz > > > Applications), one combined product, or multiple specialized > > distributions, > > > as well as which tools and workflows we’ll adopt to support > contributors > > > and users. These are important questions, but they don’t necessarily > > block > > > us from reorganizing our codebase according to the principles mentioned > > > above. > > > > I'm sure Deepak and you will be working on this responsibly but I also > > have difficulties with the feeling to just start and see where it goes. > > > > Maybe we'll just need some examples to have a better understanding of > > the plans your have in mind. That is why I raised the fundamental > > questions, which certainly have not yet been fully and thoroughly > > thought through. > > > > I definitely want to avoid undertaking extensive renovations without > > having a clear picture of the consequences. > > > > > In summary, I’d suggest we begin with small, concrete steps to improve > > > separation and organization, addressing specific issues as they come > up. > > If > > > at some point we find that too limiting, we could still consider a more > > > revolutionary approach (like a new branch for a “next-gen” framework), > > but > > > for now I don’t think that’s needed. > > > > How do you plan to move this forward in a way that we can follow the > > work and have discussion / synch points when we come to fundamental > > changes? > > > > > Best, > > > Jacopo > > > > > > On Wed, Oct 29, 2025 at 12:33 PM Michael Brohl < > [email protected] > > > > > > wrote: > > > > > >> Hi Deepak, > > >> > > >> How can we establish a sound basis for decision-making for the > > community? > > >> > > >> I believe we need a more detailed plan regarding a possible separation > > >> between applications and framework, which addresses the following > > >> questions, among others: > > >> > > >> * Where is the dividing line between framework and applications? > > >> > > >> * Which part of the applications and the data model will be assigned > to > > >> the framework in the future (e.g., logins are required for the > > framework)? > > >> > > >> * How is the data model organized (in my opinion, it should be moved > > >> back to the individual applications; it was outsourced to a separate > > >> component some time ago) > > >> > > >> * Can we create a technical option that allows users of OFBiz > > >> applications to configure the framework in order to remain updatable? > > >> > > >> * How are Util* classes organized (centrally vs. application-specific > > >> vs. ...)? > > >> > > >> * etc. > > >> > > >> Best regards, > > >> > > >> Michael Brohl > > >> > > >> ecomify GmbH - www.ecomify.de > > >> > > >> > > >> Am 27.10.25 um 08:20 schrieb Deepak Dixit: > > >>> 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 > > >>>>>> > > >
