[OSGeo-Discuss] FOSS Packaging (was: Open Location Services)

[Sampson, David]

Hey Folks,

Noticed the discussion has moved onto packaging issues of FOSS...

Perhaps this link may be of interest from the Australian Government:
http://www.finance.gov.au/Publications/guide-to-open-source-software/app
endix-c-oss-packaging.html

Cheers

> -----Original Message-----
> From: discuss-bounces at lists.osgeo.org 
> [mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Jody Garnett
> Sent: Wednesday, November 04, 2009 21:50
> To: OSGeo Discussions
> Subject: Re: [OSGeo-Discuss] Open Location Services
> 
> <bruce.bannerman.osgeo at gmail.com> wrote:
> > Jody,
> >
> > Thanks for the walk through of the decision processes. It was very 
> > enlightening. Particularly what makes it into and stays within the 
> > code base of a successful project.
> >
> > I recall a number of vendor presentations that I've been to over 
> > recent years where an OS Advocate representing a company will 
> > 'guarantee' that any work that we [1] commissioned from them would 
> > make it into a project in perpetuity.
> 
> I trust the 'OS Advocate' already was aware of community 
> activity and interest in said features. I would check a 
> project road map and discussion lists to gauge interest.
> 
> > I could not see how that could work, as just because we may want a 
> > feature does not mean that the rest of the community will also want 
> > that same feature.
> 
> One of the bold moves GeoTools has done recently is create 
> the idea of an "unsupported" module in order to attract 
> investment. This provides a way for a potential contributor 
> (of say OpenLS) to take part and share their work with the 
> community; as a first step in attracting interest in 
> volunteers or funding to bring the code up the level required 
> to be included in the project.
> 
> So if an OpenLS implementation approached us today we would 
> have a much better story on how the could be involved and 
> eventually included in the library.
> - create an unsupported module; a project management 
> committee member would take on the overhead of walking the 
> contributor through these steps, setting up with svn, and 
> answer questions about the developers guide
> - unsupported modules are deployed nightly making the work 
> available to the public
> - when the module is ready to be supported it needs to meet 
> project standards for: IP review, minimal  documentation, 
> support via users list, test coverage, etc..
> 
> By breaking this in to sections we allow a module to take the 
> required time to get its act together; and try to share the 
> "packaging costs"
> Cameron referred to.
> 
> > Also a one off commission to develop some code, does not look after 
> > the ongoing maintenance release after release...
> 
> There are ways around this; as long as the cost includes; 
> cost for initial community outreach; teaming up with a member 
> of the community (in geotools we have module maintainers what 
> would be approached to review and accept the material); 
> ability to meet the documentation and quality assurance 
> levels required and so on.
> 
> Now while many of these things sounds like (and are) costs - 
> each one of these steps also represent value. A community 
> review costs maybe 3 days prep time; in trade you get 
> detailed feedback by the project steering committee. By the 
> same token the documentation and QA requirements are tangible 
> deliverables that can be delivered to the customer as well as 
> to the community.
> 
> It is an interesting balance.
> 
> Jody
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>