Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared.
There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: > In the last period the OFBiz project has grown a lot in shape: the implicitly > accepted (or tolerated) strategy operated by the active committers was that > the more features you could add to the official repository the better was: > you make happy the contributors, making them feel like they are a part of > something, and each committer could manage the code implemented for his/her > own projects directly in the OFBiz codebase. > > We operated under the concept that, since the code if "free" and the author > (committer or not) is willing to contribute it, then no one should/could > complain if it is added to the repository, if it doesn't cause immediate > problems to others; all in all it is an additional feature that may be used > by someone else in the future or if not would simply stay there without > causing any harm. > Following this strategy we got a lot of code like for example Webslinger, > seleniumxml, debian packages, all sort of specialpurpose applications etc... > > Since there was not a central and agreed upon roadmap, no one could really > state that a contribution was not a good fit for the project: each and every > committer could add what, in his own personal vision, was good for the > project. > > The wrong assumption is that, since the code if "free" then it doesn't harm > to include it. This is completely *wrong*: the code is not *free* at all > because as soon as you add it to the repository then you add a future cost to > the community: you all know that in the software industry the cost to > maintain a piece of code is by far greater than the cost to write it; and you > *have* to maintain the code unless you want to have and distribute stale code. > And this is exactly what we have now: > * high costs to maintain the code (e.g. I recently spent a lot of hours to > remove the Webslinger component) > * stale/unused/half baked code that causes confusion and bad impression to > user evaluating the quality of our product > > The message to all the committers is: when you add code to the repository, > you are asking the community to take care of its maintenance costs forever. > So please, add new code only when it is really beneficial to the project and > to a large audience of committers and users. > > It is like feeding a wild animal at the zoo with chips: everyone knows it is > bad for its health but when you are there it is so nice when it picks the > food from your own hands and you cannot resist and have to feed it. > > OFBiz is now suffering from serious weight issues: the committers community > is having an hard time to maintain the huge codebase, it is difficult to keep > track of all the features in the system etc... > > I think it is important to start a new phase of the project and focus our > energy in cleanup and consolidation of what we have. One step in this > direction is for OFBiz to lose weight. > > In order to get the ball rolling and focus on some concrete tasks I am > providing here some examples of stuff that I would like to see removed from > the project. > > IMPORTANT: Please consider that the list is not based on what I think the > perfect framework should be (so PLEASE do not reply stating what your ideal > framework should have), but simply on the following considerations: > * can the component be easily removed by the project? is it independent and > can live outside as a plugin? > * do we need all this custom code? can't we find a simpler, lighter and > better way to implement this? > * is this feature used by other code in the system? > * is the feature functional? or is it largely incomplete? > * is this an old component/code? > * is this used by a lot of persons? (this is tricky to decide but you can get > a feeling of it by reading the mailing lists, considering commit activity, > the status of the feature etc...) > > DISCLAIMER: I know it will be a painful decision because each of us reading > this will have a connection with some of the code listed below: several hours > spent on it, great ideas that never came to a finished plan; in fact I feel > the same for a few of the things in the list.... there are great ideas that > didn't come to a finalization... it doesn't mean that moving them out of the > project will kill them and this may actually help to get more visibility and > different user group; so please when you will read it... think to the greater > good of the community. > > Legenda for what I propose for each piece of code: > * Attic: remove from code base and document the removal for future reference > in this page > * Extras: identify a person interested in maintaining the code as a separate > project hosted as an Apache Extra project (not officially under the ASF); add > a link to it from the page that will contain "OFBiz Extras" > > And now (drums)..... THE LIST - PART 1(but this is really a very first pass > only, PART 2 will come soon with more granular - subcomponent - details): > > A) move framework/guiapp out of the framework; after all these years no code > made advantage of it being part of the framework and it is only used by the > specialpurpose/pos component (which was the component for which it was built > for); so guiapp can go in the pos component > > B) specialpurpose/pos: move to "Extras" > > C) $OFBIZ_HOME/debian: move to "Attic" > > D) the seleniumxml code in framework/testtools: move to "Attic" > > E) specialpurpose/workflow: move to "Attic" > > F) specialpurpose/shark: move to "Attic" > > G) specialpurpose/ofbizwebsite: move to "Attic" > > H) specialpurpose/*: move several (if not all, apart ecommerce) of the > components to "Extras" (if there are persons interested to become > committers/maintainers) or to "Attic" > > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to > "Extras"; keep just one (or two) > > J) framework/appserver: move to "Extras" > > K) framework/jetty: move to "Extras" (or "Attic") > > L) framework/birt (and related dependencies/reports spread around): move to > "Extras" > > M) framework/bi (and related dependencies - ecas/business rules and data - > spread around): move to "Extras" > > N) framework/jcr: move back into the Jackrabbit branch until the work is > completed and can replace the existing "content framework" > > O) framework/documents: move the content to Wiki and then move to "Attic" > > P) framework/datafile: (who is currently using it?) move to "Extras" or > "Attic"; we could replace it with commons-csv or similar tool > > Q) framework/example and framework/exampleext: move to specialpurpose > > Kind regards, > > Jacopo >
