The main purpose of this thread is discussing the ideas; then we can proceed with the plan where there is agreement, discuss more (as it is happening for the "example" component) and find a good solution; if there are different opinions on specific components, and we will not find a good solution for all, we could start a vote. But I don't think it is necessary to vote formally on each specific item (but I am not against this idea if there is a general interest in a formal vote): we usually don't vote to add new features and in the same way we can remove them if there is a lazy consensus.
Kind regards, Jacopo On Mar 18, 2012, at 1:08 PM, Hans Bakker wrote: > Jacopo, > > seeing you are such a believer in community discussion, i assume this is a > proposal which gets properly discussed and will be voted upon? > > Regards, > Hans > > > On 03/18/2012 04:10 PM, 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 >> >
