<br><font size=2 face="sans-serif">Thanks to Frank, Puneet and Landon for
your comments.<br>
</font>
<br>
<br>
<br><font size=2><tt><br>
> <Puneet> I guess you might be meaning specifically governmental
organizations<br>
> -- specifying what you mean by an organization would be necessary.<br>
<br>
</tt></font>
<br><font size=2><tt>By organisation, I was inferring organisations that
do not currently actively contribute. They could be public or private.</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>> <Frank> There is always the fallback
option of a fork if plans are too divergent<br>
> but that should be a last option. I think most projects are
open to substantial<br>
> new features that aren't the core teams priority if there is some
assurance<br>
> that the added parts will be maintained by the contributors, and are
perhaps<br>
> optional (plugins, etc). Ultimately though, if a direction
is strongly<br>
> opposed by the core team, it may be a bad idea to proceed.</tt></font>
<br>
<br>
<br><font size=2><tt>Agreed. Forking would not be desirable.</tt></font>
<br>
<br><font size=2><tt>Plugins are a good idea, provided that the project's
architecture and desired change will allow them.</tt></font>
<br>
<br><font size=2><tt>If a proposal is strongly opposed, perhaps the communication
attempt has failed. Regardless, it would not be a good idea to proceed.</tt></font>
<br>
<br><font size=2><tt>I'd like to see proposals embraced by the relevant
core team as a desirable enhancement.</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>> <Landon> We are trying to hammer
out a system of <br>
> benchmarks that can be used to determine when an official release
<br>
> needs to be made.</tt></font>
<br>
<br><font size=2><tt>The Ubuntu team seem to be establishing a fairly good
compromise of ~six monthly release cycles with ongoing security and critical
bug fixes rolled out automatically as required (of course it helps that
they are based on the Debian distribution ;-) ) </tt></font>
<br>
<br>
<br><font size=2><tt>> <Landon> ... organization can
always maintain there own <br>
> build. </tt></font>
<br>
<br><font size=2><tt>Yes, though as a project progresses through iterative
releases, this may be increasingly more difficult to maintain. I like Frank's
idea of using a plugin approach, though this may not always be possible.</tt></font>
<br>
<br>
<br><font size=2><tt>> <br>
> <Landon> This would include things like minor bug
fixes, documentation, user <br>
> interface consistency, code testing... I think every open source <br>
> project struggles with this. I can think of two solutions. Pay your
<br>
> own programmers to tackle the tasks or pay other programmers to do
<br>
> it for you. Often you will find you don't have to complete an entire<br>
> task, just get the framework started and manage it. <br>
> </tt></font>
<br>
<br><font size=2><tt>Good point. This is often overlooked when talking
about OS development.</tt></font>
<br>
<br>
<br><font size=2><tt>> <br>
> Bruce wrote: "- Project based funding is typically focused on
a <br>
> deliverable. The deliverable may well be an enhancement to an OSGeo
<br>
> project. How can a development team get that enhancement accepted
<br>
> into an OSGeo Project's code base in a timely manner? Can they be
<br>
> confident that the enhancement would not be removed at a later <br>
> iteration of the OSGeo Project?"<br>
> <br>
> <Landon> Here are some suggestions in this regard:<br>
> <br>
> - Avoid giving the impression that you are out to hijack control of
<br>
> the project.</tt></font>
<br>
<br><font size=2><tt>This is an excellent point. I would not like to see
this occur. However it is a real danger that any OS project could face
if enough developers with a specific agenda get involved. </tt></font>
<br>
<br><font size=2><tt>I would hope that OSGeo as an umbrella organisation
would have a part to play to stamp out such undesirable activity. Does
OSGeo have a redress process that can be used in such cases?</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>> <Landon> - Consider hiring
a programmer already involved in the project to <br>
> act as your liaison or ambassador.<br>
> - Make it clear your enhancement or improvement is being donated to
<br>
> the community, that you are interested in maintaining it, and that
<br>
> you are really making an effort to serve the needs of the community
<br>
> while you meet you own needs or the needs of you client.<br>
> </tt></font>
<br>
<br><font size=2><tt>Also good points. The requirement for maintenance
is a prerequisite.</tt></font>
<br>
<br><font size=2><tt><br>
> <Landon> We could really do a better job of supporting
third parties <br>
> interested in contributing to open source software. <br>
<br>
Agreed. While people experienced with OS may have an idea as to where to
start, it can be quite daunting for people in organisations used to traditional
methodology to know where to start and have confidence that they will be
able to get a result.</tt></font>
<br>
<br>
<br><font size=2><tt>Bruce.</tt></font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<P><FONT face=Arial size=2>Notice:</FONT><FONT
style="BACKGROUND-COLOR: #ff0000"><BR></FONT><FONT size=2><FONT face=Arial>This
email and any attachments may contain information that is personal,
confidential,<BR>legally privileged and/or copyright.</FONT> <FONT face=Arial>No
part of it should be reproduced, adapted or communicated </FONT><FONT
face=Arial>without the prior written consent of the copyright owner.
</FONT></FONT></P>
<P><FONT size=2><FONT face=Arial>It is the responsibility of the recipient to
check for and remove viruses.</FONT></FONT></P>
<P><FONT face=Arial size=2>If you have received this email in error, please
notify the sender by return email, delete it from your system and destroy any
copies. You are not authorised to use, communicate or rely on the information
contained in this email.</FONT></P>
<P><FONT face=Arial color=#008000 size=2>Please consider the environment before
printing this email.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P> </P>
<P> </P>