<div dir="ltr"><div><div>Thanks to all who contributed for your thoughts. <br><br></div>I think that Andrea and Jody hit the nail on the head with their summaries:<br><br></div>i.e. from Andrea:<br><br>"<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt">Generally speaking I would not put the question in terms of "how much commercial <br>
involvement there is", but more of "is there a set of rules that are equals for everybody,<br>
and that allow new contributors to raise their rank up to PSC level if their work qualifies<br>
them to get there?".<br>
Also the community should be sane and lively, in particular if the eventual company<br>
that released the software to open source moves on and stops actively contributing to the project,<br>
its control position should diminish accordingly, going from active PSC member to<br>
emeritus. In other terms, "we are very grateful for your past work, but today you're not relevant<br>
anymore".</span></font>
"<br><div><div><div><br></div><div>i.e from Jody:<br><br><span>"The only exception to this is during incubation (when we have
a mentor available to answer questions) and some specific checks
to perform (check the IP, check that the license is open, check
that the development process is open to outsiders)."<br><br>=======<br><br></span></div><div><span>Therefore to summarise:<br><br></span></div><div><span>OSGeo, through the Incubation process seeks to ensure that graduated OSGeo projects:<br>
<br></span></div><div><span>* </span><span>are </span><span>open for contributions from interested developers.<br></span></div><div><span>* have an open process for evaluating contributions and deciding what proposed change goes into each version.<br>
</span></div><div><span>* have an open project governance structure, where any developer can be selected to become involved in PSC or <br> similar through their interest, project performance and merit.<br></span></div><div>
<span>* are not controlled by a single entity.<br><br>=======<br><br><br><br></span></div><div><span>Again quoting Jody:<br><br>"</span><span><span>If the
project does not have a useful model for commercial involvement
I would expect it to suffer, if it does not have a useful model
for community engagement (say the original JUMP) I would expect
it to fail (or be forked).</span>"<br></span></div><div><span><br></span></div><div><br></div><div>Are there any comments on my summary above?<br><br></div><div>Bruce<br></div><div><br><br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 10:56 AM, Jody Garnett <span dir="ltr"><<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
I think the MapGuide and FDO projects went through a similar story - with the community duplicating functionality. I wonder if we have a representative who can talk us through how that worked out? This would only be for interest sake, as we may be able to learn from their experience.
</div><div><br></div><div>Duplication does happen: for GeoServer we have two implementations of netCDF support on the horizon. We depend on our architecture, and project policies, to allow two "community plugins" to be developed by different teams. While we can encourage developers to work together it is VERY rare for it happen (as each has different sponsors, goals and deadlines).</div>
<div><br></div><div>While I hate to see duplicated effort, it is completely understandable.</div><span class=""><font color="#888888"><div>-- </div><div><div>Jody Garnett<br></div><div><br></div></div></font></span><div class="">
<div class="h5">
<p style="color:rgb(160,160,168)">On Friday, 8 March 2013 at 10:37 AM, Peter Baumann wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div>
<div>Hi all,<br>
<br>
allow me to chime in. First, thanks to Bruce for abstracting from
the case by fleshing out these variations, and to all for your
thoughts!<br>
<br>
I'm pretty much in line that #4 is not very desirable, although
I'm not sure OSGeo should influence - I understand OSGeo more as a
project quality check, but not as project hypervisor. Usually
community is quite aware and the situation probably would
self-regulate. <br>
<br>
Actually, in the concrete case at hand the question was different
even from scenario #4, aka: Should OSGeo actively encourage
contributors in dual-license projects to clone commercial
functionality? On a side note, in the case on hand the commercial
player is a key contributor to the open-source version, as the
commit logs convey; this may or may not be relevant.<br>
<br>
Of course this situation was not planned, it just surfaced the
potential issue by coincidence. Consequently, I see no particular
severity in it, just a useful discussion. My personal preference?
Coexistence.<br>
<br>
-Peter<br>
<br>
<br>
<br>
On 03/07/2013 11:52 PM, Jody Garnett wrote:<br>
</div><blockquote type="cite"><div>
<div> OSGeo does not tend to have policies with respect to our
projects - the organisation is driven by its goals and does its
best be "hands off". </div>
<div><br>
</div>
<div>The only exception to this is during incubation (when we have
a mentor available to answer questions) and some specific checks
to perform (check the IP, check that the license is open, check
that the development process is open to outsiders).</div>
<div><br>
</div>
<div>In this respect we are trying to do all the research that an
"contributor" would require before participating in a project …
and ensure each OSGeo project is in position to handle new
contributors. </div>
<div><br>
</div>
<div>We have never been involved in the business model supporting
the project, and any related commercial considerations. If the
project does not have a useful model for commercial involvement
I would expect it to suffer, if it does not have a useful model
for community engagement (say the original JUMP) I would expect
it to fail (or be forked).</div>
<div><br>
</div>
<div>During incubation we ask that the community be handled with
"open source" and that contributors be handled with "open
development". Beyond that (rather low) bar the specifics of how
a project intends to stay viable and manage its commercial
relationships is outside of our scope. </div>
<div><br>
</div>
<div>I had hoped that the OSGeo Foundation could be part of the
solution (a reason GeoTools joined the foundation was to pursue
funding for thankless tasks such as documentation and
marketing). The recent board decisions take this goal off the
table.</div>
<div>-- </div>
<div>
<div>Jody Garnett<br>
</div>
<div><br>
</div>
</div>
<p style="color:rgb(160,160,168)">On Thursday, 7 March 2013 at 4:54 PM,
Bruce Bannerman wrote:</p><blockquote type="cite"><div>
<span>
<div>
<div>
<div dir="ltr">This is a generic question that may help us
develop a consistent policy to be applied towards
projects that we are currently working with and those
that we may potentially work with in the future.<br>
<div><br>
<br>
I would appreciate some guidance on what we consider
acceptable commercial involvement within an OSGeo
project.<br>
<br>
</div>
<div>To start this discussion off, I will propose a set
of scenarios to help start and guide the conversation.<br>
<br>
</div>
<div>These are but four scenarios. There are of course a
continuum of variations to these.<br>
<br>
<br>
*****<br>
</div>
<div>Does OSGeo provide clear guidance as to what is
acceptable commercial involvement within an OSGeo
project?<br>
</div>
<div>*****<br>
<br>
</div>
<div>Where do we draw the line on what is considered
acceptable involvement?<br>
<br>
</div>
<div>Bruce<br>
</div>
<div><br>
<br>
=================</div>
<div>Scenario 1<br>
<br>
</div>
<div>Organisation X is interested in furthering the
development of project A. The involvement is:<br>
<br>
</div>
<div>* X allows staff to work on project A<br>
</div>
<div>* staff contribute work to project<br>
</div>
<div>* staff are assigned commit access<br>
</div>
<div>* staff work within project processes and Project
Steering Committee (PSC) to <br>
ensure that contributed work is assigned a priority
release date<br>
</div>
<div>* staff integrate work with rest of project code,
provide automated tests etc<br>
<br>
<br>
<br>
==================<br>
</div>
<div>Scenario 2<br>
<br>
</div>
<div>Organisation Y offers commercial services based on
project B.<br>
<br>
</div>
<div>* Y contracts staff to develop functionality on
behalf of a client G<br>
</div>
<div>* contract requires G to contribute software back
to project B<br>
* Y staff integrate work with rest of project code,
provide automated tests etc<br>
</div>
<div>* Y has both commit rights and staff on PSC and
ensure that work is <br>
prioritised for an early release.<br>
<br>
<br>
<br>
==================<br>
</div>
<div>Scenario 3<br>
<br>
<div>Same organisation Y offers commercial services
based on same project B.<br>
<br>
</div>
<div>* Y contracts staff to develop functionality on
behalf of a client H<br>
</div>
* contract does not allow Y to contribute software
back to project B<br>
* Y staff delivers software to client H as a
standalone branch of B<br>
</div>
<div>* Y will only integrate above work to project B if
paid a fee.<br>
<br>
<br>
==================<br>
</div>
<div>Scenario 4<br>
<br>
</div>
<div>Organisation Z releases their previously
proprietary software as an Open Source project under a
GPL Licence. This becomes Project C.<br>
<br>
</div>
<div>* Z also releases the software under dual
licensing, with a commercial <br>
closed source version containing more advanced
functionality than <br>
the open source version<br>
</div>
<div>* Project C attracts a number of developers<br>
</div>
<div>* Z retains control of PSC and discourages
developers from adding the <br>
functionality found in the closed source version to
the open source version<br>
</div>
<div>* if a developer does submit such functionality, it
is ranked by the PSC <br>
as low priority and is never released within the
open source version.<br>
<br>
</div>
<div>==================<br>
</div>
</div>
</div>
<div>
<div>_______________________________________________</div>
<div>Incubator mailing list</div>
<div><a href="mailto:Incubator@lists.osgeo.org" target="_blank">Incubator@lists.osgeo.org</a></div>
<div><a href="http://lists.osgeo.org/mailman/listinfo/incubator" target="_blank">http://lists.osgeo.org/mailman/listinfo/incubator</a></div>
</div>
</div>
</span> </div></blockquote><div> <br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Incubator mailing list
<a href="mailto:Incubator@lists.osgeo.org" target="_blank">Incubator@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/incubator" target="_blank">http://lists.osgeo.org/mailman/listinfo/incubator</a>
</pre>
</div></blockquote><br>
<pre cols="80">--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
<a href="http://www.faculty.jacobs-university.de/pbaumann" target="_blank">www.faculty.jacobs-university.de/pbaumann</a>
mail: <a href="mailto:p.baumann@jacobs-university.de" target="_blank">p.baumann@jacobs-university.de</a>
tel: <a href="tel:%2B49-421-200-3178" value="+494212003178" target="_blank">+49-421-200-3178</a>, fax: <a href="tel:%2B49-421-200-493178" value="+49421200493178" target="_blank">+49-421-200-493178</a>
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
<a href="http://www.rasdaman.com" target="_blank">www.rasdaman.com</a>, mail: <a href="mailto:baumann@rasdaman.com" target="_blank">baumann@rasdaman.com</a>
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: <a href="tel:%2B49-173-5837882" value="+491735837882" target="_blank">+49-173-5837882</a>
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
</pre>
</div></div></span>
</blockquote>
<div>
<br>
</div>
</div></div></blockquote></div><br></div></div></div></div></div>