[Incubator] about the website and reviewing incoming projects

Jo Cook jocook at astuntechnology.com
Tue Jan 23 06:30:17 PST 2018


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>
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> 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
> 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 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 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/8b3aa8a7/attachment.html>


More information about the Incubator mailing list