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