Reposting from David Jones on Moqui

[byersa]

In light of the current discussion about the future of OFBiz I thought it
would be worth revisiting one of my finer moments by reposting this from
David Jones. In today's world 12 technology years is a lifetime. It is not
reasonable to think that we can keep scaling the original framework.
Another thing to think about is that in order to attract a new group of
users sometimes it takes a big new idea and Moqui fills that role. We
should all keep in mind that OFBiz succeeded secondly because of all the
hard work put in by the community, but firstly because of the brilliant
architecture and foundation provided by David (and Andrew). When that same
mind applies it to fixing most of OFBiz's problems we should be talking
about how to transition - end of discussion, IMHO.

I believe that it has been since David wrote this email that he has
integrated Elasticsearch and Drools into Moqui. Those are the kinds of
exciting technologies that OFBiz needs. And it is high time that we stopped
programming in Java. I have loved the seemless transition to Groovy and I
like having only one scripting language. The future is going to demand much
more flexibility than OFBiz can deliver. Moqui, with its small core size
and its application of FreeMarker to the frontend provides that flexibility.

I don't know exactly how the transition to Moqui should take place, but
that is where the discussion should take place. Anything else, and we are
just discussing how slowly the ship will be sinking. I think David should
remain in control of the core (as I think he would insist), but there are a
lot of options for porting the mantle and crust portions. I think we should
think outside the box and look to something like KickStarter to get it done
quickly.

-Al

On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:

>
> OFBiz has recently turned 12 years old. At the time it was written many
> more modern libraries either didn't exist or were not usable, including:
>
> - Groovy
> - ehcache
> - Quartz Scheduler
> - Atomikos
> - JackRabbit (and JCR in general)
> - Shiro
> - Camel
> - JSON-RPC, REST, JSON in general
> - ElasticSearch (and to some extent even Lucene)
> - Document and other NoSQL databases (of which ElasticSearch is sort of,
> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
>
> Some of these are used, or with some customization usable, in OFBiz. Many
> of them overlap a lot with parts of the OFBiz framework, and unlike
> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
>
> Some big ones are caching, job scheduling, content management, and even
> searching. The OFBiz ProductSearch stuff works well enough (though not
> great) for smaller sets of products, but doesn't compare in flexibility,
> scalability, and speed to ElasticSearch and some other Lucene-based
> alternatives. With some simple framework extensions (like the DataDocument,
> DataFeed, and DataSearch features of Moqui) implementing excellent search
> for products would be easy, as would search for any other part of the
> system... and all combined in a single system-wide search or segmented as
> desired.
>
> Another big one, that has been most painful for me in dealing with OFBiz,
> is the lack of consistent scripting and expressions. Once you get used to
> the elegance of Groovy dealing with BSH and JUEL is downright painful...
> and for me anyway requires a number of misses before I finally get it
> working. The ${groovy:...} work-around is there, but quirky, and the
> resulting object is unreliable as in some OFBiz XML files it results in a
> String while in others it results in the actual Object the expression
> evaluates to.
>
> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
> but it needs FAR more modernization than is currently happening or that is
> likely to happen. The new feature velocity in the framework is so slow
> (mostly because of the architecture and existing code, partly because of
> collaboration breakdown reasons), that it can't keep up with alternatives.
>
> So yes, OFBiz is great, but it exists in a world that is progressing far
> faster than it can. My reason for starting fresh was just that simple:
> development velocity.
>
> On top of that OFBiz uses certain approaches that are difficult to deploy
> and maintain. Try dropping all of OFBiz into a single war file for easy
> upload deployment on the dozens of modern cloud/PaaS services. Try adding
> plug-ins that require a proper init/destroy lifecycle instead of relying on
> static initialization and no proper tear down. Try finding framework
> functionality in thousands of static methods spread across dozens (or
> hundreds?) of classes. I know these weaknesses of OFBiz well... they are my
> mistakes. Correcting them is another matter... and one I didn't find
> possible in the context of the project with the limited time I have
> available. It was faster and easier to start fresh.
>
> When I started OFBiz I was 23 years old and had about 2 years of
> experience in ERP systems. I think it's great that there is enough interest
> to keep the project alive and at whatever pace keep it progressing both
> technically and for support of business activities. Still, something must
> be done for it to remain competitive with open source and commercial
> alternatives if it is to compete... including with what I've been calling
> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
> Artifacts, and the various projects and products built on them.
>
> As good as it is, there is lots of room for improvement and others are
> doing just that. I don't think Al was implying that "OFBiz is no longer
> brilliant", maybe some are overly sensitive to that. The fact is that OFBiz
> is what it is, and without major improvements alternatives exceed it in so
> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
> bright stars its brilliance is only relevant in context.
>
> OFBiz has lots of momentum, and pretty good marketplace around it, and a
> lot of people are making good money doing work based on it (including me).
> Still, I tire frequently of explaining that so many things are known issues
> with the project and not easy to correct, but are corrected in the "Next
> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround that
> can't be committed because it breaks other things, just things they don't
> intend to use (this still has consequences for bigger projects... things
> all seem to come back around).
>
> So, it is what it is. I understand the motivation to paint OFBiz the best
> possible for marketing purposes and such... I personally did that for years
> in spite of known flaws. Eventually that only goes so far... OFBiz versus
> other open source alternatives has its pluses and minuses, and most in the
> community are very aware of those minuses. This causes many to drool over
> cleaner, newer solutions like Magento, even if it is based on a totally
> different underlying technology and one that doesn't scale as well or
> interact in enterprise environments as well.
>
> Sooner or later reality catches up... best to stay ahead of it or at least
> have long-term plans and alternatives to fall-back on.
>
> -David
>
>
> On May 20, 2013, at 11:10 AM, Adrian Crum <
> [hidden email]> wrote:
>
> > A quick clarification on this.
> >
> > "OFBiz was brilliant when David created it over ten years ago, but..."
> implies OFBiz is no longer brilliant. OFBiz continues to be just as
> brilliant, with a talented team of developers keeping it current with
> current technology.
> >
> > -Adrian
> >
> > On 5/20/2013 4:04 PM, Al Byers wrote:
> >> Hi Carlos,
> >>
> >> I am just starting to look around for OFBiz work and was intrigued to
> see your email there this morning. I have been working with OFBiz for over
> 10 years now and am interested in what you have going.
> >>
> >> But I must ask if you have considered Moqui (moqui.org <
> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
> small conference with David and the folks at HowWax Media and based on
> David's comments and what I know about Moqui from my past year of working
> with it, if you are starting anew, and especially if you are not using the
> current e-commerce features of OFBiz, then you would be well served to look
> at Moqui. OFBiz was brilliant when David created it over ten years ago, but
> technology has made great advances in that time and if you have the freedom
> to do so, it makes sense to start with the latest base.
> >>
> >> I have attached David's introduction to Moqui PDF, which I don't think
> is readily available off the moqui.org <http://moqui.org> website.
> >>
> >> I hope to hear from you soon.
> >>
> >> Al Byers
> >> 801-400-5111
> >>
> >>
> >> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz <[hidden email]<mailto:
> [hidden email]>> wrote:
> >>
> >>    Hi;
> >>
> >>    I'm looking for a Java programmer that is familiar with OFBiz.
> >>    Particularly with OFBiz Web Services and OFBiz Entity Engine.
> >>
> >>    I'm interested in hosting OFBiz for some very specific industries
> >>    and I want to develop some very specific interfaces.
> >>
> >>    This is a long term project, I could be flexible with the hours.
> >>
> >>    If you're interested email me for more details.
> >>
> >>    Also feel free to forward this email to someone you think might be
> >>    interested.
> >>
> >>    Thanks!!
> >>
> >>    Carlos
> >>
> >>    logo-for-social-media-sites-email_signature
> >>
> >>    CruzControl Radius
> >>
> >>    Your Success Is Our Service
> >>
> >>    www.ccradius.com <http://www.ccradius.com>
> >>
> >>    email:[hidden email] <mailto:email%[hidden email]>
> >>
> >>    1-877-285-5499 <tel:[phone]>
> >>
> >>
> >
>
>

[Adrian Crum-3]

Switching OFBiz to a different framework has been discussed in the past,
and I brought up the subject again in a recent thread on the dev mailing
list. At this time, there are some PMC members who are opposed to the
idea, so I don't see any hope for switching to Moqui in this project.

If anyone is interested in building applications on Moqui, then they
should do it in the Moqui community.

I don't agree that OFBiz is a sinking ship. There are a number of
service providers who are heavily invested in this project, and they are
not going to throw that all away for a new one.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 3/7/2014 5:58 AM, Al Byers wrote:

> In light of the current discussion about the future of OFBiz I thought it
> would be worth revisiting one of my finer moments by reposting this from
> David Jones. In today's world 12 technology years is a lifetime. It is not
> reasonable to think that we can keep scaling the original framework.
> Another thing to think about is that in order to attract a new group of
> users sometimes it takes a big new idea and Moqui fills that role. We
> should all keep in mind that OFBiz succeeded secondly because of all the
> hard work put in by the community, but firstly because of the brilliant
> architecture and foundation provided by David (and Andrew). When that same
> mind applies it to fixing most of OFBiz's problems we should be talking
> about how to transition - end of discussion, IMHO.
>
> I believe that it has been since David wrote this email that he has
> integrated Elasticsearch and Drools into Moqui. Those are the kinds of
> exciting technologies that OFBiz needs. And it is high time that we stopped
> programming in Java. I have loved the seemless transition to Groovy and I
> like having only one scripting language. The future is going to demand much
> more flexibility than OFBiz can deliver. Moqui, with its small core size
> and its application of FreeMarker to the frontend provides that flexibility.
>
> I don't know exactly how the transition to Moqui should take place, but
> that is where the discussion should take place. Anything else, and we are
> just discussing how slowly the ship will be sinking. I think David should
> remain in control of the core (as I think he would insist), but there are a
> lot of options for porting the mantle and crust portions. I think we should
> think outside the box and look to something like KickStarter to get it done
> quickly.
>
> -Al
>
> On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:
>
>>
>> OFBiz has recently turned 12 years old. At the time it was written many
>> more modern libraries either didn't exist or were not usable, including:
>>
>> - Groovy
>> - ehcache
>> - Quartz Scheduler
>> - Atomikos
>> - JackRabbit (and JCR in general)
>> - Shiro
>> - Camel
>> - JSON-RPC, REST, JSON in general
>> - ElasticSearch (and to some extent even Lucene)
>> - Document and other NoSQL databases (of which ElasticSearch is sort of,
>> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
>>
>> Some of these are used, or with some customization usable, in OFBiz. Many
>> of them overlap a lot with parts of the OFBiz framework, and unlike
>> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
>>
>> Some big ones are caching, job scheduling, content management, and even
>> searching. The OFBiz ProductSearch stuff works well enough (though not
>> great) for smaller sets of products, but doesn't compare in flexibility,
>> scalability, and speed to ElasticSearch and some other Lucene-based
>> alternatives. With some simple framework extensions (like the DataDocument,
>> DataFeed, and DataSearch features of Moqui) implementing excellent search
>> for products would be easy, as would search for any other part of the
>> system... and all combined in a single system-wide search or segmented as
>> desired.
>>
>> Another big one, that has been most painful for me in dealing with OFBiz,
>> is the lack of consistent scripting and expressions. Once you get used to
>> the elegance of Groovy dealing with BSH and JUEL is downright painful...
>> and for me anyway requires a number of misses before I finally get it
>> working. The ${groovy:...} work-around is there, but quirky, and the
>> resulting object is unreliable as in some OFBiz XML files it results in a
>> String while in others it results in the actual Object the expression
>> evaluates to.
>>
>> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
>> but it needs FAR more modernization than is currently happening or that is
>> likely to happen. The new feature velocity in the framework is so slow
>> (mostly because of the architecture and existing code, partly because of
>> collaboration breakdown reasons), that it can't keep up with alternatives.
>>
>> So yes, OFBiz is great, but it exists in a world that is progressing far
>> faster than it can. My reason for starting fresh was just that simple:
>> development velocity.
>>
>> On top of that OFBiz uses certain approaches that are difficult to deploy
>> and maintain. Try dropping all of OFBiz into a single war file for easy
>> upload deployment on the dozens of modern cloud/PaaS services. Try adding
>> plug-ins that require a proper init/destroy lifecycle instead of relying on
>> static initialization and no proper tear down. Try finding framework
>> functionality in thousands of static methods spread across dozens (or
>> hundreds?) of classes. I know these weaknesses of OFBiz well... they are my
>> mistakes. Correcting them is another matter... and one I didn't find
>> possible in the context of the project with the limited time I have
>> available. It was faster and easier to start fresh.
>>
>> When I started OFBiz I was 23 years old and had about 2 years of
>> experience in ERP systems. I think it's great that there is enough interest
>> to keep the project alive and at whatever pace keep it progressing both
>> technically and for support of business activities. Still, something must
>> be done for it to remain competitive with open source and commercial
>> alternatives if it is to compete... including with what I've been calling
>> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
>> Artifacts, and the various projects and products built on them.
>>
>> As good as it is, there is lots of room for improvement and others are
>> doing just that. I don't think Al was implying that "OFBiz is no longer
>> brilliant", maybe some are overly sensitive to that. The fact is that OFBiz
>> is what it is, and without major improvements alternatives exceed it in so
>> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
>> bright stars its brilliance is only relevant in context.
>>
>> OFBiz has lots of momentum, and pretty good marketplace around it, and a
>> lot of people are making good money doing work based on it (including me).
>> Still, I tire frequently of explaining that so many things are known issues
>> with the project and not easy to correct, but are corrected in the "Next
>> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround that
>> can't be committed because it breaks other things, just things they don't
>> intend to use (this still has consequences for bigger projects... things
>> all seem to come back around).
>>
>> So, it is what it is. I understand the motivation to paint OFBiz the best
>> possible for marketing purposes and such... I personally did that for years
>> in spite of known flaws. Eventually that only goes so far... OFBiz versus
>> other open source alternatives has its pluses and minuses, and most in the
>> community are very aware of those minuses. This causes many to drool over
>> cleaner, newer solutions like Magento, even if it is based on a totally
>> different underlying technology and one that doesn't scale as well or
>> interact in enterprise environments as well.
>>
>> Sooner or later reality catches up... best to stay ahead of it or at least
>> have long-term plans and alternatives to fall-back on.
>>
>> -David
>>
>>
>> On May 20, 2013, at 11:10 AM, Adrian Crum <
>> [hidden email]> wrote:
>>
>>> A quick clarification on this.
>>>
>>> "OFBiz was brilliant when David created it over ten years ago, but..."
>> implies OFBiz is no longer brilliant. OFBiz continues to be just as
>> brilliant, with a talented team of developers keeping it current with
>> current technology.
>>>
>>> -Adrian
>>>
>>> On 5/20/2013 4:04 PM, Al Byers wrote:
>>>> Hi Carlos,
>>>>
>>>> I am just starting to look around for OFBiz work and was intrigued to
>> see your email there this morning. I have been working with OFBiz for over
>> 10 years now and am interested in what you have going.
>>>>
>>>> But I must ask if you have considered Moqui (moqui.org <
>> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
>> small conference with David and the folks at HowWax Media and based on
>> David's comments and what I know about Moqui from my past year of working
>> with it, if you are starting anew, and especially if you are not using the
>> current e-commerce features of OFBiz, then you would be well served to look
>> at Moqui. OFBiz was brilliant when David created it over ten years ago, but
>> technology has made great advances in that time and if you have the freedom
>> to do so, it makes sense to start with the latest base.
>>>>
>>>> I have attached David's introduction to Moqui PDF, which I don't think
>> is readily available off the moqui.org <http://moqui.org> website.
>>>>
>>>> I hope to hear from you soon.
>>>>
>>>> Al Byers
>>>> 801-400-5111
>>>>
>>>>
>>>> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz <[hidden email]<mailto:
>> [hidden email]>> wrote:
>>>>
>>>>     Hi;
>>>>
>>>>     I'm looking for a Java programmer that is familiar with OFBiz.
>>>>     Particularly with OFBiz Web Services and OFBiz Entity Engine.
>>>>
>>>>     I'm interested in hosting OFBiz for some very specific industries
>>>>     and I want to develop some very specific interfaces.
>>>>
>>>>     This is a long term project, I could be flexible with the hours.
>>>>
>>>>     If you're interested email me for more details.
>>>>
>>>>     Also feel free to forward this email to someone you think might be
>>>>     interested.
>>>>
>>>>     Thanks!!
>>>>
>>>>     Carlos
>>>>
>>>>     logo-for-social-media-sites-email_signature
>>>>
>>>>     CruzControl Radius
>>>>
>>>>     Your Success Is Our Service
>>>>
>>>>     www.ccradius.com <http://www.ccradius.com>
>>>>
>>>>     email:[hidden email] <mailto:email%[hidden email]>
>>>>
>>>>     1-877-285-5499 <tel:[phone]>
>>>>
>>>>
>>>
>>
>>
>

[byersa]

Adrian, I think that you have summed up the situation in your succinct post
- there are some service providers who are heavily invested in this project
and it is their concern for their own interests that is  guiding OFBiz.
Someone new looking at OFBiz should lament the fact that so much
application value is tied to such old technology. Then they should look at
Moqui and see how easy it would be to port that value to a new platform -
at least much easier than creating a new framework - and wonder why it is
not being done.

I reject the idea that "anyone is interested in building applications on
Moqui, [...]should do it in the Moqui community". OFBiz does not belong to
the PMC; it belongs to everybody. I have a dream... sorry, got carried
away. This seems like a test of the Apache framework - does it provide for
the long-term life of a project when it conflicts with the self-interests
of the PMC?


On Fri, Mar 7, 2014 at 10:24 AM, Adrian Crum <
[hidden email]> wrote:

> Switching OFBiz to a different framework has been discussed in the past,
> and I brought up the subject again in a recent thread on the dev mailing
> list. At this time, there are some PMC members who are opposed to the idea,
> so I don't see any hope for switching to Moqui in this project.
>
> If anyone is interested in building applications on Moqui, then they
> should do it in the Moqui community.
>
> I don't agree that OFBiz is a sinking ship. There are a number of service
> providers who are heavily invested in this project, and they are not going
> to throw that all away for a new one.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
>
> On 3/7/2014 5:58 AM, Al Byers wrote:
>
>> In light of the current discussion about the future of OFBiz I thought it
>> would be worth revisiting one of my finer moments by reposting this from
>> David Jones. In today's world 12 technology years is a lifetime. It is not
>> reasonable to think that we can keep scaling the original framework.
>> Another thing to think about is that in order to attract a new group of
>> users sometimes it takes a big new idea and Moqui fills that role. We
>> should all keep in mind that OFBiz succeeded secondly because of all the
>> hard work put in by the community, but firstly because of the brilliant
>> architecture and foundation provided by David (and Andrew). When that same
>> mind applies it to fixing most of OFBiz's problems we should be talking
>> about how to transition - end of discussion, IMHO.
>>
>> I believe that it has been since David wrote this email that he has
>> integrated Elasticsearch and Drools into Moqui. Those are the kinds of
>> exciting technologies that OFBiz needs. And it is high time that we
>> stopped
>> programming in Java. I have loved the seemless transition to Groovy and I
>> like having only one scripting language. The future is going to demand
>> much
>> more flexibility than OFBiz can deliver. Moqui, with its small core size
>> and its application of FreeMarker to the frontend provides that
>> flexibility.
>>
>> I don't know exactly how the transition to Moqui should take place, but
>> that is where the discussion should take place. Anything else, and we are
>> just discussing how slowly the ship will be sinking. I think David should
>> remain in control of the core (as I think he would insist), but there are
>> a
>> lot of options for porting the mantle and crust portions. I think we
>> should
>> think outside the box and look to something like KickStarter to get it
>> done
>> quickly.
>>
>> -Al
>>
>> On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:
>>
>>
>>> OFBiz has recently turned 12 years old. At the time it was written many
>>> more modern libraries either didn't exist or were not usable, including:
>>>
>>> - Groovy
>>> - ehcache
>>> - Quartz Scheduler
>>> - Atomikos
>>> - JackRabbit (and JCR in general)
>>> - Shiro
>>> - Camel
>>> - JSON-RPC, REST, JSON in general
>>> - ElasticSearch (and to some extent even Lucene)
>>> - Document and other NoSQL databases (of which ElasticSearch is sort of,
>>> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
>>>
>>> Some of these are used, or with some customization usable, in OFBiz. Many
>>> of them overlap a lot with parts of the OFBiz framework, and unlike
>>> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
>>>
>>> Some big ones are caching, job scheduling, content management, and even
>>> searching. The OFBiz ProductSearch stuff works well enough (though not
>>> great) for smaller sets of products, but doesn't compare in flexibility,
>>> scalability, and speed to ElasticSearch and some other Lucene-based
>>> alternatives. With some simple framework extensions (like the
>>> DataDocument,
>>> DataFeed, and DataSearch features of Moqui) implementing excellent search
>>> for products would be easy, as would search for any other part of the
>>> system... and all combined in a single system-wide search or segmented as
>>> desired.
>>>
>>> Another big one, that has been most painful for me in dealing with OFBiz,
>>> is the lack of consistent scripting and expressions. Once you get used to
>>> the elegance of Groovy dealing with BSH and JUEL is downright painful...
>>> and for me anyway requires a number of misses before I finally get it
>>> working. The ${groovy:...} work-around is there, but quirky, and the
>>> resulting object is unreliable as in some OFBiz XML files it results in a
>>> String while in others it results in the actual Object the expression
>>> evaluates to.
>>>
>>> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
>>> but it needs FAR more modernization than is currently happening or that
>>> is
>>> likely to happen. The new feature velocity in the framework is so slow
>>> (mostly because of the architecture and existing code, partly because of
>>> collaboration breakdown reasons), that it can't keep up with
>>> alternatives.
>>>
>>> So yes, OFBiz is great, but it exists in a world that is progressing far
>>> faster than it can. My reason for starting fresh was just that simple:
>>> development velocity.
>>>
>>> On top of that OFBiz uses certain approaches that are difficult to deploy
>>> and maintain. Try dropping all of OFBiz into a single war file for easy
>>> upload deployment on the dozens of modern cloud/PaaS services. Try adding
>>> plug-ins that require a proper init/destroy lifecycle instead of relying
>>> on
>>> static initialization and no proper tear down. Try finding framework
>>> functionality in thousands of static methods spread across dozens (or
>>> hundreds?) of classes. I know these weaknesses of OFBiz well... they are
>>> my
>>> mistakes. Correcting them is another matter... and one I didn't find
>>> possible in the context of the project with the limited time I have
>>> available. It was faster and easier to start fresh.
>>>
>>> When I started OFBiz I was 23 years old and had about 2 years of
>>> experience in ERP systems. I think it's great that there is enough
>>> interest
>>> to keep the project alive and at whatever pace keep it progressing both
>>> technically and for support of business activities. Still, something must
>>> be done for it to remain competitive with open source and commercial
>>> alternatives if it is to compete... including with what I've been calling
>>> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
>>> Artifacts, and the various projects and products built on them.
>>>
>>> As good as it is, there is lots of room for improvement and others are
>>> doing just that. I don't think Al was implying that "OFBiz is no longer
>>> brilliant", maybe some are overly sensitive to that. The fact is that
>>> OFBiz
>>> is what it is, and without major improvements alternatives exceed it in
>>> so
>>> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
>>> bright stars its brilliance is only relevant in context.
>>>
>>> OFBiz has lots of momentum, and pretty good marketplace around it, and a
>>> lot of people are making good money doing work based on it (including
>>> me).
>>> Still, I tire frequently of explaining that so many things are known
>>> issues
>>> with the project and not easy to correct, but are corrected in the "Next
>>> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround
>>> that
>>> can't be committed because it breaks other things, just things they don't
>>> intend to use (this still has consequences for bigger projects... things
>>> all seem to come back around).
>>>
>>> So, it is what it is. I understand the motivation to paint OFBiz the best
>>> possible for marketing purposes and such... I personally did that for
>>> years
>>> in spite of known flaws. Eventually that only goes so far... OFBiz versus
>>> other open source alternatives has its pluses and minuses, and most in
>>> the
>>> community are very aware of those minuses. This causes many to drool over
>>> cleaner, newer solutions like Magento, even if it is based on a totally
>>> different underlying technology and one that doesn't scale as well or
>>> interact in enterprise environments as well.
>>>
>>> Sooner or later reality catches up... best to stay ahead of it or at
>>> least
>>> have long-term plans and alternatives to fall-back on.
>>>
>>> -David
>>>
>>>
>>> On May 20, 2013, at 11:10 AM, Adrian Crum <
>>> [hidden email]> wrote:
>>>
>>>  A quick clarification on this.
>>>>
>>>> "OFBiz was brilliant when David created it over ten years ago, but..."
>>>>
>>> implies OFBiz is no longer brilliant. OFBiz continues to be just as
>>> brilliant, with a talented team of developers keeping it current with
>>> current technology.
>>>
>>>>
>>>> -Adrian
>>>>
>>>> On 5/20/2013 4:04 PM, Al Byers wrote:
>>>>
>>>>> Hi Carlos,
>>>>>
>>>>> I am just starting to look around for OFBiz work and was intrigued to
>>>>>
>>>> see your email there this morning. I have been working with OFBiz for
>>> over
>>> 10 years now and am interested in what you have going.
>>>
>>>>
>>>>> But I must ask if you have considered Moqui (moqui.org <
>>>>>
>>>> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
>>> small conference with David and the folks at HowWax Media and based on
>>> David's comments and what I know about Moqui from my past year of working
>>> with it, if you are starting anew, and especially if you are not using
>>> the
>>> current e-commerce features of OFBiz, then you would be well served to
>>> look
>>> at Moqui. OFBiz was brilliant when David created it over ten years ago,
>>> but
>>> technology has made great advances in that time and if you have the
>>> freedom
>>> to do so, it makes sense to start with the latest base.
>>>
>>>>
>>>>> I have attached David's introduction to Moqui PDF, which I don't think
>>>>>
>>>> is readily available off the moqui.org <http://moqui.org> website.
>>>
>>>>
>>>>> I hope to hear from you soon.
>>>>>
>>>>> Al Byers
>>>>> 801-400-5111
>>>>>
>>>>>
>>>>> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz <[hidden email]
>>>>> <mailto:
>>>>>
>>>> [hidden email]>> wrote:
>>>
>>>>
>>>>>     Hi;
>>>>>
>>>>>     I'm looking for a Java programmer that is familiar with OFBiz.
>>>>>     Particularly with OFBiz Web Services and OFBiz Entity Engine.
>>>>>
>>>>>     I'm interested in hosting OFBiz for some very specific industries
>>>>>     and I want to develop some very specific interfaces.
>>>>>
>>>>>     This is a long term project, I could be flexible with the hours.
>>>>>
>>>>>     If you're interested email me for more details.
>>>>>
>>>>>     Also feel free to forward this email to someone you think might be
>>>>>     interested.
>>>>>
>>>>>     Thanks!!
>>>>>
>>>>>     Carlos
>>>>>
>>>>>     logo-for-social-media-sites-email_signature
>>>>>
>>>>>     CruzControl Radius
>>>>>
>>>>>     Your Success Is Our Service
>>>>>
>>>>>     www.ccradius.com <http://www.ccradius.com>
>>>>>
>>>>>     email:[hidden email] <mailto:email%[hidden email]>
>>>>>
>>>>>     1-877-285-5499 <tel:[phone]>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>

[byersa]

And BTW, I need to emphasize that I do not think the PMC has been selfish
in their actions. They have added untold value to OFBiz. If I had made the
sacrifices that they have made, I would be hesitant to entertain notions
that would detract from that value. I just happen to think that when looked
at objectively, porting to Moqui would be the best choice in terms of
keeping the project viable.


On Fri, Mar 7, 2014 at 11:12 AM, Al Byers <[hidden email]>wrote:

> Adrian, I think that you have summed up the situation in your succinct
> post - there are some service providers who are heavily invested in this
> project and it is their concern for their own interests that is  guiding
> OFBiz. Someone new looking at OFBiz should lament the fact that so much
> application value is tied to such old technology. Then they should look at
> Moqui and see how easy it would be to port that value to a new platform -
> at least much easier than creating a new framework - and wonder why it is
> not being done.
>
> I reject the idea that "anyone is interested in building applications on
> Moqui, [...]should do it in the Moqui community". OFBiz does not belong to
> the PMC; it belongs to everybody. I have a dream... sorry, got carried
> away. This seems like a test of the Apache framework - does it provide for
> the long-term life of a project when it conflicts with the self-interests
> of the PMC?
>
>
> On Fri, Mar 7, 2014 at 10:24 AM, Adrian Crum <
> [hidden email]> wrote:
>
>> Switching OFBiz to a different framework has been discussed in the past,
>> and I brought up the subject again in a recent thread on the dev mailing
>> list. At this time, there are some PMC members who are opposed to the idea,
>> so I don't see any hope for switching to Moqui in this project.
>>
>> If anyone is interested in building applications on Moqui, then they
>> should do it in the Moqui community.
>>
>> I don't agree that OFBiz is a sinking ship. There are a number of service
>> providers who are heavily invested in this project, and they are not going
>> to throw that all away for a new one.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>>
>> On 3/7/2014 5:58 AM, Al Byers wrote:
>>
>>> In light of the current discussion about the future of OFBiz I thought it
>>> would be worth revisiting one of my finer moments by reposting this from
>>> David Jones. In today's world 12 technology years is a lifetime. It is
>>> not
>>> reasonable to think that we can keep scaling the original framework.
>>> Another thing to think about is that in order to attract a new group of
>>> users sometimes it takes a big new idea and Moqui fills that role. We
>>> should all keep in mind that OFBiz succeeded secondly because of all the
>>> hard work put in by the community, but firstly because of the brilliant
>>> architecture and foundation provided by David (and Andrew). When that
>>> same
>>> mind applies it to fixing most of OFBiz's problems we should be talking
>>> about how to transition - end of discussion, IMHO.
>>>
>>> I believe that it has been since David wrote this email that he has
>>> integrated Elasticsearch and Drools into Moqui. Those are the kinds of
>>> exciting technologies that OFBiz needs. And it is high time that we
>>> stopped
>>> programming in Java. I have loved the seemless transition to Groovy and I
>>> like having only one scripting language. The future is going to demand
>>> much
>>> more flexibility than OFBiz can deliver. Moqui, with its small core size
>>> and its application of FreeMarker to the frontend provides that
>>> flexibility.
>>>
>>> I don't know exactly how the transition to Moqui should take place, but
>>> that is where the discussion should take place. Anything else, and we are
>>> just discussing how slowly the ship will be sinking. I think David should
>>> remain in control of the core (as I think he would insist), but there
>>> are a
>>> lot of options for porting the mantle and crust portions. I think we
>>> should
>>> think outside the box and look to something like KickStarter to get it
>>> done
>>> quickly.
>>>
>>> -Al
>>>
>>> On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:
>>>
>>>
>>>> OFBiz has recently turned 12 years old. At the time it was written many
>>>> more modern libraries either didn't exist or were not usable, including:
>>>>
>>>> - Groovy
>>>> - ehcache
>>>> - Quartz Scheduler
>>>> - Atomikos
>>>> - JackRabbit (and JCR in general)
>>>> - Shiro
>>>> - Camel
>>>> - JSON-RPC, REST, JSON in general
>>>> - ElasticSearch (and to some extent even Lucene)
>>>> - Document and other NoSQL databases (of which ElasticSearch is sort of,
>>>> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
>>>>
>>>> Some of these are used, or with some customization usable, in OFBiz.
>>>> Many
>>>> of them overlap a lot with parts of the OFBiz framework, and unlike
>>>> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
>>>>
>>>> Some big ones are caching, job scheduling, content management, and even
>>>> searching. The OFBiz ProductSearch stuff works well enough (though not
>>>> great) for smaller sets of products, but doesn't compare in flexibility,
>>>> scalability, and speed to ElasticSearch and some other Lucene-based
>>>> alternatives. With some simple framework extensions (like the
>>>> DataDocument,
>>>> DataFeed, and DataSearch features of Moqui) implementing excellent
>>>> search
>>>> for products would be easy, as would search for any other part of the
>>>> system... and all combined in a single system-wide search or segmented
>>>> as
>>>> desired.
>>>>
>>>> Another big one, that has been most painful for me in dealing with
>>>> OFBiz,
>>>> is the lack of consistent scripting and expressions. Once you get used
>>>> to
>>>> the elegance of Groovy dealing with BSH and JUEL is downright painful...
>>>> and for me anyway requires a number of misses before I finally get it
>>>> working. The ${groovy:...} work-around is there, but quirky, and the
>>>> resulting object is unreliable as in some OFBiz XML files it results in
>>>> a
>>>> String while in others it results in the actual Object the expression
>>>> evaluates to.
>>>>
>>>> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
>>>> but it needs FAR more modernization than is currently happening or that
>>>> is
>>>> likely to happen. The new feature velocity in the framework is so slow
>>>> (mostly because of the architecture and existing code, partly because of
>>>> collaboration breakdown reasons), that it can't keep up with
>>>> alternatives.
>>>>
>>>> So yes, OFBiz is great, but it exists in a world that is progressing far
>>>> faster than it can. My reason for starting fresh was just that simple:
>>>> development velocity.
>>>>
>>>> On top of that OFBiz uses certain approaches that are difficult to
>>>> deploy
>>>> and maintain. Try dropping all of OFBiz into a single war file for easy
>>>> upload deployment on the dozens of modern cloud/PaaS services. Try
>>>> adding
>>>> plug-ins that require a proper init/destroy lifecycle instead of
>>>> relying on
>>>> static initialization and no proper tear down. Try finding framework
>>>> functionality in thousands of static methods spread across dozens (or
>>>> hundreds?) of classes. I know these weaknesses of OFBiz well... they
>>>> are my
>>>> mistakes. Correcting them is another matter... and one I didn't find
>>>> possible in the context of the project with the limited time I have
>>>> available. It was faster and easier to start fresh.
>>>>
>>>> When I started OFBiz I was 23 years old and had about 2 years of
>>>> experience in ERP systems. I think it's great that there is enough
>>>> interest
>>>> to keep the project alive and at whatever pace keep it progressing both
>>>> technically and for support of business activities. Still, something
>>>> must
>>>> be done for it to remain competitive with open source and commercial
>>>> alternatives if it is to compete... including with what I've been
>>>> calling
>>>> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
>>>> Artifacts, and the various projects and products built on them.
>>>>
>>>> As good as it is, there is lots of room for improvement and others are
>>>> doing just that. I don't think Al was implying that "OFBiz is no longer
>>>> brilliant", maybe some are overly sensitive to that. The fact is that
>>>> OFBiz
>>>> is what it is, and without major improvements alternatives exceed it in
>>>> so
>>>> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
>>>> bright stars its brilliance is only relevant in context.
>>>>
>>>> OFBiz has lots of momentum, and pretty good marketplace around it, and a
>>>> lot of people are making good money doing work based on it (including
>>>> me).
>>>> Still, I tire frequently of explaining that so many things are known
>>>> issues
>>>> with the project and not easy to correct, but are corrected in the "Next
>>>> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround
>>>> that
>>>> can't be committed because it breaks other things, just things they
>>>> don't
>>>> intend to use (this still has consequences for bigger projects... things
>>>> all seem to come back around).
>>>>
>>>> So, it is what it is. I understand the motivation to paint OFBiz the
>>>> best
>>>> possible for marketing purposes and such... I personally did that for
>>>> years
>>>> in spite of known flaws. Eventually that only goes so far... OFBiz
>>>> versus
>>>> other open source alternatives has its pluses and minuses, and most in
>>>> the
>>>> community are very aware of those minuses. This causes many to drool
>>>> over
>>>> cleaner, newer solutions like Magento, even if it is based on a totally
>>>> different underlying technology and one that doesn't scale as well or
>>>> interact in enterprise environments as well.
>>>>
>>>> Sooner or later reality catches up... best to stay ahead of it or at
>>>> least
>>>> have long-term plans and alternatives to fall-back on.
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 20, 2013, at 11:10 AM, Adrian Crum <
>>>> [hidden email]> wrote:
>>>>
>>>>  A quick clarification on this.
>>>>>
>>>>> "OFBiz was brilliant when David created it over ten years ago, but..."
>>>>>
>>>> implies OFBiz is no longer brilliant. OFBiz continues to be just as
>>>> brilliant, with a talented team of developers keeping it current with
>>>> current technology.
>>>>
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 5/20/2013 4:04 PM, Al Byers wrote:
>>>>>
>>>>>> Hi Carlos,
>>>>>>
>>>>>> I am just starting to look around for OFBiz work and was intrigued to
>>>>>>
>>>>> see your email there this morning. I have been working with OFBiz for
>>>> over
>>>> 10 years now and am interested in what you have going.
>>>>
>>>>>
>>>>>> But I must ask if you have considered Moqui (moqui.org <
>>>>>>
>>>>> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
>>>> small conference with David and the folks at HowWax Media and based on
>>>> David's comments and what I know about Moqui from my past year of
>>>> working
>>>> with it, if you are starting anew, and especially if you are not using
>>>> the
>>>> current e-commerce features of OFBiz, then you would be well served to
>>>> look
>>>> at Moqui. OFBiz was brilliant when David created it over ten years ago,
>>>> but
>>>> technology has made great advances in that time and if you have the
>>>> freedom
>>>> to do so, it makes sense to start with the latest base.
>>>>
>>>>>
>>>>>> I have attached David's introduction to Moqui PDF, which I don't think
>>>>>>
>>>>> is readily available off the moqui.org <http://moqui.org> website.
>>>>
>>>>>
>>>>>> I hope to hear from you soon.
>>>>>>
>>>>>> Al Byers
>>>>>> 801-400-5111
>>>>>>
>>>>>>
>>>>>> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz <
>>>>>> [hidden email]<mailto:
>>>>>>
>>>>> [hidden email]>> wrote:
>>>>
>>>>>
>>>>>>     Hi;
>>>>>>
>>>>>>     I'm looking for a Java programmer that is familiar with OFBiz.
>>>>>>     Particularly with OFBiz Web Services and OFBiz Entity Engine.
>>>>>>
>>>>>>     I'm interested in hosting OFBiz for some very specific industries
>>>>>>     and I want to develop some very specific interfaces.
>>>>>>
>>>>>>     This is a long term project, I could be flexible with the hours.
>>>>>>
>>>>>>     If you're interested email me for more details.
>>>>>>
>>>>>>     Also feel free to forward this email to someone you think might be
>>>>>>     interested.
>>>>>>
>>>>>>     Thanks!!
>>>>>>
>>>>>>     Carlos
>>>>>>
>>>>>>     logo-for-social-media-sites-email_signature
>>>>>>
>>>>>>     CruzControl Radius
>>>>>>
>>>>>>     Your Success Is Our Service
>>>>>>
>>>>>>     www.ccradius.com <http://www.ccradius.com>
>>>>>>
>>>>>>     email:[hidden email] <mailto:email%[hidden email]>
>>>>>>
>>>>>>     1-877-285-5499 <tel:[phone]>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>

[Todd Thorner]

I just found out about Moqui, but I refuse to sign up for LinkedIn so I
won't be joining that community anytime soon.

Pity party for me, I suppose.  Considering how I'm just barely getting
on board with the whole "ERP/E-Commerce framework" thing, I'd prefer to
start off with the latest up-and-coming technology.  I loathe the idea
of keeping some legacy system patched together while 99.99% of the
business world has moved on to something else.  I can remember the whole
"Forget about DP and just keep using these Selectrics we all know and
love" debate among tech writers 25-odd years ago, as well as the
argument about whether RDBMS/SQL was going to make much of an impact on
companies with established, proprietary mainframe systems.  For that
matter, ten or twelve years ago I was a big fan of Struts, although many
have since moved on to Springier things (or away from Java altogether).

Are differences between the OFBiz and Moqui frameworks quite
significant?  That's not a question directed toward Mr. Byers
specifically, I'm just trying to get a potential business strategy
straightened out in my head.

Aside: I might as well put in my 0.02 regarding the teleconference that
Mr. Smits arranged.  Almost all software products both open source and
proprietary share a major end user pain point: documentation.  All too
often, in a bug-ticket kind of way, such pain points go beyond being
major to become critical show-stoppers.

Oh, and also 0.02 worth of cheerleading for CMIS.  If y'all get a
chance, take a look at the ASF Chemistry project, it might offer a way
to lessen some of this project's code maintenance chores (although I'm
in no way qualified to be certain one way or the other).



On 14-03-07 08:43 AM, Al Byers wrote:

> And BTW, I need to emphasize that I do not think the PMC has been selfish
> in their actions. They have added untold value to OFBiz. If I had made the
> sacrifices that they have made, I would be hesitant to entertain notions
> that would detract from that value. I just happen to think that when looked
> at objectively, porting to Moqui would be the best choice in terms of
> keeping the project viable.
>
>
> On Fri, Mar 7, 2014 at 11:12 AM, Al Byers <[hidden email]>wrote:
>
>> Adrian, I think that you have summed up the situation in your succinct
>> post - there are some service providers who are heavily invested in this
>> project and it is their concern for their own interests that is  guiding
>> OFBiz. Someone new looking at OFBiz should lament the fact that so much
>> application value is tied to such old technology. Then they should look at
>> Moqui and see how easy it would be to port that value to a new platform -
>> at least much easier than creating a new framework - and wonder why it is
>> not being done.
>>
>> I reject the idea that "anyone is interested in building applications on
>> Moqui, [...]should do it in the Moqui community". OFBiz does not belong to
>> the PMC; it belongs to everybody. I have a dream... sorry, got carried
>> away. This seems like a test of the Apache framework - does it provide for
>> the long-term life of a project when it conflicts with the self-interests
>> of the PMC?
>>
>>
>> On Fri, Mar 7, 2014 at 10:24 AM, Adrian Crum <
>> [hidden email]> wrote:
>>
>>> Switching OFBiz to a different framework has been discussed in the past,
>>> and I brought up the subject again in a recent thread on the dev mailing
>>> list. At this time, there are some PMC members who are opposed to the idea,
>>> so I don't see any hope for switching to Moqui in this project.
>>>
>>> If anyone is interested in building applications on Moqui, then they
>>> should do it in the Moqui community.
>>>
>>> I don't agree that OFBiz is a sinking ship. There are a number of service
>>> providers who are heavily invested in this project, and they are not going
>>> to throw that all away for a new one.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>>
>>> On 3/7/2014 5:58 AM, Al Byers wrote:
>>>
>>>> In light of the current discussion about the future of OFBiz I thought it
>>>> would be worth revisiting one of my finer moments by reposting this from
>>>> David Jones. In today's world 12 technology years is a lifetime. It is
>>>> not
>>>> reasonable to think that we can keep scaling the original framework.
>>>> Another thing to think about is that in order to attract a new group of
>>>> users sometimes it takes a big new idea and Moqui fills that role. We
>>>> should all keep in mind that OFBiz succeeded secondly because of all the
>>>> hard work put in by the community, but firstly because of the brilliant
>>>> architecture and foundation provided by David (and Andrew). When that
>>>> same
>>>> mind applies it to fixing most of OFBiz's problems we should be talking
>>>> about how to transition - end of discussion, IMHO.
>>>>
>>>> I believe that it has been since David wrote this email that he has
>>>> integrated Elasticsearch and Drools into Moqui. Those are the kinds of
>>>> exciting technologies that OFBiz needs. And it is high time that we
>>>> stopped
>>>> programming in Java. I have loved the seemless transition to Groovy and I
>>>> like having only one scripting language. The future is going to demand
>>>> much
>>>> more flexibility than OFBiz can deliver. Moqui, with its small core size
>>>> and its application of FreeMarker to the frontend provides that
>>>> flexibility.
>>>>
>>>> I don't know exactly how the transition to Moqui should take place, but
>>>> that is where the discussion should take place. Anything else, and we are
>>>> just discussing how slowly the ship will be sinking. I think David should
>>>> remain in control of the core (as I think he would insist), but there
>>>> are a
>>>> lot of options for porting the mantle and crust portions. I think we
>>>> should
>>>> think outside the box and look to something like KickStarter to get it
>>>> done
>>>> quickly.
>>>>
>>>> -Al
>>>>
>>>> On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:
>>>>
>>>>
>>>>> OFBiz has recently turned 12 years old. At the time it was written many
>>>>> more modern libraries either didn't exist or were not usable, including:
>>>>>
>>>>> - Groovy
>>>>> - ehcache
>>>>> - Quartz Scheduler
>>>>> - Atomikos
>>>>> - JackRabbit (and JCR in general)
>>>>> - Shiro
>>>>> - Camel
>>>>> - JSON-RPC, REST, JSON in general
>>>>> - ElasticSearch (and to some extent even Lucene)
>>>>> - Document and other NoSQL databases (of which ElasticSearch is sort of,
>>>>> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
>>>>>
>>>>> Some of these are used, or with some customization usable, in OFBiz.
>>>>> Many
>>>>> of them overlap a lot with parts of the OFBiz framework, and unlike
>>>>> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
>>>>>
>>>>> Some big ones are caching, job scheduling, content management, and even
>>>>> searching. The OFBiz ProductSearch stuff works well enough (though not
>>>>> great) for smaller sets of products, but doesn't compare in flexibility,
>>>>> scalability, and speed to ElasticSearch and some other Lucene-based
>>>>> alternatives. With some simple framework extensions (like the
>>>>> DataDocument,
>>>>> DataFeed, and DataSearch features of Moqui) implementing excellent
>>>>> search
>>>>> for products would be easy, as would search for any other part of the
>>>>> system... and all combined in a single system-wide search or segmented
>>>>> as
>>>>> desired.
>>>>>
>>>>> Another big one, that has been most painful for me in dealing with
>>>>> OFBiz,
>>>>> is the lack of consistent scripting and expressions. Once you get used
>>>>> to
>>>>> the elegance of Groovy dealing with BSH and JUEL is downright painful...
>>>>> and for me anyway requires a number of misses before I finally get it
>>>>> working. The ${groovy:...} work-around is there, but quirky, and the
>>>>> resulting object is unreliable as in some OFBiz XML files it results in
>>>>> a
>>>>> String while in others it results in the actual Object the expression
>>>>> evaluates to.
>>>>>
>>>>> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
>>>>> but it needs FAR more modernization than is currently happening or that
>>>>> is
>>>>> likely to happen. The new feature velocity in the framework is so slow
>>>>> (mostly because of the architecture and existing code, partly because of
>>>>> collaboration breakdown reasons), that it can't keep up with
>>>>> alternatives.
>>>>>
>>>>> So yes, OFBiz is great, but it exists in a world that is progressing far
>>>>> faster than it can. My reason for starting fresh was just that simple:
>>>>> development velocity.
>>>>>
>>>>> On top of that OFBiz uses certain approaches that are difficult to
>>>>> deploy
>>>>> and maintain. Try dropping all of OFBiz into a single war file for easy
>>>>> upload deployment on the dozens of modern cloud/PaaS services. Try
>>>>> adding
>>>>> plug-ins that require a proper init/destroy lifecycle instead of
>>>>> relying on
>>>>> static initialization and no proper tear down. Try finding framework
>>>>> functionality in thousands of static methods spread across dozens (or
>>>>> hundreds?) of classes. I know these weaknesses of OFBiz well... they
>>>>> are my
>>>>> mistakes. Correcting them is another matter... and one I didn't find
>>>>> possible in the context of the project with the limited time I have
>>>>> available. It was faster and easier to start fresh.
>>>>>
>>>>> When I started OFBiz I was 23 years old and had about 2 years of
>>>>> experience in ERP systems. I think it's great that there is enough
>>>>> interest
>>>>> to keep the project alive and at whatever pace keep it progressing both
>>>>> technically and for support of business activities. Still, something
>>>>> must
>>>>> be done for it to remain competitive with open source and commercial
>>>>> alternatives if it is to compete... including with what I've been
>>>>> calling
>>>>> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
>>>>> Artifacts, and the various projects and products built on them.
>>>>>
>>>>> As good as it is, there is lots of room for improvement and others are
>>>>> doing just that. I don't think Al was implying that "OFBiz is no longer
>>>>> brilliant", maybe some are overly sensitive to that. The fact is that
>>>>> OFBiz
>>>>> is what it is, and without major improvements alternatives exceed it in
>>>>> so
>>>>> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
>>>>> bright stars its brilliance is only relevant in context.
>>>>>
>>>>> OFBiz has lots of momentum, and pretty good marketplace around it, and a
>>>>> lot of people are making good money doing work based on it (including
>>>>> me).
>>>>> Still, I tire frequently of explaining that so many things are known
>>>>> issues
>>>>> with the project and not easy to correct, but are corrected in the "Next
>>>>> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround
>>>>> that
>>>>> can't be committed because it breaks other things, just things they
>>>>> don't
>>>>> intend to use (this still has consequences for bigger projects... things
>>>>> all seem to come back around).
>>>>>
>>>>> So, it is what it is. I understand the motivation to paint OFBiz the
>>>>> best
>>>>> possible for marketing purposes and such... I personally did that for
>>>>> years
>>>>> in spite of known flaws. Eventually that only goes so far... OFBiz
>>>>> versus
>>>>> other open source alternatives has its pluses and minuses, and most in
>>>>> the
>>>>> community are very aware of those minuses. This causes many to drool
>>>>> over
>>>>> cleaner, newer solutions like Magento, even if it is based on a totally
>>>>> different underlying technology and one that doesn't scale as well or
>>>>> interact in enterprise environments as well.
>>>>>
>>>>> Sooner or later reality catches up... best to stay ahead of it or at
>>>>> least
>>>>> have long-term plans and alternatives to fall-back on.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On May 20, 2013, at 11:10 AM, Adrian Crum <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>  A quick clarification on this.
>>>>>>
>>>>>> "OFBiz was brilliant when David created it over ten years ago, but..."
>>>>>>
>>>>> implies OFBiz is no longer brilliant. OFBiz continues to be just as
>>>>> brilliant, with a talented team of developers keeping it current with
>>>>> current technology.
>>>>>
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 5/20/2013 4:04 PM, Al Byers wrote:
>>>>>>
>>>>>>> Hi Carlos,
>>>>>>>
>>>>>>> I am just starting to look around for OFBiz work and was intrigued to
>>>>>>>
>>>>>> see your email there this morning. I have been working with OFBiz for
>>>>> over
>>>>> 10 years now and am interested in what you have going.
>>>>>
>>>>>>
>>>>>>> But I must ask if you have considered Moqui (moqui.org <
>>>>>>>
>>>>>> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
>>>>> small conference with David and the folks at HowWax Media and based on
>>>>> David's comments and what I know about Moqui from my past year of
>>>>> working
>>>>> with it, if you are starting anew, and especially if you are not using
>>>>> the
>>>>> current e-commerce features of OFBiz, then you would be well served to
>>>>> look
>>>>> at Moqui. OFBiz was brilliant when David created it over ten years ago,
>>>>> but
>>>>> technology has made great advances in that time and if you have the
>>>>> freedom
>>>>> to do so, it makes sense to start with the latest base.
>>>>>
>>>>>>
>>>>>>> I have attached David's introduction to Moqui PDF, which I don't think
>>>>>>>
>>>>>> is readily available off the moqui.org <http://moqui.org> website.
>>>>>
>>>>>>
>>>>>>> I hope to hear from you soon.
>>>>>>>
>>>>>>> Al Byers
>>>>>>> 801-400-5111
>>>>>>>
>>>>>>>
>>>>>>> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz <
>>>>>>> [hidden email]<mailto:
>>>>>>>
>>>>>> [hidden email]>> wrote:
>>>>>
>>>>>>
>>>>>>>     Hi;
>>>>>>>
>>>>>>>     I'm looking for a Java programmer that is familiar with OFBiz.
>>>>>>>     Particularly with OFBiz Web Services and OFBiz Entity Engine.
>>>>>>>
>>>>>>>     I'm interested in hosting OFBiz for some very specific industries
>>>>>>>     and I want to develop some very specific interfaces.
>>>>>>>
>>>>>>>     This is a long term project, I could be flexible with the hours.
>>>>>>>
>>>>>>>     If you're interested email me for more details.
>>>>>>>
>>>>>>>     Also feel free to forward this email to someone you think might be
>>>>>>>     interested.
>>>>>>>
>>>>>>>     Thanks!!
>>>>>>>
>>>>>>>     Carlos
>>>>>>>
>>>>>>>     logo-for-social-media-sites-email_signature
>>>>>>>
>>>>>>>     CruzControl Radius
>>>>>>>
>>>>>>>     Your Success Is Our Service
>>>>>>>
>>>>>>>     www.ccradius.com <http://www.ccradius.com>
>>>>>>>
>>>>>>>     email:[hidden email] <mailto:email%[hidden email]>
>>>>>>>
>>>>>>>     1-877-285-5499 <tel:[phone]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>

[SkipDever]

I am sure Moqui is a fine framework, but I must agree with Adrian.  Yes,
lets all just abandon hundreds of man-years of work and start from scratch.
I don't know about most of you, but I derive most of my income servicing
EXISTING Ofbiz derived works.

Specifically, I take issue with the following from Al:

1.  "It is not reasonable to think that we can keep scaling the original
framework." --- Bullxxxx.  Ofbiz (or derivitives) is used by many LARGE
companies and scaling does not seem to be an issue.  Furthermore, Ofbiz is
mostly used by smallish companies where scale is not an issue.

2.  "I don't know exactly how the transition to Moqui should take place, but
that is where the discussion should take place."  -- There should be no
transition to Moqui IMHO.  Ofbiz is terrific.

3.  Ofbiz will never be a slowly sinking ship.  Go to the Moqui web site and
you will read "Ofbiz...reused and built on to create thousands of custom
systems and dozens of open source and commercial derivative works."  This
does not sound like a ship that is going to sink any time soon.

4.  JSON-RPC, REST, JSON in general, and ElasticSearch I think might have
general value to the community, but REST can be done now with JSON (in
custom URLs) and solr is also implemented in a JIRA and by BigFish.  All of
this can be implemented inside Ofbiz, Moqui is not required.

Just my two cents.

Skip

-----Original Message-----
From: Adrian Crum [mailto:[hidden email]]
Sent: Friday, March 07, 2014 7:24 AM
To: [hidden email]
Subject: Re: Reposting from David Jones on Moqui


Switching OFBiz to a different framework has been discussed in the past,
and I brought up the subject again in a recent thread on the dev mailing
list. At this time, there are some PMC members who are opposed to the
idea, so I don't see any hope for switching to Moqui in this project.

If anyone is interested in building applications on Moqui, then they
should do it in the Moqui community.

I don't agree that OFBiz is a sinking ship. There are a number of
service providers who are heavily invested in this project, and they are
not going to throw that all away for a new one.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 3/7/2014 5:58 AM, Al Byers wrote:

> In light of the current discussion about the future of OFBiz I thought it
> would be worth revisiting one of my finer moments by reposting this from
> David Jones. In today's world 12 technology years is a lifetime. It is not
> reasonable to think that we can keep scaling the original framework.
> Another thing to think about is that in order to attract a new group of
> users sometimes it takes a big new idea and Moqui fills that role. We
> should all keep in mind that OFBiz succeeded secondly because of all the
> hard work put in by the community, but firstly because of the brilliant
> architecture and foundation provided by David (and Andrew). When that same
> mind applies it to fixing most of OFBiz's problems we should be talking
> about how to transition - end of discussion, IMHO.
>
> I believe that it has been since David wrote this email that he has
> integrated Elasticsearch and Drools into Moqui. Those are the kinds of
> exciting technologies that OFBiz needs. And it is high time that we

stopped
> programming in Java. I have loved the seemless transition to Groovy and I
> like having only one scripting language. The future is going to demand
much
> more flexibility than OFBiz can deliver. Moqui, with its small core size
> and its application of FreeMarker to the frontend provides that
flexibility.
>
> I don't know exactly how the transition to Moqui should take place, but
> that is where the discussion should take place. Anything else, and we are
> just discussing how slowly the ship will be sinking. I think David should
> remain in control of the core (as I think he would insist), but there are
a
> lot of options for porting the mantle and crust portions. I think we
should
> think outside the box and look to something like KickStarter to get it
done

> quickly.
>
> -Al
>
> On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:
>
>>
>> OFBiz has recently turned 12 years old. At the time it was written many
>> more modern libraries either didn't exist or were not usable, including:
>>
>> - Groovy
>> - ehcache
>> - Quartz Scheduler
>> - Atomikos
>> - JackRabbit (and JCR in general)
>> - Shiro
>> - Camel
>> - JSON-RPC, REST, JSON in general
>> - ElasticSearch (and to some extent even Lucene)
>> - Document and other NoSQL databases (of which ElasticSearch is sort of,
>> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
>>
>> Some of these are used, or with some customization usable, in OFBiz. Many
>> of them overlap a lot with parts of the OFBiz framework, and unlike
>> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
>>
>> Some big ones are caching, job scheduling, content management, and even
>> searching. The OFBiz ProductSearch stuff works well enough (though not
>> great) for smaller sets of products, but doesn't compare in flexibility,
>> scalability, and speed to ElasticSearch and some other Lucene-based
>> alternatives. With some simple framework extensions (like the

DataDocument,

>> DataFeed, and DataSearch features of Moqui) implementing excellent search
>> for products would be easy, as would search for any other part of the
>> system... and all combined in a single system-wide search or segmented as
>> desired.
>>
>> Another big one, that has been most painful for me in dealing with OFBiz,
>> is the lack of consistent scripting and expressions. Once you get used to
>> the elegance of Groovy dealing with BSH and JUEL is downright painful...
>> and for me anyway requires a number of misses before I finally get it
>> working. The ${groovy:...} work-around is there, but quirky, and the
>> resulting object is unreliable as in some OFBiz XML files it results in a
>> String while in others it results in the actual Object the expression
>> evaluates to.
>>
>> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
>> but it needs FAR more modernization than is currently happening or that

is
>> likely to happen. The new feature velocity in the framework is so slow
>> (mostly because of the architecture and existing code, partly because of
>> collaboration breakdown reasons), that it can't keep up with
alternatives.
>>
>> So yes, OFBiz is great, but it exists in a world that is progressing far
>> faster than it can. My reason for starting fresh was just that simple:
>> development velocity.
>>
>> On top of that OFBiz uses certain approaches that are difficult to deploy
>> and maintain. Try dropping all of OFBiz into a single war file for easy
>> upload deployment on the dozens of modern cloud/PaaS services. Try adding
>> plug-ins that require a proper init/destroy lifecycle instead of relying
on
>> static initialization and no proper tear down. Try finding framework
>> functionality in thousands of static methods spread across dozens (or
>> hundreds?) of classes. I know these weaknesses of OFBiz well... they are
my
>> mistakes. Correcting them is another matter... and one I didn't find
>> possible in the context of the project with the limited time I have
>> available. It was faster and easier to start fresh.
>>
>> When I started OFBiz I was 23 years old and had about 2 years of
>> experience in ERP systems. I think it's great that there is enough
interest

>> to keep the project alive and at whatever pace keep it progressing both
>> technically and for support of business activities. Still, something must
>> be done for it to remain competitive with open source and commercial
>> alternatives if it is to compete... including with what I've been calling
>> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
>> Artifacts, and the various projects and products built on them.
>>
>> As good as it is, there is lots of room for improvement and others are
>> doing just that. I don't think Al was implying that "OFBiz is no longer
>> brilliant", maybe some are overly sensitive to that. The fact is that

OFBiz
>> is what it is, and without major improvements alternatives exceed it in
so
>> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
>> bright stars its brilliance is only relevant in context.
>>
>> OFBiz has lots of momentum, and pretty good marketplace around it, and a
>> lot of people are making good money doing work based on it (including
me).
>> Still, I tire frequently of explaining that so many things are known
issues
>> with the project and not easy to correct, but are corrected in the "Next
>> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround
that
>> can't be committed because it breaks other things, just things they don't
>> intend to use (this still has consequences for bigger projects... things
>> all seem to come back around).
>>
>> So, it is what it is. I understand the motivation to paint OFBiz the best
>> possible for marketing purposes and such... I personally did that for
years
>> in spite of known flaws. Eventually that only goes so far... OFBiz versus
>> other open source alternatives has its pluses and minuses, and most in
the
>> community are very aware of those minuses. This causes many to drool over
>> cleaner, newer solutions like Magento, even if it is based on a totally
>> different underlying technology and one that doesn't scale as well or
>> interact in enterprise environments as well.
>>
>> Sooner or later reality catches up... best to stay ahead of it or at
least

>> have long-term plans and alternatives to fall-back on.
>>
>> -David
>>
>>
>> On May 20, 2013, at 11:10 AM, Adrian Crum <
>> [hidden email]> wrote:
>>
>>> A quick clarification on this.
>>>
>>> "OFBiz was brilliant when David created it over ten years ago, but..."
>> implies OFBiz is no longer brilliant. OFBiz continues to be just as
>> brilliant, with a talented team of developers keeping it current with
>> current technology.
>>>
>>> -Adrian
>>>
>>> On 5/20/2013 4:04 PM, Al Byers wrote:
>>>> Hi Carlos,
>>>>
>>>> I am just starting to look around for OFBiz work and was intrigued to
>> see your email there this morning. I have been working with OFBiz for

over
>> 10 years now and am interested in what you have going.
>>>>
>>>> But I must ask if you have considered Moqui (moqui.org <
>> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
>> small conference with David and the folks at HowWax Media and based on
>> David's comments and what I know about Moqui from my past year of working
>> with it, if you are starting anew, and especially if you are not using
the
>> current e-commerce features of OFBiz, then you would be well served to
look
>> at Moqui. OFBiz was brilliant when David created it over ten years ago,
but
>> technology has made great advances in that time and if you have the
freedom

>> to do so, it makes sense to start with the latest base.
>>>>
>>>> I have attached David's introduction to Moqui PDF, which I don't think
>> is readily available off the moqui.org <http://moqui.org> website.
>>>>
>>>> I hope to hear from you soon.
>>>>
>>>> Al Byers
>>>> 801-400-5111
>>>>
>>>>
>>>> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz

<[hidden email]<mailto:

>> [hidden email]>> wrote:
>>>>
>>>>     Hi;
>>>>
>>>>     I'm looking for a Java programmer that is familiar with OFBiz.
>>>>     Particularly with OFBiz Web Services and OFBiz Entity Engine.
>>>>
>>>>     I'm interested in hosting OFBiz for some very specific industries
>>>>     and I want to develop some very specific interfaces.
>>>>
>>>>     This is a long term project, I could be flexible with the hours.
>>>>
>>>>     If you're interested email me for more details.
>>>>
>>>>     Also feel free to forward this email to someone you think might be
>>>>     interested.
>>>>
>>>>     Thanks!!
>>>>
>>>>     Carlos
>>>>
>>>>     logo-for-social-media-sites-email_signature
>>>>
>>>>     CruzControl Radius
>>>>
>>>>     Your Success Is Our Service
>>>>
>>>>     www.ccradius.com <http://www.ccradius.com>
>>>>
>>>>     email:[hidden email] <mailto:email%[hidden email]>
>>>>
>>>>     1-877-285-5499 <tel:[phone]>
>>>>
>>>>
>>>
>>
>>
>

[byersa]

Skip, most of what you say, I will let stand as your two cents, but one
piece of misinformation should be corrected: no one is proposing that we
abandon all the years of work that that have gone into OFBiz and start from
scratch. Moqui was designed by the creator of OFBiz to allow as painless
migration as possible - though somethings have to change or there would be
no reason for making the switch. Just how painful the migration would be
would take some time to predict.


On Fri, Mar 7, 2014 at 2:58 PM, Skip <[hidden email]> wrote:

> I am sure Moqui is a fine framework, but I must agree with Adrian.  Yes,
> lets all just abandon hundreds of man-years of work and start from scratch.
> I don't know about most of you, but I derive most of my income servicing
> EXISTING Ofbiz derived works.
>
> Specifically, I take issue with the following from Al:
>
> 1.  "It is not reasonable to think that we can keep scaling the original
> framework." --- Bullxxxx.  Ofbiz (or derivitives) is used by many LARGE
> companies and scaling does not seem to be an issue.  Furthermore, Ofbiz is
> mostly used by smallish companies where scale is not an issue.
>
> 2.  "I don't know exactly how the transition to Moqui should take place,
> but
> that is where the discussion should take place."  -- There should be no
> transition to Moqui IMHO.  Ofbiz is terrific.
>
> 3.  Ofbiz will never be a slowly sinking ship.  Go to the Moqui web site
> and
> you will read "Ofbiz...reused and built on to create thousands of custom
> systems and dozens of open source and commercial derivative works."  This
> does not sound like a ship that is going to sink any time soon.
>
> 4.  JSON-RPC, REST, JSON in general, and ElasticSearch I think might have
> general value to the community, but REST can be done now with JSON (in
> custom URLs) and solr is also implemented in a JIRA and by BigFish.  All of
> this can be implemented inside Ofbiz, Moqui is not required.
>
> Just my two cents.
>
> Skip
>
> -----Original Message-----
> From: Adrian Crum [mailto:[hidden email]]
> Sent: Friday, March 07, 2014 7:24 AM
> To: [hidden email]
> Subject: Re: Reposting from David Jones on Moqui
>
>
> Switching OFBiz to a different framework has been discussed in the past,
> and I brought up the subject again in a recent thread on the dev mailing
> list. At this time, there are some PMC members who are opposed to the
> idea, so I don't see any hope for switching to Moqui in this project.
>
> If anyone is interested in building applications on Moqui, then they
> should do it in the Moqui community.
>
> I don't agree that OFBiz is a sinking ship. There are a number of
> service providers who are heavily invested in this project, and they are
> not going to throw that all away for a new one.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 3/7/2014 5:58 AM, Al Byers wrote:
> > In light of the current discussion about the future of OFBiz I thought it
> > would be worth revisiting one of my finer moments by reposting this from
> > David Jones. In today's world 12 technology years is a lifetime. It is
> not
> > reasonable to think that we can keep scaling the original framework.
> > Another thing to think about is that in order to attract a new group of
> > users sometimes it takes a big new idea and Moqui fills that role. We
> > should all keep in mind that OFBiz succeeded secondly because of all the
> > hard work put in by the community, but firstly because of the brilliant
> > architecture and foundation provided by David (and Andrew). When that
> same
> > mind applies it to fixing most of OFBiz's problems we should be talking
> > about how to transition - end of discussion, IMHO.
> >
> > I believe that it has been since David wrote this email that he has
> > integrated Elasticsearch and Drools into Moqui. Those are the kinds of
> > exciting technologies that OFBiz needs. And it is high time that we
> stopped
> > programming in Java. I have loved the seemless transition to Groovy and I
> > like having only one scripting language. The future is going to demand
> much
> > more flexibility than OFBiz can deliver. Moqui, with its small core size
> > and its application of FreeMarker to the frontend provides that
> flexibility.
> >
> > I don't know exactly how the transition to Moqui should take place, but
> > that is where the discussion should take place. Anything else, and we are
> > just discussing how slowly the ship will be sinking. I think David should
> > remain in control of the core (as I think he would insist), but there are
> a
> > lot of options for porting the mantle and crust portions. I think we
> should
> > think outside the box and look to something like KickStarter to get it
> done
> > quickly.
> >
> > -Al
> >
> > On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:
> >
> >>
> >> OFBiz has recently turned 12 years old. At the time it was written many
> >> more modern libraries either didn't exist or were not usable, including:
> >>
> >> - Groovy
> >> - ehcache
> >> - Quartz Scheduler
> >> - Atomikos
> >> - JackRabbit (and JCR in general)
> >> - Shiro
> >> - Camel
> >> - JSON-RPC, REST, JSON in general
> >> - ElasticSearch (and to some extent even Lucene)
> >> - Document and other NoSQL databases (of which ElasticSearch is sort of,
> >> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
> >>
> >> Some of these are used, or with some customization usable, in OFBiz.
> Many
> >> of them overlap a lot with parts of the OFBiz framework, and unlike
> >> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
> >>
> >> Some big ones are caching, job scheduling, content management, and even
> >> searching. The OFBiz ProductSearch stuff works well enough (though not
> >> great) for smaller sets of products, but doesn't compare in flexibility,
> >> scalability, and speed to ElasticSearch and some other Lucene-based
> >> alternatives. With some simple framework extensions (like the
> DataDocument,
> >> DataFeed, and DataSearch features of Moqui) implementing excellent
> search
> >> for products would be easy, as would search for any other part of the
> >> system... and all combined in a single system-wide search or segmented
> as
> >> desired.
> >>
> >> Another big one, that has been most painful for me in dealing with
> OFBiz,
> >> is the lack of consistent scripting and expressions. Once you get used
> to
> >> the elegance of Groovy dealing with BSH and JUEL is downright painful...
> >> and for me anyway requires a number of misses before I finally get it
> >> working. The ${groovy:...} work-around is there, but quirky, and the
> >> resulting object is unreliable as in some OFBiz XML files it results in
> a
> >> String while in others it results in the actual Object the expression
> >> evaluates to.
> >>
> >> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
> >> but it needs FAR more modernization than is currently happening or that
> is
> >> likely to happen. The new feature velocity in the framework is so slow
> >> (mostly because of the architecture and existing code, partly because of
> >> collaboration breakdown reasons), that it can't keep up with
> alternatives.
> >>
> >> So yes, OFBiz is great, but it exists in a world that is progressing far
> >> faster than it can. My reason for starting fresh was just that simple:
> >> development velocity.
> >>
> >> On top of that OFBiz uses certain approaches that are difficult to
> deploy
> >> and maintain. Try dropping all of OFBiz into a single war file for easy
> >> upload deployment on the dozens of modern cloud/PaaS services. Try
> adding
> >> plug-ins that require a proper init/destroy lifecycle instead of relying
> on
> >> static initialization and no proper tear down. Try finding framework
> >> functionality in thousands of static methods spread across dozens (or
> >> hundreds?) of classes. I know these weaknesses of OFBiz well... they are
> my
> >> mistakes. Correcting them is another matter... and one I didn't find
> >> possible in the context of the project with the limited time I have
> >> available. It was faster and easier to start fresh.
> >>
> >> When I started OFBiz I was 23 years old and had about 2 years of
> >> experience in ERP systems. I think it's great that there is enough
> interest
> >> to keep the project alive and at whatever pace keep it progressing both
> >> technically and for support of business activities. Still, something
> must
> >> be done for it to remain competitive with open source and commercial
> >> alternatives if it is to compete... including with what I've been
> calling
> >> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
> >> Artifacts, and the various projects and products built on them.
> >>
> >> As good as it is, there is lots of room for improvement and others are
> >> doing just that. I don't think Al was implying that "OFBiz is no longer
> >> brilliant", maybe some are overly sensitive to that. The fact is that
> OFBiz
> >> is what it is, and without major improvements alternatives exceed it in
> so
> >> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
> >> bright stars its brilliance is only relevant in context.
> >>
> >> OFBiz has lots of momentum, and pretty good marketplace around it, and a
> >> lot of people are making good money doing work based on it (including
> me).
> >> Still, I tire frequently of explaining that so many things are known
> issues
> >> with the project and not easy to correct, but are corrected in the "Next
> >> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround
> that
> >> can't be committed because it breaks other things, just things they
> don't
> >> intend to use (this still has consequences for bigger projects... things
> >> all seem to come back around).
> >>
> >> So, it is what it is. I understand the motivation to paint OFBiz the
> best
> >> possible for marketing purposes and such... I personally did that for
> years
> >> in spite of known flaws. Eventually that only goes so far... OFBiz
> versus
> >> other open source alternatives has its pluses and minuses, and most in
> the
> >> community are very aware of those minuses. This causes many to drool
> over
> >> cleaner, newer solutions like Magento, even if it is based on a totally
> >> different underlying technology and one that doesn't scale as well or
> >> interact in enterprise environments as well.
> >>
> >> Sooner or later reality catches up... best to stay ahead of it or at
> least
> >> have long-term plans and alternatives to fall-back on.
> >>
> >> -David
> >>
> >>
> >> On May 20, 2013, at 11:10 AM, Adrian Crum <
> >> [hidden email]> wrote:
> >>
> >>> A quick clarification on this.
> >>>
> >>> "OFBiz was brilliant when David created it over ten years ago, but..."
> >> implies OFBiz is no longer brilliant. OFBiz continues to be just as
> >> brilliant, with a talented team of developers keeping it current with
> >> current technology.
> >>>
> >>> -Adrian
> >>>
> >>> On 5/20/2013 4:04 PM, Al Byers wrote:
> >>>> Hi Carlos,
> >>>>
> >>>> I am just starting to look around for OFBiz work and was intrigued to
> >> see your email there this morning. I have been working with OFBiz for
> over
> >> 10 years now and am interested in what you have going.
> >>>>
> >>>> But I must ask if you have considered Moqui (moqui.org <
> >> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
> >> small conference with David and the folks at HowWax Media and based on
> >> David's comments and what I know about Moqui from my past year of
> working
> >> with it, if you are starting anew, and especially if you are not using
> the
> >> current e-commerce features of OFBiz, then you would be well served to
> look
> >> at Moqui. OFBiz was brilliant when David created it over ten years ago,
> but
> >> technology has made great advances in that time and if you have the
> freedom
> >> to do so, it makes sense to start with the latest base.
> >>>>
> >>>> I have attached David's introduction to Moqui PDF, which I don't think
> >> is readily available off the moqui.org <http://moqui.org> website.
> >>>>
> >>>> I hope to hear from you soon.
> >>>>
> >>>> Al Byers
> >>>> 801-400-5111
> >>>>
> >>>>
> >>>> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz
> <[hidden email]<mailto:
> >> [hidden email]>> wrote:
> >>>>
> >>>>     Hi;
> >>>>
> >>>>     I'm looking for a Java programmer that is familiar with OFBiz.
> >>>>     Particularly with OFBiz Web Services and OFBiz Entity Engine.
> >>>>
> >>>>     I'm interested in hosting OFBiz for some very specific industries
> >>>>     and I want to develop some very specific interfaces.
> >>>>
> >>>>     This is a long term project, I could be flexible with the hours.
> >>>>
> >>>>     If you're interested email me for more details.
> >>>>
> >>>>     Also feel free to forward this email to someone you think might be
> >>>>     interested.
> >>>>
> >>>>     Thanks!!
> >>>>
> >>>>     Carlos
> >>>>
> >>>>     logo-for-social-media-sites-email_signature
> >>>>
> >>>>     CruzControl Radius
> >>>>
> >>>>     Your Success Is Our Service
> >>>>
> >>>>     www.ccradius.com <http://www.ccradius.com>
> >>>>
> >>>>     email:[hidden email] <mailto:email%[hidden email]>
> >>>>
> >>>>     1-877-285-5499 <tel:[phone]>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>

[Adrian Crum-3]

Maybe we should separate passionate hyperbole from facts.

There is no "old technology" in OFBiz. We keep the project up to date
with the latest libraries. The project has always supported
user-replaceable components, so if a portion of the OFBiz framework
doesn't meet your needs, then you are free to replace it with something
else.

There is nothing new or revolutionary about Moqui. Basically, it is a
rewrite of the OFBiz framework, and unfortunately it has duplicated some
of the problems we have been solving recently in OFBiz.

You mentioned one advantage of using Moqui is the ability to use Groovy
scripts instead of Java - OFBiz has had that capability for years. Not
only that, you requested server-side JavaScript some years ago and I
added that too. You also mentioned Moqui using FreeMarker on the front
end - OFBiz has been using FreeMarker for years.

I could go on, but the basic point I am trying to make is this: Moqui is
different than OFBiz, but it isn't necessarily better.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 3/7/2014 8:12 AM, Al Byers wrote:

> Adrian, I think that you have summed up the situation in your succinct post
> - there are some service providers who are heavily invested in this project
> and it is their concern for their own interests that is  guiding OFBiz.
> Someone new looking at OFBiz should lament the fact that so much
> application value is tied to such old technology. Then they should look at
> Moqui and see how easy it would be to port that value to a new platform -
> at least much easier than creating a new framework - and wonder why it is
> not being done.
>
> I reject the idea that "anyone is interested in building applications on
> Moqui, [...]should do it in the Moqui community". OFBiz does not belong to
> the PMC; it belongs to everybody. I have a dream... sorry, got carried
> away. This seems like a test of the Apache framework - does it provide for
> the long-term life of a project when it conflicts with the self-interests
> of the PMC?
>
>
> On Fri, Mar 7, 2014 at 10:24 AM, Adrian Crum <
> [hidden email]> wrote:
>
>> Switching OFBiz to a different framework has been discussed in the past,
>> and I brought up the subject again in a recent thread on the dev mailing
>> list. At this time, there are some PMC members who are opposed to the idea,
>> so I don't see any hope for switching to Moqui in this project.
>>
>> If anyone is interested in building applications on Moqui, then they
>> should do it in the Moqui community.
>>
>> I don't agree that OFBiz is a sinking ship. There are a number of service
>> providers who are heavily invested in this project, and they are not going
>> to throw that all away for a new one.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>>
>> On 3/7/2014 5:58 AM, Al Byers wrote:
>>
>>> In light of the current discussion about the future of OFBiz I thought it
>>> would be worth revisiting one of my finer moments by reposting this from
>>> David Jones. In today's world 12 technology years is a lifetime. It is not
>>> reasonable to think that we can keep scaling the original framework.
>>> Another thing to think about is that in order to attract a new group of
>>> users sometimes it takes a big new idea and Moqui fills that role. We
>>> should all keep in mind that OFBiz succeeded secondly because of all the
>>> hard work put in by the community, but firstly because of the brilliant
>>> architecture and foundation provided by David (and Andrew). When that same
>>> mind applies it to fixing most of OFBiz's problems we should be talking
>>> about how to transition - end of discussion, IMHO.
>>>
>>> I believe that it has been since David wrote this email that he has
>>> integrated Elasticsearch and Drools into Moqui. Those are the kinds of
>>> exciting technologies that OFBiz needs. And it is high time that we
>>> stopped
>>> programming in Java. I have loved the seemless transition to Groovy and I
>>> like having only one scripting language. The future is going to demand
>>> much
>>> more flexibility than OFBiz can deliver. Moqui, with its small core size
>>> and its application of FreeMarker to the frontend provides that
>>> flexibility.
>>>
>>> I don't know exactly how the transition to Moqui should take place, but
>>> that is where the discussion should take place. Anything else, and we are
>>> just discussing how slowly the ship will be sinking. I think David should
>>> remain in control of the core (as I think he would insist), but there are
>>> a
>>> lot of options for porting the mantle and crust portions. I think we
>>> should
>>> think outside the box and look to something like KickStarter to get it
>>> done
>>> quickly.
>>>
>>> -Al
>>>
>>> On Wed, May 22, 2013 at 2:26 PM, David E. Jones <[hidden email]> wrote:
>>>
>>>
>>>> OFBiz has recently turned 12 years old. At the time it was written many
>>>> more modern libraries either didn't exist or were not usable, including:
>>>>
>>>> - Groovy
>>>> - ehcache
>>>> - Quartz Scheduler
>>>> - Atomikos
>>>> - JackRabbit (and JCR in general)
>>>> - Shiro
>>>> - Camel
>>>> - JSON-RPC, REST, JSON in general
>>>> - ElasticSearch (and to some extent even Lucene)
>>>> - Document and other NoSQL databases (of which ElasticSearch is sort of,
>>>> but I mean CouchDB, MongoDB, Hadoop and derivatives, etc)
>>>>
>>>> Some of these are used, or with some customization usable, in OFBiz. Many
>>>> of them overlap a lot with parts of the OFBiz framework, and unlike
>>>> JPA/Hibernate sorts of things, do a better job than what is in OFBiz.
>>>>
>>>> Some big ones are caching, job scheduling, content management, and even
>>>> searching. The OFBiz ProductSearch stuff works well enough (though not
>>>> great) for smaller sets of products, but doesn't compare in flexibility,
>>>> scalability, and speed to ElasticSearch and some other Lucene-based
>>>> alternatives. With some simple framework extensions (like the
>>>> DataDocument,
>>>> DataFeed, and DataSearch features of Moqui) implementing excellent search
>>>> for products would be easy, as would search for any other part of the
>>>> system... and all combined in a single system-wide search or segmented as
>>>> desired.
>>>>
>>>> Another big one, that has been most painful for me in dealing with OFBiz,
>>>> is the lack of consistent scripting and expressions. Once you get used to
>>>> the elegance of Groovy dealing with BSH and JUEL is downright painful...
>>>> and for me anyway requires a number of misses before I finally get it
>>>> working. The ${groovy:...} work-around is there, but quirky, and the
>>>> resulting object is unreliable as in some OFBiz XML files it results in a
>>>> String while in others it results in the actual Object the expression
>>>> evaluates to.
>>>>
>>>> Even if it is self-serving, I agree that OFBiz was brilliant in its day,
>>>> but it needs FAR more modernization than is currently happening or that
>>>> is
>>>> likely to happen. The new feature velocity in the framework is so slow
>>>> (mostly because of the architecture and existing code, partly because of
>>>> collaboration breakdown reasons), that it can't keep up with
>>>> alternatives.
>>>>
>>>> So yes, OFBiz is great, but it exists in a world that is progressing far
>>>> faster than it can. My reason for starting fresh was just that simple:
>>>> development velocity.
>>>>
>>>> On top of that OFBiz uses certain approaches that are difficult to deploy
>>>> and maintain. Try dropping all of OFBiz into a single war file for easy
>>>> upload deployment on the dozens of modern cloud/PaaS services. Try adding
>>>> plug-ins that require a proper init/destroy lifecycle instead of relying
>>>> on
>>>> static initialization and no proper tear down. Try finding framework
>>>> functionality in thousands of static methods spread across dozens (or
>>>> hundreds?) of classes. I know these weaknesses of OFBiz well... they are
>>>> my
>>>> mistakes. Correcting them is another matter... and one I didn't find
>>>> possible in the context of the project with the limited time I have
>>>> available. It was faster and easier to start fresh.
>>>>
>>>> When I started OFBiz I was 23 years old and had about 2 years of
>>>> experience in ERP systems. I think it's great that there is enough
>>>> interest
>>>> to keep the project alive and at whatever pace keep it progressing both
>>>> technically and for support of business activities. Still, something must
>>>> be done for it to remain competitive with open source and commercial
>>>> alternatives if it is to compete... including with what I've been calling
>>>> the "Next Generation" of OFBiz, ie Moqui Framework, Mantle Business
>>>> Artifacts, and the various projects and products built on them.
>>>>
>>>> As good as it is, there is lots of room for improvement and others are
>>>> doing just that. I don't think Al was implying that "OFBiz is no longer
>>>> brilliant", maybe some are overly sensitive to that. The fact is that
>>>> OFBiz
>>>> is what it is, and without major improvements alternatives exceed it in
>>>> so
>>>> many ways. It doesn't make OFBiz less brilliant, but in a sky with other
>>>> bright stars its brilliance is only relevant in context.
>>>>
>>>> OFBiz has lots of momentum, and pretty good marketplace around it, and a
>>>> lot of people are making good money doing work based on it (including
>>>> me).
>>>> Still, I tire frequently of explaining that so many things are known
>>>> issues
>>>> with the project and not easy to correct, but are corrected in the "Next
>>>> Generation", ie Moqui/Mantle. Usually the fix is a hack and workaround
>>>> that
>>>> can't be committed because it breaks other things, just things they don't
>>>> intend to use (this still has consequences for bigger projects... things
>>>> all seem to come back around).
>>>>
>>>> So, it is what it is. I understand the motivation to paint OFBiz the best
>>>> possible for marketing purposes and such... I personally did that for
>>>> years
>>>> in spite of known flaws. Eventually that only goes so far... OFBiz versus
>>>> other open source alternatives has its pluses and minuses, and most in
>>>> the
>>>> community are very aware of those minuses. This causes many to drool over
>>>> cleaner, newer solutions like Magento, even if it is based on a totally
>>>> different underlying technology and one that doesn't scale as well or
>>>> interact in enterprise environments as well.
>>>>
>>>> Sooner or later reality catches up... best to stay ahead of it or at
>>>> least
>>>> have long-term plans and alternatives to fall-back on.
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 20, 2013, at 11:10 AM, Adrian Crum <
>>>> [hidden email]> wrote:
>>>>
>>>>   A quick clarification on this.
>>>>>
>>>>> "OFBiz was brilliant when David created it over ten years ago, but..."
>>>>>
>>>> implies OFBiz is no longer brilliant. OFBiz continues to be just as
>>>> brilliant, with a talented team of developers keeping it current with
>>>> current technology.
>>>>
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 5/20/2013 4:04 PM, Al Byers wrote:
>>>>>
>>>>>> Hi Carlos,
>>>>>>
>>>>>> I am just starting to look around for OFBiz work and was intrigued to
>>>>>>
>>>>> see your email there this morning. I have been working with OFBiz for
>>>> over
>>>> 10 years now and am interested in what you have going.
>>>>
>>>>>
>>>>>> But I must ask if you have considered Moqui (moqui.org <
>>>>>>
>>>>> http://moqui.org>) - David Jones's successor to OFBiz? I was just at a
>>>> small conference with David and the folks at HowWax Media and based on
>>>> David's comments and what I know about Moqui from my past year of working
>>>> with it, if you are starting anew, and especially if you are not using
>>>> the
>>>> current e-commerce features of OFBiz, then you would be well served to
>>>> look
>>>> at Moqui. OFBiz was brilliant when David created it over ten years ago,
>>>> but
>>>> technology has made great advances in that time and if you have the
>>>> freedom
>>>> to do so, it makes sense to start with the latest base.
>>>>
>>>>>
>>>>>> I have attached David's introduction to Moqui PDF, which I don't think
>>>>>>
>>>>> is readily available off the moqui.org <http://moqui.org> website.
>>>>
>>>>>
>>>>>> I hope to hear from you soon.
>>>>>>
>>>>>> Al Byers
>>>>>> 801-400-5111
>>>>>>
>>>>>>
>>>>>> On Mon, May 20, 2013 at 7:19 AM, Carlos Cruz <[hidden email]
>>>>>> <mailto:
>>>>>>
>>>>> [hidden email]>> wrote:
>>>>
>>>>>
>>>>>>      Hi;
>>>>>>
>>>>>>      I'm looking for a Java programmer that is familiar with OFBiz.
>>>>>>      Particularly with OFBiz Web Services and OFBiz Entity Engine.
>>>>>>
>>>>>>      I'm interested in hosting OFBiz for some very specific industries
>>>>>>      and I want to develop some very specific interfaces.
>>>>>>
>>>>>>      This is a long term project, I could be flexible with the hours.
>>>>>>
>>>>>>      If you're interested email me for more details.
>>>>>>
>>>>>>      Also feel free to forward this email to someone you think might be
>>>>>>      interested.
>>>>>>
>>>>>>      Thanks!!
>>>>>>
>>>>>>      Carlos
>>>>>>
>>>>>>      logo-for-social-media-sites-email_signature
>>>>>>
>>>>>>      CruzControl Radius
>>>>>>
>>>>>>      Your Success Is Our Service
>>>>>>
>>>>>>      www.ccradius.com <http://www.ccradius.com>
>>>>>>
>>>>>>      email:[hidden email] <mailto:email%[hidden email]>
>>>>>>
>>>>>>      1-877-285-5499 <tel:[phone]>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>

[Adrian Crum-3]

On 3/7/2014 11:58 AM, Skip wrote:

> I am sure Moqui is a fine framework, but I must agree with Adrian.  Yes,
> lets all just abandon hundreds of man-years of work and start from scratch.
> I don't know about most of you, but I derive most of my income servicing
> EXISTING Ofbiz derived works.
>
> Specifically, I take issue with the following from Al:
>
> 1.  "It is not reasonable to think that we can keep scaling the original
> framework." --- Bullxxxx.  Ofbiz (or derivitives) is used by many LARGE
> companies and scaling does not seem to be an issue.  Furthermore, Ofbiz is
> mostly used by smallish companies where scale is not an issue.

 From a developer's perspective, OFBiz is in some ways more scalable
than Moqui. I'm going to give an arcane example, but I think it
illustrates well why I am not enthusiastic about switching to Moqui.

Some years ago I introduced a new data type in the OFBiz framework -
TimeDuration. Getting that new data type integrated into the framework
was a huge problem, because there are many places in the framework where
data type conversion is needed, and in all those places there were long
switch statements. Every one of those switch statements needed to be
modified to accommodate the new data type. Worse, not all of the switch
statements were the same - so the existing data type conversion was
inconsistent.

So, I created a flexible, expandable data conversion framework that
makes it easy to introduce new data types into the project - without the
need to modify the framework code. I replaced all of the switch
statements with calls to the conversion framework. Now users can create
their own data types and add them into the conversion framework easily.

How does Moqui handle data conversion? Multiple switch statements. So, a
scalability problem that was solved in OFBiz was duplicated in Moqui.

-Adrian

[Todd Thorner]

Cool, thanks for the information and for the framework contribution.
One thing I do like is Moqui's public domain non-license arrangement
with potential users (my opinion is that IP stands for Imaginary
Property).  If that project wanted to use your type conversion framework
(or anything else from the OFBiz project), they would need to include a
copy of the Apache License over there too, right?

That would, of course, destroy their vision of having a project
unencumbered by any IP legalese.  I think I'd rather see them write
their own framework from scratch (more duplication of effort of course
but that was always their call to make).

I'm hoping the ASF will release all projects into the public domain.



On 14-03-07 01:58 PM, Adrian Crum wrote:

> On 3/7/2014 11:58 AM, Skip wrote:
>> I am sure Moqui is a fine framework, but I must agree with Adrian.  Yes,
>> lets all just abandon hundreds of man-years of work and start from
>> scratch.
>> I don't know about most of you, but I derive most of my income servicing
>> EXISTING Ofbiz derived works.
>>
>> Specifically, I take issue with the following from Al:
>>
>> 1.  "It is not reasonable to think that we can keep scaling the original
>> framework." --- Bullxxxx.  Ofbiz (or derivitives) is used by many LARGE
>> companies and scaling does not seem to be an issue.  Furthermore,
>> Ofbiz is
>> mostly used by smallish companies where scale is not an issue.
>
> From a developer's perspective, OFBiz is in some ways more scalable than
> Moqui. I'm going to give an arcane example, but I think it illustrates
> well why I am not enthusiastic about switching to Moqui.
>
> Some years ago I introduced a new data type in the OFBiz framework -
> TimeDuration. Getting that new data type integrated into the framework
> was a huge problem, because there are many places in the framework where
> data type conversion is needed, and in all those places there were long
> switch statements. Every one of those switch statements needed to be
> modified to accommodate the new data type. Worse, not all of the switch
> statements were the same - so the existing data type conversion was
> inconsistent.
>
> So, I created a flexible, expandable data conversion framework that
> makes it easy to introduce new data types into the project - without the
> need to modify the framework code. I replaced all of the switch
> statements with calls to the conversion framework. Now users can create
> their own data types and add them into the conversion framework easily.
>
> How does Moqui handle data conversion? Multiple switch statements. So, a
> scalability problem that was solved in OFBiz was duplicated in Moqui.
>
> -Adrian

[Ejaz Ahmed]

Adrian,

Just few questions from your earlier emails in developer mailing list:

>My preference would be to create a branch and start building things out
>there - with the help of others. The goal would be to start over from
>scratch - using sound design principles and the lessons learned from the
>current code.

If ofbiz is so much scalable and up to date with technology, why do you want start
rebasing such a stable and well proven software to something which is yet to be developed
and that too from scratch.

By the way, if you make this branch and start building OFBIZ on top of Moqui, I will be much happy.
Same was suggested by Piere Smits on dev mailing list and Al will also be happy with it.

>If there is support for this effort, then I can begin working on it in
>February. If not, then I will most likely start a separate project -
>similar to the approach taken by Moqui.

If you are so much impressed by Moqui's approach, then why don't you want to join hands with
David and address all those issue which you think are copied from ofbiz. There are so many
people out there who think Moqui is the right choice.

>Moqui copies problems from our existing framework, I want to fix them.
David might not have done this intentionally, but no one will stop you fixing those in Moqui instead of
starting a new framework from scratch.
>Therefore, I have to come to the same conclusion David did: Innovation
>is impossible in this community, so it needs to be done somewhere else.

You argue that innovation is impossible in this community but still oppose the fact that ofbiz is a sinking ship.

It would be a great loss for the community if you too follow the David's approach
of leaving this community. If this happens, ofbiz will surely be a sinking ship.




Regards:

Ejaz Ahmed


     

[Adrian Crum-3]

On 3/7/2014 11:24 PM, Ejaz Ahmed wrote:

> Adrian,
>
> Just few questions from your earlier emails in developer mailing list:
>
>> My preference would be to create a branch and start building things out
>> there - with the help of others. The goal would be to start over from
>> scratch - using sound design principles and the lessons learned from the
>> current code.
>
> If ofbiz is so much scalable and up to date with technology, why do you want start
> rebasing such a stable and well proven software to something which is yet to be developed
> and that too from scratch.

Some things cannot be fixed with small modifications. One example:

https://issues.apache.org/jira/browse/OFBIZ-5534

will require a rewrite. In addition, OFBiz cannot use multi-threaded
code due to the transaction handling design. Changing that design could
improve performance significantly. There are other problems with the
current transaction handling design:

https://issues.apache.org/jira/browse/OFBIZ-1029

read the excellent PDF attachment.

There are other reasons that were referenced in the original email.

>
> By the way, if you make this branch and start building OFBIZ on top of Moqui, I will be much happy.
> Same was suggested by Piere Smits on dev mailing list and Al will also be happy with it.
>
>> If there is support for this effort, then I can begin working on it in
>> February. If not, then I will most likely start a separate project -
>> similar to the approach taken by Moqui.
>
> If you are so much impressed by Moqui's approach, then why don't you want to join hands with
> David and address all those issue which you think are copied from ofbiz. There are so many
> people out there who think Moqui is the right choice.

I didn't say I was impressed by Moqui's approach. I said I will spin off
a separate project the way Moqui did.

I will support an effort to switch to Moqui if anyone wants to work on
it. My preference is for us to build our own framework. I believe our
combined experience will produce a superior product.

>
>> Moqui copies problems from our existing framework, I want to fix them.
> David might not have done this intentionally, but no one will stop you fixing those in Moqui instead of
> starting a new framework from scratch.
>> Therefore, I have to come to the same conclusion David did: Innovation
>> is impossible in this community, so it needs to be done somewhere else.
>
> You argue that innovation is impossible in this community but still oppose the fact that ofbiz is a sinking ship.
>
> It would be a great loss for the community if you too follow the David's approach
> of leaving this community. If this happens, ofbiz will surely be a sinking ship.

I don't agree. Over the years, many key players have left the OFBiz
developer community, and it still marches on.


Adrian Crum
Sandglass Software
www.sandglass-software.com

[Pierre Smits]

Ejaz,

You inadvertedly, and probably unintentionally, misinterpreted my postings
in the mail thread regarding the framework refactoring as an endorsement to
change over to Moqui.

Please reread the thread to get your fact straightened. See
http://ofbiz.135035.n4.nabble.com/Framework-Refactor-Revisited-td4647362.html#a4647384

Regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Paul Piper]

I have to second Adrian's opinion on this:

From my perspective Moqui is a rather lost cause. Not because I am not impressed by David's work, but rather because it is years away from becoming an actual thing. From an industry perspective it is difficult if not almost impossible to implement an ERP framework to begin with. OFBiz is a marvelous thing in that extend as that it managed to actually become feature complete. It is, however, an exception and not the rule. Any new "framework" would require a huge amount of either time or money, and frankly Moqui won't be heading there.

Again: this doesn't take away anything from David's accomplishments, but if you want my personal two cents on this - ofbiz is what you are looking for.

[Mike Z]

I agree and disagree.  If anyone could create a full blown ERP using Moqui,
David could do it.  After all he has already managed to do it once, but
yes, it is (probably) years away.  However, I have no idea of it's current
state.

Regarding the current imperfections of OFBIZ:  All large software projects
have hacks and shortcuts built-in.  I bet SAP has thousands of hacks that
the original designers wish were not there, but are now so ingrained into
the framework they are impossible to change.  For me the biggest question
is "does it work"?  OFBIZ already seems to.  Good enough.


On Sun, Mar 9, 2014 at 6:42 AM, Paul Piper <[hidden email]> wrote:

> I have to second Adrian's opinion on this:
>
> From my perspective Moqui is a rather lost cause. Not because I am not
> impressed by David's work, but rather because it is years away from
> becoming
> an actual thing. From an industry perspective it is difficult if not almost
> impossible to implement an ERP framework to begin with. OFBiz is a
> marvelous
> thing in that extend as that it managed to actually become feature
> complete.
> It is, however, an exception and not the rule. Any new "framework" would
> require a huge amount of either time or money, and frankly Moqui won't be
> heading there.
>
> Again: this doesn't take away anything from David's accomplishments, but if
> you want my personal two cents on this - ofbiz is what you are looking for.
>
>
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/Reposting-from-David-Jones-on-Moqui-tp4648884p4648953.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

[David E. Jones-2]

ERP systems are complex, but implementations are often large and complex mostly due to inadequate tools and practices, and generally poor organization, resulting in large volume of code that is highly redundant and inflexible. It doesn't HAVE to be this way, it just usually is.

If the discussion of Moqui in the context of OFBiz is the framework (toolset), then Moqui Framework is already far more advanced than the OFBiz framework. That has been true since late 2012, and Moqui Framework has still progressed quite a bit since then. The Moqui Framework code is also only about 15% of the size of the OFBiz Framework code. There are many reasons for this including a well defined and minimally redundant API (using DSL style classes in many places), implementation in Groovy instead of Java, and extensive use of existing open source libraries.

On the business level the Moqui Ecosystem is structured different from OFBiz. Instead of a single project there is a framework project, a business artifacts project (with entities and services, no UI), and then an ecosystem of projects based on them. The Mantle Business Artifacts project, even just comparing to the services in OFBiz, does not have as much functionality as OFBiz. The existing applications based on Moqui are also not nearly as extensive as those in and based on OFBiz.

For those who don't believe that this can be done quickly and efficiently, development in this area only really got started in late 2012 in the Moqui Ecosystem. The initial functionality was focused on basic order placement (with a simple UI in the POP Commerce application), and more extensive end-to-end project management and billing (in the HiveMind PM app). End-to-end order processing functionality including shipping, invoicing, payments, inventory, and accounting/GL were implemented in around 60 days when I finally had space to work on it nearly full-time as opposed to occasional part-time efforts before. This can be done quickly with good tools, good design, and well structured, flexible code.

The current functionality in Mantle Business Artifacts (with various end-to-end automated tests that are also a good reference of some of the high-level services and the resulting database records) are summarized here:

http://www.moqui.org/mantle.html

Most of this was finished in late 2013, and there are already a couple of custom ERP systems for specific industries (that I'm aware of...) based on these that are nearly to the end of initial development and ready for deployment. On the open source front the most extensive application is the HiveMind Project Manager, which was an interesting initial focus as it is something never really done completely in OFBiz. It addresses general needs of services organizations and includes project/task, request, and content (wiki) management with support for multiple vendors, multiple clients, flexible billing rates, time recording, expenses, invoicing, payments, and general ledger. More details and releases are available here:

https://github.com/jonesde/HiveMind

This wasn't true a year ago, but right now I would recommend that clients use Moqui instead of OFBiz whenever extensive customizations are needed and the plan is to build a complete UI anyway. Most larger projects based on OFBiz are in that category, including nearly all of the OFBiz projects I have consulted on over the past 3 years. That said, I should also say that until this year most of my consulting work was based on OFBiz, including various multi-million dollar custom ecommerce and ERP projects.

As far as general velocity and future potential, things are already moving quickly and just getting to a point where the ecosystem structure will become more important and allow things to grow very quickly. The general idea is instead of a single project with various groups compromising over functionality there is an ecosystem of complementary and competing open source projects and commercial products. This allows as many people to get involved as want to with no stepping on toes. With a common framework and foundational business artifacts these are implicitly integrated (as much as app developers follow existing patterns and use existing services), and the opportunity for various user interfaces focused on different industries and organization sizes. Being business process and target user specific these are also much more usable OOTB, and still customizable given the toolset and foundation business artifacts they are built on.

Lost cause and not heading there? Hardly. The current market environment is FAR more difficult than when OFBiz started. There is much more competition and many more open source alternatives. When OFBiz was started just being an open source eCommerce and ERP system, even with pretty basic and poorly implemented functionality, it got huge interest. I spoke at all sorts of conferences and landed all sorts of contracts just because of the novelty of the thing. It's really quite a wild story, and I feel lucky to have been a part of it. That just isn't enough to be interesting any more. Even still, the Moqui Ecosystem projects are far further along that OFBiz was 3 years in, and in spite of few contributors and users, the software itself is advancing at a faster pace.

Could OFBiz (both the software and ecosystem) be restructured and organized differently to leap forward even more? Probably so. I've already communicated the reasons that I chose to do these as separate projects with a clean rewrite of everything (no code at all comes from OFBiz), but others could choose a different path and perhaps do just as well... and the existing framework and functionality in OFBiz could perhaps be cleaned up enough to act as the same sort of foundation for growth.

I am not writing this to try to recruit Moqui contributors and users from the OFBiz community. To date that hasn't happened anyway and I don't know that it will very much. OFBiz is still a good system and many contributors and users already have a lot of momentum with it. Currently the vast majority of Moqui contributors and users did not come from the OFBiz world, only a few have. Even investors I've spoken with in recent years consider my approach to be a bit crazy given the existing momentum that OFBiz and organizations around it already have. My desire is to do better. The development efficiency I had in mind in the early years of OFBiz has been dampened by a number of things, and it just doesn't have to be.

My path is my personal decision, and I've enjoyed it very much so far, with both OFBiz and the Moqui/etc projects. Pursuing the best possible solutions in whatever way is necessary is deeply satisfying. The most difficult thing I face these days is that I still do a lot of consulting based on OFBiz, and it is hard to explain that there are good solutions to various problems and try to explain why those aren't done in OFBiz itself already. It doesn't have to be that way, even if I did personally choose another path for myself.

Predicting the future is a tricky thing. The only guarantee is that the more detailed one gets the more one is incorrect. Anything could happen. For those who think things can be better, just do it. All it takes is what is these days a cheap computer, some time, and personal experience and knowledge. Competition isn't a bad thing, we can all learn from each other and choices in a "marketplace", even an open source one, are a good thing. I'd still love to see OFBiz and its various derivatives take off and go amazing places. In various cases I still recommend OFBiz and its derivatives, especially the ones that are more publicly available and that I'm aware of (like Big Fish) even though I know there are many others made by different companies that are just used internally or for their clients only.

-David


On Mar 9, 2014, at 9:25 AM, Mike <[hidden email]> wrote:

> I agree and disagree.  If anyone could create a full blown ERP using Moqui,
> David could do it.  After all he has already managed to do it once, but
> yes, it is (probably) years away.  However, I have no idea of it's current
> state.
>
> Regarding the current imperfections of OFBIZ:  All large software projects
> have hacks and shortcuts built-in.  I bet SAP has thousands of hacks that
> the original designers wish were not there, but are now so ingrained into
> the framework they are impossible to change.  For me the biggest question
> is "does it work"?  OFBIZ already seems to.  Good enough.
>
>
> On Sun, Mar 9, 2014 at 6:42 AM, Paul Piper <[hidden email]> wrote:
>
>> I have to second Adrian's opinion on this:
>>
>> From my perspective Moqui is a rather lost cause. Not because I am not
>> impressed by David's work, but rather because it is years away from
>> becoming
>> an actual thing. From an industry perspective it is difficult if not almost
>> impossible to implement an ERP framework to begin with. OFBiz is a
>> marvelous
>> thing in that extend as that it managed to actually become feature
>> complete.
>> It is, however, an exception and not the rule. Any new "framework" would
>> require a huge amount of either time or money, and frankly Moqui won't be
>> heading there.
>>
>> Again: this doesn't take away anything from David's accomplishments, but if
>> you want my personal two cents on this - ofbiz is what you are looking for.
>>
>>
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Reposting-from-David-Jones-on-Moqui-tp4648884p4648953.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>

[Norbert Reinhard]

I am anew in ofbiz and would like to create a product for my shop,
where the user has the possibility to enter the selected product a start
date and end date on a calendar.
The days will be calculated automatically and will be charged with the
price.

Can anyone recommend a tutorial for this or tell me which approach is
suitable for this purpose?

would be happy about tips and suggestions very much.

[Pierre Smits]

Norbert,

There are several books available on how to do this and other actions in
relation to ecommerce with OFBiz. Have a look at the documentation section
on the website and look/search for these books. Otherwise, documents in the
wiki might help you further as well.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Pierre Smits]

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

[Todd Thorner]

All I know is I'm more confused than ever, and that's saying something
because I'm always a bit of a drooler.

For the time being, I hitch my business wagon to neither project.  My
business is lucky that way, being at the moment completely ERPa derpa it
will be able to adapt to one or the other (or maybe yet another) after I
have time for more thorough information gathering.

Mr. Jones, if you're influential over at Moqui (I'm guessing you are if
you started the darned thing), please consider creating a regular ol'
mailing list so I can join the community and learn more.  I prefer to
stop taking up space within the OFBiz ml talking about how I'd like to
check out one of its alternatives -- but I don't do LinkedIn and Stack
Overflow is more for my potential "I'm trying to implement this..."
questions.



On 14-03-10 08:45 AM, Pierre Smits 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
>