On 28/01/2011, at 12:02 AM, Erwan de FERRIERES wrote: > Le 27/01/2011 11:50, Scott Gray a écrit : >> (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. >> >> 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. >> > > we've got the apache-extras which could be a great place to put those > features and so on. At the moment, there is nothing related to OFBiz. > > http://code.google.com/a/apache-extras.org/hosting/
Well I'll be damned, that looks like it might be pretty perfect. > > Also, at Nereide, where I'm working, we've got the addon manager, which we > are using for adding features to OFBiz. Maybe we could give it a try for > splitting OFBiz, as you say. I've already been speaking about it. Still open > to anyone ! You may be aware that I don't personally see patches via an add-on manager as the ideal solution. But this is a wonderful example of Nereide taking the initiative and finding a solution for increasing the extensibility of OFBiz. I just see patches as a work-around to some of OFBiz's inflexibility instead of solving the core problems.
smime.p7s
Description: S/MIME cryptographic signature
