<div><div dir="auto">The key difference is they have asked and wish to be part of OSGeo. </div><div dir="auto"><br></div><div dir="auto">Some of the projects on the website belong to other organizations or companies or do not belong to an organization. Consider leaflet or geotrellis. </div><div dir="auto"><br></div><div dir="auto">The difference you list are from the benefits OSGeo provides, we may also wish to highlight requirements.</div><div dir="auto"><br></div><div dir="auto">We are estblishig the requirements now, if you check back to August you can see some of the concerns that were raised about setting requirements. I would strongly prefer to avoid subjective requirements. </div><br><div class="gmail_quote"><div>On Tue, Jan 23, 2018 at 5:04 AM Alex HighViz <<a href="mailto:alexhighviz@hotmail.com">alexhighviz@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Jody,<br>
<br>
Could you clarify the substantial difference between OSGeo Community projects and OSGeo only-listed-on-the-website projects?<br>
<br>
I can see the following differences:<br>
<br>
- Community projects are voted on by the Incubator Committee<br>
- There is some budget that Community projects can apply for<br>
- Community projects are more prominently positioned on the OSGeo website and may display a Community badge<br>
- Community projects receive some mentoring<br>
<br>
None of these differences is substantially about the project. It is not clear to me why any only-listed-on-the-website project, wouldn’t be a Community project.<br>
<br>
When a project is nominated as a Community project, what is it that the Incubator Committee is really voting on? Is it about meeting the formal OSGeo requirements? Or is it about more subjective criteria, e.g. whether the committee members like the project; think it is well managed; offers a valuable service; has potential for future development; has reputable developers; etc. ?<br>
<br>
I looked at the mailing list archive to get an idea of what is being considered, but there is limited public discussion.<br>
<br>
Thanks, Alex<br>
<br>
<br>
<br>
From: Incubator [mailto:<a href="mailto:incubator-bounces@lists.osgeo.org" target="_blank">incubator-bounces@lists.osgeo.org</a>] On Behalf Of Jody Garnett<br>
Sent: 23 January 2018 05:46<br>
To: <a href="mailto:incubator@lists.osgeo.org" target="_blank">incubator@lists.osgeo.org</a><br>
Subject: Re: [Incubator] about the website and reviewing incoming projects<br>
<br>
Some of the feedback (and questions) I have gotten privately points out that we do not ask very much more out of our "osgeo community" projects. I think that is by design, we would like OSGeo to be an organization that is easy to join.<br>
<br>
Something to consider:<br>
<br>
a) relax the requirement to be listed on the website to just be "open source license" (ie no check of headers)<br>
<br>
b) increate the requirement for "osgeo community" to include making a release<br>
<br>
What do you think?<br>
<br>
<br>
<br>
--<br>
Jody Garnett<br>
<br>
On 11 January 2018 at 10:12, Jody Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>> wrote:<br>
Discussion in August focused on what to do with projects that bridge to proprietary work.<br>
- Projects like GeoTools or GDAL obviously do so to help bridge the gap and introduce more people to open source.<br>
- Projects that require an "API Key" or similar may be open source in license, but have the opposite intent directing open source to paid services.<br>
<br>
How can we tell these two stories apart?<br>
<br>
The other group I work with, LocationTech, captures this distinction between "works with" vs "dependency". I do not know if we want to make up a similar hard line at OSGeo. The general idea is a "dependency" is required for a project to run, a "works with" unlocks additional functionality or integration if present in the execution environment.<br>
<br>
Why is this not clear cut? Because some projects are an open source response from users of a proprietary product wanting to share their knowledge. This is however an exceptional case - I think we could write up a guidelines to reject applications that require an API key, and then be open to community lead projects asking for an exemption <br>
<br>
This is a hotbed topic, where our community needs to think through its principles and commitment to open source. I am willing to accept that ordinations such as ESRI are capable of adopting open source principles over time - and our mission is an organization is to encourage such change.<br>
<br>
The caution on this, as mentioned in the august discussion, mentioned "open washing" which I take to mean adopting some of the language of open geospatial (usually open data and open standards) as a marketing ploy. We also need to be careful to not accept projects like the recent "mapzen dumping" that are open source in license, but do not have a mechanism for participation and fair governance. Both of these examples send the wrong message about what open source is for and do not align with the "empower" part of "empower everyone with open source geospatial".<br>
<br>
I think by keeping these two extremes (API key as a dependency is a clear case of requiring a license to use) and open source dumping (a GitHub repository with an open source license is not an open source project capable of accepting contributions) we can stay true to our principles.<br>
<br>
We have members who are passionate about "open source", and also members that are passionate about "free and open source". We have to go into this knowing we will not make everyone happy - and that both viewpoints are right. <br>
<br>
I am in open source for the long game, indeed that is the reason I volunteer here in the incubation committee.<br>
<br>
</blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<div>Jody Garnett</div></div></div>