[OSGeo-Discuss] Are there any thoughts on how organisations canwork with OSGeo projects?

[Bruce.Bannerman at dpi.vic.gov.au]

Thanks to Frank, Puneet and Landon for your comments.




> <Puneet>  I guess you might be meaning specifically governmental 
organizations
> -- specifying what you mean by an organization would be necessary.


By organisation, I was inferring organisations that do not currently 
actively contribute. They could be public or private.



> <Frank>  There is always the fallback option of a fork if plans are too 
divergent
> but that should be a last option.  I think most projects are open to 
substantial
> new features that aren't the core teams priority if there is some 
assurance
> that the added parts will be maintained by the contributors, and are 
perhaps
> optional (plugins, etc).   Ultimately though, if a direction is strongly
> opposed by the core team, it may be a bad idea to proceed.


Agreed. Forking would not be desirable.

Plugins are a good idea, provided that the project's architecture and 
desired change will allow them.

If a proposal is strongly opposed, perhaps the communication attempt has 
failed. Regardless, it would not be a good idea to proceed.

I'd like to see proposals embraced by the relevant core team as a 
desirable enhancement.



> <Landon>  We are trying to hammer out a system of 
> benchmarks that can be used to determine when an official release 
> needs to be made.

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  ;-)  ) 


>  <Landon>  ... organization can always maintain there own 
> build. 

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.


> 
>  <Landon>  This would include things like minor bug fixes, 
documentation, user 
> interface consistency, code testing... I think every open source 
> project struggles with this. I can think of two solutions. Pay your 
> own programmers to tackle the tasks or pay other programmers to do 
> it for you. Often you will find you don't have to complete an entire
> task, just get the framework started and manage it. 
> 

Good point. This is often overlooked when talking about OS development.


> 
> Bruce wrote: "- Project based funding is typically focused on a 
> deliverable. The deliverable may well be an enhancement to an OSGeo 
> project. How can a development team get that enhancement accepted 
> into an OSGeo Project's code base in a timely manner? Can they be 
> confident that the enhancement would not be removed at a later 
> iteration of the OSGeo Project?"
> 
>  <Landon>  Here are some suggestions in this regard:
> 
> - Avoid giving the impression that you are out to hijack control of 
> the project.

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. 

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?



>  <Landon>  - Consider hiring a programmer already involved in the 
project to 
> act as your liaison or ambassador.
> - Make it clear your enhancement or improvement is being donated to 
> the community, that you are interested in maintaining it, and that 
> you are really making an effort to serve the needs of the community 
> while you meet you own needs or the needs of you client.
> 

Also good points. The requirement for maintenance is a prerequisite.


>  <Landon>  We could really do a better job of supporting third parties 
> interested in contributing to open source software. 

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.


Bruce.







Notice:
This email and any attachments may contain information that is personal, 
confidential, legally privileged and/or copyright.No part of it should be reproduced, 
adapted or communicated without the prior written consent of the copyright owner. 

It is the responsibility of the recipient to check for and remove viruses.
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.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20070928/b30a5b46/attachment-0002.html>