[gdal-dev] Driver maintenance - long-term solution ?

[Carl Godkin]

Hi everyone,

Regarding funding, I thought the barn raising that Howard mentioned from a
few years ago was a good thing.  My little company made a donation and I
think we'd do it again were another "barn" proposed.  Tools like GDAL &
PROJ and related projects are worth supporting and periodic donations seem
to be an easy way to pay our part.

Thanks,
carl

On Wed, Jan 13, 2021 at 2:58 PM Howard Butler <howard at hobu.co> wrote:

>
>
> On Jan 13, 2021, at 4:28 PM, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>
> On Thu, 14 Jan 2021 at 06:24, David Strip <gdal at stripfamily.net> wrote:
>
> What is the path forward?  One path Howard suggests is establishing a
> foundation similar to that behind Qgis. Another alternative, probably far
> more controversial, is a license change.
>
>
> I'm pretty clueless regarding licenses -- but this is an interesting
> thought. I wonder if any new drivers added to GDAL could be done with
> a dual-licensing under both GPL + some other license which requires
> ongoing sponsorship of the GDAL project?
>
>
> License monkey business isn't viable in any way with GDAL. It would just
> create confusion and erode trust, which we can't get back if broken.
>
> The big organizations running 100,000,000s of CPU hours extracting
> information from imagery they're reading in COGs with GDAL need to be
> donating substantial resources into an organization that provides
> coordination. The last time I did a fund raise with gdalbarn.com I was
> called out for naming some of these organizations and expressing my
> disappointment they couldn't find a way to participate or simply ignored
> the request.  Maybe they will step forward this time around.
>
> Whether it is in a new foundation or an existing one like NumFocus,
> substantial resources need to be dumped in a pot that are earmarked for
> supporting work that generates value for the project. Chasing new feature
> work to subsidize project maintenance activities is not sustainable in two
> directions – burn out for the maintainer and creeping feature-itis for the
> project.
>
> It's clear what's happened in the past is a combination of luck and
> graciousness by both Frank and Even.
>
> Howard
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210113/86dd19d8/attachment-0001.html>