On 20/04/2015 3:11 PM, David E. Jones wrote:
On 20 Apr 2015, at 11:35, Ron Wheeler <rwhee...@artifact-software.com> wrote:
Would Moqui become a sub-project of OFBiz with distinct deliverable with an
Apache license?
Or is that too much community?
IMO they are better as distinct projects. There is a chance Moqui Framework could become
a separate ASF project, though the name "Apache Moqui" is oddly contradictory
(I chose the name based on Moqui Marbles, but it is also another name for the Hopi
tribe). More seriously, these days I like the distributed and moderated approaches used
in the Linux kernel more than the community approach mandated by the ASF.
What would be the problem of it being part of OFBiz in the same way that
FOP and Batik are part of the XLMGraphics project or Jetspeed is part of
the Portals project.
A lot less work than a TLP but still benefiting from Apache.
Would not have to call of Apache Moqui. It would just be Moqui , part of
Apache OfBiz
As for community, regardless of the structure the various Moqui projects are now in a
good place for a bigger community and it is needed for more significant growth in the
projects. There are parallels to OFBiz which was mostly two people until around 2004-2005
when the project exploded (we had other contributors before then, but most not so
involved or enduring). Jacopo was the first really strong contributor in 2003, and
remains to this day! I'm still looking for a "Jacopo" for Moqui... heck, maybe
it'll be Jacopo. ;) (No pressure Jacopo: I know you're a busy man and doing fantastic and
important work elsewhere including OFBiz, Hotwax, and other projects you contribute to.)
As for licensing: the public domain "license" is even less restrictive than the Apache 2
license. The one thing that bothers me about the licensing approach, that I'll freely admit but
that I'm not sure how to handle better, is the explicit patent grant that is in the Apache 2
license (which made it incompatible with GPL2, though GPL3 has it too so it is
"compatible", ie no additional restrictions). In theory this shouldn't be a legal issue
because releasing it as public domain means giving up most IP rights, and there is the prior art
aspect of it too, but patent courts these days (at least in the USA) are awful and they don't seem
to care about prior art unless you pay a few million USD to lawyers along with substantial court
fees to get that recognized. In theory it shouldn't be an issue, not sure if it ever has been even
for Apache 2 licensed code, but it could be and in theory the terms in the Apache 2 license make it
cheaper to defend against patent claims (again in theory... chances are there would still be
significant, possibly bankrupting, legal fees to defend against such).
Being a part of an Apache project makes it harder to try to steal the IP
or claim ownership.
-David
On 20/04/2015 1:19 PM, David E. Jones wrote:
On 20 Apr 2015, at 02:24, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:
Le 20/04/2015 09:47, Adrian Crum a écrit :
Generally speaking, I am in favor of using another framework. I have two
reservations about Moqui:
1. It is controlled by a single person - so responsiveness to issues are
dependent on that person's availability.
This is indeed a regression from the current community sharing. On the other
hand a such change would not be done in one day, so we would have a long period
to experiment in parallel before possibly switching to Moqui.
I also guess in such cases David could open the Moqui to people he trusts. I
though wonder how this would be linked together. Nothing blocking but to be
seriously thought about, not only technically but legally. I know it's David's
will to share and he proved it already with OFBiz but the licensing aspect is
not clear to me http://www.moqui.org/#model.
With Moqui it's no secret that I chose the "code over community" route which is
certainly different from the ASF emphasis on community (and my emphasis on community and
collaboration from the beginning in OFBiz).
Moqui Framework is now pretty mature and I have sent out a couple of solicitations (in
the LinkedIn group) for more contributors, but I'm in no hurry to bring on other
committers/moderators... better to wait until clearly interested and capable people come
along. The infrastructure is in place for this on GitHub, ie the main repo is under the
"moqui" group and not my personal account any more so it is easy to add others
to that group with permission for particular repositories (ie moqui vs mantle, HiveMind,
etc).
Part of the reason I'm less worried about this is the different model for source
management that Git makes possible and GitHub makes easy. In other words, the magic of
distributed source management. Distributed source management and the moderator model make
it possible for "forks" to exist that have variations on the main code base
that are available for all and pulled into the main code base by moderators. You don't
have to be a moderator to contribute, or even share your code with the world.
The whole distributed source and moderator model is very different from the
community model in OFBiz, and overall better for some things and worse for
others. Many big projects use this model, including the Linux kernel which is
probably the biggest and the use of this model for the Linux kernel is exactly
where git came from.
My guess is that if OFBiz started using Moqui Framework one or more current
OFBiz committers would become moderators with commit access to the main Moqui
Framework repository.
2. It repeats a lot of mistakes that have been made in OFBiz, so those things
will need to be fixed again in Moqui after we bring it on board.
Indeed, a lot of fixes have been done recently in OFBiz which is battle tested
for years. Moqui though certainly well done, is still young and we would need
to compare them, point by point.
I'd love to hear more detail on this. I know one criticism in the past from
Adrian is Moqui's approach to object type conversions, especially in the Entity
Facade (the part of Moqui similar to the OFBiz Entity Engine). In some parts of
Moqui, like for service parameters, it uses the Groovy type conversion which is
pretty good but isn't a pluggable type conversion framework as I'm sure Adrian
would like to see... but that honestly I still have yet to find a need for.
On the entity level I prefer the current approach, mostly for performance
reasons. In recent changes to the framework for performance improvements (which
were significant... Moqui now getting around 15,000 entity ops per second as
opposed to 3,000 before the latest changes, and close to 300 in the original
version of Moqui though that was on an older laptop/etc and before ANY
optimizations where done). This does limit the types available for entity
fields, but is that really an issue? You're going to a database through JDBC,
and really just the least common denominator of types available in databases to
cleanly run on various ones, so there aren't many options in the first place!
We can take advantage of that for simpler code and better performance.
Neither one is a show-stopper for me.
Same here, just cautious.
Caution is good in this case... to be honest I'm not sure using Moqui Framework
in OFBiz is a good idea (as I've mentioned before), will write more on that in
another reply.
-David
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102