From: "Matt Warnock" <mwarn...@ridgecrestherbals.com>
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.
I agree with the answer Chris made you earlier. But bypassing the applications power is not ideal to me, and should not be
recommended... for long term solutions...
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.
I saw your try, when I will get some time (and my high rate connection back, grrrr) I will review, complete and link. For instance
did you know that we have a maturing Glossary?
http://cwiki.apache.org/confluence/display/OFBIZ/Glossary
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).
Quickly : because it's a real community based project backed by Apache. A company may disappear (look at what is happening to even
Sun, MySQL, etc.) Apache and OFBiz community is less prone to disappear
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.
Too rapid, you are kidding ;o), or you mean not controlled enough maybe? I will later try to explain, as clearly as possible, why
the trunk is the right solution. If you search in the ML you will already find many good explanations by David.
2) Bug fixes don't generally get applied to the releases, only to trunk.
Wrong, as a commiter I always apply bug fixes 1st in trunk then backport them in last releases (and even if possible in older
releases). And we all (commiters) try to do so (sometimes some seem to forget though)
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.
Right, in case it changes, there is always this page
http://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
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.
Good decision! I will explain later why, you can already look for David's
answers in archives (MLs archives I mean)
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 will let you know when I will have written this article (actually only a new paragraph) For the moment it's only in French but I
will make an English version (I'd love to still have the original from Automation Group)
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.
The FAQ is useful (it was done with the same idea in mind), but I agree limited
and mostly technical
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.
Eclipse is frigthening when you begin but some days of use and it's ok (some months you begin to see its power, years are needed to
get the best from it).
With tools around ( Tortoise on Windows makes miracles, Subclipse is not bad
and complementary) SVN is not a problem.
For XML I'd recommend to use a goods tool like Oxygen but now there are also
good capabilities OOTB in Eclipse
Java is not hard to use when you don't dive in details, else follow Adam's
advices on dev ML :o)
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.
Yes and a jargon :/ But don't be afraid, as long as you don't dive in technical and architectural details, you don't have to worry
about them
XML is close enough to HTML that I don't feel completely at sea, but I
don't know where all the DTDs are.
Did you miss to read this page?
http://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Documentation+Index
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.
You will have to have you hand dirty, but with XML completion (Oxygen does a good job as I said) it's not as hard as it may look at
1st glance.
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.
There are strategies for that, look for "vendor" in wiki. But as I said (not
clearly yet), using hot-deploy is the real thing...
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,
Silverton's concepts...
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,
As concepts,
Applications correspond rougly to the Silverstion's Book 1
Special Purpose Applications correspond to the Silverstion's Book 2+3
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.
http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none
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?
http://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
HTH
Jacques
Sorry for he long post, I have this in mind for a long time...
Jacques
--
Matt Warnock <mwarn...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.
