[Incubator] about the website and reviewing incoming projects

[Jody Garnett]

The key difference is they have asked and wish to be part of OSGeo.

Some of the projects on the website belong to other organizations or
companies or do not belong to an organization. Consider leaflet or
geotrellis.

The difference you list are from the benefits OSGeo provides, we may also
wish to highlight requirements.

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.

On Tue, Jan 23, 2018 at 5:04 AM Alex HighViz <alexhighviz at hotmail.com>
wrote:

> Dear Jody,
>
> Could you clarify the substantial difference between  OSGeo Community
> projects and OSGeo only-listed-on-the-website projects?
>
> I can see the following differences:
>
> - Community projects are voted on by the Incubator Committee
> - There is some budget that Community projects can apply for
> - Community projects are more prominently positioned on the OSGeo website
> and may display a Community badge
> - Community projects receive some mentoring
>
> 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.
>
> 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. ?
>
> I looked at the mailing list archive to get an idea of what is being
> considered, but there is limited public discussion.
>
> Thanks, Alex
>
>
>
> From: Incubator [mailto:incubator-bounces at lists.osgeo.org] On Behalf Of
> Jody Garnett
> Sent: 23 January 2018 05:46
> To: incubator at lists.osgeo.org
> Subject: Re: [Incubator] about the website and reviewing incoming projects
>
> 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 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
> 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.
>
> --
--
Jody Garnett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20180123/add754ad/attachment.html>