David,
Sorry for the wrong attribution of OFBiz's management responsibility. The name "Undersun" just
stuck. I thought that's the "go-to guy" for OFBiz! In fact, I do watch you (or Undersun or Hotwax)
for directions in matters that might impact our "business viability with OFBiz". I still
unconsciously lump every contributor to you and company. Wrong, yes. Just convenient to refer to a
single entity, or just being lazy. Sorry. :P
I agree with the add-in components. But I encounter problems trying to make my individual projects
lean like add-in components. Quite a bit of the non-framework aspects of OFBiz are not generic
enough to render tweaks unnecessary, and those non-framework aspects are built into OFBiz like
they are core. OFBiz already has many mechanisms for "extensions coding (overriding, overloading,
etc)", to cleanly create add-in components, but some areas may still need to be developed further.
But I digress.
The forks and best-of-breeds strategy is for competition between implementations of complex core
functions. Often, it's hard to see in foresight what is the best way to go about a complex
function. The best way is to take a measured charge forward with SVN, and use cheaper hindsight to
guide us. Either that, or we get stuck with multiple camps arguing for opposing directions. The
typical "deep-thought-related team paralysis".
That said, the fact that "competition" is needed to hunt down the best of breed implementation
will bring in a whole suite of human problems. We've seen many fiefdoms in the open source arena
that simply don't match or merge. Few humans can lay down personal pride for greater good (so pat
yourselves on back, those of you who contribute to OFBiz!).
> So no, this would never work. There is no central organization to
> pull stuff into the project, just users to push stuff into the
> project. That's the WHOLE point of a community driven project that
> facilitates collaboration.
Yeah, I guess you're right. It would never work. The only platform where it'll work is with
private... erm... users, who do "pull best of breed stuff" into their private SVNs. Hindsight can
bring a lot of insight.
Anyway, I think I have beaten this "SVN tricks and acrobatics" topic to death before. I'm either
an undiscovered genius, or I'm doing something terribly wrong with SVN and such! Heh. Probably the
latter, since I'm still undiscovered.
Jonathon
David E Jones wrote:
Jonathon -- Improov wrote:
Ean,
I agree that the branch-explore-prune strategy is wickedly rapid, for
quick prototyping and cultivation of "best of breed" directions.
With multiple official/public OFBiz branches, each branch can be more
specialized to cater more tightly to particular user groups.
This would be done better with add-in components than with branches, or
forks, or intended branches that turn into forks.
For things that need to be changed in the OFBiz framework or base
applications patches should be submitted (or a committer working on it
should just put them in). These would tend to be smaller and go in more
quickly.
Then David or Undersun could oversee all the official branches, and
pick up best of breed ideas to be merged back into main OFBiz SVN.
Yes, they'll need more hires for this, possibly. And they are busy
enough already. Note that without this step, each fork will simply do
their own dances and end up duplicating each others' functionalities
over time. Wasteful.
Ummm... not sure where this idea came from...
Neither "David" nor "Undersun" (now part of Hotwax Media) nor any other
person or organization are some central source of resources or driving
force for the project. OFBiz is overseen by a PMC (project management
committee) but everything that goes into OFBiz is contributed by users.
So no, this would never work. There is no central organization to pull
stuff into the project, just users to push stuff into the project.
That's the WHOLE point of a community driven project that facilitates
collaboration.
Of course, this is also impossible with current forks like opentaps and
Neogia because they specifically structure their licensing and copyright
ownership so that it is impossible to bring the contributions back into
OFBiz.
Note that packaging of the forks is very important to facilitate easy
reconciliation! Ideally, each fork should only contain files that are
specialized, and not files that duplicate core OFBiz parts.
See the comments about components above.
Each fork manager should be responsible for removing specialized
components that have been merged back into main OFBiz SVN, to keep
forks lean.
Again this can be avoided by focusing on add-ons combined with patches
that go into OFBiz sooner and easier.
Personally, I have several forks by now, each catering to an
individual customer. I package the forks with this policy: "strictly
no duplication of core OFBiz". All my SVN repos are lean,
minimalistic, containing only specialized files. This makes it very
easy for me to update from OFBiz SVN (the Undersun one) to any of my
forks.
Ummm... there is no Undersun SVN except the pre-ASF SVN repo that is no
longer active. It's the Apache Software Foundation SVN server we use for
OFBiz.
I don't think people understand just how incorrect and harmful to the
project this sort of thought is. If it isn't community driven people and
organizations won't be as interested in contributing and the whole
project will fall apart. It's a vicious and damaging lie! For anyone
thinking this please check your facts and motives!
-David
Ean Schuessler wrote:
On Monday 10 September 2007 03:40:59 pm David E Jones wrote:
This seems different from what you described above with the Linux
kernel...
but I'm interested to hear more of how you think that would work
independent of what is going on with OFBiz and OFBiz derivatives
right now.
The way I look at it is that the open source project really has one
purpose: it allows different groups to collaborate and do things
together
that would be too difficult and expensive any group to really do on
their
own.
Hotwax is becoming one of the larger OFBiz-based consultancies (though
certainly not even close to the biggest), but even Hotwax is WAY too
small
to handle something the size and scope of OFBiz... like probably at
least
10 to 1 and perhaps a 100 to 1 level of magnitude difference.
The ASF repository is definitely not meant to be Hotwax only, and I
don't
see it as that at all. In fact, it worries me a LOT to see anyone say
something like that. I don't think it's even close to true either...
the
traffic in the mailing lists, issue tracker AND the SVN repository
all tell
a very different story!
IMO it's totally fine and normal for there to be local repos that
groups
maintain for their projects.
Whatever is done and however it's done the trick is how do you work
with
others? If you don't have processes and practices to participate in
a group
effort, then you're really not participating in the group...
OFBiz could greatly benefit from more contributors and committers,
and from
experience with this type of software it is difficult for
enthusiasts and
hobbyists to participate part-time, so the people doing stuff full-time
based on OFBiz are the most valuable to the project... and by
participating
in the project open the door to receive benefits that just aren't
possible
any other way! Collaboration really is the WHOLE point of an open
source
project, or to put it in ASF terms: communication is the key!
I may be overstating matters and its certainly a matter of
perception. I suppose I may just be grumpy because no one paid any
attention to my ProductRole patch (OFBIZ-1177).
Grand Hotwax cabal conspiracies aside, I think the point is cogent
that the project would benefit from the highly decentralized
development strategy implied by GIT/Mercurial. We are all going to
have different priorities about what should or shouldn't be done in
the project, everyone is capable of making mistakes and market forces
will (presumably) eventually direct users to whichever source base
provides the most value.
I think Si's development efforts are the starkest example currently
because their can be little doubt about the role of Open Source
Solutions in the OpenTaps repository. Being able to submit patches to
Si or OFBiz, but then later coordinate a merge between sourcebases
with, perhaps, some patches already applied on both sides would be a
real convenience.
