[Incubator] about the website and reviewing incoming projects

Tue Jan 23 07:14:23 PST 2018

Hi Jo, Jody

I agree that the release requirement is not onerous and that it is in fact a helpful requirement. Just did it!

Kind regards, Alex

From: Incubator [mailto:incubator-bounces at lists.osgeo.org] On Behalf Of Jo Cook
Sent: 23 January 2018 14:30
To: Jody Garnett <jody.garnett at gmail.com>
Cc: incubator at lists.osgeo.org
Subject: Re: [Incubator] about the website and reviewing incoming projects

Hi Jody,

While I'm not on the Incubation Committee, my feeling is that  you shouldn't relax the requirement for checking the headers, and that you should include making a release as a requirement for "osgeo community". The requirements are not onerous, and in my mind help people get going with good practices. I certainly learnt a fair bit from going through the process.

Regards

Jo

On Tue, Jan 23, 2018 at 5:45 AM, Jody Garnett <jody.garnett at gmail.com<mailto:jody.garnett at gmail.com>> wrote:
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.

Something to consider:

a) relax the requirement to be listed on the website to just be "open source license" (ie no check of headers)

b) increate the requirement for "osgeo community" to include making a release

What do you think?

--
Jody Garnett

On 11 January 2018 at 10:12, Jody Garnett <jody.garnett at gmail.com<mailto:jody.garnett at gmail.com>> wrote:

Discussion in August focused on what to do with projects that bridge to proprietary work.

- Projects like GeoTools or GDAL obviously do so to help bridge the gap and introduce more people to open source.

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

How can we tell these two stories apart?

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.

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

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<https://staging.www.osgeo.org/resources/open-source-projects-esri/> are capable of adopting open source principles over time - and our mission is an organization is to encourage such change.

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<https://github.com/nextzen> 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".

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.

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.

I am in open source for the long game, indeed that is the reason I volunteer here in the incubation committee.

_______________________________________________
Incubator mailing list
Incubator at lists.osgeo.org<mailto:Incubator at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/incubator

--
Jo Cook
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com<http://support.astuntechnology.com/> or phone our office on 01372 744009

--
Astun Technology Ltd, The Coach House, 17 West Street, Epsom, Surrey, KT18 7RL, UK
t:+44 1372 744 009 w: astuntechnology.com<http://astuntechnology.com/> twitter:@astuntech<https://twitter.com/astuntech>

iShare - enterprise geographic intelligence platform<https://astuntechnology.com/ishare/>
GeoServer, PostGIS and QGIS training<https://astuntechnology.com/services/#training>
Helpdesk and customer portal<http://support.astuntechnology.com/support/login>

Company registration no. 5410695. Registered in England and Wales. Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no. 864201149.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20180123/8b2f501b/attachment-0001.html>