[OSGeo-Discuss] Open Location Services

Wed Nov 4 17:16:58 PST 2009

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 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.

Also a one off commission to develop some code, does not look after the
ongoing maintenance release after release...

Thanks for sharing.

Bruce

[1] ('we' meaning several organisations that I've been at in the past)

>
>
> > -----Original Message-----
> > From: discuss-bounces at lists.osgeo.org
> > [mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Jody Garnett
> > Sent: Thursday, 5 November 2009 11:57 AM
> > To: punkish at eidesis.org; OSGeo Discussions
> > Subject: Re: [OSGeo-Discuss] Open Location Services
> >
> > > The above makes sense, but honestly, I had never heard of
> > this until
> > > now, and I have been tinkering with open source for almost a decade
> > > now. Most open source projects seemed organic to me. Someone had an
> > > itch, they scratched it, they put it out, and the project either
> > > gathered traction, or it died. Seems like my scholarship of open
> > > source has been lacking in this aspect hugely.
> >
> > You will notice that I expressed the same concern from the
> > other side of the street. When GeoTools is approached by a
> > private company with functionality to "donate" we are often
> > forced to say no.
> >
> > A couple of examples:
> > - the jts-wrapper module was developed in 2004 offering ISO
> > 19107 api wraped around the jts library. We accepted the
> > library as an unsupported module in 2005, taking the time to
> > add it to our build etc
> >  - and nothing has happened with it. As a result we will
> > shortly be removing it.
> > - OpenLS was offered but without community resources; or any
> > requests from our user list asking for the functionality; we
> > were forced to say no
> > - the geometry module is a full fork of jts backed on to ISO
> > 19107 api. Developed by a grad student and donated to the
> > library; this time the university was on hand to help adding
> > it to the build; and commercial funding was received to
> > document the result. Still without an active maintainer
> > uptake has been low and we will be removing it.
> >
> > > I wonder if I can find out the "packaging costs" of other projects,
> > > for example, what was the packaging cost for MapServer, or
> > GeoServer,
> > > or OpenLayers, or Perl/Python, etc.
> >
> > These situations are often slightly different in that open
> > source was used as venue to enable collaboration between
> > several interested parties. In the case of OpenLS we don't
> > have any interested parties.
> >
> > > Is this routine practice, or is this a consideration only when a
> > > private company wants to put its code into open source?
> >
> > The cost of making code open source is measured in volunteer
> > time; either someone such as yourself who is interested in
> > the functionality; or an organisation paying their employees
> > to do the work.
> >
> > Phrased another way a private company can benefit from making
> > its code open source if it can attract a larger user
> > community to cut down on testing costs.
> >
> > I recently "ran" these numbers for GeoServer. It costs
> > LISAsoft a couple of days time to release the most recent
> > GeoServer (thanks to LISAsoft for allowing us to take part!).
> >
> > In trade we got back around 4-5 useful bug reports. I figure
> > each bug report represents someone downloading; installing;
> > configuring (1-2
> > hours) and then taking the time to write a bug report; for a
> > useful bug report that will take 1 hour).
> >
> > So 4 reports; 3 hours each = 12 hours. It took 16 hours to
> > make the release - so from the standpoint of time saving it
> > would of been cheaper for us to just do the testing ourselves.
> >
> > Now I am sure many more people downloaded and tried out the
> > application; but if they did not report a bug the community
> > is not benefiting from the release. We depend on this in
> > order to maintain open-source's reputation for quality. The
> > number of bug reports against GeoServer 2.0 vs the RC issued
> > the week before really highlights the need to talk about this
> > relationship between open source projects and the value of testing.
> >
> > > Another question -- if you don't put the code into open source, are
> > > you somehow recouping this cost? In other words, does
> > putting the code
> > > into open source have any opportunity costs? Asked another
> > way, if you
> > > did just "dump the code into sourceforge," besides the potentially
> > > legitimate worry that the project might just die, would you
> > incur any
> > > other cost?
> >
> > I don't think as professionals we could just dump the code on
> > source forge; it would harm our reputation.
> >
> > > No, I don't have any sponsor. I am a rather indigent
> > > academic/developer/activist with barely funds to keep
> > myself afloat. I
> > > am, however, still very curious about the magnitude of these
> > > "packaging" costs. What are we talking about here? A few hundred, a
> > > few thousand, a few tens of thousands, say, Euros (considering even
> > > Kanye West doesn't want greenbacks anymore). You say above, "we can
> > > look into it further." Does that imply that you haven't yet
> > calculated
> > > these packaging costs, but have a sense that they might be
> > > substantial?
> >
> > It may also be measured in terms of man hours; we could make
> > a copy of the code available to your organisation under an
> > open source license (but that would not be the same as an
> > open source project that you could take part in).
> >
> > This is some times seen as the difference between "open
> > source" and "open development". OSGeo is focused on an open
> > development model; we take pains to ask projects to document
> > their decision making process and how new organisations and
> > members can take part.
> >
> > > At the very least, because of this thread, I have now been
> > made aware
> > > of a potential aspect of open source about which I had
> > absolutely no
> > > idea until now.
> >
> > Don't get hung up on the phrase "packaging costs"; instead
> > focus on the larger picture of the community that forms
> > around a project and what it takes to make that relationship
> > healthy (each party needs to get a benefit out of it that is
> > more then they are putting in etc...).
> >
> > Regards,
> > Jody
> > _______________________________________________
> > Discuss mailing list
> > Discuss at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/discuss
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20091105/d880d87c/attachment-0002.html>