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/

Reply via email to