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