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" <[email protected]> >>> 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 <[email protected]> >>> >>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >> >> >
