Learning and Using OFBiz (was: Re: What I would like to see)

[David E Jones <de...@me.com>]

We're covering all sorts of ground in this thread! On the other hand, if we look closely at the ground there are hints that all of this has been covered before... ;)

Matt, I think what Chris Snow is referring to is the difficulty of learning to effectively use the OFBiz framework versus learning to effectively reuse the applications (both the base and specialpurpose application). Based on what Chris has written in other messages he is still struggling with how OFBiz is organized (ie the base applications are intentionally NOT organized around business processes in order to be as reusable as possible in different business processes, and instead are organized around the data structures).

In any case, there are a few reasons why the business side of OFBiz (the applications) are a lot more complicated and difficult to learn than the technical side of OFBiz. The basic problem is the size of each, but that's over-simplifying things.

Read Before You Write: It's not really human nature to do this, and it takes a lot of patience. This is made worse because if individuals have a hard time with patience, organizations are simply incapable of it. The PHBs want results... and reading sure doesn't look like it's producing any. What's worse is if the individual manages to produce a result with a couple of dozen lines of configuration and bits of code instead of a couple of thousand lines of raw, meaty, manly Java then a semi-technical PHB may find it really unsatisfying to have paid for so much time to get so little, not realizing that the individual just save him 10-100 times what the alternative would have cost initially and over its useful lifetime.

Scratching the Surface: A business application is not like an operating system, or even a framework for building business applications (which is like an operating, except the interfaces are tuned to a different type of input, a less technical and more business-oriented type of input). The difference is by nature there is no way to design an interface adequate to represent a business application, and that is what both operating systems and application frameworks are all about. Unfortunately business people don't like being told that an interface with a few little parameters is supposed to represent the entirety of options for ANY process in their business, even "standard" ones like billing or shipping. Business people don't like not be able to change and tune any part of their business that they want, and if the systems can't keep up then they don't get used. SAP and most ERPs out there are great examples of this. They are proprietary software works and you don't get the source code, and can only change what they've decided it's okay to change (unless you want to rewrite something, usually more than you think). Those sorts of systems don't let you get below the surface, which is unfortunate because then you don't even have an option to Read Before You Write.

In other words, the way you go about adding value (via easy of reuse) in a business application is very different from how you go about adding value in an operating system or a business application framework. With the OFBiz framework you can learn the "interface" to it, but with the applications you pretty much have to deal with it all. On the other hand, there are more concise "interfaces" to it, like the data model and browsing things related to data model elements, which is made easier with the Artifact Info and other related tools in the OFBiz WebTools application.

And how do you apply that in your business? The basic answer is you don't. OFBiz is meant to adapted to businesses, not businesses to OFBiz. You can certainly run it OOTB, but that's not how it's meant to be used and you'll find that a painful experience. It's not going to hold your hand because it was never designed to run your business. Frankly, how could it be? Some systems claim they are in their marketing, but that marketing isn't honest because how do they know how you want to run your business? When you start trying to use those systems in your business you find out pretty quick that they really don't know.

So, your best bet is to define your business and then do a gap/overlap analysis with OFBiz to see what you can use, what needs to be adapted, and what needs to be built to fill gaps. If you really want a tuned system, like for a larger company or for a derivative work (like a commercial application targeted at a certain type of company) then you can define the business, design the application, and build it, and save resources building it by reusing as much as possible from something like OFBiz (which gets back to why OFBiz is organized like it is). To do these things effectively takes some experience, and to shorten the path certain tools are helpful like the HEMP approach (http://www.dejc.com/home/HEMP.html).

Stepping back a little... there is a bigger trick... and that is how many people believe what I wrote above Read Before You Write and Scratching the Surface? Well, not many. For those that do understand and agree OFBiz is great (could be better, lots better, because even many people involved with OFBiz don't believe or don't understand those two ideas and as the number of contributors increases that painful fact becomes more apparent). For those who don't understand or don't agree, they are destined to a life of making things painful for them and others they work with, whether they attempt to use OFBiz (probably won't last long) or whether they choose a likely painful commercial route filled with reasons to spend more and more money on more and more different software.

-David



On Feb 7, 2010, at 10:45 AM, Matt Warnock wrote:

> On Sun, 2010-02-07 at 08:30 +0000, Christopher Snow wrote:
>> Matt, what was the 300 - 400 hours for?  
> 
> It was Milind Parikh's estimate of the learning curve, except I
> misquoted.  He said people should be "expected" to spend 200-400 hours
> to "understand OFBiz".
> 
>> 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'm not sure I understand this.  After 300-400 hours you can develop
> standalone apps, but using existing functionality takes longer?  I would
> think it was the other way around? 
> 
>> 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.
> 
> I can take any Linux (or BSD) distribution off the shelf, spend a
> half-hour installing it, and immediately get SOME useful work done. It
> may not do everything I want, but OOTB, it does the basics.  And OOTB, I
> can use it well enough to at least evaluate how well it meets my general
> needs.
> 
> I can then work on tuning the system to my specific needs, or use it as
> a platform to develop custom apps.  I don't need to understand all of
> the kernel (say the schedule or VM code) to get my job done, let alone
> the whole system.  If I need to write a new driver, filesystem, text
> filter, or whatever, I take an existing one as a template or example,
> and I write another that can be plugged in.  And you're right, I doubt
> anyone knows it all, and that's OK.
> 
> By the same token, IMO, you should not have to understand all of OFBiz
> to either 1) use it productively, or 2) write apps (or other plugin
> code) for it.  If that is not the case, then the system design and
> modularization needs improvement.  
> 
> And that is exactly why (I think) your work on framework independence
> and attention to dependencies is really important.
> 
> -- 
> Matt Warnock <mw...@ridgecrestherbals.com>
> RidgeCrest Herbals, Inc.
> 

Re: Learning and Using OFBiz (was: Re: What I would like to see)

[David E Jones <de...@me.com>]

On Feb 7, 2010, at 9:40 PM, Matt Warnock wrote:

> On Sun, 2010-02-07 at 14:58 -0600, David E Jones wrote:
>> We're covering all sorts of ground in this thread! On the other hand,
>> if we look closely at the ground there are hints that all of this has
>> been covered before... ;)
> 
> No doubt. :)  I have renamed my index to "New User Guide"-- better
> describes it, more consistent with suggestions from this list, and less
> overlap with what is already there.  It is a different approach from
> "Getting Started with OFBiz", and "OFBiz Documentation Index" but mine
> references both of those.  It just organizes some of the stuff that PHBs
> will want to see right away, and lays out a clear plan for getting from
> here to there.  Still a lot to flesh out, though, mostly finding and
> organizing the stuff already there.  
> 
>> Matt, I think what Chris Snow is referring to is the difficulty of
>> learning to effectively use the OFBiz framework versus learning to
>> effectively reuse the applications (both the base and specialpurpose
>> application). Based on what Chris has written in other messages he is
>> still struggling with how OFBiz is organized (ie the base applications
>> are intentionally NOT organized around business processes in order to
>> be as reusable as possible in different business processes, and
>> instead are organized around the data structures).
> 
> So we're saying that "hello world" in the OFBiz framework requires
> knowing the framework, but repurposing an existing app to fill a new
> need requires 1) knowing which apps are in the toolbox, 2) knowing which
> one is the closest fit, and 3) making, testing, and deploying the
> changes.  Is that about it?  If so, thanks, that makes more sense to me.
> 
>> In any case, there are a few reasons why the business side of OFBiz
>> (the applications) are a lot more complicated and difficult to learn
>> than the technical side of OFBiz. The basic problem is the size of
>> each, but that's over-simplifying things.
>> 
>> Read Before You Write: It's not really human nature to do this, and it
>> takes a lot of patience. This is made worse because if individuals
>> have a hard time with patience, organizations are simply incapable of
>> it. The PHBs want results... and reading sure doesn't look like it's
>> producing any. What's worse is if the individual manages to produce a
>> result with a couple of dozen lines of configuration and bits of code
>> instead of a couple of thousand lines of raw, meaty, manly Java then a
>> semi-technical PHB may find it really unsatisfying to have paid for so
>> much time to get so little, not realizing that the individual just
>> save him 10-100 times what the alternative would have cost initially
>> and over its useful lifetime.
> 
> This is an Organizational Behavior problem that certainly exists, but is
> by no means universal, or even in the majority.  Most managers worth
> their salary know that the right tool makes all the difference.  But
> they also know that there is a tradeoff between how many times you do a
> thing, and how right it needs to be.  We use nail guns in construction,
> but hammers also have a purpose, even in construction.
> 
> "Close enough" is OK in horseshoes and hand grenades, and in business
> processes that are not repeated often enough to make the effort of
> fine-tuning worthwhile.  My wife calls the other end of the spectrum
> "analysis paralysis" and business managers can't much tolerate that,
> either. 
> 
> As I pointed out before, its the 80/20 rule.  I don't WANT to build a
> custom tool for 80% of my business, and if I have to do that, the value
> of the whole is greatly diminished.  But you are correct that PHBs do
> NEED to be able to customize the 20% that generates the profits and is
> repeated with high frequency.  That 20% will differ in every business. 
> 
> It's like code optimization-- do you really want to unroll every loop by
> hand, and write all the code in optimized assembly for maximum speed?
> No, you get a working prototype first, then you profile it, and you
> optimize only where you must to achieve your performance goals. Much
> (most) of the time, code clarity is more important than optimization.

The point is not to get into "analysis paralysis", but to avoid rewriting things so that you can leverage the hopefully 80% that matches your business.

On a side note: I think "Analysis Paralysis" a bad name for a common problem... a better name might be "we have no idea what we're doing paralysis" or "we can't agree on how to do this paralysis". Good analysis involves a fairly straight course with a clearly defined target, and when walking into an existing analysis project or an implementation project that lacks adequate planning it is pretty clear where things have gone wrong. Implementation consultant managers often like this because it's a great alternative to sales when you get to implement things over and over. That's a bit of a jaded perspective though, so moving on...

Anyway, you're absolutely right that the point is to reuse as much as possible (the proverbial 80%), so you can focus on the remaining (ie the 20%). The problem is you never know where the 20% is going to be. It is typically spread all over the place and parts of it sometimes pop up in the most annoying of places, like picking or billing or automated GL posting or whatever annoying nook or cranny the poor designer of the system forgot to consider making changeable. ;)

I'm watching "The Right Stuff" right now and there is a great quote by a German scientist when Alan Shepard had to do #1: "we didn't think of that" (sounded more like "vee didn't sink of dat".

>> Scratching the Surface: A business application is not like an operating
>> system, or even a framework for building business applications (which
>> is like an operating, except the interfaces are tuned to a different
>> type of input, a less technical and more business-oriented type of
>> input). The difference is by nature there is no way to design an
>> interface adequate to represent a business application, and that is
>> what both operating systems and application frameworks are all about.
>> Unfortunately business people don't like being told that an interface
>> with a few little parameters is supposed to represent the entirety of
>> options for ANY process in their business, even "standard" ones like
>> billing or shipping. Business people don't like not be able to change
>> and tune any part of their business that they want, and if the systems
>> can't keep up then they don't get used. SAP and most ERPs out there
>> are great examples of this. They are proprietary software works and
>> you don't get the source code, and can only change what they've
>> decided it's okay to change (unless you want to rewrite something,
>> usually more than you think). Those sorts of systems don't let you get
>> below the surface, which is unfortunate because then you don't even
>> have an option to Read Before You Write.
> 
> So you are saying that these systems only scratch the surface of the
> problem, because they only allow certain modifications?  I wasn't fully
> clear on whether scratching the surface is a good thing, or not, from
> what you wrote here.

What I mean is that with operating systems and frameworks the surface is all the user cares about. With business applications every little bit of it is subject to examination and change (or needs to be).

> Granted, a Business App (BA) is not an OS, and a BA is not a BA
> framework (a meta-BA, if you will).  I assume OFBiz is your meta-BA, and
> you seem to be saying that there is no way to create a truly universal
> BA, because it needs to be able to be customized, and I agree.  But it
> doesn't ALL need to be customized, and the part that needs customizing
> will be different in each case.

For a given company you're right, they certainly (hopefully!) won't have to customize everything. However, over the course of thousands of organizations chances are every bit of the system will at some point become a candidate for customization.

>  Besides, if its open source, I CAN customize anything and everything--
> but that doesn't mean I want to rewrite the whole app-- only those few
> parts that are worthwhile. That is the value of HAVING an app to
> rewrite, rather than building from scratch.  The beauty of OSS is that
> it offers a third option in the classic "Buy vs. Build" decision.

Yeah, my first attempt at a marketing message was just that: "Build vs Buy vs OFBiz".

>> In other words, the way you go about adding value (via easy of reuse)
>> in a business application is very different from how you go about
>> adding value in an operating system or a business application
>> framework. With the OFBiz framework you can learn the "interface" to
>> it, but with the applications you pretty much have to deal with it
>> all. On the other hand, there are more concise "interfaces" to it,
>> like the data model and browsing things related to data model
>> elements, which is made easier with the Artifact Info and other
>> related tools in the OFBiz WebTools application.
>> 
>> And how do you apply that in your business? The basic answer is you
>> don't. OFBiz is meant to adapted to businesses, not businesses to
>> OFBiz. You can certainly run it OOTB, but that's not how it's meant to
>> be used and you'll find that a painful experience. It's not going to
>> hold your hand because it was never designed to run your business.
>> Frankly, how could it be? Some systems claim they are in their
>> marketing, but that marketing isn't honest because how do they know
>> how you want to run your business? When you start trying to use those
>> systems in your business you find out pretty quick that they really
>> don't know.
> 
> I think you overestimate the pain of a "good" OOTB solution.  Maybe
> OFBiz isn't that, at this point.  And granted, every business will
> differ.  But if my 80% problem is largely solved OOTB, I have a LOT more
> time and money to throw at the 20% that NEEDS to be customized, and a
> lot more incentive to do it.  

When I think of an OOTB solution it's not 80% there... that could mean it's a million dollars away. OOTB to me means at least 95% there, and preferably 100% (though subjectivity pretty much makes that impossible, IMO), but at least close enough to what the business needs to not force them to rely on spreadsheets or additional systems in order to completely run whatever part of their business it is meant for.

I guess by current standards covering 80% of what the software is meant for is actually spectacular, and fortunately people aren't too picky about that. The fact is that a lot of companies are happy with QuickBooks even if they have half a dozen other apps and/or spreadsheets to run other parts of their business. In larger businesses the difficult to change ERP system may be supplemented by a hundreds, or even hundreds, of other systems.

> Every body is different, too-- but that doesn't mean that every article
> of clothing needs to be hand-tailored to fit decently (not perfectly).
> But most any article CAN be tailored, if the need arises, and if such
> tailoring is worthwhile.
> 
>> So, your best bet is to define your business and then do a gap/overlap
>> analysis with OFBiz to see what you can use, what needs to be adapted,
>> and what needs to be built to fill gaps. 
> 
> This is precisely where the huge learning curve is the impediment.  I
> know my business, but I don't know OFBiz, so even the most basic
> gap/overlap analysis requires hiring an OFBiz expert (if I can find one)
> and then I have to educate them on my business.  If I could use OFBiz
> effectively OOTB, then the gaps/overlaps would be apparent by trial and
> error, probably ranging from mild annoyances to (rarely) deal-breakers.
> But I can always continue to use existing systems and processes, until
> the deal-breaker gaps in OFBiz can be filled. In the meantime, it is
> still useful.

Actually you don't need an experienced person. Once you have business activities listed out anyone can go through and try to figure out how to use the system to do them, and then document the steps (with specific screen references, including URLs for clarity and buttons/links pressed, etc).

The only place you really need an expert is to verify gaps. In other words, if you can't find any way to do a certain thing then talk to an expert (or to save money, get a list of them, in the context of your general business process and the overlaps you've found, and have the expert review them).

But yeah, as OFBiz is right now anyone with a web-capable computer and an understanding of common business terms and a good deal of time can identify and document overlaps. In fact, the only thing that makes an "expert" an expert is that they have (hopefully!) already invested this sort of time and they understand the general patterns of the system well enough to do this quickly.

BTW, my experience with larger enterprise systems is that there usually isn't a person who is an expert on the entire system, and both analysts and developers tend to specialize in specific parts of the system.

>> If you really want a tuned
>> system, like for a larger company or for a derivative work (like a
>> commercial application targeted at a certain type of company) then you
>> can define the business, design the application, and build it, and
>> save resources building it by reusing as much as possible from
>> something like OFBiz (which gets back to why OFBiz is organized like
>> it is). To do these things effectively takes some experience, and to
>> shorten the path certain tools are helpful like the HEMP approach
>> (http://www.dejc.com/home/HEMP.html).
> 
> Not what I need, but others will.  But the absolute number of people
> needing either of these scenarios will be much smaller, IMO, than the
> number of SMB owners.  
> 
> The Fortune 1000 will have big budgets for ERP, and will be hard to land
> (long buying cycle).  You really need a sales army of "elephant hunters"
> to play in that space. 
> 
> If you envision VARs being your principal sales channel, then this
> design choice makes perfect sense.  I don't see that happening myself.

Actually, VARs are the primary sales channel for OFBiz-based solutions. In fact, they are the only "sales" channel because service providers are the only ones who "sell" anything. Of course, that's a play on words, but the concept really does mean something.

How did all of this stuff magically get into OFBiz? It wasn't a company developing something with the hope of getting a return on that investment in terms of sales (except for the developers who contribute things or become active on the mailing lists or whatever in order to attract clients, ie as a marketing channel). The majority of what exists in OFBiz, especially the business apps, was created because some VAR added it for a client and contributed it back to the project.

IMO that's what makes OFBiz interesting. It doesn't make it super clean or consistent in design (well, not any more), but it does make it very "real", and very organic.

> The differences from one type of company to another are probably not so
> overwhelming as you think.  Why was John Sculley pulled from PepsiCo to
> run Apple?  Because businesses are not that different.  Apple and Pepsi
> have more in common from the marketing side than most people think-- its
> all about the brand.  Sure, one item has a lifetime is seconds, the
> other in years.  But the processes are largely similar, though the
> terminology may change.  Is there a role for VARs? Absolutely.  Is it
> the primary sales channel?  I doubt it, but YMMV.

John Sculley! I'm surprised you'd bring up that example. ;) Isn't that the PERFECT example of a CEO transplant gone bad? Yeah, Apple was big and successful enough before he came on board that he wasn't able to trash and loot the entire company and force it into bankruptcy, but those weren't exactly the most stellar years in the history of Apple...

There may be some similarities between business approaches, but business systems don't deal with such generalities, they help automate the nitty-gritty details that are difficult and/or boring for humans to keep track of. For large companies like Apple the external auditors generally know more about such details than any C-level officer, and still the external auditors don't know nearly enough about the company to even specify sufficiently detailed requirements for the systems for that company.

> VARs are always a step removed from customers and users, which makes it
> that much harder to be customer-focused.  I should know-- we sell to
> distributors, which sell to retailers, which sell to users.  If I didn't
> go out of my way to talk to end users, I'd NEVER know what they think of
> our products.  I could tell you some war stories...

But you sell an off-the-shelf product, right? That's a little bit different isn't it?

Usually (for software) VARs are the ones who make the software fit the business, and if they are to do a good job they need to be more familiar with the business than most of the people running the business are (and by more familiar, I mean they should be able to hide some of the complexity by verifying things at a high level that imply certain lower level details).

Of course, most software consultants and analysts really honestly aren't very good, and not always because they are not experienced. In many cases they just don't know what works and what doesn't, what's a good idea and what isn't, what matters and is relevant and what isn't, and so on. Of course, sometimes even the best consultant simply can't contribute to a good software solution, some businesses just won't budge on certain things (usually related to unwillingness to address or even acknowledge certain problems, or even accept enough that they might be problems in order to test whether they are or not!).

Anyway, I believe you about a disconnect between manufacturers and end-users because of resellers! In the software world this is frustration usually pops up with the gap between developers and end-users. Again, sometimes analysts are actually WORSE than developers at gathering requirements and designing solutions.

>> Stepping back a little... there is a bigger trick... and that is how
>> many people believe what I wrote above Read Before You Write and
>> Scratching the Surface? Well, not many. For those that do understand
>> and agree OFBiz is great (could be better, lots better, because even
>> many people involved with OFBiz don't believe or don't understand
>> those two ideas and as the number of contributors increases that
>> painful fact becomes more apparent). For those who don't understand or
>> don't agree, they are destined to a life of making things painful for
>> them and others they work with, whether they attempt to use OFBiz
>> (probably won't last long) or whether they choose a likely painful
>> commercial route filled with reasons to spend more and more money on
>> more and more different software.
>> 
>> -David
> 
> This really boils down to a basic marketing issue: who is your customer,
> and what do they really need?  If you really meet that need effectively,
> delivering solid value, you will be successful beyond your ability to
> expand and serve.  How do you segment the market?  By revenues? By
> industry? By employees?  What are your sales channels?  Direct?  Through
> VARs or consultants?  What are your customers' real needs and how well
> do you meet them? In the venture capital community, we sometimes talk
> about "a solution in search of a problem."  Companies (or non-profits)
> that don't know what their customers really need will always struggle.
> 
> If this is indeed a "missionary sale", in that you have to sell people
> on a value proposition that they can't really see, or won't see for
> months or years, then you do have an uphill battle, no question.
> Thinking that they are stupid won't help.  Suffice it to say that I
> don't think it absolutely HAS to be that way.  
> 
> In my management experience, if I'm not getting the sales results I
> want, I try to re-examine what I'm doing, and I usually find that the
> reasons are both apparent and solvable.  A better mousetrap is often in
> the eye of the beholder-- a completely customizable mousetrap might not
> be the overwhelming marketing advantage, if you want to be catching mice
> like, yesterday. (And who doesn't?)  But if you give me a better
> mousetrap today, and it *immediately* solves 80% (or even 60% or 40%) of
> my mouse problem, who do you think I'll call for the more intractable
> part of the problem?

I think OFBiz, from my point of view anyway, has a pretty clearly defined target market and is doing just fine there. However, this isn't the target market that people think it should be, or perhaps more accurately _wish_ that it was.

The target market of OFBiz is... enterprise application service providers (including those who work for other companies, and those who work for internally in their own company, ie IT departments and such). As for end-users the intended audience is clients or customers of these service providers, ie including both companies that want to customize software for themselves, and companies that want others to customize software for them.

Another target market that is maturing is the derivative work company. This is a variation on a service provider where instead of customizing OFBiz for a single company they customize it for a type of company, or a vertical industry, and then instead of charging for customization and other such services they charge for a license and support.

The real point of the OFBiz target market is that is HAS to be something that leads to the project being self-sustaining. There may not be a revenue model for OFBiz, but there still must be a resource and motivation model. In fact, it is kind of fun because it is one of the few resource and motivation models that does not involve revenue.

> When I get entrenched in a particular view, my wife sometimes asks me:
> "do you want to be right, or do you want to be happy?"  Or as Dr. Phil
> would say, "How's that working for you?"  Often the only difference
> between a martyr and a hero is-- well, the hero actually WON the battle
> in question.  If you find yourself in an uphill fight to sell a solution
> to someone else's problem, maybe it isn't (yet) quite the solution it
> needs to be.  Not that it isn't great-- it just may need a bit of work
> yet to really break loose.  

Yeah, the Dr. Phil view of the world. I love his frequent quote "the past is the best predictor of the future." Why do I love it? Because it's horridly silly truism. The past is in fact the only possible predictor of the future. The implication that one can predict the future is ridiculous, as is the implication that Dr. Phil any sort of special way to cherry pick things from the past that support his chosen portrayal of a possible future. It's not that I think what he says is not true, it is just so terribly not useful, and his conclusions and recommendations seem to be so arbitrary instead of based on any real logic. A good read or listen through Mark Joyner's "Simple.ology" is helpful for recognizing this and all sorts of logical fallacies.

The "How's that working for you" question is similar. Yes, sometimes things make sense, but more often than not people know a lot less than they'd like others to believe they do. I'm more of the school of thought portrayed in Malcolm Gladwell's "Outliers". The basic tenet of that book is that context and circumstance have FAR more to do with success or failure. People like to credit and blame others far more than is probably usually deserved, in various aspects of life and certainly in business. Maybe the reason that I like "Outliers" so much is that it is totally contrary to the current popular notions that drive most of business and politics.

On the other hand, perhaps it is my persistent failure in business that pushes me to prefer such schools of thought. Perhaps that's best as another topic... ;)

> You've brought OFBiz this far (and that is a LONG bloody way), so I
> figure that you are a pragmatist and a problem-solver at heart.  And I
> think you have the groundwork laid to blow this market wide open,
> building a much larger, more committed, and more wealthy community, if
> you can make the value proposition more palatable to average SMB
> leaders, who I think are often smarter than you sometimes give them
> credit for.  
> 
> Not all PHBs got there under the Peter Principle.  Especially in the SMB
> sector, which is where I see the biggest potential for OFBiz.  ;)
> 
> http://en.wikipedia.org/wiki/Peter_Principle

I have no doubt about the value of small businesses. In fact, I am of the opinion that the majority of innovation and progress in the world comes from small businesses, and that small businesses are FAR more efficient that large businesses. I'm also of the more controversial opinion that if it were not for government interference in market places that large businesses would simply not exist as they do today because smaller organizations would serve the market so much better that larger ones would never have a chance. There may be something to the strength of branding and familiarity that help companies get bigger, but I have my doubts about that as the primary reason, and of course governments interfere with advertising in major ways. If your business is herbs as your email implies, you've probably either experienced this or heard the stories of men with guns shutting down small herbal businesses just for advertising, while protecting the larger companies that are actually allowed to cause death without any penalty as long as they play ball.

Anyway, back on topic...

OFBiz can't go after the SMB market. It's not because many people involved with OFBiz don't want to, in fact I think many people in the community would prefer it. It's because it can't.

Like you mentioned all organizations need a business model, not necessarily a revenue model, but they MUST have a resource and motivation model. Most resource and motivation models rely on revenue since money really is usually the easiest way to get people to do things (only people with money will deny that... and only because they've failed to get people to do certain things in spite of substantial offers of money, and then they just need to realize that an individual isn't a market and there is always someone who will willingly do something for money, anything really).

Anyway, in this regard OFBiz is a spectacular experiment. People collaborate and build and share things and get real work done that benefits others, and they do so without money flowing through a central organization. It IS in fact a resource and motivation model that doesn't involve revenue. I don't know if OFBiz will be recognized in this light, but I personally like to think of it as a masterpiece of revenue-free business. But aren't most community-driven open source projects this way, what about other Apache projects? Each project most certainly has a resource and motivation model, but many of them rely on (or to get started relied on) corporate sponsorship, and/or are driven by the "scratch an itch" or hobby theory.

Most contributions to OFBiz are not things they would do as a hobby. Dealing with legal requirements and ugly/complicated aspects of business is not fun for most people, and I'd wager that most people involved with OFBiz would only work on the framework or more technical things generally if they were not paid to do it. Still, the Apache OFBiz project is not paying them, someone else is and they or their client is voluntarily giving the results of that work to their project. Why do they do it? Because the value of collaboration on this software is higher than the cost of performing the contribution.

So, I know how to setup a community-driven open source project that is targeted at service providers who have a motivation to contribute back. What I DON'T know how to do (or in spite of trying haven't figured out yet) is how to get people to create, without monetary compensation, software that is meant for OOTB/as-is use by small businesses.

The problem with small businesses is that they typically can't contribute back to the project. Typically their employees can't (or don't have time to), and typically they can't afford to pay someone else to. So, if the project was targeted specifically at small businesses, where would the contributions come from? What revenue and motivation model would make that sustainable?

Creating derivative works for certain types of small businesses could, IMO, be VERY profitable. However, it would require investment to create the work based on OFBiz. I can't say how many times I've seen such things fail because in spite of being able to reduce the development budget the marketing isn't free. You can reduce it a lot by targeting a specific market because you inherently have more targeted advertising, but it's still not zero and if you don't budget for it then you are unknowingly already on the road to failure, and may have a hard to recovering your even modest investment in the software. Fortunately people are still trying this, and I really think it holds a lot of promise and is the key to the SMB market, ie vertically oriented derivative works of open source software, and there is no better starting point for that than Apache OFBiz.

Can software be created for small business? Most certainly yes, and has been, many many times in quite profitable ways. Am I interested in doing so? Not really. But wait, won't I get spectacularly rich if I do so and it succeeds? Well, no, probably not. I've been involved with a number of startups, both as an employee and as a consultant. Based on a half dozen such experiences I know a wide variety of strategies to get work for very little from gullible programmers. I know now that I'm just a resource and an expense and the business goal related to me is to reduce the size of that expense, or maximize its efficiency by getting as much out of it for as little as possible. There are ways to reduce such expenses just in case the business fails, and ways to reduce expenses with changes and technicalities later on just in case the business succeeds. 

I'm happy work on an hourly (or well-defined fixed-bid) basis for a fair consulting rate (or at least one that competes with whatever other opportunities I may have), but I won't offer discounts and unless the business plan is really good and I'm impressed with the people (which has never happened, not even among the dozen startups that have approached me in the last year). These days if I offer a discount it means I'm having a hard getting higher paying work, and of course clients should be careful of that because it really is fickle and doesn't foster any sort of a long-term relationship or a commitment. Yeah, people will accept getting beaten up on price if they have no other choice, but once they do... Of course, this opinion about startups may be a catch-22 because the part I'm usually not impressed with is the revenue and marketing plan... whereas if they have sufficient funding then chances are they'll pay my full rate and not try to get me to work for a percentage of the company. So, yeah, sorry if it seems a little bit funny, and I know that there certainly are those who are more interested in such risks, and perhaps I will be again in the future at some point.

To sum up, I don't know how to produce software for SMBs that they could get directly from a community-driven open source project. My opinion right now, until I see someone successfully do so over the period of at least a decade (okay, 9 years like OFBiz) is that there is no resource or motivation model that will get it done. People just don't work that way. The only "open source" model that I know of that produces good, clean, OOTB usable business applications for small businesses is the dual-license (typically GPL/commercial) model where they actually have a staff of paid designers and developers, and they have investments and a revenue model and all other traditional software business things, including expected revenue from software licensing, control over service and support markets, and so on.

Community-driven open source projects are GREAT for people and organizations that want to collaborate with peers to develop something bigger than they could alone, and in a way that is more efficient than paying for all of it. The software gets built, the clients get what they want (hopefully...), the contributors get more work because of offering a solution for less than other market alternatives and get attention (and sometimes more work because of that attention) because of their contributions, and the software exists and the project grows and progresses in a sustainable way.

If someone can tell me how I'm wrong, and how you could get people to contribute to a community-driven project meant for SMBs that can't contribute back, then please do so and it will be worth all of the effort in this thread and more.

-David


> And BTW, I'd still like to take you to lunch next time you are in town.
> Do you know when yet? :)
> 
>> 
>> 
>> On Feb 7, 2010, at 10:45 AM, Matt Warnock wrote:
>> 
>>> On Sun, 2010-02-07 at 08:30 +0000, Christopher Snow wrote:
>>>> Matt, what was the 300 - 400 hours for?  
>>> 
>>> It was Milind Parikh's estimate of the learning curve, except I
>>> misquoted.  He said people should be "expected" to spend 200-400 hours
>>> to "understand OFBiz".
>>> 
>>>> 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'm not sure I understand this.  After 300-400 hours you can develop
>>> standalone apps, but using existing functionality takes longer?  I would
>>> think it was the other way around? 
>>> 
>>>> 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.
>>> 
>>> I can take any Linux (or BSD) distribution off the shelf, spend a
>>> half-hour installing it, and immediately get SOME useful work done. It
>>> may not do everything I want, but OOTB, it does the basics.  And OOTB, I
>>> can use it well enough to at least evaluate how well it meets my general
>>> needs.
>>> 
>>> I can then work on tuning the system to my specific needs, or use it as
>>> a platform to develop custom apps.  I don't need to understand all of
>>> the kernel (say the schedule or VM code) to get my job done, let alone
>>> the whole system.  If I need to write a new driver, filesystem, text
>>> filter, or whatever, I take an existing one as a template or example,
>>> and I write another that can be plugged in.  And you're right, I doubt
>>> anyone knows it all, and that's OK.
>>> 
>>> By the same token, IMO, you should not have to understand all of OFBiz
>>> to either 1) use it productively, or 2) write apps (or other plugin
>>> code) for it.  If that is not the case, then the system design and
>>> modularization needs improvement.  
>>> 
>>> And that is exactly why (I think) your work on framework independence
>>> and attention to dependencies is really important.
>>> 
>>> -- 
>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>> RidgeCrest Herbals, Inc.
>>> 
> 
> 
> -- 
> Matt Warnock <mw...@ridgecrestherbals.com>
> RidgeCrest Herbals, Inc.
> 

Re: Learning and Using OFBiz (was: Re: What I would like to see)

[Shi Jinghai <sh...@langhua.cn>]

In the high-end market, there is no room for channels/vars.

在 2010-02-07日的 20:40 -0700，Matt Warnock写道：
> On Sun, 2010-02-07 at 14:58 -0600, David E Jones wrote:
> > We're covering all sorts of ground in this thread! On the other hand,
> >  if we look closely at the ground there are hints that all of this has
> >  been covered before... ;)
> 
> No doubt. :)  I have renamed my index to "New User Guide"-- better
> describes it, more consistent with suggestions from this list, and less
> overlap with what is already there.  It is a different approach from
> "Getting Started with OFBiz", and "OFBiz Documentation Index" but mine
> references both of those.  It just organizes some of the stuff that PHBs
> will want to see right away, and lays out a clear plan for getting from
> here to there.  Still a lot to flesh out, though, mostly finding and
> organizing the stuff already there.  
> 
> > Matt, I think what Chris Snow is referring to is the difficulty of
> >  learning to effectively use the OFBiz framework versus learning to
> >  effectively reuse the applications (both the base and specialpurpose
> >  application). Based on what Chris has written in other messages he is
> >  still struggling with how OFBiz is organized (ie the base applications
> >  are intentionally NOT organized around business processes in order to
> >  be as reusable as possible in different business processes, and
> >  instead are organized around the data structures).
> 
> So we're saying that "hello world" in the OFBiz framework requires
> knowing the framework, but repurposing an existing app to fill a new
> need requires 1) knowing which apps are in the toolbox, 2) knowing which
> one is the closest fit, and 3) making, testing, and deploying the
> changes.  Is that about it?  If so, thanks, that makes more sense to me.
> 
> > In any case, there are a few reasons why the business side of OFBiz
> >  (the applications) are a lot more complicated and difficult to learn
> >  than the technical side of OFBiz. The basic problem is the size of
> >  each, but that's over-simplifying things.
> > 
> > Read Before You Write: It's not really human nature to do this, and it
> >  takes a lot of patience. This is made worse because if individuals
> >  have a hard time with patience, organizations are simply incapable of
> >  it. The PHBs want results... and reading sure doesn't look like it's
> >  producing any. What's worse is if the individual manages to produce a
> >  result with a couple of dozen lines of configuration and bits of code
> >  instead of a couple of thousand lines of raw, meaty, manly Java then a
> >  semi-technical PHB may find it really unsatisfying to have paid for so
> >  much time to get so little, not realizing that the individual just
> >  save him 10-100 times what the alternative would have cost initially
> >  and over its useful lifetime.
> 
> This is an Organizational Behavior problem that certainly exists, but is
> by no means universal, or even in the majority.  Most managers worth
> their salary know that the right tool makes all the difference.  But
> they also know that there is a tradeoff between how many times you do a
> thing, and how right it needs to be.  We use nail guns in construction,
> but hammers also have a purpose, even in construction.
> 
> "Close enough" is OK in horseshoes and hand grenades, and in business
> processes that are not repeated often enough to make the effort of
> fine-tuning worthwhile.  My wife calls the other end of the spectrum
> "analysis paralysis" and business managers can't much tolerate that,
> either. 
> 
> As I pointed out before, its the 80/20 rule.  I don't WANT to build a
> custom tool for 80% of my business, and if I have to do that, the value
> of the whole is greatly diminished.  But you are correct that PHBs do
> NEED to be able to customize the 20% that generates the profits and is
> repeated with high frequency.  That 20% will differ in every business. 
> 
> It's like code optimization-- do you really want to unroll every loop by
> hand, and write all the code in optimized assembly for maximum speed?
> No, you get a working prototype first, then you profile it, and you
> optimize only where you must to achieve your performance goals. Much
> (most) of the time, code clarity is more important than optimization.
> 
> > Scratching the Surface: A business application is not like an operating
> >  system, or even a framework for building business applications (which
> >  is like an operating, except the interfaces are tuned to a different
> >  type of input, a less technical and more business-oriented type of
> >  input). The difference is by nature there is no way to design an
> >  interface adequate to represent a business application, and that is
> >  what both operating systems and application frameworks are all about.
> >  Unfortunately business people don't like being told that an interface
> >  with a few little parameters is supposed to represent the entirety of
> >  options for ANY process in their business, even "standard" ones like
> >  billing or shipping. Business people don't like not be able to change
> >  and tune any part of their business that they want, and if the systems
> >  can't keep up then they don't get used. SAP and most ERPs out there
> >  are great examples of this. They are proprietary software works and
> >  you don't get the source code, and can only change what they've
> >  decided it's okay to change (unless you want to rewrite something,
> >  usually more than you think). Those sorts of systems don't let you get
> >  below the surface, which is unfortunate because then you don't even
> >  have an option to Read Before You Write.
> 
> So you are saying that these systems only scratch the surface of the
> problem, because they only allow certain modifications?  I wasn't fully
> clear on whether scratching the surface is a good thing, or not, from
> what you wrote here. 
> 
> Granted, a Business App (BA) is not an OS, and a BA is not a BA
> framework (a meta-BA, if you will).  I assume OFBiz is your meta-BA, and
> you seem to be saying that there is no way to create a truly universal
> BA, because it needs to be able to be customized, and I agree.  But it
> doesn't ALL need to be customized, and the part that needs customizing
> will be different in each case.  
> 
> Besides, if its open source, I CAN customize anything and everything--
> but that doesn't mean I want to rewrite the whole app-- only those few
> parts that are worthwhile. That is the value of HAVING an app to
> rewrite, rather than building from scratch.  The beauty of OSS is that
> it offers a third option in the classic "Buy vs. Build" decision.
> 
> > In other words, the way you go about adding value (via easy of reuse)
> >  in a business application is very different from how you go about
> >  adding value in an operating system or a business application
> >  framework. With the OFBiz framework you can learn the "interface" to
> >  it, but with the applications you pretty much have to deal with it
> >  all. On the other hand, there are more concise "interfaces" to it,
> >  like the data model and browsing things related to data model
> >  elements, which is made easier with the Artifact Info and other
> >  related tools in the OFBiz WebTools application.
> > 
> > And how do you apply that in your business? The basic answer is you
> >  don't. OFBiz is meant to adapted to businesses, not businesses to
> >  OFBiz. You can certainly run it OOTB, but that's not how it's meant to
> >  be used and you'll find that a painful experience. It's not going to
> >  hold your hand because it was never designed to run your business.
> >  Frankly, how could it be? Some systems claim they are in their
> >  marketing, but that marketing isn't honest because how do they know
> >  how you want to run your business? When you start trying to use those
> >  systems in your business you find out pretty quick that they really
> >  don't know.
> 
> I think you overestimate the pain of a "good" OOTB solution.  Maybe
> OFBiz isn't that, at this point.  And granted, every business will
> differ.  But if my 80% problem is largely solved OOTB, I have a LOT more
> time and money to throw at the 20% that NEEDS to be customized, and a
> lot more incentive to do it.  
> 
> Every body is different, too-- but that doesn't mean that every article
> of clothing needs to be hand-tailored to fit decently (not perfectly).
> But most any article CAN be tailored, if the need arises, and if such
> tailoring is worthwhile.
> 
> > So, your best bet is to define your business and then do a gap/overlap
> >  analysis with OFBiz to see what you can use, what needs to be adapted,
> >  and what needs to be built to fill gaps. 
> 
> This is precisely where the huge learning curve is the impediment.  I
> know my business, but I don't know OFBiz, so even the most basic
> gap/overlap analysis requires hiring an OFBiz expert (if I can find one)
> and then I have to educate them on my business.  If I could use OFBiz
> effectively OOTB, then the gaps/overlaps would be apparent by trial and
> error, probably ranging from mild annoyances to (rarely) deal-breakers.
> But I can always continue to use existing systems and processes, until
> the deal-breaker gaps in OFBiz can be filled. In the meantime, it is
> still useful.
> 
> > If you really want a tuned
> >  system, like for a larger company or for a derivative work (like a
> >  commercial application targeted at a certain type of company) then you
> >  can define the business, design the application, and build it, and
> >  save resources building it by reusing as much as possible from
> >  something like OFBiz (which gets back to why OFBiz is organized like
> >  it is). To do these things effectively takes some experience, and to
> >  shorten the path certain tools are helpful like the HEMP approach
> >  (http://www.dejc.com/home/HEMP.html).
> 
> Not what I need, but others will.  But the absolute number of people
> needing either of these scenarios will be much smaller, IMO, than the
> number of SMB owners.  
> 
> The Fortune 1000 will have big budgets for ERP, and will be hard to land
> (long buying cycle).  You really need a sales army of "elephant hunters"
> to play in that space. 
> 
> If you envision VARs being your principal sales channel, then this
> design choice makes perfect sense.  I don't see that happening myself.
> The differences from one type of company to another are probably not so
> overwhelming as you think.  Why was John Sculley pulled from PepsiCo to
> run Apple?  Because businesses are not that different.  Apple and Pepsi
> have more in common from the marketing side than most people think-- its
> all about the brand.  Sure, one item has a lifetime is seconds, the
> other in years.  But the processes are largely similar, though the
> terminology may change.  Is there a role for VARs? Absolutely.  Is it
> the primary sales channel?  I doubt it, but YMMV.
> 
> VARs are always a step removed from customers and users, which makes it
> that much harder to be customer-focused.  I should know-- we sell to
> distributors, which sell to retailers, which sell to users.  If I didn't
> go out of my way to talk to end users, I'd NEVER know what they think of
> our products.  I could tell you some war stories...
> 
> > Stepping back a little... there is a bigger trick... and that is how
> >  many people believe what I wrote above Read Before You Write and
> >  Scratching the Surface? Well, not many. For those that do understand
> >  and agree OFBiz is great (could be better, lots better, because even
> >  many people involved with OFBiz don't believe or don't understand
> >  those two ideas and as the number of contributors increases that
> >  painful fact becomes more apparent). For those who don't understand or
> >  don't agree, they are destined to a life of making things painful for
> >  them and others they work with, whether they attempt to use OFBiz
> >  (probably won't last long) or whether they choose a likely painful
> >  commercial route filled with reasons to spend more and more money on
> >  more and more different software.
> > 
> > -David
> 
> This really boils down to a basic marketing issue: who is your customer,
> and what do they really need?  If you really meet that need effectively,
> delivering solid value, you will be successful beyond your ability to
> expand and serve.  How do you segment the market?  By revenues? By
> industry? By employees?  What are your sales channels?  Direct?  Through
> VARs or consultants?  What are your customers' real needs and how well
> do you meet them? In the venture capital community, we sometimes talk
> about "a solution in search of a problem."  Companies (or non-profits)
> that don't know what their customers really need will always struggle.
> 
> If this is indeed a "missionary sale", in that you have to sell people
> on a value proposition that they can't really see, or won't see for
> months or years, then you do have an uphill battle, no question.
> Thinking that they are stupid won't help.  Suffice it to say that I
> don't think it absolutely HAS to be that way.  
> 
> In my management experience, if I'm not getting the sales results I
> want, I try to re-examine what I'm doing, and I usually find that the
> reasons are both apparent and solvable.  A better mousetrap is often in
> the eye of the beholder-- a completely customizable mousetrap might not
> be the overwhelming marketing advantage, if you want to be catching mice
> like, yesterday. (And who doesn't?)  But if you give me a better
> mousetrap today, and it *immediately* solves 80% (or even 60% or 40%) of
> my mouse problem, who do you think I'll call for the more intractable
> part of the problem?
> 
> When I get entrenched in a particular view, my wife sometimes asks me:
> "do you want to be right, or do you want to be happy?"  Or as Dr. Phil
> would say, "How's that working for you?"  Often the only difference
> between a martyr and a hero is-- well, the hero actually WON the battle
> in question.  If you find yourself in an uphill fight to sell a solution
> to someone else's problem, maybe it isn't (yet) quite the solution it
> needs to be.  Not that it isn't great-- it just may need a bit of work
> yet to really break loose.  
> 
> You've brought OFBiz this far (and that is a LONG bloody way), so I
> figure that you are a pragmatist and a problem-solver at heart.  And I
> think you have the groundwork laid to blow this market wide open,
> building a much larger, more committed, and more wealthy community, if
> you can make the value proposition more palatable to average SMB
> leaders, who I think are often smarter than you sometimes give them
> credit for.  
> 
> Not all PHBs got there under the Peter Principle.  Especially in the SMB
> sector, which is where I see the biggest potential for OFBiz.  ;)
> 
> http://en.wikipedia.org/wiki/Peter_Principle
> 
> And BTW, I'd still like to take you to lunch next time you are in town.
> Do you know when yet? :)
> 
> > 
> > 
> > On Feb 7, 2010, at 10:45 AM, Matt Warnock wrote:
> > 
> > > On Sun, 2010-02-07 at 08:30 +0000, Christopher Snow wrote:
> > >> Matt, what was the 300 - 400 hours for?  
> > > 
> > > It was Milind Parikh's estimate of the learning curve, except I
> > > misquoted.  He said people should be "expected" to spend 200-400 hours
> > > to "understand OFBiz".
> > > 
> > >> 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'm not sure I understand this.  After 300-400 hours you can develop
> > > standalone apps, but using existing functionality takes longer?  I would
> > > think it was the other way around? 
> > > 
> > >> 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.
> > > 
> > > I can take any Linux (or BSD) distribution off the shelf, spend a
> > > half-hour installing it, and immediately get SOME useful work done. It
> > > may not do everything I want, but OOTB, it does the basics.  And OOTB, I
> > > can use it well enough to at least evaluate how well it meets my general
> > > needs.
> > > 
> > > I can then work on tuning the system to my specific needs, or use it as
> > > a platform to develop custom apps.  I don't need to understand all of
> > > the kernel (say the schedule or VM code) to get my job done, let alone
> > > the whole system.  If I need to write a new driver, filesystem, text
> > > filter, or whatever, I take an existing one as a template or example,
> > > and I write another that can be plugged in.  And you're right, I doubt
> > > anyone knows it all, and that's OK.
> > > 
> > > By the same token, IMO, you should not have to understand all of OFBiz
> > > to either 1) use it productively, or 2) write apps (or other plugin
> > > code) for it.  If that is not the case, then the system design and
> > > modularization needs improvement.  
> > > 
> > > And that is exactly why (I think) your work on framework independence
> > > and attention to dependencies is really important.
> > > 
> > > -- 
> > > Matt Warnock <mw...@ridgecrestherbals.com>
> > > RidgeCrest Herbals, Inc.
> > > 
> 
> 

Re: Learning and Using OFBiz (was: Re: What I would like to see)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Hi Matt,

On Feb 8, 2010, at 4:40 AM, Matt Warnock wrote:

> This is precisely where the huge learning curve is the impediment.  I
> know my business, but I don't know OFBiz, so even the most basic
> gap/overlap analysis requires hiring an OFBiz expert (if I can find one)
> and then I have to educate them on my business. 

this is definitely a critical phase of every ERP project; you have to know both sides if you want to join them in a good way.
But since OFBiz applications are (mostly) based on generic and universal concepts, if your business is a
Unfortunately most of the time people think that the processes of their own company represent a good template of universal processes, but this is not true and they are very specific (of the industry or even company), and they cannot find the same processes in OFBiz they get confused.
That said, I agree that much more can be done on the OFBiz side to make it more user friendly and understandable, while keeping it enough generic/universal.
Really, a lot can be done to improve OFBiz, and a lot has beed done already in the past. But we have to improve this.

Kind regards,

Jacopo

Re: Learning and Using OFBiz (was: Re: What I would like to see)

[Matt Warnock <mw...@ridgecrestherbals.com>]

On Sun, 2010-02-07 at 14:58 -0600, David E Jones wrote:
> We're covering all sorts of ground in this thread! On the other hand,
>  if we look closely at the ground there are hints that all of this has
>  been covered before... ;)

No doubt. :)  I have renamed my index to "New User Guide"-- better
describes it, more consistent with suggestions from this list, and less
overlap with what is already there.  It is a different approach from
"Getting Started with OFBiz", and "OFBiz Documentation Index" but mine
references both of those.  It just organizes some of the stuff that PHBs
will want to see right away, and lays out a clear plan for getting from
here to there.  Still a lot to flesh out, though, mostly finding and
organizing the stuff already there.  

> Matt, I think what Chris Snow is referring to is the difficulty of
>  learning to effectively use the OFBiz framework versus learning to
>  effectively reuse the applications (both the base and specialpurpose
>  application). Based on what Chris has written in other messages he is
>  still struggling with how OFBiz is organized (ie the base applications
>  are intentionally NOT organized around business processes in order to
>  be as reusable as possible in different business processes, and
>  instead are organized around the data structures).

So we're saying that "hello world" in the OFBiz framework requires
knowing the framework, but repurposing an existing app to fill a new
need requires 1) knowing which apps are in the toolbox, 2) knowing which
one is the closest fit, and 3) making, testing, and deploying the
changes.  Is that about it?  If so, thanks, that makes more sense to me.

> In any case, there are a few reasons why the business side of OFBiz
>  (the applications) are a lot more complicated and difficult to learn
>  than the technical side of OFBiz. The basic problem is the size of
>  each, but that's over-simplifying things.
> 
> Read Before You Write: It's not really human nature to do this, and it
>  takes a lot of patience. This is made worse because if individuals
>  have a hard time with patience, organizations are simply incapable of
>  it. The PHBs want results... and reading sure doesn't look like it's
>  producing any. What's worse is if the individual manages to produce a
>  result with a couple of dozen lines of configuration and bits of code
>  instead of a couple of thousand lines of raw, meaty, manly Java then a
>  semi-technical PHB may find it really unsatisfying to have paid for so
>  much time to get so little, not realizing that the individual just
>  save him 10-100 times what the alternative would have cost initially
>  and over its useful lifetime.

This is an Organizational Behavior problem that certainly exists, but is
by no means universal, or even in the majority.  Most managers worth
their salary know that the right tool makes all the difference.  But
they also know that there is a tradeoff between how many times you do a
thing, and how right it needs to be.  We use nail guns in construction,
but hammers also have a purpose, even in construction.

"Close enough" is OK in horseshoes and hand grenades, and in business
processes that are not repeated often enough to make the effort of
fine-tuning worthwhile.  My wife calls the other end of the spectrum
"analysis paralysis" and business managers can't much tolerate that,
either. 

As I pointed out before, its the 80/20 rule.  I don't WANT to build a
custom tool for 80% of my business, and if I have to do that, the value
of the whole is greatly diminished.  But you are correct that PHBs do
NEED to be able to customize the 20% that generates the profits and is
repeated with high frequency.  That 20% will differ in every business. 

It's like code optimization-- do you really want to unroll every loop by
hand, and write all the code in optimized assembly for maximum speed?
No, you get a working prototype first, then you profile it, and you
optimize only where you must to achieve your performance goals. Much
(most) of the time, code clarity is more important than optimization.

> Scratching the Surface: A business application is not like an operating
>  system, or even a framework for building business applications (which
>  is like an operating, except the interfaces are tuned to a different
>  type of input, a less technical and more business-oriented type of
>  input). The difference is by nature there is no way to design an
>  interface adequate to represent a business application, and that is
>  what both operating systems and application frameworks are all about.
>  Unfortunately business people don't like being told that an interface
>  with a few little parameters is supposed to represent the entirety of
>  options for ANY process in their business, even "standard" ones like
>  billing or shipping. Business people don't like not be able to change
>  and tune any part of their business that they want, and if the systems
>  can't keep up then they don't get used. SAP and most ERPs out there
>  are great examples of this. They are proprietary software works and
>  you don't get the source code, and can only change what they've
>  decided it's okay to change (unless you want to rewrite something,
>  usually more than you think). Those sorts of systems don't let you get
>  below the surface, which is unfortunate because then you don't even
>  have an option to Read Before You Write.

So you are saying that these systems only scratch the surface of the
problem, because they only allow certain modifications?  I wasn't fully
clear on whether scratching the surface is a good thing, or not, from
what you wrote here. 

Granted, a Business App (BA) is not an OS, and a BA is not a BA
framework (a meta-BA, if you will).  I assume OFBiz is your meta-BA, and
you seem to be saying that there is no way to create a truly universal
BA, because it needs to be able to be customized, and I agree.  But it
doesn't ALL need to be customized, and the part that needs customizing
will be different in each case.  

Besides, if its open source, I CAN customize anything and everything--
but that doesn't mean I want to rewrite the whole app-- only those few
parts that are worthwhile. That is the value of HAVING an app to
rewrite, rather than building from scratch.  The beauty of OSS is that
it offers a third option in the classic "Buy vs. Build" decision.

> In other words, the way you go about adding value (via easy of reuse)
>  in a business application is very different from how you go about
>  adding value in an operating system or a business application
>  framework. With the OFBiz framework you can learn the "interface" to
>  it, but with the applications you pretty much have to deal with it
>  all. On the other hand, there are more concise "interfaces" to it,
>  like the data model and browsing things related to data model
>  elements, which is made easier with the Artifact Info and other
>  related tools in the OFBiz WebTools application.
> 
> And how do you apply that in your business? The basic answer is you
>  don't. OFBiz is meant to adapted to businesses, not businesses to
>  OFBiz. You can certainly run it OOTB, but that's not how it's meant to
>  be used and you'll find that a painful experience. It's not going to
>  hold your hand because it was never designed to run your business.
>  Frankly, how could it be? Some systems claim they are in their
>  marketing, but that marketing isn't honest because how do they know
>  how you want to run your business? When you start trying to use those
>  systems in your business you find out pretty quick that they really
>  don't know.

I think you overestimate the pain of a "good" OOTB solution.  Maybe
OFBiz isn't that, at this point.  And granted, every business will
differ.  But if my 80% problem is largely solved OOTB, I have a LOT more
time and money to throw at the 20% that NEEDS to be customized, and a
lot more incentive to do it.  

Every body is different, too-- but that doesn't mean that every article
of clothing needs to be hand-tailored to fit decently (not perfectly).
But most any article CAN be tailored, if the need arises, and if such
tailoring is worthwhile.

> So, your best bet is to define your business and then do a gap/overlap
>  analysis with OFBiz to see what you can use, what needs to be adapted,
>  and what needs to be built to fill gaps. 

This is precisely where the huge learning curve is the impediment.  I
know my business, but I don't know OFBiz, so even the most basic
gap/overlap analysis requires hiring an OFBiz expert (if I can find one)
and then I have to educate them on my business.  If I could use OFBiz
effectively OOTB, then the gaps/overlaps would be apparent by trial and
error, probably ranging from mild annoyances to (rarely) deal-breakers.
But I can always continue to use existing systems and processes, until
the deal-breaker gaps in OFBiz can be filled. In the meantime, it is
still useful.

> If you really want a tuned
>  system, like for a larger company or for a derivative work (like a
>  commercial application targeted at a certain type of company) then you
>  can define the business, design the application, and build it, and
>  save resources building it by reusing as much as possible from
>  something like OFBiz (which gets back to why OFBiz is organized like
>  it is). To do these things effectively takes some experience, and to
>  shorten the path certain tools are helpful like the HEMP approach
>  (http://www.dejc.com/home/HEMP.html).

Not what I need, but others will.  But the absolute number of people
needing either of these scenarios will be much smaller, IMO, than the
number of SMB owners.  

The Fortune 1000 will have big budgets for ERP, and will be hard to land
(long buying cycle).  You really need a sales army of "elephant hunters"
to play in that space. 

If you envision VARs being your principal sales channel, then this
design choice makes perfect sense.  I don't see that happening myself.
The differences from one type of company to another are probably not so
overwhelming as you think.  Why was John Sculley pulled from PepsiCo to
run Apple?  Because businesses are not that different.  Apple and Pepsi
have more in common from the marketing side than most people think-- its
all about the brand.  Sure, one item has a lifetime is seconds, the
other in years.  But the processes are largely similar, though the
terminology may change.  Is there a role for VARs? Absolutely.  Is it
the primary sales channel?  I doubt it, but YMMV.

VARs are always a step removed from customers and users, which makes it
that much harder to be customer-focused.  I should know-- we sell to
distributors, which sell to retailers, which sell to users.  If I didn't
go out of my way to talk to end users, I'd NEVER know what they think of
our products.  I could tell you some war stories...

> Stepping back a little... there is a bigger trick... and that is how
>  many people believe what I wrote above Read Before You Write and
>  Scratching the Surface? Well, not many. For those that do understand
>  and agree OFBiz is great (could be better, lots better, because even
>  many people involved with OFBiz don't believe or don't understand
>  those two ideas and as the number of contributors increases that
>  painful fact becomes more apparent). For those who don't understand or
>  don't agree, they are destined to a life of making things painful for
>  them and others they work with, whether they attempt to use OFBiz
>  (probably won't last long) or whether they choose a likely painful
>  commercial route filled with reasons to spend more and more money on
>  more and more different software.
> 
> -David

This really boils down to a basic marketing issue: who is your customer,
and what do they really need?  If you really meet that need effectively,
delivering solid value, you will be successful beyond your ability to
expand and serve.  How do you segment the market?  By revenues? By
industry? By employees?  What are your sales channels?  Direct?  Through
VARs or consultants?  What are your customers' real needs and how well
do you meet them? In the venture capital community, we sometimes talk
about "a solution in search of a problem."  Companies (or non-profits)
that don't know what their customers really need will always struggle.

If this is indeed a "missionary sale", in that you have to sell people
on a value proposition that they can't really see, or won't see for
months or years, then you do have an uphill battle, no question.
Thinking that they are stupid won't help.  Suffice it to say that I
don't think it absolutely HAS to be that way.  

In my management experience, if I'm not getting the sales results I
want, I try to re-examine what I'm doing, and I usually find that the
reasons are both apparent and solvable.  A better mousetrap is often in
the eye of the beholder-- a completely customizable mousetrap might not
be the overwhelming marketing advantage, if you want to be catching mice
like, yesterday. (And who doesn't?)  But if you give me a better
mousetrap today, and it *immediately* solves 80% (or even 60% or 40%) of
my mouse problem, who do you think I'll call for the more intractable
part of the problem?

When I get entrenched in a particular view, my wife sometimes asks me:
"do you want to be right, or do you want to be happy?"  Or as Dr. Phil
would say, "How's that working for you?"  Often the only difference
between a martyr and a hero is-- well, the hero actually WON the battle
in question.  If you find yourself in an uphill fight to sell a solution
to someone else's problem, maybe it isn't (yet) quite the solution it
needs to be.  Not that it isn't great-- it just may need a bit of work
yet to really break loose.  

You've brought OFBiz this far (and that is a LONG bloody way), so I
figure that you are a pragmatist and a problem-solver at heart.  And I
think you have the groundwork laid to blow this market wide open,
building a much larger, more committed, and more wealthy community, if
you can make the value proposition more palatable to average SMB
leaders, who I think are often smarter than you sometimes give them
credit for.  

Not all PHBs got there under the Peter Principle.  Especially in the SMB
sector, which is where I see the biggest potential for OFBiz.  ;)

http://en.wikipedia.org/wiki/Peter_Principle

And BTW, I'd still like to take you to lunch next time you are in town.
Do you know when yet? :)

> 
> 
> On Feb 7, 2010, at 10:45 AM, Matt Warnock wrote:
> 
> > On Sun, 2010-02-07 at 08:30 +0000, Christopher Snow wrote:
> >> Matt, what was the 300 - 400 hours for?  
> > 
> > It was Milind Parikh's estimate of the learning curve, except I
> > misquoted.  He said people should be "expected" to spend 200-400 hours
> > to "understand OFBiz".
> > 
> >> 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'm not sure I understand this.  After 300-400 hours you can develop
> > standalone apps, but using existing functionality takes longer?  I would
> > think it was the other way around? 
> > 
> >> 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.
> > 
> > I can take any Linux (or BSD) distribution off the shelf, spend a
> > half-hour installing it, and immediately get SOME useful work done. It
> > may not do everything I want, but OOTB, it does the basics.  And OOTB, I
> > can use it well enough to at least evaluate how well it meets my general
> > needs.
> > 
> > I can then work on tuning the system to my specific needs, or use it as
> > a platform to develop custom apps.  I don't need to understand all of
> > the kernel (say the schedule or VM code) to get my job done, let alone
> > the whole system.  If I need to write a new driver, filesystem, text
> > filter, or whatever, I take an existing one as a template or example,
> > and I write another that can be plugged in.  And you're right, I doubt
> > anyone knows it all, and that's OK.
> > 
> > By the same token, IMO, you should not have to understand all of OFBiz
> > to either 1) use it productively, or 2) write apps (or other plugin
> > code) for it.  If that is not the case, then the system design and
> > modularization needs improvement.  
> > 
> > And that is exactly why (I think) your work on framework independence
> > and attention to dependencies is really important.
> > 
> > -- 
> > Matt Warnock <mw...@ridgecrestherbals.com>
> > RidgeCrest Herbals, Inc.
> > 


-- 
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.