Jacques, very interesting analysis, thank you.
Jacopo On May 13, 2015, at 10:26 AM, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > Hi Julien, > > Actually it's a very important topic. OFBiz indeed misses from the start a > way to include extensions in a snap. OFBiz was created in 2001, then > components was seen as a way to introduce extensions. And it did not work too > bad, see we are still there :). > > Then microservices was not a hot-topic, and OFBiz was a bit ahead with SOA , > then the EDA was introduced in OFBiz when it was obvious a workflow engine > was not the way. So in 2005 OFBiz had a state of art architecture. But then a > new generation of concurrents (open source ERPs) was emerging. One of the > most proeminent was OpenERP (now Odoo). Actually note that OFBiz has no real > concurrents in the sense of no other is supported by a community like we do > here at Apache apart Adempiere, all others are owned by a company. > > But there is a lesson we can take from Odoo, it's its extensions mechanism (I > don't think other "concurrents" have the same extensions mechanism > available). Actually I don't know much about it, I never used it, and I know > there are also issues with it (*spaghetti syndrome*) but the idea worked also > for other projects (not ERP) to build a strong community. I sometimes wonder > if it's not a marketing way to build a community, but that another topic and > it would break the one we are currently discussing. Examples: > https://www.odoo.com/apps > https://www.drupal.org/project/extensions > https://github.com/django-extensions/django-extensions > http://www.magentocommerce.com/magento-connect/ > > So I agree about the functional part, as you call it, but the point is more > the technical part: how to achieve this extensions mechanism. > > I see 4 proposed ways for now: > > 1. a patches manager as proposed by OFBiz-France > 2. Git branches and a Git ecosystem (like GitHub) > 3. Sub projects > 4. A microservices architecture > > Sincerely, all have their limitations and drawbacks, and we should discuss > them. Note that they are not antinomic and could be combined. In the end it's > a huge and risky effort, we need to clear about what to do, if ever we do > something! > > One last things I'd like to add, is I believe the current situation is > because main OFBiz integrators are eCommerce sites providers (OFBiz has been > towed by eCommerce). So they have a minor interest in the ERP/backend side > even if actually they know it's what distinguish them from other more > traditional eCommerce sites providers like Magento and the now declining > OsCommerce (users ate too much *spaghetti)*.**Finally, this would not be > complete if I did not add my own rant. You can see the disinterest in the ERP > side because those companies need to build specific UIs for their client > (whatever technology they use for that). So, since the jQuery effort, almost > nothing has been done in widgets side. For backend I still find smarter to > generate HTML using widgets than to build all by hand, but this needs more > love, it's unfortunately the neglected part of the framework :/ > > Jacques > > Le 13/05/2015 08:56, Julien NICOLAS a écrit : >> Hi all, >> >> I was hopping more people will explain on this subject. It's exactly what I >> was thinking, that the functional part is less than the last priority of the >> project. >> I don't know exactly how I can do it but I really want to start something >> that will use OFBiz as a framework. If it can be done with the OFBiz >> community, it will be really good. >> >> Efforts exist but need people of the strong OFBiz community to be really >> better (GrowERP, BigFish, TERCompta, etc.). >> >> It's a pity that every new company that want to work with OFBiz must work on >> it's own version to be able to integrate it. I don't think it's a good thing >> for the project growing. >> And OFBiz community don't allow company to find easily other effort to >> enhance the software. And finally it seems that there is less than 5 peoples >> interested to work on this way. >> >> Maybe I'm wrong, functional is not as important as I thought... >> >> Sorry for the noise, >> >> Julien. >> >> >> Le 07/05/2015 16:00, Ron Wheeler a écrit : >>> I agree with Julien's analysis. >>> If I say "sub-projects" again, Jacques will whack me upside the head but I >>> really think that a restructuring of the way the architecture is presented >>> and developed would provide a number of benefits: >>> - increase community involvement with less work for the current key >>> committers >>> - reduce or eliminate sub-optimal inter-component dependencies through >>> clearer definitions and independent releases of components >>> - reduce mixing of core seed data with demo and customizable seed data and >>> inter-component data confusion. >>> - facilitate the construction of components and add-ons that do not have >>> undesirable or unknown side-affects >>> - facilitate the injection of a smart installer that would allow the >>> selection of components and templates as suggested at install time. >>> - facilitate the development of an OFBiz marketplace for add-ons and >>> industry-specific configurations. >>> - make the role of the framework as a base for other products much clearer. >>> - possibly make it easier to "Moquify" the framework if the framework API >>> can be made less implementation dependent - lots of issues here that >>> already have been fully ventilated last week. >>> >>> Ron >>> >>> On 07/05/2015 7:28 AM, Michael Brohl wrote: >>>> Hi Julien, >>>> >>>> thank you for bringing this up! >>>> >>>> I don't think that this is of no interest in the community, it's just >>>> overlaid by the many other topics we are discussing currently. I >>>> personally think that all topics are worth to be discussed and elaborated, >>>> maybe they have to be prioritised a little bit more. Right now it's a >>>> little bit confusing and not easy to follow (and contribute to) the >>>> discussions besides daily business. >>>> >>>> I think it is an important topic to simplify the backend component's UI >>>> and have more sophisticated usability there. On the other hand, it is >>>> important to somehow show customers the powers of OFBiz and the many >>>> already set-up functionalities. It would be a big step forward if we find >>>> a way to make this customizeable. For an ERP, it would also be a big plus >>>> to have some kind of "business templates" (!= UI templates) on top of such >>>> a mechanism, like >>>> >>>> - Your customer sells products over the internet? - pull the ecommerce >>>> template >>>> - Your customer brews beer? - pull the manufacturing +x template >>>> - Your customer has a small business? - pull the corresponding template >>>> etc. >>>> >>>> I belive that would require different configuration mechanisms, more on a >>>> database level with a clever UI instead of many different property files. >>>> And maybe a tool to chain services together on base of such a template. >>>> >>>> I won't reduce the functionality in OFBiz per se, as long as they are >>>> stable and/or have a maintainer. >>>> >>>> I know of at least one contributor who is also working on a more >>>> sophisticated UI, maybe he shows up here also ;-) >>>> >>>> So, without having a concrete plan or more thought-out ideas how to >>>> implement this, I would support such an effort. >>>> >>>> As a community, I think we have to find a way to channel the different >>>> interests from core technology work up to the business layer. Some kind of >>>> overall project management would help but would be difficult to install in >>>> an open community. Too many open building sites in parallel are not that >>>> efficient. >>>> >>>> Curious what others think... >>>> >>>> Regards, >>>> >>>> Michael Brohl >>>> ecomify GmbH >>>> www.ecomify.de >>>> >>>> >>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS: >>>>> Hello All, >>>>> >>>>> Since I work on the bootstrap theme in OFBiz, I have many thoughtful, >>>>> carefully read the ofbiz community exchanges and spoke with some members >>>>> of the OFBiz community. >>>>> Today I am convinced that the OFBiz project is a framework that is not >>>>> intended to be an ERP. Its OOTB user interface is a nightmare and is not >>>>> really user oriented. >>>>> Several topics that seem to have no link together, seems to be linked >>>>> around the same idea. >>>>> >>>>> The first topic is about functionality of OFBiz. >>>>> On one hand, there is the OFBiz framework. It contains a user interface >>>>> to show the possibility of OFBiz, but must be changed during integration. >>>>> It also includes functional oriented features. These features split the >>>>> community between those who want to keep them in the project and those >>>>> who wish to exclude them. >>>>> On the other hand, there are new initiatives,abandoned projects, old or >>>>> having no longer contributors (project manager, POS, etc.) who need >>>>> support, visibility, even if they are not added to the OFBiz project. >>>>> A first approach was discussed with GIT. It can allow everyone to share >>>>> their work more easily with branch feature. Which is good but not the >>>>> best in my opinion. >>>>> >>>>> Another topic that is important to me is the functional part of OFBiz. >>>>> Sharan explained me about its willingness to invest energy to make the >>>>> software more functional, and if it's possible to have a version with ERP >>>>> oriented for small businesses with minimal features but easy to use. Like >>>>> growERP or TerCompta offer. Using OFBiz framework but simplify the UI to >>>>> allow the software to be used intuitively without modifications. >>>>> >>>>> These initiatives come up against the model of OFBiz project. Who has >>>>> still not decided whether it is an ERP, in which case it needs to adjust >>>>> its UI or an automation of enterprise processes framework, which involves >>>>> getting rid of unnecessary features dedicated to ERP. >>>>> >>>>> There are several solutions that could help to make better the model of >>>>> OFBiz and satisfy the entire community. >>>>> The first solution would be to limit the “OFBiz framewok” project >>>>> framework for automation enterprise processes and to have another “OFBiz >>>>> ERP” project which would use the framework as a basis, and which would >>>>> provide a user-friendly UI and dedicated tools to ERP. >>>>> >>>>> The second option is to find a way to cut the project in extensions. This >>>>> solution would have the opportunity to clean the framework and have >>>>> features as micro projects and therefore no longer a monolithic software. >>>>> >>>>> I see a lot of debate about adding new functionality that allow to >>>>> improve development, compile, manage sources, merge with another >>>>> framework, but the debate on the division of project extensions seems not >>>>> to interest. It seems to me extremely important to facilitate development >>>>> and therefore, ultimately, the visibility of the project in the >>>>> developers community. >>>>> >>>>> At Nomaka, we initiated an effort starting from the first solution. We >>>>> took OFBiz framework, deleted all the themes and created a new one. Then >>>>> we redesigned the interface to match a basic ERP. >>>>> We started with actor UI. Disabled existing screens and created new ones >>>>> more functional and user-friendly. >>>>> >>>>> I find it a pity to work alone in my corner without being able to easily >>>>> share my work, without taking advantage of the OFBiz community knowledge >>>>> to guide me onthe right way. >>>>> I wonder if we could work on this axis and balance the rigidity necessary >>>>> to have a stable project and flexibility that allow to include >>>>> non-committer contributions ... >>>>> >>>>> What do you think ? >>>>> >>>>> Julien. >>>>> >>>> >>> >>> >> >> >> >
