[gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions

Howard Butler howard at hobu.co
Tue Jan 18 08:46:05 PST 2022



> On Jan 18, 2022, at 9:28 AM, Kemeter, Mathias via gdal-dev <gdal-dev at lists.osgeo.org> wrote:
> 
> Hi Even,
>  
> thanks for the feedback.
>  
> Let me briefly elaborate on the distinction between corporate and non-corporate contributors (…which I did not intend in the first place):
> As an individual, I can very well live with the general message and ‘sign’ the policy based on trust. As written before, I do understand this message and fully agree to it. 
> However, as an employee in a corporate environment, I will have to justify and quantify investments. No one likes that – but that’s just how it is.

As an open source community, we must also justify and quantify our time investments. A GDAL driver based on a binary SDK that is contributed by the company whose SDK it supports is a white elephant for the project. Fixing issues with it is often not simply a matter of putting in time and attention. GDAL's distribution mechanism provides a lot of value – the binary SDK proprietor is using GDAL to give the benefits of GDAL to its userbase. This RFC is about giving the PSC some tools to react when that cost/benefit as measured by the project is out of balance. 

> Accepting a policy means signing a contract. And if formulations leave room for interpretation, it gets harder to sign (or fulfill) this contract. As an individual I wouldn’t care too much. However, in a company with legal departments these thing are handled more strict.

There's no crying in baseball and there's no contracts in open source. It is run by social mores, social capital, and expertise/time gifting. Showing up cold to drop +15k lines onto a project in one which you have no social capital is rightly met with skepticism. It's the easiest thing for that project to just say no. 

This RFC is to flip the default policy to 'yes', but to provide some guidelines when the contribution has gone stale to the point that it is imposing time/money/maintenance/attention/usability cost on the project.

Howard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220118/c3a0291c/attachment.html>


More information about the gdal-dev mailing list