Users - how to spur greater adoption - let's brainstorm!
Locked
123
123
 
|
Hi everybody. I'm sure this is something we all think about day and
night, so I thought I'd start a thread to discuss it:
How do we spur greater adoption of OFBIZ? Basically, I've feel that everybody's done a great job here creating a truly top notch product, and we've gone much further and faster than I'd have thought possible just six months ago. So how do we get more users and more organizations to use OFBIZ? I'd like to hear everybody's comments and thoughts, especially those of you who have had real-life experiences selling or implementing OFBIZ. Here are some ideas I've had. It'd be great to get your feedback on how important they might be for your organization or clients: 1. Freely available user documentation 2. Deployability inside of other Java application servers (JBoss, Geronimo, WebLogic, Websphere, etc.) 3. Support for multi-tenancy - multiple instances of OFBIZ inside of one (application) server 4. JSR-168 portal/portlet compatibility (I heard this is big now?) 5. A PHP or Ruby On Rails reference application which talks to OFBiz. For example, a simple PHP store which talks to the OFBiz backend. 6. Integration with Bugzilla, GForge, or JIRA issue trackers 7. Integration with Jasper Server, Pentaho 8. A regular online Jabber or IRC chat session 9. More features (what exactly? we've got a lot of features . . . ) 10. More high-visibility clients Thanks and have a great weekend, Si _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
In my 6 month’s experience of OFBiz, it is one of the most sophisticated pieces of software and one of the most complex. It is this second part that is the main issue with adoptation. After six months of hard work, I am just beginning to understand it. So my mantra would be-simplify, simplify, simplify. Of course it is possible only to an extent, as Einstein said, keep it simple but not simpler than it has to be. So my recommendations are (part of which I would implement for myself)
Regards, Vinay Agarwal
-----Original
Message-----
Hi everybody. I'm
sure this is something we all think about day and night, so I thought I'd start
a thread to discuss it: _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Si Chen-2
According to my very limited experience that the customer complain about the GUI part.
1. I am not sure the you guys case, but I think OFBiz provides a good opportunity to replace QuickBook for small-middle size business. But the GUI is so different from QuickBook and, to developers, it is very difficult to change. 2. One more thing is the language used in OFBiz, like mini-lang, and FTL, not many developers know about them. I agree that they are very handy some time, but for complex use case, I think we need to Java directly. cause debuging either FTL or Mini-Lang are very difficult. 3. Another good feature in my mind is it is good to store the FORM information into the database, that way, user can change the GUI themselves(Lef's say hide, display, enable, disable some fields or labels). I know some other ERP products do this. They store the metadata of each forms and at runtime, they just need to change the metadata, then the screen gets changed. 4. GUI themes, allow user switch between different CSS files at run time to set different themes. These are are currently in my mind. Lei On 5/5/06,
Si Chen <[hidden email]> wrote:
_______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
We implemented #4 here. I'm sure it could be expanded to accomplish #3.
Lei Gao wrote: > According to my very limited experience that the customer complain about > the GUI part. > > 1. I am not sure the you guys case, but I think OFBiz provides a good > opportunity to replace QuickBook for small-middle size business. But the > GUI is so different from QuickBook and, to developers, it is very > difficult to change. > > 2. One more thing is the language used in OFBiz, like mini-lang, and > FTL, not many developers know about them. I agree that they are very > handy some time, but for complex use case, I think we need to Java > directly. cause debuging either FTL or Mini-Lang are very difficult. > > 3. Another good feature in my mind is it is good to store the FORM > information into the database, that way, user can change the GUI > themselves(Lef's say hide, display, enable, disable some fields or > labels). I know some other ERP products do this. They store the metadata > of each forms and at runtime, they just need to change the metadata, > then the screen gets changed. > > 4. GUI themes, allow user switch between different CSS files at run time > to set different themes. > > These are are currently in my mind. > > Lei > > > > > > On 5/5/06, * Si Chen* <[hidden email] > <mailto:[hidden email]>> wrote: > > Hi everybody. I'm sure this is something we all think about day and > night, so I thought I'd start a thread to discuss it: > > *How do we spur greater adoption of OFBIZ?* > > Basically, I've feel that everybody's done a great job here creating > a truly top notch product, and we've gone much further and faster > than I'd have thought possible just six months ago. So how do we > get more users and more organizations to use OFBIZ? I'd like to > hear everybody's comments and thoughts, especially those of you who > have had real-life experiences selling or implementing OFBIZ. > > Here are some ideas I've had. It'd be great to get your feedback on > how important they might be for your organization or clients: > > 1. Freely available user documentation > > 2. Deployability inside of other Java application servers (JBoss, > Geronimo, WebLogic, Websphere, etc.) > > 3. Support for multi-tenancy - multiple instances of OFBIZ inside > of one (application) server > > 4. JSR-168 portal/portlet compatibility (I heard this is big now?) > > 5. A PHP or Ruby On Rails reference application which talks to > OFBiz. For example, a simple PHP store which talks to the OFBiz > backend. > > 6. Integration with Bugzilla, GForge, or JIRA issue trackers > > 7. Integration with Jasper Server, Pentaho > > 8. A regular online Jabber or IRC chat session > > 9. More features (what exactly? we've got a lot of features . . . ) > > 10. More high-visibility clients > > Thanks and have a great weekend, > > Si > > > _______________________________________________ > Users mailing list > [hidden email] <mailto:[hidden email]> > http://lists.ofbiz.org/mailman/listinfo/users > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
In reply to this post by Si Chen-2
Hello Si,
I would like to start my view from the line "East or West Ofbiz is the Best". It's really amazing peace of s/w in the Open Source market.I really appreciate the work by the Ofbiz Community.I really like its features like Service Engine and Entity Engine.Working in ofbiz always makes smile on my face.The people contributing in mailing list is really great.And the way of working in JIRA issue tracker is awesome. Now something that i like : My Likes : 1) Its GUI is great. 2) Form,Screen and Menu Widget technology. 3) Webtools,Party,Catalog,Order,Accounting component. 4) Adoptation of latest open source technology available in market. 5) Documentation on ofbiz on ofbiz.org and http://opensourcestrategies.com(Si you are really awesome man). 6) Before few months i saw the vedio conferencing available on ofbiz.org site it was also nice. 7) Working in ofbiz looks tough at starting but it gives relaxation when you know the things. There is countless features in ofbiz that i like.I would like to give many thanks to David & Andy for starting such a nice work in Open Source Community. Suggesstions : Its a time to start Advertising of OFbiz on Google,Yahoo(mail),MSN and the group of two or three people can start an article regarding to ofbiz strength and can start publishing it on sites like "http://www.theserverside.com/tss","http://www.javaworld.com/" and many sites and the common article. I would like to give some heading of this article "Ofbiz-Mature framework for Enterprise Applications","Ofbiz-Ready to face challenges","Ofbiz-Makes the things simpler". I think there is something required like Client Side Validation,Change of GUI color through CSS,Tooltip in some places. At the end i wish all the best to all the Ofbizian's and wish them all the best. One more thing :--- > David,Andy,Si you all are Rock man. Bye and god luck. Thanks for everything Thanks and Regards Ashish |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
In reply to this post by Si Chen-2
Si:
IMHO, before your question can be answered, you first have to identify your target market. In other words, who are these "users" and "organizations" you refer to? If your answer is developers and independent consultants then, IMHO it's the lack of high quality, print ready, easy to follow documentation that keeps this amazing suite of software from being "discovered". Books can be effective marketing tools as well as invaluable aids in getting perspective developers and consultants productive, quickly. Freely available documentation is a given for the basics, but beyond that, up-to-date, professionally edited, typeset and published documentation is extremely important for the developer/consultant community. If it's mind share you are after, then nothing beats a good book, or two. Three or more is even better! If your audience is the average business owner, then the answer is much different. In my experience, these adopters look for low risk, low cost, no hassle solutions. So, your marketing angle is the development of product features that keep costs down and minimize risk. Packaging is really important to these people. They like to see a stable, reliable and hassle free support structure behind the products they invest in. Bottom line: they don't care about deployment strategies, Ruby on Rails or AJAX. They just want a solution that "runs fine and lasts a long time". Are you trying to convert users of other frameworks to OFBiz? If so, to do the topic justice would require some market research. However, from what I've seen, you'd have a tough time enticing anyone by offering, say a JSR-168 portlet interface or PHP integration. (OK, you might get one or two...but is it really worth it?) Chasing technology is a tricky business..be careful with this one. All that said, here's my wish list, based not on market demand, but on what would make it easier for me to convince others to use OFBiz: 1) Documentation 2) Formal training materials 3) More work towards separating the Entity Engine/Service Engine/Security and User Management logic from the rest of the suite, so that they may be used independently to develop new applications. (Personally, I think there's a another product in there...just dying to be set free :-) One final observation: Recently, I convinced someone to bypass consideration of the Sun Portal Server for a pending development effort, all because the "free" Sun download was too hard to install. (My argument: if it's that hard to install, then it must be a nightmare to maintain...) Please, no matter what else you do, don't ever trade away the easy download, installation and initial demonstration features of OFBiz. To me, that is one of its best selling points. Hope this helps. Ruth _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
Documentation, as all have been saying, I would agree to be the number
one requirement. Looking further down the line, if Ofbiz is to be used at the heart of an enterprise's ERP solution, tools to assist in migrating existing data to the 'universal data model' of Ofbiz would be helpful in easing adopters through the painful process of shifting their centre of persistence. Such tools are difficult to find in my experience. CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
In reply to this post by Ruth Hoffman
Documentation, as all have been saying, I would agree to be the number
one requirement. Looking further down the line, if Ofbiz is to be used at the heart of an enterprise's ERP solution, tools to assist in migrating existing data to the 'universal data model' of Ofbiz would be helpful in easing adopters through the painful process of shifting their centre of persistence. Such tools are difficult to find in my experience. CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
Being a relative newbie to the rest of you, I would say:
1. Documentation - I have purchased the online documentation and have been reading and studying the application for a couple months now, but it really is a deep stack of requirements and solutions. 2. Having a skilled designer put a higher end theme on the demo - the most important thing is that I downloaded this application and it worked right out of the box. That instills confidence the first time that you play with it. After that, I think that my customers have been able to understand the model relatively well and have been stoked about the functionality that is at their fingertips, but a more slick interface would go a LONG way to providing continuing the good vibes they are getting from just using the app. I hope to hire someone who can help out with this aspect during the summer. 3. Running in any app server 4. Run more than one instance in the same app server 5. JSR-168 compliance Thanks for listening. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 Charles Johnson wrote: > Documentation, as all have been saying, I would agree to be the number > one requirement. > > Looking further down the line, if Ofbiz is to be used at the heart of an > enterprise's ERP solution, tools to assist in migrating existing data to > the 'universal data model' of Ofbiz would be helpful in easing adopters > through the painful process of shifting their centre of persistence. > Such tools are difficult to find in my experience. > > CJ > > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Si Chen-2
I'd have to agree with Ruth, that's a very broad
question and who you're trying to get to adopt OFBiz needs to be identified. I would like to slightly disagree with everyone on documentation. I think that there is plenty of documentation available. The only documentation that could be improved is more of a javadoc style output for the services (what the purpose of each one is supposed to be). I think the wanting of documentation is coming from the generic nature of OFBiz. That you have this vast playground that makes itself available for all types of business but that in order to successfully run "your" business you need to constrain it. This constraint should be considered outside of the scope of OFBiz and should be left to third party, specialized applications. However, OFBiz could (and IMO opinion should) be tweaked to allow easier creation of those third party applications. I think this is a natural evolution of OFBiz. If some more people could comment on jira issue 833. This part might get resolved a lot quicker and third party applications will be made a lot quicker. ================Ruth Hoffman wrote: Si: IMHO, before your question can be answered, you first have to identify your target market. In other words, who are these "users" and "organizations" you refer to? If your answer is developers and independent consultants then, IMHO it's the lack of high quality, print ready, easy to follow documentation that keeps this amazing suite of software from being "discovered". Books can be effective marketing tools as well as invaluable aids in getting perspective developers and consultants productive, quickly. Freely available documentation is a given for the basics, but beyond that, up-to-date, professionally edited, typeset and published documentation is extremely important for the developer/consultant community. If it's mind share you are after, then nothing beats a good book, or two. Three or more is even better! If your audience is the average business owner, then the answer is much different. In my experience, these adopters look for low risk, low cost, no hassle solutions. So, your marketing angle is the development of product features that keep costs down and minimize risk. Packaging is really important to these people. They like to see a stable, reliable and hassle free support structure behind the products they invest in. Bottom line: they don't care about deployment strategies, Ruby on Rails or AJAX. They just want a solution that "runs fine and lasts a long time". Are you trying to convert users of other frameworks to OFBiz? If so, to do the topic justice would require some market research. However, from what I've seen, you'd have a tough time enticing anyone by offering, say a JSR-168 portlet interface or PHP integration. (OK, you might get one or two...but is it really worth it?) Chasing technology is a tricky business..be careful with this one. All that said, here's my wish list, based not on market demand, but on what would make it easier for me to convince others to use OFBiz: 1) Documentation 2) Formal training materials 3) More work towards separating the Entity Engine/Service Engine/Security and User Management logic from the rest of the suite, so that they may be used independently to develop new applications. (Personally, I think there's a another product in there...just dying to be set free :-) One final observation: Recently, I convinced someone to bypass consideration of the Sun Portal Server for a pending development effort, all because the "free" Sun download was too hard to install. (My argument: if it's that hard to install, then it must be a nightmare to maintain...) Please, no matter what else you do, don't ever trade away the easy download, installation and initial demonstration features of OFBiz. To me, that is one of its best selling points. Hope this helps. Ruth _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Chris,
The actual idea seems really good, but I think the hardest thing about commenting on this is that it's far from clear that a stable page layout can be achieved (particularly in IE) by strictly using this approach. The ecommerce application has quite a few oddities. Is anyone working specifically on layout? -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
In reply to this post by Si Chen-2
On 5/5/06, Si Chen <[hidden email]> wrote:
> Hi everybody. I'm sure this is something we all think about day and night, > so I thought I'd start a thread to discuss it: > > How do we spur greater adoption of OFBIZ? Hi, here are some of my thoughts. I'm in a bit of a hurry, so they're a bit jumbled: *) Who is the target? I'm sure those who have been doing consulting have a better idea, but I see two groups: 1) those who don't have the money to purchase a big, expensive solution, and 2) people who need to do heavy duty customization, and value the freedom to do so. I think the second group has less requirements than the first does, because they expect to get their hands dirty with code. They're also more likely to participate in development and give something back. However, the first group is potentially much larger (I think, at least), but likely requires more effort. Here are a few things I think would help: *) Documentation. *) A more polished 'user experience'. I think there is a lot of room for both a prettier and more intuitive UI in OFBiz. This doesn't just mean a prettier look, but a UI that helps guide the user through common tasks without confounding them with too many options or "unnecessary" steps. As an example, my boss likes JIRA a lot, and is lukewarm to OFBiz. He was surprised to hear they are based on the same engine. *) 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. *) Tested releases. Maybe it's not time yet, but people like to have something that's been gone over thoroughly. More test automation would probably help. *) Minimize forking. Choice *isn't* good in some cases - it tends to confuse people, and make them worry about whether they're getting the best/right one. Anyway, can't say as I'll have the chance in the near future to actually help do those things, but, since you asked... Ciao, -- 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 |
|
|
In reply to this post by Andrew Sykes
On Sunday 07 May 2006 16:00, Andrew Sykes wrote:
> Chris, > > Is anyone working specifically on layout? the opentravel system backend has a new design, however only tweeking the css stylesheets... -- 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 |
attachment0 (196 bytes)
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
In reply to this post by davidnwelton
David Welton wrote: > *) A more polished 'user experience'. I think there is a lot of room > for both a prettier and more intuitive UI in OFBiz. This doesn't just > mean a prettier look, but a UI that helps guide the user through > common tasks without confounding them with too many options or > "unnecessary" steps. As an example, my boss likes JIRA a lot, and is > lukewarm to OFBiz. He was surprised to hear they are based on the > same engine. > > *) 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 Because that is the case we have decided to be inclusive about functionality and as different groups with different requirements use and contribute to OFBiz we over time get a bigger and bigger library of (hopefully) generic functionality. The problem, as you've identified here is that it is _way_ too much for many users and they don't want to see it all. The reason for leaning toward the inclusive side is that it is much easier to comment things out in the UI or create a derivate custom UI that doesn't include them (or extends existing forms, for example, and explicitly excludes/ignores them) than it is to add them in for those who need/want them... Without defining at least an industry to target it is impossible to limit the fields and such used in places, or to set good default values for them in many cases. So, for your group #1 who wants to use it mostly as-is, they can either put in the time/money to customize the UI, or wait for a derivative (not fork if done properly...) of OFBiz that addresses their specific industry. These can certainly be open source, but I think given the smaller target audience (by definition) for them that they will be more functional and less expensive alternatives to existing commercial systems, but still commercial themselves... > *) Tested releases. Maybe it's not time yet, but people like to have > something that's been gone over thoroughly. More test automation > would probably help. Yes, more test automation is _very_ important for this. Gone are the days when I could personally review the code base and test things and assure some level of quality, it is just too big! We do have some ongoing testing being done by various people, including the technical writer who maintains the Undersun online end-user oriented documentation. Still, we really need automated testing. There have been various discussions about this and a pretty good set of tools and techniques laid down but what is still lacking is a tool to tie all of these together in a way to run different kinds of tests in a big sequence (perhaps with thread branches and such to test parallel behavior). I've written a bit about the need for this and what it would look like, but it needs to be written. It has been next on my list of things to do in my "free" time for a while, but got supplanted recently by the Geronimo stuff. As with all things it doesn't happen until someone does it, and I see about a 1 in 1,000,000 chance of getting funding for this, so everyone is just going to have to wait until I have enough free time and energy to get it done... Of course, if someone who understands what is needed here would like to work on it that would be great. It will involve some sort of configuration file (preferably XML...) that defines a series of te sts to run each of the types that we have discussed for automated (unit and functional) tests. Maybe I'll just do that instead of touristy things while I'm here in London, as those are usually pretty lame and disgusting in their cheaply prostituting great things for commercial gain, with the exception of various things of course. Maybe I just need a meal... Anyway, once a test running harness is in place we'll still have a huge amount of work to write automated tests for OFBiz. This is something that can be done in a much more parallel way and once an example is in place it should be easy for people to get started with it. Still, even if we don't have a comprehensive test suite I'd like to do a release after we are done with the Apache incubation process. We'll try to make it the best we can, and maybe even do a feature freeze and branch for it if there is enough interest... I think this would help adoption significantly even if the release isn't "perfect", and it would be a nice milestone as part of the move to a better place in the ASF for OFBiz. > *) Minimize forking. Choice *isn't* good in some cases - it tends to > confuse people, and make them worry about whether they're getting the > best/right one. It would be nice if there was a way to get people to get involved with the core project instead of forking. This applies not only to other open source projects, but on the largest scale to internal customized versions of OFBiz that so many companies use. For our clients I really push them toward updating regularly and putting as much as possible back in the project, and in their own self-interest too (significantly reduces ongoing maintenance and sometimes development costs), but it usually requires some very unpleasant and inefficient experiences with not doing so before they set it as an objective. Even once that happens it is still difficult to get people in their organization to understand what it means and how its best done... But as long as they set it as a priority that issue gets ironed out pretty quickly it seems. -David _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - End-User Docs (was: how to spur greater adoption - let's brainstorm!)
|
|
In reply to this post by Si Chen-2
These and many others are great ideas. Some have been "on the table" for a while, but I think it's a great idea to do some group brainstorming and maybe get pushing or finish previous efforts on some of these... Si Chen wrote: > 1. Freely available user documentation We have been trying to figure out a way to finance end-user oriented documentation for while. The online documentation site that Undersun is running is moving along steadily but has some issues: 1. it isn't free to use, unless you volunteer as a contributor 2. even not being free it is still about 85% subsidized by Andy and David, with lots of unpaid initial time contribution from Al Byers too 3. we have a good arrangement with a technical writer (Les Austin) who maintains this, but we get very little feedback and corrections and this is very needed; I am guessing/hoping that with a free site (or whatever form the content is in) this would improve a great deal... Si (who hopefully won't mind me making this public...) has written to me along these lines and we are brainstorming about ways to fund this effort and make the online site possibly free, but certainly have some sort of reformatted export that can be used in PDF form or printed if desired (perhaps even as a series of books to be published...), and make this freely available. With a book there is some potential of royalties, but I don't think that is a good plan and with the size of the potential buyer base, I think will not be even profitable for a long time, for the publisher (_if_ they even go for it), or for us. I may be wrong about this, but talking with authors of other books and such this seems to be largely the case. Companies like O'Reilly, Wrox, etc like very generic topics because they sell quantity, and I don't know if we'll be able to hit those, even if we do books on specific and more generic topics like the OFBiz Framework, or "Super-Duper Enterprise-ready Open Source eCommerce with OFBiz". Anyway, the problem here is just one simple thing: funding. With most of OFBiz we have funded the development through dozens of people working on probably hundreds of different contracts over the years. That model has worked okay for that, but for documentation the success rate percentage is probably not even in the single digits (ie less than 1%...). So, we have a big old "Little Red Hen" problem, but even worse. We have a lot of people interested in helping and such, but this ain't no loaf of bread we're breaking. It will have thousands of pages covering thousands of often complex topics requiring a lot of knowledge of the world of business in general and how OFBiz fits into that. Various people have written documents about one topic or another, but these are often redundant and being separate documents maintained by separate groups are very difficult to maintain. My proposal for this is the following: 1. have a central documentation repository, like the Undersun online doc site 2. have a single group (for now can be one person, Les Austin) of technical writers to incorporate contributions and do various organization and editing tasks based on feedback 3. make periodic exports from it freely available, and if we can various source forms that can be more easily customized for internal use as well 4. work toward a series of books based on this material, perhaps split along the traditional enterprise software lines to focus on ERP, CRM, MRP (could be included in ERP?), eCommerce, etc. Now back to the question of funding... We have a good arrangement with Les that is okay for him right now, but he won't be able to continue working forever at the rates we are paying him. Still, he lives simply and is interested in this work so it will be very affordable in any case for someone with his skills. If we could raise $2500 per month we should be able to keep Les on full-time for a while. This can come from various sources: 1. donations! 2. documentation customization efforts for internal documentation for customized versions of OFBiz, or for derivative works; hopefully we can arrange this in such a way that for anyone who wants a custom version of the documentation part of the contract earnings will be back into paying for maintenance of the generic docs, ie the $2500/mo listed above 3. sponsorship with nice big logos on the cover page and such as the reward for doing so, kind of like the Integral/Undersun thingy for the Basic Production Setup Guide document Right now the repository is running on a custom application that is build on the content manager of OFBiz. It is pretty good and has been in use for a couple of years now. Les has had to work around some quirks and I imagine that this could be improved a lot, but it was a big enough contribution as it was to the effort done mostly by Al Byers. He gets a share of the documentation revenue, but as mentioned above it doesn't come close to covering what goes into this... We could change the tool used for this, but I don't really know of a really good alternative. Perhaps something like Confluence, but we'd have to look into it. The current solutions allows for management of thousands of little chunks of content organized into a big tree with various top-level documents. Of course I'm biased on the design and structure of the data because I was the channel through which it was spewed into the world. On second thought I'm going to make this a separate post to get the discussion on end-user documentation isolated... -David _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
|
|
In reply to this post by Si Chen-2
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 rel 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 |
|
|
In reply to this post by David E. Jones
David E Jones wrote: >These and many others are great ideas. Some have been "on the table" for a while, but I think it's a great idea to do some group brainstorming and maybe get pushing or finish previous efforts on some of these... > > >Si Chen wrote: > > >>1. Freely available user documentation >> >> > >We have been trying to figure out a way to finance end-user oriented documentation for while. The online documentation site that Undersun is running is moving along steadily but has some issues: > >1. it isn't free to use, unless you volunteer as a contributor >2. even not being free it is still about 85% subsidized by Andy and David, with lots of unpaid initial time contribution from Al Byers too >3. we have a good arrangement with a technical writer (Les Austin) who maintains this, but we get very little feedback and corrections and this is very needed; I am guessing/hoping that with a free site (or whatever form the content is in) this would improve a great deal... > >Si (who hopefully won't mind me making this public...) has written to me along these lines and we are brainstorming about ways to fund this effort and make the online site possibly free, but certainly have some sort of reformatted export that can be used in PDF form or printed if desired (perhaps even as a series of books to be published...), and make this freely available. > >With a book there is some potential of royalties, but I don't think that is a good plan and with the size of the potential buyer base, I think will not be even profitable for a long time, for the publisher (_if_ they even go for it), or for us. I may be wrong about this, but talking with authors of other books and such this seems to be largely the case. Companies like O'Reilly, Wrox, etc like very generic topics because they sell quantity, and I don't know if we'll be able to hit those, even if we do books on specific and more generic topics like the OFBiz Framework, or "Super-Duper Enterprise-ready Open Source eCommerce with OFBiz". > >Anyway, the problem here is just one simple thing: funding. With most of OFBiz we have funded the development through dozens of people working on probably hundreds of different contracts over the years. That model has worked okay for that, but for documentation the success rate percentage is probably not even in the single digits (ie less than 1%...). > >So, we have a big old "Little Red Hen" problem, but even worse. We have a lot of people interested in helping and such, but this ain't no loaf of bread we're breaking. It will have thousands of pages covering thousands of often complex topics requiring a lot of knowledge of the world of business in general and how OFBiz fits into that. Various people have written documents about one topic or another, but these are often redundant and being separate documents maintained by separate groups are very difficult to maintain. > >My proposal for this is the following: > >1. have a central documentation repository, like the Undersun online doc site >2. have a single group (for now can be one person, Les Austin) of technical writers to incorporate contributions and do various organization and editing tasks based on feedback >3. make periodic exports from it freely available, and if we can various source forms that can be more easily customized for internal use as well >4. work toward a series of books based on this material, perhaps split along the traditional enterprise software lines to focus on ERP, CRM, MRP (could be included in ERP?), eCommerce, etc. > >Now back to the question of funding... We have a good arrangement with Les that is okay for him right now, but he won't be able to continue working forever at the rates we are paying him. Still, he lives simply and is interested in this work so it will be very affordable in any case for someone with his skills. If we could raise $2500 per month we should be able to keep Les on full-time for a while. This can come from various sources: > >1. donations! >2. documentation customization efforts for internal documentation for customized versions of OFBiz, or for derivative works; hopefully we can arrange this in such a way that for anyone who wants a custom version of the documentation part of the contract earnings will be back into paying for maintenance of the generic docs, ie the $2500/mo listed above >3. sponsorship with nice big logos on the cover page and such as the reward for doing so, kind of like the Integral/Undersun thingy for the Basic Production Setup Guide document > >Right now the repository is running on a custom application that is build on the content manager of OFBiz. It is pretty good and has been in use for a couple of years now. Les has had to work around some quirks and I imagine that this could be improved a lot, but it was a big enough contribution as it was to the effort done mostly by Al Byers. He gets a share of the documentation revenue, but as mentioned above it doesn't come close to covering what goes into this... > >We could change the tool used for this, but I don't really know of a really good alternative. Perhaps something like Confluence, but we'd have to look into it. The current solutions allows for management of thousands of little chunks of content organized into a big tree with various top-level documents. Of course I'm biased on the design and structure of the data because I was the channel through which it was spewed into the world. > >On second thought I'm going to make this a separate post to get the discussion on end-user documentation isolated... > >-David > > > >_______________________________________________ >Users mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/users > > > > >>we get very little feedback and corrections and this is very needed I would be quite happy, as an experienced copy-editor, to make corrections as I read it and to post them to you. CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by David E. Jones
David E Jones wrote: >These and many others are great ideas. Some have been "on the table" for a while, but I think it's a great idea to do some group brainstorming and maybe get pushing or finish previous efforts on some of these... > > >Si Chen wrote: > > >>1. Freely available user documentation >> >> > >We have been trying to figure out a way to finance end-user oriented documentation for while. The online documentation site that Undersun is running is moving along steadily but has some issues: > >1. it isn't free to use, unless you volunteer as a contributor >2. even not being free it is still about 85% subsidized by Andy and David, with lots of unpaid initial time contribution from Al Byers too >3. we have a good arrangement with a technical writer (Les Austin) who maintains this, but we get very little feedback and corrections and this is very needed; I am guessing/hoping that with a free site (or whatever form the content is in) this would improve a great deal... > >Si (who hopefully won't mind me making this public...) has written to me along these lines and we are brainstorming about ways to fund this effort and make the online site possibly free, but certainly have some sort of reformatted export that can be used in PDF form or printed if desired (perhaps even as a series of books to be published...), and make this freely available. > >With a book there is some potential of royalties, but I don't think that is a good plan and with the size of the potential buyer base, I think will not be even profitable for a long time, for the publisher (_if_ they even go for it), or for us. I may be wrong about this, but talking with authors of other books and such this seems to be largely the case. Companies like O'Reilly, Wrox, etc like very generic topics because they sell quantity, and I don't know if we'll be able to hit those, even if we do books on specific and more generic topics like the OFBiz Framework, or "Super-Duper Enterprise-ready Open Source eCommerce with OFBiz". > >Anyway, the problem here is just one simple thing: funding. With most of OFBiz we have funded the development through dozens of people working on probably hundreds of different contracts over the years. That model has worked okay for that, but for documentation the success rate percentage is probably not even in the single digits (ie less than 1%...). > >So, we have a big old "Little Red Hen" problem, but even worse. We have a lot of people interested in helping and such, but this ain't no loaf of bread we're breaking. It will have thousands of pages covering thousands of often complex topics requiring a lot of knowledge of the world of business in general and how OFBiz fits into that. Various people have written documents about one topic or another, but these are often redundant and being separate documents maintained by separate groups are very difficult to maintain. > >My proposal for this is the following: > >1. have a central documentation repository, like the Undersun online doc site >2. have a single group (for now can be one person, Les Austin) of technical writers to incorporate contributions and do various organization and editing tasks based on feedback >3. make periodic exports from it freely available, and if we can various source forms that can be more easily customized for internal use as well >4. work toward a series of books based on this material, perhaps split along the traditional enterprise software lines to focus on ERP, CRM, MRP (could be included in ERP?), eCommerce, etc. > >Now back to the question of funding... We have a good arrangement with Les that is okay for him right now, but he won't be able to continue working forever at the rates we are paying him. Still, he lives simply and is interested in this work so it will be very affordable in any case for someone with his skills. If we could raise $2500 per month we should be able to keep Les on full-time for a while. This can come from various sources: > >1. donations! >2. documentation customization efforts for internal documentation for customized versions of OFBiz, or for derivative works; hopefully we can arrange this in such a way that for anyone who wants a custom version of the documentation part of the contract earnings will be back into paying for maintenance of the generic docs, ie the $2500/mo listed above >3. sponsorship with nice big logos on the cover page and such as the reward for doing so, kind of like the Integral/Undersun thingy for the Basic Production Setup Guide document > >Right now the repository is running on a custom application that is build on the content manager of OFBiz. It is pretty good and has been in use for a couple of years now. Les has had to work around some quirks and I imagine that this could be improved a lot, but it was a big enough contribution as it was to the effort done mostly by Al Byers. He gets a share of the documentation revenue, but as mentioned above it doesn't come close to covering what goes into this... > >We could change the tool used for this, but I don't really know of a really good alternative. Perhaps something like Confluence, but we'd have to look into it. The current solutions allows for management of thousands of little chunks of content organized into a big tree with various top-level documents. Of course I'm biased on the design and structure of the data because I was the channel through which it was spewed into the world. > >On second thought I'm going to make this a separate post to get the discussion on end-user documentation isolated... > >-David > > > >_______________________________________________ >Users mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/users > > > > >>we get very little feedback and corrections and this is very needed; I would be quite happy, as an experienced copy-editor, to make corrections as I read it and to post them to you. CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
I just was at a meeting of open source developers here in Portland where someone gave a presentation on on different methods OS teams use to get funding for their projects. This being the most recent project I've played around with, I was relating the material to your situation (for as well as I understand it). My conclusion is that you will find the funding you are seeking in the form of donations or venture capitalism, voluntary "royalty"-like donations of a growing user base and whatnot if you can develop clear and accurate-to-version documentation that comes in the distribution package itself, is linked to from the application screens, and provides: 1. Basic setup guide for non-developers who want to see how hard it is to get running. 2. A basic tour of the general feature packages -- breaking it down may be okay, as mentioned below, but they need to be linked too, so that a team of business people, some of whom will be the sole users of certain areas of the package (example: book keeper vs. web site editor). The tour should include an overview, and maybe a 101, 202, and Advanced sections for levels of use. Advanced would essentially be written for developers, whereas 101 and 202 would be for people who think java is coffee or an evolutionary stage of humans. The software package's wysiwyg web site editor and the setup software should reflect this philosophy as well. The wysiwyg editor need not be capable of doing advanced site development, as people more serious than throwing together an html site on their own should be expected to know how to code it anyway, or hire someone. In touring other OS packages of various types, I've found it helpful when setup software and basic editor software has some way of showing you what it is doing to the architecture in the background... um, I guess an example of this would be phpMyAdmin, with its display of the SQL commands that are being executed by clicking on different options. 3. I'm just beginning to get a basic feel for the demo data that can be installed, so I don't know how much redundancy I'm typing out right now -- I am about halfway through the Undersun tutorial on changing the demo data to your own company's data. Because of the complexity of this program, I was thinking a good way to help people get familiar with it is to actually have a tutorial that takes the existing demo data and replaces it with other demo data -- like an organizational face-lift. I'm thinking primarily about the web store's site, but you could blow it up into a full-scale overhaul, I suppose. So the idea is you have a basic company running on OFBiz, and you decide to hire a graphic artist and marketing person who make suggestions for a new look. They hand you all of the redesign bits (images, color palettes, etc.), and it's your responsibility to swap out the existing bits for the new bits using the wysiwig editor, maybe create some new pages, and then you can see the results of the face-lift. Also, there really should be a How-To wiki that is filling up with various company structuring suggestions (so you have a how-to for some different manufacturing companies, and maybe some more for some music retail companies, a subscribable online magazine, a doctor's office, etc.). Does this exist somewhere? There's something to be said for access and intuitiveness, which David pretty much covers below. An example is Wrapper's (wrapper.tanukisoftware.org) documentation. It's so easy to find the setup docs on the site, and you pretty much know what you need to do to set something up as a service with little to no understanding of how wrapper's components work in the background. No wiki at some user's site can do a better job than the instructions they provide, which hints at how good those instructions are. The first time I used wrapper I hadn't looked at Java in seven years. Uh, not to say that ofbiz is as simplistic a software package... no no no, I understand that it's huge and feature rich, but user docs should not reflect that in being complex themselves. MS Word (Penguin forgive me for the utterance) is a huge chunk of software, but the docs could be read and understood by someone from the 1700's who hasn't slept in ten days, and most users won't even know what it's written in. Easy to yak and not to help. I THINK OFBiz is what I'm going to use to build a new ecommerce site I have in mind. If I can find a java developer who is interested in the project and is willing to put in some hours doing the stuff I'm clueless about for later reward, and the site takes off, I'd be happy to turn around and put some of the earnings where my mouth is, hire someone to provide you guys with the docs I dream of. I'm sure such documentation would draw a whole new user-base of people. Of course, I'm impulsive and interested in keeping my house, so if it looks like it's going to be long and drawn out, I'll scuttle everything and move on to the next idea. So don't count on me. :) Finally, some of what I talked about above was not documentation, but refining the setup process. No full-scale CRM/ERP/ecommerce open source package out there does a good job at setup -- meaning, it's as easy as installing, for example, XAMPP (I love those people). If you can figure out how to make it so Joe Dorkus (that's me) can install the thing and get a good feel for all of the features in a couple of hours, then, like I already said, you'll be chalk full of distribution. Best, --ChrisM David E Jones wrote: --------------030304000401010809020400--These and many others are great ideas. Some have been "on the table" for a while, but I think it's a great idea to do some group brainstorming and maybe get pushing or finish previous efforts on some of these... Si Chen wrote:
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. _______________________________________________ Users mailing list Users@... http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - how to spur greater adoption - let's brainstorm!
Administrator
|
In reply to this post by David E. Jones
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 |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |