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