Users - how to spur greater adoption - let's brainstorm!

[Mark-60]

I just signed up last night, so excuse me if I'm writing something that
has already been written - I don't know the history of the thread..
A few things came to my mind when I read the subject of this thread:

- when I started downloading ofbiz, I was wondering if the project was
really still actively alive - the diagrams and docs were mostly dated
2004 and older. The news section on the home page has no entry for 2006
at all, and I could not find anything else on the ofbiz site either that
would show recent activity. So it seemed a little abandoned. Maybe this
is something that may shy away some potential users

- More documentation. Not only on the admin/install/developer side, but
also on the user side. I only found user-related documentation on the
wiki - or so I thought. It turned out, it was only an empty skeleton
with "TODO" pages. I started playing around with creating a PO with a
vendor and approving it, and it seemed like there are many pages
involved in the process, most of them I don't fully understand (how is
the flow, what is the purpose of the page, how is data cross-referenced
[e.g. products], what are some of the input fields for). I know people
spend so much time in developing open-source projects for free, and I
always feel bad and unthankful when I critize the documentation in
return (please note that's meant as constructive criticism) - but the
more complex a project gets, the more people will feel lost and
frustrated about missing or too short documentation - especially when
they are under time-pressure on top of it.

- Downloaded distros rather than source that has to be compiled. Luckily
I found Si Chen's weekly builds - although I am still having problems
getting it to work with MySQL - see my other thread last night (nobody
responded so far, unfortunately)

MARK



Jacques Le Roux wrote:

> Sorry I'm late, I was away with poor connections (ok that's not an excuse)
>
> To begin I must say that OFBiz is the greatest software with which I ever had to
> work with. There is a lot of knowledge in it and it's difficult to learn and
> follow the news... So users complaining seems normal to me.
>
> Points that concern me (ordered. Perhaps it's some kind of rewriting, I'm still
> learning)
>
> 1) BackOffice (BO) UI
> Often People are complaining about BackOffice (BO) UI. Not about Ecommerce UI
> because it's something that clearly has to be customised. As David as explained
> BO UI is so general that it's difficult to make it better. Most of users
> understand that there is more functionnality than they need. Often they
> appreciate but have difficulties to tied this complexity with the UI complexity
> (In french we say that they want "butter and money of butter").
> Because, at least at beginning, even "big users" do not want to put much money
> in BO UI, perhaps one solution is to make sub projects dedicated to some
> targets. This is not affordable yet, not enough people interested ! Mmm...
> "Little Red Hen" problem again....
> The begining may be to add "fun" in it. Remember in old MS DOS time, a lot of
> people did not care about an UI. Everybody know now that it's easier to spot an
> icon than a word (that's normal : less synapses needed ;o).
> One other point is that people appreciate "link in text" to go from one part to
> the other. Maybe adding new links when possible will ease the use of the
> standard BO UI. (icon link even better ;o)
> Also how about Ajax and such ?
> And to finish : please remember that 80% of world resolution is 1024*768...
>
> I will work on POS very soon. I hope to make my work general enough to enhance
> the POS UI (few points). But as for Ecommerce UI this is something special and
> nobody want to give all its works for free (specially customers paying for it).
> That's why I think OFBiz UIs will always be poor without funding. Sorry to be
> crude.
>
> 2) Freely available user documentation.
> I like David's idea of Confluence use with Les Austin supervising (WikiPedia
> way). I'm ready to help.
>
> 3) More high-visibility clients
> It seems to me that this kind of clients does not want to be exposed for the
> moment. Perhaps the ASF move will ease this point ?
>
> 4) Formal training materials
> I think that brilliant Si's effort must be seconded... This is already a solid
> base. I hope to do some (mostly in french sorry) soon.
>
> Happy to be with you.
>
> Jacques
>
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
>
>
>  

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[davidnwelton]

> > *) Scale down.  This is closely related to the above, and just means
> > that the easier it is to do simple things, the more likely you are to
> > hook people and get them interested in learning the rest.  In other
> > words, a shallow learning curve is likely to have fewer people 'drop
> > out' because they can't make heads nor tails of how things work.

> These two items relate to one of the primary tenets behind the scope definition for OFBiz. This has been discussed a fair amount, but I don't know that it is really well documented anywhere...

> The first rule of reality related to this problem is this:
>
> 1. It is not possible to build something that is ideal for everyone

No, but without intending any slight to you guys' design abilities I
think a professional designer could squeeze a decent amount out of the
existing application.  Of course, that costs money if someone with
those talents doesn't happen on OFBiz by chance.  I don't pretend to
have the answers, I just think that there is some room for improvement
without spending a fortune, and Si asked:-)

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

David,

I see your point.  Well, in that case we should definitely stick with the current setup as the default.  Hey, if OFBiz weren't so easy to deploy, I probably wouldn't be here writing you about it today :)

Still I think there is some value in getting to work inside of other servers.  Should we look at the stuff in appserver/ and see if they could be expanded for some others?  Should we open an issue with the Geronimo folks?  (I met a couple of them recently--they seem pretty nice and reasonable!)

Si

David E Jones wrote:

Some comments on the app server part of this... another big issue so splitting to a different subject/thread...

Si Chen wrote:
  

2.  Deployability inside of other Java application servers (JBoss, 
Geronimo, WebLogic, Websphere, etc.)
    

This is already possible and much of the manual effort is automated using configuration templates  for a couple of app servers (in the framework/appserver component, see the README there for more info). These need to be expanded and the effort can be done independently for each app server. Right now we have stuff in place for Orion and Weblogic. It would be great to have more...

This is a _very_ difficult problem because of one little deficiency in the standards:

1. the ability to add classpath entries shared by a set of webapps

That's it. That one little thing makes OFBiz a real pain to deploy. If the EAR standard has "classes" and "lib" directories like the WAR standard does we would be good to go with no problems for a nice generic way to deploy all of OFBiz. Of course, for development-oriented deployments if they couldn't do an exploded EAR directory it would be a pain because you couldn't change files on the fly, but that's another issue... (a little more on that below related to in-place deployment)

Some app servers, like Weblogic, do have proprietary extensions to add to the shared classpath inside an EAR. For others you can add to the global classpath to get that effect. To really annoying ones, like Geronimo 1.0 and Tomcat, you have to copy the jar files and other classpath resources into their directories... Say good-bye to in-place deployment ladies and gents and welcome to the hellish world of wondering why your changes don't seem to be doing anything...

Whatever we do the default deployment for OFBiz, ie the out-of-the-SVN configuration, really needs to be an in-place deployment. All settings out of SVN are intended to be developer friendly, with various things needed (mostly documented in the Basic Production Setup Guide) to get it into a production deployment. What this means is that you build and run with no copying or changing of files needed, as it is now.

The component design in OFBiz makes it possible to have a single place to configure and organize OFBiz framework, application, and extension components and based on this to generate appserver deployment files.

My proposal for would be to enhance the current appserver templates and if necessary the templating mechanism (though it shouldn't be necessary). Some OFBiz container enhancements may also be desired, as Andy has started to crack into in a different thread.

What I would oppose _VERY_ strongly is going back to the approach where we try to have "ready to go" scripts and config files for different app servers. This is a nightmare to maintain and there is a pretty much 100% chance that these will be incorrect and incomplete, as they were in the past when we used this approach. It is a bit of a pain to run the appserver templates to create these deployment scripts and config files, but it is WELL worth it because at least they will include everything needed, even for add-ins that are dropped in hot-deploy or specialized or whatever...

-David


P.S. A separate topic (that I'll leave in the existing thread...) is how to get our desired default out-of-the-SVN deployment kosher with ASF licensing requirements. It looks like we actually have some good options for this. Maybe I shouldn't say it here, but what I'd like to see it something as Geronimo-based as possible, and if they could fix their bizarre classpath management scheme so we could do an in-place deployment maybe even run OFBiz in Geronimo instead of bits of Geronimo running in OFBiz. Barring that I'd like to get the connection pool from Geronimo going along with the transaction manager stuff Jacopo and I did last week, and then we'd be in a pretty clean state at least... and get rid of the standards jars that are of unknown license and use the geronimo ones for that too, though we should be able to do that with Minerva or whatever, so it's not such an issue, just a to-do. Okay, I wrote more than I should, hopefully this won't muddy the main topic as it is re
l
ated but I'd like to keep them separate to make discussions more effective.


 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users


  

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

Si Chen wrote:
> Still I think there is some value in getting to work inside of other
> servers.  Should we look at the stuff in appserver/ and see if they
> could be expanded for some others?  Should we open an issue with the
> Geronimo folks?  (I met a couple of them recently--they seem pretty nice
> and reasonable!)

Yes, this is certainly an area that would be nice to improve. The templates are fairly simple to put together, so the bulk of the work required for getting these done is to learn about (or already know about) the target application server, and determine a good deployment strategy for it. You'll notice that the current Weblogic and Orion templates do things in quite different ways, especially the class loading.

For Geronimo unless we want to create templates to generate deployment scripts that copy all classpath entries into the Geronimo repository directory, we would need some sort of change to accommodate modifying a classpath that can be shared among multiple webapps.

In an email from a few weeks ago Andy mentioned that he contacted them but he didn't include any details, so I'm not sure what the approach they proposed or that he asked for might be...

If you have met people in the Geronimo group it would be great to contact them, and if you'd like me to write details to include just let me know. The short sentence above about the change we need may be sufficient... If they have questions about why we need this or want to discuss alternatives that might be a good thing. What would be nice is just a tidy little XML file that we can drop into an EAR APP-INFO directory or such, kind of like the proprietary extensions to the EAR standard that other app servers do.

-David


 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Leon Torres-2]

David E Jones wrote:
>
> 1. It is not possible to build something that is ideal for everyone

Agreed, and it should further be emphasized that the View layer allows the user
great flexibility in shaping ofbiz to how they like it to look and behave. The
screen widgets are a very important part of this, but it needs good
documentation if the public is to appreciate it.

We also need to create a ready-made "application theme" for those evaluating
OFBiz. Sort of like the CRM application, but for basic ecommerce. That is, there
needs to be an entry level view and sandbox for people to try out so they don't
get overwhelmed.

It doesn't even have to use the OFBiz shopping cart and ecommerce system, it
could be written in PHP and connected to OFBiz using service calls. This sandbox
can benefit from a professional design (both UI and look-feel) more readily than
the entire ofbiz system. It could even serve as a testing ground for new tech,
like AJAX.

So my recommendations: Accessible Documentation and Accessible Demonstrations.

- Leon
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Leon Torres-2]

It just occurred to me: Having a killer application is most powerful way to
drive up adoption. We might have just the right ingredients for one in OFBiz. If
we can identify what that application is, then all we need to do is polish the
related components and give it a very fancy View layer.

- Leon
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Mark-60]

Leon Torres wrote:

David E Jones wrote:
  

1. It is not possible to build something that is ideal for everyone
    

Agreed, and it should further be emphasized that the View layer allows the user 
great flexibility in shaping ofbiz to how they like it to look and behave. The 
screen widgets are a very important part of this, but it needs good 
documentation if the public is to appreciate it.

We also need to create a ready-made "application theme" for those evaluating 
OFBiz. Sort of like the CRM application, but for basic ecommerce. That is, there 
needs to be an entry level view and sandbox for people to try out so they don't 
get overwhelmed.
  

Well, I think that most people probably need their own front-end customization anyway. Even creating a (very?) simplified version will not change that.
So it may be more valuable to spend the time on documentation instead.

I just started learning ofbiz and tried to create a simple Purchase order and failed. I had questions come up like:
- Do I always need to set up a Person as a supplier/vendor/etc? What if I only buy stuff at a regular store - then there is no first name , last name, or person at all, all I have is the store's name.
- What is the difference between Vendors and Suppliers?
- How do I set up and maintain a bunch of items?
- Can I create Products without categories?
- How can I remove a Catalog Category? I created one and want to remove it again, but can't. I found the deleteProductCategory (or something like that) service in the Service Directory and I can schedule it with the Category ID as parameter, but it never seems to execute.
Instead it keeps adding another copy of this thing into my Job list every X seconds, so after 5 minutes I had a ton of them in there, but my Category is still not deleted...
- Can I just "Execute now" a service rather than scheduling it?
- How can I remove the default parties (or any party for that matter)? I don't need 4 different kinds of Blog users and all that, just the admin account is fine for now.

I have not found any documentation for any of this so far - the closest to what I need is in french (I think I saw links to those on opentaps)...

Long term, my goal is to create for example a very simplified PO entry process that consists of one screen - but I can't even get a PO created in the webtools application in order to see what entities are involved in POs.

MARK

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Mark-60]

Sounds good, but if it is a "killer app", it will still be too complex
and people still won't understand what any of the screens are.
And if you make it too simple, people will think "oh man, that ofbiz can
not even do 10% of what I need"...

I think it comes down to documentation. And I mean for users, not only
developers and administrators. Like "what are the main pieces? what are
all those fields?". Not "how do I instal it?" "how do I program this and
that?"
My main goal is to program my own thing based on ofbiz too, but I first
need to understand what all these data components and the relations are
before I can change the screens and flows and build a whole new thing.
And I can't even get that far without running back to the mailing-list
for every single small thing.

MARK


Leon Torres wrote:

> It just occurred to me: Having a killer application is most powerful way to
> drive up adoption. We might have just the right ingredients for one in OFBiz. If
> we can identify what that application is, then all we need to do is polish the
> related components and give it a very fancy View layer.
>
> - Leon
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
>
>
>  

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Jacques Le Roux]

Hope it will be readable in text format ...

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Wednesday, May 10, 2006 11:36 PM

Subject: Re: [OFBiz] Users - how to spur greater adoption - let's brainstorm!

Leon Torres wrote:

David E Jones wrote:
  

1. It is not possible to build something that is ideal for everyone
    

Agreed, and it should further be emphasized that the View layer allows the user 
great flexibility in shaping ofbiz to how they like it to look and behave. The 
screen widgets are a very important part of this, but it needs good 
documentation if the public is to appreciate it.

We also need to create a ready-made "application theme" for those evaluating 
OFBiz. Sort of like the CRM application, but for basic ecommerce. That is, there 
needs to be an entry level view and sandbox for people to try out so they don't 
get overwhelmed.
  

Well, I think that most people probably need their own front-end customization anyway. Even creating a (very?) simplified version will not change that.
So it may be more valuable to spend the time on documentation instead.

 

I agree. I remember to have read some time ago that the real value of a library (API, etc.) is its documentation...

 

Jacques

I just started learning ofbiz and tried to create a simple Purchase order and failed. I had questions come up like:
- Do I always need to set up a Person as a supplier/vendor/etc? What if I only buy stuff at a regular store - then there is no first name , last name, or person at all, all I have is the store's name.
- What is the difference between Vendors and Suppliers?
- How do I set up and maintain a bunch of items?
- Can I create Products without categories?
- How can I remove a Catalog Category? I created one and want to remove it again, but can't. I found the deleteProductCategory (or something like that) service in the Service Directory and I can schedule it with the Category ID as parameter, but it never seems to execute.
Instead it keeps adding another copy of this thing into my Job list every X seconds, so after 5 minutes I had a ton of them in there, but my Category is still not deleted...
- Can I just "Execute now" a service rather than scheduling it?
- How can I remove the default parties (or any party for that matter)? I don't need 4 different kinds of Blog users and all that, just the admin account is fine for now.

I have not found any documentation for any of this so far - the closest to what I need is in french (I think I saw links to those on opentaps)...

 

Thanks, it's mine ;) Most of it come from http://www.undersunconsulting.com/static/OFBizBasicProductionSetup.pdf (essential) and http://www.undersunconsulting.com/ofbizdoc/control/MainDoc (not free but first month only $5)

 

Jacques

 

Long term, my goal is to create for example a very simplified PO entry process that consists of one screen - but I can't even get a PO created in the webtools application in order to see what entities are involved in POs.

MARK

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Vinay Agarwal]

In this thread, I have seen two categories of suggestions originating from two different views of OFBiz—as a packaged product and as a development tool. At this time, I don’t think OFBiz or any packaged product can satisfy enterprise automation needs of a “large” number of companies although it may happen in future a year or two from now. Therefore, our best bet to increase adoption, at this moment in time, may come from having OFBiz become a “better” development tool for a large number of enterprise automation needs.

 

There is no lack of generality in OFBiz framework to limit it to only a certain type of applications. In other words, there is no issue with the breadth of applications that OFBiz can support. The key issue, from my personal experience and from emails in the mailing lists, seems to be is the time to ramp up and be productive on this framework. I estimate this ramp up time to be about 6-months full time effort. Anything we can do to cut it down significantly (10-20% reduction just won’t do) would increase adoption.

 

Regards,

Vinay Agarwal

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Leon Torres-2]

Mark wrote:
>
> Well, I think that most people probably need their own front-end
> customization anyway. Even creating a (very?) simplified version will
> not change that.
> So it may be more valuable to spend the time on documentation instead.

Consider that a simplified sandbox would be a source of documentation in itself.
We could document it thoroughly and provide stepping-stone advice for using the
bigger system. That is, the intent is to smoothen the steep learning curve.

If the killer application is simple, then it could also double as the
well-documented reference system. But what could it be? :-)

- Leon
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Hans Bakker]

On Saturday 06 May 2006 04:30, Si Chen wrote:
>
> *How do we spur greater adoption of OFBIZ?*
>

This adoption is certainly a problem. The system is too big for the smaller
companies and still a big risk for the larger companies.

Therefore I am currently implementing the following business model:

1. offer a 'part' of the OFBiz system in a simplified version in a shared
environment on the same system. Every customer will have 1 webapp for the
frontend and they share the same backend webapp in the same component.
2. This 'part' can be ecommerce/ordering (rental and selling), accounting,
timesheets(workeffort) and later CRM, marketing(mailing list) and the POS
system.
3. When these companies are using one 'part' of the system, show them the
possibility of using another part in the same system.
4. When they even want more functionality transfer the data to a complete
ofbiz system.

This shared system I am now putting in production. The site promoting this
idea is the dutch site: www.openwinkel.nl which will soon have an
international version in www.openE-Commerce.com. Our first customer is at
www.openwinkel.nl/bw, a 3 language site which will go in production in the
next few weeks and which is using this shared system.

This 'shared' system is the opentravelsystem in the specialized directory. It
started of as a hotelroom reservation system but is now also used for selling
items.

If you would like to implement this business model yourself be my guest and
lets work together.

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Mark-60]

Leon Torres wrote:

Mark wrote:
  

Well, I think that most people probably need their own front-end 
customization anyway. Even creating a (very?) simplified version will 
not change that.
So it may be more valuable to spend the time on documentation instead.
    

Consider that a simplified sandbox would be a source of documentation in itself. 
We could document it thoroughly and provide stepping-stone advice for using the 
bigger system. That is, the intent is to smoothen the steep learning curve.
  

This means you make it very simple, keep the minimum required fields, screens, relations and entities you need to do whatever your basic app is supposed to do and hope that they are self-explanatory. You are cutting out everything that may need explanation or documentation.
At that point people will still have no idea what additional options they have, what all that complex stuff is, what the relations are, and so on .
Once they start trying to explore the world outside the little sandbox, the only other place to go to is what we have now: the big monster app that comes with the ofbiz download.
And they will have the same problem they have now - they will be hopelessly lost.

Don't get me wrong - a sandbox app would be great for developers to learn how to make small easy apps, but it will not replace a solid documentation.

If the killer application is simple, then it could also double as the 
well-documented reference system. But what could it be? :-)
  

I don't know... maybe somebody who has done some implementation(s) has some suggestions.

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

Hans,

In general what you're saying makes a lot of sense.  Please count me in.

In particular I'm really curious how you are able to host multiple companies on one instance of OFBiz.  This is something I think a lot of people can benefit from.  Can you share it with us?

Si

Hans Bakker wrote:

On Saturday 06 May 2006 04:30, Si Chen wrote:
  

*How do we spur greater adoption of OFBIZ?*

    

This adoption is certainly a problem. The system is too big for the smaller 
companies and still a big risk for the larger companies.

Therefore I am currently implementing the following business model:

1. offer a 'part' of the OFBiz system in a simplified version in a shared 
environment on the same system. Every customer will have 1 webapp for the 
frontend and they share the same backend webapp in the same component.
2. This 'part' can be ecommerce/ordering (rental and selling), accounting, 
timesheets(workeffort) and later CRM, marketing(mailing list) and the POS 
system.
3. When these companies are using one 'part' of the system, show them the 
possibility of using another part in the same system.
4. When they even want more functionality transfer the data to a complete 
ofbiz system.

This shared system I am now putting in production. The site promoting this 
idea is the dutch site: www.openwinkel.nl which will soon have an 
international version in www.openE-Commerce.com. Our first customer is at 
www.openwinkel.nl/bw, a 3 language site which will go in production in the 
next few weeks and which is using this shared system.

This 'shared' system is the opentravelsystem in the specialized directory. It 
started of as a hotelroom reservation system but is now also used for selling 
items.

If you would like to implement this business model yourself be my guest and 
lets work together.

  

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Hans Bakker]

On Thursday 11 May 2006 07:50, Si Chen wrote:
> Hans,
>
> In general what you're saying makes a lot of sense.  Please count me in.
>
> In particular I'm really curious how you are able to host multiple
> companies on one instance of OFBiz.  This is something I think a lot of
> people can benefit from.  Can you share it with us?
>

Hi Si,
i just updated the specialized/opentravelsystem/README.pdf document which
explains this.

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[rajshekhar]

To get more users and more organizations to use OFBIZ,First thing is documentation.We hve to provide full fledge documentation which aso useful for developer,What i feel is current documentation does not support enough inormation to do l develpment in ofbiz(bocs i am developing app. in ofbiz on trial and error basis),Especially doc. should provide flow of control in ofbiz and detail explanation of tags in xml files

G.Rajshekhar

[David E. Jones]

Vinay,

>From your experience how would you compare this ramp up time to that of becoming a proficient developer to customize other ERP, CRM and ecommerce systems of a similar scope and scale?

-David


Vinay Agarwal wrote:

> In this thread, I have seen two categories of suggestions originating
> from two different views of OFBiz—as a packaged product and as a
> development tool. At this time, I don’t think OFBiz or any packaged
> product can satisfy enterprise automation needs of a “large” number of
> companies although it may happen in future a year or two from now.
> Therefore, our best bet to increase adoption, at this moment in time,
> may come from having OFBiz become a “better” development tool for a
> large number of enterprise automation needs.
>
>  
>
> There is no lack of generality in OFBiz framework to limit it to only a
> certain type of applications. In other words, there is no issue with the
> breadth of applications that OFBiz can support. The key issue, from my
> personal experience and from emails in the mailing lists, seems to be is
> the time to ramp up and be productive on this framework. I estimate this
> ramp up time to be about 6-months full time effort. Anything we can do
> to cut it down significantly (10-20% reduction just won’t do) would
> increase adoption.
>
>  
>
> Regards,
>
> Vinay Agarwal
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Vinay Agarwal]

The short answer is--other systems are no better in ramp up time. But,
1) they benefit from a mindset similar to the 70's saying "nobody got fired
for buying IBM," and
2) their adoption (or growth) is no better.

An appropriate theoretical model for growth desired by OFBiz is Everett
Rodgers' Diffusion of Innovation. (Plenty of details are available on the
web.)

I compare the state of enterprise software today to the state of PC/Windows
software prior to Microsoft Foundation Class (and related Visual Studio
tools). That cut down the required development effort by an order of
magnitude. OFBiz (and to a lesser extent or JBoss/Hibernate) have capability
to have a similar impact. OFBiz has the following impediments:
1. No publicly visible examples that show the full extent of OFBiz'
capabilities. Examples are the most powerful way of communicating
capabilities.
2. Rough edges (bad html, poor looking screens, no theme capabilities, etc.)
block visibility to its internal elegance.
3. Lack of big name -- solved through Apache.
4. And, here we go again, ramp up time. Ramp up time would be less
significant if there were other means of growing adoption. For OFBiz, my
best guess to adoption growth is bottom up, from engineers to companies. In
that model, the ramp up time is of utmost importance.

I actually think it is not very difficult to cut down the ramp up time by
50% through customized tools. Documentation would help too (may be 10%) but
would be more beneficial for reference.

Regards,
Vinay Agarwal

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of David E Jones
Sent: Wednesday, May 10, 2006 10:26 PM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - how to spur greater adoption - let's
brainstorm!


Vinay,

>From your experience how would you compare this ramp up time to that of
becoming a proficient developer to customize other ERP, CRM and ecommerce
systems of a similar scope and scale?

-David


Vinay Agarwal wrote:

> In this thread, I have seen two categories of suggestions originating
> from two different views of OFBiz-as a packaged product and as a
> development tool. At this time, I don't think OFBiz or any packaged
> product can satisfy enterprise automation needs of a "large" number of
> companies although it may happen in future a year or two from now.
> Therefore, our best bet to increase adoption, at this moment in time,
> may come from having OFBiz become a "better" development tool for a
> large number of enterprise automation needs.
>
>  
>
> There is no lack of generality in OFBiz framework to limit it to only a
> certain type of applications. In other words, there is no issue with the
> breadth of applications that OFBiz can support. The key issue, from my
> personal experience and from emails in the mailing lists, seems to be is
> the time to ramp up and be productive on this framework. I estimate this
> ramp up time to be about 6-months full time effort. Anything we can do
> to cut it down significantly (10-20% reduction just won't do) would
> increase adoption.
>
>  
>
> Regards,
>
> Vinay Agarwal
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[S Pole]

My 2 cents after evaluating (and deciding against) OFBiz for our organization:

1. Better design documentation with a clearer path to go about around the existing documentation about OFBiz.
2. Better support for business services integration -- We were interested in deploying our web services alongside OFBiz and providing a common interface.
3. Conformance to best practices and standards -- Important from the view of interoperability.
4. A cleaner and up-to-date OFBiz.org home page without misleading information

Regards,
SBP.

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Chris Medinger]

I was initially going to suggest a space on one of the
sites be made for
user-contributed downloadable templates of databases
that can be swapped
in during the install process to replace the default
business template.  
But managing the cleanliness of submissions could
become a
labor-intensive job, and if hundreds of templates were
uploaded, then
you would practically lose the increase in
configuration simplicity.

As I was typing I realized it would be even better if
there were a set
of small database-building scripts that could be
parsed together by a
setup program where the user picks options that
pertain to his/her
business, sort of how certain proprietary book keeping
programs ask
about the general nature of your business before
assembling all of the
relevant initial accounts together.

example:  I own a retail store that sells items I buy
from two or three
different wholesalers, and I'm interested in moving my
books and
inventory management over to OFBiz.  In addition, I've
decided to put up
a web store to draw more non-local business, and have
hit a deal with a
local shipping store.  So in the install options, I
check (please
forgive for not using exact terminology): Retail Store
w/POS option to
be managed by OFBiz (quantity 1), Web site (quantity
1), wholesale accts
(quantity 3), Shipping contract (quantity 1), maybe
even Employees (5),
Merchant acct. (quantity 1).  The inventory and accts.
are dealt with in
migration from the software I was using before, so
there's no point in
doing in-depth analysis of this.

So after the db-building script has been parsed
together and run, the
user installing the program will also be given a
likewise
parsed-together checklist or set of instructions on
finalizing
configuration for each part (it's really just a
customized version of
the configuration section in the installation manual).

Is something like that possible, or totally ludicrous?
 Is it possible
to build a single parser engine, that would be
compatible with the
different database servers people are using (I'm
assuming so since this
you can install the initial database on any of them)?

--Chris Medinger

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users