Hi all, I generally agree with the proposal to revisit and revamp the positioning and long-term vision for Apache OFBiz, as outlined by Divesh. I think having a clearer, future-facing narrative is valuable not only for external audiences evaluating OFBiz today, but also for the community itself as we think about where to focus our efforts.
I also agree with Taher’s assessment of the current state of the codebase. As long as OFBiz continues to live as a single, very large repository, it will naturally resist deeper architectural change. The size and tight coupling make it difficult to reason about the system as a whole, and even harder to evolve it in meaningful, incremental ways. Breaking the system into smaller, more clearly bounded pieces feels like a necessary foundational step if we genuinely want to move toward modularity, cleaner APIs, and modern deployment models. >From a practical standpoint, I think many of us are already adapting OFBiz in our own client projects to meet modern requirements. Whether that’s API-first integrations, cloud deployments, or experimenting with AI/LLM-driven use cases. These adaptations are happening out of necessity, driven by real-world demands. Sooner or later, everyone ends up solving similar problems in parallel to keep OFBiz relevant for their customers. In that context, the idea Taher mentioned of gradually breaking OFBiz down into smaller chunks at the community level sounds like a good way to get the ball rolling. This doesn’t have to be a disruptive “big rewrite,” but rather a series of pragmatic, incremental steps that make the system easier to evolve over time. Alongside this technical evolution, I also like the idea of communicating more openly about what’s happening and what to expect. Publishing blogs or updates about ongoing modernization efforts, architectural changes, and future direction could help set expectations, attract new contributors, and give enterprises a clearer picture of where OFBiz is heading. Overall, I see this as an opportunity to align vision, architecture, and communication that is grounded in the realities of the existing codebase, but still ambitious about the future. Looking forward to hearing more thoughts from the community. Thanks! Best regards, Pranay Pandey On Fri, 9 Jan 2026 at 21:23, Taher Alkhateeb via dev <[email protected]> wrote: > 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 > >> > > >
