Same feeling on Sharan' role. BTW, perhaps we can add EDI support to OFBiz: Retailer A's ERP (OFBiz) with EDI adaptor <-> EDI Center (Moqui) <-> Brand A's ERP (OFBiz) Retailer B's ERP (OFBiz) with EDI adaptor <-> <-> Brand B's ERP (OFBiz)
-----邮件原件----- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2015年10月16日 18:34 收件人: dev@ofbiz.apache.org 主题: Re: Why A Framework Rewrite Is Necessary By and large, that also sounds wise to me. Like we said in French : "Il ne faut pas mettre la charrue avant les boeufs" (the cart before the horse) But this also does not mean that nothing should be done. Simply we are not in a hurry and should take the time to collect, not the opinions (we have enough), but the ways to go. And we should not depend on projects to grow (easy to say...) I personally think Sharan is doing an excellent work a that, a kinda PM for the OFBiz project. We don't need a benevolent dictator (no misunderstandingDavid, I don't say that to you, I know you rejected the term and you always proved your openness and understanding, for those - if any - who would doubt, OFBiz is here to prove it) but we need a *more coherent team*. That's exactly how I feel Sharan's work, and it's not an easy one... Jacques Le 16/10/2015 09:41, Pierre Smits a écrit : > On Fri, Oct 16, 2015 at 5:31 AM, David E. Jones <d...@me.com> wrote: > >> >>> On 15 Oct 2015, at 07:58, Adrian Crum < >> adrian.c...@sandglass-software.com> 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/ >
