On 28/01/2011, at 12:17 AM, Jacques Le Roux wrote: > 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. > > I'd keep two: New Flat Grey and Tomahawk (Tomahawk is evolution of others but > Bizness Time which miss too much things: > https://issues.apache.org/jira/browse/OFBIZ-2398)
This is exactly the mentality we need to break away from, keeping two is just
an attempt to not piss anyone off. Pick one and let those who would be annoyed
maintain and deploy the other one themselves (I could be one of those people
and I'm fine with that).
>> - 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.
>
> Finally, the more I think about it the more I'd like this plugin way. With
> OFBiz maturity, it's really needed as Scott well explained.
>
> Jacques
>
>> 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
smime.p7s
Description: S/MIME cryptographic signature
