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