[Incubator] about the website and reviewing incoming projects

[Jody Garnett]

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> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20180122/664a3fa2/attachment-0001.html>