Hi Paul,
Inline...
Paul Piper wrote:
Here is what I think:
· Is Apache OFBiz an eCommerce or an ERP System?
Apache OFBiz is marketed as an eCommerce System, but the eCommerce App is a
special purpose application. This doesn't mean that it cannot be both, but
if you are marketing Apache OFBiz as a big eCommerce System (competing with
Hybris, Intershop and IBM Websphere on the market), then it should focus on
that. Don't get me wrong, the overall architecture underneath aims at being
great for much more than the eCommerce App (clearly it is aiming to be used
for all business processes), but I think here is where we fail to show
Apache OFBiz at what it is. By losing focus on the eCommerce aspect of it
all, we fail to market it as a whole.
From the main page on site <<Apache OFBiz (The Apache Open For Business
Project) is an open source enterprise automation software
project>> But I think you have a point, a lot of users are actually using it
primarily because they needed an eCommerce site.
It seems it's mostly a marketing decision.
· Target company size & clients
I think there is a big misunderstanding on our target group as a whole.
Apache OFBiz reaches a complexity so that it comes unattractive for small
size businesses. True, it features a lot for low costs, but then again, the
backoffice is overwhelming and customization takes a lot of effort so that
small size companies simply cannot implement Apache OFBiz successfully. If
they go that route they will have to pay for it with a lot of labor and or
by paying a lot of money. That is, in my opinion, why OFBiz competes with
Hybris, intershop, IBM Websphere and other rather big systems and is not
competing against Magento.
Truth to be told, and I think it derives from OFBiz history which was more
intially backed by independents working on smaller
projects than now OFBiz is sometimes used in.
· Contradicting Architecture
The current architecture defines framework, applications, special-purpose
and hot-deploy apps. Whereas the definition being a little vague on:
A good way to see it is described by Moqui: http://www.moqui.org/ even if I'm
abusing here (they are not the same but the same
"Decorator Pattern" is used)
o Framework - the basic stuff, entities, services and such
Moqui Core
o Applications - General Applications that play a role in most
environments
Moqui Mantle
o Special Purpose - hey look, you can do this, too (more of a demo
implementation or lesser used applications)
Moqui Crust
o Hot-Deploy applications - your own application/modification
Moqui Crust
I have no problem with Framework & Hot-Deploy, but I believe that the
current way Applications and Special-Purpose are used is at least a little
misleading. If we assume that Apache OFBiz is an eCommerce Application then
we must assume that the eCommerce Component is a core element of the
architecture. It isn't.
Apache OFBiz is not *ONLY* an eCommerce Application. View from a web agency it is. But there are much more type of actors which are
using OFBiz.
The same applies for payment partners and
distribution channels. All of these are special purpose applications. I
believe this goes hand in hand with a mind unset on whether Apache OFBiz is
an ERP or an eCommerce System.
Those can be used out of the context of a typical eCommerce application (B2B
for instance).
I would argue that either eCommerce is added
to applications and modified to be self-contained (I will explain this a bit
further in my next statement),
Mixing Mantle and Crust is not a good idea IMO. Keeping layers clearly separate is better IMO. OFBiz is a good tools to learn not
only itself but a lot of good practices. We should keep that in mind also...
or that eCommerce and all other special
purpose applications are dropped in favor of a modular design in which third
parties provide a store as a plugin to the Apache OFBiz framework.
This is the idea of the coming slim down action using Apache Extra as external
repository.
*Important note:* BTW I think using svn external could help http://svnbook.red-bean.com/en/1.0/ch07s03.html to keep Extras
components in sync
In case
of the latter Apache OFBiz should drop the eCommerce approach and rather
focus on creating a great eCommerce or ERP framework. It would also require
proper release planning and rollouts. Here a switch to maven could be
beneficial since the dependencies are easier to maintain - but that is
another discussion.
I prefer ant+Ivy over Maven. I also read a bit about BuildR:
http://buildr.apache.org/ it uses Ruby...
· Making it accessible
On a user level, I believe that OFbiz has a problem with showing too much to
the general public. Sure, OFBiz can do all a client would ask for, but the
problem is that the client doesn't see it. He sees all functions at once and
is hence losing out of sight what he was looking for. This is the true
reason for why all eCommerce Agencies start working on their own shop design
and drop functions wherever they can. It simply isn't attractive to
outsiders otherwise (though again, the structure itself and the
functionality it comes with is where ofbiz shines). I personally would argue
that keeping it down to a bare minimum could benefit all. Perhaps we could
create a list of supported functions rather than trying to show off all of
them at once.
This could be discussed indeed and has been already in the past which ended in the current status quo. What we could do rather is
explaining to user why it's like that on main OFBiz site page and especially with a note on all main application pages. I found that
adding small notes (few lines at max) in screens can help much new comers.
The functions can remain as is. The same can be said about the
backoffice, where we show off functionalities that aren't of interest to the
key-users (a marketing person is only interested in the marketing app, a
product manager only in the product manager etc.).
Ha you see, you are really focused on web agency actitivy when I have a wider view. So the comment about stands really for the
ERP/backend side. For the eCommerce I tend to agree with you that some parts could be removed (forums, pools, blogs). But even ther
I'd prefer to keep them and explain why they are there and how easy it can be pruned (still few lines)
Here we fail, by keeping
cross references to other apps, instead of opting for intuitive wizards or
forms that the user can rely on. Simplicity is key.
I don't agree, but we could indeed have a common slimed down eCommerce application (named tinyecommerce?) in Extras, which is the
way we are considering to handle things now. I say common because I know few companies have already their. Now this would need to
come on a common ground. Could be a new thread...
On a developer level, OFBiz has a problem with keeping it easy to work with.
The structure in its own is designed for reusability, but at the same time
OFBiz fails to make it easy to customize. The current way widgets are used
are confusing to many outsiders - the cross references are simply
overwhelming. So I would argue we need better tools and opt for a clear
design goal of each application. At the same time the confusing architecture
of the eCommerce application makes it more difficult to customize the shop
than it has to be. Most people will probably look at OFBiz as an alternative
to another eCommerce System. We basically show off all the eCommerce App can
do by providing a "demo" with the special purpose application. However, we
made it so that the eCommerce app is not self-contained, meaning that she
heavily relies on screens and widgets that derive from the other
applications.
The tinyecommerce could avoid this. Each aplication README could explain why
and how..
This means that we have a conflict of interest here: we want
people to customize, but at the same time they cannot do that, because they
will affect the other core applications. This is the sole reason to why all
developers either begin to copy the ftls into the eCommerce application or
another reasons why eCommerce agencies build their own version of the store.
OOTB the uis are demos, nothing else. But yes, we should try to improve not only new comers experience but also reusability across
projects.
There is probably a lot more that I could add, but I really want to start a
discussion with you guys. As I said, I myself and ilscipio are really eager
to contribute more in the future and we would love to push OFBiz into a
direction that is beneficial to all of us J
Looking forward :o)
Jacques
Cheers,
Paul
---
Paul Piper
Geschäftsführer
Web: <http://www.ilscipio.com/> http://www.ilscipio.com
Tel: (+49) 611-94589441
Mobil: (+49) 176-63283066
Fax: (+49) 611-94589449
eMail: <mailto:p...@ilscipio.com> p...@ilscipio.com
ilscipio GmbH
Am Drosselschlag 7
D-35452 Heuchelheim
Germany
