On Fri, Oct 16, 2015 at 5:31 AM, David E. Jones <[email protected]> wrote: > > > > On 15 Oct 2015, at 07:58, Adrian Crum < > [email protected]> wrote: > > > > Keep in mind that much of David's code in OFBiz has been rewritten. So > yes, we CAN do a better job than him. > > I think there’s a name for this logical fallacy… > > And this could also be called a logical fallacy. But let us not make it into a pissing contest again, like we had in the past regarding the opposing viewpoints on this.
> > Also keep in mind that Moqui duplicates some of the problems I listed - > so by using Moqui, we keep the same problems instead of fixing them. > > Could you be more specific, other than the type conversion stuff you > mentioned many years ago (which I fully disagree with)? > > This is not about who is right or wrong, but where the community wants to go. I understand the reluctance of the community, because the impact will be huge. When looking at the data in OpenHub I see OFBiz having an estimate effort spend of 519 person years vs 6 for the combined Moqui-Mantle-HiveMindPM-PopCommerce suite. And one of the reasons behind it is simple: Many more have worked on OFBiz (from day 1) than on the Moqui suite. One could even argue that both directions took the same number of years in duration to get where they are now. Without all the experiences regarding the OFBiz product there couldn't have been an evolution called the Moqui suite. Coming back to opting for a new direction, as Scott has stated we can have this in a separate code repository (subproject, like many other Apache projects do their work) even combined with a new JIRA an Wiki under the umbrella of the OFBiz project. Based on the comments provided, this seems like a logical choice to ensure that adopters of the current solution will keep the support of the community while at the same time ensuring containment of the new approach. But these are mere technical, supportive aspects. The more important issue is what this new solution will encompass. There are talks of a rewrite, which sounds like reinvention of the wheel. But I guess it is not like that. Yet, taking decisions based on a few one-pagers (e.g. http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf) are seldom done. Maybe it works for a single person, but I doubt it will make a community fly. Whether fix or rewrite, choices will be made regarding the supporting 3rd party libraries/solutions and the community needs to understand the impact to get behind it. So before we embark on the coding trip, let us get into trying to define a bit more what the new solution will encompass and get consensus on that. Another issue regarding getting the community behind behind this new effort is this: 'restrict access to the new code'. I guess this meant restrict write access. Though understandable from a avoidance of dilution/scope creep point of view, I see this as a wrong direction. This 'proposed' exclusion of contributors of the kind will bring us back to where this project came from: discrimination and favouritism. I even doubt that this is possible under the current principles of the ASF. Given that this is an enormous undertaking, we need to get as many on board as possible. Not only to ensure that the decisions (at each level) will get consensus, but also the ensure that every aspect down the line will get addressed (e.g. documentation, test definitions, marketing/promotions, etc) in order to get this kite flying. Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/
