We will setup a page in the OFBiz website, for sure. The final decision on the projects that will appear there will be done by the OFBiz PMC but I guess that initially it will only contain projects in Apache Extras; there may be exceptions to to this rule, I guess.
Jacopo On Mar 21, 2012, at 11:05 AM, Sam Hamilton wrote: > Where are we going to show the list of addons for OFBiz? Will this only be > limited to ones in Apache Extra's or for the people who prefer to do their > source hosting on say github join in too? > > Thanks > Sam > > > On 21 Mar 2012, at 16:23, Vikas Mayur wrote: > >> Thanks Jacopo for your quick response. It clears my doubt. >> >> Regards >> Vikas >> >> On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: >> >>> Hi Vikas, >>> >>> I am sharing my ideas about this new process (they are also based on my >>> reading of various documents provided by ASF): >>> >>> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: >>> >>>> Hi Jacopo, >>>> >>>> I have few questions on the proposed idea for Extras. >>>> >>>> -- Since the projects will be hosted as Apache OFBiz Extras and not >>>> officially under ASF, In future does this means these projects should >>>> strictly follow the ASF license? What if user group and/or the code >>>> maintainer of the project tries to change any such thing over time? >>> >>> No, each project will be free to decide the license; of course the ASL2.0 >>> will make it easier to contribute code with Apache OFBiz, but it will not >>> be a requirement. >>> >>>> >>>> -- Will all committers from OFBiz other than the maintainer still have a >>>> commit rights to Extras? I believe maintainer would be any existing >>>> committer(s) or new committer(s) assigned to the project(s) in Extras. >>> >>> Not necessarily: the maintainer could be also a non-committer and not all >>> OFBiz committers will automatically get access to the project in Extras >>> (you have to accept the agreement with Google etc...); this is definitely >>> true for new projects that will start from scratch; for projects that will >>> be contributed by the OFBiz community (by moving components out of OFBiz) >>> we will ask to the maintainer to invite each OFBiz committer to become a >>> committer: the ones that will accept will be setup there >>> >>>> -- Will the OFBiz community in general still be keeping track of >>>> development, discussions, future of these projects or any other activities? >>> >>> I would like something like this: the OFBiz community could encourage (not >>> oblige) the external project to send status updates to the OFBiz dev list >>> from time to time to keep the community updated (every month/quarter or >>> based on activity or milestones reached); I guess that the best mechanism >>> will be refined over time with some experience >>> >>>> -- Is it necessary for Apache OFBiz Extras projects to follow the release >>>> policy similar to OFBiz? >>> >>> No >>> >>>> -- If no one come forward for a certain project under specialpurpose, it >>>> will be moved to Attic. What if, in future someone show interest in the >>>> project, will the project be moved Extras or not? >>> >>> Yes, we can resurrect all the code in our repository; the Attic page in >>> Confluence will help to keep track of components that we remove. >>> >>> Regards, >>> >>> Jacopo >>> >>> >>>> >>>> Regards >>>> Vikas >>>> >>>> On Mar 18, 2012, at 2:40 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 >>>>> >>>> >>> >> >
