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

[Javier Jimenez Shaw]

Kudos++
Even's question about deprecating drivers triggered several discussions:

- Should we deprecate unused drivers? or how to find out that many drivers
are really not used? I liked the idea of reducing the weight in gdal with
unused code. Breaking the execution is the only way that most of the people
understand, and enabling them via environment variable is a good workaround
imho. Unfortunately the timing of Ubuntu LTSs does not help with the
proposed calendar.
If we maintain a library to use old and inefficient formats, "natural
selection" will never extinguish them. (Ok, I do not use any of the formats
in the list, so maybe I am a bit biased).

- How to make GDAL more attractive for contributors? We know that Even is
the main contributor by far. Making the code easier to maintain is a good
idea. It is going to be enough?

- How to finance the development of GDAL? Well, do not forget that Even is
also working a lot in PROJ, a library by the way used by GDAL... (should
GDAL contribute to PROJ, as QGIS should contribute to GDAL and PROJ?) I do
not know how do the donations to QGIS work, and how complicated is to
organize that. A friend mentioned GitHub Sponsors (
https://github.com/sponsors) . Maybe it is an easy way. Not only private
companies may contribute. I am sure that many governmental institutions are
using GDAL and  PROJ in a daily basis. However, as somebody said, the
developer that codes with GDAL usually does not have any power to induce
the company to make a donation. That is my case... but I still insist every
few months (I guess they ignore me more and more).

I want to thank Even for the great work he is doing.

Cheers
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Wed, 13 Jan 2021 at 21:24, David Strip <gdal at stripfamily.net> wrote:

> Kudos to Howard for his succinct summary of the situation and the call to
> action. While I have nowhere near his experience with open source, my
> experience with other volunteer organizations reveals a similar pattern.
> One person, or maybe a small number of people, carry the burden of keeping
> the organization running. This goes on for years until someone burns out.
> Sometimes new people step before chaos sets in, but too often the
> organization begins a death spiral.
>
> Open source broadly is facing something of a turning point as commercial
> organizations have learned how to profit from open source, but have not yet
> learned they have to contribute to the commons. A particularly relevant
> example is the case of MongoDB where cloud services were offering paid
> hosting while paying nothing to support the project. Gdal's situation
> strikes me as similar. Large commercial vendors are embedding gdal in their
> offerings, either directly in software delivered to users or as part of the
> infrastructure behind the services they provide. Some of these companies
> are very profitable and could well afford to pay their way. Unfortunately,
> it is often the case that the developer who is aware of this reliance on
> gdal may not be in a position to convince his/her management to ante up for
> the "free" software.
>
> 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. MongoDB created a license class
> directed at the cloud suppliers who were (morally) abusing the free license
> terms. gdal could adopt a license that requires those bundling gdal into a
> commercial product or service to pay their way. As I said, this would no
> doubt be quite controversial. Then there's the case of "second-order"
> free-riders. Gdal is critical technology underlying Qgis, another free,
> open-source project. Should firms that contribute to the qgis foundation
> also contribute to gdal, or can they rely on the appropriate portion of
> their "dues"  to be forwarded to gdal?
>
>
> _______________________________________________
> 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/48d8af6a/attachment-0001.html>