Marketing OFBiz and the OFBiz non-object approach (was Re: Wicket in OFBiz)

[BJ Freeman]

#1 I can see the problem with backward compatibility, though I think
this is confused with migration path. From the statement not to support
backward and/or migration, you have created a new industry, which I am
glad to fill.

#2 From David statements about dumping ofbiz framework for Moqui, and
that his concern is more a out getting developers to adopt ofbiz or
moqui, I would say there is not much support for production servers done
for commercial purposes. the only statement was that the Developers
(committers) had many production servers does not count since it still
means you need developer to use ofbiz, and developers, on the mailing
list have not voiced support for #1.
So this is mute as far as anyone planning to use ofbiz in their business
and want a decent ROI.

#3I like your thinking, and agree. Having worked with IBM, and their
licensing, I keep feeling like many have the same attitude.
I was actually looking forward to the ASF acceptance because it would
force a lot of attitudes to conform. Looks like there is a lot of
resistance to that.




=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Jacopo Cappellato sent the following on 1/26/2011 2:11 AM:

> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>
> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk
>
> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)
>
> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this
>
> Kind regards,
>
> Jacopo
>
> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>
>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>
>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>
>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>
>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>
>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>
>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>
>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>
>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>
>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>
>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>
>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>
>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>
>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>
>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>
>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>
>> So, please say something.
>>
>> -Adrian
>>
>>
>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>
>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>
>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>
>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>
>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>
>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>
>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>
>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>
>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>
>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>
>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>
>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>
>>> I should get back to work... there's a short list anyway...
>>>
>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>
>>> -David
>>>
>>>
>>
>
>

[BJ Freeman]

I have created
https://sourceforge.net/projects/ofbizaddons/
when ofbiz was at version 3.
this also allows people to get donations or their work.
Based on the conversation on this thread, I don't a addon manager will
deal with lack of compatibility and migration.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Erwan de FERRIERES sent the following on 1/27/2011 3:02 AM:

> Le 27/01/2011 11:50, Scott Gray a écrit :
>> (With so many messages I don't have a good spot to say my short piece
>> so here will do)
>>
>> IMO our problems will only increase with the size of the code base.
>> Every time a new feature is committed you have an additional potential
>> audience that must be kept happy and our ability to please everybody
>> continues to decrease. Unhappy people don't work well together so
>> things just keep getting worse.
>>
>> Solution? Decrease the size of the code base and included features and
>> increase the ability for the community to share contributions outside
>> of the ASF's repo. Decrease the load on the committers and let the
>> rest of the community put their money where their mouth is.
>> Some ideas (feasible or not):
>> - Pull out all of the themes except one and move each one to google
>> code or wherever if there is someone interested in looking after each
>> one.
>> - Then do the same for the bulk of the special purpose apps.
>> - Separate the framework from the applications.
>> - Remove any framework features that aren't used by the applications
>> or are of relatively low value and allow them to be dropped in by
>> users when they need them.
>> - Perhaps even take another look at the possibility of reducing the
>> dependencies among the core apps and splitting them (I'd gladly
>> welcome 100 new committers to the humanres app because I have no
>> interest in it).
>> - Turn the payment and shipping gateway implementations into drop in
>> components along with any other pieces of code that are suitable for
>> extraction
>> - Investigate ways to allow plug-in modification of apps and implement
>> something (anything) that allows it.
>>
>> Right now we have a gigantic project with a gateway of ~13 active
>> committers (23 total) who have day jobs to worry about along with
>> reviewing (and fighting about) commits (or just giving up on this
>> responsibility), attempting to improve the project and taking part in
>> these (mostly pointless discussions) and then keeping the rest of the
>> community happy. Increasing the number of committers just increases
>> the potential for disagreement and then stagnation so the only other
>> option to reduce the code.
>>
>> Give control of features and components to people who care about them
>> and then help users find them externally as they need them. Don't like
>> the direction a feature/component is taking? Fork it and compete.
>>
>
> we've got the apache-extras which could be a great place to put those
> features and so on. At the moment, there is nothing related to OFBiz.
>
> http://code.google.com/a/apache-extras.org/hosting/
>
> Also, at Nereide, where I'm working, we've got the addon manager, which
> we are using for adding features to OFBiz. Maybe we could give it a try
> for splitting OFBiz, as you say. I've already been speaking about it.
> Still open to anyone !
>
>
>

[BJ Freeman]

another solution is to get people committed to a part of the code and
establish a communication form where all contribute.
This has worked well in a formal commercial enviorement. So even though
this is a community effort why can't we take from a commercial model
that works.
the Biggest piece I see missing is code review.
This, is by the ASF, suppose to be initiated by an annoucemtn of changes
to the code in the Dev list. I see a few use the announcement discuss
but not the majority.




=========================

BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Scott Gray sent the following on 1/27/2011 2:50 AM:

> (With so many messages I don't have a good spot to say my short piece so here will do)
>
> IMO our problems will only increase with the size of the code base.  Every time a new feature is committed you have an additional potential audience that must be kept happy and our ability to please everybody continues to decrease.  Unhappy people don't work well together so things just keep getting worse.
>
> Solution?  Decrease the size of the code base and included features and increase the ability for the community to share contributions outside of the ASF's repo.  Decrease the load on the committers and let the rest of the community put their money where their mouth is.
> Some ideas (feasible or not):
> - Pull out all of the themes except one and move each one to google code or wherever if there is someone interested in looking after each one.
> - Then do the same for the bulk of the special purpose apps.
> - Separate the framework from the applications.
> - Remove any framework features that aren't used by the applications or are of relatively low value and allow them to be dropped in by users when they need them.
> - Perhaps even take another look at the possibility of reducing the dependencies among the core apps and splitting them (I'd gladly welcome 100 new committers to the humanres app because I have no interest in it).
> - Turn the payment and shipping gateway implementations into drop in components along with any other pieces of code that are suitable for extraction
> - Investigate ways to allow plug-in modification of apps and implement something (anything) that allows it.
>
> Right now we have a gigantic project with a gateway of ~13 active committers (23 total) who have day jobs to worry about along with reviewing (and fighting about) commits (or just giving up on this responsibility), attempting to improve the project and taking part in these (mostly pointless discussions) and then keeping the rest of the community happy.  Increasing the number of committers just increases the potential for disagreement and then stagnation so the only other option to reduce the code.
>
> Give control of features and components to people who care about them and then help users find them externally as they need them.  Don't like the direction a feature/component is taking? Fork it and compete.
>
> Regards
> Scott
>
> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>
>> I have noticed some negative trends happening to us in the last (1-2) years:
>> * a dramatic decrease of design discussions and an increase in commits
>> * committers are often working for themselves and not for the greater good of the project ("if a customer pays me to do something then it will be also good for the project")
>> * less peer reviews and mostly focused on formal aspects rather then fundamental aspects of the contributions
>> * a decrease in the minimum quality level needed to make a commit "acceptable"
>> * a proliferation of "best practices" and "rules" in an attempt to improve the quality of the commits
>> * a decay in the attitude and quality of discussions: attacks, critics and fights instead of healthy discussions to learn from others and improve design decisions
>>
>> Of course I am focusing on bad things, to the good ones (yes, there are also good ones) it is easier to adjust: however when the final result of our efforts is that a person like David doesn't feel comfortable in contributing more then I feel bad.
>> The primary goal of the PMC, and the community in general, should be that of creating the perfect environment to facilitate contributions from people like David, and limit/review/improve the contributions from other less blessed contributors: it seems like all our efforts are obtaining the exact opposite result.
>>
>> Jacopo
>>
>> On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
>>
>>>
>>> I'll respond here to Adrian's comments below, and to what Raj and others have written as well.
>>>
>>> Backwards compatibility is a huge issue, but I suppose that is as much a symptom as it is a disease in and of itself. The underlying issue is bureaucracy.
>>>
>>> If I wanted to spend all my time chatting with others and writing endlessly about when to do things and what to do, and trying to recruit others to do it... then OFBiz would be the perfect place for that. I did that for years, and I'm happy with what has been done with OFBiz, but there came a point in time where the whole bureaucratic trend became stronger than any single person's ability to push for new or different things. That point in time was at least a yeah and a half ago, and perhaps long earlier than that depending on how you look at it.
>>>
>>> Personally, I'd rather spend my time on more productive efforts, and do so in a way that avoids this same bureaucratic mess in the future (like different management style and keeping framework, data model, themes, and applications as separate projects). This way not only I, but many people are free to work on what they want to and not have to argue about every little thing they want to do, or deal with constant complaints about every little thing they actually do.
>>>
>>> Isn't separate and competing projects better than that everyone arguing and having to agree on what to do? Well, I have good news! No matter how you (the reader) answer that question, you have an option to fit your preferences.
>>>
>>> -David
>>>
>>>
>>> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>>>
>>>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>>>
>>>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>>>
>>>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>>>
>>>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>>>
>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>>>
>>>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>>>
>>>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>>>
>>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>>>
>>>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>>>
>>>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>>>
>>>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>>>
>>>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>>>
>>>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>>>
>>>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>>>
>>>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>>>
>>>> So, please say something.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>
>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>>>
>>>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>>>
>>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>
>>>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>
>>>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>>>
>>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>>>
>>>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>>>
>>>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>>>
>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>>>
>>>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>>>
>>>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>>>
>>>>> I should get back to work... there's a short list anyway...
>>>>>
>>>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>
>>>
>>
>

[David E. Jones-2]

Thanks Scott, this is exactly the approach I'd prefer to see and I agree it would avoid a lot of the conflict (not more tragedy of the commons) and allow for greater growth for the project, and opportunities for individuals to do something.

-David


On Jan 27, 2011, at 2:50 AM, Scott Gray wrote:

> (With so many messages I don't have a good spot to say my short piece so here will do)
>
> IMO our problems will only increase with the size of the code base.  Every time a new feature is committed you have an additional potential audience that must be kept happy and our ability to please everybody continues to decrease.  Unhappy people don't work well together so things just keep getting worse.
>
> Solution?  Decrease the size of the code base and included features and increase the ability for the community to share contributions outside of the ASF's repo.  Decrease the load on the committers and let the rest of the community put their money where their mouth is.  
> Some ideas (feasible or not):
> - Pull out all of the themes except one and move each one to google code or wherever if there is someone interested in looking after each one.  
> - Then do the same for the bulk of the special purpose apps.  
> - Separate the framework from the applications.
> - Remove any framework features that aren't used by the applications or are of relatively low value and allow them to be dropped in by users when they need them.
> - Perhaps even take another look at the possibility of reducing the dependencies among the core apps and splitting them (I'd gladly welcome 100 new committers to the humanres app because I have no interest in it).  
> - Turn the payment and shipping gateway implementations into drop in components along with any other pieces of code that are suitable for extraction
> - Investigate ways to allow plug-in modification of apps and implement something (anything) that allows it.
>
> Right now we have a gigantic project with a gateway of ~13 active committers (23 total) who have day jobs to worry about along with reviewing (and fighting about) commits (or just giving up on this responsibility), attempting to improve the project and taking part in these (mostly pointless discussions) and then keeping the rest of the community happy.  Increasing the number of committers just increases the potential for disagreement and then stagnation so the only other option to reduce the code.
>
> Give control of features and components to people who care about them and then help users find them externally as they need them.  Don't like the direction a feature/component is taking? Fork it and compete.
>
> Regards
> Scott
>
> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>
>> I have noticed some negative trends happening to us in the last (1-2) years:
>> * a dramatic decrease of design discussions and an increase in commits
>> * committers are often working for themselves and not for the greater good of the project ("if a customer pays me to do something then it will be also good for the project")
>> * less peer reviews and mostly focused on formal aspects rather then fundamental aspects of the contributions
>> * a decrease in the minimum quality level needed to make a commit "acceptable"
>> * a proliferation of "best practices" and "rules" in an attempt to improve the quality of the commits
>> * a decay in the attitude and quality of discussions: attacks, critics and fights instead of healthy discussions to learn from others and improve design decisions
>>
>> Of course I am focusing on bad things, to the good ones (yes, there are also good ones) it is easier to adjust: however when the final result of our efforts is that a person like David doesn't feel comfortable in contributing more then I feel bad.
>> The primary goal of the PMC, and the community in general, should be that of creating the perfect environment to facilitate contributions from people like David, and limit/review/improve the contributions from other less blessed contributors: it seems like all our efforts are obtaining the exact opposite result.
>>
>> Jacopo
>>
>> On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
>>
>>>
>>> I'll respond here to Adrian's comments below, and to what Raj and others have written as well.
>>>
>>> Backwards compatibility is a huge issue, but I suppose that is as much a symptom as it is a disease in and of itself. The underlying issue is bureaucracy.
>>>
>>> If I wanted to spend all my time chatting with others and writing endlessly about when to do things and what to do, and trying to recruit others to do it... then OFBiz would be the perfect place for that. I did that for years, and I'm happy with what has been done with OFBiz, but there came a point in time where the whole bureaucratic trend became stronger than any single person's ability to push for new or different things. That point in time was at least a yeah and a half ago, and perhaps long earlier than that depending on how you look at it.
>>>
>>> Personally, I'd rather spend my time on more productive efforts, and do so in a way that avoids this same bureaucratic mess in the future (like different management style and keeping framework, data model, themes, and applications as separate projects). This way not only I, but many people are free to work on what they want to and not have to argue about every little thing they want to do, or deal with constant complaints about every little thing they actually do.
>>>
>>> Isn't separate and competing projects better than that everyone arguing and having to agree on what to do? Well, I have good news! No matter how you (the reader) answer that question, you have an option to fit your preferences.
>>>
>>> -David
>>>
>>>
>>> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>>>
>>>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>>>
>>>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>>>
>>>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>>>
>>>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>>>
>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>>>
>>>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>>>
>>>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>>>
>>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>>>
>>>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>>>
>>>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>>>
>>>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>>>
>>>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>>>
>>>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>>>
>>>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>>>
>>>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>>>
>>>> So, please say something.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>
>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>>>
>>>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>>>
>>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>
>>>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>
>>>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>>>
>>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>>>
>>>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>>>
>>>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>>>
>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>>>
>>>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>>>
>>>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>>>
>>>>> I should get back to work... there's a short list anyway...
>>>>>
>>>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>
>>>
>>
>

[David E. Jones-2]

This is an interesting point on its own. OFBiz started with a heavy ecommerce emphasis, but I think it would be interesting to move that to another project and open the way for competing ecommerce apps too...

-David


On Jan 27, 2011, at 3:47 AM, Scott Gray wrote:

> I agree that ecommerce is significantly important enough that it should be kept under project control but I don't believe for a second that the other special purpose components benefit from being in the main code base except that it increases their visibility.
>
> On 28/01/2011, at 12:34 AM, Jacques Le Roux wrote:
>
>> Another interesting idea, competing with Erwan's. I'd also prefer to keep things in ASF repo if possible...
>> We could have a distinction between components, important one (eCommerce, ...) still in ASF repo, others more peripheric, (ebay, Google, Oagis, etc.) out of it?
>>
>> Jacques
>>
>> From: "Pierre Smits" <[hidden email]>
>>> That sounds like a workable solution to me as well.
>>>
>>> But why move parts of the current code of the product (as is it is now)
>>> outside of the ASF' repo?
>>>
>>> Looking at Commons in JIRA I see several related projects. We could do this
>>> for OFBiz too. Split up in to several sub projects, have for each sub
>>> project a committed sub community of users, contributors and committers. And
>>> still having interaction between all.
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>>
>>>
>>> 2011/1/27 Jacopo Cappellato <[hidden email]>
>>>
>>>> On Jan 27, 2011, at 11:50 AM, Scott Gray wrote:
>>>>
>>>>> (With so many messages I don't have a good spot to say my short piece so
>>>> here will do)
>>>>>
>>>>> IMO our problems will only increase with the size of the code base.
>>>> Every time a new feature is committed you have an additional potential
>>>> audience that must be kept happy and our ability to please everybody
>>>> continues to decrease.  Unhappy people don't work well together so things
>>>> just keep getting worse.
>>>>>
>>>>> Solution?  Decrease the size of the code base and included features and
>>>> increase the ability for the community to share contributions outside of the
>>>> ASF's repo.  Decrease the load on the committers and let the rest of the
>>>> community put their money where their mouth is.
>>>>> Some ideas (feasible or not):
>>>>> - Pull out all of the themes except one and move each one to google code
>>>> or wherever if there is someone interested in looking after each one.
>>>>> - Then do the same for the bulk of the special purpose apps.
>>>>> - Separate the framework from the applications.
>>>>> - Remove any framework features that aren't used by the applications or
>>>> are of relatively low value and allow them to be dropped in by users when
>>>> they need them.
>>>>> - Perhaps even take another look at the possibility of reducing the
>>>> dependencies among the core apps and splitting them (I'd gladly welcome 100
>>>> new committers to the humanres app because I have no interest in it).
>>>>> - Turn the payment and shipping gateway implementations into drop in
>>>> components along with any other pieces of code that are suitable for
>>>> extraction
>>>>> - Investigate ways to allow plug-in modification of apps and implement
>>>> something (anything) that allows it.
>>>>>
>>>>
>>>> +1 on all points; the next step in the life of the project will be the
>>>> setup of an healthy ecosystem and these are concrete steps in that
>>>> direction.
>>>>
>>>> Jacopo
>>>>
>>>>> Right now we have a gigantic project with a gateway of ~13 active
>>>> committers (23 total) who have day jobs to worry about along with reviewing
>>>> (and fighting about) commits (or just giving up on this responsibility),
>>>> attempting to improve the project and taking part in these (mostly pointless
>>>> discussions) and then keeping the rest of the community happy.  Increasing
>>>> the number of committers just increases the potential for disagreement and
>>>> then stagnation so the only other option to reduce the code.
>>>>>
>>>>> Give control of features and components to people who care about them and
>>>> then help users find them externally as they need them.  Don't like the
>>>> direction a feature/component is taking? Fork it and compete.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> I have noticed some negative trends happening to us in the last (1-2)
>>>> years:
>>>>>> * a dramatic decrease of design discussions and an increase in commits
>>>>>> * committers are often working for themselves and not for the greater
>>>> good of the project ("if a customer pays me to do something then it will be
>>>> also good for the project")
>>>>>> * less peer reviews and mostly focused on formal aspects rather then
>>>> fundamental aspects of the contributions
>>>>>> * a decrease in the minimum quality level needed to make a commit
>>>> "acceptable"
>>>>>> * a proliferation of "best practices" and "rules" in an attempt to
>>>> improve the quality of the commits
>>>>>> * a decay in the attitude and quality of discussions: attacks, critics
>>>> and fights instead of healthy discussions to learn from others and improve
>>>> design decisions
>>>>>>
>>>>>> Of course I am focusing on bad things, to the good ones (yes, there are
>>>> also good ones) it is easier to adjust: however when the final result of our
>>>> efforts is that a person like David doesn't feel comfortable in contributing
>>>> more then I feel bad.
>>>>>> The primary goal of the PMC, and the community in general, should be
>>>> that of creating the perfect environment to facilitate contributions from
>>>> people like David, and limit/review/improve the contributions from other
>>>> less blessed contributors: it seems like all our efforts are obtaining the
>>>> exact opposite result.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
>>>>>>
>>>>>>>
>>>>>>> I'll respond here to Adrian's comments below, and to what Raj and
>>>> others have written as well.
>>>>>>>
>>>>>>> Backwards compatibility is a huge issue, but I suppose that is as much
>>>> a symptom as it is a disease in and of itself. The underlying issue is
>>>> bureaucracy.
>>>>>>>
>>>>>>> If I wanted to spend all my time chatting with others and writing
>>>> endlessly about when to do things and what to do, and trying to recruit
>>>> others to do it... then OFBiz would be the perfect place for that. I did
>>>> that for years, and I'm happy with what has been done with OFBiz, but there
>>>> came a point in time where the whole bureaucratic trend became stronger than
>>>> any single person's ability to push for new or different things. That point
>>>> in time was at least a yeah and a half ago, and perhaps long earlier than
>>>> that depending on how you look at it.
>>>>>>>
>>>>>>> Personally, I'd rather spend my time on more productive efforts, and do
>>>> so in a way that avoids this same bureaucratic mess in the future (like
>>>> different management style and keeping framework, data model, themes, and
>>>> applications as separate projects). This way not only I, but many people are
>>>> free to work on what they want to and not have to argue about every little
>>>> thing they want to do, or deal with constant complaints about every little
>>>> thing they actually do.
>>>>>>>
>>>>>>> Isn't separate and competing projects better than that everyone arguing
>>>> and having to agree on what to do? Well, I have good news! No matter how you
>>>> (the reader) answer that question, you have an option to fit your
>>>> preferences.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Many of the things listed here have been discussed, and as far as I
>>>> can tell, there is no objection to making those changes - we just need the
>>>> manpower to do it.
>>>>>>>>
>>>>>>>> Item #7 has been discussed and there hasn't been any argument against
>>>> that change - except that it touches on the backwards-compatibility issue.
>>>> And I'm going to use this opportunity to address that issue.
>>>>>>>>
>>>>>>>> Some of the changes mentioned here wouldn't affect any of my projects
>>>> - because I don't attempt to patch or modify the framework - I only build
>>>> applications on it. Other changes mentioned here would make application
>>>> development easier.
>>>>>>>>
>>>>>>>> The other day Ryan Foster described the backwards-compatibility talk
>>>> as a mantra. I view it as more of a straw man. Five days ago I posed this
>>>> question to the user mailing list:
>>>>>>>>
>>>>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project
>>>> could be improved greatly - but at the cost of some backward incompatibility
>>>> - accept the changes? If yes, how often would backwards-incompatible changes
>>>> be acceptable?"
>>>>>>>>
>>>>>>>> It is interesting to note that in a list of over 400 subscribers, no
>>>> one has replied.
>>>>>>>>
>>>>>>>> The most vocal proponents of backwards-compatibility (in the
>>>> framework) are a few players who have modified the framework locally. As a
>>>> community, do we really want to allow those few members to stifle
>>>> innovation?
>>>>>>>>
>>>>>>>> Some users claimed the updated Flat Grey visual theme wasn't
>>>> "backwards compatible."  What does that even mean? Some colors and
>>>> background images were changed - how is that backwards incompatible?
>>>>>>>>
>>>>>>>> To be fair, I have been an advocate for backwards-compatibility. But
>>>> that has been for things that break application functionality.
>>>>>>>>
>>>>>>>> At the least, there needs to be a compromise. At best, there needs to
>>>> be acceptance of the possibility of future versions that are not backwards
>>>> compatible with previous versions. That concept is not new or revolutionary
>>>> - it goes on in every software project, both open source and commercial.
>>>>>>>>
>>>>>>>> David has some great ideas, but he feels compelled to start over from
>>>> scratch to implement them. From my perspective, that's a tragedy. One of the
>>>> project's founders feels the need to start another project as a last resort
>>>> to make the project he originally started better. Does that make sense?
>>>>>>>>
>>>>>>>> I don't want to use Moqui. It's an unfinished framework controlled by
>>>> one person and it has no applications built around it. Bottom line - it's
>>>> not an option. What I want is  Moqui's innovations in OFBiz.
>>>>>>>>
>>>>>>>> I believe it's time we have a serious discussion about this. Users
>>>> have commented that there is no plan for OFBiz - what is planned for its
>>>> future? They're right. Maybe we should come up with some plans, or some kind
>>>> of path to the future.
>>>>>>>>
>>>>>>>> I propose we put all the cards on the table. Where do we go from here?
>>>> Continue on our present path and have competing projects that improve on
>>>> OFBiz technology?  Try to keep innovation in the project at the expense of
>>>> some backwards incompatibility? Maintain backwards compatibility by forking
>>>> the project to something new? Or have milestone versions that are clearly
>>>> marketed as backwards incompatible with previous milestone versions?
>>>>>>>>
>>>>>>>> Lately, it seems many of the big players in the OFBiz developer
>>>> community have been absent on the mailing list. I understand that this is a
>>>> volunteer community, but at the same time, we all have a say, and that "say"
>>>> depends on us saying *something.*
>>>>>>>>
>>>>>>>> So, please say something.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>>>>
>>>>>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>>>>>> All of that said, now that Moqui is starting to take shape I find
>>>> the OFBiz Framework to be cumbersome and inconsistent in many ways (things
>>>> that are hard to fix, but that are not surprising given the pioneering
>>>> history of the OFBiz Framework). Those funny quirky things are likely a
>>>> turn-off to prospective developers and I'm hoping to remove that impediment
>>>> to adopting the approach.
>>>>>>>>>> David - you keep saying this..Please provide some examples of
>>>> "cumbersome and inconsistent" within the framework. And why not try and fix
>>>> these? Instead of reinventing the wheel. What "funny quirky" things have
>>>> turned of prospective developers? Do you have an specific examples?
>>>>>>>>> Yes, I have mentioned these many times especially in the last 2-3
>>>> years. Some of them I have tried to fix in OFBiz itself and ran into rather
>>>> large problems. These are not easy changes to make in a large and mature
>>>> project like OFBiz, and after trying a few times I decided that a new
>>>> framework was the only way forward (another thing I've written before and
>>>> made very clear).
>>>>>>>>>
>>>>>>>>> These are the things that led to many aspects of the design of Moqui,
>>>> and the best summary of them is the document I wrote about the differences
>>>> between the Moqui and OFBiz frameworks:
>>>>>>>>>
>>>>>>>>>
>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>>>>
>>>>>>>>> To sum up here are some of the major inconsistencies and annoyances
>>>> in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>>>>>
>>>>>>>>> 1. XML actions are different in each widget and in the
>>>> simple-methods; they share some underlying code but there are so many
>>>> differences
>>>>>>>>>
>>>>>>>>> 2. scriptlets and expressions are a messy combination of BeanShell,
>>>> UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax
>>>> and capabilities are SO much better than the others so I find myself almost
>>>> always using ${groovy:...} instead of the default, and in annoying places
>>>> like the form.field.@use-when attribute since it is always BeanShell I
>>>> just use a set action to prepare a boolean and then check it in the use-when
>>>> (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML
>>>> attributes)
>>>>>>>>>
>>>>>>>>> 3. the controller.xml file gets HUGE for larger applications, and if
>>>> split it becomes harder to find requests and views; *Screen.xml files also
>>>> tend to get HUGE with large numbers of screens in them; both are not
>>>> organized in the same way as the application, also generally making things
>>>> harder to find; views/screens and requests don't define incoming parameters
>>>> so when doing request-redirect you have to specify the parameters to use in
>>>> a larger number of places
>>>>>>>>>
>>>>>>>>> 4. another on the topic of why so many files: service groups and
>>>> simple-methods are just XML, why not include them inline in the service
>>>> definition (especially for smaller services), and encourage fewer services
>>>> per file
>>>>>>>>>
>>>>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>>>> screens, forms, services, entities and so on that are not used are loaded
>>>> anyway; also many artifacts are difficult to reload by cache clearing and so
>>>> that has limited support in OFBiz; this slows things down reloading lots of
>>>> stuff in development, and results in more resources used than needed in
>>>> production
>>>>>>>>>
>>>>>>>>> 6. the deployment model of OFBiz is limited and the use of static
>>>> fields for initialization makes it difficult to deploy in other ways; there
>>>> are few init/destroy methods and object instances that would make more
>>>> deployment models easier and more flexible; also because of this it is
>>>> difficult to get data from other parts of the framework (for example the
>>>> audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to
>>>> pass userLoginId and visitId down since there is no other good way of doing
>>>> it); in other words, the tools don't share a context
>>>>>>>>>
>>>>>>>>> 7. no API for apps; the framework is made up of an enormous number of
>>>> classes that follow a bunch of different "patterns" (in quotes because the
>>>> use of the term is generous) because of various people "cleaning" things up
>>>> over time (also in quotes because the use of the term is generous), and
>>>> there is no distinction between the API that apps are intended to use and
>>>> the internal implementation of that API; this has the nasty side effect of
>>>> making it difficult to find the object and method you want, AND it makes
>>>> backward compatibility problems REALLY nasty because it gets people
>>>> believing that EVERY SINGLE object needs to ALWAYS be backward compatible...
>>>> and that results in more and more piles of trash code lying around over
>>>> time, and all of that code and differing patterns makes framework changes
>>>> error-prone and unnecessarily difficult (and this is true for some of the
>>>> app code in OFBiz too)
>>>>>>>>>
>>>>>>>>> I should get back to work... there's a short list anyway...
>>>>>>>>>
>>>>>>>>> The trick is how to solve these without abandoning backward
>>>> compatibility, and requiring a refactor of much of the framework and then
>>>> based on that the updating of massive numbers of application artifacts...
>>>> and that is just the stuff in OFBiz itself... not including everything that
>>>> everyone else has written outside the project that they may want to update.
>>>> And, ALL of that would have to be retested. Plus, it would take so long to
>>>> get all of this done in a branch with huge numbers of changes while others
>>>> are making incremental changes in the trunk making it nearly impossible to
>>>> merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>

[David E. Jones-2]

I agree with you Adrian, any major rewrites or changes are probably best done in a way to not affect the active trunk, especially when it is has been a while since a release branch and we are close to the 2011 one (we could really do it any time I support).

But, there is no reason to rush it either. If people want to work on major changes they can work on them in feature branches. Of course, some changes (like splitting out pieces of the project) are probably best done in a central place and the trunk might be best for that (after a release branch).

-David


On Jan 27, 2011, at 6:10 AM, Adrian Crum wrote:

> Thanks - I understand now. I apologize if I over-asserted myself.
>
> I wasn't trying to be a bureaucrat. My suggestion wasn't push-back - it was a suggestion based on the current level of activity in the community. It seems everyone is really busy right now, so in my mind starting a major rewrite could be held off until after the 11.x branch is created. If people are available now to get started, then that's great - let's get started.
>
> -Adrian
>
> On 1/26/2011 11:56 PM, David E Jones wrote:
>> No, the discussion is not, but your response here is "inherently bureaucratic".
>>
>> You wrote: "Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas."
>>
>> That's some serious push-back... MAYBE after the 11.x branch we can DISCUSS these ideas?
>>
>> Hints at bureaucracy are still bureaucracy.
>>
>> To take this to its logical conclusion: "Following the 11.x branch, which is a date not yet decided, the Committee will consider the discussion of your ideas. Should the Committee decide that discussion of said ideas is not in the best interest of the Project, the Committee will not discuss your ideas. The Committee does not consider the discussion of any idea from any source to be a commitment to act on said idea. The Committee hereby reserves the right to complain and push back and if necessary commit-war against any idea deemed improper or not in the best interest of the Project. The Committee further hereby disclaims any official status regarding these statements."
>>
>> This is a great definition of the term from Wikipedia: "organization characterized by hierarchy, fixed rules, impersonal relationships, rigid adherence to procedures, and a highly specialized division of labor."
>>
>> Is that a clear enough explanation of the community patterns I find less than desirable?
>>
>> -David
>>
>>
>> On Jan 26, 2011, at 10:56 PM, Adrian Crum wrote:
>>
>>> I'm not sure what you mean by that. From my perspective, we're having a discussion. Is discussion inherently bureaucratic?
>>>
>>> -Adrian
>>>
>>> On 1/26/2011 10:48 PM, David E Jones wrote:
>>>> Adrian,
>>>>
>>>> Thanks for writing this. It is an excellent example of the paradigm of bureaucracy in action.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jan 26, 2011, at 6:21 AM, Adrian Crum wrote:
>>>>
>>>>> Jacopo,
>>>>>
>>>>> Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 1/26/2011 2:11 AM, Jacopo Cappellato wrote:
>>>>>> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>>>>>>
>>>>>> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk
>>>>>>
>>>>>> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
>>>>>> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
>>>>>> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
>>>>>> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
>>>>>> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
>>>>>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
>>>>>> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)
>>>>>>
>>>>>> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>>>>>>
>>>>>>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>>>>>>
>>>>>>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>>>>>>
>>>>>>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>>>>>>
>>>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>>>>>>
>>>>>>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>>>>>>
>>>>>>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>>>>>>
>>>>>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>>>>>>
>>>>>>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>>>>>>
>>>>>>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>>>>>>
>>>>>>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>>>>>>
>>>>>>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>>>>>>
>>>>>>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>>>>>>
>>>>>>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>>>>>>
>>>>>>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>>>>>>
>>>>>>> So, please say something.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>>>
>>>>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>>>>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>>>>>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>>>>>>
>>>>>>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>>>>>>
>>>>>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>>>
>>>>>>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>>>>
>>>>>>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>>>>>>
>>>>>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>>>>>>
>>>>>>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>>>>>>
>>>>>>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>>>>>>
>>>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>>>>>>
>>>>>>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>>>>>>
>>>>>>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>>>>>>
>>>>>>>> I should get back to work... there's a short list anyway...
>>>>>>>>
>>>>>>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>

[David E. Jones-2]

Sorry Adrian, you're speaking for me, not based on anything I've written, and you couldn't be more wrong.

The point is not to be able to make innovative changes without discussion and planning, the point is to be able to setup the project structure to facilitate innovative changes and insulate users of the project from the side effects of those changes. With the way OFBiz is structured now (both the software and the community) that is REALLY hard to do. What I am pursuing now should make that a lot easier because of a totally different structure and ecosystem. If OFBiz moves in that direction as well, that's great.

Just in case it wasn't clear, the backwards part is that you think I'm trying to get away from user feedback and discussion. That couldn't be further from the truth. I'm trying to create an environment that places the concerns of users of the software first, including users who are developers who want to build something with it or on it.

About the consensus idea... are you implying that consensus is ever reached in OFBiz? Perhaps lazy consensus where no one is willing to get into a commit war or invest a lot in correcting someone else's work, but a consensus? Almost never.

And, BTW, stop speaking for me. You're generally hostile when doing so and trying to make me look bad. I've asked you this before as you've done it many times. It's really childish behavior, so stop it.

I haven't been pulling many punches lately, and it seems like it may be opening the way for discussion to happen that have been needed for a LONG time. I might as throw out another controversial opinion: the current PMC and committer groups need to be cut back a LOT. Some are not active and won't mind leaving, others are somewhat active and/or like their place in the project and wouldn't want to go. We all probably have out opinions about who we'd like to see leave. Guess what one of my opinions is?

-David


On Jan 27, 2011, at 8:22 AM, [hidden email] wrote:

> One thing that is important to remember is that there is a difference between real obstacles to innovation and imagined ones.
>
> David expressed frustration with the inability to innovate due to push back from a few people who insist on backward compatibility. That is a real obstacle. I am hopeful my appeal to compromise will help us get past that one.
>
> He is also nostalgic about the "good old days" when a handful of committers were free to make any changes they wanted with little or no discussion, or any consideration of the impact those changes would have on the user base. He sees discussion, planning, and finding a consensus as an obstacle to innovation. That obstacle is imagined.
>
> Like I said in a previous reply, there is nothing prohibiting David from innovating in OFBiz - his ideas have been discussed before and we all seemed to agree that they would be good things to do.
>
> David's decision to give up on participating in this community has nothing to do with a failure on the PMCs part.
>
> -Adrian
>
> Quoting Jacopo Cappellato <[hidden email]>:
>> The primary goal of the PMC, and the community in general, should be that of creating the perfect environment to facilitate contributions from people like David, and limit/review/improve the contributions from other less blessed contributors: it seems like all our efforts are obtaining the exact opposite result.
>
>

[BJ Freeman]

looking at the data model book, I don't see how to do that at the data
level.
then you have ones perception of what should go where.
good example is Agreements.
I believe it should be in party but it is currently in Accounting.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Sam Hamilton sent the following on 1/27/2011 5:14 AM:

> I think that we should separate everything so nothing depends on each other and then provide release bundles so that new users to the system are presented with a package that includes the everything and the kitchen sink but also instructions on how to turn it off if they don't want it, while everyone else can pick and choose what they want. Like warehouse only application or POS only application - suppose those could also be released too???
>
> Sam
>
>
> On 27 Jan 2011, at 20:23, Pierre Smits wrote:
>
>> Crudely put, but nonetheless true.
>>
>> And all can have their place in the OFBiz ecosystem. Even HumanRes could be
>> considered a SpecialApp. Which of the current set of core apps should stay
>> in? And which not? Your opinions please.
>>
>> Regards,
>>
>> Pierre
>>
>> 2011/1/27 Scott Gray<[hidden email]>
>>
>>> If they have a user base then what does it matter?  If people care then
>>> they'll look after them and if not then they'll die, either way it's one
>>> less thing to worry about.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 28/01/2011, at 1:03 AM, Jacques Le Roux wrote:
>>>
>>>> Project Manager, POS? Even maybe My Portal and AssetMaint?
>>>>
>>>> Jacques
>>>>
>>>> Scott Gray wrote:
>>>>> I agree that ecommerce is significantly important enough that it should
>>> be kept under project control but I don't believe for a
>>>>> second that the other special purpose components benefit from being in
>>> the main code base except that it increases their
>>>>> visibility.  On 28/01/2011, at 12:34 AM, Jacques Le Roux wrote:
>>>>>> Another interesting idea, competing with Erwan's. I'd also prefer to
>>> keep things in ASF repo if possible...
>>>>>> We could have a distinction between components, important one
>>> (eCommerce, ...) still in ASF repo, others more peripheric, (ebay,
>>>>>> Google, Oagis, etc.) out of it? Jacques
>>>>>> From: "Pierre Smits"<[hidden email]>
>>>>>>> That sounds like a workable solution to me as well.
>>>>>>> But why move parts of the current code of the product (as is it is
>>> now)
>>>>>>> outside of the ASF' repo?
>>>>>>> Looking at Commons in JIRA I see several related projects. We could do
>>> this
>>>>>>> for OFBiz too. Split up in to several sub projects, have for each sub
>>>>>>> project a committed sub community of users, contributors and
>>> committers. And
>>>>>>> still having interaction between all.
>>>>>>> Regards,
>>>>>>> Pierre
>>>>>>> 2011/1/27 Jacopo Cappellato<[hidden email]>
>>>>>>>> On Jan 27, 2011, at 11:50 AM, Scott Gray wrote:
>>>>>>>>> (With so many messages I don't have a good spot to say my short
>>> piece so
>>>>>>>> here will do)
>>>>>>>>> IMO our problems will only increase with the size of the code base.
>>>>>>>> Every time a new feature is committed you have an additional
>>> potential
>>>>>>>> audience that must be kept happy and our ability to please everybody
>>>>>>>> continues to decrease.  Unhappy people don't work well together so
>>> things
>>>>>>>> just keep getting worse.
>>>>>>>>> Solution?  Decrease the size of the code base and included features
>>> and
>>>>>>>> increase the ability for the community to share contributions outside
>>> of the
>>>>>>>> ASF's repo.  Decrease the load on the committers and let the rest of
>>> the
>>>>>>>> community put their money where their mouth is.
>>>>>>>>> Some ideas (feasible or not):
>>>>>>>>> - Pull out all of the themes except one and move each one to google
>>> code
>>>>>>>> or wherever if there is someone interested in looking after each one.
>>>>>>>>> - Then do the same for the bulk of the special purpose apps.
>>>>>>>>> - Separate the framework from the applications.
>>>>>>>>> - Remove any framework features that aren't used by the applications
>>> or
>>>>>>>> are of relatively low value and allow them to be dropped in by users
>>> when
>>>>>>>> they need them.
>>>>>>>>> - Perhaps even take another look at the possibility of reducing the
>>>>>>>> dependencies among the core apps and splitting them (I'd gladly
>>> welcome 100
>>>>>>>> new committers to the humanres app because I have no interest in it).
>>>>>>>>> - Turn the payment and shipping gateway implementations into drop in
>>>>>>>> components along with any other pieces of code that are suitable for
>>>>>>>> extraction
>>>>>>>>> - Investigate ways to allow plug-in modification of apps and
>>> implement
>>>>>>>> something (anything) that allows it.
>>>>>>>> +1 on all points; the next step in the life of the project will be
>>> the
>>>>>>>> setup of an healthy ecosystem and these are concrete steps in that
>>>>>>>> direction.
>>>>>>>> Jacopo
>>>>>>>>> Right now we have a gigantic project with a gateway of ~13 active
>>>>>>>> committers (23 total) who have day jobs to worry about along with
>>> reviewing
>>>>>>>> (and fighting about) commits (or just giving up on this
>>> responsibility),
>>>>>>>> attempting to improve the project and taking part in these (mostly
>>> pointless
>>>>>>>> discussions) and then keeping the rest of the community happy.
>>> Increasing
>>>>>>>> the number of committers just increases the potential for
>>> disagreement and
>>>>>>>> then stagnation so the only other option to reduce the code.
>>>>>>>>> Give control of features and components to people who care about
>>> them and
>>>>>>>> then help users find them externally as they need them.  Don't like
>>> the
>>>>>>>> direction a feature/component is taking? Fork it and compete.
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>>>>>>>>>> I have noticed some negative trends happening to us in the last
>>> (1-2)
>>>>>>>> years:
>>>>>>>>>> * a dramatic decrease of design discussions and an increase in
>>> commits
>>>>>>>>>> * committers are often working for themselves and not for the
>>> greater
>>>>>>>> good of the project ("if a customer pays me to do something then it
>>> will be
>>>>>>>> also good for the project")
>>>>>>>>>> * less peer reviews and mostly focused on formal aspects rather
>>> then
>>>>>>>> fundamental aspects of the contributions
>>>>>>>>>> * a decrease in the minimum quality level needed to make a commit
>>>>>>>> "acceptable"
>>>>>>>>>> * a proliferation of "best practices" and "rules" in an attempt to
>>>>>>>> improve the quality of the commits
>>>>>>>>>> * a decay in the attitude and quality of discussions: attacks,
>>> critics
>>>>>>>> and fights instead of healthy discussions to learn from others and
>>> improve
>>>>>>>> design decisions
>>>>>>>>>> Of course I am focusing on bad things, to the good ones (yes, there
>>> are
>>>>>>>> also good ones) it is easier to adjust: however when the final result
>>> of our
>>>>>>>> efforts is that a person like David doesn't feel comfortable in
>>> contributing
>>>>>>>> more then I feel bad.
>>>>>>>>>> The primary goal of the PMC, and the community in general, should
>>> be
>>>>>>>> that of creating the perfect environment to facilitate contributions
>>> from
>>>>>>>> people like David, and limit/review/improve the contributions from
>>> other
>>>>>>>> less blessed contributors: it seems like all our efforts are
>>> obtaining the
>>>>>>>> exact opposite result.
>>>>>>>>>> Jacopo
>>>>>>>>>> On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
>>>>>>>>>>> I'll respond here to Adrian's comments below, and to what Raj and
>>>>>>>> others have written as well.
>>>>>>>>>>> Backwards compatibility is a huge issue, but I suppose that is as
>>> much
>>>>>>>> a symptom as it is a disease in and of itself. The underlying issue
>>> is
>>>>>>>> bureaucracy.
>>>>>>>>>>> If I wanted to spend all my time chatting with others and writing
>>>>>>>> endlessly about when to do things and what to do, and trying to
>>> recruit
>>>>>>>> others to do it... then OFBiz would be the perfect place for that. I
>>> did
>>>>>>>> that for years, and I'm happy with what has been done with OFBiz, but
>>> there
>>>>>>>> came a point in time where the whole bureaucratic trend became
>>> stronger than
>>>>>>>> any single person's ability to push for new or different things. That
>>> point
>>>>>>>> in time was at least a yeah and a half ago, and perhaps long earlier
>>> than
>>>>>>>> that depending on how you look at it.
>>>>>>>>>>> Personally, I'd rather spend my time on more productive efforts,
>>> and do
>>>>>>>> so in a way that avoids this same bureaucratic mess in the future
>>> (like
>>>>>>>> different management style and keeping framework, data model, themes,
>>> and
>>>>>>>> applications as separate projects). This way not only I, but many
>>> people are
>>>>>>>> free to work on what they want to and not have to argue about every
>>> little
>>>>>>>> thing they want to do, or deal with constant complaints about every
>>> little
>>>>>>>> thing they actually do.
>>>>>>>>>>> Isn't separate and competing projects better than that everyone
>>> arguing
>>>>>>>> and having to agree on what to do? Well, I have good news! No matter
>>> how you
>>>>>>>> (the reader) answer that question, you have an option to fit your
>>>>>>>> preferences.
>>>>>>>>>>> -David
>>>>>>>>>>> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>>>>>>>>>>>> Many of the things listed here have been discussed, and as far as
>>> I
>>>>>>>> can tell, there is no objection to making those changes - we just
>>> need the
>>>>>>>> manpower to do it.
>>>>>>>>>>>> Item #7 has been discussed and there hasn't been any argument
>>> against
>>>>>>>> that change - except that it touches on the backwards-compatibility
>>> issue.
>>>>>>>> And I'm going to use this opportunity to address that issue.
>>>>>>>>>>>> Some of the changes mentioned here wouldn't affect any of my
>>> projects
>>>>>>>> - because I don't attempt to patch or modify the framework - I only
>>> build
>>>>>>>> applications on it. Other changes mentioned here would make
>>> application
>>>>>>>> development easier.
>>>>>>>>>>>> The other day Ryan Foster described the backwards-compatibility
>>> talk
>>>>>>>> as a mantra. I view it as more of a straw man. Five days ago I posed
>>> this
>>>>>>>> question to the user mailing list:
>>>>>>>>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz
>>> project
>>>>>>>> could be improved greatly - but at the cost of some backward
>>> incompatibility
>>>>>>>> - accept the changes? If yes, how often would backwards-incompatible
>>> changes
>>>>>>>> be acceptable?"
>>>>>>>>>>>> It is interesting to note that in a list of over 400 subscribers,
>>> no
>>>>>>>> one has replied.
>>>>>>>>>>>> The most vocal proponents of backwards-compatibility (in the
>>>>>>>> framework) are a few players who have modified the framework locally.
>>> As a
>>>>>>>> community, do we really want to allow those few members to stifle
>>>>>>>> innovation?
>>>>>>>>>>>> Some users claimed the updated Flat Grey visual theme wasn't
>>>>>>>> "backwards compatible."  What does that even mean? Some colors and
>>>>>>>> background images were changed - how is that backwards incompatible?
>>>>>>>>>>>> To be fair, I have been an advocate for backwards-compatibility.
>>> But
>>>>>>>> that has been for things that break application functionality.
>>>>>>>>>>>> At the least, there needs to be a compromise. At best, there
>>> needs to
>>>>>>>> be acceptance of the possibility of future versions that are not
>>> backwards
>>>>>>>> compatible with previous versions. That concept is not new or
>>> revolutionary
>>>>>>>> - it goes on in every software project, both open source and
>>> commercial.
>>>>>>>>>>>> David has some great ideas, but he feels compelled to start over
>>> from
>>>>>>>> scratch to implement them. From my perspective, that's a tragedy. One
>>> of the
>>>>>>>> project's founders feels the need to start another project as a last
>>> resort
>>>>>>>> to make the project he originally started better. Does that make
>>> sense?
>>>>>>>>>>>> I don't want to use Moqui. It's an unfinished framework
>>> controlled by
>>>>>>>> one person and it has no applications built around it. Bottom line -
>>> it's
>>>>>>>> not an option. What I want is  Moqui's innovations in OFBiz.
>>>>>>>>>>>> I believe it's time we have a serious discussion about this.
>>> Users
>>>>>>>> have commented that there is no plan for OFBiz - what is planned for
>>> its
>>>>>>>> future? They're right. Maybe we should come up with some plans, or
>>> some kind
>>>>>>>> of path to the future.
>>>>>>>>>>>> I propose we put all the cards on the table. Where do we go from
>>> here?
>>>>>>>> Continue on our present path and have competing projects that improve
>>> on
>>>>>>>> OFBiz technology?  Try to keep innovation in the project at the
>>> expense of
>>>>>>>> some backwards incompatibility? Maintain backwards compatibility by
>>> forking
>>>>>>>> the project to something new? Or have milestone versions that are
>>> clearly
>>>>>>>> marketed as backwards incompatible with previous milestone versions?
>>>>>>>>>>>> Lately, it seems many of the big players in the OFBiz developer
>>>>>>>> community have been absent on the mailing list. I understand that
>>> this is a
>>>>>>>> volunteer community, but at the same time, we all have a say, and
>>> that "say"
>>>>>>>> depends on us saying *something.*
>>>>>>>>>>>> So, please say something.
>>>>>>>>>>>> -Adrian
>>>>>>>>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>>>>>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>>>>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>>>>>>>>>> All of that said, now that Moqui is starting to take shape I
>>> find
>>>>>>>> the OFBiz Framework to be cumbersome and inconsistent in many ways
>>> (things
>>>>>>>> that are hard to fix, but that are not surprising given the
>>> pioneering
>>>>>>>> history of the OFBiz Framework). Those funny quirky things are likely
>>> a
>>>>>>>> turn-off to prospective developers and I'm hoping to remove that
>>> impediment
>>>>>>>> to adopting the approach.
>>>>>>>>>>>>>> David - you keep saying this..Please provide some examples of
>>>>>>>> "cumbersome and inconsistent" within the framework. And why not try
>>> and fix
>>>>>>>> these? Instead of reinventing the wheel. What "funny quirky" things
>>> have
>>>>>>>> turned of prospective developers? Do you have an specific examples?
>>>>>>>>>>>>> Yes, I have mentioned these many times especially in the last
>>> 2-3
>>>>>>>> years. Some of them I have tried to fix in OFBiz itself and ran into
>>> rather
>>>>>>>> large problems. These are not easy changes to make in a large and
>>> mature
>>>>>>>> project like OFBiz, and after trying a few times I decided that a new
>>>>>>>> framework was the only way forward (another thing I've written before
>>> and
>>>>>>>> made very clear).
>>>>>>>>>>>>> These are the things that led to many aspects of the design of
>>> Moqui,
>>>>>>>> and the best summary of them is the document I wrote about the
>>> differences
>>>>>>>> between the Moqui and OFBiz frameworks:
>>>>>>>>
>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>>>>>>>> To sum up here are some of the major inconsistencies and
>>> annoyances
>>>>>>>> in the current OFBiz framework that bug me frequently while I'm
>>> developing:
>>>>>>>>>>>>> 1. XML actions are different in each widget and in the
>>>>>>>> simple-methods; they share some underlying code but there are so many
>>>>>>>> differences
>>>>>>>>>>>>> 2. scriptlets and expressions are a messy combination of
>>> BeanShell,
>>>>>>>> UEL, and Groovy and keeping track of which is a pain, plus the Groovy
>>> syntax
>>>>>>>> and capabilities are SO much better than the others so I find myself
>>> almost
>>>>>>>> always using ${groovy:...} instead of the default, and in annoying
>>> places
>>>>>>>> like the form.field.@use-when attribute since it is always BeanShell
>>> I
>>>>>>>> just use a set action to prepare a boolean and then check it in the
>>> use-when
>>>>>>>> (BeanShell is HORRIBLE compared to groovy, especially when squeezed
>>> into XML
>>>>>>>> attributes)
>>>>>>>>>>>>> 3. the controller.xml file gets HUGE for larger applications,
>>> and if
>>>>>>>> split it becomes harder to find requests and views; *Screen.xml files
>>> also
>>>>>>>> tend to get HUGE with large numbers of screens in them; both are not
>>>>>>>> organized in the same way as the application, also generally making
>>> things
>>>>>>>> harder to find; views/screens and requests don't define incoming
>>> parameters
>>>>>>>> so when doing request-redirect you have to specify the parameters to
>>> use in
>>>>>>>> a larger number of places
>>>>>>>>>>>>> 4. another on the topic of why so many files: service groups and
>>>>>>>> simple-methods are just XML, why not include them inline in the
>>> service
>>>>>>>> definition (especially for smaller services), and encourage fewer
>>> services
>>>>>>>> per file
>>>>>>>>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>>>>>>>> screens, forms, services, entities and so on that are not used are
>>> loaded
>>>>>>>> anyway; also many artifacts are difficult to reload by cache clearing
>>> and so
>>>>>>>> that has limited support in OFBiz; this slows things down reloading
>>> lots of
>>>>>>>> stuff in development, and results in more resources used than needed
>>> in
>>>>>>>> production
>>>>>>>>>>>>> 6. the deployment model of OFBiz is limited and the use of
>>> static
>>>>>>>> fields for initialization makes it difficult to deploy in other ways;
>>> there
>>>>>>>> are few init/destroy methods and object instances that would make
>>> more
>>>>>>>> deployment models easier and more flexible; also because of this it
>>> is
>>>>>>>> difficult to get data from other parts of the framework (for example
>>> the
>>>>>>>> audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables
>>> to
>>>>>>>> pass userLoginId and visitId down since there is no other good way of
>>> doing
>>>>>>>> it); in other words, the tools don't share a context
>>>>>>>>>>>>> 7. no API for apps; the framework is made up of an enormous
>>> number of
>>>>>>>> classes that follow a bunch of different "patterns" (in quotes
>>> because the
>>>>>>>> use of the term is generous) because of various people "cleaning"
>>> things up
>>>>>>>> over time (also in quotes because the use of the term is generous),
>>> and
>>>>>>>> there is no distinction between the API that apps are intended to use
>>> and
>>>>>>>> the internal implementation of that API; this has the nasty side
>>> effect of
>>>>>>>> making it difficult to find the object and method you want, AND it
>>> makes
>>>>>>>> backward compatibility problems REALLY nasty because it gets people
>>>>>>>> believing that EVERY SINGLE object needs to ALWAYS be backward
>>> compatible...
>>>>>>>> and that results in more and more piles of trash code lying around
>>> over
>>>>>>>> time, and all of that code and differing patterns makes framework
>>> changes
>>>>>>>> error-prone and unnecessarily difficult (and this is true for some of
>>> the
>>>>>>>> app code in OFBiz too)
>>>>>>>>>>>>> I should get back to work... there's a short list anyway...
>>>>>>>>>>>>> The trick is how to solve these without abandoning backward
>>>>>>>> compatibility, and requiring a refactor of much of the framework and
>>> then
>>>>>>>> based on that the updating of massive numbers of application
>>> artifacts...
>>>>>>>> and that is just the stuff in OFBiz itself... not including
>>> everything that
>>>>>>>> everyone else has written outside the project that they may want to
>>> update.
>>>>>>>> And, ALL of that would have to be retested. Plus, it would take so
>>> long to
>>>>>>>> get all of this done in a branch with huge numbers of changes while
>>> others
>>>>>>>> are making incremental changes in the trunk making it nearly
>>> impossible to
>>>>>>>> merge the branch into the trunk, so it would basically be a fork
>>> anyway...
>>>>>>>>>>>>> -David
>>>>
>>>> Project Manager, POS? Even maybe My Portal?
>>>>
>>>> Jacquees
>>>
>>>
>
>

[David E. Jones-2]

One more thing: I did not "give up on participating in this community". I never said I was, nor do I think my behavior related to this community has demonstrated any such things.

I just started another project.

-David


On Jan 27, 2011, at 8:22 AM, [hidden email] wrote:

> One thing that is important to remember is that there is a difference between real obstacles to innovation and imagined ones.
>
> David expressed frustration with the inability to innovate due to push back from a few people who insist on backward compatibility. That is a real obstacle. I am hopeful my appeal to compromise will help us get past that one.
>
> He is also nostalgic about the "good old days" when a handful of committers were free to make any changes they wanted with little or no discussion, or any consideration of the impact those changes would have on the user base. He sees discussion, planning, and finding a consensus as an obstacle to innovation. That obstacle is imagined.
>
> Like I said in a previous reply, there is nothing prohibiting David from innovating in OFBiz - his ideas have been discussed before and we all seemed to agree that they would be good things to do.
>
> David's decision to give up on participating in this community has nothing to do with a failure on the PMCs part.
>
> -Adrian
>
> Quoting Jacopo Cappellato <[hidden email]>:
>> The primary goal of the PMC, and the community in general, should be that of creating the perfect environment to facilitate contributions from people like David, and limit/review/improve the contributions from other less blessed contributors: it seems like all our efforts are obtaining the exact opposite result.
>
>

[Adrian Crum-3]

I wasn't speaking for you - I was commenting on your recent replies  
and Jacopo's suggestion that the PMC has done something wrong to cause  
them. As a member of the community and a participant in this  
discussion, I reserve the right to do so.

We already know you would like to change the PMC and the roster of  
committers - you said as much before. Personally, I don't want to see  
anyone leave - we need as much help as possible. I enjoy working with  
our community and I don't believe reducing its size will improve  
anything. Scott's idea of reducing code would likely have better  
success.

-Adrian


Quoting David E Jones <[hidden email]>:

> And, BTW, stop speaking for me. You're generally hostile when doing  
> so and trying to make me look bad. I've asked you this before as  
> you've done it many times. It's really childish behavior, so stop it.
>
> I haven't been pulling many punches lately, and it seems like it may  
> be opening the way for discussion to happen that have been needed  
> for a LONG time. I might as throw out another controversial opinion:  
> the current PMC and committer groups need to be cut back a LOT. Some  
> are not active and won't mind leaving, others are somewhat active  
> and/or like their place in the project and wouldn't want to go. We  
> all probably have out opinions about who we'd like to see leave.  
> Guess what one of my opinions is?
>
> -David
>
>
> On Jan 27, 2011, at 8:22 AM, [hidden email] wrote:
>
>> One thing that is important to remember is that there is a  
>> difference between real obstacles to innovation and imagined ones.
>>
>> David expressed frustration with the inability to innovate due to  
>> push back from a few people who insist on backward compatibility.  
>> That is a real obstacle. I am hopeful my appeal to compromise will  
>> help us get past that one.
>>
>> He is also nostalgic about the "good old days" when a handful of  
>> committers were free to make any changes they wanted with little or  
>> no discussion, or any consideration of the impact those changes  
>> would have on the user base. He sees discussion, planning, and  
>> finding a consensus as an obstacle to innovation. That obstacle is  
>> imagined.
>>
>> Like I said in a previous reply, there is nothing prohibiting David  
>> from innovating in OFBiz - his ideas have been discussed before and  
>> we all seemed to agree that they would be good things to do.
>>
>> David's decision to give up on participating in this community has  
>> nothing to do with a failure on the PMCs part.
>>
>> -Adrian
>>
>> Quoting Jacopo Cappellato <[hidden email]>:
>>> The primary goal of the PMC, and the community in general, should  
>>> be that of creating the perfect environment to facilitate  
>>> contributions from people like David, and limit/review/improve the  
>>> contributions from other less blessed contributors: it seems like  
>>> all our efforts are obtaining the exact opposite result.
>>
>>
>
>

[David E. Jones-2]

The biggest issue with interdependency in the "base applications" (ie those in the ofbiz/applications directory) is that of the data model. The nature of business data is that it is pretty much all related other other areas of the business data. This is based on the fact that not much happens in a business in isolation. Some higher level activities can use only lower level data elements without reverse references, but all of accounting, logistics, operations, customer service, etc, etc are pretty interdependent and need to know about each other.

Of course, that doesn't mean that all of the services and user interfaces need to know about each other. Those can be designed to be more isolated and target a specific set of business activities.

In other words, IMO, the key to this is to have a "data model" component (or separate project) that is separate from the framework and separate from the applications, and that the applications can be built on.

Applications could certainly extend the data model for areas specific to their needs and that don't make sense to make more general (or that are in the process of becoming part of the "official" or shared data model).

-David


On Jan 27, 2011, at 5:14 AM, Sam Hamilton wrote:

> I think that we should separate everything so nothing depends on each other and then provide release bundles so that new users to the system are presented with a package that includes the everything and the kitchen sink but also instructions on how to turn it off if they don't want it, while everyone else can pick and choose what they want. Like warehouse only application or POS only application - suppose those could also be released too???
>
> Sam
>
>
> On 27 Jan 2011, at 20:23, Pierre Smits wrote:
>
>> Crudely put, but nonetheless true.
>>
>> And all can have their place in the OFBiz ecosystem. Even HumanRes could be
>> considered a SpecialApp. Which of the current set of core apps should stay
>> in? And which not? Your opinions please.
>>
>> Regards,
>>
>> Pierre
>>
>> 2011/1/27 Scott Gray <[hidden email]>
>>
>>> If they have a user base then what does it matter?  If people care then
>>> they'll look after them and if not then they'll die, either way it's one
>>> less thing to worry about.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 28/01/2011, at 1:03 AM, Jacques Le Roux wrote:
>>>
>>>> Project Manager, POS? Even maybe My Portal and AssetMaint?
>>>>
>>>> Jacques
>>>>
>>>> Scott Gray wrote:
>>>>> I agree that ecommerce is significantly important enough that it should
>>> be kept under project control but I don't believe for a
>>>>> second that the other special purpose components benefit from being in
>>> the main code base except that it increases their
>>>>> visibility.  On 28/01/2011, at 12:34 AM, Jacques Le Roux wrote:
>>>>>> Another interesting idea, competing with Erwan's. I'd also prefer to
>>> keep things in ASF repo if possible...
>>>>>> We could have a distinction between components, important one
>>> (eCommerce, ...) still in ASF repo, others more peripheric, (ebay,
>>>>>> Google, Oagis, etc.) out of it? Jacques
>>>>>> From: "Pierre Smits" <[hidden email]>
>>>>>>> That sounds like a workable solution to me as well.
>>>>>>> But why move parts of the current code of the product (as is it is
>>> now)
>>>>>>> outside of the ASF' repo?
>>>>>>> Looking at Commons in JIRA I see several related projects. We could do
>>> this
>>>>>>> for OFBiz too. Split up in to several sub projects, have for each sub
>>>>>>> project a committed sub community of users, contributors and
>>> committers. And
>>>>>>> still having interaction between all.
>>>>>>> Regards,
>>>>>>> Pierre
>>>>>>> 2011/1/27 Jacopo Cappellato <[hidden email]>
>>>>>>>> On Jan 27, 2011, at 11:50 AM, Scott Gray wrote:
>>>>>>>>> (With so many messages I don't have a good spot to say my short
>>> piece so
>>>>>>>> here will do)
>>>>>>>>> IMO our problems will only increase with the size of the code base.
>>>>>>>> Every time a new feature is committed you have an additional
>>> potential
>>>>>>>> audience that must be kept happy and our ability to please everybody
>>>>>>>> continues to decrease.  Unhappy people don't work well together so
>>> things
>>>>>>>> just keep getting worse.
>>>>>>>>> Solution?  Decrease the size of the code base and included features
>>> and
>>>>>>>> increase the ability for the community to share contributions outside
>>> of the
>>>>>>>> ASF's repo.  Decrease the load on the committers and let the rest of
>>> the
>>>>>>>> community put their money where their mouth is.
>>>>>>>>> Some ideas (feasible or not):
>>>>>>>>> - Pull out all of the themes except one and move each one to google
>>> code
>>>>>>>> or wherever if there is someone interested in looking after each one.
>>>>>>>>> - Then do the same for the bulk of the special purpose apps.
>>>>>>>>> - Separate the framework from the applications.
>>>>>>>>> - Remove any framework features that aren't used by the applications
>>> or
>>>>>>>> are of relatively low value and allow them to be dropped in by users
>>> when
>>>>>>>> they need them.
>>>>>>>>> - Perhaps even take another look at the possibility of reducing the
>>>>>>>> dependencies among the core apps and splitting them (I'd gladly
>>> welcome 100
>>>>>>>> new committers to the humanres app because I have no interest in it).
>>>>>>>>> - Turn the payment and shipping gateway implementations into drop in
>>>>>>>> components along with any other pieces of code that are suitable for
>>>>>>>> extraction
>>>>>>>>> - Investigate ways to allow plug-in modification of apps and
>>> implement
>>>>>>>> something (anything) that allows it.
>>>>>>>> +1 on all points; the next step in the life of the project will be
>>> the
>>>>>>>> setup of an healthy ecosystem and these are concrete steps in that
>>>>>>>> direction.
>>>>>>>> Jacopo
>>>>>>>>> Right now we have a gigantic project with a gateway of ~13 active
>>>>>>>> committers (23 total) who have day jobs to worry about along with
>>> reviewing
>>>>>>>> (and fighting about) commits (or just giving up on this
>>> responsibility),
>>>>>>>> attempting to improve the project and taking part in these (mostly
>>> pointless
>>>>>>>> discussions) and then keeping the rest of the community happy.
>>> Increasing
>>>>>>>> the number of committers just increases the potential for
>>> disagreement and
>>>>>>>> then stagnation so the only other option to reduce the code.
>>>>>>>>> Give control of features and components to people who care about
>>> them and
>>>>>>>> then help users find them externally as they need them.  Don't like
>>> the
>>>>>>>> direction a feature/component is taking? Fork it and compete.
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>>>>>>>>>> I have noticed some negative trends happening to us in the last
>>> (1-2)
>>>>>>>> years:
>>>>>>>>>> * a dramatic decrease of design discussions and an increase in
>>> commits
>>>>>>>>>> * committers are often working for themselves and not for the
>>> greater
>>>>>>>> good of the project ("if a customer pays me to do something then it
>>> will be
>>>>>>>> also good for the project")
>>>>>>>>>> * less peer reviews and mostly focused on formal aspects rather
>>> then
>>>>>>>> fundamental aspects of the contributions
>>>>>>>>>> * a decrease in the minimum quality level needed to make a commit
>>>>>>>> "acceptable"
>>>>>>>>>> * a proliferation of "best practices" and "rules" in an attempt to
>>>>>>>> improve the quality of the commits
>>>>>>>>>> * a decay in the attitude and quality of discussions: attacks,
>>> critics
>>>>>>>> and fights instead of healthy discussions to learn from others and
>>> improve
>>>>>>>> design decisions
>>>>>>>>>> Of course I am focusing on bad things, to the good ones (yes, there
>>> are
>>>>>>>> also good ones) it is easier to adjust: however when the final result
>>> of our
>>>>>>>> efforts is that a person like David doesn't feel comfortable in
>>> contributing
>>>>>>>> more then I feel bad.
>>>>>>>>>> The primary goal of the PMC, and the community in general, should
>>> be
>>>>>>>> that of creating the perfect environment to facilitate contributions
>>> from
>>>>>>>> people like David, and limit/review/improve the contributions from
>>> other
>>>>>>>> less blessed contributors: it seems like all our efforts are
>>> obtaining the
>>>>>>>> exact opposite result.
>>>>>>>>>> Jacopo
>>>>>>>>>> On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
>>>>>>>>>>> I'll respond here to Adrian's comments below, and to what Raj and
>>>>>>>> others have written as well.
>>>>>>>>>>> Backwards compatibility is a huge issue, but I suppose that is as
>>> much
>>>>>>>> a symptom as it is a disease in and of itself. The underlying issue
>>> is
>>>>>>>> bureaucracy.
>>>>>>>>>>> If I wanted to spend all my time chatting with others and writing
>>>>>>>> endlessly about when to do things and what to do, and trying to
>>> recruit
>>>>>>>> others to do it... then OFBiz would be the perfect place for that. I
>>> did
>>>>>>>> that for years, and I'm happy with what has been done with OFBiz, but
>>> there
>>>>>>>> came a point in time where the whole bureaucratic trend became
>>> stronger than
>>>>>>>> any single person's ability to push for new or different things. That
>>> point
>>>>>>>> in time was at least a yeah and a half ago, and perhaps long earlier
>>> than
>>>>>>>> that depending on how you look at it.
>>>>>>>>>>> Personally, I'd rather spend my time on more productive efforts,
>>> and do
>>>>>>>> so in a way that avoids this same bureaucratic mess in the future
>>> (like
>>>>>>>> different management style and keeping framework, data model, themes,
>>> and
>>>>>>>> applications as separate projects). This way not only I, but many
>>> people are
>>>>>>>> free to work on what they want to and not have to argue about every
>>> little
>>>>>>>> thing they want to do, or deal with constant complaints about every
>>> little
>>>>>>>> thing they actually do.
>>>>>>>>>>> Isn't separate and competing projects better than that everyone
>>> arguing
>>>>>>>> and having to agree on what to do? Well, I have good news! No matter
>>> how you
>>>>>>>> (the reader) answer that question, you have an option to fit your
>>>>>>>> preferences.
>>>>>>>>>>> -David
>>>>>>>>>>> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>>>>>>>>>>>> Many of the things listed here have been discussed, and as far as
>>> I
>>>>>>>> can tell, there is no objection to making those changes - we just
>>> need the
>>>>>>>> manpower to do it.
>>>>>>>>>>>> Item #7 has been discussed and there hasn't been any argument
>>> against
>>>>>>>> that change - except that it touches on the backwards-compatibility
>>> issue.
>>>>>>>> And I'm going to use this opportunity to address that issue.
>>>>>>>>>>>> Some of the changes mentioned here wouldn't affect any of my
>>> projects
>>>>>>>> - because I don't attempt to patch or modify the framework - I only
>>> build
>>>>>>>> applications on it. Other changes mentioned here would make
>>> application
>>>>>>>> development easier.
>>>>>>>>>>>> The other day Ryan Foster described the backwards-compatibility
>>> talk
>>>>>>>> as a mantra. I view it as more of a straw man. Five days ago I posed
>>> this
>>>>>>>> question to the user mailing list:
>>>>>>>>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz
>>> project
>>>>>>>> could be improved greatly - but at the cost of some backward
>>> incompatibility
>>>>>>>> - accept the changes? If yes, how often would backwards-incompatible
>>> changes
>>>>>>>> be acceptable?"
>>>>>>>>>>>> It is interesting to note that in a list of over 400 subscribers,
>>> no
>>>>>>>> one has replied.
>>>>>>>>>>>> The most vocal proponents of backwards-compatibility (in the
>>>>>>>> framework) are a few players who have modified the framework locally.
>>> As a
>>>>>>>> community, do we really want to allow those few members to stifle
>>>>>>>> innovation?
>>>>>>>>>>>> Some users claimed the updated Flat Grey visual theme wasn't
>>>>>>>> "backwards compatible."  What does that even mean? Some colors and
>>>>>>>> background images were changed - how is that backwards incompatible?
>>>>>>>>>>>> To be fair, I have been an advocate for backwards-compatibility.
>>> But
>>>>>>>> that has been for things that break application functionality.
>>>>>>>>>>>> At the least, there needs to be a compromise. At best, there
>>> needs to
>>>>>>>> be acceptance of the possibility of future versions that are not
>>> backwards
>>>>>>>> compatible with previous versions. That concept is not new or
>>> revolutionary
>>>>>>>> - it goes on in every software project, both open source and
>>> commercial.
>>>>>>>>>>>> David has some great ideas, but he feels compelled to start over
>>> from
>>>>>>>> scratch to implement them. From my perspective, that's a tragedy. One
>>> of the
>>>>>>>> project's founders feels the need to start another project as a last
>>> resort
>>>>>>>> to make the project he originally started better. Does that make
>>> sense?
>>>>>>>>>>>> I don't want to use Moqui. It's an unfinished framework
>>> controlled by
>>>>>>>> one person and it has no applications built around it. Bottom line -
>>> it's
>>>>>>>> not an option. What I want is  Moqui's innovations in OFBiz.
>>>>>>>>>>>> I believe it's time we have a serious discussion about this.
>>> Users
>>>>>>>> have commented that there is no plan for OFBiz - what is planned for
>>> its
>>>>>>>> future? They're right. Maybe we should come up with some plans, or
>>> some kind
>>>>>>>> of path to the future.
>>>>>>>>>>>> I propose we put all the cards on the table. Where do we go from
>>> here?
>>>>>>>> Continue on our present path and have competing projects that improve
>>> on
>>>>>>>> OFBiz technology?  Try to keep innovation in the project at the
>>> expense of
>>>>>>>> some backwards incompatibility? Maintain backwards compatibility by
>>> forking
>>>>>>>> the project to something new? Or have milestone versions that are
>>> clearly
>>>>>>>> marketed as backwards incompatible with previous milestone versions?
>>>>>>>>>>>> Lately, it seems many of the big players in the OFBiz developer
>>>>>>>> community have been absent on the mailing list. I understand that
>>> this is a
>>>>>>>> volunteer community, but at the same time, we all have a say, and
>>> that "say"
>>>>>>>> depends on us saying *something.*
>>>>>>>>>>>> So, please say something.
>>>>>>>>>>>> -Adrian
>>>>>>>>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>>>>>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>>>>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>>>>>>>>>> All of that said, now that Moqui is starting to take shape I
>>> find
>>>>>>>> the OFBiz Framework to be cumbersome and inconsistent in many ways
>>> (things
>>>>>>>> that are hard to fix, but that are not surprising given the
>>> pioneering
>>>>>>>> history of the OFBiz Framework). Those funny quirky things are likely
>>> a
>>>>>>>> turn-off to prospective developers and I'm hoping to remove that
>>> impediment
>>>>>>>> to adopting the approach.
>>>>>>>>>>>>>> David - you keep saying this..Please provide some examples of
>>>>>>>> "cumbersome and inconsistent" within the framework. And why not try
>>> and fix
>>>>>>>> these? Instead of reinventing the wheel. What "funny quirky" things
>>> have
>>>>>>>> turned of prospective developers? Do you have an specific examples?
>>>>>>>>>>>>> Yes, I have mentioned these many times especially in the last
>>> 2-3
>>>>>>>> years. Some of them I have tried to fix in OFBiz itself and ran into
>>> rather
>>>>>>>> large problems. These are not easy changes to make in a large and
>>> mature
>>>>>>>> project like OFBiz, and after trying a few times I decided that a new
>>>>>>>> framework was the only way forward (another thing I've written before
>>> and
>>>>>>>> made very clear).
>>>>>>>>>>>>> These are the things that led to many aspects of the design of
>>> Moqui,
>>>>>>>> and the best summary of them is the document I wrote about the
>>> differences
>>>>>>>> between the Moqui and OFBiz frameworks:
>>>>>>>>
>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>>>>>>>> To sum up here are some of the major inconsistencies and
>>> annoyances
>>>>>>>> in the current OFBiz framework that bug me frequently while I'm
>>> developing:
>>>>>>>>>>>>> 1. XML actions are different in each widget and in the
>>>>>>>> simple-methods; they share some underlying code but there are so many
>>>>>>>> differences
>>>>>>>>>>>>> 2. scriptlets and expressions are a messy combination of
>>> BeanShell,
>>>>>>>> UEL, and Groovy and keeping track of which is a pain, plus the Groovy
>>> syntax
>>>>>>>> and capabilities are SO much better than the others so I find myself
>>> almost
>>>>>>>> always using ${groovy:...} instead of the default, and in annoying
>>> places
>>>>>>>> like the form.field.@use-when attribute since it is always BeanShell
>>> I
>>>>>>>> just use a set action to prepare a boolean and then check it in the
>>> use-when
>>>>>>>> (BeanShell is HORRIBLE compared to groovy, especially when squeezed
>>> into XML
>>>>>>>> attributes)
>>>>>>>>>>>>> 3. the controller.xml file gets HUGE for larger applications,
>>> and if
>>>>>>>> split it becomes harder to find requests and views; *Screen.xml files
>>> also
>>>>>>>> tend to get HUGE with large numbers of screens in them; both are not
>>>>>>>> organized in the same way as the application, also generally making
>>> things
>>>>>>>> harder to find; views/screens and requests don't define incoming
>>> parameters
>>>>>>>> so when doing request-redirect you have to specify the parameters to
>>> use in
>>>>>>>> a larger number of places
>>>>>>>>>>>>> 4. another on the topic of why so many files: service groups and
>>>>>>>> simple-methods are just XML, why not include them inline in the
>>> service
>>>>>>>> definition (especially for smaller services), and encourage fewer
>>> services
>>>>>>>> per file
>>>>>>>>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>>>>>>>> screens, forms, services, entities and so on that are not used are
>>> loaded
>>>>>>>> anyway; also many artifacts are difficult to reload by cache clearing
>>> and so
>>>>>>>> that has limited support in OFBiz; this slows things down reloading
>>> lots of
>>>>>>>> stuff in development, and results in more resources used than needed
>>> in
>>>>>>>> production
>>>>>>>>>>>>> 6. the deployment model of OFBiz is limited and the use of
>>> static
>>>>>>>> fields for initialization makes it difficult to deploy in other ways;
>>> there
>>>>>>>> are few init/destroy methods and object instances that would make
>>> more
>>>>>>>> deployment models easier and more flexible; also because of this it
>>> is
>>>>>>>> difficult to get data from other parts of the framework (for example
>>> the
>>>>>>>> audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables
>>> to
>>>>>>>> pass userLoginId and visitId down since there is no other good way of
>>> doing
>>>>>>>> it); in other words, the tools don't share a context
>>>>>>>>>>>>> 7. no API for apps; the framework is made up of an enormous
>>> number of
>>>>>>>> classes that follow a bunch of different "patterns" (in quotes
>>> because the
>>>>>>>> use of the term is generous) because of various people "cleaning"
>>> things up
>>>>>>>> over time (also in quotes because the use of the term is generous),
>>> and
>>>>>>>> there is no distinction between the API that apps are intended to use
>>> and
>>>>>>>> the internal implementation of that API; this has the nasty side
>>> effect of
>>>>>>>> making it difficult to find the object and method you want, AND it
>>> makes
>>>>>>>> backward compatibility problems REALLY nasty because it gets people
>>>>>>>> believing that EVERY SINGLE object needs to ALWAYS be backward
>>> compatible...
>>>>>>>> and that results in more and more piles of trash code lying around
>>> over
>>>>>>>> time, and all of that code and differing patterns makes framework
>>> changes
>>>>>>>> error-prone and unnecessarily difficult (and this is true for some of
>>> the
>>>>>>>> app code in OFBiz too)
>>>>>>>>>>>>> I should get back to work... there's a short list anyway...
>>>>>>>>>>>>> The trick is how to solve these without abandoning backward
>>>>>>>> compatibility, and requiring a refactor of much of the framework and
>>> then
>>>>>>>> based on that the updating of massive numbers of application
>>> artifacts...
>>>>>>>> and that is just the stuff in OFBiz itself... not including
>>> everything that
>>>>>>>> everyone else has written outside the project that they may want to
>>> update.
>>>>>>>> And, ALL of that would have to be retested. Plus, it would take so
>>> long to
>>>>>>>> get all of this done in a branch with huge numbers of changes while
>>> others
>>>>>>>> are making incremental changes in the trunk making it nearly
>>> impossible to
>>>>>>>> merge the branch into the trunk, so it would basically be a fork
>>> anyway...
>>>>>>>>>>>>> -David
>>>>
>>>> Project Manager, POS? Even maybe My Portal?
>>>>
>>>> Jacquees
>>>
>>>
>

[Adrian Crum-3]

On 1/26/2011 11:56 PM, David E Jones wrote:

> No, the discussion is not, but your response here is "inherently bureaucratic".
>
> You wrote: "Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas."
>
> That's some serious push-back... MAYBE after the 11.x branch we can DISCUSS these ideas?
>
> Hints at bureaucracy are still bureaucracy.
>
> To take this to its logical conclusion: "Following the 11.x branch, which is a date not yet decided, the Committee will consider the discussion of your ideas. Should the Committee decide that discussion of said ideas is not in the best interest of the Project, the Committee will not discuss your ideas. The Committee does not consider the discussion of any idea from any source to be a commitment to act on said idea. The Committee hereby reserves the right to complain and push back and if necessary commit-war against any idea deemed improper or not in the best interest of the Project. The Committee further hereby disclaims any official status regarding these statements."
>
> This is a great definition of the term from Wikipedia: "organization characterized by hierarchy, fixed rules, impersonal relationships, rigid adherence to procedures, and a highly specialized division of labor."
>
> Is that a clear enough explanation of the community patterns I find less than desirable?

I found some definitions of bureaucracy too:

"What might be nice is to restrict
access to the framework, and maybe even have people acting as moderators for
different parts of the framework. For example, if you can't make any
changes to
the Entity Engine without going through Adam Heath then this may slow things
down a bit, but there would be a review of the design and implementation of
every new feature or fix and that would lead to more consistency and
quality in
the design and implementation of the tool, making it hopefully easier to
use and
safer to rely on." -David Jones, OFBiz Dev mailing list, March 2010
(http://markmail.org/message/kitdbna5lltj5jyp)

"The idea is for everything to go
through a single moderator. Contributions from others may be accepted,
but never
directly and only through the moderator. The project may have multiple
moderators each responsible for a different part of the whole, but
nothing will
go into the project without centralized review." -Dav id Jones, OFBiz
User mailing list, March 2010 (http://markmail.org/message/tkpzmvbqxb75mnks)

I'll leave it to the community to compare what I found with Wikipedia's
definition.

-Adrian

[David E. Jones-2]

On Jan 27, 2011, at 6:46 PM, Adrian Crum wrote:

> On 1/26/2011 11:56 PM, David E Jones wrote:
>> No, the discussion is not, but your response here is "inherently bureaucratic".
>>
>> You wrote: "Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas."
>>
>> That's some serious push-back... MAYBE after the 11.x branch we can DISCUSS these ideas?
>>
>> Hints at bureaucracy are still bureaucracy.
>>
>> To take this to its logical conclusion: "Following the 11.x branch, which is a date not yet decided, the Committee will consider the discussion of your ideas. Should the Committee decide that discussion of said ideas is not in the best interest of the Project, the Committee will not discuss your ideas. The Committee does not consider the discussion of any idea from any source to be a commitment to act on said idea. The Committee hereby reserves the right to complain and push back and if necessary commit-war against any idea deemed improper or not in the best interest of the Project. The Committee further hereby disclaims any official status regarding these statements."
>>
>> This is a great definition of the term from Wikipedia: "organization characterized by hierarchy, fixed rules, impersonal relationships, rigid adherence to procedures, and a highly specialized division of labor."
>>
>> Is that a clear enough explanation of the community patterns I find less than desirable?
>
> I found some definitions of bureaucracy too:
>
> "What might be nice is to restrict
> access to the framework, and maybe even have people acting as moderators for
> different parts of the framework. For example, if you can't make any changes to
> the Entity Engine without going through Adam Heath then this may slow things
> down a bit, but there would be a review of the design and implementation of
> every new feature or fix and that would lead to more consistency and quality in
> the design and implementation of the tool, making it hopefully easier to use and
> safer to rely on." -David Jones, OFBiz Dev mailing list, March 2010 (http://markmail.org/message/kitdbna5lltj5jyp)
>
> "The idea is for everything to go
> through a single moderator. Contributions from others may be accepted, but never
> directly and only through the moderator. The project may have multiple
> moderators each responsible for a different part of the whole, but nothing will
> go into the project without centralized review." -Dav id Jones, OFBiz User mailing list, March 2010 (http://markmail.org/message/tkpzmvbqxb75mnks)
>
> I'll leave it to the community to compare what I found with Wikipedia's definition.

Maybe you should stop trying to attack and start trying to understand.

Consider how multiple projects fits into this.

-David

[Adrian Crum-3]

On 1/27/2011 7:28 PM, David E Jones wrote:

> On Jan 27, 2011, at 6:46 PM, Adrian Crum wrote:
>
>> On 1/26/2011 11:56 PM, David E Jones wrote:
>>> No, the discussion is not, but your response here is "inherently bureaucratic".
>>>
>>> You wrote: "Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas."
>>>
>>> That's some serious push-back... MAYBE after the 11.x branch we can DISCUSS these ideas?
>>>
>>> Hints at bureaucracy are still bureaucracy.
>>>
>>> To take this to its logical conclusion: "Following the 11.x branch, which is a date not yet decided, the Committee will consider the discussion of your ideas. Should the Committee decide that discussion of said ideas is not in the best interest of the Project, the Committee will not discuss your ideas. The Committee does not consider the discussion of any idea from any source to be a commitment to act on said idea. The Committee hereby reserves the right to complain and push back and if necessary commit-war against any idea deemed improper or not in the best interest of the Project. The Committee further hereby disclaims any official status regarding these statements."
>>>
>>> This is a great definition of the term from Wikipedia: "organization characterized by hierarchy, fixed rules, impersonal relationships, rigid adherence to procedures, and a highly specialized division of labor."
>>>
>>> Is that a clear enough explanation of the community patterns I find less than desirable?
>> I found some definitions of bureaucracy too:
>>
>> "What might be nice is to restrict
>> access to the framework, and maybe even have people acting as moderators for
>> different parts of the framework. For example, if you can't make any changes to
>> the Entity Engine without going through Adam Heath then this may slow things
>> down a bit, but there would be a review of the design and implementation of
>> every new feature or fix and that would lead to more consistency and quality in
>> the design and implementation of the tool, making it hopefully easier to use and
>> safer to rely on." -David Jones, OFBiz Dev mailing list, March 2010 (http://markmail.org/message/kitdbna5lltj5jyp)
>>
>> "The idea is for everything to go
>> through a single moderator. Contributions from others may be accepted, but never
>> directly and only through the moderator. The project may have multiple
>> moderators each responsible for a different part of the whole, but nothing will
>> go into the project without centralized review." -Dav id Jones, OFBiz User mailing list, March 2010 (http://markmail.org/message/tkpzmvbqxb75mnks)
>>
>> I'll leave it to the community to compare what I found with Wikipedia's definition.
> Maybe you should stop trying to attack and start trying to understand.
>

I understand completely. Maybe you should stop imagining non-existent
bureaucracies, non-existent obstacles, and non-existent attacks, and try
to contribute something positive to the community.

The path has been cleared for you to fix the things you listed as being
wrong with OFBiz. Go for it! I'm available to help.

-Adrian

[BJ Freeman]

Just a note David
I agree with Adam when more than one has a view that agree, would not
that mean they might have a valid point.


=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


David E Jones sent the following on 1/27/2011 7:28 PM:

>
> On Jan 27, 2011, at 6:46 PM, Adrian Crum wrote:
>
>> On 1/26/2011 11:56 PM, David E Jones wrote:
>>> No, the discussion is not, but your response here is "inherently bureaucratic".
>>>
>>> You wrote: "Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas."
>>>
>>> That's some serious push-back... MAYBE after the 11.x branch we can DISCUSS these ideas?
>>>
>>> Hints at bureaucracy are still bureaucracy.
>>>
>>> To take this to its logical conclusion: "Following the 11.x branch, which is a date not yet decided, the Committee will consider the discussion of your ideas. Should the Committee decide that discussion of said ideas is not in the best interest of the Project, the Committee will not discuss your ideas. The Committee does not consider the discussion of any idea from any source to be a commitment to act on said idea. The Committee hereby reserves the right to complain and push back and if necessary commit-war against any idea deemed improper or not in the best interest of the Project. The Committee further hereby disclaims any official status regarding these statements."
>>>
>>> This is a great definition of the term from Wikipedia: "organization characterized by hierarchy, fixed rules, impersonal relationships, rigid adherence to procedures, and a highly specialized division of labor."
>>>
>>> Is that a clear enough explanation of the community patterns I find less than desirable?
>>
>> I found some definitions of bureaucracy too:
>>
>> "What might be nice is to restrict
>> access to the framework, and maybe even have people acting as moderators for
>> different parts of the framework. For example, if you can't make any changes to
>> the Entity Engine without going through Adam Heath then this may slow things
>> down a bit, but there would be a review of the design and implementation of
>> every new feature or fix and that would lead to more consistency and quality in
>> the design and implementation of the tool, making it hopefully easier to use and
>> safer to rely on." -David Jones, OFBiz Dev mailing list, March 2010 (http://markmail.org/message/kitdbna5lltj5jyp)
>>
>> "The idea is for everything to go
>> through a single moderator. Contributions from others may be accepted, but never
>> directly and only through the moderator. The project may have multiple
>> moderators each responsible for a different part of the whole, but nothing will
>> go into the project without centralized review." -Dav id Jones, OFBiz User mailing list, March 2010 (http://markmail.org/message/tkpzmvbqxb75mnks)
>>
>> I'll leave it to the community to compare what I found with Wikipedia's definition.
>
> Maybe you should stop trying to attack and start trying to understand.
>
> Consider how multiple projects fits into this.
>
> -David
>
>
>

[BJ Freeman]

oops mean Adrian.


BJ Freeman sent the following on 1/27/2011 10:53 PM:

> Just a note David
> I agree with Adam when more than one has a view that agree, would not
> that mean they might have a valid point.
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation
> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
>
>
> David E Jones sent the following on 1/27/2011 7:28 PM:
>>
>> On Jan 27, 2011, at 6:46 PM, Adrian Crum wrote:
>>
>>> On 1/26/2011 11:56 PM, David E Jones wrote:
>>>> No, the discussion is not, but your response here is "inherently
>>>> bureaucratic".
>>>>
>>>> You wrote: "Your suggestions sound fair to me. Maybe after the 11.x
>>>> branch is created we can discuss these ideas."
>>>>
>>>> That's some serious push-back... MAYBE after the 11.x branch we can
>>>> DISCUSS these ideas?
>>>>
>>>> Hints at bureaucracy are still bureaucracy.
>>>>
>>>> To take this to its logical conclusion: "Following the 11.x branch,
>>>> which is a date not yet decided, the Committee will consider the
>>>> discussion of your ideas. Should the Committee decide that
>>>> discussion of said ideas is not in the best interest of the Project,
>>>> the Committee will not discuss your ideas. The Committee does not
>>>> consider the discussion of any idea from any source to be a
>>>> commitment to act on said idea. The Committee hereby reserves the
>>>> right to complain and push back and if necessary commit-war against
>>>> any idea deemed improper or not in the best interest of the Project.
>>>> The Committee further hereby disclaims any official status regarding
>>>> these statements."
>>>>
>>>> This is a great definition of the term from Wikipedia: "organization
>>>> characterized by hierarchy, fixed rules, impersonal relationships,
>>>> rigid adherence to procedures, and a highly specialized division of
>>>> labor."
>>>>
>>>> Is that a clear enough explanation of the community patterns I find
>>>> less than desirable?
>>>
>>> I found some definitions of bureaucracy too:
>>>
>>> "What might be nice is to restrict
>>> access to the framework, and maybe even have people acting as
>>> moderators for
>>> different parts of the framework. For example, if you can't make any
>>> changes to
>>> the Entity Engine without going through Adam Heath then this may slow
>>> things
>>> down a bit, but there would be a review of the design and
>>> implementation of
>>> every new feature or fix and that would lead to more consistency and
>>> quality in
>>> the design and implementation of the tool, making it hopefully easier
>>> to use and
>>> safer to rely on." -David Jones, OFBiz Dev mailing list, March 2010
>>> (http://markmail.org/message/kitdbna5lltj5jyp)
>>>
>>> "The idea is for everything to go
>>> through a single moderator. Contributions from others may be
>>> accepted, but never
>>> directly and only through the moderator. The project may have multiple
>>> moderators each responsible for a different part of the whole, but
>>> nothing will
>>> go into the project without centralized review." -Dav id Jones, OFBiz
>>> User mailing list, March 2010
>>> (http://markmail.org/message/tkpzmvbqxb75mnks)
>>>
>>> I'll leave it to the community to compare what I found with
>>> Wikipedia's definition.
>>
>> Maybe you should stop trying to attack and start trying to understand.
>>
>> Consider how multiple projects fits into this.
>>
>> -David
>>
>>
>>
>
>

[Jacopo Cappellato-4]

On Jan 27, 2011, at 12:19 PM, Pierre Smits wrote:

> That sounds like a workable solution to me as well.
>
> But why move parts of the current code of the product (as is it is now)
> outside of the ASF' repo?
>
> Looking at Commons in JIRA I see several related projects. We could do this
> for OFBiz too. Split up in to several sub projects, have for each sub
> project a committed sub community of users, contributors and committers. And
> still having interaction between all.

In my opinion, the "paperwork" overhead required to setup maintain several subprojects (each with its own PMC, committers etc..) in the OFBiz community will be an overkill: our community is still too small for this.
But of course we do not have to necessarily throw our code out; we can still, even if in a more informal way, internally structure our code base in a subproject friendly way.
For example, we could follow a path like this:

1) separate the framework and application into two "trunks":
trunk/framework
trunk/applications
2) create a stable branch from the framework
branches/old-framework
3) the checkout instructions (and releases) will be done using:
branches/old-framework
trunk/applications
i.e. applications will be maintained over the stable framework, not the trunk/framework
4) the development for the next generation framework will happen in the trunk/framework and initially we will not care about compatibility with the applications
In this way the community will continue to work: a part of it will develop applications in the old way (as it is now); some developers will work on the new framework
5) when the new framework will reach a stable point we will plan to port the applications to it

A lot of details are missing but this is the general idea

Jacopo

>
> Regards,
>
> Pierre
>
>
>
> 2011/1/27 Jacopo Cappellato <[hidden email]>
>
>> On Jan 27, 2011, at 11:50 AM, Scott Gray wrote:
>>
>>> (With so many messages I don't have a good spot to say my short piece so
>> here will do)
>>>
>>> IMO our problems will only increase with the size of the code base.
>> Every time a new feature is committed you have an additional potential
>> audience that must be kept happy and our ability to please everybody
>> continues to decrease.  Unhappy people don't work well together so things
>> just keep getting worse.
>>>
>>> Solution?  Decrease the size of the code base and included features and
>> increase the ability for the community to share contributions outside of the
>> ASF's repo.  Decrease the load on the committers and let the rest of the
>> community put their money where their mouth is.
>>> Some ideas (feasible or not):
>>> - Pull out all of the themes except one and move each one to google code
>> or wherever if there is someone interested in looking after each one.
>>> - Then do the same for the bulk of the special purpose apps.
>>> - Separate the framework from the applications.
>>> - Remove any framework features that aren't used by the applications or
>> are of relatively low value and allow them to be dropped in by users when
>> they need them.
>>> - Perhaps even take another look at the possibility of reducing the
>> dependencies among the core apps and splitting them (I'd gladly welcome 100
>> new committers to the humanres app because I have no interest in it).
>>> - Turn the payment and shipping gateway implementations into drop in
>> components along with any other pieces of code that are suitable for
>> extraction
>>> - Investigate ways to allow plug-in modification of apps and implement
>> something (anything) that allows it.
>>>
>>
>> +1 on all points; the next step in the life of the project will be the
>> setup of an healthy ecosystem and these are concrete steps in that
>> direction.
>>
>> Jacopo
>>
>>> Right now we have a gigantic project with a gateway of ~13 active
>> committers (23 total) who have day jobs to worry about along with reviewing
>> (and fighting about) commits (or just giving up on this responsibility),
>> attempting to improve the project and taking part in these (mostly pointless
>> discussions) and then keeping the rest of the community happy.  Increasing
>> the number of committers just increases the potential for disagreement and
>> then stagnation so the only other option to reduce the code.
>>>
>>> Give control of features and components to people who care about them and
>> then help users find them externally as they need them.  Don't like the
>> direction a feature/component is taking? Fork it and compete.
>>>
>>> Regards
>>> Scott
>>>
>>> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>>>
>>>> I have noticed some negative trends happening to us in the last (1-2)
>> years:
>>>> * a dramatic decrease of design discussions and an increase in commits
>>>> * committers are often working for themselves and not for the greater
>> good of the project ("if a customer pays me to do something then it will be
>> also good for the project")
>>>> * less peer reviews and mostly focused on formal aspects rather then
>> fundamental aspects of the contributions
>>>> * a decrease in the minimum quality level needed to make a commit
>> "acceptable"
>>>> * a proliferation of "best practices" and "rules" in an attempt to
>> improve the quality of the commits
>>>> * a decay in the attitude and quality of discussions: attacks, critics
>> and fights instead of healthy discussions to learn from others and improve
>> design decisions
>>>>
>>>> Of course I am focusing on bad things, to the good ones (yes, there are
>> also good ones) it is easier to adjust: however when the final result of our
>> efforts is that a person like David doesn't feel comfortable in contributing
>> more then I feel bad.
>>>> The primary goal of the PMC, and the community in general, should be
>> that of creating the perfect environment to facilitate contributions from
>> people like David, and limit/review/improve the contributions from other
>> less blessed contributors: it seems like all our efforts are obtaining the
>> exact opposite result.
>>>>
>>>> Jacopo
>>>>
>>>> On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
>>>>
>>>>>
>>>>> I'll respond here to Adrian's comments below, and to what Raj and
>> others have written as well.
>>>>>
>>>>> Backwards compatibility is a huge issue, but I suppose that is as much
>> a symptom as it is a disease in and of itself. The underlying issue is
>> bureaucracy.
>>>>>
>>>>> If I wanted to spend all my time chatting with others and writing
>> endlessly about when to do things and what to do, and trying to recruit
>> others to do it... then OFBiz would be the perfect place for that. I did
>> that for years, and I'm happy with what has been done with OFBiz, but there
>> came a point in time where the whole bureaucratic trend became stronger than
>> any single person's ability to push for new or different things. That point
>> in time was at least a yeah and a half ago, and perhaps long earlier than
>> that depending on how you look at it.
>>>>>
>>>>> Personally, I'd rather spend my time on more productive efforts, and do
>> so in a way that avoids this same bureaucratic mess in the future (like
>> different management style and keeping framework, data model, themes, and
>> applications as separate projects). This way not only I, but many people are
>> free to work on what they want to and not have to argue about every little
>> thing they want to do, or deal with constant complaints about every little
>> thing they actually do.
>>>>>
>>>>> Isn't separate and competing projects better than that everyone arguing
>> and having to agree on what to do? Well, I have good news! No matter how you
>> (the reader) answer that question, you have an option to fit your
>> preferences.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>>>>>
>>>>>> Many of the things listed here have been discussed, and as far as I
>> can tell, there is no objection to making those changes - we just need the
>> manpower to do it.
>>>>>>
>>>>>> Item #7 has been discussed and there hasn't been any argument against
>> that change - except that it touches on the backwards-compatibility issue.
>> And I'm going to use this opportunity to address that issue.
>>>>>>
>>>>>> Some of the changes mentioned here wouldn't affect any of my projects
>> - because I don't attempt to patch or modify the framework - I only build
>> applications on it. Other changes mentioned here would make application
>> development easier.
>>>>>>
>>>>>> The other day Ryan Foster described the backwards-compatibility talk
>> as a mantra. I view it as more of a straw man. Five days ago I posed this
>> question to the user mailing list:
>>>>>>
>>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project
>> could be improved greatly - but at the cost of some backward incompatibility
>> - accept the changes? If yes, how often would backwards-incompatible changes
>> be acceptable?"
>>>>>>
>>>>>> It is interesting to note that in a list of over 400 subscribers, no
>> one has replied.
>>>>>>
>>>>>> The most vocal proponents of backwards-compatibility (in the
>> framework) are a few players who have modified the framework locally. As a
>> community, do we really want to allow those few members to stifle
>> innovation?
>>>>>>
>>>>>> Some users claimed the updated Flat Grey visual theme wasn't
>> "backwards compatible."  What does that even mean? Some colors and
>> background images were changed - how is that backwards incompatible?
>>>>>>
>>>>>> To be fair, I have been an advocate for backwards-compatibility. But
>> that has been for things that break application functionality.
>>>>>>
>>>>>> At the least, there needs to be a compromise. At best, there needs to
>> be acceptance of the possibility of future versions that are not backwards
>> compatible with previous versions. That concept is not new or revolutionary
>> - it goes on in every software project, both open source and commercial.
>>>>>>
>>>>>> David has some great ideas, but he feels compelled to start over from
>> scratch to implement them. From my perspective, that's a tragedy. One of the
>> project's founders feels the need to start another project as a last resort
>> to make the project he originally started better. Does that make sense?
>>>>>>
>>>>>> I don't want to use Moqui. It's an unfinished framework controlled by
>> one person and it has no applications built around it. Bottom line - it's
>> not an option. What I want is  Moqui's innovations in OFBiz.
>>>>>>
>>>>>> I believe it's time we have a serious discussion about this. Users
>> have commented that there is no plan for OFBiz - what is planned for its
>> future? They're right. Maybe we should come up with some plans, or some kind
>> of path to the future.
>>>>>>
>>>>>> I propose we put all the cards on the table. Where do we go from here?
>> Continue on our present path and have competing projects that improve on
>> OFBiz technology?  Try to keep innovation in the project at the expense of
>> some backwards incompatibility? Maintain backwards compatibility by forking
>> the project to something new? Or have milestone versions that are clearly
>> marketed as backwards incompatible with previous milestone versions?
>>>>>>
>>>>>> Lately, it seems many of the big players in the OFBiz developer
>> community have been absent on the mailing list. I understand that this is a
>> volunteer community, but at the same time, we all have a say, and that "say"
>> depends on us saying *something.*
>>>>>>
>>>>>> So, please say something.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>>
>>>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>>>> All of that said, now that Moqui is starting to take shape I find
>> the OFBiz Framework to be cumbersome and inconsistent in many ways (things
>> that are hard to fix, but that are not surprising given the pioneering
>> history of the OFBiz Framework). Those funny quirky things are likely a
>> turn-off to prospective developers and I'm hoping to remove that impediment
>> to adopting the approach.
>>>>>>>> David - you keep saying this..Please provide some examples of
>> "cumbersome and inconsistent" within the framework. And why not try and fix
>> these? Instead of reinventing the wheel. What "funny quirky" things have
>> turned of prospective developers? Do you have an specific examples?
>>>>>>> Yes, I have mentioned these many times especially in the last 2-3
>> years. Some of them I have tried to fix in OFBiz itself and ran into rather
>> large problems. These are not easy changes to make in a large and mature
>> project like OFBiz, and after trying a few times I decided that a new
>> framework was the only way forward (another thing I've written before and
>> made very clear).
>>>>>>>
>>>>>>> These are the things that led to many aspects of the design of Moqui,
>> and the best summary of them is the document I wrote about the differences
>> between the Moqui and OFBiz frameworks:
>>>>>>>
>>>>>>>
>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>>
>>>>>>> To sum up here are some of the major inconsistencies and annoyances
>> in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>>>
>>>>>>> 1. XML actions are different in each widget and in the
>> simple-methods; they share some underlying code but there are so many
>> differences
>>>>>>>
>>>>>>> 2. scriptlets and expressions are a messy combination of BeanShell,
>> UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax
>> and capabilities are SO much better than the others so I find myself almost
>> always using ${groovy:...} instead of the default, and in annoying places
>> like the form.field.@use-when attribute since it is always BeanShell I
>> just use a set action to prepare a boolean and then check it in the use-when
>> (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML
>> attributes)
>>>>>>>
>>>>>>> 3. the controller.xml file gets HUGE for larger applications, and if
>> split it becomes harder to find requests and views; *Screen.xml files also
>> tend to get HUGE with large numbers of screens in them; both are not
>> organized in the same way as the application, also generally making things
>> harder to find; views/screens and requests don't define incoming parameters
>> so when doing request-redirect you have to specify the parameters to use in
>> a larger number of places
>>>>>>>
>>>>>>> 4. another on the topic of why so many files: service groups and
>> simple-methods are just XML, why not include them inline in the service
>> definition (especially for smaller services), and encourage fewer services
>> per file
>>>>>>>
>>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>> screens, forms, services, entities and so on that are not used are loaded
>> anyway; also many artifacts are difficult to reload by cache clearing and so
>> that has limited support in OFBiz; this slows things down reloading lots of
>> stuff in development, and results in more resources used than needed in
>> production
>>>>>>>
>>>>>>> 6. the deployment model of OFBiz is limited and the use of static
>> fields for initialization makes it difficult to deploy in other ways; there
>> are few init/destroy methods and object instances that would make more
>> deployment models easier and more flexible; also because of this it is
>> difficult to get data from other parts of the framework (for example the
>> audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to
>> pass userLoginId and visitId down since there is no other good way of doing
>> it); in other words, the tools don't share a context
>>>>>>>
>>>>>>> 7. no API for apps; the framework is made up of an enormous number of
>> classes that follow a bunch of different "patterns" (in quotes because the
>> use of the term is generous) because of various people "cleaning" things up
>> over time (also in quotes because the use of the term is generous), and
>> there is no distinction between the API that apps are intended to use and
>> the internal implementation of that API; this has the nasty side effect of
>> making it difficult to find the object and method you want, AND it makes
>> backward compatibility problems REALLY nasty because it gets people
>> believing that EVERY SINGLE object needs to ALWAYS be backward compatible...
>> and that results in more and more piles of trash code lying around over
>> time, and all of that code and differing patterns makes framework changes
>> error-prone and unnecessarily difficult (and this is true for some of the
>> app code in OFBiz too)
>>>>>>>
>>>>>>> I should get back to work... there's a short list anyway...
>>>>>>>
>>>>>>> The trick is how to solve these without abandoning backward
>> compatibility, and requiring a refactor of much of the framework and then
>> based on that the updating of massive numbers of application artifacts...
>> and that is just the stuff in OFBiz itself... not including everything that
>> everyone else has written outside the project that they may want to update.
>> And, ALL of that would have to be retested. Plus, it would take so long to
>> get all of this done in a branch with huge numbers of changes while others
>> are making incremental changes in the trunk making it nearly impossible to
>> merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>

[rajsaini]

I think this is the best way to move forward and will keep current
development going while working on new ideas on new generation framework.

Thanks,

Raj


On Friday 28 January 2011 09:16 PM, Jacopo Cappellato wrote:

> On Jan 27, 2011, at 12:19 PM, Pierre Smits wrote:
>
>> That sounds like a workable solution to me as well.
>>
>> But why move parts of the current code of the product (as is it is now)
>> outside of the ASF' repo?
>>
>> Looking at Commons in JIRA I see several related projects. We could do this
>> for OFBiz too. Split up in to several sub projects, have for each sub
>> project a committed sub community of users, contributors and committers. And
>> still having interaction between all.
> In my opinion, the "paperwork" overhead required to setup maintain several subprojects (each with its own PMC, committers etc..) in the OFBiz community will be an overkill: our community is still too small for this.
> But of course we do not have to necessarily throw our code out; we can still, even if in a more informal way, internally structure our code base in a subproject friendly way.
> For example, we could follow a path like this:
>
> 1) separate the framework and application into two "trunks":
> trunk/framework
> trunk/applications
> 2) create a stable branch from the framework
> branches/old-framework
> 3) the checkout instructions (and releases) will be done using:
> branches/old-framework
> trunk/applications
> i.e. applications will be maintained over the stable framework, not the trunk/framework
> 4) the development for the next generation framework will happen in the trunk/framework and initially we will not care about compatibility with the applications
> In this way the community will continue to work: a part of it will develop applications in the old way (as it is now); some developers will work on the new framework
> 5) when the new framework will reach a stable point we will plan to port the applications to it
>
> A lot of details are missing but this is the general idea
>
> Jacopo
>
>> Regards,
>>
>> Pierre
>>
>>
>>
>> 2011/1/27 Jacopo Cappellato<[hidden email]>
>>
>>> On Jan 27, 2011, at 11:50 AM, Scott Gray wrote:
>>>
>>>> (With so many messages I don't have a good spot to say my short piece so
>>> here will do)
>>>> IMO our problems will only increase with the size of the code base.
>>> Every time a new feature is committed you have an additional potential
>>> audience that must be kept happy and our ability to please everybody
>>> continues to decrease.  Unhappy people don't work well together so things
>>> just keep getting worse.
>>>> Solution?  Decrease the size of the code base and included features and
>>> increase the ability for the community to share contributions outside of the
>>> ASF's repo.  Decrease the load on the committers and let the rest of the
>>> community put their money where their mouth is.
>>>> Some ideas (feasible or not):
>>>> - Pull out all of the themes except one and move each one to google code
>>> or wherever if there is someone interested in looking after each one.
>>>> - Then do the same for the bulk of the special purpose apps.
>>>> - Separate the framework from the applications.
>>>> - Remove any framework features that aren't used by the applications or
>>> are of relatively low value and allow them to be dropped in by users when
>>> they need them.
>>>> - Perhaps even take another look at the possibility of reducing the
>>> dependencies among the core apps and splitting them (I'd gladly welcome 100
>>> new committers to the humanres app because I have no interest in it).
>>>> - Turn the payment and shipping gateway implementations into drop in
>>> components along with any other pieces of code that are suitable for
>>> extraction
>>>> - Investigate ways to allow plug-in modification of apps and implement
>>> something (anything) that allows it.
>>> +1 on all points; the next step in the life of the project will be the
>>> setup of an healthy ecosystem and these are concrete steps in that
>>> direction.
>>>
>>> Jacopo
>>>
>>>> Right now we have a gigantic project with a gateway of ~13 active
>>> committers (23 total) who have day jobs to worry about along with reviewing
>>> (and fighting about) commits (or just giving up on this responsibility),
>>> attempting to improve the project and taking part in these (mostly pointless
>>> discussions) and then keeping the rest of the community happy.  Increasing
>>> the number of committers just increases the potential for disagreement and
>>> then stagnation so the only other option to reduce the code.
>>>> Give control of features and components to people who care about them and
>>> then help users find them externally as they need them.  Don't like the
>>> direction a feature/component is taking? Fork it and compete.
>>>> Regards
>>>> Scott
>>>>
>>>> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>>>>
>>>>> I have noticed some negative trends happening to us in the last (1-2)
>>> years:
>>>>> * a dramatic decrease of design discussions and an increase in commits
>>>>> * committers are often working for themselves and not for the greater
>>> good of the project ("if a customer pays me to do something then it will be
>>> also good for the project")
>>>>> * less peer reviews and mostly focused on formal aspects rather then
>>> fundamental aspects of the contributions
>>>>> * a decrease in the minimum quality level needed to make a commit
>>> "acceptable"
>>>>> * a proliferation of "best practices" and "rules" in an attempt to
>>> improve the quality of the commits
>>>>> * a decay in the attitude and quality of discussions: attacks, critics
>>> and fights instead of healthy discussions to learn from others and improve
>>> design decisions
>>>>> Of course I am focusing on bad things, to the good ones (yes, there are
>>> also good ones) it is easier to adjust: however when the final result of our
>>> efforts is that a person like David doesn't feel comfortable in contributing
>>> more then I feel bad.
>>>>> The primary goal of the PMC, and the community in general, should be
>>> that of creating the perfect environment to facilitate contributions from
>>> people like David, and limit/review/improve the contributions from other
>>> less blessed contributors: it seems like all our efforts are obtaining the
>>> exact opposite result.
>>>>> Jacopo
>>>>>
>>>>> On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
>>>>>
>>>>>> I'll respond here to Adrian's comments below, and to what Raj and
>>> others have written as well.
>>>>>> Backwards compatibility is a huge issue, but I suppose that is as much
>>> a symptom as it is a disease in and of itself. The underlying issue is
>>> bureaucracy.
>>>>>> If I wanted to spend all my time chatting with others and writing
>>> endlessly about when to do things and what to do, and trying to recruit
>>> others to do it... then OFBiz would be the perfect place for that. I did
>>> that for years, and I'm happy with what has been done with OFBiz, but there
>>> came a point in time where the whole bureaucratic trend became stronger than
>>> any single person's ability to push for new or different things. That point
>>> in time was at least a yeah and a half ago, and perhaps long earlier than
>>> that depending on how you look at it.
>>>>>> Personally, I'd rather spend my time on more productive efforts, and do
>>> so in a way that avoids this same bureaucratic mess in the future (like
>>> different management style and keeping framework, data model, themes, and
>>> applications as separate projects). This way not only I, but many people are
>>> free to work on what they want to and not have to argue about every little
>>> thing they want to do, or deal with constant complaints about every little
>>> thing they actually do.
>>>>>> Isn't separate and competing projects better than that everyone arguing
>>> and having to agree on what to do? Well, I have good news! No matter how you
>>> (the reader) answer that question, you have an option to fit your
>>> preferences.
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>>>>>>
>>>>>>> Many of the things listed here have been discussed, and as far as I
>>> can tell, there is no objection to making those changes - we just need the
>>> manpower to do it.
>>>>>>> Item #7 has been discussed and there hasn't been any argument against
>>> that change - except that it touches on the backwards-compatibility issue.
>>> And I'm going to use this opportunity to address that issue.
>>>>>>> Some of the changes mentioned here wouldn't affect any of my projects
>>> - because I don't attempt to patch or modify the framework - I only build
>>> applications on it. Other changes mentioned here would make application
>>> development easier.
>>>>>>> The other day Ryan Foster described the backwards-compatibility talk
>>> as a mantra. I view it as more of a straw man. Five days ago I posed this
>>> question to the user mailing list:
>>>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project
>>> could be improved greatly - but at the cost of some backward incompatibility
>>> - accept the changes? If yes, how often would backwards-incompatible changes
>>> be acceptable?"
>>>>>>> It is interesting to note that in a list of over 400 subscribers, no
>>> one has replied.
>>>>>>> The most vocal proponents of backwards-compatibility (in the
>>> framework) are a few players who have modified the framework locally. As a
>>> community, do we really want to allow those few members to stifle
>>> innovation?
>>>>>>> Some users claimed the updated Flat Grey visual theme wasn't
>>> "backwards compatible."  What does that even mean? Some colors and
>>> background images were changed - how is that backwards incompatible?
>>>>>>> To be fair, I have been an advocate for backwards-compatibility. But
>>> that has been for things that break application functionality.
>>>>>>> At the least, there needs to be a compromise. At best, there needs to
>>> be acceptance of the possibility of future versions that are not backwards
>>> compatible with previous versions. That concept is not new or revolutionary
>>> - it goes on in every software project, both open source and commercial.
>>>>>>> David has some great ideas, but he feels compelled to start over from
>>> scratch to implement them. From my perspective, that's a tragedy. One of the
>>> project's founders feels the need to start another project as a last resort
>>> to make the project he originally started better. Does that make sense?
>>>>>>> I don't want to use Moqui. It's an unfinished framework controlled by
>>> one person and it has no applications built around it. Bottom line - it's
>>> not an option. What I want is  Moqui's innovations in OFBiz.
>>>>>>> I believe it's time we have a serious discussion about this. Users
>>> have commented that there is no plan for OFBiz - what is planned for its
>>> future? They're right. Maybe we should come up with some plans, or some kind
>>> of path to the future.
>>>>>>> I propose we put all the cards on the table. Where do we go from here?
>>> Continue on our present path and have competing projects that improve on
>>> OFBiz technology?  Try to keep innovation in the project at the expense of
>>> some backwards incompatibility? Maintain backwards compatibility by forking
>>> the project to something new? Or have milestone versions that are clearly
>>> marketed as backwards incompatible with previous milestone versions?
>>>>>>> Lately, it seems many of the big players in the OFBiz developer
>>> community have been absent on the mailing list. I understand that this is a
>>> volunteer community, but at the same time, we all have a say, and that "say"
>>> depends on us saying *something.*
>>>>>>> So, please say something.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>>>
>>>>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>>>>> All of that said, now that Moqui is starting to take shape I find
>>> the OFBiz Framework to be cumbersome and inconsistent in many ways (things
>>> that are hard to fix, but that are not surprising given the pioneering
>>> history of the OFBiz Framework). Those funny quirky things are likely a
>>> turn-off to prospective developers and I'm hoping to remove that impediment
>>> to adopting the approach.
>>>>>>>>> David - you keep saying this..Please provide some examples of
>>> "cumbersome and inconsistent" within the framework. And why not try and fix
>>> these? Instead of reinventing the wheel. What "funny quirky" things have
>>> turned of prospective developers? Do you have an specific examples?
>>>>>>>> Yes, I have mentioned these many times especially in the last 2-3
>>> years. Some of them I have tried to fix in OFBiz itself and ran into rather
>>> large problems. These are not easy changes to make in a large and mature
>>> project like OFBiz, and after trying a few times I decided that a new
>>> framework was the only way forward (another thing I've written before and
>>> made very clear).
>>>>>>>> These are the things that led to many aspects of the design of Moqui,
>>> and the best summary of them is the document I wrote about the differences
>>> between the Moqui and OFBiz frameworks:
>>>>>>>>
>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>>> To sum up here are some of the major inconsistencies and annoyances
>>> in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>>>> 1. XML actions are different in each widget and in the
>>> simple-methods; they share some underlying code but there are so many
>>> differences
>>>>>>>> 2. scriptlets and expressions are a messy combination of BeanShell,
>>> UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax
>>> and capabilities are SO much better than the others so I find myself almost
>>> always using ${groovy:...} instead of the default, and in annoying places
>>> like the form.field.@use-when attribute since it is always BeanShell I
>>> just use a set action to prepare a boolean and then check it in the use-when
>>> (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML
>>> attributes)
>>>>>>>> 3. the controller.xml file gets HUGE for larger applications, and if
>>> split it becomes harder to find requests and views; *Screen.xml files also
>>> tend to get HUGE with large numbers of screens in them; both are not
>>> organized in the same way as the application, also generally making things
>>> harder to find; views/screens and requests don't define incoming parameters
>>> so when doing request-redirect you have to specify the parameters to use in
>>> a larger number of places
>>>>>>>> 4. another on the topic of why so many files: service groups and
>>> simple-methods are just XML, why not include them inline in the service
>>> definition (especially for smaller services), and encourage fewer services
>>> per file
>>>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>>> screens, forms, services, entities and so on that are not used are loaded
>>> anyway; also many artifacts are difficult to reload by cache clearing and so
>>> that has limited support in OFBiz; this slows things down reloading lots of
>>> stuff in development, and results in more resources used than needed in
>>> production
>>>>>>>> 6. the deployment model of OFBiz is limited and the use of static
>>> fields for initialization makes it difficult to deploy in other ways; there
>>> are few init/destroy methods and object instances that would make more
>>> deployment models easier and more flexible; also because of this it is
>>> difficult to get data from other parts of the framework (for example the
>>> audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to
>>> pass userLoginId and visitId down since there is no other good way of doing
>>> it); in other words, the tools don't share a context
>>>>>>>> 7. no API for apps; the framework is made up of an enormous number of
>>> classes that follow a bunch of different "patterns" (in quotes because the
>>> use of the term is generous) because of various people "cleaning" things up
>>> over time (also in quotes because the use of the term is generous), and
>>> there is no distinction between the API that apps are intended to use and
>>> the internal implementation of that API; this has the nasty side effect of
>>> making it difficult to find the object and method you want, AND it makes
>>> backward compatibility problems REALLY nasty because it gets people
>>> believing that EVERY SINGLE object needs to ALWAYS be backward compatible...
>>> and that results in more and more piles of trash code lying around over
>>> time, and all of that code and differing patterns makes framework changes
>>> error-prone and unnecessarily difficult (and this is true for some of the
>>> app code in OFBiz too)
>>>>>>>> I should get back to work... there's a short list anyway...
>>>>>>>>
>>>>>>>> The trick is how to solve these without abandoning backward
>>> compatibility, and requiring a refactor of much of the framework and then
>>> based on that the updating of massive numbers of application artifacts...
>>> and that is just the stuff in OFBiz itself... not including everything that
>>> everyone else has written outside the project that they may want to update.
>>> And, ALL of that would have to be retested. Plus, it would take so long to
>>> get all of this done in a branch with huge numbers of changes while others
>>> are making incremental changes in the trunk making it nearly impossible to
>>> merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>
>

[Erwan de FERRIERES]

Le 27/01/2011 12:29, Jacques Le Roux a écrit :

> From: "Erwan de FERRIERES" <[hidden email]>
>> Le 27/01/2011 11:50, Scott Gray a écrit :
>
> Erwan, could you give us a summary on how it works, from a technical
> POV? Few sentences should be enough...
>
> Thanks
>
> Jacques
>

Hi Jacques and all,

here is some info I wrote some time ago on the addon manager. It's still
true, so I'm just pasting the link.

http://ofbiz.135035.n4.nabble.com/Apache-OFBiz-EZBiz-td277317i20.html#a974679

HTH,

--
Erwan de FERRIERES
www.nereide.biz

[Jacques Le Roux]

Thanks Erwan,

I forgot about it, keeping it somewhere now

Jacques

From: "Erwan de FERRIERES" <[hidden email]>

> Le 27/01/2011 12:29, Jacques Le Roux a écrit :
>> From: "Erwan de FERRIERES" <[hidden email]>
>>> Le 27/01/2011 11:50, Scott Gray a écrit :
>>
>> Erwan, could you give us a summary on how it works, from a technical
>> POV? Few sentences should be enough...
>>
>> Thanks
>>
>> Jacques
>>
> Hi Jacques and all,
>
> here is some info I wrote some time ago on the addon manager. It's still true, so I'm just pasting the link.
>
> http://ofbiz.135035.n4.nabble.com/Apache-OFBiz-EZBiz-td277317i20.html#a974679
>
> HTH,
>
> --
> Erwan de FERRIERES
> www.nereide.biz
>