<br><font size=2 face="sans-serif">IMO:</font>
<br><font size=2 face="sans-serif"><br>
</font><font size=2><tt>Thanks Landon and Puneet,</tt></font>
<br>
<br>
<br><font size=2><tt>In this case, I tend to agree with Jeroen.</tt></font>
<br>
<br><font size=2><tt>There is a community developing GeoNetwork (and other
projects) with ongoing work occuring.</tt></font>
<br>
<br><font size=2><tt>This would be occurring concurrently with our development
work on a fork.</tt></font>
<br>
<br>
<br><font size=2><tt>We would want to be able to take advantage of the
new developments that others make to the parent project, without having
to refactor our 'fork' each time, or conversly, the additional work of
refactoring our customisations, or part there of back to the parent project.</tt></font>
<br>
<br>
<br><font size=2><tt>We (the Australian ANZLIC community) have tried this
approach already with the GeoNetwork ANZLIC Profile, and it is clearly
not working (despite might I add the outstanding efforts of the main developer).</tt></font>
<br>
<br>
<br><font size=2><tt>I think that the only sane approach is to work within
the parent project's community as peer participants.</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>I do agree with Puneet that the *ability* to fork
a project is critical to the success of open source projects, however I
think that it should really only be used as a last resort if a situation
is clearly unsalvagable. There is too much dilution of effort otherwise.</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>Bruce Bannerman </tt></font>
<br>
<br><font size=2><tt><br>
</tt></font>
<br><font size=2><tt><br>
> Bruce,</tt></font>
<br><font size=2><tt>> </tt></font>
<br><font size=2><tt>> I agree with Puneet. In this scenario it would
make more sense for <br>
> the organization to maintain their own fork of the code to which <br>
> improvements can be made. This really doesn’t cause problems for
the<br>
> parent of the fork as long as there is an established process and
<br>
> some honest effort made to integrate the best of the improvements
<br>
> back into the parent code base.</tt></font>
<br><font size=2><tt>> </tt></font>
<br><font size=2><tt>> This is actually how OpenJUMP works. There are
only a handful of <br>
> developers that actually work on the parent code base. Most of our
<br>
> contributors maintain their own fork, but siphon back improvements
<br>
> to the parent.</tt></font>
<br><font size=2><tt>> </tt></font>
<br><font size=2><tt>> Landon</tt></font>
<br><font size=2><tt>> </tt></font>
<br>
<SMx
j["퍢{N51N5;-W