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 <jacques.le.r...@les7arts.com>
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.
