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.
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.
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.
Each fork manager should be responsible for removing specialized components that have been merged
back into main OFBiz SVN, to keep forks lean.
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.
Nothing more than simple party tricks with SVN, really. But it all goes a long way to managing and
maintaining disparate projects.
Jonathon
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.
