Is it really sad? It is just my opinion, but what OFBiz really needs is a more flexible structure... though not how that would work exactly.
One case in point is my decision to start and independent effort to create a redesigned and more modern framework, and refine the data model and services, and build applications on those. Over the last 4 years I've put around 1500 hours into these 4 projects (Moqui Framework, Mantle Business Artifacts, HiveMind Project Manager, and POP commerce). This is MUCH less time per year than I used to put into OFBiz (in fact probably around 1/3 the time I used to per year), but that was necessary anyway as the service industry blew apart and I was making a LOT less per hour for a couple years starting in 2009, and I was trying to achieve a better work-life balance. One small part of that was losing weight... I'm about 110 pounds lighter than I was around the time of making this shift. Anyway, my contributions to OFBiz itself would have dramatically reduced either way. There are other current situations demonstrating a need for a more flexible project and software structure. I'm aware of a half dozen very significant derivative works of OFBiz, some focused more on eCommerce and others more on ERP... most on both in some aspect or another. These are mostly internally maintained open source projects or commercial products (some not really publicly available, only used for clients of certain larger OFBiz service providers). Many of these projects/products represent a shift for the people involved away from contributing to OFBiz and instead putting the bulk of their effort into these derivative works. From what I've seen much of the effort in these projects goes into streamlined user interfaces and the logic/services necessary to support them. These efforts still result in contributions coming back to OFBiz itself, but mostly more minor bug fixes and such as opposed to significant enhancements, new apps, or new functionality. Some bigger things get in here and there, but not a lot. In other words, these efforts are also separations from OFBiz itself. Is that a bad or sad thing? It would be better if many of these OFBiz derivatives were more publicly available, even if under paid licenses and not just free/open source ones. That would at least make it easier for the software and services sides of the OFBiz ecosystem to grow. If more made it into OFBiz itself, or into open source OFBiz derivatives that involved more collaborative efforts, that would be even better for OFBiz and all of those who work on it and/or do paid work based on it. Still, each of these is an expansion of the OFBiz ecosystem and are good for OFBiz itself and everyone who works with or on it, even if in minor ways. For all open source (and much commercial) software that lives for a long time some fragmentation is inevitable. Most open source ERP systems that have been around for very long have been through this (aside from a few of the tightly controlled "commercial open source" ones, but even some of those). Back to my opinion on the situation: some fragmentation is inevitable, so it's better to structure things to keep things shared between all fragments shared and collectively maintained, and let everything else fragment... even facilitate the fragmentation and make it a clear and encouraged part of the ecosystem. How much do I believe this is a better approach? So much that the shared business functionality in the Moqui Ecosystem, which is in the Mantle Business Artifacts project, doesn't have a UI at all because that is where much of the fragmentation tends to happen... and really where much of it is actually _needed_ and _should_ happen. I'm not saying that OFBiz should go in this direction, there is already quite a bit of decent UI in the project (even if it does get mostly replaced or heavily changed in any decent sized customization project). There are other ways of defining and limiting the scope of OFBiz itself, and making it more obvious that it is the center of an ecosystem that involves many other software packages. This sort of encouraged fragmentation minimizes the general "tragedy of the commons" trend, and provides a playground for independent efforts and creative expressions. As another case in point, consider the massive growth of open source foundations like WordPress and Drupal with a huge add on ecosystem, and commercial ones like Force.com. OFBiz in some ways has reached a sort of "maturity crisis", and in other ways has huge room for improvement and added value... and along with it more users and contributors. Technically OFBiz already has some pretty good extension mechanisms, and with a lot effort they could be a lot better. OFBiz also already has a solid core of business functionality that can be the basis for many different application and tool extensions. Many of these already exist in fact, just maintained as separate projects that can't easily be found through the OFBiz web site or wiki. In other words, OFBiz is already in a pretty good place for all of this... in some ways even better positioned than the Moqui Ecosystem which is more intentionally designed to eventually get to this sort of thing! -David On Mar 10, 2014, at 8:45 AM, Pierre Smits <pierre.sm...@gmail.com> wrote: > This is truly a nice thread. With lots of assumptions and veiled > accusations of hardened viewpoints... The other must change for my benefit > (that is what I perceive)... > > But let us bring in some perspective: > > - SAP r/3 <http://en.wikipedia.org/wiki/SAP_ERP> was launched in 2002 > and was/is an evolution of something else. > - JD Edwards <http://en.wikipedia.org/wiki/JD_Edwards> came from the > mainframe (way back when) > - The variants offered by Microsoft came from all over the world and > started also way back when... > > > And are these competitors all at the end of their individual lifecycles? > I dare to say No. > > And do these all have (had) their share of legacy issues? > And if started anew would the owners/architects/business consultants/system > developers/programmers et al. behind these product shed paradigms and > introduce new ones? > And if done so, would these new paradigms not also require a lot of effort > (of a lot of people) to implement, reach maturity and when new architects > get on board lose their momentum? > > I dare to say Yes. > > What I am trying to get accross is this: > It took a lot of persons to get OFBiz to where it is now. This is not only > the feat of David, though his contribution is substantial. > > And David starting over (and shedding wrong paradigms - in his vision and > perception) took him 4 year to get Moqui to where it is now. But it doesn't > deliver today what OFBiz delivers. Yes, it is a clean slate. With new > learning (steep) learning curves and such... > > But yes, when anyone needs to implement something new for a customer the > criteria on which you need to choose the framework to work with is your > skill set, as time-to-market dictates cost. > > David chose to not do the paradigm shifts within this community. And why? > > Anyway, that ship has sailed and that can be regarded as sad. > > Regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com
