Hi Jacopo,
Interesting discussion :)
Like you said, the selected solution will have all the features we need.
At this time Apache OFBiz offering a great functional framework with
technical interface, this allows to functional developer to stay focused
on their needsand don't waste on technical problem. It's really
important to don't lose it.
My feedback between Neogia and OFBiz (since we have in the same case
that choice 3) and 4))
* Fork : easier to improve the framework, but really difficult to back
improvements to original project. Many waste time to realize
improvement in parallel. I don't recommend it
* Synchronize by repository : import a external framework release,
provides flexibility to update the external source and show own
improvement. But with time past, the differences grow, increasing the
synchro time and decreasing the back improvement quality. We stop this
solution there are two years.
* At this time, with develop addon manager system to separate each
improvement on dedicate addon. This simplify the synchronization with
external source, keep back improvement quality. We lost in commit
celerit, it's a little more complicated to improve an addon than only
commit in a repository.
Whatever solution, I am available to help you.
Nicolas
Le 02/03/2012 09:28, Jacopo Cappellato a écrit :
On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:
Jacopo,
You would even consider forking?
From Wikipedia [*]:
"[...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of
the term "fork", blurring the distinction with "branch". With a DVCS such as Mercurial or
Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your
changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS
hosting expressly supporting independent branches, such that the technical, social and financial barriers to
forking a source code repository are massively reduced."
In order of preference (descending), here are the options I see for the future
of the OFBiz framework:
1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then
release it separately from the Apache OFBiz ERP
2) greatly clean up and improve the existing framework (I was not sure if this
could go at #1)
3) if the above will not be possible (frankly speaking, in the committers
group, apart from David, none of us ever implemented with success an open
source framework) we should also consider to drop the existing code and have
our community focusing on the ERP part (as Hans seems to advocate); at this
point Moqui would be the most natural choice; if we will ever go with this path
a great exchange of information will have to happen between the two projects:
for example OFBiz will probably have to ask the Moqui framework to evolve some
of its features; given the current nature of the Moqui project, I doubt that
the OFBiz committers will be ever invited as committers there; if Moqui will be
our choice, I see two possibilities:
3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be
possible if Moqui release will have all the features we need (and if Moqui
community will be interested in getting contribution to evolve in the direction
required by OFBzi)
3.b) if 3.a will not be possible because OFBiz will need some features that Moqui
community will not consider as a good fit for Moqui, then, under the guidance and bless
of David, we could work on a fork: get the code from a Moqui release, import in our
repository and add to it, in a controlled way, the features we need; of course this
should be always kept as close as possible to the original code; we could synch our
custom code with every new Moqui release; I was not thinking about *stealing* code to
Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in
the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it
will be still an ugly solution but for example when you said: "My proposal is that
Apache OFBiz will be in the future just the ERP system based on many opensource products
like birt and also Moqui...." you are actually implying that the ERP applications
will be able to use Birt... but this requires some sort of framework and what would you
do if Moqui will not think that Birt is a good fit for them?
4) if Moqui will not be a good option we may consider other frameworks (?), but
it will be difficult, or continue with what we have
Jacopo
[*]: http://en.wikipedia.org/wiki/Fork_(software_development)
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
