David,
Yes, I meant to "market", that is, to "sell" a company/client on OFBiz.
Be it to "market" OFBiz to an end-user company or an IT company, it is still
difficult.
Even to competent IT companies, OFBiz often does give the impression that a lot of work still
needs to be done to reach baseline "marketability". It's like Cameron Smith's decision to go with
ZK. Not everyone thinks it is fun AND worthwhile to learn OFBiz, especially if it does take
several months to get minimally up to speed with it (for most users?). (Factors could be outdated
docs, unconsolidated docs, inconsistent implementation or structure at places, seriously
"work-in-progress", UI issues, I don't know for sure.)
Obviously, OFBiz cannot be sold entirely "as is", as OOTB-functional as it may be now. I cannot
possibly mean to "actually sell OFBiz as is". :)
Jonathon
David E Jones wrote:
Jonathon,
This is intriguing to me... if you aren't selling a re-package (like a
industry or business type specific specialization I'm assuming) of OFBiz
or expertise related to OFBiz, what exactly ARE you trying to sell?
I ask because just trying to "sell OFBiz" itself doesn't really make
sense, hopefully for obvious reasons (or unless by "sell" you mean
market rather than sell).
-David
Jonathon -- Improov wrote:
I have the same experience/difficulty trying to sell OFBiz. I've had
to either re-package OFBiz quite a bit, or I sell our expertise
related to OFBiz (we show them how fast we get a job done).
Jonathon
Cameron Smith wrote:
Skip, your criterion f is certainly a valid criterion for choosing a
technology to incorporate into the OFBiz core. It is not a valid
criteria for a commercial company like mine, in a competitive market,
which lives only if it satisfies its customers, in a cost-effective
way. That is why it did not feature in my analysis. Note that I am
not making a moral judgement here, simply a practical one.
Another related point which may be of interest, is that all
successful ERP systems (in terms of installed client base) have a
significant cost component related to customer-specific
configurations, parametrizations and new development. The market
leader, SAP, has a business model based on this. And as far as I
can glean, many OFBiz stalwarts like David and Jacques, also make a
living at least partially from this. This is not bad, it is
inherent in the complexity of the organizational and financial
interactions which an ERP automates and helps to manage. If you try
and ignore these by "just using whatever is free OOTB", you risk
putting in place a system which is either unusable or (worse), leads
to wrong decisions by the client firm. For instance stocking levels,
missing invoices, duplicated accounting entries. If you have ever
had to deal with issues like this in any capacity, you will know
what a nightmare they are.
In this context, I agree with your argument about the importance of
usability, but I would put it second. In first place I would put the
consistency of the Data Model and the processes which operate on it.
OFBiz is enormously flexible in this regard - but that flexibility
can be dangerous if you do not apply it correctly (particularly in
the attribution of business semantics to Type and Status table
values). This is one of the reasons why "OFBiz plus" systems,
focussed on certain more specific target markets, like Neogia and
Opentaps (and many others, including my company's) exist. I
actually do not bemoan their existence, I think they are a sign of
the fundamental quality of the core OFBiz code frameworks and data
model.
Finally, I would like to point out that my point of view is obviously
interested by the nature of my client market: SMEs in a developing
country. Bear in mind that the average Medium-sized enterprise in
Mozambique, has a gross turnover smaller than the average "Small"
enterprise in the USA. Although in terms of personnel it may have
more! The in-house IT capacity is not even in the same ballpark as
that of even a small US or UK manufacturing firm, for instance.
However the desire to automate and rationalize business processes is
equally strong.
Our experience when we tried initially to sell "pure" OFBiz (that is,
no code changes, only market specific parametrizations) to
Medium-scale clients here, is that they rejected it as too
overwhelmingly complex. We therefore developed our own custom
frontend and business rules, built on top of OFBiz and specialized
for the market and legal context here, and this has worked. ZK was,
in our analysis, the cheapest way to actually turn the
market-specific frontend design into running code. I do feel that
in what you say, there is an implicit, or perhaps subconscious, moral
judgement that anything which is not completely free for anyone to
use in commercial work, is bad. You are welcome to make that
judgement, but you should consider the whole context.
And certainly, we have built up a lot of expertise and improvements
which could be contributed back to OFBiz, especially in the area of
multi-company accounting. At the moment we have not prioritized this
giving back, partly because the initial feedback we received from the
community was fairly disinterested, and partly because we lack the
technical resources to spare on regression testing everything we put
back, against OOTB OFBiz.
However, I certainly think that every time an OFBiz-based system like
ours (or like Neogia, Opentaps, or your own company's system) is
installed in a client firm - instead of Navision or whatever - and
actually helps their business run better - then this can only be good
for OFBiz.
Anyway, just my 2 pence (well, actually more like 10 pence ;-)
cameron
----- Original Message ----
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: user@ofbiz.apache.org; Cameron Smith <[EMAIL PROTECTED]>
Sent: Sunday, 16 September, 2007 1:16:43 AM
Subject: RE: Rich client: licensing and other features
Cameron
"In term of the best value-for-money option, my (and my company's)
money is
on ZK. We bought commercial licenses, because our programmers receive
salaries, and every hour they spend reinventing the wheel instead of
using
someone else's wheel, however fun it may be, is an additional cost."
Well said and very true. However, there is no chance of integrating
ZK with
Ofbiz because of the licensing. There is a chance of doing it with
OpenLazlo. Ofbiz is an open source project and all benefit from the
collective work of the contributors. In addition, there are several
forks
which add to this work (Opentaps and Noegia (spelling?). On these
collective versions are built many real live implementations.
If we look at the usefulness, additions to Ofbiz benefit everyone.
Additions to Opentaps and Noegia benefit their users but not all Ofbiz
users. Changes to individual implementations benenit the
implementations
alone.
ZK can only ever fit in the last catagory.
It is my view that usability by the end user should be the most
important
consideration in an project. For this reason, a rich UI is highly
desirable
(maybe even manditory in some cases). It certainly is manditory in
the ones
I currently serve. I have therefore been evaluating the alternatives
and
have carefully read the two missives you wrote in the Ofbiz wiki and
TheServerSide.com. In the later case, you rated the various
technologies .
In your abcde list of criteria, I think you missed one, and that being
f. The number of users likely to benefit from it's adoption.
If that list was re-evaluated today including my f, Openlazlo would
win with
a 5 vs. 4.5.
Having said that, I personally like ZK better (with only a cursory
look at
both). But, for the communities sake, I may choose Openlazlo instead
(or
might use the existing Dojo).
Skip
___________________________________________________________
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good
http://uk.promotions.yahoo.com/forgood/environment.html
