[Incubator] about the website and reviewing incoming projects

Jody Garnett jody.garnett at gmail.com
Thu Jan 11 10:12:06 PST 2018

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

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

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

I am in open source for the long game, indeed that is the reason I
volunteer here in the incubation committee.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20180111/b75e2da2/attachment.html>

More information about the Incubator mailing list