[OSGeo-Discuss] Are there any thoughts on how organisations canwork with OSGeo projects?
Bruce.Bannerman at dpi.vic.gov.au
Bruce.Bannerman at dpi.vic.gov.au
Thu Sep 27 17:18:26 PDT 2007
Thanks to Frank, Puneet and Landon for your comments.
> <Puneet> I guess you might be meaning specifically governmental
> -- 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
> but that should be a last option. I think most projects are open to
> new features that aren't the core teams priority if there is some
> that the added parts will be maintained by the contributors, and are
> 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
> <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
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,
> 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
> 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.
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...
More information about the Discuss