Matt, what was the 300 - 400 hours for? I think that time would give you the capability to develop a standalone solution. If you want to use existing functionality (order mgt, invoicing, shipping, mfg, workeffort, etc) you need a lot more time depending on which functionality you use. I've been using ofbiz pretty heavily for nearly a year now, and have a 'good' understanding of developing solutions. In terms of the components, I am only really starting to get a deep understanding of how workefforts work. If fact some discussions I've had on the ML suggest that it may not be possible to know all of ofbiz at all. Instead you have to know how to find the answers to the areas you are trying to implement. However to know how to get the answers, you need to know the questions to ask. For this you need a good understanding of the overall system, for which there is no documentation except the universal data models.


Matt Warnock wrote:
Jaques, I think you have hit the nail on the head.  Specific responses
follow.

 Sat, 2010-02-06 at 17:02 +0100, Jacques Le Roux wrote:
From: "David E Jones" <d...@me.com>
On Feb 5, 2010, at 3:24 PM, Jacques Le Roux wrote:

One feeling I have though, PHBs are often pushing this way, note that I did not 
say that you are a PHB :p
Actually, I agree with you about "our" lack of interest for end user. I think 
this is due to the nature of OFBiz itself...
I won't agree there is any lack of interest for end-users. In fact, nearly 
everything in OFBiz is the result of some end-user or
other requesting functionality and being willing to sponsor its creation and 
contribution back to the project.
That's not exactly what I meant. Who are those end-users I was trying to talk 
about?  Technical aware persons, with influence in
companies but not enough time to look into every technical details (CTO, CIO, 
etc.). So they make (or at least help to make) very
important decisions (financial decision, I mean) for the future of their 
entreprises. And for that try to get as much as possible
information when making a choice between competitors. It's already a good news 
when they are considering OSS. Then chances are they
will compare projects. This is the target I was talking about. I personnaly 
think that a *huge* effort as been already done in OFBIz
to give them ways to make their choice. I was simply saying that we should try 
to continue this effort. Not only some persons as it
was some years ago, when the knowledge was not as shared as today. For instance 
the effort you made, David, on the Framework *open
and (now) free* documentation was certainly one the most important the project 
benefited. But I'm not quite sure (euphemism ;o) all
the decision-makers (or helpers) take the time to read it thourougly and to 
understand all subtleties while evaluating OFBiz. So
now, what we need is a satellite map (kind of marketing) to facilitate the 
decisions of these guys and, as much as possible, to make
them happy to choice OFBiz :o)

I admit it, I am one of these PHBs.  I am looking to implement OFBiz as
a long-term solution.  But the learning curve is steep.  Someone earlier
today estimated 300-400 hours.  That's 10 weeks, and I would submit
there ain't a PHB alive, tech-savvy or not, who that has that kind of
time.  Hiring it is expensive and assumes availability, which is
uncertain.
We need more ease of use OOTB (including clearer and more concise docs),
so that (as they say in perl) the easy  stuff is easy, and the hard
stuff is possible.

Some themes I foresee:

1) Why you should use the trunk instead of a release,
2) Why OFBIz is here to stay, independtly of the people working currently on it
3) Why... ok I'm lazy today (actually more knackered but who cares ;o)...

The theme 1 is one of the most important to me because it distinguishs OFBiz 
from its competitors, even VAR projects based on OFBiz.
It allows to follow the projects and, if inclined to, to contribute to it and 
to make it grow along your own needs.

As a PHB, themes 1 and 2 are really important to me, and I still don't
know that I made the "right" decision.  I just hope so.  Don't know how
you can satisfy me on point 2, but I watched a long time before pulling
the trigger (and I still haven't pulled the trigger except in devoting
resources to get into it).

On theme 1, I seemed to read, and was also told by experienced people
that I should be on 9.04, as it is more stable than trunk.  But I now
really doubt that should be the case, for several reasons.

1) development is progressing at a rapid rate, perhaps too rapid, and
the 9.04 code base is 10 months old now.

2) Bug fixes don't generally get applied to the releases, only to trunk.

3) It seems from discussions here that the underlying model doesn't
usually change much, and while code is being added, it isn't often
breaking prior code.  This is good.

So if I want to contribute (and I do, though I doubt my ability to
contribute much) I gather I should really be on trunk.
When you Google for "OFBiz" in France you get these pages in this order
http://ofbiz.apache.org/
http://fr.wikipedia.org/wiki/Apache_OFBiz
http://www.les7arts.com/assist/ArgumentaireOFBiz.htm

The 1st is obvious, the 2d I frequently garden and I'm happy to see it there, 
the 3d was a page I wrote in 2005, and is a free
translation (with a lot of changes and adaptation through the years) from an 
old Automation Group site page. Something is missing in
this document, the point 1. It's now months that I want to write something 
about that. Because I believe it's why so much projects
based on OFBiz did not evolve with OFBiz and became legacy. This is bad for 2 
reasons: these projects will not benefit of all the
enhancements OFBiz is able to give them, OFBiz does not benefit of potential 
long term contributors. From my experience, few
projects succeed in this way (even VAR projects) because they neglict this 
paramount point!

There are already a lot of things spreaded in the wiki. I will try, when I will 
get a chance, to make something more comprehensible
for new comers (I prefer this word than newbies or even worse noobs ;o)


I agree there is a lot in the Wiki, but it isn't very accessible.  A lot
of people (me included) are asking questions here, and being referred to
things they couldn't find on their own.  We need to fix that, and I'm
happy to help organize the wiki with some kind of index if I can.

Just to give old hands an idea what newbies (and PHBs) like me struggle
with, and need to find easily:

I am an OFBiz newbie, so that is the first issue.  But it isn't the only
one.  I am an SVN newbie too.  And a Java newbie.  And an XML newbie.
Haven't tried Eclipse yet.  Not to mention half a dozen other new
technologies here.

Java is just another language, I have learned about 20 to date, so that
isn't that big an issue, but there are a lot of libraries out there to
learn.
XML is close enough to HTML that I don't feel completely at sea, but I
don't know where all the DTDs are.  I see seed and configuration data
and the like stored in XML files which to me seems a very verbose and
error-prone way to edit/change data, but I assume there are reasons for
this that I don't understand yet.  Generally when I have seen XML files
used for configuration (like /etc/cups/printers.conf) you don't edit
those by hand, there is a GUI for that.

Subversion seems simple enough in the classic shared-codebase scenario,
but if there is a tutorial out there on "How to update from a shared
repository without clobbering your local modifications" I haven't seen
it.  As a PHB relying on a moving SVN target, I need to know how to keep
my local changes intact while updating code.

Very little about OFBiz seems intuitive.  To some extent I know that is
a result of necessary complexity, like Party/Party Groups and related
data.  No one thinks that way in business, or even in law (I was a
lawyer in a previous life), we all think about People and Organizations,
but terms are relatively easy to learn, at least compared to alien
concepts like workflows and virtual products.  But I still don't know
yet how to get standard Sales Leads (source, date, name, address, phone,
comments) into my OFBiz database in an automated fashion.

The code is currently structured into Framework (which I think I
understand, though the edges are fuzzy to more than just me),
Applications (which seem to be subject-related, though OFBiz itself is
an application), Special Purpose (an odd catch-all, since everything has
a Special Purpose, but like Steve Martin in The Jerk, we might not know
what it is yet) and Hot-Deploy (which really seems to mean "local").

The whole update process makes me nervous.  I don't know what quality
controls are applied to code that is merged into the base, or whether
database design changes break things.  With perl for example, an
automated test suite runs every time I update a library, so I get a warm
fuzzy feeling that the update hasn't broken anything I use.  DBMS code
is traditionally the easiest to break, and at the same time production
systems have huge data investments, and a day outage due to a DBMS
change is NOT an option.  What does OFBiz do to ensure that doesn't
happen?





Sorry for he long post, I have this in mind for a long time...

Jacques



Reply via email to