Wow the formatting was horrid :) reposting Hello Friends,
It’s been a while since I posted here; I’ll try to keep this terse and useful. The following writing was proposed below: “Now, through community-driven modernization, Apache OFBiz is becoming a modular, microservice-ready, AI-enabled enterprise automation framework.” I understand this as an aspirational goal, and I agree with the intent. That said, I think it’s important we’re honest, especially with ourselves, about what it would actually take to make this statement true. A quick look at the codebase shows that OFBiz still behaves as a very large monolith: - The applications folder alone currently contains ~647k lines of code - Plugins account for ~213k lines - Total framework size is ~1.15M lines of code Beyond size, OFBiz includes tightly coupled internal subsystems (transaction management, caching, core utilities, etc.) that are not clearly isolated behind stable, well-defined APIs. Much of this functionality is scattered across shared helpers and static utility classes, making architectural change very difficult. This is simply the reality of a mature, 20+ year old codebase. In the past, discussions about large rewrites understandably raised concerns. But I don’t believe modernization needs to be an all-or-nothing event. One small but meaningful step could be this: Break it into pieces. By gradually extracting clearly bounded subsystems into separate git repositories, and defining explicit interfaces between them, we can begin to create the conditions necessary for real architectural evolution. As long as OFBiz lives as one massive repository, it will naturally resist deeper rewrites. This doesn’t need to be disruptive or irreversible: and there a few big quick wins. Simply remove applications. Another action is to split out the basic sub-systems into different directories. From there it might be possible to actually start reasoning about this project and think with more clarity on the next step. But I doubt any human can think of the whole thing in its current shape. This can act as a foundation that enables everything else we talk about: modularity, microservices, replaceable infrastructure, and realistic integration with modern platforms. Food for thought! Love to read yours. Cheers, Taher Alkhateeb On January 9, 2026 7:27:52 PM GMT+04:00, Taher Alkhateeb via dev <[email protected]> wrote: > >Hello Friends, >It’s been a while since I posted here; I’ll try to keep this terse and useful. >The following writing was proposed below: “Now, through community-driven >modernization, Apache OFBiz is becoming a modular, microservice-ready, >AI-enabled enterprise automation framework.” >I understand this as an aspirational goal, and I agree with the intent. That >said, I think it’s important we’re honest, especially with ourselves, about >what it would actually take to make this statement true. >A quick look at the codebase shows that OFBiz still behaves as a very large >monolith: >- The applications folder alone currently contains ~647k lines of code >- Plugins account for ~213k lines >- Total framework size is ~1.15M lines of code >Beyond size, OFBiz includes tightly coupled internal subsystems (transaction >management, caching, core utilities, etc.) that are not clearly isolated >behind stable, well-defined APIs. Much of this functionality is scattered >across shared helpers and static utility classes, making architectural change >very difficult. > >This is simply the reality of a mature, 20+ year old codebase. In the past, >discussions about large rewrites understandably raised concerns. But I don’t >believe modernization needs to be an all-or-nothing event. >One small but meaningful step could be this: Break it into pieces. >By gradually extracting clearly bounded subsystems into separate git >repositories, and defining explicit interfaces between them, we can begin to >create the conditions necessary for real architectural evolution. As long as >OFBiz lives as one massive repository, it will naturally resist deeper >rewrites. >This doesn’t need to be disruptive or irreversible: and there a few big quick >wins. Simply remove applications. Another action is to split out the basic >sub-systems into different directories. From there it might be possible to >actually start reasoning about this project and think with more clarity on the >next step. But I doubt any human can think of the whole thing in its current >shape. >This can act as a foundation that enables everything else we talk about: >modularity, microservices, replaceable infrastructure, and realistic >integration with modern platforms. >Food for thought! Love to read yours. >Cheers, >Taher Alkhateeb > >On Friday, January 09, 2026 16:15 +04, Michael Brohl ><[email protected]> wrote: > > >Hi Divesh, > >I wanted to respond way earlier, but life prevented me from doing so. > >Thank your for the initiative, very much appreciated. I cannot dive in >to deeply now but I generally agree with the proposed statement. We are >having the same discussions at ecomify and also see the need to better >explain what OFBiz is, what it can be used for and how well it fits in >modern system infrastructures. > >We will dive deeper into your proposal and respond in more detail. > >Thanks and regards, > >Michael Brohl > >ecomify GmbH - www.ecomify.de > > >Am 12.12.25 um 13:24 schrieb Divesh Dutta: >> Hi all, >> >> I’ve been thinking about how we talk about Apache OFBiz, not only in the >> context of our code , but also in terms of the project’s long-term roadmap, >> vision and its role in the modern enterprise software landscape. >> >> Apache OFBiz has more than 20-year legacy and has powered a wide range of >> business applications across industries. At the same time, the broader >> technology ecosystem has evolved significantly, with trends like API-first >> architectures, microservices, cloud-native deployments, modular systems, >> and (more recently) AI/LLM-driven automation becoming mainstream. >> >> As contributors, I believe we have a unique opportunity to articulate how >> OFBiz fits into this modern landscape, and how community-driven >> modernization work can help shape the next chapter of the project. >> >> With that intention, I wanted to share a *proposed positioning statement >> and strategic summary* for Apache OFBiz. >> >> >> This is to start a community conversation about a shared narrative that can >> guide documentation, onboarding, future modernization efforts, and >> communication with enterprises and developers looking at Apache OFBiz today. >> ------------------------------ >> *Proposed Positioning Statement for Apache OFBiz* >> >> *“Apache OFBiz is evolving into a modular, microservice-ready, API-first, >> cloud-native enterprise automation framework ready for AI-driven >> workflows.”* >> ------------------------------ >> *Proposed Strategic Positioning Summary* >> >> Apache OFBiz is evolving. >> >> For more than two decades, Apache OFBiz has been a reliable backbone for >> enterprise workflows. >> >> >> Now, through community-driven modernization, Apache OFBiz is becoming a >> modular, microservice-ready, AI-enabled enterprise automation framework. >> >> With REST APIs, cloud-native deployment, modern security (OAuth2, SAML, >> JWT), and MCP integration for AI/LLM workflows, Apache OFBiz is being >> re-engineered for the future of enterprise software development. >> >> Either organizations can build fully custom solutions on the Apache OFBiz >> framework — or accelerate implementation by leveraging enterprise-grade >> modules such as Order Management, Manufacturing, Warehouse Management, >> Catalog Management, and Accounting. >> >> The modernization work is active and ongoing, with contributions from the >> Apache OFBiz community. >> ------------------------------ >> *Why I am proposing this* >> >> My goal is to: >> >> - >> >> Help articulate a clear, future-facing vision for Apache OFBiz >> - >> >> Reflect modernization themes many contributors have been discussing >> (modularity, APIs, cloud, security, AI) >> - >> >> Provide enterprises and developers a fresh lens through which they can >> understand the potential of Apache OFBiz today >> - >> >> Encourage us, as a community, to think about how Apache OFBiz aligns >> with modern architectural principles >> - >> >> Create shared language that can strengthen our roadmap, documentation, >> onboarding, community outreach, and adoption >> >> I want to emphasize that this is *not a directive* — simply a proposal to >> start an open discussion on how we collectively describe the project and >> its future trajectory. >> ------------------------------ >> I would love to hear thoughts, suggestions, or concerns from the community. >> >> - >> >> Does this narrative resonate with how you see the project evolving? >> - >> >> What would you adjust, add, or remove? >> - >> >> Should we publish an official positioning statement as part of our >> documentation? >> - >> >> Are there additional modernization themes we should highlight? >> >> I’m sharing this in the spirit of collaboration and to help us build a >> shared vision that reflects the strengths, ambitions, and ongoing work of >> the Apache OFBiz community. >> >> Looking forward to the discussion. >> >> Thanks >> >> -- >> >> Divesh Dutta >> >
