Addons for OFBiz

[JulienNicolas]

Hello All,

Since I work on the bootstrap theme in OFBiz, I have many thoughtful,
carefully read the ofbiz community exchanges and spoke with some members
of the OFBiz community.
Today I am convinced that the OFBiz project is a framework that is not
intended to be an ERP. Its OOTB user interface is a nightmare and is not
really user oriented.
Several topics that seem to have no link together, seems to be linked
around the same idea.

The first topic is about functionality of OFBiz.
On one hand, there is the OFBiz framework. It contains a user interface
to show the possibility of OFBiz, but must be changed during
integration. It also includes functional oriented features. These
features split the community between those who want to keep them in the
project and those who wish to exclude them.
On the other hand, there are new initiatives,abandoned projects, old or
having no longer contributors (project manager, POS, etc.) who need
support, visibility, even if they are not added to the OFBiz project.
A first approach was discussed with GIT. It can allow everyone to share
their work more easily with branch feature. Which is good but not the
best in my opinion.

Another topic that is important to me is the functional part of OFBiz.
Sharan explained me about its willingness to invest energy to make the
software more functional, and if it's possible to have a version with
ERP oriented for small businesses with minimal features but easy to use.
Like growERP or TerCompta offer. Using OFBiz framework but simplify the
UI to allow the software to be used intuitively without modifications.

These initiatives come up against the model of OFBiz project. Who has
still not decided whether it is an ERP, in which case it needs to adjust
its UI or an automation of enterprise processes framework, which
involves getting rid of unnecessary features dedicated to ERP.

There are several solutions that could help to make better the model of
OFBiz and satisfy the entire community.
The first solution would be to limit the “OFBiz framewok” project
framework for automation enterprise processes and to have another “OFBiz
ERP” project which would use the framework as a basis, and which would
provide a user-friendly UI and dedicated tools to ERP.

The second option is to find a way to cut the project in extensions.
This solution would have the opportunity to clean the framework and have
features as micro projects and therefore no longer a monolithic software.

I see a lot of debate about adding new functionality that allow to
improve development, compile, manage sources, merge with another
framework, but the debate on the division of project extensions seems
not to interest. It seems to me extremely important to facilitate
development and therefore, ultimately, the visibility of the project in
the developers community.

At Nomaka, we initiated an effort starting from the first solution. We
took OFBiz framework, deleted all the themes and created a new one. Then
we redesigned the interface to match a basic ERP.
We started with actor UI. Disabled existing screens and created new ones
more functional and user-friendly.

I find it a pity to work alone in my corner without being able to easily
share my work, without taking advantage of the OFBiz community knowledge
to guide me onthe right way.
I wonder if we could work on this axis and balance the rigidity
necessary to have a stable project and flexibility that allow to include
non-committer contributions ...

What do you think ?

Julien.

[Michael Brohl-3]

Hi Julien,

thank you for bringing this up!

I don't think that this is of no interest in the community, it's just
overlaid by the many other topics we are discussing currently. I
personally think that all topics are worth to be discussed and
elaborated, maybe they have to be prioritised a little bit more. Right
now it's a little bit confusing and not easy to follow (and contribute
to) the discussions besides daily business.

I think it is an important topic to simplify the backend component's UI
and have more sophisticated usability there. On the other hand, it is
important to somehow show customers the powers of OFBiz and the many
already set-up functionalities. It would be a big step forward if we
find a way to make this customizeable. For an ERP, it would also be a
big plus to have some kind of "business templates" (!= UI templates) on
top of such a mechanism, like

- Your customer sells products over the internet? - pull the ecommerce
template
- Your customer brews beer? - pull the manufacturing +x template
- Your customer has a small business? - pull the corresponding template
etc.

I belive that would require different configuration mechanisms, more on
a database level with a clever UI instead of many different property
files. And maybe a tool to chain services together on base of  such a
template.

I won't reduce the functionality in OFBiz per se, as long as they are
stable and/or have a maintainer.

I know of at least one contributor who is also working on a more
sophisticated UI, maybe he shows up here also ;-)

So, without having a concrete plan or more thought-out ideas how to
implement this, I would support such an effort.

As a community, I think we have to find a way to channel the different
interests from core technology work up to the business layer. Some kind
of overall project management would help but would be difficult to
install in an open community. Too many open building sites in parallel
are not that efficient.

Curious what others think...

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 07.05.15 um 12:48 schrieb Julien NICOLAS:

> Hello All,
>
> Since I work on the bootstrap theme in OFBiz, I have many thoughtful,
> carefully read the ofbiz community exchanges and spoke with some
> members of the OFBiz community.
> Today I am convinced that the OFBiz project is a framework that is not
> intended to be an ERP. Its OOTB user interface is a nightmare and is
> not really user oriented.
> Several topics that seem to have no link together, seems to be linked
> around the same idea.
>
> The first topic is about functionality of OFBiz.
> On one hand, there is the OFBiz framework. It contains a user
> interface to show the possibility of OFBiz, but must be changed during
> integration. It also includes functional oriented features. These
> features split the community between those who want to keep them in
> the project and those who wish to exclude them.
> On the other hand, there are new initiatives,abandoned projects, old
> or having no longer contributors (project manager, POS, etc.) who need
> support, visibility, even if they are not added to the OFBiz project.
> A first approach was discussed with GIT. It can allow everyone to
> share their work more easily with branch feature. Which is good but
> not the best in my opinion.
>
> Another topic that is important to me is the functional part of OFBiz.
> Sharan explained me about its willingness to invest energy to make the
> software more functional, and if it's possible to have a version with
> ERP oriented for small businesses with minimal features but easy to
> use. Like growERP or TerCompta offer. Using OFBiz framework but
> simplify the UI to allow the software to be used intuitively without
> modifications.
>
> These initiatives come up against the model of OFBiz project. Who has
> still not decided whether it is an ERP, in which case it needs to
> adjust its UI or an automation of enterprise processes framework,
> which involves getting rid of unnecessary features dedicated to ERP.
>
> There are several solutions that could help to make better the model
> of OFBiz and satisfy the entire community.
> The first solution would be to limit the “OFBiz framewok” project
> framework for automation enterprise processes and to have another
> “OFBiz ERP” project which would use the framework as a basis, and
> which would provide a user-friendly UI and dedicated tools to ERP.
>
> The second option is to find a way to cut the project in extensions.
> This solution would have the opportunity to clean the framework and
> have features as micro projects and therefore no longer a monolithic
> software.
>
> I see a lot of debate about adding new functionality that allow to
> improve development, compile, manage sources, merge with another
> framework, but the debate on the division of project extensions seems
> not to interest. It seems to me extremely important to facilitate
> development and therefore, ultimately, the visibility of the project
> in the developers community.
>
> At Nomaka, we initiated an effort starting from the first solution. We
> took OFBiz framework, deleted all the themes and created a new one.
> Then we redesigned the interface to match a basic ERP.
> We started with actor UI. Disabled existing screens and created new
> ones more functional and user-friendly.
>
> I find it a pity to work alone in my corner without being able to
> easily share my work, without taking advantage of the OFBiz community
> knowledge to guide me onthe right way.
> I wonder if we could work on this axis and balance the rigidity
> necessary to have a stable project and flexibility that allow to
> include non-committer contributions ...
>
> What do you think ?
>
> Julien.
>

[Sharan-F]

Hi

I also think it's great that this topic has been raised (so thanks Julien).

I would be really keen to participate in any effort that could simplify and improve the user experience for OFBiz. Our demo is there to show people what OFBiz can do but if it doesn't look very nice or easy to use then we have lost them already.  I suppose it's a balance between showing something functionally complete against trying to show that it can do everything but needs to be customised.

There was an effort a while ago that David started looking at version of OFBiz for small businesses called Ezbiz (I think it's still on the Requirements and Designs workspace) https://cwiki.apache.org/confluence/display/OFBREQDES/OFBiz+EZBiz   but it didnt get too far, I think due to lack of support so perhaps this could help as a base otherwise we could start again from scratch (or use Julien's model so far     ).

Thanks
Sharan

[Ron Wheeler]

I agree with Julien's analysis.
If I say "sub-projects" again, Jacques will whack me upside the head but
I really think that a restructuring of the way the architecture is
presented and developed would provide a number of benefits:
- increase community involvement with less work for the current key
committers
- reduce or eliminate sub-optimal inter-component dependencies through
clearer definitions and independent releases of components
- reduce mixing of core seed data with demo and customizable seed data
and inter-component data confusion.
- facilitate the construction of components and add-ons that do not have
undesirable or unknown side-affects
- facilitate the injection of a smart installer that would allow the
selection of  components and templates as suggested at install time.
- facilitate the development of an OFBiz marketplace for add-ons and
industry-specific configurations.
- make the role of the framework as a base for other products much clearer.
- possibly make it easier to "Moquify" the framework if the framework
API can be made less implementation dependent - lots of issues here that
already have been fully ventilated last week.

Ron

On 07/05/2015 7:28 AM, Michael Brohl wrote:

> Hi Julien,
>
> thank you for bringing this up!
>
> I don't think that this is of no interest in the community, it's just
> overlaid by the many other topics we are discussing currently. I
> personally think that all topics are worth to be discussed and
> elaborated, maybe they have to be prioritised a little bit more. Right
> now it's a little bit confusing and not easy to follow (and contribute
> to) the discussions besides daily business.
>
> I think it is an important topic to simplify the backend component's
> UI and have more sophisticated usability there. On the other hand, it
> is important to somehow show customers the powers of OFBiz and the
> many already set-up functionalities. It would be a big step forward if
> we find a way to make this customizeable. For an ERP, it would also be
> a big plus to have some kind of "business templates" (!= UI templates)
> on top of such a mechanism, like
>
> - Your customer sells products over the internet? - pull the ecommerce
> template
> - Your customer brews beer? - pull the manufacturing +x template
> - Your customer has a small business? - pull the corresponding template
> etc.
>
> I belive that would require different configuration mechanisms, more
> on a database level with a clever UI instead of many different
> property files. And maybe a tool to chain services together on base
> of  such a template.
>
> I won't reduce the functionality in OFBiz per se, as long as they are
> stable and/or have a maintainer.
>
> I know of at least one contributor who is also working on a more
> sophisticated UI, maybe he shows up here also ;-)
>
> So, without having a concrete plan or more thought-out ideas how to
> implement this, I would support such an effort.
>
> As a community, I think we have to find a way to channel the different
> interests from core technology work up to the business layer. Some
> kind of overall project management would help but would be difficult
> to install in an open community. Too many open building sites in
> parallel are not that efficient.
>
> Curious what others think...
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>> Hello All,
>>
>> Since I work on the bootstrap theme in OFBiz, I have many thoughtful,
>> carefully read the ofbiz community exchanges and spoke with some
>> members of the OFBiz community.
>> Today I am convinced that the OFBiz project is a framework that is
>> not intended to be an ERP. Its OOTB user interface is a nightmare and
>> is not really user oriented.
>> Several topics that seem to have no link together, seems to be linked
>> around the same idea.
>>
>> The first topic is about functionality of OFBiz.
>> On one hand, there is the OFBiz framework. It contains a user
>> interface to show the possibility of OFBiz, but must be changed
>> during integration. It also includes functional oriented features.
>> These features split the community between those who want to keep
>> them in the project and those who wish to exclude them.
>> On the other hand, there are new initiatives,abandoned projects, old
>> or having no longer contributors (project manager, POS, etc.) who
>> need support, visibility, even if they are not added to the OFBiz
>> project.
>> A first approach was discussed with GIT. It can allow everyone to
>> share their work more easily with branch feature. Which is good but
>> not the best in my opinion.
>>
>> Another topic that is important to me is the functional part of OFBiz.
>> Sharan explained me about its willingness to invest energy to make
>> the software more functional, and if it's possible to have a version
>> with ERP oriented for small businesses with minimal features but easy
>> to use. Like growERP or TerCompta offer. Using OFBiz framework but
>> simplify the UI to allow the software to be used intuitively without
>> modifications.
>>
>> These initiatives come up against the model of OFBiz project. Who has
>> still not decided whether it is an ERP, in which case it needs to
>> adjust its UI or an automation of enterprise processes framework,
>> which involves getting rid of unnecessary features dedicated to ERP.
>>
>> There are several solutions that could help to make better the model
>> of OFBiz and satisfy the entire community.
>> The first solution would be to limit the “OFBiz framewok” project
>> framework for automation enterprise processes and to have another
>> “OFBiz ERP” project which would use the framework as a basis, and
>> which would provide a user-friendly UI and dedicated tools to ERP.
>>
>> The second option is to find a way to cut the project in extensions.
>> This solution would have the opportunity to clean the framework and
>> have features as micro projects and therefore no longer a monolithic
>> software.
>>
>> I see a lot of debate about adding new functionality that allow to
>> improve development, compile, manage sources, merge with another
>> framework, but the debate on the division of project extensions seems
>> not to interest. It seems to me extremely important to facilitate
>> development and therefore, ultimately, the visibility of the project
>> in the developers community.
>>
>> At Nomaka, we initiated an effort starting from the first solution.
>> We took OFBiz framework, deleted all the themes and created a new
>> one. Then we redesigned the interface to match a basic ERP.
>> We started with actor UI. Disabled existing screens and created new
>> ones more functional and user-friendly.
>>
>> I find it a pity to work alone in my corner without being able to
>> easily share my work, without taking advantage of the OFBiz community
>> knowledge to guide me onthe right way.
>> I wonder if we could work on this axis and balance the rigidity
>> necessary to have a stable project and flexibility that allow to
>> include non-committer contributions ...
>>
>> What do you think ?
>>
>> Julien.
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Adam Heath-2]

On 05/07/2015 05:48 AM, Julien NICOLAS wrote:
> I see a lot of debate about adding new functionality that allow to
> improve development, compile, manage sources, merge with another
> framework, but the debate on the division of project extensions seems
> not to interest. It seems to me extremely important to facilitate
> development and therefore, ultimately, the visibility of the project
> in the developers community.

You don't understand the force behind my work then. That's the goal, to
be able to require only just what we(Brainfood) need for a deployment.  
For reference, we don't write our frontends in any of the widget systems.

The built-in build system, the use of svn, are holding the project
back.  It's not just about switching because of switching, but the new
tools open the door for everything you are talking about.

So, please be patient.

[JulienNicolas]

Hi Adam,

I'm not talking about how to do it but to answer the question : is the
community want to do it ?

Is the community want to maintain only a framework and not an ERP ?
Split the project in several part.

Maven could be a solution, but before choosing a solution, we must be
sure that it is a common decision.
Then we can define action plan on how to do it and go ahead :)

Julien.


Le 07/05/2015 16:19, Adam Heath a écrit :

>
>
> On 05/07/2015 05:48 AM, Julien NICOLAS wrote:
>> I see a lot of debate about adding new functionality that allow to
>> improve development, compile, manage sources, merge with another
>> framework, but the debate on the division of project extensions seems
>> not to interest. It seems to me extremely important to facilitate
>> development and therefore, ultimately, the visibility of the project
>> in the developers community.
>
> You don't understand the force behind my work then. That's the goal,
> to be able to require only just what we(Brainfood) need for a
> deployment.  For reference, we don't write our frontends in any of the
> widget systems.
>
> The built-in build system, the use of svn, are holding the project
> back.  It's not just about switching because of switching, but the new
> tools open the door for everything you are talking about.
>
> So, please be patient.
>

[Adam Heath-2]

On 05/07/2015 09:42 AM, Julien NICOLAS wrote:

> Hi Adam,
>
> I'm not talking about how to do it but to answer the question : is the
> community want to do it ?
>
> Is the community want to maintain only a framework and not an ERP ?
> Split the project in several part.
>
> Maven could be a solution, but before choosing a solution, we must be
> sure that it is a common decision.
> Then we can define action plan on how to do it and go ahead :)
>

No more endless talk.  That's the status quo.  It's a dead end. That's
how things have been going, and Jacopo's own graphs have shown ofbiz in
decline(namely, the number of commits to the project).  It may not have
been apparent, but when I saw that slide, my heart sank.  It was obvious
to me, that something had to change. The downturn in the graph was long,
it wasn't something recent.  It appeared that no one in the community
was doing anything towards solving that problem.  What I took away from
that is a whole new way needed to be applied.  Sorry if that ruffles
feathers, but that's how I feal.

I'm creating actual code, in isolated branches, in the public, where
everyone can see, with incremental, small changes(not one huge patch,
which is the jira way).  I'm not working in isolation. Please join the
effort.

What I am doing is actually good, I'm giving of my time to ofbiz.  I had
been doing nothing for so long, so even if what I have started isn't
used, I'll keep giving more time, and doing other things. Maven(and/or
gradle, still haven't decided that) is just the start of ideas I've been
sitting on.

ps: In the graph I mention, there are 2 large spike, outside of the
average.  The first was because of Jacques, the second was me.  I
cross-references the graphs from github for the same timeframe.

[Jacopo Cappellato-5]

On May 7, 2015, at 5:32 PM, Adam Heath <[hidden email]> wrote:

> ... and Jacopo's own graphs have shown ofbiz in decline(namely, the number of commits to the project).

I completely disagree with your analysis.

Jacopo

[Adam Heath-2]

On 05/07/2015 11:02 AM, Jacopo Cappellato wrote:
> On May 7, 2015, at 5:32 PM, Adam Heath <[hidden email]> wrote:
>
>> ... and Jacopo's own graphs have shown ofbiz in decline(namely, the number of commits to the project).
> I completely disagree with your analysis.

Well, that's a wonderfully informative response.

[byersa]

Adam,

How does your work on refactoring OFBiz fit with your interest in a Moqui
PoC? Do you think that with your work there would not be a need to add in
Moqui in order to resolve the inadequacies that you find? Are you open to
the idea that it will be better to use Moqui in some way and not need to
continue your re-factoring?

I found the areas in which you are interested in adding Moqui to OFBiz
(entity engine, service engine and security) to be the ones that interest
me the most. I have no interest in the UI component at the moment (though I
like its flexibility and may incorporate it in the future). Are you
thinking that you may add those in and with your other re-factoring that
would be the best solution?

Obviously, you probably can't answer definitively because you're not there
yet, but I was just wonder what your thoughts are.

-Al

On Thu, May 7, 2015 at 9:32 AM, Adam Heath <[hidden email]> wrote:

>
>
> On 05/07/2015 09:42 AM, Julien NICOLAS wrote:
>
>> Hi Adam,
>>
>> I'm not talking about how to do it but to answer the question : is the
>> community want to do it ?
>>
>> Is the community want to maintain only a framework and not an ERP ? Split
>> the project in several part.
>>
>> Maven could be a solution, but before choosing a solution, we must be
>> sure that it is a common decision.
>> Then we can define action plan on how to do it and go ahead :)
>>
>>
> No more endless talk.  That's the status quo.  It's a dead end. That's how
> things have been going, and Jacopo's own graphs have shown ofbiz in
> decline(namely, the number of commits to the project).  It may not have
> been apparent, but when I saw that slide, my heart sank.  It was obvious to
> me, that something had to change. The downturn in the graph was long, it
> wasn't something recent.  It appeared that no one in the community was
> doing anything towards solving that problem.  What I took away from that is
> a whole new way needed to be applied.  Sorry if that ruffles feathers, but
> that's how I feal.
>
> I'm creating actual code, in isolated branches, in the public, where
> everyone can see, with incremental, small changes(not one huge patch, which
> is the jira way).  I'm not working in isolation. Please join the effort.
>
> What I am doing is actually good, I'm giving of my time to ofbiz.  I had
> been doing nothing for so long, so even if what I have started isn't used,
> I'll keep giving more time, and doing other things. Maven(and/or gradle,
> still haven't decided that) is just the start of ideas I've been sitting on.
>
> ps: In the graph I mention, there are 2 large spike, outside of the
> average.  The first was because of Jacques, the second was me.  I
> cross-references the graphs from github for the same timeframe.
>

[Michael Brohl-3]

Adam,

I must admit that it's really hard for me to follow you. If you want
people to join the effort you should try to convince them, pick them up
where they are, just do some marketing for your ideas.

If you have the big picture in your mind, share it with us. And take
critical questions as constructive help to work things out, I'm sure
they are not meant to attack your efforts.

Telling people to shut up, be patient and to wait for great things to
come might not be the right approach.
And steadily mentioning past merits is not an argument for future
changes and neither convincing.

To be clear, I appreciate your work, past and future. I do business
using OFBiz for about 12 years now so I think I know what people have
done for the project. But that adds nothing substantial to the discussions.

That said, please try to pick us up where we are and I'm sure people
will join you if they are convinced that the work they are doing goes in
the right direction. I would be glad to be one of them, if I can.

Thanks and regards,

Michael


Am 07.05.15 um 17:32 schrieb Adam Heath:

>
>
> On 05/07/2015 09:42 AM, Julien NICOLAS wrote:
>> Hi Adam,
>>
>> I'm not talking about how to do it but to answer the question : is
>> the community want to do it ?
>>
>> Is the community want to maintain only a framework and not an ERP ?
>> Split the project in several part.
>>
>> Maven could be a solution, but before choosing a solution, we must be
>> sure that it is a common decision.
>> Then we can define action plan on how to do it and go ahead :)
>>
>
> No more endless talk.  That's the status quo.  It's a dead end. That's
> how things have been going, and Jacopo's own graphs have shown ofbiz
> in decline(namely, the number of commits to the project).  It may not
> have been apparent, but when I saw that slide, my heart sank.  It was
> obvious to me, that something had to change. The downturn in the graph
> was long, it wasn't something recent.  It appeared that no one in the
> community was doing anything towards solving that problem.  What I
> took away from that is a whole new way needed to be applied.  Sorry if
> that ruffles feathers, but that's how I feal.
>
> I'm creating actual code, in isolated branches, in the public, where
> everyone can see, with incremental, small changes(not one huge patch,
> which is the jira way).  I'm not working in isolation. Please join the
> effort.
>
> What I am doing is actually good, I'm giving of my time to ofbiz. I
> had been doing nothing for so long, so even if what I have started
> isn't used, I'll keep giving more time, and doing other things.
> Maven(and/or gradle, still haven't decided that) is just the start of
> ideas I've been sitting on.
>
> ps: In the graph I mention, there are 2 large spike, outside of the
> average.  The first was because of Jacques, the second was me.  I
> cross-references the graphs from github for the same timeframe.

[JulienNicolas]

Hi all,

I was hopping more people will explain on this subject. It's exactly
what I was thinking, that the functional part is less than the last
priority of the project.
I don't know exactly how I can do it but I really want to start
something that will use OFBiz as a framework. If it can be done with the
OFBiz community, it will be really good.

Efforts exist but need people of the strong OFBiz community to be really
better (GrowERP, BigFish, TERCompta, etc.).

It's a pity that every new company that want to work with OFBiz must
work on it's own version to be able to integrate it. I don't think it's
a good thing for the project growing.
And OFBiz community don't allow company to find easily other effort to
enhance the software. And finally it seems that there is less than 5
peoples interested to work on this way.

Maybe I'm wrong, functional is not as important as I thought...

Sorry for the noise,

Julien.


Le 07/05/2015 16:00, Ron Wheeler a écrit :

> I agree with Julien's analysis.
> If I say "sub-projects" again, Jacques will whack me upside the head
> but I really think that a restructuring of the way the architecture is
> presented and developed would provide a number of benefits:
> - increase community involvement with less work for the current key
> committers
> - reduce or eliminate sub-optimal inter-component dependencies through
> clearer definitions and independent releases of components
> - reduce mixing of core seed data with demo and customizable seed data
> and inter-component data confusion.
> - facilitate the construction of components and add-ons that do not
> have undesirable or unknown side-affects
> - facilitate the injection of a smart installer that would allow the
> selection of  components and templates as suggested at install time.
> - facilitate the development of an OFBiz marketplace for add-ons and
> industry-specific configurations.
> - make the role of the framework as a base for other products much
> clearer.
> - possibly make it easier to "Moquify" the framework if the framework
> API can be made less implementation dependent - lots of issues here
> that already have been fully ventilated last week.
>
> Ron
>
> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>> Hi Julien,
>>
>> thank you for bringing this up!
>>
>> I don't think that this is of no interest in the community, it's just
>> overlaid by the many other topics we are discussing currently. I
>> personally think that all topics are worth to be discussed and
>> elaborated, maybe they have to be prioritised a little bit more.
>> Right now it's a little bit confusing and not easy to follow (and
>> contribute to) the discussions besides daily business.
>>
>> I think it is an important topic to simplify the backend component's
>> UI and have more sophisticated usability there. On the other hand, it
>> is important to somehow show customers the powers of OFBiz and the
>> many already set-up functionalities. It would be a big step forward
>> if we find a way to make this customizeable. For an ERP, it would
>> also be a big plus to have some kind of "business templates" (!= UI
>> templates) on top of such a mechanism, like
>>
>> - Your customer sells products over the internet? - pull the
>> ecommerce template
>> - Your customer brews beer? - pull the manufacturing +x template
>> - Your customer has a small business? - pull the corresponding template
>> etc.
>>
>> I belive that would require different configuration mechanisms, more
>> on a database level with a clever UI instead of many different
>> property files. And maybe a tool to chain services together on base
>> of  such a template.
>>
>> I won't reduce the functionality in OFBiz per se, as long as they are
>> stable and/or have a maintainer.
>>
>> I know of at least one contributor who is also working on a more
>> sophisticated UI, maybe he shows up here also ;-)
>>
>> So, without having a concrete plan or more thought-out ideas how to
>> implement this, I would support such an effort.
>>
>> As a community, I think we have to find a way to channel the
>> different interests from core technology work up to the business
>> layer. Some kind of overall project management would help but would
>> be difficult to install in an open community. Too many open building
>> sites in parallel are not that efficient.
>>
>> Curious what others think...
>>
>> Regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>> Hello All,
>>>
>>> Since I work on the bootstrap theme in OFBiz, I have many
>>> thoughtful, carefully read the ofbiz community exchanges and spoke
>>> with some members of the OFBiz community.
>>> Today I am convinced that the OFBiz project is a framework that is
>>> not intended to be an ERP. Its OOTB user interface is a nightmare
>>> and is not really user oriented.
>>> Several topics that seem to have no link together, seems to be
>>> linked around the same idea.
>>>
>>> The first topic is about functionality of OFBiz.
>>> On one hand, there is the OFBiz framework. It contains a user
>>> interface to show the possibility of OFBiz, but must be changed
>>> during integration. It also includes functional oriented features.
>>> These features split the community between those who want to keep
>>> them in the project and those who wish to exclude them.
>>> On the other hand, there are new initiatives,abandoned projects, old
>>> or having no longer contributors (project manager, POS, etc.) who
>>> need support, visibility, even if they are not added to the OFBiz
>>> project.
>>> A first approach was discussed with GIT. It can allow everyone to
>>> share their work more easily with branch feature. Which is good but
>>> not the best in my opinion.
>>>
>>> Another topic that is important to me is the functional part of OFBiz.
>>> Sharan explained me about its willingness to invest energy to make
>>> the software more functional, and if it's possible to have a version
>>> with ERP oriented for small businesses with minimal features but
>>> easy to use. Like growERP or TerCompta offer. Using OFBiz framework
>>> but simplify the UI to allow the software to be used intuitively
>>> without modifications.
>>>
>>> These initiatives come up against the model of OFBiz project. Who
>>> has still not decided whether it is an ERP, in which case it needs
>>> to adjust its UI or an automation of enterprise processes framework,
>>> which involves getting rid of unnecessary features dedicated to ERP.
>>>
>>> There are several solutions that could help to make better the model
>>> of OFBiz and satisfy the entire community.
>>> The first solution would be to limit the “OFBiz framewok” project
>>> framework for automation enterprise processes and to have another
>>> “OFBiz ERP” project which would use the framework as a basis, and
>>> which would provide a user-friendly UI and dedicated tools to ERP.
>>>
>>> The second option is to find a way to cut the project in extensions.
>>> This solution would have the opportunity to clean the framework and
>>> have features as micro projects and therefore no longer a monolithic
>>> software.
>>>
>>> I see a lot of debate about adding new functionality that allow to
>>> improve development, compile, manage sources, merge with another
>>> framework, but the debate on the division of project extensions
>>> seems not to interest. It seems to me extremely important to
>>> facilitate development and therefore, ultimately, the visibility of
>>> the project in the developers community.
>>>
>>> At Nomaka, we initiated an effort starting from the first solution.
>>> We took OFBiz framework, deleted all the themes and created a new
>>> one. Then we redesigned the interface to match a basic ERP.
>>> We started with actor UI. Disabled existing screens and created new
>>> ones more functional and user-friendly.
>>>
>>> I find it a pity to work alone in my corner without being able to
>>> easily share my work, without taking advantage of the OFBiz
>>> community knowledge to guide me onthe right way.
>>> I wonder if we could work on this axis and balance the rigidity
>>> necessary to have a stable project and flexibility that allow to
>>> include non-committer contributions ...
>>>
>>> What do you think ?
>>>
>>> Julien.
>>>
>>
>
>

[Hans Bakker]

Julien, It can be that i do not understand your point.

When we implement OFBiz for a customer we create a new component in
hot-deploy and we re-use as much from the OFBiz system as we can. We
also create new components like GrowERP which is just a component in
Hot-deploy. When we do that we almost not change the core ofbiz system
so we can easily upgrade.

So i think that add-ons can be easily created just by adding new
components in hot-deploy, or do i miss something?

Regards,
Hans


On 13/05/15 13:56, Julien NICOLAS wrote:

> Hi all,
>
> I was hopping more people will explain on this subject. It's exactly
> what I was thinking, that the functional part is less than the last
> priority of the project.
> I don't know exactly how I can do it but I really want to start
> something that will use OFBiz as a framework. If it can be done with
> the OFBiz community, it will be really good.
>
> Efforts exist but need people of the strong OFBiz community to be
> really better (GrowERP, BigFish, TERCompta, etc.).
>
> It's a pity that every new company that want to work with OFBiz must
> work on it's own version to be able to integrate it. I don't think
> it's a good thing for the project growing.
> And OFBiz community don't allow company to find easily other effort to
> enhance the software. And finally it seems that there is less than 5
> peoples interested to work on this way.
>
> Maybe I'm wrong, functional is not as important as I thought...
>
> Sorry for the noise,
>
> Julien.
>
>
> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>> I agree with Julien's analysis.
>> If I say "sub-projects" again, Jacques will whack me upside the head
>> but I really think that a restructuring of the way the architecture
>> is presented and developed would provide a number of benefits:
>> - increase community involvement with less work for the current key
>> committers
>> - reduce or eliminate sub-optimal inter-component dependencies
>> through clearer definitions and independent releases of components
>> - reduce mixing of core seed data with demo and customizable seed
>> data and inter-component data confusion.
>> - facilitate the construction of components and add-ons that do not
>> have undesirable or unknown side-affects
>> - facilitate the injection of a smart installer that would allow the
>> selection of  components and templates as suggested at install time.
>> - facilitate the development of an OFBiz marketplace for add-ons and
>> industry-specific configurations.
>> - make the role of the framework as a base for other products much
>> clearer.
>> - possibly make it easier to "Moquify" the framework if the framework
>> API can be made less implementation dependent - lots of issues here
>> that already have been fully ventilated last week.
>>
>> Ron
>>
>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>> Hi Julien,
>>>
>>> thank you for bringing this up!
>>>
>>> I don't think that this is of no interest in the community, it's
>>> just overlaid by the many other topics we are discussing currently.
>>> I personally think that all topics are worth to be discussed and
>>> elaborated, maybe they have to be prioritised a little bit more.
>>> Right now it's a little bit confusing and not easy to follow (and
>>> contribute to) the discussions besides daily business.
>>>
>>> I think it is an important topic to simplify the backend component's
>>> UI and have more sophisticated usability there. On the other hand,
>>> it is important to somehow show customers the powers of OFBiz and
>>> the many already set-up functionalities. It would be a big step
>>> forward if we find a way to make this customizeable. For an ERP, it
>>> would also be a big plus to have some kind of "business templates"
>>> (!= UI templates) on top of such a mechanism, like
>>>
>>> - Your customer sells products over the internet? - pull the
>>> ecommerce template
>>> - Your customer brews beer? - pull the manufacturing +x template
>>> - Your customer has a small business? - pull the corresponding template
>>> etc.
>>>
>>> I belive that would require different configuration mechanisms, more
>>> on a database level with a clever UI instead of many different
>>> property files. And maybe a tool to chain services together on base
>>> of  such a template.
>>>
>>> I won't reduce the functionality in OFBiz per se, as long as they
>>> are stable and/or have a maintainer.
>>>
>>> I know of at least one contributor who is also working on a more
>>> sophisticated UI, maybe he shows up here also ;-)
>>>
>>> So, without having a concrete plan or more thought-out ideas how to
>>> implement this, I would support such an effort.
>>>
>>> As a community, I think we have to find a way to channel the
>>> different interests from core technology work up to the business
>>> layer. Some kind of overall project management would help but would
>>> be difficult to install in an open community. Too many open building
>>> sites in parallel are not that efficient.
>>>
>>> Curious what others think...
>>>
>>> Regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>> Hello All,
>>>>
>>>> Since I work on the bootstrap theme in OFBiz, I have many
>>>> thoughtful, carefully read the ofbiz community exchanges and spoke
>>>> with some members of the OFBiz community.
>>>> Today I am convinced that the OFBiz project is a framework that is
>>>> not intended to be an ERP. Its OOTB user interface is a nightmare
>>>> and is not really user oriented.
>>>> Several topics that seem to have no link together, seems to be
>>>> linked around the same idea.
>>>>
>>>> The first topic is about functionality of OFBiz.
>>>> On one hand, there is the OFBiz framework. It contains a user
>>>> interface to show the possibility of OFBiz, but must be changed
>>>> during integration. It also includes functional oriented features.
>>>> These features split the community between those who want to keep
>>>> them in the project and those who wish to exclude them.
>>>> On the other hand, there are new initiatives,abandoned projects,
>>>> old or having no longer contributors (project manager, POS, etc.)
>>>> who need support, visibility, even if they are not added to the
>>>> OFBiz project.
>>>> A first approach was discussed with GIT. It can allow everyone to
>>>> share their work more easily with branch feature. Which is good but
>>>> not the best in my opinion.
>>>>
>>>> Another topic that is important to me is the functional part of OFBiz.
>>>> Sharan explained me about its willingness to invest energy to make
>>>> the software more functional, and if it's possible to have a
>>>> version with ERP oriented for small businesses with minimal
>>>> features but easy to use. Like growERP or TerCompta offer. Using
>>>> OFBiz framework but simplify the UI to allow the software to be
>>>> used intuitively without modifications.
>>>>
>>>> These initiatives come up against the model of OFBiz project. Who
>>>> has still not decided whether it is an ERP, in which case it needs
>>>> to adjust its UI or an automation of enterprise processes
>>>> framework, which involves getting rid of unnecessary features
>>>> dedicated to ERP.
>>>>
>>>> There are several solutions that could help to make better the
>>>> model of OFBiz and satisfy the entire community.
>>>> The first solution would be to limit the “OFBiz framewok” project
>>>> framework for automation enterprise processes and to have another
>>>> “OFBiz ERP” project which would use the framework as a basis, and
>>>> which would provide a user-friendly UI and dedicated tools to ERP.
>>>>
>>>> The second option is to find a way to cut the project in
>>>> extensions. This solution would have the opportunity to clean the
>>>> framework and have features as micro projects and therefore no
>>>> longer a monolithic software.
>>>>
>>>> I see a lot of debate about adding new functionality that allow to
>>>> improve development, compile, manage sources, merge with another
>>>> framework, but the debate on the division of project extensions
>>>> seems not to interest. It seems to me extremely important to
>>>> facilitate development and therefore, ultimately, the visibility of
>>>> the project in the developers community.
>>>>
>>>> At Nomaka, we initiated an effort starting from the first solution.
>>>> We took OFBiz framework, deleted all the themes and created a new
>>>> one. Then we redesigned the interface to match a basic ERP.
>>>> We started with actor UI. Disabled existing screens and created new
>>>> ones more functional and user-friendly.
>>>>
>>>> I find it a pity to work alone in my corner without being able to
>>>> easily share my work, without taking advantage of the OFBiz
>>>> community knowledge to guide me onthe right way.
>>>> I wonder if we could work on this axis and balance the rigidity
>>>> necessary to have a stable project and flexibility that allow to
>>>> include non-committer contributions ...
>>>>
>>>> What do you think ?
>>>>
>>>> Julien.
>>>>
>>>
>>
>>
>

[pierre-29]

Hi Hans,

At Néréide we use the same way as you explain except that some time we have to do modifications in OFBiz core to slightly change one service because there is an error or the process is not exactly what we need. In this case we have to isolate these modifications so that they can be applied when OFBiz core is upgraded. This is done thru addon.

How do you manage modifications in OFBiz core?

Pierre

On 13/05/2015 09:48, Hans Bakker wrote:

Julien, It can be that i do not understand your point.

When we implement OFBiz for a customer we create a new component in hot-deploy and we re-use as much from the OFBiz system as we can. We also create new components like GrowERP which is just a component in Hot-deploy. When we do that we almost not change the core ofbiz system so we can easily upgrade.

So i think that add-ons can be easily created just by adding new components in hot-deploy, or do i miss something?

Regards,
Hans


On 13/05/15 13:56, Julien NICOLAS wrote:

Hi all,

I was hopping more people will explain on this subject. It's exactly what I was thinking, that the functional part is less than the last priority of the project.
I don't know exactly how I can do it but I really want to start something that will use OFBiz as a framework. If it can be done with the OFBiz community, it will be really good.

Efforts exist but need people of the strong OFBiz community to be really better (GrowERP, BigFish, TERCompta, etc.).

It's a pity that every new company that want to work with OFBiz must work on it's own version to be able to integrate it. I don't think it's a good thing for the project growing.
And OFBiz community don't allow company to find easily other effort to enhance the software. And finally it seems that there is less than 5 peoples interested to work on this way.

Maybe I'm wrong, functional is not as important as I thought...

Sorry for the noise,

Julien.


Le 07/05/2015 16:00, Ron Wheeler a écrit :

I agree with Julien's analysis.
If I say "sub-projects" again, Jacques will whack me upside the head but I really think that a restructuring of the way the architecture is presented and developed would provide a number of benefits:
- increase community involvement with less work for the current key committers
- reduce or eliminate sub-optimal inter-component dependencies through clearer definitions and independent releases of components
- reduce mixing of core seed data with demo and customizable seed data and inter-component data confusion.
- facilitate the construction of components and add-ons that do not have undesirable or unknown side-affects
- facilitate the injection of a smart installer that would allow the selection of  components and templates as suggested at install time.
- facilitate the development of an OFBiz marketplace for add-ons and industry-specific configurations.
- make the role of the framework as a base for other products much clearer.
- possibly make it easier to "Moquify" the framework if the framework API can be made less implementation dependent - lots of issues here that already have been fully ventilated last week.

Ron

On 07/05/2015 7:28 AM, Michael Brohl wrote:

Hi Julien,

thank you for bringing this up!

I don't think that this is of no interest in the community, it's just overlaid by the many other topics we are discussing currently. I personally think that all topics are worth to be discussed and elaborated, maybe they have to be prioritised a little bit more. Right now it's a little bit confusing and not easy to follow (and contribute to) the discussions besides daily business.

I think it is an important topic to simplify the backend component's UI and have more sophisticated usability there. On the other hand, it is important to somehow show customers the powers of OFBiz and the many already set-up functionalities. It would be a big step forward if we find a way to make this customizeable. For an ERP, it would also be a big plus to have some kind of "business templates" (!= UI templates) on top of such a mechanism, like

- Your customer sells products over the internet? - pull the ecommerce template
- Your customer brews beer? - pull the manufacturing +x template
- Your customer has a small business? - pull the corresponding template
etc.

I belive that would require different configuration mechanisms, more on a database level with a clever UI instead of many different property files. And maybe a tool to chain services together on base of  such a template.

I won't reduce the functionality in OFBiz per se, as long as they are stable and/or have a maintainer.

I know of at least one contributor who is also working on a more sophisticated UI, maybe he shows up here also ;-)

So, without having a concrete plan or more thought-out ideas how to implement this, I would support such an effort.

As a community, I think we have to find a way to channel the different interests from core technology work up to the business layer. Some kind of overall project management would help but would be difficult to install in an open community. Too many open building sites in parallel are not that efficient.

Curious what others think...

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 07.05.15 um 12:48 schrieb Julien NICOLAS:

Hello All,

Since I work on the bootstrap theme in OFBiz, I have many thoughtful, carefully read the ofbiz community exchanges and spoke with some members of the OFBiz community.
Today I am convinced that the OFBiz project is a framework that is not intended to be an ERP. Its OOTB user interface is a nightmare and is not really user oriented.
Several topics that seem to have no link together, seems to be linked around the same idea.

The first topic is about functionality of OFBiz.
On one hand, there is the OFBiz framework. It contains a user interface to show the possibility of OFBiz, but must be changed during integration. It also includes functional oriented features. These features split the community between those who want to keep them in the project and those who wish to exclude them.
On the other hand, there are new initiatives,abandoned projects, old or having no longer contributors (project manager, POS, etc.) who need support, visibility, even if they are not added to the OFBiz project.
A first approach was discussed with GIT. It can allow everyone to share their work more easily with branch feature. Which is good but not the best in my opinion.

Another topic that is important to me is the functional part of OFBiz.
Sharan explained me about its willingness to invest energy to make the software more functional, and if it's possible to have a version with ERP oriented for small businesses with minimal features but easy to use. Like growERP or TerCompta offer. Using OFBiz framework but simplify the UI to allow the software to be used intuitively without modifications.

These initiatives come up against the model of OFBiz project. Who has still not decided whether it is an ERP, in which case it needs to adjust its UI or an automation of enterprise processes framework, which involves getting rid of unnecessary features dedicated to ERP.

There are several solutions that could help to make better the model of OFBiz and satisfy the entire community.
The first solution would be to limit the “OFBiz framewok” project framework for automation enterprise processes and to have another “OFBiz ERP” project which would use the framework as a basis, and which would provide a user-friendly UI and dedicated tools to ERP.

The second option is to find a way to cut the project in extensions. This solution would have the opportunity to clean the framework and have features as micro projects and therefore no longer a monolithic software.

I see a lot of debate about adding new functionality that allow to improve development, compile, manage sources, merge with another framework, but the debate on the division of project extensions seems not to interest. It seems to me extremely important to facilitate development and therefore, ultimately, the visibility of the project in the developers community.

At Nomaka, we initiated an effort starting from the first solution. We took OFBiz framework, deleted all the themes and created a new one. Then we redesigned the interface to match a basic ERP.
We started with actor UI. Disabled existing screens and created new ones more functional and user-friendly.

I find it a pity to work alone in my corner without being able to easily share my work, without taking advantage of the OFBiz community knowledge to guide me onthe right way.
I wonder if we could work on this axis and balance the rigidity necessary to have a stable project and flexibility that allow to include non-committer contributions ...

What do you think ?

Julien.

[JulienNicolas]

Hello Hans,

Le 13/05/2015 09:48, Hans Bakker a écrit :

> Julien, It can be that i do not understand your point.
>
> When we implement OFBiz for a customer we create a new component in
> hot-deploy and we re-use as much from the OFBiz system as we can. We
> also create new components like GrowERP which is just a component in
> Hot-deploy. When we do that we almost not change the core ofbiz system
> so we can easily upgrade.
>
> So i think that add-ons can be easily created just by adding new
> components in hot-deploy, or do i miss something?

Yes, I think so.

I explain that OFBiz project is monolithic software. Yes you can disable
all existing applications and create specific component for your
customer in hot-deploy.
Problem is, I want to enhance OFBiz functional part (GUI, Theme, user
experience, etc.) but It's really difficult to share it with the
community because it must be included in the whole project and it's hard
to share your work.
Specially if the specific GUI enhancement must be done in the core...

And maybe some company have other specific code to enhance some part. It
could be interesting to have it in add-on that could be easily add to
your customer instance. There is many example.

Hope it's clearer,

Julien.

>
> Regards,
> Hans
>
>
> On 13/05/15 13:56, Julien NICOLAS wrote:
>> Hi all,
>>
>> I was hopping more people will explain on this subject. It's exactly
>> what I was thinking, that the functional part is less than the last
>> priority of the project.
>> I don't know exactly how I can do it but I really want to start
>> something that will use OFBiz as a framework. If it can be done with
>> the OFBiz community, it will be really good.
>>
>> Efforts exist but need people of the strong OFBiz community to be
>> really better (GrowERP, BigFish, TERCompta, etc.).
>>
>> It's a pity that every new company that want to work with OFBiz must
>> work on it's own version to be able to integrate it. I don't think
>> it's a good thing for the project growing.
>> And OFBiz community don't allow company to find easily other effort
>> to enhance the software. And finally it seems that there is less than
>> 5 peoples interested to work on this way.
>>
>> Maybe I'm wrong, functional is not as important as I thought...
>>
>> Sorry for the noise,
>>
>> Julien.
>>
>>
>> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>>> I agree with Julien's analysis.
>>> If I say "sub-projects" again, Jacques will whack me upside the head
>>> but I really think that a restructuring of the way the architecture
>>> is presented and developed would provide a number of benefits:
>>> - increase community involvement with less work for the current key
>>> committers
>>> - reduce or eliminate sub-optimal inter-component dependencies
>>> through clearer definitions and independent releases of components
>>> - reduce mixing of core seed data with demo and customizable seed
>>> data and inter-component data confusion.
>>> - facilitate the construction of components and add-ons that do not
>>> have undesirable or unknown side-affects
>>> - facilitate the injection of a smart installer that would allow the
>>> selection of  components and templates as suggested at install time.
>>> - facilitate the development of an OFBiz marketplace for add-ons and
>>> industry-specific configurations.
>>> - make the role of the framework as a base for other products much
>>> clearer.
>>> - possibly make it easier to "Moquify" the framework if the
>>> framework API can be made less implementation dependent - lots of
>>> issues here that already have been fully ventilated last week.
>>>
>>> Ron
>>>
>>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>>> Hi Julien,
>>>>
>>>> thank you for bringing this up!
>>>>
>>>> I don't think that this is of no interest in the community, it's
>>>> just overlaid by the many other topics we are discussing currently.
>>>> I personally think that all topics are worth to be discussed and
>>>> elaborated, maybe they have to be prioritised a little bit more.
>>>> Right now it's a little bit confusing and not easy to follow (and
>>>> contribute to) the discussions besides daily business.
>>>>
>>>> I think it is an important topic to simplify the backend
>>>> component's UI and have more sophisticated usability there. On the
>>>> other hand, it is important to somehow show customers the powers of
>>>> OFBiz and the many already set-up functionalities. It would be a
>>>> big step forward if we find a way to make this customizeable. For
>>>> an ERP, it would also be a big plus to have some kind of "business
>>>> templates" (!= UI templates) on top of such a mechanism, like
>>>>
>>>> - Your customer sells products over the internet? - pull the
>>>> ecommerce template
>>>> - Your customer brews beer? - pull the manufacturing +x template
>>>> - Your customer has a small business? - pull the corresponding
>>>> template
>>>> etc.
>>>>
>>>> I belive that would require different configuration mechanisms,
>>>> more on a database level with a clever UI instead of many different
>>>> property files. And maybe a tool to chain services together on base
>>>> of  such a template.
>>>>
>>>> I won't reduce the functionality in OFBiz per se, as long as they
>>>> are stable and/or have a maintainer.
>>>>
>>>> I know of at least one contributor who is also working on a more
>>>> sophisticated UI, maybe he shows up here also ;-)
>>>>
>>>> So, without having a concrete plan or more thought-out ideas how to
>>>> implement this, I would support such an effort.
>>>>
>>>> As a community, I think we have to find a way to channel the
>>>> different interests from core technology work up to the business
>>>> layer. Some kind of overall project management would help but would
>>>> be difficult to install in an open community. Too many open
>>>> building sites in parallel are not that efficient.
>>>>
>>>> Curious what others think...
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>> ecomify GmbH
>>>> www.ecomify.de
>>>>
>>>>
>>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>>> Hello All,
>>>>>
>>>>> Since I work on the bootstrap theme in OFBiz, I have many
>>>>> thoughtful, carefully read the ofbiz community exchanges and spoke
>>>>> with some members of the OFBiz community.
>>>>> Today I am convinced that the OFBiz project is a framework that is
>>>>> not intended to be an ERP. Its OOTB user interface is a nightmare
>>>>> and is not really user oriented.
>>>>> Several topics that seem to have no link together, seems to be
>>>>> linked around the same idea.
>>>>>
>>>>> The first topic is about functionality of OFBiz.
>>>>> On one hand, there is the OFBiz framework. It contains a user
>>>>> interface to show the possibility of OFBiz, but must be changed
>>>>> during integration. It also includes functional oriented features.
>>>>> These features split the community between those who want to keep
>>>>> them in the project and those who wish to exclude them.
>>>>> On the other hand, there are new initiatives,abandoned projects,
>>>>> old or having no longer contributors (project manager, POS, etc.)
>>>>> who need support, visibility, even if they are not added to the
>>>>> OFBiz project.
>>>>> A first approach was discussed with GIT. It can allow everyone to
>>>>> share their work more easily with branch feature. Which is good
>>>>> but not the best in my opinion.
>>>>>
>>>>> Another topic that is important to me is the functional part of
>>>>> OFBiz.
>>>>> Sharan explained me about its willingness to invest energy to make
>>>>> the software more functional, and if it's possible to have a
>>>>> version with ERP oriented for small businesses with minimal
>>>>> features but easy to use. Like growERP or TerCompta offer. Using
>>>>> OFBiz framework but simplify the UI to allow the software to be
>>>>> used intuitively without modifications.
>>>>>
>>>>> These initiatives come up against the model of OFBiz project. Who
>>>>> has still not decided whether it is an ERP, in which case it needs
>>>>> to adjust its UI or an automation of enterprise processes
>>>>> framework, which involves getting rid of unnecessary features
>>>>> dedicated to ERP.
>>>>>
>>>>> There are several solutions that could help to make better the
>>>>> model of OFBiz and satisfy the entire community.
>>>>> The first solution would be to limit the “OFBiz framewok” project
>>>>> framework for automation enterprise processes and to have another
>>>>> “OFBiz ERP” project which would use the framework as a basis, and
>>>>> which would provide a user-friendly UI and dedicated tools to ERP.
>>>>>
>>>>> The second option is to find a way to cut the project in
>>>>> extensions. This solution would have the opportunity to clean the
>>>>> framework and have features as micro projects and therefore no
>>>>> longer a monolithic software.
>>>>>
>>>>> I see a lot of debate about adding new functionality that allow to
>>>>> improve development, compile, manage sources, merge with another
>>>>> framework, but the debate on the division of project extensions
>>>>> seems not to interest. It seems to me extremely important to
>>>>> facilitate development and therefore, ultimately, the visibility
>>>>> of the project in the developers community.
>>>>>
>>>>> At Nomaka, we initiated an effort starting from the first
>>>>> solution. We took OFBiz framework, deleted all the themes and
>>>>> created a new one. Then we redesigned the interface to match a
>>>>> basic ERP.
>>>>> We started with actor UI. Disabled existing screens and created
>>>>> new ones more functional and user-friendly.
>>>>>
>>>>> I find it a pity to work alone in my corner without being able to
>>>>> easily share my work, without taking advantage of the OFBiz
>>>>> community knowledge to guide me onthe right way.
>>>>> I wonder if we could work on this axis and balance the rigidity
>>>>> necessary to have a stable project and flexibility that allow to
>>>>> include non-committer contributions ...
>>>>>
>>>>> What do you think ?
>>>>>
>>>>> Julien.
>>>>>
>>>>
>>>
>>>
>>
>

[Jacques Le Roux]

Hi Julien,

Actually it's a very important topic. OFBiz indeed misses from the start a way to include extensions in a snap. OFBiz was created in 2001, then
components was seen as a way to introduce extensions. And it did not work too bad, see we are still there :).

Then microservices was not a hot-topic, and OFBiz was a bit ahead with SOA , then the EDA was introduced in OFBiz when it was obvious a workflow
engine was not the way. So in 2005 OFBiz had a state of art architecture. But then a new generation of concurrents (open source ERPs)  was emerging.
One of the most proeminent was OpenERP (now Odoo). Actually note that OFBiz has no real concurrents in the sense of no other is supported by a
community like we do here at Apache apart Adempiere, all others are owned by a company.

But there is a lesson we can take from Odoo, it's its extensions mechanism (I don't think other "concurrents" have the same extensions mechanism
available). Actually I don't know much about it, I never used it, and I know there are also issues with it (*spaghetti syndrome*) but the idea worked
also for other projects (not ERP) to build a strong community. I sometimes wonder if it's not a marketing way to build a community, but that another
topic and it would break the one we are currently discussing. Examples:
https://www.odoo.com/apps
https://www.drupal.org/project/extensions
https://github.com/django-extensions/django-extensions
http://www.magentocommerce.com/magento-connect/

So I agree about the functional part, as you call it, but the point is more the technical part: how to achieve this extensions mechanism.

I see 4 proposed ways for now:

 1. a patches manager as proposed by OFBiz-France
 2. Git branches and a Git ecosystem (like GitHub)
 3. Sub projects
 4. A microservices architecture

Sincerely, all have their limitations and drawbacks, and we should discuss them. Note that they are not antinomic and could be combined. In the end
it's a huge and risky effort, we need to clear about what to do, if ever we do something!

One last things I'd like to add, is I believe the current situation is because main OFBiz integrators are eCommerce sites providers (OFBiz has been
towed by eCommerce). So they have a minor interest in the ERP/backend side even if actually they know it's what distinguish them from other more
traditional eCommerce sites providers like Magento and the now declining OsCommerce (users ate too much *spaghetti)*.**Finally, this would not be
complete if I did not add my own rant. You can see the disinterest in the ERP side because those companies need to build specific UIs for their client
(whatever technology they use for that). So, since the jQuery effort, almost nothing has been done in widgets side. For backend I still find smarter
to generate HTML using widgets than to build all by hand, but this needs more love, it's unfortunately the neglected part of the framework :/

Jacques

Le 13/05/2015 08:56, Julien NICOLAS a écrit :

> Hi all,
>
> I was hopping more people will explain on this subject. It's exactly what I was thinking, that the functional part is less than the last priority of
> the project.
> I don't know exactly how I can do it but I really want to start something that will use OFBiz as a framework. If it can be done with the OFBiz
> community, it will be really good.
>
> Efforts exist but need people of the strong OFBiz community to be really better (GrowERP, BigFish, TERCompta, etc.).
>
> It's a pity that every new company that want to work with OFBiz must work on it's own version to be able to integrate it. I don't think it's a good
> thing for the project growing.
> And OFBiz community don't allow company to find easily other effort to enhance the software. And finally it seems that there is less than 5 peoples
> interested to work on this way.
>
> Maybe I'm wrong, functional is not as important as I thought...
>
> Sorry for the noise,
>
> Julien.
>
>
> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>> I agree with Julien's analysis.
>> If I say "sub-projects" again, Jacques will whack me upside the head but I really think that a restructuring of the way the architecture is
>> presented and developed would provide a number of benefits:
>> - increase community involvement with less work for the current key committers
>> - reduce or eliminate sub-optimal inter-component dependencies through clearer definitions and independent releases of components
>> - reduce mixing of core seed data with demo and customizable seed data and inter-component data confusion.
>> - facilitate the construction of components and add-ons that do not have undesirable or unknown side-affects
>> - facilitate the injection of a smart installer that would allow the selection of  components and templates as suggested at install time.
>> - facilitate the development of an OFBiz marketplace for add-ons and industry-specific configurations.
>> - make the role of the framework as a base for other products much clearer.
>> - possibly make it easier to "Moquify" the framework if the framework API can be made less implementation dependent - lots of issues here that
>> already have been fully ventilated last week.
>>
>> Ron
>>
>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>> Hi Julien,
>>>
>>> thank you for bringing this up!
>>>
>>> I don't think that this is of no interest in the community, it's just overlaid by the many other topics we are discussing currently. I personally
>>> think that all topics are worth to be discussed and elaborated, maybe they have to be prioritised a little bit more. Right now it's a little bit
>>> confusing and not easy to follow (and contribute to) the discussions besides daily business.
>>>
>>> I think it is an important topic to simplify the backend component's UI and have more sophisticated usability there. On the other hand, it is
>>> important to somehow show customers the powers of OFBiz and the many already set-up functionalities. It would be a big step forward if we find a
>>> way to make this customizeable. For an ERP, it would also be a big plus to have some kind of "business templates" (!= UI templates) on top of such
>>> a mechanism, like
>>>
>>> - Your customer sells products over the internet? - pull the ecommerce template
>>> - Your customer brews beer? - pull the manufacturing +x template
>>> - Your customer has a small business? - pull the corresponding template
>>> etc.
>>>
>>> I belive that would require different configuration mechanisms, more on a database level with a clever UI instead of many different property
>>> files. And maybe a tool to chain services together on base of  such a template.
>>>
>>> I won't reduce the functionality in OFBiz per se, as long as they are stable and/or have a maintainer.
>>>
>>> I know of at least one contributor who is also working on a more sophisticated UI, maybe he shows up here also ;-)
>>>
>>> So, without having a concrete plan or more thought-out ideas how to implement this, I would support such an effort.
>>>
>>> As a community, I think we have to find a way to channel the different interests from core technology work up to the business layer. Some kind of
>>> overall project management would help but would be difficult to install in an open community. Too many open building sites in parallel are not
>>> that efficient.
>>>
>>> Curious what others think...
>>>
>>> Regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>> Hello All,
>>>>
>>>> Since I work on the bootstrap theme in OFBiz, I have many thoughtful, carefully read the ofbiz community exchanges and spoke with some members of
>>>> the OFBiz community.
>>>> Today I am convinced that the OFBiz project is a framework that is not intended to be an ERP. Its OOTB user interface is a nightmare and is not
>>>> really user oriented.
>>>> Several topics that seem to have no link together, seems to be linked around the same idea.
>>>>
>>>> The first topic is about functionality of OFBiz.
>>>> On one hand, there is the OFBiz framework. It contains a user interface to show the possibility of OFBiz, but must be changed during integration.
>>>> It also includes functional oriented features. These features split the community between those who want to keep them in the project and those
>>>> who wish to exclude them.
>>>> On the other hand, there are new initiatives,abandoned projects, old or having no longer contributors (project manager, POS, etc.) who need
>>>> support, visibility, even if they are not added to the OFBiz project.
>>>> A first approach was discussed with GIT. It can allow everyone to share their work more easily with branch feature. Which is good but not the
>>>> best in my opinion.
>>>>
>>>> Another topic that is important to me is the functional part of OFBiz.
>>>> Sharan explained me about its willingness to invest energy to make the software more functional, and if it's possible to have a version with ERP
>>>> oriented for small businesses with minimal features but easy to use. Like growERP or TerCompta offer. Using OFBiz framework but simplify the UI
>>>> to allow the software to be used intuitively without modifications.
>>>>
>>>> These initiatives come up against the model of OFBiz project. Who has still not decided whether it is an ERP, in which case it needs to adjust
>>>> its UI or an automation of enterprise processes framework, which involves getting rid of unnecessary features dedicated to ERP.
>>>>
>>>> There are several solutions that could help to make better the model of OFBiz and satisfy the entire community.
>>>> The first solution would be to limit the “OFBiz framewok” project framework for automation enterprise processes and to have another “OFBiz ERP”
>>>> project which would use the framework as a basis, and which would provide a user-friendly UI and dedicated tools to ERP.
>>>>
>>>> The second option is to find a way to cut the project in extensions. This solution would have the opportunity to clean the framework and have
>>>> features as micro projects and therefore no longer a monolithic software.
>>>>
>>>> I see a lot of debate about adding new functionality that allow to improve development, compile, manage sources, merge with another framework,
>>>> but the debate on the division of project extensions seems not to interest. It seems to me extremely important to facilitate development and
>>>> therefore, ultimately, the visibility of the project in the developers community.
>>>>
>>>> At Nomaka, we initiated an effort starting from the first solution. We took OFBiz framework, deleted all the themes and created a new one. Then
>>>> we redesigned the interface to match a basic ERP.
>>>> We started with actor UI. Disabled existing screens and created new ones more functional and user-friendly.
>>>>
>>>> I find it a pity to work alone in my corner without being able to easily share my work, without taking advantage of the OFBiz community knowledge
>>>> to guide me onthe right way.
>>>> I wonder if we could work on this axis and balance the rigidity necessary to have a stable project and flexibility that allow to include
>>>> non-committer contributions ...
>>>>
>>>> What do you think ?
>>>>
>>>> Julien.
>>>>
>>>
>>
>>
>
>
>

[Jacopo Cappellato-5]

On May 13, 2015, at 10:15 AM, Julien NICOLAS <[hidden email]> wrote:

> Problem is, I want to enhance OFBiz functional part (GUI, Theme, user experience, etc.) but It's really difficult to share it with the community because it must be included in the whole project and it's hard to share your work.

Hi Julien,

this is an interesting topic, thanks for sharing your thoughts.
Some time ago I proposed to move all entity definitions from the applications components into a separate one; this component could also contain crud/generic services: in this way it will be easier to deploy the framework+data-model without the user interfaces that are not as generic and universal as the data model is.
In my opinion this would be a good step in the right direction and it would be very easy to implement.

Regards,

Jacopo

[Jacopo Cappellato-5]

A minor note: I think that Jacques is using the word "concurrent" for "competitor".
It is quite easy for me to understand the meaning because we have a similar one in Italian (as I guess in French): "concorrente". :-)

Jacopo

On May 13, 2015, at 10:26 AM, Jacques Le Roux <[hidden email]> wrote:

> Hi Julien,
>
> Actually it's a very important topic. OFBiz indeed misses from the start a way to include extensions in a snap. OFBiz was created in 2001, then components was seen as a way to introduce extensions. And it did not work too bad, see we are still there :).
>
> Then microservices was not a hot-topic, and OFBiz was a bit ahead with SOA , then the EDA was introduced in OFBiz when it was obvious a workflow engine was not the way. So in 2005 OFBiz had a state of art architecture. But then a new generation of concurrents (open source ERPs)  was emerging. One of the most proeminent was OpenERP (now Odoo). Actually note that OFBiz has no real concurrents in the sense of no other is supported by a community like we do here at Apache apart Adempiere, all others are owned by a company.
>
> But there is a lesson we can take from Odoo, it's its extensions mechanism (I don't think other "concurrents" have the same extensions mechanism available). Actually I don't know much about it, I never used it, and I know there are also issues with it (*spaghetti syndrome*) but the idea worked also for other projects (not ERP) to build a strong community. I sometimes wonder if it's not a marketing way to build a community, but that another topic and it would break the one we are currently discussing. Examples:
> https://www.odoo.com/apps
> https://www.drupal.org/project/extensions
> https://github.com/django-extensions/django-extensions
> http://www.magentocommerce.com/magento-connect/
>
> So I agree about the functional part, as you call it, but the point is more the technical part: how to achieve this extensions mechanism.
>
> I see 4 proposed ways for now:
>
> 1. a patches manager as proposed by OFBiz-France
> 2. Git branches and a Git ecosystem (like GitHub)
> 3. Sub projects
> 4. A microservices architecture
>
> Sincerely, all have their limitations and drawbacks, and we should discuss them. Note that they are not antinomic and could be combined. In the end it's a huge and risky effort, we need to clear about what to do, if ever we do something!
>
> One last things I'd like to add, is I believe the current situation is because main OFBiz integrators are eCommerce sites providers (OFBiz has been towed by eCommerce). So they have a minor interest in the ERP/backend side even if actually they know it's what distinguish them from other more traditional eCommerce sites providers like Magento and the now declining OsCommerce (users ate too much *spaghetti)*.**Finally, this would not be complete if I did not add my own rant. You can see the disinterest in the ERP side because those companies need to build specific UIs for their client (whatever technology they use for that). So, since the jQuery effort, almost nothing has been done in widgets side. For backend I still find smarter to generate HTML using widgets than to build all by hand, but this needs more love, it's unfortunately the neglected part of the framework :/
>
> Jacques
>
> Le 13/05/2015 08:56, Julien NICOLAS a écrit :
>> Hi all,
>>
>> I was hopping more people will explain on this subject. It's exactly what I was thinking, that the functional part is less than the last priority of the project.
>> I don't know exactly how I can do it but I really want to start something that will use OFBiz as a framework. If it can be done with the OFBiz community, it will be really good.
>>
>> Efforts exist but need people of the strong OFBiz community to be really better (GrowERP, BigFish, TERCompta, etc.).
>>
>> It's a pity that every new company that want to work with OFBiz must work on it's own version to be able to integrate it. I don't think it's a good thing for the project growing.
>> And OFBiz community don't allow company to find easily other effort to enhance the software. And finally it seems that there is less than 5 peoples interested to work on this way.
>>
>> Maybe I'm wrong, functional is not as important as I thought...
>>
>> Sorry for the noise,
>>
>> Julien.
>>
>>
>> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>>> I agree with Julien's analysis.
>>> If I say "sub-projects" again, Jacques will whack me upside the head but I really think that a restructuring of the way the architecture is presented and developed would provide a number of benefits:
>>> - increase community involvement with less work for the current key committers
>>> - reduce or eliminate sub-optimal inter-component dependencies through clearer definitions and independent releases of components
>>> - reduce mixing of core seed data with demo and customizable seed data and inter-component data confusion.
>>> - facilitate the construction of components and add-ons that do not have undesirable or unknown side-affects
>>> - facilitate the injection of a smart installer that would allow the selection of  components and templates as suggested at install time.
>>> - facilitate the development of an OFBiz marketplace for add-ons and industry-specific configurations.
>>> - make the role of the framework as a base for other products much clearer.
>>> - possibly make it easier to "Moquify" the framework if the framework API can be made less implementation dependent - lots of issues here that already have been fully ventilated last week.
>>>
>>> Ron
>>>
>>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>>> Hi Julien,
>>>>
>>>> thank you for bringing this up!
>>>>
>>>> I don't think that this is of no interest in the community, it's just overlaid by the many other topics we are discussing currently. I personally think that all topics are worth to be discussed and elaborated, maybe they have to be prioritised a little bit more. Right now it's a little bit confusing and not easy to follow (and contribute to) the discussions besides daily business.
>>>>
>>>> I think it is an important topic to simplify the backend component's UI and have more sophisticated usability there. On the other hand, it is important to somehow show customers the powers of OFBiz and the many already set-up functionalities. It would be a big step forward if we find a way to make this customizeable. For an ERP, it would also be a big plus to have some kind of "business templates" (!= UI templates) on top of such a mechanism, like
>>>>
>>>> - Your customer sells products over the internet? - pull the ecommerce template
>>>> - Your customer brews beer? - pull the manufacturing +x template
>>>> - Your customer has a small business? - pull the corresponding template
>>>> etc.
>>>>
>>>> I belive that would require different configuration mechanisms, more on a database level with a clever UI instead of many different property files. And maybe a tool to chain services together on base of  such a template.
>>>>
>>>> I won't reduce the functionality in OFBiz per se, as long as they are stable and/or have a maintainer.
>>>>
>>>> I know of at least one contributor who is also working on a more sophisticated UI, maybe he shows up here also ;-)
>>>>
>>>> So, without having a concrete plan or more thought-out ideas how to implement this, I would support such an effort.
>>>>
>>>> As a community, I think we have to find a way to channel the different interests from core technology work up to the business layer. Some kind of overall project management would help but would be difficult to install in an open community. Too many open building sites in parallel are not that efficient.
>>>>
>>>> Curious what others think...
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>> ecomify GmbH
>>>> www.ecomify.de
>>>>
>>>>
>>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>>> Hello All,
>>>>>
>>>>> Since I work on the bootstrap theme in OFBiz, I have many thoughtful, carefully read the ofbiz community exchanges and spoke with some members of the OFBiz community.
>>>>> Today I am convinced that the OFBiz project is a framework that is not intended to be an ERP. Its OOTB user interface is a nightmare and is not really user oriented.
>>>>> Several topics that seem to have no link together, seems to be linked around the same idea.
>>>>>
>>>>> The first topic is about functionality of OFBiz.
>>>>> On one hand, there is the OFBiz framework. It contains a user interface to show the possibility of OFBiz, but must be changed during integration. It also includes functional oriented features. These features split the community between those who want to keep them in the project and those who wish to exclude them.
>>>>> On the other hand, there are new initiatives,abandoned projects, old or having no longer contributors (project manager, POS, etc.) who need support, visibility, even if they are not added to the OFBiz project.
>>>>> A first approach was discussed with GIT. It can allow everyone to share their work more easily with branch feature. Which is good but not the best in my opinion.
>>>>>
>>>>> Another topic that is important to me is the functional part of OFBiz.
>>>>> Sharan explained me about its willingness to invest energy to make the software more functional, and if it's possible to have a version with ERP oriented for small businesses with minimal features but easy to use. Like growERP or TerCompta offer. Using OFBiz framework but simplify the UI to allow the software to be used intuitively without modifications.
>>>>>
>>>>> These initiatives come up against the model of OFBiz project. Who has still not decided whether it is an ERP, in which case it needs to adjust its UI or an automation of enterprise processes framework, which involves getting rid of unnecessary features dedicated to ERP.
>>>>>
>>>>> There are several solutions that could help to make better the model of OFBiz and satisfy the entire community.
>>>>> The first solution would be to limit the “OFBiz framewok” project framework for automation enterprise processes and to have another “OFBiz ERP” project which would use the framework as a basis, and which would provide a user-friendly UI and dedicated tools to ERP.
>>>>>
>>>>> The second option is to find a way to cut the project in extensions. This solution would have the opportunity to clean the framework and have features as micro projects and therefore no longer a monolithic software.
>>>>>
>>>>> I see a lot of debate about adding new functionality that allow to improve development, compile, manage sources, merge with another framework, but the debate on the division of project extensions seems not to interest. It seems to me extremely important to facilitate development and therefore, ultimately, the visibility of the project in the developers community.
>>>>>
>>>>> At Nomaka, we initiated an effort starting from the first solution. We took OFBiz framework, deleted all the themes and created a new one. Then we redesigned the interface to match a basic ERP.
>>>>> We started with actor UI. Disabled existing screens and created new ones more functional and user-friendly.
>>>>>
>>>>> I find it a pity to work alone in my corner without being able to easily share my work, without taking advantage of the OFBiz community knowledge to guide me onthe right way.
>>>>> I wonder if we could work on this axis and balance the rigidity necessary to have a stable project and flexibility that allow to include non-committer contributions ...
>>>>>
>>>>> What do you think ?
>>>>>
>>>>> Julien.
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>

[Jacopo Cappellato-5]

Jacques,

very interesting analysis, thank you.

Jacopo

On May 13, 2015, at 10:26 AM, Jacques Le Roux <[hidden email]> wrote:

> Hi Julien,
>
> Actually it's a very important topic. OFBiz indeed misses from the start a way to include extensions in a snap. OFBiz was created in 2001, then components was seen as a way to introduce extensions. And it did not work too bad, see we are still there :).
>
> Then microservices was not a hot-topic, and OFBiz was a bit ahead with SOA , then the EDA was introduced in OFBiz when it was obvious a workflow engine was not the way. So in 2005 OFBiz had a state of art architecture. But then a new generation of concurrents (open source ERPs)  was emerging. One of the most proeminent was OpenERP (now Odoo). Actually note that OFBiz has no real concurrents in the sense of no other is supported by a community like we do here at Apache apart Adempiere, all others are owned by a company.
>
> But there is a lesson we can take from Odoo, it's its extensions mechanism (I don't think other "concurrents" have the same extensions mechanism available). Actually I don't know much about it, I never used it, and I know there are also issues with it (*spaghetti syndrome*) but the idea worked also for other projects (not ERP) to build a strong community. I sometimes wonder if it's not a marketing way to build a community, but that another topic and it would break the one we are currently discussing. Examples:
> https://www.odoo.com/apps
> https://www.drupal.org/project/extensions
> https://github.com/django-extensions/django-extensions
> http://www.magentocommerce.com/magento-connect/
>
> So I agree about the functional part, as you call it, but the point is more the technical part: how to achieve this extensions mechanism.
>
> I see 4 proposed ways for now:
>
> 1. a patches manager as proposed by OFBiz-France
> 2. Git branches and a Git ecosystem (like GitHub)
> 3. Sub projects
> 4. A microservices architecture
>
> Sincerely, all have their limitations and drawbacks, and we should discuss them. Note that they are not antinomic and could be combined. In the end it's a huge and risky effort, we need to clear about what to do, if ever we do something!
>
> One last things I'd like to add, is I believe the current situation is because main OFBiz integrators are eCommerce sites providers (OFBiz has been towed by eCommerce). So they have a minor interest in the ERP/backend side even if actually they know it's what distinguish them from other more traditional eCommerce sites providers like Magento and the now declining OsCommerce (users ate too much *spaghetti)*.**Finally, this would not be complete if I did not add my own rant. You can see the disinterest in the ERP side because those companies need to build specific UIs for their client (whatever technology they use for that). So, since the jQuery effort, almost nothing has been done in widgets side. For backend I still find smarter to generate HTML using widgets than to build all by hand, but this needs more love, it's unfortunately the neglected part of the framework :/
>
> Jacques
>
> Le 13/05/2015 08:56, Julien NICOLAS a écrit :
>> Hi all,
>>
>> I was hopping more people will explain on this subject. It's exactly what I was thinking, that the functional part is less than the last priority of the project.
>> I don't know exactly how I can do it but I really want to start something that will use OFBiz as a framework. If it can be done with the OFBiz community, it will be really good.
>>
>> Efforts exist but need people of the strong OFBiz community to be really better (GrowERP, BigFish, TERCompta, etc.).
>>
>> It's a pity that every new company that want to work with OFBiz must work on it's own version to be able to integrate it. I don't think it's a good thing for the project growing.
>> And OFBiz community don't allow company to find easily other effort to enhance the software. And finally it seems that there is less than 5 peoples interested to work on this way.
>>
>> Maybe I'm wrong, functional is not as important as I thought...
>>
>> Sorry for the noise,
>>
>> Julien.
>>
>>
>> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>>> I agree with Julien's analysis.
>>> If I say "sub-projects" again, Jacques will whack me upside the head but I really think that a restructuring of the way the architecture is presented and developed would provide a number of benefits:
>>> - increase community involvement with less work for the current key committers
>>> - reduce or eliminate sub-optimal inter-component dependencies through clearer definitions and independent releases of components
>>> - reduce mixing of core seed data with demo and customizable seed data and inter-component data confusion.
>>> - facilitate the construction of components and add-ons that do not have undesirable or unknown side-affects
>>> - facilitate the injection of a smart installer that would allow the selection of  components and templates as suggested at install time.
>>> - facilitate the development of an OFBiz marketplace for add-ons and industry-specific configurations.
>>> - make the role of the framework as a base for other products much clearer.
>>> - possibly make it easier to "Moquify" the framework if the framework API can be made less implementation dependent - lots of issues here that already have been fully ventilated last week.
>>>
>>> Ron
>>>
>>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>>> Hi Julien,
>>>>
>>>> thank you for bringing this up!
>>>>
>>>> I don't think that this is of no interest in the community, it's just overlaid by the many other topics we are discussing currently. I personally think that all topics are worth to be discussed and elaborated, maybe they have to be prioritised a little bit more. Right now it's a little bit confusing and not easy to follow (and contribute to) the discussions besides daily business.
>>>>
>>>> I think it is an important topic to simplify the backend component's UI and have more sophisticated usability there. On the other hand, it is important to somehow show customers the powers of OFBiz and the many already set-up functionalities. It would be a big step forward if we find a way to make this customizeable. For an ERP, it would also be a big plus to have some kind of "business templates" (!= UI templates) on top of such a mechanism, like
>>>>
>>>> - Your customer sells products over the internet? - pull the ecommerce template
>>>> - Your customer brews beer? - pull the manufacturing +x template
>>>> - Your customer has a small business? - pull the corresponding template
>>>> etc.
>>>>
>>>> I belive that would require different configuration mechanisms, more on a database level with a clever UI instead of many different property files. And maybe a tool to chain services together on base of  such a template.
>>>>
>>>> I won't reduce the functionality in OFBiz per se, as long as they are stable and/or have a maintainer.
>>>>
>>>> I know of at least one contributor who is also working on a more sophisticated UI, maybe he shows up here also ;-)
>>>>
>>>> So, without having a concrete plan or more thought-out ideas how to implement this, I would support such an effort.
>>>>
>>>> As a community, I think we have to find a way to channel the different interests from core technology work up to the business layer. Some kind of overall project management would help but would be difficult to install in an open community. Too many open building sites in parallel are not that efficient.
>>>>
>>>> Curious what others think...
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>> ecomify GmbH
>>>> www.ecomify.de
>>>>
>>>>
>>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>>> Hello All,
>>>>>
>>>>> Since I work on the bootstrap theme in OFBiz, I have many thoughtful, carefully read the ofbiz community exchanges and spoke with some members of the OFBiz community.
>>>>> Today I am convinced that the OFBiz project is a framework that is not intended to be an ERP. Its OOTB user interface is a nightmare and is not really user oriented.
>>>>> Several topics that seem to have no link together, seems to be linked around the same idea.
>>>>>
>>>>> The first topic is about functionality of OFBiz.
>>>>> On one hand, there is the OFBiz framework. It contains a user interface to show the possibility of OFBiz, but must be changed during integration. It also includes functional oriented features. These features split the community between those who want to keep them in the project and those who wish to exclude them.
>>>>> On the other hand, there are new initiatives,abandoned projects, old or having no longer contributors (project manager, POS, etc.) who need support, visibility, even if they are not added to the OFBiz project.
>>>>> A first approach was discussed with GIT. It can allow everyone to share their work more easily with branch feature. Which is good but not the best in my opinion.
>>>>>
>>>>> Another topic that is important to me is the functional part of OFBiz.
>>>>> Sharan explained me about its willingness to invest energy to make the software more functional, and if it's possible to have a version with ERP oriented for small businesses with minimal features but easy to use. Like growERP or TerCompta offer. Using OFBiz framework but simplify the UI to allow the software to be used intuitively without modifications.
>>>>>
>>>>> These initiatives come up against the model of OFBiz project. Who has still not decided whether it is an ERP, in which case it needs to adjust its UI or an automation of enterprise processes framework, which involves getting rid of unnecessary features dedicated to ERP.
>>>>>
>>>>> There are several solutions that could help to make better the model of OFBiz and satisfy the entire community.
>>>>> The first solution would be to limit the “OFBiz framewok” project framework for automation enterprise processes and to have another “OFBiz ERP” project which would use the framework as a basis, and which would provide a user-friendly UI and dedicated tools to ERP.
>>>>>
>>>>> The second option is to find a way to cut the project in extensions. This solution would have the opportunity to clean the framework and have features as micro projects and therefore no longer a monolithic software.
>>>>>
>>>>> I see a lot of debate about adding new functionality that allow to improve development, compile, manage sources, merge with another framework, but the debate on the division of project extensions seems not to interest. It seems to me extremely important to facilitate development and therefore, ultimately, the visibility of the project in the developers community.
>>>>>
>>>>> At Nomaka, we initiated an effort starting from the first solution. We took OFBiz framework, deleted all the themes and created a new one. Then we redesigned the interface to match a basic ERP.
>>>>> We started with actor UI. Disabled existing screens and created new ones more functional and user-friendly.
>>>>>
>>>>> I find it a pity to work alone in my corner without being able to easily share my work, without taking advantage of the OFBiz community knowledge to guide me onthe right way.
>>>>> I wonder if we could work on this axis and balance the rigidity necessary to have a stable project and flexibility that allow to include non-committer contributions ...
>>>>>
>>>>> What do you think ?
>>>>>
>>>>> Julien.
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>

[Jacques Le Roux]

Le 13/05/2015 10:31, Jacopo Cappellato a écrit :
> A minor note: I think that Jacques is using the word "concurrent" for "competitor".
> It is quite easy for me to understand the meaning because we have a similar one in Italian (as I guess in French): "concorrente". :-)

Right, from Latin indeed http://en.wiktionary.org/wiki/concurrent#Latin

Jacques

>
> Jacopo
>
> On May 13, 2015, at 10:26 AM, Jacques Le Roux <[hidden email]> wrote:
>
>> Hi Julien,
>>
>> Actually it's a very important topic. OFBiz indeed misses from the start a way to include extensions in a snap. OFBiz was created in 2001, then components was seen as a way to introduce extensions. And it did not work too bad, see we are still there :).
>>
>> Then microservices was not a hot-topic, and OFBiz was a bit ahead with SOA , then the EDA was introduced in OFBiz when it was obvious a workflow engine was not the way. So in 2005 OFBiz had a state of art architecture. But then a new generation of concurrents (open source ERPs)  was emerging. One of the most proeminent was OpenERP (now Odoo). Actually note that OFBiz has no real concurrents in the sense of no other is supported by a community like we do here at Apache apart Adempiere, all others are owned by a company.
>>
>> But there is a lesson we can take from Odoo, it's its extensions mechanism (I don't think other "concurrents" have the same extensions mechanism available). Actually I don't know much about it, I never used it, and I know there are also issues with it (*spaghetti syndrome*) but the idea worked also for other projects (not ERP) to build a strong community. I sometimes wonder if it's not a marketing way to build a community, but that another topic and it would break the one we are currently discussing. Examples:
>> https://www.odoo.com/apps
>> https://www.drupal.org/project/extensions
>> https://github.com/django-extensions/django-extensions
>> http://www.magentocommerce.com/magento-connect/
>>
>> So I agree about the functional part, as you call it, but the point is more the technical part: how to achieve this extensions mechanism.
>>
>> I see 4 proposed ways for now:
>>
>> 1. a patches manager as proposed by OFBiz-France
>> 2. Git branches and a Git ecosystem (like GitHub)
>> 3. Sub projects
>> 4. A microservices architecture
>>
>> Sincerely, all have their limitations and drawbacks, and we should discuss them. Note that they are not antinomic and could be combined. In the end it's a huge and risky effort, we need to clear about what to do, if ever we do something!
>>
>> One last things I'd like to add, is I believe the current situation is because main OFBiz integrators are eCommerce sites providers (OFBiz has been towed by eCommerce). So they have a minor interest in the ERP/backend side even if actually they know it's what distinguish them from other more traditional eCommerce sites providers like Magento and the now declining OsCommerce (users ate too much *spaghetti)*.**Finally, this would not be complete if I did not add my own rant. You can see the disinterest in the ERP side because those companies need to build specific UIs for their client (whatever technology they use for that). So, since the jQuery effort, almost nothing has been done in widgets side. For backend I still find smarter to generate HTML using widgets than to build all by hand, but this needs more love, it's unfortunately the neglected part of the framework :/
>>
>> Jacques
>>
>> Le 13/05/2015 08:56, Julien NICOLAS a écrit :
>>> Hi all,
>>>
>>> I was hopping more people will explain on this subject. It's exactly what I was thinking, that the functional part is less than the last priority of the project.
>>> I don't know exactly how I can do it but I really want to start something that will use OFBiz as a framework. If it can be done with the OFBiz community, it will be really good.
>>>
>>> Efforts exist but need people of the strong OFBiz community to be really better (GrowERP, BigFish, TERCompta, etc.).
>>>
>>> It's a pity that every new company that want to work with OFBiz must work on it's own version to be able to integrate it. I don't think it's a good thing for the project growing.
>>> And OFBiz community don't allow company to find easily other effort to enhance the software. And finally it seems that there is less than 5 peoples interested to work on this way.
>>>
>>> Maybe I'm wrong, functional is not as important as I thought...
>>>
>>> Sorry for the noise,
>>>
>>> Julien.
>>>
>>>
>>> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>>>> I agree with Julien's analysis.
>>>> If I say "sub-projects" again, Jacques will whack me upside the head but I really think that a restructuring of the way the architecture is presented and developed would provide a number of benefits:
>>>> - increase community involvement with less work for the current key committers
>>>> - reduce or eliminate sub-optimal inter-component dependencies through clearer definitions and independent releases of components
>>>> - reduce mixing of core seed data with demo and customizable seed data and inter-component data confusion.
>>>> - facilitate the construction of components and add-ons that do not have undesirable or unknown side-affects
>>>> - facilitate the injection of a smart installer that would allow the selection of  components and templates as suggested at install time.
>>>> - facilitate the development of an OFBiz marketplace for add-ons and industry-specific configurations.
>>>> - make the role of the framework as a base for other products much clearer.
>>>> - possibly make it easier to "Moquify" the framework if the framework API can be made less implementation dependent - lots of issues here that already have been fully ventilated last week.
>>>>
>>>> Ron
>>>>
>>>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>>>> Hi Julien,
>>>>>
>>>>> thank you for bringing this up!
>>>>>
>>>>> I don't think that this is of no interest in the community, it's just overlaid by the many other topics we are discussing currently. I personally think that all topics are worth to be discussed and elaborated, maybe they have to be prioritised a little bit more. Right now it's a little bit confusing and not easy to follow (and contribute to) the discussions besides daily business.
>>>>>
>>>>> I think it is an important topic to simplify the backend component's UI and have more sophisticated usability there. On the other hand, it is important to somehow show customers the powers of OFBiz and the many already set-up functionalities. It would be a big step forward if we find a way to make this customizeable. For an ERP, it would also be a big plus to have some kind of "business templates" (!= UI templates) on top of such a mechanism, like
>>>>>
>>>>> - Your customer sells products over the internet? - pull the ecommerce template
>>>>> - Your customer brews beer? - pull the manufacturing +x template
>>>>> - Your customer has a small business? - pull the corresponding template
>>>>> etc.
>>>>>
>>>>> I belive that would require different configuration mechanisms, more on a database level with a clever UI instead of many different property files. And maybe a tool to chain services together on base of  such a template.
>>>>>
>>>>> I won't reduce the functionality in OFBiz per se, as long as they are stable and/or have a maintainer.
>>>>>
>>>>> I know of at least one contributor who is also working on a more sophisticated UI, maybe he shows up here also ;-)
>>>>>
>>>>> So, without having a concrete plan or more thought-out ideas how to implement this, I would support such an effort.
>>>>>
>>>>> As a community, I think we have to find a way to channel the different interests from core technology work up to the business layer. Some kind of overall project management would help but would be difficult to install in an open community. Too many open building sites in parallel are not that efficient.
>>>>>
>>>>> Curious what others think...
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Brohl
>>>>> ecomify GmbH
>>>>> www.ecomify.de
>>>>>
>>>>>
>>>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>>>> Hello All,
>>>>>>
>>>>>> Since I work on the bootstrap theme in OFBiz, I have many thoughtful, carefully read the ofbiz community exchanges and spoke with some members of the OFBiz community.
>>>>>> Today I am convinced that the OFBiz project is a framework that is not intended to be an ERP. Its OOTB user interface is a nightmare and is not really user oriented.
>>>>>> Several topics that seem to have no link together, seems to be linked around the same idea.
>>>>>>
>>>>>> The first topic is about functionality of OFBiz.
>>>>>> On one hand, there is the OFBiz framework. It contains a user interface to show the possibility of OFBiz, but must be changed during integration. It also includes functional oriented features. These features split the community between those who want to keep them in the project and those who wish to exclude them.
>>>>>> On the other hand, there are new initiatives,abandoned projects, old or having no longer contributors (project manager, POS, etc.) who need support, visibility, even if they are not added to the OFBiz project.
>>>>>> A first approach was discussed with GIT. It can allow everyone to share their work more easily with branch feature. Which is good but not the best in my opinion.
>>>>>>
>>>>>> Another topic that is important to me is the functional part of OFBiz.
>>>>>> Sharan explained me about its willingness to invest energy to make the software more functional, and if it's possible to have a version with ERP oriented for small businesses with minimal features but easy to use. Like growERP or TerCompta offer. Using OFBiz framework but simplify the UI to allow the software to be used intuitively without modifications.
>>>>>>
>>>>>> These initiatives come up against the model of OFBiz project. Who has still not decided whether it is an ERP, in which case it needs to adjust its UI or an automation of enterprise processes framework, which involves getting rid of unnecessary features dedicated to ERP.
>>>>>>
>>>>>> There are several solutions that could help to make better the model of OFBiz and satisfy the entire community.
>>>>>> The first solution would be to limit the “OFBiz framewok” project framework for automation enterprise processes and to have another “OFBiz ERP” project which would use the framework as a basis, and which would provide a user-friendly UI and dedicated tools to ERP.
>>>>>>
>>>>>> The second option is to find a way to cut the project in extensions. This solution would have the opportunity to clean the framework and have features as micro projects and therefore no longer a monolithic software.
>>>>>>
>>>>>> I see a lot of debate about adding new functionality that allow to improve development, compile, manage sources, merge with another framework, but the debate on the division of project extensions seems not to interest. It seems to me extremely important to facilitate development and therefore, ultimately, the visibility of the project in the developers community.
>>>>>>
>>>>>> At Nomaka, we initiated an effort starting from the first solution. We took OFBiz framework, deleted all the themes and created a new one. Then we redesigned the interface to match a basic ERP.
>>>>>> We started with actor UI. Disabled existing screens and created new ones more functional and user-friendly.
>>>>>>
>>>>>> I find it a pity to work alone in my corner without being able to easily share my work, without taking advantage of the OFBiz community knowledge to guide me onthe right way.
>>>>>> I wonder if we could work on this axis and balance the rigidity necessary to have a stable project and flexibility that allow to include non-committer contributions ...
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>> Julien.
>>>>>>
>>>>
>>>
>>>
>
>