Lose Weight Program for OFBiz

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

I think Example should stay in the framework, but get rid of all of  
the "showroom" stuff that has been added to it. In other words, keep  
it and return it to its original purpose - a very basic component for  
new users to understand OFBiz.

I use datafile to connect legacy systems to OFBiz.

I agree that specialpurpose should be slimmed down, but we should  
retain one or two components to demonstrate the concept of reusing  
artifacts to create custom applications.

-Adrian

Quoting Jacopo Cappellato <[hidden email]>:

> 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
>
>

[Jacques Le Roux]

Thanks for the proposition Jacopo,

Inline...

From: <[hidden email]>
>I think Example should stay in the framework, but get rid of all of  
> the "showroom" stuff that has been added to it. In other words, keep  
> it and return it to its original purpose - a very basic component for  
> new users to understand OFBiz.

I agree notably the forms page
https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples

The rest could be in specialpurpose, with another name?
 
> I use datafile to connect legacy systems to OFBiz.
>
> I agree that specialpurpose should be slimmed down, but we should  
> retain one or two components to demonstrate the concept of reusing  
> artifacts to create custom applications.

Yes, ecomclone for instance should stay with ecommerce

> -Adrian
>
> Quoting Jacopo Cappellato <[hidden email]>:
>
>> 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

I can handle the  framework/guiapp move to 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"

specialpurpose/ofbizwebsite could go to extras rather... if someone is interested to continue the effort...

>> 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)

I would move all to extras and keep Tomahawk and Flat Grey. I'd prefer to keep Tomahawk  the defautl as it is now.

>> 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"

This should be coordinated with  https://issues.apache.org/jira/browse/OFBIZ-4709

>> O) framework/documents: move the content to Wiki and then move to "Attic"

So get rid of the online help also?

>> P) framework/datafile: (who is currently using it?) move to "Extras"  
>> or "Attic"; we could replace it with commons-csv or similar tool

I second Adrian on datafile. Though I have not used it for years, it can be handy at any moment.

>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>> Kind regards,
>>
>> Jacopo

For the rest I agree

Jacques

[hans_bakker]

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
>

[Adrian Crum-3]

Quoting Jacques Le Roux <[hidden email]>:

> Thanks for the proposition Jacopo,
>
> Inline...
>
> From: <[hidden email]>
>> I think Example should stay in the framework, but get rid of all of  
>>  the "showroom" stuff that has been added to it. In other words,  
>> keep  it and return it to its original purpose - a very basic  
>> component for  new users to understand OFBiz.
>
> I agree notably the forms page  
> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples

Form widget examples, Ajax examples, Portal examples, JCR examples,  
etc. All of it. This was supposed to be a stripped down application  
that would not overwhelm a new user.

-Adrian

[Olivier.heintz]

Le 18/03/2012 10:10, Jacopo Cappellato a écrit :

> 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

It's true because there is no way in a "large application" to know who
are available to maintain this part of code or who is using it. So one
of main conclusion is to manage more small piece of "code", to be sure a
committer in a project is responsible for all the Project.
> 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.

To avoid that some feel attacked or judged by the removing of a piece of
code, it seems to me very important that all portions of code that is
removed or move can be easily maintained (in parallel to OFBiz) by one
who wishes.
If it's a full component, it's currently easy.
If it's a functionality or a technical part (ex: Birt) it's currently
possible but it's more complex to maintain the relative report in the
different end user application (in OFBiz) which used it
if it's a functionality, such as rental, it's currently very complex to
maintain it in parallel to OFBiz

I am convinced that the proper evaluation of the usefulness and / or use
of a feature is:
1) is there enough contributors - maintainers
2) is there enough users

There will inevitably be errors in this (very good) approach to weight
loss. So, we also need the right tool to be able to correct them.

In parallel with this work to classify Code which is Used or Not, I
propose to start a second thread about OFBiz Plugin Management, what is
available and what is needed before removing or moving some components
(or part of component)

> 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
>
>

[Olivier.heintz]

Inline

Le 18/03/2012 13:05, Jacques Le Roux a écrit :
> Thanks for the proposition Jacopo,
>
> Inline...
>
> From: <[hidden email]>
>> I think Example should stay in the framework, but get rid of all of  
>> the "showroom" stuff that has been added to it. In other words, keep  
>> it and return it to its original purpose - a very basic component
>> for  new users to understand OFBiz.
+1
>
> I agree notably the forms page
> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>
> The rest could be in specialpurpose, with another name?
>
>> I use datafile to connect legacy systems to OFBiz.
I've never used except 1 month ago ;-) , and it was very effective.
>>
>> I agree that specialpurpose should be slimmed down, but we should  
>> retain one or two components to demonstrate the concept of reusing  
>> artifacts to create custom applications.
+1
>
> Yes, ecomclone for instance should stay with ecommerce
>
>> -Adrian
>>
>> Quoting Jacopo Cappellato <[hidden email]>:
>>
>>>
...

>>>
>>> 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
>
> I can handle the  framework/guiapp move to 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"
>
> specialpurpose/ofbizwebsite could go to extras rather... if someone is
> interested to continue the effort...

+1
>
>>> 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)
only one and other to extras, in our customer project, all are using
depending on end-user choice

>
> I would move all to extras and keep Tomahawk and Flat Grey. I'd prefer
> to keep Tomahawk  the defautl as it is now.
>
>>> 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"

+1
>
> This should be coordinated with  
> https://issues.apache.org/jira/browse/OFBIZ-4709
>
>>> O) framework/documents: move the content to Wiki and then move to
>>> "Attic"
>
> So get rid of the online help also?
online help is more efficient way to have end user help and sometime
existing feature boundary. In some customer project online help is using
to define what is operational or not, it's very convenient for business
Analyst and End user.

>
>>> P) framework/datafile: (who is currently using it?) move to
>>> "Extras"  or "Attic"; we could replace it with commons-csv or
>>> similar tool
>
> I second Adrian on datafile. Though I have not used it for years, it
> can be handy at any moment.
>
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>> Kind regards,
>>>
>>> Jacopo
>
> For the rest I agree
>
> Jacques
>

[Jacques Le Roux]

From: <[hidden email]>

> Quoting Jacques Le Roux <[hidden email]>:
>
>> Thanks for the proposition Jacopo,
>>
>> Inline...
>>
>> From: <[hidden email]>
>>> I think Example should stay in the framework, but get rid of all of
>>>  the "showroom" stuff that has been added to it. In other words,
>>> keep  it and return it to its original purpose - a very basic
>>> component for  new users to understand OFBiz.
>>
>> I agree notably the forms page
>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>
> Form widget examples, Ajax examples, Portal examples, JCR examples,
> etc. All of it. This was supposed to be a stripped down application
> that would not overwhelm a new user.

I think I misread and thought Jacopo suggested to put them in Extra. Finally, no pb with me as long as they stay in specialpurpose:
ie users have an obvious acces to it.

So you would only keep the main page (ie https://demo-trunk.ofbiz.apache.org/example/control/main)?
Why not put all in specialpurpose? It would be more clear than having things separated.

Jacques

> -Adrian
>
>

[Adrian Crum-3]

Here is what I am suggesting:

1. Keep the Example component in the framework folder.
2. Return the Example component to its original purpose: A stripped  
down, very basic application for a new user to evaluate and  
understand. That would require removing all of the things that have  
been added that have nothing to do with the original purpose - like  
Ajax examples, form widgets examples, portal page examples, JCR  
examples, etc.

-Adrian


Quoting Jacques Le Roux <[hidden email]>:

> From: <[hidden email]>
>> Quoting Jacques Le Roux <[hidden email]>:
>>
>>> Thanks for the proposition Jacopo,
>>>
>>> Inline...
>>>
>>> From: <[hidden email]>
>>>> I think Example should stay in the framework, but get rid of all of
>>>> the "showroom" stuff that has been added to it. In other words,
>>>> keep  it and return it to its original purpose - a very basic
>>>> component for  new users to understand OFBiz.
>>>
>>> I agree notably the forms page
>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>
>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>> etc. All of it. This was supposed to be a stripped down application
>> that would not overwhelm a new user.
>
> I think I misread and thought Jacopo suggested to put them in Extra.  
> Finally, no pb with me as long as they stay in specialpurpose: ie  
> users have an obvious acces to it.
>
> So you would only keep the main page (ie  
> https://demo-trunk.ofbiz.apache.org/example/control/main)?
> Why not put all in specialpurpose? It would be more clear than  
> having things separated.
>
> Jacques
>
>> -Adrian
>>
>>
>

[Mansour]

Jacopo,
thank you for opening this subject. I agree with you on everything.
I started few days ago, cleaning ofbiz on my local machine
restructuring as I go. I am new to the internals of the framework, and
doing this as an exercise.

Stuck on the few things but that's another post. The bottom line, I
agree with you about cleaning and losing some weight.

and by the way, thank you for removing Webslinger.


On Sun, Mar 18, 2012 at 9:43 AM,  <[hidden email]> wrote:

> Here is what I am suggesting:
>
> 1. Keep the Example component in the framework folder.
> 2. Return the Example component to its original purpose: A stripped down,
> very basic application for a new user to evaluate and understand. That would
> require removing all of the things that have been added that have nothing to
> do with the original purpose - like Ajax examples, form widgets examples,
> portal page examples, JCR examples, etc.
>
> -Adrian
>
>
>
> Quoting Jacques Le Roux <[hidden email]>:
>
>> From: <[hidden email]>
>>>
>>> Quoting Jacques Le Roux <[hidden email]>:
>>>
>>>> Thanks for the proposition Jacopo,
>>>>
>>>> Inline...
>>>>
>>>> From: <[hidden email]>
>>>>>
>>>>> I think Example should stay in the framework, but get rid of all of
>>>>> the "showroom" stuff that has been added to it. In other words,
>>>>> keep  it and return it to its original purpose - a very basic
>>>>> component for  new users to understand OFBiz.
>>>>
>>>>
>>>> I agree notably the forms page
>>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>>
>>>
>>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>>> etc. All of it. This was supposed to be a stripped down application
>>> that would not overwhelm a new user.
>>
>>
>> I think I misread and thought Jacopo suggested to put them in Extra.
>> Finally, no pb with me as long as they stay in specialpurpose: ie users have
>> an obvious acces to it.
>>
>> So you would only keep the main page (ie
>> https://demo-trunk.ofbiz.apache.org/example/control/main)?
>> Why not put all in specialpurpose? It would be more clear than having
>> things separated.
>>
>> Jacques
>>
>>> -Adrian
>>>
>>>
>>
>
>
>

[Olivier.heintz]

Le 18/03/2012 14:43, [hidden email] a écrit :
> Here is what I am suggesting:
>
> 1. Keep the Example component in the framework folder.
> 2. Return the Example component to its original purpose: A stripped
> down, very basic application for a new user to evaluate and
> understand. That would require removing all of the things that have
> been added that have nothing to do with the original purpose - like
> Ajax examples, form widgets examples, portal page examples, JCR
> examples, etc.
In my understanding, example contain a example of each developing
current valid method to help new developer to see an example of each.
If it's not in example, these examples  should be move to exampleext in
extra

>
> -Adrian
>
>
> Quoting Jacques Le Roux <[hidden email]>:
>
>> From: <[hidden email]>
>>> Quoting Jacques Le Roux <[hidden email]>:
>>>
>>>> Thanks for the proposition Jacopo,
>>>>
>>>> Inline...
>>>>
>>>> From: <[hidden email]>
>>>>> I think Example should stay in the framework, but get rid of all of
>>>>> the "showroom" stuff that has been added to it. In other words,
>>>>> keep  it and return it to its original purpose - a very basic
>>>>> component for  new users to understand OFBiz.
>>>>
>>>> I agree notably the forms page
>>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>>
>>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>>> etc. All of it. This was supposed to be a stripped down application
>>> that would not overwhelm a new user.
>>
>> I think I misread and thought Jacopo suggested to put them in Extra.
>> Finally, no pb with me as long as they stay in specialpurpose: ie
>> users have an obvious acces to it.
>>
>> So you would only keep the main page (ie
>> https://demo-trunk.ofbiz.apache.org/example/control/main)?
>> Why not put all in specialpurpose? It would be more clear than having
>> things separated.
>>
>> Jacques
>>
>>> -Adrian
>>>
>>>
>>
>
>
>
>

[Jacopo Cappellato-4]

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
>>
>

[Jacques Le Roux]

From: "Olivier Heintz" <[hidden email]>

> Le 18/03/2012 14:43, [hidden email] a écrit :
>> Here is what I am suggesting:
>>
>> 1. Keep the Example component in the framework folder.
>> 2. Return the Example component to its original purpose: A stripped down, very basic application for a new user to evaluate and
>> understand. That would require removing all of the things that have been added that have nothing to do with the original
>> purpose - like Ajax examples, form widgets examples, portal page examples, JCR examples, etc.
> In my understanding, example contain a example of each developing current valid method to help new developer to see an example of
> each.
> If it's not in example, these examples  should be move to exampleext in extra

I'd prefer to keep exampleext (or whatever it's names) in specialpurpose rather for 2 reasons
1. Easy access for new users but not bloating framework
2. I sometimes use the form widget page in demo trunk when testing things, having it in specialpurpose would be easier than extra

Jacques

>>
>> -Adrian
>>
>>
>> Quoting Jacques Le Roux <[hidden email]>:
>>
>>> From: <[hidden email]>
>>>> Quoting Jacques Le Roux <[hidden email]>:
>>>>
>>>>> Thanks for the proposition Jacopo,
>>>>>
>>>>> Inline...
>>>>>
>>>>> From: <[hidden email]>
>>>>>> I think Example should stay in the framework, but get rid of all of
>>>>>> the "showroom" stuff that has been added to it. In other words,
>>>>>> keep  it and return it to its original purpose - a very basic
>>>>>> component for  new users to understand OFBiz.
>>>>>
>>>>> I agree notably the forms page
>>>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>>>
>>>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>>>> etc. All of it. This was supposed to be a stripped down application
>>>> that would not overwhelm a new user.
>>>
>>> I think I misread and thought Jacopo suggested to put them in Extra. Finally, no pb with me as long as they stay in
>>> specialpurpose: ie users have an obvious acces to it.
>>>
>>> So you would only keep the main page (ie https://demo-trunk.ofbiz.apache.org/example/control/main)?
>>> Why not put all in specialpurpose? It would be more clear than having things separated.
>>>
>>> Jacques
>>>
>>>> -Adrian
>>>>
>>>>
>>>
>>
>>
>>
>>
>

[Jacopo Cappellato-4]

On Mar 18, 2012, at 1:05 PM, Jacques Le Roux wrote:

>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>
> So get rid of the online help also?

We can keep the online help (we can maybe review the implementation of the mechanism... and the content itself really needs some serious review) if there is a general interest; however it shouldn't stay in the framework... commonext would be a better fit (and yes I think it is acceptable to not have the online help for webtools and example, if example will stay in the framework).

Jacopo

[Jacques Le Roux]

From: "Olivier Heintz" <[hidden email]>
>> Le 18/03/2012 13:05, Jacques Le Roux a écrit :
>> Quoting Jacopo Cappellato <[hidden email]>:

>>> O) framework/documents: move the content to Wiki and then move to "Attic"

>> So get rid of the online help also?

> online help is more efficient way to have end user help and sometime existing feature boundary. In some customer project online
> help is using to define what is operational or not, it's very convenient for business Analyst and End user.

Yes that's why I asked this question. I don't use the online help but it seems something interesting to me, not sure if/how users
are using it...

Jacques

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>

> On Mar 18, 2012, at 1:05 PM, Jacques Le Roux wrote:
>
>>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>
>> So get rid of the online help also?
>
> We can keep the online help (we can maybe review the implementation of the mechanism... and the content itself really needs some
> serious review) if there is a general interest; however it shouldn't stay in the framework... commonext would be a better fit (and
> yes I think it is acceptable to not have the online help for webtools and example, if example will stay in the framework).
>
> Jacopo

excerpts:
>we can maybe review the implementation of the mechanism...

Yes there are documents folders also under some framework components...

>and the content itself really needs some serious review

That's the trap with help, comments in codes, etc. : it really needs to stay up to date...


> I think it is acceptable to not have the online help for webtools and example, if example will stay in the framework

I think there are none anyway (at least no help button there)

Jacques

[Scott Gray-2]

I agree with the concept completely.  I wonder though if each of the suggested changes should get their own thread rather than be discussed in this one, a thread with too many topics flying around is a little difficult to follow.  Or perhaps even just tackle each of these consecutively after an agreement on the course of action is reached and a volunteer to do the work is found then we could move on to the next suggestion?

Regards
Scott

On 18/03/2012, at 10: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
>

[Anne Jessel]

On 19 March 2012 07:15, Scott Gray <[hidden email]> wrote:

>   Or perhaps even just tackle each of these consecutively after an
> agreement on the course of action is reached and a volunteer to do the work
> is found then we could move on to the next suggestion?
>
>
+1

Basic ideas all look very good to me. IMO anything that is incomplete or
not maintained should be moved to Attic or Extras, unless there is a very
good reason for keeping it. The reason for moving it should be well
documented. That way it is obvious which code needs work. If someone wants
it, they can fix it and offer to maintain it, and then the community can
consider whether it is important enough to return.

Hopefully if non-committers can easily see what areas need work, they'll be
more likely to adopt some code.

Cheers,
Anne.

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Jacopo Cappellato-4]

On Mar 19, 2012, at 12:26 AM, Anne wrote:

> Basic ideas all look very good to me. IMO anything that is incomplete or
> not maintained should be moved to Attic or Extras, unless there is a very
> good reason for keeping it. The reason for moving it should be well
> documented. That way it is obvious which code needs work. If someone wants
> it, they can fix it and offer to maintain it, and then the community can
> consider whether it is important enough to return.
>
> Hopefully if non-committers can easily see what areas need work, they'll be
> more likely to adopt some code.
>
> Cheers,
> Anne.

Anne, I completely agree.
I actually see a few more areas of involvement/participation for the community in this cleanup effort:

1) when this discussion will be finalized, we will have a pretty clear roadmap of cleanup tasks to work one; we will then create Jira tasks for the agreed upon removals and community members (committers and non-committers) will have a chance to assign the tasks to them and help the community to implement the plan; this is really a "roadmap"

2) for components candidate to become projects in the Apache Extras (for OFBiz): we will need at least one project maintainer for each of them: this person doesn't necessarily have to be one of the existing OFBiz committers; I would actually like to see new persons show up and take the leadership; we could then delegate to them to write up (in their Apache Extras" project) the goals for the component (of course we will sync with them)

3) for components that will be simply removed (Attic): I agree about the need to document the status of the code at the time of the removal to give opportunity in the future to an interested person to get them and do some more work

Kind regards,

Jacopo

[Hans Bakker]

Hi Jacopo,

Thank you for the effort you spend with OFBiz the last few months. I
generally agree that sure we have to cut the dead wood in the system.
Components and functions which are not used or only halfway implemented
sure, sounds like a good idea to move them out.

However the reasons you list as 'high maintenance' i do not agree with.
Only with file changes there is work, otherwise it is pretty limited.
Removing half baked code sure, lets remove it.

The 'not complete' reasons do not apply to several applications and
functions you want to remove because they are complete, like asset
maintenance, LDAP, POS, e-commerce, cmssite(demo for the content
component perhaps better to integrate it with ecommerce), projectmgr and
scrum. Also moving the JCR function out is not a good idea however when
not improved in the next few months using the content manager, i would
agree to a removal.
Then I was even more surprised, because reporting is a pretty weak point
in OFBiz, to remove the Birt integration and data warehouse entities.
I cannot agree with the removal of these components, Birt integration
and JCR (in the short term)

Some other proposals:
1. I would like to push for more junit tests and use even this as a
measure to keep a component in the system or not. (cobertura minimum
percentage?)
2. To have a lead committer appointed for every component in the system
who will check incoming patches and will commit them, to relieve Jacques
of some work.
3. List functions/tasks with every committer, if a committer does not
have a function/task or is not active for a year, put him on the
emeritus list, if he gets active again put him back as a committer on
his request. This to get a real committers (and contributors, see next
point) list.
4. Also list contributors who have a function/task assigned either for
creating documents, reporting errors or supply patches, list the
contributions he/she did so we can keep up if he/she could be nominated
to be a committer.

Thanks again for your activity, keep up the good work!

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
>