Bruce, I will add some of my own thoughts to those offered by Frank Wammerdam's. Please note that I agree with all of Frank's responses, which were excellent.
Bruce wrote: "What I have seen of OS projects over the last seven years or so is that they are typically run by a group of committed individuals who have a desire for a particular type of product. Focus is often on delivering a quality product that is released 'when it is ready' rather than to a marketing department's timeframe." I think this is an accurate analysis. Regular releases occur more frequently in proprietary software because you need an incentive for purchases of "upgrades". In open source software this pressure is absent. This can be a two-edged sword. On one side of the blade there is little incentive to "rush" buggy or incomplete code to the customer to satisfy a marketing schedule. One the other side of the sword open source projects can go a long way between "official" or public releases. We've been talking about this a little bit on the OpenJUMP mailing list. We are trying to hammer out a system of benchmarks that can be used to determine when an official release needs to be made. I'm not sure how much of an impact this issue would have on the situation being discussed. If there is some type of benchmark release system in place, and the contributing organizations want to see a release moved up, they can help reach the benchmarks. If this system doesn't work the organization can always maintain there own build. This is what some programmers do with OpenJUMP. Bruce wrote: "While there is often an end goal and a set of requirements for a release of a product, it is sometimes difficult to find people interested in spending their own time on the less exciting aspects of a project." 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. For example, an open source program might lack a good user manual. If you organization starts writing one, and sets up a system in which others can contribute content or make editorial suggestions, it may have a snowball effect. Most players in an open source project are very reluctant to duplicate efforts by starting their own pet project. In summary, it might be hard to get someone to write an entire user manual. It would be a lot easier to have them contribute a chapter if the framework is set up. This is just one example. 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?" Here are some suggestions in this regard: - Avoid giving the impression that you are out to hijack control of the project. - Communicate, communicate, communicate... - Maintain, maintain, maintain... - 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. We could really do a better job of supporting third parties interested in contributing to open source software. I once considered writing a short article with suggestions on how to do this, but decided not to do so after concerns about "scaring" potential contributors away from open source projects. Let me know if I can help with more suggestions. Landon ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 10:58 PM To: [email protected]; [EMAIL PROTECTED] Subject: [OSGeo-Discuss] Are there any thoughts on how organisations canwork with OSGeo projects? <sorry for cross posting> I have been involved in a number of discussions over the last year or so where people representing organisations have expressed an interest in extending Open Source spatial products and projects but are unsure or sceptical as to how it could be done. I'm interested in other people's thoughts on this. Overview: Typically in Government and other larger organisations, funding is Project based with a clear definition of business requirements, end deliverables and time frame. What I have seen of OS projects over the last seven years or so is that they are typically run by a group of committed individuals who have a desire for a particular type of product. Focus is often on delivering a quality product that is released 'when it is ready' rather than to a marketing department's timeframe. While there is often an end goal and a set of requirements for a release of a product, it is sometimes difficult to find people interested in spending their own time on the less exciting aspects of a project. For some context: #1 - I recently attended an workshop that contained representatives from a significant number of government departments from around Australia. There was a general consensus that we liked what we saw with GeoNetwork as a potential 'National' Metadata entry tool and Catalogue. There was also some discussion as to the types of features that we'd like to see developed longer term to support an 'Australian' metadata toolset. If this was to proceed we'd no doubt end up with a program of works that we'd like to see implemented. #2 - I have also been involved on the periphery of the GeoSciML efforts, part of which is a desire to use GeoServer to support GeoSciML and 'complex' objects. The GeoSciML work involves a number of Geological Survey organisations from around the world. This could also result in a program of works that people would like to see included into GeoServer. Some initial examples of issues that I can see (excluding funding) are: - Communication and liaison with the relevant open source community. We may have a block of work that we'd like to see developed, however this may potentially take a project in a direction that the community does not want to go in. How do we address this? - A shortage of developers with the required skills in a particular project. While we could put resources towards this problem, it will take time for the developers to get an understanding of the products and build the necessary credibility within the community. In the meantime, we have the problem of getting some early wins to ensure sufficient funding for the longer term. - Project based funding is typically focussed 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? - Where is the best place to discuss issues relating to a program of works that may span several OSGeo projects? + If the discussions were to take place on individual projects' development lists, then the overall 'Program' context may be lost. Also other OSGeo project developers may not be interested in the additional 'noise'. + In the first example above where it relates to a National program of works, it may be better to discuss these issues on the country's local chapter mailing list. At least this would still be visible to interested parties. + In the second example where it relates to an international program of works, perhaps a dedicated chapter could be established under OSGeo? + what would be the best way to coordinate the aims of a program of works and the aims of various OSGeo communities. I'm sure that others are thinking of these issues. They don't just relate to large programs of works, they also relate to smaller projects. Perhaps you would like to share your thoughts. 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. Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. _______________________________________________ Discuss mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/discuss
