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 -- Matt Warnock <mwarn...@ridgecrestherbals.com> RidgeCrest Herbals, Inc.
