[OSGeo-Discuss] Open Location Services

[Jody Garnett]

<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