Dear Paul, and all others providing feedback before me,

Here are my thought on this subject and other mail treads that have spawned
recently regarding the road ahead:

Is OFbiz an eCommerce solution or an ERP system?

I believe OFBiz (the product) is an eco-system of Business Applications
supported by a sound framework and maintained by a community of developers
and System Integrators. For me, it doesn’t matter whether the individual
implemented eco-system consists of nothing but the ecommerce solution on
top of the components in the ‘applications’-folder and the framework or
that such an implementation consists of a well extended HR solution + some
specials (to name a few examples. It enables us to adhere to any scenario.
That is the strength of the product.



When I implement OFBiz at a customer’s where the focus is on secondment and
project management + HR functionality and FICO, the first that get moved
from ‘Special Purpose’ to ‘Applications’ are the Scrum and Project Mgr
solutions. And for that implementation all redundant components are removed
(e.g. pos, ecommerce, ebay and such, but also example). We want to deliver
lean solutions.

If the focus of a customer is B2B ecommerce we remove what is unwanted
also. But in all cases, this is done in consultation with the customer.
Customer satisfaction is king!



Having said that, I do believe that the product has reached a state where
there is needed more than just the love and convictions of developers. It
needs clear and elaborate statements on functionality, sound examples that
are well documented and explained. It needs explanation on possible
implementation scenarios and more.



*Re eCommerce*

I believe that at the moment this can best be positioned between ecommerce
add-on in WCM solutions, like WordPress, Joomla, Drupal etc, and on the
other side of the spectrum solutions like Magento.



In the lower part of the spectrum (WCM-plugins) besides the webshop-plugin
the customer needs also plugins to deal with logistics and payment. And
what they get, besides a shop front-end, is a poor solution regarding
catalog/product mgt, price ruling, promo’s etc and in house logistics
(warehousing, picking and packing), combined with a poor separation of
responsibilities and functions (organisational).



I also believe that the eCommerce eco-system, given that it will get a
dedicated visionary team of business consultants and developers, can be
enhanced to compete with solutions like Magento et all. And yes and again,
it all has to to with customer expectations and satisfaction. Given that
little love has been spent on the theme and was left to the individual
System Integrators, the proposition is difficult to make.


Contradicting architecture

I agree that current architecture is hindering growth. Having apps in the
‘applications’, ‘specialpurpose’ and ‘hot-deploy’ is a matter of taste. I
guess it was decided upon in the early days of the project and since then
been regarded as cast in stone.

But what is more important is the fact that a number of screens and forms
in applications.are dependant on screens and form in other applications
wherever they are found. Reuse of services I agree to, because for that is
the intention of the solutions in the framework (and found in the framework
folder). But each application should be as much self providing (self
contained?) as possible, because each application is following a different
business purpose and should therefore be able to be run as contained as
possible. Having this it would help to find per application that dedicated
team of business consultants and developers to provide the love and the
roadmap for each. And that is also required from a marketing point of view.
What applies to the eCommerce solution also applies to any other app (see
above).



Yes, current setup of the community where we have a dedicated few that
commit to everything (our committers, who deserve thanks and respect for
the effort they spend assisting us) and where there are to few who have
their focus on any specific application, hinders the adoption of OFBiz. But
recent discussions in this forum have gotten/are getting us on the same
page with respect to the heading of the community and the product. And I
believe that it is not only a destination, but also a journey.



Having applications in either sub projects in current OFBiz community setup
or outside and under no guidance/control of the community is again a matter
of taste. But I believe that having any application as dedicated sub
project will enhance the community aspects more (despite the increase in
paperwork) than having them as separate projects on another platform.



Any application needs to serve a business purpose/need, no one will deny
this. Any enhancement in functionality, change of setup and/or bug fix
should serve a community purpose as well. I believe in the past some
misjudgements have been made in the community. When contributors provide
feedback, enhancements, improvement and bug fixes their products have to go
through a vetting process by their peers and the committers.

But I have seen committers dumping code into the product without consulting
the community (contributors and committers) on the need (business and
community) and technical adherence to the framework for it. This is more of
an adoption hindrance than lacking technical maturity (which I think it
has). Both by peers and customers, because if we (the community) not act as
one, there is no community that supports the product
Make it accessible

This is more a marketing issue than a technical one. OotB, OFBiz enables
any of us to showcase eco-system functionality tailored to specific target
audiences, whether they be marketing and eCommerce, warehousing/logistics
oriented, FICO or Project Mgt/Workflow oriented. It is just a matter using
the right demo account for the need required.



When you show all while demoing with the admin account you’ll get
information overload and a difficulty in acceptance of any specific
solution.

My 2cts

With my utmost regards,


Pierre Smits

Reply via email to