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
