Reposting from David Jones on Moqui

[David E. Jones-2]

This really isn't the place to discuss Moqui Framework and related projects. This mailing list is about OFBiz. Please contact me directly if you'd like to discuss this, either on LinkedIn, the Moqui SourceForge project, or by email (my contact info is easy to find... even from this email).

-David


On Mar 10, 2014, at 9:28 AM, Todd Thorner <[hidden email]> wrote:

> 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
>>

[David E. Jones-2]

Is it really sad?

It is just my opinion, but what OFBiz really needs is a more flexible structure... though not how that would work exactly.

One case in point is my decision to start and independent effort to create a redesigned and more modern framework, and refine the data model and services, and build applications on those. Over the last 4 years I've put around 1500 hours into these 4 projects (Moqui Framework, Mantle Business Artifacts, HiveMind Project Manager, and POP commerce). This is MUCH less time per year than I used to put into OFBiz (in fact probably around 1/3 the time I used to per year), but that was necessary anyway as the service industry blew apart and I was making a LOT less per hour for a couple years starting in 2009, and I was trying to achieve a better work-life balance. One small part of that was losing weight... I'm about 110 pounds lighter than I was around the time of making this shift. Anyway, my contributions to OFBiz itself would have dramatically reduced either way.

There are other current situations demonstrating a need for a more flexible project and software structure. I'm aware of a half dozen very significant derivative works of OFBiz, some focused more on eCommerce and others more on ERP... most on both in some aspect or another. These are mostly internally maintained open source projects or commercial products (some not really publicly available, only used for clients of certain larger OFBiz service providers). Many of these projects/products represent a shift for the people involved away from contributing to OFBiz and instead putting the bulk of their effort into these derivative works.

From what I've seen much of the effort in these projects goes into streamlined user interfaces and the logic/services necessary to support them. These efforts still result in contributions coming back to OFBiz itself, but mostly more minor bug fixes and such as opposed to significant enhancements, new apps, or new functionality. Some bigger things get in here and there, but not a lot. In other words, these efforts are also separations from OFBiz itself.

Is that a bad or sad thing? It would be better if many of these OFBiz derivatives were more publicly available, even if under paid licenses and not just free/open source ones. That would at least make it easier for the software and services sides of the OFBiz ecosystem to grow. If more made it into OFBiz itself, or into open source OFBiz derivatives that involved more collaborative efforts, that would be even better for OFBiz and all of those who work on it and/or do paid work based on it.

Still, each of these is an expansion of the OFBiz ecosystem and are good for OFBiz itself and everyone who works with or on it, even if in minor ways.

For all open source (and much commercial) software that lives for a long time some fragmentation is inevitable. Most open source ERP systems that have been around for very long have been through this (aside from a few of the tightly controlled "commercial open source" ones, but even some of those).

Back to my opinion on the situation: some fragmentation is inevitable, so it's better to structure things to keep things shared between all fragments shared and collectively maintained, and let everything else fragment... even facilitate the fragmentation and make it a clear and encouraged part of the ecosystem.

How much do I believe this is a better approach? So much that the shared business functionality in the Moqui Ecosystem, which is in the Mantle Business Artifacts project, doesn't have a UI at all because that is where much of the fragmentation tends to happen... and really where much of it is actually _needed_ and _should_ happen. I'm not saying that OFBiz should go in this direction, there is already quite a bit of decent UI in the project (even if it does get mostly replaced or heavily changed in any decent sized customization project). There are other ways of defining and limiting the scope of OFBiz itself, and making it more obvious that it is the center of an ecosystem that involves many other software packages.

This sort of encouraged fragmentation minimizes the general "tragedy of the commons" trend, and provides a playground for independent efforts and creative expressions.

As another case in point, consider the massive growth of open source foundations like WordPress and Drupal with a huge add on ecosystem, and commercial ones like Force.com.

OFBiz in some ways has reached a sort of "maturity crisis", and in other ways has huge room for improvement and added value... and along with it more users and contributors. Technically OFBiz already has some pretty good extension mechanisms, and with a lot effort they could be a lot better. OFBiz also already has a solid core of business functionality that can be the basis for many different application and tool extensions. Many of these already exist in fact, just maintained as separate projects that can't easily be found through the OFBiz web site or wiki. In other words, OFBiz is already in a pretty good place for all of this... in some ways even better positioned than the Moqui Ecosystem which is more intentionally designed to eventually get to this sort of thing!

-David



On Mar 10, 2014, at 8:45 AM, Pierre Smits <[hidden email]> 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

[Norbert Reinhard]

Thank Pierre for your answer!

Yes. There are books to ofbiz in which much is described and are also good.
There is a lot on the internet but for a beginner with OFBiz, it is very
difficult to find a description of how the product created as in the
example "Large Room" with a date field, .....

Can anyone recommend a tutorial for here?
Tell me which files need to be edited for this or how I can create on
the Product Manger so that I get a product in which the user must enter
a date?

Just the basics for this.

About a little jump start on this I would be very happy!

Norbert

Am 10.03.2014 15:34, schrieb 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
>
>

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.