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.
