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
>>>>>
>>>>>
>>>>
>>>
>>
>
